{"aaData": [["1", "DBIA1", "Other", "KERNEL", "1989/07/27", "APPROVED", "Active", "Private", "", "", "", "", "2000/01/01"], ["2", "DBIA2", "Other", "KERNEL", "1989/07/27", "APPROVED", "Active", "Private", "", "", "", "", ""], ["3", "DBIA3", "Other", "KERNEL", "1989/07/27", "APPROVED", "Active", "Private", "", "
Using the following variables: DT= Date DTIME = Read
timeout DUZ = User and paramaters in the DUZ array", "", "", ""], ["4", "DBIA4-A", "File", "KERNEL", "1989/07/27", "", "Retired", "Private", "", "", "", "", ""], ["5", "DBIA5-A", "File", "KERNEL", "1989/07/27", "", "Retired", "Private", "19", "", "", "", ""], ["6", "DBIA6-A", "Other", "1", "1989/07/27", "APPROVED", "Active", "Private", "", "
The following variables are killed only:
D0,DI,DIG,DIH,DIU,DIV,& DIQ DIROUT - Is used as a quick exit when ^^ is
entered at prompts. DLAYGO - is used for calls to Fileman.", "", "", ""], ["7", "DBIA7", "File", "KERNEL", "1989/07/27", "APPROVED", "Active", "Private", "", "
Uses variables DX and DY to call %ZOSF and global %ZOSF
to get system specific variables.", "", "", ""], ["8", "DBIA8", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1990/03/15", "", "Retired", "Private", "", "
KERNEL 6.5 USES/HAS INCLUDED ADD^OR1 & AFT^OR1", "", "OR1", ""], ["9", "DBIA9", "Other", "VETERANS ADMINISTRATION", "1990/03/15", "", "Pending", "Private", "", "
KERNEL AND TOOLKIT USES VA NAMESPACE FOR ^VA(200,
PERSON FILE.", "", "", ""], ["10", "DBIA10", "File", "KERNEL", "1990/03/12", "APPROVED", "Active", "Private", "40.5", "
USE OF THE HOLIDAY FILE, ^HOLIDAY", "", "", ""], ["11", "DBIA11", "File", "REGISTRATION", "1990/03/20", "APPROVED", "Active", "Private", "", "
Use of variable pointers to DPT & REFFERAL File. Uses
following patient nodes:\n
Address Node .11
Phone node .13
Field 1, Alias subfile
0 Node", "", "", ""], ["12", "DBIA12", "Other", "LAB SERVICE", "1990/03/21", "APPROVED", "Active", "Private", "", "
USE OF FILE 63 NODE "LR" AND ^LRDPT FOR DEATH
INFORMATION", "", "", ""], ["13", "DBIA13", "File", "REGISTRATION", "1990/03/21", "APPROVED", "Active", "Private", "2", "
PATIENT NODE .35 - DEATH INFO USED TO STUFF ^LR(
GLOBAL.", "", "", ""], ["14", "DBIA14", "Routine", "GEN. MED. REC. - VITALS", "1990/02/23", "", "Retired", "Private", "", "", "", "GMRVUT0", ""], ["15", "DBIA15-A", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1990/02/23", "APPROVED", "Active", "Private", "70", "
RADIOLOGY PATIENT FILE CROSS REFERENCE", "", "", ""], ["16", "DBIA16", "File", "SURGERY", "1990/02/26", "APPROVED", "Active", "Private", "130", "
Surgery file (130).", "", "", ""], ["17", "DBIA17-A", "File", "REGISTRATION", "1990/03/12", "APPROVED", "Active", "Controlled Subscription", "405", "
PATIENT MOVEMENT FILE (405).", "", "", ""], ["18", "DBIA18", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
Hospital Location file (44)", "", "", ""], ["19", "DBIA19", "File", "SCHEDULING", "1990/01/29", "APPROVED", "Active", "Private", "40.7", "", "", "", ""], ["20", "DBIA20", "Routine", "SCHEDULING", "1987/05/07", "", "Retired", "Private", "", "", "", "SDACS", ""], ["21", "DBIA21", "File", "REGISTRATION", "1989/12/08", "APPROVED", "Active", "Private", "2", "
Fields 220 and 220.1 of the Patient Files were
established for Dental use and Dental will begin using them.", "", "", ""], ["22", "DBIA22", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "", "", "", ""], ["23", "DBIA23", "File", "REGISTRATION", "1990/01/18", "", "Retired", "Private", "2", "", "", "", ""], ["24", "DBIA24", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "", "", "", ""], ["25", "DBIA25", "File", "PHARMACY DATA MANAGEMENT", "1989/09/18", "", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at REDACTED OI SDD
PHARM REENG DEV using Microsoft Outlook. Redaction applied since Retired.", "", "", ""], ["26", "DBIA26", "File", "KERNEL", "1989/05/08", "APPROVED", "Active", "Private", "", "", "", "", ""], ["27", "DBIA27", "File", "REGISTRATION", "1989/07/17", "APPROVED", "Active", "Private", "45", "", "", "", ""], ["28", "DBIA28", "Routine", "REGISTRATION", "1989/03/21", "", "Retired", "Private", "", "
*****TEMPORARY SUPPORTED CALL FOR IFCAP V2 TEST SITES
ONLY*****
call to ZIS^DGUTL", "", "DGUTL", ""], ["29", "DBIA29", "File", "1", "1990/02/13", "APPROVED", "Active", "Private", "", "
Routines LRWU5 & LRWU7 Do direct sets to the Data
Dictionary. The routines allow the user to add a new Data Name or Antibiotic
without giving programmer access.", "", "", ""], ["30", "DBIA30-A", "File", "REGISTRATION", "1989/11/14", "", "Retired", "Private", "2", "", "", "", ""], ["31", "DBIA31-A", "File", "REGISTRATION", "1989/11/14", "APPROVED", "Active", "Private", "42", "", "", "", ""], ["32", "DBIA32", "File", "REGISTRATION", "1989/11/14", "", "Expired", "Private", "2", "
Inpatient Medic ations will be referenceing the
following files & fields:\n
FILE 2 401 ADMISSION DATE/TIME subfile & all fields
2 TRANSFER DATE/TIME " "
5 TREATING SPECIALTY " "
57.1 HEIGHT
57.2 WEIGHT
53 REACTIONS
55 GENERIC DRUG subfile
57 ALLERGIES/DISORDERS subfile
X-REF "AA","AD","AT"\n
EXPIRED AS OF THE RELEASE OF MAS 5", "", "", ""], ["33", "DBIA33", "File", "REGISTRATION", "1989/11/14", "APPROVED", "Active", "Private", "42", "
Inpatient Medications will be referencing the following
files & fields:\n
FILE 42 2 ROOM subfile & all fields
2 BED " "
X-REF "B" on ROOM-BED\n
FILE 42.3 TRANSFER TYPE\n
EXPIRED AS OF THE RELEASE OF MAS 5.\n", "", "", ""], ["34", "DBIA34-A", "File", "OUTPATIENT PHARMACY", "2003/06/10", "", "Retired", "Private", "50.5", "
Direct references are made to the globals to get
allergy information.", "", "", ""], ["35", "DBIA35", "Other", "VETERANS ADMINISTRATION", "1989/03/22", "", "Retired", "Private", "", "
Variables VADM & VAIN are used when calling ^VADPT\n
Global ^DIC(16 is used to lookup person requesting orders and to print
attending physician.\n
Routines OERR^VADPT & INP^VADP are used to get patient variables.", "", "", ""], ["36", "DBIA36-A", "File", "REGISTRATION", "1989/03/22", "APPROVED", "Active", "Private", "42", "\n
^DIC(42 Used to get link to file 44 for inpatients", "", "", ""], ["37", "DBIA37", "File", "REGISTRATION", "1989/03/22", "", "Retired", "Private", "2", "
Uses the variable DFN and the following globals:
^DPT(DFN,.101 for Treating Specialty
^DPT(DFN,"PA" for patient allergies
^DPT(DFN,"PI" " "
^DPT(DFN,"PF" " "
^DPT(DFN,"PG" " "
^DPT "CN" X-Reference for ward reports", "", "", ""], ["38", "DBIA38", "Other", "LAB SERVICE", "1988/05/23", "APPROVED", "Active", "Private", "", "
Cardiology package exports Lab Codes for Cardiology.", "", "", ""], ["39", "DBIA39", "File", "REGISTRATION", "1990/01/23", "", "Expired", "Private", "2", "
AMIE uses the following:
INP^VADPT to get inpatient information", "", "", ""], ["40", "DBIA40", "File", "KERNEL", "1989/02/10", "", "Retired", "Private", "16", "
File 16 (old Person File) exported with version 3 of
Patient Funds.", "", "", ""], ["41", "DBIA41", "File", "1", "1990/06/06", "APPROVED", "Active", "Private", "", "
Routine DGABTP30 (background job) sets the ^DIBT
global. The routine checks for sort templates, specifically [DGPMABSENCES] &
[DGPMAB30], through the crossreference, and uses the template's IFN to set
node ^DIBT(IFN,1,MOVEMENT IFN) for selected records.", "", "", ""], ["42", "DBIA42", "File", "KERNEL", "1990/06/06", "APPROVED", "Active", "Private", "4", "
LAYGO to the Institution File is allowed through an
option in the MCCR module.", "", "", ""], ["43", "DBIA43", "File", "IFCAP", "1990/06/18", "APPROVED", "Active", "Private", "442", "", "", "", ""], ["44", "DBIA44", "File", "REGISTRATION", "1990/06/26", "APPROVED", "Active", "Private", "43", "", "", "", ""], ["45", "DBIA45", "File", "REGISTRATION", "1990/06/26", "", "Retired", "Private", "43", "", "", "", ""], ["46", "DBIA46", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1990/03/15", "", "Retired", "Private", "", "
ADD^OR1 AND AFT^OR1 are necessary integration links
between OE/RR & Kenrel", "", "OR1", ""], ["47", "DBIA47", "File", "REGISTRATION", "1990/07/25", "APPROVED", "Active", "Private", "41.9", "", "", "", ""], ["48", "DBIA48", "File", "DRG GROUPER", "1990/07/25", "APPROVED", "Retired", "Private", "80.2", "", "", "", ""], ["49", "DBIA49", "File", "MAILMAN", "1990/08/07", "", "Retired", "Private", "3.7", "
The only package granted a DBA to extract data from
MailMan's file 3.7 is Albany's Site Installation Report.\n\n
References and extracts data from ^XMB global. $O's thru the Postmaster's
basket, ^XMB(3.7,.5.2."B" ,to get IFN for SIR.REDACTED basket, then $O's thru
messages in the basket & extracts data into a FM file.\n
DURATION: Till next version of Fileman (v.18) when filegram and mail server
functionality is available.\n
If this DBA is NOT OUT-OF-DATE and to be deleted, please note change suggested
below.", "", "", ""], ["50", "DBIA50", "File", "IFCAP", "1990/10/17", "", "Retired", "Private", "420.1", "
DMMS Points to and reads the .01 field (cost center) of
file 420.1", "", "", ""], ["51", "DBIA51", "File", "1", "1990/10/22", "APPROVED", "Active", "Private", "720", "
The .01 field of file 720, "B" crossreference has been
modified to be 50 characters rather than the standard 30.", "", "", ""], ["52", "DBIA52", "File", "1", "2003/06/10", "", "Retired", "Private", "50", "
The "B" cross reference on the .01 field of the Drug
File is 40 characters rather than the standard 30.", "", "", ""], ["53", "DBIA53", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
DSS Extracts references the following data from the
PRESCRIPTION file(#52).\n
For the extract date range, DSS uses the following cross references:
"AD" cross reference ^PSRX("AD",DATE,D0,REFILL# or 0 for NEW RX
"AL" cross reference ^PSRX("AL",DATE,D0,REFILL# or 0 for NEW RX
"AM" cross reference ^PSRX("AM",DATE,D0,PARTIAL_REFILL#
"AR" cross reference ^PSRX("AR",DATE,D0,FILL#\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["54", "DBIA54", "Other", "ACCOUNTS RECEIVABLE", "1990/07/05", "APPROVED", "Active", "Private", "", "
MAS version 4.7 will be exporting the following:\n
Routine PRCASVC3
FILE 430.4 AR BILL NUMBER FILE wit input template PRCAF COMMON SERIES\n
Following options make the indicated forgien calls:\n
OPTION ACTION
DGCR FILLING SUPERVISOR MENU calls COUNT^PRCAUT2
DGCR BILLING CLERK MENU calls COUNT^PRCAUT2
DGCR RETURNED BILL LIST calls RETN^PRCALST
DGCR CANCEL BILL calls CANCEL^PRCASVC1
Return of edited bill calls REL^PRCASVC", "", "", ""], ["55", "DBIA55", "File", "1", "1990/11/28", "APPROVED", "Active", "Controlled Subscription", "", "
Since the use of ^DOPT has a long and honored history,
it may be permitted to be used until further notice.", "", "", ""], ["56", "DBIA56", "File", "1", "1990/11/28", "APPROVED", "Active", "Private", "", "
Given the longstanding history of the use of ^DOPT,
scheduling may continue to use it.", "", "", ""], ["57", "DBIA57", "File", "SURGERY", "1990/12/04", "APPROVED", "Active", "Private", "130", "", "", "", ""], ["58", "DBIA58", "File", "KERNEL", "1990/11/27", "APPROVED", "Active", "Private", "200", "", "", "", ""], ["59", "DBIA59-A", "File", "LAB SERVICE", "2005/05/25", "", "Retired", "Private", "68", "
- ECT namspaced option runs routine ^LRUPACA
Enter ACTION: S DIC=68,DIC(0)="QEAM" D ^DIC K DIC I Y>0 S LRAA=+Y,
LRAA(1)=$P(Y,U,2)\n
- ECT namespaced option runs routine ^LRCAPS.\n
- Refences file 68 Accession (read only)
2 DATE
.01 DATE
1 ACCESSION NUMBER
.01 LRDFN
11 TESTS
.01 TESTS", "", "", ""], ["60", "DBIA60-A", "Routine", "OUTPATIENT PHARMACY", "1990/12/11", "", "Retired", "Private", "", "
Version 1 of Health summaries exports and calls routine
PSOHCSUM. It is exported as routine GMTSPSZO and renamed if needed. Health
Summary post-inits check the environment for existance of PSOHCSUM.\n
- If PSOHCSUM does not exist or is an earlier version than 6,
GMTSPSZO is renamed PSOHCSUM.\n
- If PSOHCSUM exists and is version 6 or greater, no changes are
made.\n
^GMTSPSO is the component driver, which sets up the context and calls the
extract routine prior to printing. ^PSOHCSUM extracts data from the pharmacy
files for use with the Health Summary.", "", "PSOHCSUM", ""], ["61", "DBIA61", "File", "INTEGRATED BILLING", "1990/11/05", "APPROVED", "Active", "Private", "36", "
MAS may request Social Work to use an MAS supplied
utility for future versions.", "", "", ""], ["62", "DBIA62", "File", "NURSING SERVICE", "1990/10/22", "APPROVED", "Active", "Private", "214.6", "
Subject to version 2.5 purge allowing 6 months data
only.\n
DSS uses the "B" cross reference on the CLASSIFICATION DATE/TIME field.
Global: ^NURSA(214.6,"B",DATE,D0)", "", "", ""], ["63", "DBIA63", "File", "DENTAL", "1990/10/22", "APPROVED", "Active", "Private", "221", "
In addition to the field references as indicated below,
a direct global read of the 'B' Cross Reference may be made in the DENTAL
TREATMENT (AMIS) file.", "", "", ""], ["64", "DBIA64", "File", "BENEFICIARY TRAVEL", "1990/08/21", "APPROVED", "Active", "Private", "392.4", "", "", "", ""], ["65", "RAD/NUC MED PATIENT file data extract", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1990/10/22", "APPROVED", "Active", "Controlled Subscription", "70", "
This Integration Agreement allows subscribers to read
data from the NAME (#.01) field (top-level, DINUMed) and agreed to fields
associated with the REGISTERED EXAMS (#70.02) and EXAMINATIONS (#70.03)
sub-files.", "", "", "2023/10/03"], ["66", "DBIA66", "File", "KERNEL", "1990/11/25", "", "Retired", "Private", "16", "
Part of file 16 is exported with IFCAP THIS AGREEMENT
SHOULD END BY LATE 1992.", "", "", ""], ["67", "LAB TEST NAMES, PANELS, REFERENCE VALUES", "File", "LAB SERVICE", "1991/01/31", "", "Other", "Controlled Subscription", "60", "
Allows access to several group of fields in LABORATORY
TEST file (#60).", "", "", ""], ["68", "DBIA68-A", "Routine", "UNIT DOSE PHARMACY", "1991/01/31", "", "Retired", "Private", "", "
^GMTSPSG is the component driver, which sets up the
context and calls the extract routine prior to printing.\n
^PSJEEU0 extracts data from the pharmacy files for use with the health
summary. If ^PSJEEU0 is not available (i.e., Inpatient Meds package not yet
installed), then ^GMTSPSGE is called, which accesses the same fields as
^PSJEEU0.\n", "", "PSJEEU0", ""], ["69", "DBIA69-A", "Routine", "IV PHARMACY", "1991/01/31", "", "Retired", "Private", "", "
^PSJEEU0 routine available in version 3 of Inpatient
Medications Package will be used to extracts data from the pharmacy files for
use with the health summary. If ^PSJEEU0 is not available (i.e., Inpatient
Meds package not yet installed), then ^GMTSPSIE is called, which accesses the
same fields as ^PSJEEU0.\n", "", "PSJEEU0", ""], ["70", "DBIA70", "Other", "LAB SERVICE", "1991/02/01", "", "Retired", "Private", "", "
Version 1 of Health Summaries exports a partial DD for
the Lab Orders File (#60), which includes a new whole-file cross-reference
named "D", which indexes the file by Patient, Collection date and Specimen #.
In addition, the routines LROW2A, LRORDST, LRORDST1 and LROC, which have been
modified to execute the SET and KILL logic for the "D" cross-reference, are
renamed and exported in the following manner:\n
LROW2A as GMTSLRZ1,
LRORDST as GMTSLRZ2,
LRORDST1 as GMTSLRZ3 and
LROC as GMTSLRZ4.\n
When the post-init routine, GMTSPOST is run, it renames the GMTSLRZ* routines
as their corresponding LRO-namespaced routines as outlined above, if and only
if the following conditions are met:\n
1. The Laboratory Package is installed.
2. The installed version of Lab is NOT less than 5.0.
3. The installed version of Lab IS less than 5.1.", "", "", ""], ["71", "DBIA71", "Other", "LAB SERVICE", "1991/02/01", "APPROVED", "Active", "Private", "", "
The Laboratory Package developers have granted the
Health Summary team permission to add the application group "GMTS" to ^DIC(60,
when file 60, the Laboratory test file, exists.", "", "", ""], ["72", "DBIA72", "Other", "ORDER ENTRY/RESULTS REPORTING", "1991/02/04", "", "Retired", "Private", "", "
Permission has been granted for Health Summary to
export the routines:\n
ORF4 as GMTSORF4 and
ORF5 as GMTSORF5.\n
GMTSPOST, the Health Summary post-init, will rename the GMTSORF* routines as
their ORF* counterparts, if and only if ORF4 is not found in the UCI by
execution of ^%ZOSF("TEST").", "", "", ""], ["73", "DBIA73", "Other", "DIETETICS", "1991/02/04", "APPROVED", "Active", "Private", "", "
Permission has been granted for Health Summary to
export the routine:\n
FHWHEA as GMTSFHWZ\n
GMTSPOST, the Health Summary post-init, will rename GMTSFHWZ as FHWHEA, if and
only if FHWHEA is not found in the UCI by execution of ^%ZOSF("TEST").", "", "", ""], ["74", "DBIA74-A", "File", "PROGRESS NOTES", "1991/02/04", "", "Retired", "Private", "121", "
Agreement has been made for Health Summary to access
specific fields in the Generic Progress Notes files.\n
- The cross-references ^GMR(121,"AJ2" and "AC", are traversed.
- Globals accessed are:
^GMR(121, Generic Progress Notes", "", "", ""], ["75", "DBIA75-A", "File", "MENTAL HEALTH", "1991/02/04", "APPROVED", "Active", "Private", "606", "
Agreement has been made for Health Summary to access
the following fields in the Mental Health Progress Notes files.\n
- The cross-reference ^YSP(606,"AC", is traversed.
- Globals accessed are:
^YSP(606, Progress Notes\n
- The following fields are accessed:
^YSP(606, 606 .03 DATE/TIME OF PROGRESS NOTE
606 1 TYPE OF PROGRESS NOTE
606 2 AUTHOR
606.01 .01 TEXT
606.02 .01 SUBJECTIVE
606.021 .01 OBJECTIVE
606.022 .01 ASSESSMENT
606.023 .01 PLANS
606 30 DXLS
606 31 DISCHARGE BED SECTION
606.032A .01 OTHER DIAGNOSES
606.033 .01 OPERATIONS/PROCEDURES
606.034 .01 INSTRUCTIONS GIVEN TO PATIENT
606.04 .01 EMOTIONAL STATE
606.041 .01 BEHAVIORAL ASSESSMENT
606.042 .01 SOCIAL STATUS
606.043 .01 REHABILITATION POTENTIAL
606.044 .01 EMPLOYMENT POTENTIAL
606.045 .01 DEGREE OF DANGER - SELF/OTHERS
606.046 .01 ABNORMAL PHYSICAL FINDINGS
606.047 .01 INIT IMPRESSION/PROVISIONAL DX
606.048 .01 STATEMENT OF TREATMENT PLANNED
606.03 .01 COMMENTS/CORRECTIONS", "", "", ""], ["76", "DBIA76", "File", "REGISTRATION", "1990/03/12", "", "Retired", "Private", "2", "
For MAS versions preceeding 5:\n
The following cross references are used to access ADT information
^DPT(D0,"DA","AA", Admissions
^DPT(D1,"DA",D0,2,"ATT" Transfers
^DPT(D1,"DA",D0,"T", Treating specialties\n
The DGLOS routine will be used to get the length of stay.", "", "", ""], ["77", "DBIA77", "File", "DIETETICS", "1991/02/04", "APPROVED", "Active", "Private", "115", "
The following fields will be accessed to get patient
food allergies:
^FHPT( 115 DIETETICS PATIENT
.1 Food Allergies", "", "", ""], ["78", "DBIA78", "Other", "GEN. MED. REC. - VITALS", "1991/02/05", "APPROVED", "Active", "Private", "", "
The Vitals Package developers have granted the Health
Summary team permission to add the application group "GMTS" to ^DIC(120.51,
when file 120.51, the Vital Type file, exists.", "", "", ""], ["79", "DBIA79", "Other", "KERNEL", "1991/02/05", "", "Retired", "Private", "", "
Permission has been granted for Health Summary to
export the routines:\n
XQOR as GMTSXQ01
XQOR1 as GMTSXQ02
XQOR2 as GMTSXQ03
XQOR3 as GMTSXQ04
XQOR4 as GMTSXQ05
XQORM as GMTSXQ06
XQORM1 as GMTSXQ07
XQORM2 as GMTSXQ08
XQORM3 as GMTSXQ09
XQORM4 as GMTSXQ10
XQORM5 as GMTSXQ11
XQORMX as GMTSXQ12
XQORO as GMTSXQ13\n
GMTSPOST, the Health Summary post-init, will rename GMTSXQ* as the
corresponding XQOR* routines if and only if the version of XQOR found in the
account is less than 6.52.", "", "", ""], ["80", "DBIA80-A", "File", "CLINICAL PROCEDURES", "1991/02/05", "APPROVED", "Active", "Controlled Subscription", "690", "
This DBIA documents references to the MEDICAL PATIENT
file (#690).", "", "", ""], ["81", "DBIA81", "File", "PATIENT FILE", "1991/02/05", "", "Retired", "Private", "2", "
The Health Summary "Adverse Reaction/Allergies"
Component refers to some fields marked with * for eventual removal:\n
^DPT( 2 PATIENT File
2.57 *Allergies/Disorders
2.55 *Generic Drug\n
^DIC(57, Allergy/Disorder File (#57) ^PSDRUG( Drug File (File #50)\n
When the new Allergies package is disseminated we will be converting to
accessing allergies from that package. Until that time we would like to
continue gathering this information from the Patient File.", "", "", ""], ["82", "DBIA82", "Routine", "KERNEL", "1991/05/15", "", "Retired", "Private", "", "
To facilitate selection and collection of multiple
items, a call is made to EN^XQORM with XQORM as a required variable in
addition to the variables supported from ^XQOR (see supported references).", "", "XQORM", ""], ["83", "DBIA83", "Routine", "SCHEDULING", "1991/07/09", "", "Retired", "Private", "", "
Lab uses suported call EN3^SDACS for adding stop codes.\n", "", "SDACS", ""], ["84", "DBIA84", "Routine", "SCHEDULING", "1991/07/09", "", "Retired", "Private", "", "
Pharmacy uses EN3^SDACS for adding stop codes.", "", "SDACS", ""], ["85", "DBIA85-A", "File", "RECORD TRACKING", "1991/07/09", "APPROVED", "Active", "Private", "195.4", "\n
1. Activation interface
2. Make an appointment
Checkin/unscheduled visit
3. Cancel an appointment
4. Changing clinic names\n
1. Use of the Record Tracking System Parameter file # 195.4
SD calls RT if the field 'MAS INTERFACE STATUS' is 'UP'
^DIC(195.4,1,"UP")=1^\n
2. When a clinic appointment is made if the appointment is 'today'
or if the Record Tracking System Parameter 'Batch requests' is
set to 'No' or if records are requested for an unscheduled visit.\n
A. An entry is made in the Requested Records file #190.1
^RTV(190.1,n)
by a call from RT^SDUTL to a tasked job QUE^RTQ
or RT^SDI\n
B. After the entry is added to the Requested Records file #190.1
an entry is made in Parent Record Request field
of the Patient subfield of the Hospital Location file #44
^SC(n,"S",,,,"RTR")=n^
by a return call from CREATE+11^RTQ2 to RTSET^SDUTL\n
3. When a clinic appointment is canceled:
If there is a Requested Records entry in file #190.1
the status is changed to 'canceled' by a call
RTV(190.1,n)=^^^^^x^
from RT+2^SDUTL to CANCEL^RTQ2.\n
4. When the name of a clinic is changed the corresponding names
of entries in the Pull List file #194.2 are changed by a trigger
on the .01 field of the Hospital Location file #44. Clinic
^SC(1,0)=DJones Medical Clinic^
^RTV(194.2,n)=Dr Jones Medical Clinic [04/01/91]^
Clinic names are changed in a compiled input template. To
insure the use of this trigger the following action is taken:
The Record Tracking package includes the .01 field of the
Hospital Location file #44 so that the SDB template is
re-compiled when the Record Tracking package is initialized.", "", "", ""], ["86", "DBIA86", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
Create Requests for Records and Pull lists from clinic
appointments:\n
Record Tracking queues a task which parses the scheduling global for Record
Tracking 'Borrowers' ie 'Clinics' which have appointments in a date range and
creates Requested Records and Pull list entries for patients with
appointments.\n
IF there is a clinic appointment: An entry is made in the Pull list file
#194.2 with a name derived from the clinic name
SC(1,0)=Dr Jones Clinic^
RTV(194.2,n)=Dr Jones Clinic [04/01/91]^\n
An entry is made in the Requested Records file #190.1 ^RTV(190.1,n)\n
After the entry is added to the Requested Records file #190.1 an entry is made
in Parent Record Request field of the Patient subfield of the Hospital
Location file #44, ^SC(n,"S",,,,"RTR")=n^, by a call from CREATE+11^RTQ2 to
RTSET^SDUTL", "", "SDUTL", ""], ["87", "DBIA87-A", "File", "REGISTRATION", "1991/07/10", "APPROVED", "Active", "Private", "41.1", "
SCHEDULED ADMISSION FILE: Loops through ARSV x-ref and
looks at
RESERVATION DATE/TIME field. (routine YSCEN)", "", "", ""], ["88", "DBIA88-A", "Other", "GRECC", "1991/08/06", "APPROVED", "Active", "Private", "", "
1. The 'DG' package for MAS v5.1 will be exporting the
following
Generic Code Sheet input templates:\n
a. DG AMS1 AMIS from file 2100
b. DG AMS1 AMIS 334 from file 2100
c. DG AMS1 AMIS 336 from file 2100
d. DG AMS1 AMIS 345 from file 2100", "", "", ""], ["89", "DBIA89", "File", "IFCAP", "1991/08/08", "APPROVED", "Active", "Controlled Subscription", "411", "
Read access to File 411, ADMIN. ACTIVITY SITE
PARAMETER, following fields:\n
field 15 HOSPITAL STREET ADDR.1
field 16 HOSPITAL STREET ADDR.2
field 17 HOSPITAL CITY
field 18 HOSPITAL STATE
field 19 HOSPITAL ZIP
field 19.2 HOSPITAL PHONE", "", "", ""], ["90", "DBIA90-A", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "52", "
Amended November 1, 1993. Amended August 30, 1994.
Amended October 28, 1997.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the Pharmacy Reengineering developers in the C development team mail
group at EMAIL GROUP DEV using Microsoft Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["91", "DBIA91-A", "File", "LAB SERVICE", "1991/09/11", "APPROVED", "Active", "Controlled Subscription", "60", "", "", "", ""], ["92", "DBIA92", "File", "REGISTRATION", "1991/09/11", "APPROVED", "Active", "Controlled Subscription", "45", "
Amended October 28, 1997. fields DGPT(D0,0) .01 and
DGPT(D0,70) 80 added for CIRN 11/24/98", "", "", ""], ["93", "DBIA93-A", "File", "SCHEDULING", "2005/02/17", "APPROVED", "Active", "Controlled Subscription", "44", "
This ICR allows direct global read and read with
fileman access to the Stop Code Number (#8), Name (#.01), and Type (#2)
fields. Name field direct read access is used to determine if a value exists
and the Type field direct read access is used to determine the Hospital
Location type before it can execute another task in TIUSRVP.\n
Revision History:
- 12/3/24: A previously missing Description was added to reflect the new
changes.", "", "", ""], ["94", "DBIA94", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "1991/09/23", "APPROVED", "Active", "Private", "", "
As a requirement for the AMIE C&P (phase III), Central
Office requested that we report lab and X-ray results in conjunction with the
examination. After speaking with Troy about such a venture and attempting to
procure an agreement to make calls to the Radiology package, it was decided
that it would be better for them to write a special routine for AMIE purposes.\n
I have initially set this up under my DVBC national name space and will rename
it (using Kernel tools) to RAUTL3 which is its true name. However, before
doing this I check to see if it already exists.\n
As the package cannot function without this and some sites may not have the
latest Radiology package up (v 4.0, I think) by the time it is sent out
nationally (probably 1/92), I have been advised by Troy to request an
agreement to export this and rename it. This would be required just for the
initial release.", "", "", ""], ["95", "DBIA95-A", "File", "LAB SERVICE", "1991/09/24", "APPROVED", "Active", "Private", "63", "
Request an agreement with the lab developers for usage
of the following:\n
Cross-references:\n
CH xref in ^LR
MI xref in ^LR", "", "", ""], ["96", "DBIA96", "Routine", "NURSING SERVICE", "1991/02/21", "", "Retired", "Private", "", "
(1)NURSING SERVICE Nursing
Workload/AMIS 1106 DIRECT CALL TO YOUR ROUTINE Direct call to routine
EN1^NURSAWL0 to print 'Nursing Workload/ AMIS 1106 Report'.\n
NUR*2.2*20 will insure that the routine is there, ECT*1.05*2 will set up the
proper global root before calling the routine.\n
(2)NURSING SERVICE Nursing Personnel Inquiry REFERENCING
FIELDS FROM YOUR FILE IMS will determine global root by using ^DIC(210,0,"GL")
and will then use a VA FileMan EN^DIQ call to display all fields in file 210
(Nurs Staff).\n
Patch ECT*1.05*1 sets up the proper global root.", "", "NURSAWL0", ""], ["97", "DBIA97-A", "File", "EVENT CAPTURE", "1991/08/26", "APPROVED", "Active", "Private", "730", "
The DSS developers have agreed that the IMS developers
may export file 730 (NATIONAL SERVICE) with data and field 730 (NATIONAL
SERVICE) in file 49 (SERVICE/SECTION) with no data.", "", "", ""], ["98", "DBIA98-A", "Other", "KERNEL", "1991/03/20", "APPROVED", "Active", "Private", "", "
Version 5.1 of the laboratory package has a temporary
agreement for the following:
1) To save system $Z variables in local variables for storage in our error
trap.\n
When Kernel release their error trapping system, Lab will convert to the
Kernel supported methodology.", "", "", ""], ["99", "DBIA99", "File", "EVENT CAPTURE", "1991/07/27", "APPROVED", "Active", "Private", "730", "
The agreement consists of the following:
1) Credentials Tracking package will include the field GENERAL PRIVILEGE
(#747) and associated data in the National Service fle (#730).\n
2) Credentials Tracking will export the National Service file (#730).
This export will only install the data dictionary for file 730 if the
dictionary does not exist on the system. If file 730 does exist, Credentials
Tracking will not overwrite the data dictionary.", "", "", ""], ["100", "DBIA100", "File", "KERNEL", "1991/09/25", "APPROVED", "Active", "Private", "200", "
The agreement consists of the following:\n
1) The Credentials Tracking module will incorperate fields in the NEW
PERSON file within the field number range of 747-747.999. Data node for these
fields will be in the QAR namespace (ex. QAR1, QAR17, etc). Sub-data
dictionary numbers will be within the 200.0747-200.074799999 range. The right
is reserved to use the QAR and AQAR prefix for any cross-reference indicies.\n
2) The Credentials Tracking module will export a "clean" partial data
dictionay for file 200. This partial will include only the 747 number spaced
fields and the .01 name field.
The partial was created in an environment that contained only the 747
numberspaced fields and a partial of the .01 name field. The .01 name field
contains only the basic field definition, "B" cross- reference (only), and the
input transform. All other fields and information were deleted.", "", "", ""], ["101", "DBIA101", "File", "PAID", "1991/08/26", "APPROVED", "Active", "Private", "453", "
The agreement consists of the following:
1) Credentials Tracking module will include fields in the 747-747.999
number range.\n
2) Credentials Tracking will export the APPLICANT file (#453) partial
data-dictionary. The partial will include only fields in the 747-747.999
number range, and those other fields in the APPLICANT file that Credentials
Tracking is dependant upon.", "", "", ""], ["102", "DBIA102-A", "File", "DENTAL", "2005/11/09", "", "Retired", "Private", "221", "
The following fields are accessed in a read-only
manner:\n
^DENT(221 DENTAL TREATMENT (AMIS) File
4.5 PATIENT CATEGORY
5 BED SECTION
6 SCREENING/COMPLETE EXAM
6.2 INTERDISCIPLINARY CONSULT
6.4 EVALUATION
6.6 PRE AUTH/2ND OPINION EXAM
6.8 SPOT CHECK DISCREPANCY #
6.7 SPOT CHECK EXAM
7 ADMIN PROCEDURE
7.1 COMPLETIONS/TERMINATIONS
8 X-RAYS EXTRAORAL #
10 X-RAYS INTRAORAL #
11 PROPHY NATURAL DENTITION
12 PROPHY DENTURE
14 NEOPLASM CONFIRMED MALIGNANT #
15 NEOPLASM REMOVED #
16 BIOPSY/SMEAR #
17 FRACTURE #
19 OTHER SIGNIF. SURG. (CTV)
21 SURFACES RESTORED #
22 ROOT CANAL THERAPY #
23 PERIODONTAL QUADS (SURGICAL) #
24 PERIO QUADS (ROOT PLANE) #
25 PATIENT ED. (CTV)
27 INDIVIDUAL CROWNS #
28 POST & CORES #
29 FIXED PARTIALS (ABUT) #
30 FIXED PARTIALS (PONT ONLY) #
31 REMOVABLE PARTIALS #
32 COMPLETE DENTURES #
33 PROSTHETIC REPAIR #
34 SPLINTS & SPEC. PROCS. (CTV)
35 EXTRACTIONS #
36 SURGICAL EXTRACTIONS #
37 OTHER SIGNIFICANT TREAT (CTV)
38 OPERATING ROOM
39 FACTOR (NOT USED)
61 DATE RELEASED\n
Eligible records will be determined by using the "E" cross
reference to determine matches with patients in the
Immunology Case Registry. Records which have a value in
field #61, DATE RELEASED, will be accessed.", "", "", ""], ["103", "SURGERY file (#130)", "File", "SURGERY", "1991/07/28", "APPROVED", "Active", "Controlled Subscription", "130", "
The DSS Extracts SURGERY EXTRACT file (#727.811)
contains a field, CASE NUMBER, which is a pointer to the SURGERY file (#130).
DSS Extracts has permission to execute direct global reads of the 'B' Cross
Reference on the SURGERY file (#130).\n
DSS uses the "ADT" and "AC" cross references on the DATE OF OPERATION field:
Global: ^SRF("ADT",DFN,DATE)
Global: ^SRF("AC",DATE,IEN)=DFN", "", "", "2013/10/24"], ["104", "DBIA104-A", "File", "REGISTRATION", "1991/10/04", "", "Retired", "Private", "2", "
#2 Patient file
.35 node", "", "", ""], ["105", "DBIA105", "Other", "RECORD TRACKING", "1991/10/04", "", "Retired", "Private", "", "
Record Tracking:\n
- ^RTV(190.1,"AD"\n
Record Tracking option: RT RPT-RETRIEVAL STATS\n
If the option is removed from the Record Tracking Menu then the following
entry and exit action needs to be added:
ENTRY ACTION: D OVERALL^RTPSET
EXIT ACTION: D KILL^RTPSET\n
The above references will be made from the QIP1RTP* routines which, while
belonging to the QIP namespace, will be maintained by the record tracking
developers. Coordination of release and patches will be through the QIP
custodial ISC.", "", "", ""], ["106", "DBIA106", "File", "PHARMACY DATA MANAGEMENT", "2005/06/20", "", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
Routine QIP3POLY reads the following fields: In file 50, DRUG
.01 - GENERIC NAME
2 - VA CLASSIFICATION
3 - DEA, SPECIAL HDLG", "", "", ""], ["107", "DBIA107-A", "File", "SURGERY", "2005/06/20", "", "Retired", "Private", "130", "
The following references will be made from the QIP3SR*
routines which, while belonging to the QIP namespace, will be maintained by
the surgery developers. Coordination of release and patches will be through
the QIP custodial ISC.", "", "", ""], ["108", "DBIA108-A", "File", "NURSING SERVICE", "1991/10/04", "", "Retired", "Private", "211.4", "
NURS LOCATION FILE #211.4\n
.01 Name\n
The above references will be made from the QIP4* routines which, while
belonging to the QIP namespace, will be maintained by the nursing developers.
Coordination of release and patches will be through the QIP custodial ISC.", "", "", ""], ["109", "DBIA109-A", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "62.05", "", "", "", ""], ["110", "DBIA110-A", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The following option will be placed on the QUIC menu
structure:
SDM - Make Appointment", "", "", ""], ["111", "DBIA111-A", "Routine", "REGISTRATION", "1991/05/14", "APPROVED", "Active", "Private", "", "", "", "DGAINP3", ""], ["112", "DBIA112", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
Display a patient's eligibility and disabilities the
same way MAS does on the routing sheet..\n
The subroutine DIS^SDROUT2 make several global references:\n
^DPT(DFN,.372,
^DG(391,
^DIC(31,", "", "SDROUT2", ""], ["113", "DBIA113-A", "File", "REGISTRATION", "2005/11/09", "", "Retired", "Private", "80.1", "", "", "", ""], ["114", "DBIA114", "File", "REGISTRATION", "1991/08/24", "", "Retired", "Private", "2", "
Checks 1st piece of the .35 node for death", "", "", ""], ["115", "DBIA115-A", "File", "RECORD TRACKING", "1991/08/24", "APPROVED", "Active", "Private", "195.4", "
Use of the Record Tracking System Parameter file #
195.4. RA calls RT if the field 'RADIOLOGY INTERFACE STATUS' is 'UP',
^DIC(195.4,1,"UP")=^1, and checks if the record tracking radiology application
is defined . $D(^DIC(195.4,1,"RAD"))", "", "", ""], ["116", "DBIA116", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1991/08/24", "APPROVED", "Active", "Private", "70", "\n
With Record Tracking implementaion, records may be created for
for all the entries in Radiology Patient file.\n
When using the Record Tracking (radiology application) the
routines RTSM1 and RTSM3 look at the Radiology Patient file #70
^RADPT(dfn,0) => ^RT(n,0)=dfn;DPT(^
to create entries in the Records file #190 for each radiology
patient when initializing records.", "", "", ""], ["117", "DBIA117", "File", "PHARMACY DATA MANAGEMENT", "2005/11/14", "", "Retired", "Controlled Subscription", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at REDACTED OI SDD
PHARM REENG DEV using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006. Amended August 30, 1994.", "", "", ""], ["118", "DBIA118-A", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2005/11/09", "APPROVED", "Active", "Controlled Subscription", "70", "
Amended October 28, 1997.", "", "", ""], ["119", "DBIA119", "File", "KERNEL", "1991/10/31", "APPROVED", "Active", "Private", "", "
Routine PRCFQ uses the following extrinsic function to
determine whether Taskman is runnig:\n
TM() ;extrinsic function--is taskman running?
N ZTH,ZTR S ZTH=$H,ZTR=$S(^%ZTSCH("RUN"))#2:^("RUN"),1:"")
Q ZTH-ZTR*86400+$P(ZTH,",",2)-$P(ZTR,",",2)<500\n
Till otherwise agreed, or release of Kernel 8", "", "", ""], ["120", "DBIA120-A", "File", "RECORD TRACKING", "1991/08/24", "APPROVED", "Active", "Private", "195.4", "\n
1. Use of the Record Tracking System Parameter file # 195.4:
DG calls RT if the field 'MAS INTERFACE STATUS' is 'UP'
^DIC(195.4,1,"UP")=1^", "", "", ""], ["121", "DBIA121", "File", "REGISTRATION", "1991/09/05", "APPROVED", "Active", "Private", "2", "
APSJD X-reference on field .351, DATE OF DEATH, of file
2, PATIENT not used for sorting or look up. The code is:
set: S XX=X,X="PSJADT" X ^%ZOSF("TEST") I S X=XX D END^PSJADT
kill: Q\n
The event driver messages are not displayed.\n
^DD(2,.351,1,6,0) = 2^APSJD^MUMPS ^DD(2,.351,1,6,1) = S XX=X,X="PSJADT" X
^%ZOSF("TEST") I S X=XX D END^PSJ ADT ^DD(2,.351,1,6,2) = Q
^DD(2,.351,1,6,"%D",0) = ^^2^2^2910806^ ^DD(2,.351,1,6,"%D",1,0) = Pharmacy
cross-reference for notification upon entry/deletion of date of
^DD(2,.351,1,6,"%D",2,0) = death information. ^DD(2,.351,1,6,"DT") = 2910806", "", "", ""], ["122", "DBIA122", "File", "KERNEL", "1991/10/06", "", "Retired", "Private", "200", "
Fields in the NEW PERSON File for OE/RR\n
100.11 PRIMARY OE/RR MENU 100.12 PRIMARY ORDER MENU 100.13 PRIMARY ORDER
DISPLAY FORMAT 100.14 PRIMARY WARD 100.15 PRIMARY PATIENT LIST 100.16 SELECT
PATIENT DEFAULT 100.17 PRIMARY CLINIC 100.18 DEFAULT CLINIC START DATE 100.19
DEFAUTL CLINIC STOP DATE 100.21 SUMMARY DEFAULT 100.22 PATIENT LIST ORDER
100.23 PATIENT LIST PROCESS 100.24 PRIMARY PROFILE MENU 100.25 PRIMARY
PROVIDER 100.26 PRIMARY SPECIALTY 100.27 NEW ORDERS DEFAULT\n", "", "", ""], ["123", "DBIA123", "File", "QUALITY IMPROVEMENT CHECKLIST", "1991/10/06", "", "Retired", "Private", "736", "
Following fields point to file 736 (QUIC SORT FILE)\n
field 2 (SITE NATIONAL) in file 59 (PHARMACY SITE)\n
field 12 (SITE) in file 1900.1 (CLOZARIL REPORTS)\n
In addition, since the extended clozaril patch may go to test sites before the
QUIC package does, and since the test sites will almost certainly be
different, file 736 will be exported (with data) with the extended clozaril
patch.\n
We understand that there is at least one field in file 736 that is not to be
sent to the sites, but only to the national data base and we agree not to send
that field to the sites.", "", "", ""], ["124", "DBIA124-A", "Routine", "OUTPATIENT PHARMACY", "1991/11/06", "APPROVED", "Active", "Private", "", "\n
Routine PSOCPVW is called by Integrated Billing to display information
from the Prescription file (52) to provide a full profile of the
prescription that caused the Co-Pay Charges.\n
Input Variable: X
$P1: RX Entry Number. The pointer to the Prescription file.\n
$P2: Refill. The second piece is delimited by a colon is optional, if
defined is expected to be the entry number of the refill multiple that
caused the charges if the charges were created by a refill.\n
Output Writes pertinent data from the prescription file for the requested
entry in captioned format.", "", "PSOCPVW", ""], ["125", "DBIA125-A", "Routine", "INTEGRATED BILLING", "1991/11/06", "APPROVED", "Active", "Private", "", "
This private agreement between PSO and IB will allow
for PSO to notify IB when an Outpatient Medication Co-payment bill needs to be
created, updated, or cancelled. It will also allow PSO to cancel or update a
potential charge. There are also entry points for PSO to verify that a patient
is subject to Pharmacy Co-payment and allow PSO to check the status of a
Co-payment charge.", "", "IBARX", ""], ["126", "DBIA126", "Routine", "INTEGRATED BILLING", "1991/11/06", "APPROVED", "Active", "Private", "", "", "", "IBOLK", ""], ["127", "DBIA127-A", "Routine", "ACCOUNTS RECEIVABLE", "1991/11/06", "APPROVED", "Active", "Private", "", "\n
PRCASER This routine is used for setting up or establishing a new charge
(bill) for a debtor. When calling this routine, a new charge (pharmacy
Co-Pay, etc, should be added to the patients account.\n
Input Variable: X
$P1: Site. This is the site number the charge is being created by. For
example: 503, 516, etc. This is the station number field from the Institution
file (4).\n
$P2: Service. This is the service that is creating the bill. This is the
pointer to the Service/Section file (49).\n
$P3: Category Number. This is the AR Category that the charge should fall
under. This is the pter to the AR Category file (430.2).\n
$P4: Debtor. This is the debtor that the charge should fall under. This is
a variable pointer to the following files: Vendor, Person, Insurance,
Institution. For Pharmacy Co-Pay the debtor should be the patient in the
format of "36;DPT(" whe re 36 is the internal number of the patient in the
patient file.\n
$P5: Fiscal Year. Fiscal Year charge should be charged to.\n
$P6: Amount. Must be zero or greater and less than 9999999.99.\n
$P7: User. The person who created the charge. Pointer to the User file (3).\n
$P8: Date charge generated. This is the internal VA FileMan date the charge
was issued.\n\n
Output Variable: Y (if no error is encountered)
P1: Internal Bill Number. This is the internal file number from the Accounts
Receivable file (430).\n
$P2: Charge ID. This is the .01 field from the Accounts Receivable file
(430) and will be 10 characters in length.\n
$P3: Transaction Number. Since an "OPEN" bill may already exist and can be
used, it may be necessary to add this charge to an already existing bill as a
transaction, then this would be the pointer value to the AR Transaction file
(433). Howev er, if a new bill is set up for the current charges then this
piece equals zero.\n\n
Variable: Y (if error is encountered)
$P1: Error Indicator. -1
.
$P2: Error Code. This is the error code from the IB Action Error file.\n
$P3: Additional Text. If additional text is required to describe the error
it is in the third piece.", "", "PRCASER", ""], ["128", "DBIA128-A", "File", "KERNEL", "1991/11/20", "APPROVED", "Active", "Private", "200", "
New Bill and Edit Bill options have been modified to
prompt the user "Edit Debtor Address" after he/she has entered/edited the
bill. This prompt as well as the Edit AR Debtor Address option allow edits to
the NEW PERSON and INSTITUTION file.\n
The fields edited include:\n
for NEW PERSON file ^VA(200,
1) .111 - Street Address 1
2) .112 - Street Address 2
3) .113 - Street Address 3
4) .114 - City
5) .115 - State
6) .116 - Zip Code
7) .131 - Phone\n
The edits would also be transposed in the PERSON file (^DIC(16)).\n
Please keep in mind that "all users" with access to the Billing menu will be
able to edit the debtor address fields (option 2).", "", "", ""], ["129", "DBIA129", "Routine", "PHARMACY DATA MANAGEMENT", "1991/11/21", "APPROVED", "Active", "Private", "", "
Call to STAT^PSOEXDT:\n
The routine expects the 0 node of the prescription in RX0, the 2 node of
the prescription in RX2 and returns the printable form of the prescription
status in ST.\n
The call will be abandonded when Health Summary provides the clinical
information.", "", "PSOEXDT", ""], ["130", "DBIA130-A", "File", "REGISTRATION", "1991/12/04", "APPROVED", "Active", "Private", "2", "
Read only access to the following Files, Fields, &
X-References:\n
FILE : Patient (2)
FIELDS : Receiving A&A Benefits (.36205)
Eligibility Status Date (.3612)
Agerncy/Allied Country (.309)
Receiving Housebound Benefits (.36215)
Rated Disabilities (.3721) *stipulation*
*this is being requested by other packages and may be incorporated
into VADPT at which time we will ask packages to use the utility", "", "", ""], ["131", "DBIA131-A", "File", "SCHEDULING", "1991/12/04", "APPROVED", "Active", "Private", "2", "
'Status of the clinic appointment' field in ^DPT('S'
node will be used to determine appointment status. If the status of the
appointment is active and not an inpatient visit, it will be counted as an
outpatient visit for social work totals.", "", "", ""], ["132", "DBIA132-A", "Other", "REGISTRATION", "1991/12/05", "APPROVED", "Active", "Private", "", "
DGPM MOVEMENT EVENT DRIVER\n
For movements other than 'death': The Inpatient inits send out the protocol
'PSJ OR PAT ADT' which is 'hooked' to the MAS protocol 'DGPM MOVEMENT EVENTS'.
'PSJ OR PAT ADT' uses the PSJADT routines to take the appropriate actions.", "", "", ""], ["133", "DBIA133", "Other", "REGISTRATION", "1991/12/09", "", "Retired", "Private", "", "\n
The data for fields *Allergy/Disorders (57) and *Generic Drug (55) of the
Patient (2) file will be converted by the Allergy Tracking System V2.2 and
moved into the Patient Allergies (120.8) file. The data in the the two fields
will be deleted after it is converted. The two DD's for the two fields, 55
and 57, will be deleted also.\n
The Allergy Tracking System is using +$G(^DG(43,1,"VERSION")) to check for
the version number of MAS currently installed at the site. If this value is
less than 5, the INIT process will abort.\n
The Allergy Tracking System is hanging the GMRA DGPM MARK CHART protocol off
the DGPM MOVEMENT EVENTS protocol. The code that is executed from the GMRA
DGPM MARK CHART protocol sets up a TaskManager job if appropriate. The input
variables expected by the GMRA DGPM MARK CHART protocol are:
DFN = IFN of patient in Patient file.
DGPMP = Zeroth node in Patient Movements file prior to whatever MAS
action has taken place.
DGPMA = Zeroth node in Patient Movements file after whatever MAS action
has taken place.", "", "", ""], ["134", "DBIA134", "Other", "DIETETICS", "1991/12/09", "", "Retired", "Private", "", "\n
The data for the Food Allergies (.1) field of the Dietetics Patient (115)
file will be converted by the Allergy Tracking System V2.2 and moved into the
Patient Allergies (120.8) file. The data in the the field will be deleted
after it is converted. The DD's for field .1 will be deleted also.", "", "", ""], ["135", "DBIA135", "File", "1", "1991/12/09", "", "Retired", "Private", "", "\n
The Allergy Tracking System is using +$G(^DD("VERSION")) to check for the
version number of the VA FileManager currently installed at the site. If this
value is less than 18, the INIT process will abort.", "", "", ""], ["136", "DBIA136", "Routine", "HEALTH SUMMARY", "2004/01/27", "APPROVED", "Active", "Private", "", "", "", "GMTSLROE", ""], ["137", "DBIA137", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1991/12/09", "", "Retired", "Private", "", "
The ORVOM utility from Order Entry/Results
Reporting(OE/RR) V2.15 is used to create the GMRAO* routines to export the
GMRA DGPM MARK CHART protocol used by the Allergy Tracking System V2.2. These
GMRAO* routines will not be included in the integrity checker routine GMRANTEG
created by Kernel. These routines will run correctly under any version of
OE/RR, including the verified V1.96.", "", "ORVOM", ""], ["138", "DBIA138", "Routine", "OUTPATIENT PHARMACY", "1991/12/09", "", "Retired", "Private", "", "", "", "PSOHCSUM", ""], ["139", "DBIA139", "Routine", "INPATIENT MEDICATIONS", "1991/12/09", "", "Retired", "Private", "", "", "", "PSJEEU0", ""], ["140", "DBIA140-A", "Routine", "IFCAP", "1992/01/07", "", "Retired", "Private", "", "
1. EN3^PRCSUT - Checks for Fund Control Point user
authorization access.", "", "PRCSUT", ""], ["141", "DBIA141", "Routine", "IFCAP", "1992/01/07", "APPROVED", "Active", "Private", "", "
^PRCSDIC - Routine to perform lookup into File 410
(Control Point Activity).
Variables: DIC
DIC(0)
DIC("A")", "", "PRCSDIC", ""], ["142", "DBIA142-A", "File", "HINQ", "1992/01/23", "APPROVED", "Active", "Controlled Subscription", "31", "", "", "", ""], ["143", "DBIA143", "Other", "VETERANS ADMINISTRATION", "1992/02/05", "", "Retired", "Private", "", "
Patch DVB*4.0*71 is a partial decommission of Hospital
Inquiry (HINQ), as it disables the ability to submit HINQ requests in support
of WebHINQ. As a result, this ICR is Retired.\n
HINQ v4 inits will transfer data from field 14.9 in File 3 to field 14.9 in
File 200.", "", "", ""], ["144", "DBIA144", "File", "KERNEL", "1992/02/18", "APPROVED", "Active", "Private", "19.1", "\n
A patch (pre-release of Inpatient Meds V4) containing new keys will add the
new keys to File #19.1, field .01 name. Then based on the present version, it
will preload key holders for the new keys into the 'Holder' multiple (19.12)\n
For Inpatient Medications V4 only.", "", "", ""], ["145", "DBIA145-A", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/03/05", "APPROVED", "Active", "Private", "", "", "", "OR2", ""], ["146", "DBIA146", "File", "REGISTRATION", "1992/03/11", "APPROVED", "Active", "Private", "2", "
This request is for permission to access some
information from the DPT global directly. The data needed is the 'Other
Income' field which is not returned from VADPT. This data is used by social
work service with other monetary benefits information as an income screen for
newly admitted patients. The data is accessed from piece 9 of the .362 DPT
node.
When the MB entry point of VADPT is restructed and this information
included, it's agreed a patch will be issued to replace the direct access a
VADPT entry point call.\n
DURATION: Till otherwise agreed, and VADPT contains "other income".", "", "", ""], ["147", "DBIA147-A", "Other", "CLINICAL PROCEDURES", "1992/03/11", "APPROVED", "Active", "Private", "", "
1. The REQUEST/CONSULTATION file, 123, has a variable
pointer field called "Results" which points to the following fields.\n
691 Echo
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
691.1 Cardiac Catheterization
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
691.5 Electrocardiogram (EKG/ECG)
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
691.6 Holter
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
691.7 Exercise Tolerance Test
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
691.8 Electrophysiology (EP)
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
694 Hematology
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
698 Generator Implant
698V1 V Lead Implant
698.2 A Lead Implant
698.3 Pacemaker Surveillance
699 Endoscopy/Consult
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
700 Pulmonary Function Tests
Field 1506 RELEASE CODE
Field 1511 MARK FOR DELETION
701 Rheumatology", "", "", ""], ["148", "DBIA148", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/03/12", "APPROVED", "Active", "Controlled Subscription", "", "
Health Summary calls PATIENT^ORU1", "", "ORU1", ""], ["149", "DBIA149-A", "File", "NATIONAL DRUG FILE", "1992/03/25", "", "Retired", "Private", "50.416", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
The Adverse Reaction Tracking (ART) package will point to the Drug Ingredient
(50.416) file. Also, ART can do lookups on this file using the 'P'
cross-reference. ART will do a direct global read on the NAME field (.01).", "", "", ""], ["150", "PSNNGR", "Routine", "NATIONAL DRUG FILE", "1992/03/26", "APPROVED", "Active", "Private", "", "
The Adverse Reaction Tracking (ART) package can use the
PSONGR utility from the Outpatient Pharmacy package. This utility will return
all of the primary ingredients to an entry in the Drug (50) file.", "", "PSNNGR", ""], ["151", "PSNNGR", "Routine", "NATIONAL DRUG FILE", "1992/03/26", "APPROVED", "Active", "Private", "", "
The Adverse Reaction Tracking (ART) package can use the
PSNNGR utility from the National Drug File package. This utility will return
all of the primary ingredients to an entry in the National Drug (50.6) file.
The ART package will use the DISPDRG entry point, if it exists, otherwise ART
will call the routine from the top (i.e., D ^PSNNGR).", "", "PSNNGR", ""], ["152", "DBIA152", "Routine", "REGISTRATION", "1992/04/01", "", "Retired", "Private", "", "
A call to WARD^DGPMUTL, to find the ward at discharge,
in the routine QIP1DIS.", "", "DGPMUTL", ""], ["153", "DBIA153-A", "File", "QUALITY ASSURANCE INTEGRATION", "1992/04/20", "APPROVED", "Active", "Private", "741", "
Read access to find patients who have had a QA
occurrence which was refered to peer review associated with a particular
admission.\n
File 741 QA OCCURRENCE SCREEN
The B cross reference
Field 1 DATE
REVIEWER (MULTIPLE)
Field .01 REVIEW LEVEL
Field 11 STATUS", "", "", ""], ["154", "DBIA154", "Routine", "REGISTRATION", "1992/04/27", "APPROVED", "Active", "Private", "", "
1. CallS EN^DGYEPRP and AUTO^DGYEPRP entry points.The
EN entry point is used by a option to print an external peer review report and
AUTO entry point is used to by an option to autoque the report.
There are no input variables to the entry points.\n", "", "DGYEPRP", ""], ["155", "DBIA155", "File", "LAB SERVICE", "1992/04/29", "APPROVED", "Active", "Private", "60", "
A large number of users have requested that Health
Summary's Chemistry and Hematology component appear in a manner analogous to
the interim report. Health Summary has modified the code to look at:\n
1.) The PRINT ORDER field in file 60, and use it or the record number
divided by 1000000, to determine the print sequence.\n
2.) The PRINT CODE FIELD (#53) of file 60 to format lab results", "", "", ""], ["156", "DBIA156", "Other", "REGISTRATION", "1992/05/21", "APPROVED", "Active", "Private", "", "
Clinical Warnings hooks from within MAS are needed to
call PN at an appropriate time in the patient lookup process to display any
warnings that may exist. That code has been developed, but not released yet
by the MAS pkg. In order to beta test PN along with OE/RR and for internal
Verification, two routines,DGSEC and DPTLK, have been modified in the GMRP
namespace and released to the test sites/ISCs. In the post-init, DGSEC and
DPTLK will be renamed in lowercase, and then the GMRP hooks installed.
Documentation for the editing of the Post-Selection Action field of file #2
will also be provided.\n
AMENDMENT TO DBIA #156 DATED 10/7/93:\n
This agreement was originally written to allow Progress Notes to export the
routines DGSEC and DPTLK to its Beta test sites and to its verifying ISC; the
MAS developers had added the hooks required to call the Clinical Warnings
portion of Progress Notes at the appropriate time in a patient look-up, but
this code was not in the field yet. It has since been verified and released.
Version 5.2 of MAS and Progress Notes no longer exports them.\n
This agreement is updated to simply provide maintenance of those hooks in the
Registration pkg until otherwise agreed; Progress Notes will maintain the
entry point ENPAT^GMRPNCW called from ^DGSEC.\n", "", "", ""], ["157", "DBIA157", "Other", "TEXT INTEGRATION UTILITIES", "1992/05/21", "APPROVED", "Active", "Private", "", "
As a standing integration agreement, the Progress Notes
pkg (GMRP) will support the entry point ENPAT^GMRPNCW for the use of MAS in
the Patient Warnings application. A line was inserted after Q^DGSEC to invoke
this entry point if the rtn GMRPNCW is present in the system. Lines DGSEC+2
and CHKDFN+2^DPTLK were also modified somewhat to accomodate this call, as
well as the Post-Selection Action of the Patient file (#2). The function of
ENPAT^GMRPNCW sets flag (GMRPEN) which turns on Patient Warnings (CWAD) which
lists directly under the patient's name on a ^DIC lookup the most recent
Crisis Notes, Clinical Warning note, Allergy information, and/or Directive
note in the form "C: date time"; a secondary menu option exists to allow users
to view the text of these notes at their convenience. No variables are to be
returned to MAS, and the only variable required to be received is the patient
DFN in Y.", "", "", ""], ["158", "DBIA158", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1992/06/02", "", "Retired", "Private", "70", "\n
The following fields are used from the Radiology package for determining
radiology procedures that use contrast media that were associated with
complications:\n
To determine procedures performed for a date range:
"AR" cross-reference on the EXAM DATE field - 70.02,.01\n
To determine procedure performed and whether or not contrast media was used,
and if so, was there a complication:\n
Field Global Reference Name
------- --------------------- -------
2 70.03,2 RADIOLOGY PROCEDURE
3 70.03,3 EXAM STATUS
10 70.03,10 CONTRAST MEDIA USED
16 70.03,16 COMPLICATION
9 71,9 CPT
.01 71.03,.01 AMIS CODE
.01 78.1,.01 COMPLICATION\n
The above references will be made from the QIP1Q46 routine which, while
belonging to the QIP namespace, will be maintained by the radiology
developers. Coordination of release and patches will be through the QIP
custodial ISC.", "", "", ""], ["159", "DBIA159-A", "File", "OCCURRENCE SCREEN", "1992/06/02", "", "Retired", "Private", "741", "
The following references will be made from the QIP4QAO*
routines which, while belonging to the QIP namespace, will be maintained by
the occurrence screen developers. Coordination of release and patches will be
through the QIP custodial ISC.\n
#741 QA OCCURRENCE SCREEN file
.01 Date
4 Ward/Clinic
11 Status
10 Reviewer (multiple)
.01 Review Level
4 Findings", "", "", ""], ["160", "DBIA160-A", "File", "REGISTRATION", "1992/06/08", "APPROVED", "Active", "Private", "2", "
Pulling over the following MAS data:\n
PATIENT (#2) file:\n
^DPT(D0,.21) (#.211) K-NAME OF PRIMARY NOK Direct Global Read
(#.212) K-RELATIONSHIP TO PATIENT Direct Global Read
(#.218) K-ZIP CODE Direct Global Read
(#.219) K-PHONE NUMBER Direct Global Read
(#.2125) K-ADDRESS SAME AS PATIENT'S? Direct Global Read\n
^DPT(D0,.211) (#.2191) K2-NAME OF SECONDARY NOK Direct Global Read
(#.2192) K2-RELATIONSHIP TO PATIENT Direct Global Read
(#.2198) K2-ZIP CODE Direct Global Read
(#.2199) K2-PHONE NUMBER Direct Global Read
(#.21925) K2-ADDRESS SAME AS PATIENT'S? Direct Global Read\n
^DPT(D0,.34) (#.341) D-NAME OF DESIGNEE Direct Global Read
(#.342) D-RELATIONSHIP TO PATIENT Direct Global Read
(#.348) D-ZIP CODE Direct Global Read
(#.349) D-PHONE NUMBER Direct Global Read
(#.3405) D-DESIGNEE SAME AS NOK? Direct Global Read\n
^DPT(D0,.321) (#.32102) AGENT ORANGE EXPOS. INDICATED? Read w/FileMan
(#.32103) RADIATION EXPOSURE INDICATED? Read w/FileMan\n
^DPT(D0,.322) (#.32201) PERSIAN GULF SERVICE? Read w/FileMan", "", "", ""], ["161", "DBIA161", "Other", "MENTAL HEALTH", "1992/06/08", "APPROVED", "Active", "Private", "", "
1.) A conversion rtn will copy the data found in
^YSP(606) into ^GMR(121) in the proper format. If pointers to file #16 still
exist, they will be re-pointed to file #200.
If version 5 is present, the codes for signature will also be converted.
NO data will be automatically deleted by this process!!\n
2.) Documentation for the archive, purge the deletion, thru Fileman, of Files
#606 & #606.5 will be provided. Also documentation for replacing the YSPN*
options with GMRPN* options wherever they occur, to assure continued user
access to the data. All YSPN*, GMRPN*, and YSMOVP (move Crisis Note to PN)
options will be disabled for the duration of the conversion; when finished,
the GMRPN* and YSMOVP options will be re-enabled and the YSPN* options will
remain disabled with a message referencing the GMRPN options. Documentation
will also be provided for deletion, at the sites disgression, of the old
Mental Health options that will no longer be needed.\n
3.) When the conversion is completed, two Mental Health rtns will be updated
to allow uninterrupted user access to the data: YSPP8 will be updated to
check ^GMR(121) for the date of the most recent note on a given patient, and
YSMV1 will be updated to transfer moving Mental Health Crisis Notes and
Messages to the ^GMR(121) global from the ^YSP(606) global. These rtns will
be exported as GMRPYSP8 and GMRPYSMV respectively, and renamed in the YS
namespace\n
4.) Pointer to file #627.5, DSM-III-R Code.in field #30, DXLS, to ensure
compatibility of this field in file 606.\n
5.) An optional tool to be run before the conversion, is a utility that will
allow a site to edit the titles in the MH file (#606) before running the
conversion. It has two entry points, one to generate a FileMan listing of all
currently used MH titles and the other to edit the titles not desired in the
new file.", "", "", ""], ["162", "DBIA162", "File", "LAB SERVICE", "1992/06/08", "APPROVED", "Active", "Private", "63", "
Accessing the ^LR global as follows:\n
1) Searching the ^LR - cross references: "ASP","ACY","AEM","AAU"\n
2) Accessing the Topography and Morphology multiples:\n
^LR(D0,"SP",D1,0) - (0;1)
"SP",D1,2,D2,0)) - (0;1)
"SP",D1,2,D2,2,D3,0) - (0;1)\n
3) The same nodes for ^LR(D0,"CY") AND ^LR(D0,"EM")\n
4) Also the Autopsy nodes:\n
^LR(D0,"AU") - ("AU";1)
"AU",D1,0) - (0;1)
"AU",D1,2,D2,0) - (0;1)\n
Accessing malignancies, AND the date of the test. This information is
temporarily stored in the Oncology Patient file. The date of the test
possibly being the date of diagnosis.\n
In addition I should note that if the Casefinding Lab Report is printed all
these nodes are accessed for the report data for each patient that has been
previously "found" in a search.", "", "", ""], ["163", "DBIA163-A", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1992/06/08", "APPROVED", "Active", "Private", "78.3", "
For Automatic Casefinding Radiology: Oncology looking
at:\n
^RA(78.3 for a defined diagnostic code containing the word Malignancy...\n
Check the ^RADPT("AR") cross-reference for date.\n
Look at; ^RADPT(D0,"DT",D1,"P",D2,0) NODES for procedures which have the
diagnostic code found above in ^RA(78.3 - we capture those patients and the
date of the "suspicious procedures"", "", "", ""], ["164", "DBIA164", "Routine", "HEALTH SUMMARY", "1992/06/04", "APPROVED", "Active", "Controlled Subscription", "", "
In order to facilitate displaying Allergy alerts and
data, a call is made to Health Summary to use components there for all the
alerts -- Allergies, Crisis notes, Clinical Warning notes, and Advance
Directive notes.\n
In rtn GMRPNCW, GMTSPRM is set to the appropriate abbreviation, i.e. CN=Crisis
Notes, CW=Clinical Warnings and Advance Directives, and ADR=Allergies;
GMTSTITL is set to an appropriate heading for the HS report, depending on the
value of GMTSPRM. A call is then made to D ENCWA^GMTS to print the report of
alerts selected to view by the user.", "", "GMTS", ""], ["165", "DBIA165-A", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/15", "APPROVED", "Active", "Private", "", "", "", "OR2", ""], ["166", "DBIA166", "Other", "HEALTH SUMMARY", "1992/06/10", "APPROVED", "Active", "Private", "", "
Four components of the Health Summary package use data
from the Progress Notes package -- Progress Notes, Brief Progress Notes,
Crisis Notes and Clinical Warnings display components. There are structural
changes to the Progress Notes global in the new version, they are reflected in
changes to three Health Summary routines that access this data. Request
permission to send these routines out with the tape containing the new global
structure and routines for Progress Notes; they will be saved in the GMRP
namespace, and in the post-init routine, using the code provided in the Kernel
%ZOSF nodes, they will be saved at the site under the given Health Summary
names. The routines are GMTSPN, GMTSPNE, GMTSCW. This agreement is for
current release only. This release only.", "", "", ""], ["167", "DBIA167", "File", "KERNEL", "1992/06/15", "APPROVED", "Active", "Private", "19", "\n\n\n
1. Agreement to point to the Option File from the Request Services File
(123.5). This will be used to establish security for service updating
based on the option entered. Two special options are distributed with
the Consult/Request Package which are specific to the Packages
users for Pharmacy and Medicine. The GMRC initialization process sets
up the option/service relationships for IRM in the Request Services
File (123.5).
2. Agreement to use the XQY and XQY0 variables to determine which option
the user used to get to the "Select Action: " logic for a given
service.\n\n", "", "", ""], ["168", "DBIA168", "File", "1", "1992/06/16", "", "Retired", "Private", "6", "
DSS extracts information from a number of DHCP files.
In many of the extracts, provider information is one of the data elements.
Because this information is being shipped out of DHCP, we opted to send
pointer values rather than names. Since most packages currently point to file
6 and will ultimately point to 200 and since we don't want to try to
coordinate releases with all packages, we have chosen to send data in the form
of pointer-file. We are looking at the second "P" piece of the second "^"
piece of the zero node of the DD for the field in question.\n
Till supported call is available.", "", "", ""], ["169", "DBIA169-A", "Routine", "KERNEL", "1992/06/17", "", "Retired", "Private", "", "
The Consult/Request Tracking package populates the
Protocol File (101) with protocol items representing responses to prompts.
These responses are selectable via calls to the Menu Utility, XQORM, routines.
For example, "Select Action: ", "Place of Consultation: ", and "Urgency: "
prompts all use the XQORM routines to handle the users response. Variable,
XQORM("NO^^"), has been added for those responses that it is inappropriate to
"^^" jump.\n
Variables set to call XQORM\n
XQORM=variable pointer to Protocol File (101) entry. The Protocol File
entries specified are all Protocol Menu Type entries.(e.g., GMRCPLACEM -
INPATIENT is the Protocol Name of a distributed Protocol Menu used at "Place
of Consultation: " prompts.)\n
XQORM("NO^^")="" When defined, this variable tells XQORM not to allow "^^"
jumping at the prompt.\n
XQORM(0)=This controls the display and prompting of the menu. XQORM(0) may
contain a number, and/or letters A,D, and F. If there is a number, it must
always be at the beginning of the string. The parameters do the following:
#: maximum number of selections allowed. If there is no number, as many
selections as menu items are allowed.\n
A: The user will be prompted to make a selection.\n
D: The menu will be displayed.\n
F: Selection will NOT be saved in ^DISV.\n
For example, XQORM(0)="2A" will allow the user to make a maximum of two
selections. The menu will not be displayed (unless a ? is typed), and the
selections will be saved in ^DISV.\n
XQORM("A")=Text here will be used as the select prompt.\n
XQORM("B")=Text here will be used as the default menu selection.\n
XQORM("?")=MUMPS code that replaces the standard help.\n
XQORM("S")=(Not used by Consult/Request Tracking) MUMPS code that will
screen the items on the menu.", "", "XQORM", ""], ["170", "DBIA170", "File", "KERNEL", "1992/06/17", "APPROVED", "Active", "Private", "200", "
Agreement is made to allow the AMIE package to make
references to ^VA(200,DA(1),2,DA) directly. Generally lookup into ^VA(200 is
blessed. Any changes to security/access information is NOT blessed. Such
items of concern are: NAME, FILEMANAGER ACCESS, ACCESS CODES, VERIFY CODES,
PRIMARY & SECONDARY MENUS, SECURITY KEYS, and FILE ACCESS list.", "", "", ""], ["171", "DBIA171", "File", "1", "1992/06/17", "APPROVED", "Active", "Private", "", "
1.) The SURGERY SITE PARAMETERS file contains a
multiple titled REQUIRED FIELDS FOR SCHEDULING which containg fields that must
be entered prior to allowing a surgical case to be scheduled. This field
points to the global ^DD(130, allowing selection of filed names.\n
^DD(133.028,.01,0) = REQUIRED FIELDS FOR SCHEDULING^P130'^DD(130,^0;1^Q\n
2.) The same concept is used in the RISK MODEL LAB TEST file excep we're
pointing to the DDs for one of the lab files or sub-files.\n
^DD(139.21,.01,0) = LABORATORY DATA NAME^M*P63'X^DD(63.04,^0;1^S
DIC("S")="I Y>1" D ^DIC K DIC S DIC=DIE,X=+Y K:Y<0 X", "", "", ""], ["172", "DBIA172-A", "Routine", "DSS - DECISION SUPPORT SYSTEM EXTRACTS", "1992/06/17", "APPROVED", "Active", "Private", "", "
DSS Extracts needs data from the Inpatient Medications
package which cannot be extracted from any file. The Inpatient Medications
team has agreed to modify two routines (PSGPLF and PSGAMSA) to call, after
executing %ZOSF("TEST"), routine ECXUD1 to place data into a DSS file for
future extract by DSS.\n
The requested data is placed in the ECUD variable, which the ECXUD1 routine
uses to store the data in the UNIT DOSE EXTACTS file (#720.904).", "", "ECXUD1", ""], ["173", "DBIA173", "Other", "REGISTRATION", "1992/06/17", "APPROVED", "Active", "Private", "", "\n
The MAS package will carry along the HINQ mini inits when it installs
MAS v5.2. The HINQ mini inits (DVBY*) are a collection of routines that will
install a new edit template field into the HINQ edit template (DVBHINQ UPDATE)
which is part of the patient file. The entry point to call is ^DVBYCHK .
This routine will check to ensure the proper version of the HINQ package is
installed (V4.0). If at least 4.0 is not installed the init will not be run.
Installation notes will be provided to the MAS developers for inclusion into
the MAS release notes.\n", "", "", ""], ["174", "DBIA174", "File", "REGISTRATION", "1992/06/18", "APPROVED", "Active", "Controlled Subscription", "2", "
Direct global access to patient file, Field
.3721--Rated Disabilities (VA).", "", "", ""], ["175", "DBIA175", "Other", "REGISTRATION", "1992/06/18", "APPROVED", "Active", "Private", "", "
PDX routines will be exported with MAS 5.2.", "", "", ""], ["176", "DBIA176", "File", "REGISTRATION", "1992/06/18", "APPROVED", "Active", "Private", "", "
PDX uses direct access to ^DG global.", "", "", ""], ["177", "DBIA177", "Other", "KERNEL", "1992/06/18", "APPROVED", "Active", "Private", "", "
Progress Notes has permission to place the XUSESIG
option on one of its menus during export.", "", "", ""], ["178", "DBIA178", "Other", "KERNEL", "1992/06/18", "APPROVED", "Active", "Private", "", "
OR/RR has permission to place the XUSESIG option on one
of its menus during export.", "", "", ""], ["179", "DBIA179", "Routine", "SCHEDULING", "1992/06/18", "", "Retired", "Private", "", "
Radiology uses supported call EN3^SDACS for adding stop
codes.\n", "", "SDACS", ""], ["180", "DBIA180", "Routine", "1", "1992/06/18", "APPROVED", "Active", "Private", "", "
Surgery uses the entry point DI^DIU as follows:
Prior to entry, the following input variables must be supplied:
DI = file number
N = 0
X = null (or you can set it to any combination of "WC.01" where W" will
screen out word-processing fields, "C" will screen out computed fields, and
".01" will screen out the .01 field at both top and subfile levels.)\n
At the end, all variables set by Surgery will be killed, and in addition,
%,C,DA,DDH,DI,DIC,DISYS,I,J and Y will be killed.\n
After calling this routine, varible N will tell how many levels down you
went into subfiles (0 is top level, 1 is 1 level down, etc.). The I array
will tell the subscript for each multiple level at which the data is located
(ex., I(1) for first level down, I(2) for second). The J array will tell the
subfile number at each multiple level (ex.,J(1) for first level down, J(2) for
second).", "", "DIU", ""], ["181", "DBIA181-A", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/19", "APPROVED", "Active", "Private", "", "", "", "ORUHDR", ""], ["182", "DBIA182", "Routine", "1", "1992/07/14", "APPROVED", "Active", "Private", "", "
DGPTFMO1 AT LINE 17 ISSUES A CALL TO N^DIP1.\n
This is currently being renegotiated to use a supported reference that will be
available in version 21 of Fileman. V21 will still have the entry point
N^DIP1, but it is recommended that the new supported reference be used when
available.", "", "DIP1", ""], ["183", "DBIA183", "Routine", "OUTPATIENT PHARMACY", "1992/07/16", "", "Retired", "Controlled Subscription", "", "
Health Summary will use the entry point DFN^PSOSD1,
which can be called with DFN and PSTYPE=1, to print the Action Profile. NOTE:
This DBIA has been replaced by DBIA #1281.", "", "PSOSD1", ""], ["184", "DBIA184", "Routine", "OUTPATIENT PHARMACY", "1992/07/16", "", "Retired", "Private", "", "
OE/RR will use the entry point DFN^PSOSD1, which can be
called with DFN and PSTYPE=1, to print the Action Profile. NOTE: This DBIA
has been replaced by DBIA #1281.", "", "PSOSD1", ""], ["185", "DBIA185-A", "File", "SURGERY", "1992/07/16", "APPROVED", "Active", "Private", "131.7", "
An E3R has been issued, asking to modify the Health
Summary Print by location option to allow selection of an Operating Room, and
to queue the selected Health Summary Type to print for all patients scheduled
for surgery in that OR on a user-specified date. To that end, the Print by
Location driver has been modified to look at the "B" cross reference of the
Operating Room File (i.e., ^SRS("B",+LOC,ORLOC)) to get the record number of
the selected OR, and then traverse the "AOR" cross reference of the Surgery
File (i.e., ^SRF("AOR",+ORLOC,SDT,SRN) to get the record number of each
surgery. It then visits the zero-node of each Surgery record to get the
patient, whom it adds to the list of patients for Health Summaries to be
printed.\n
Health Summary makes direct references to the above cited globals and cross
references.", "", "", ""], ["186", "DBIA186-A", "Routine", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "", "
Means Test Billing Conversion.", "", "DGINPW", ""], ["187", "DBIA187-A", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Controlled Subscription", "2", "
Integrated Billing uses the following functions,
routines, files and fields:\n
2 DPT PATIENT FILE\n
.01 NAME-- Used for sorting and printed on a patients Check-off
Sheet and on the 'Unbilled BASC codes for insured Patients' report, returned
by function PT, function created to replace DEM^VADPT call\n
.363 PRIMARY LONG ID-- Returned by function PT, function created to
replace DEM^VADPT call\n
.364 PRIMARY SHORT ID-- Returned by function PT, function created to
replace DEM^VADPT call\n
2.98 (1900) APPOINTMENT SUBFILE
3-- STATUS-- Used to determine if Check-off sheet should be
printed\n
9.5-- APPOINTMENT TYPE
Printed on a patients Check-off Sheet\n
.3721(2.04) RATED DISABILITIES SUBFILE
printed on a patients Check-off Sheet if
SERVICE CONNECTED is true\n
.01 RATED DISABILITIES
2 DISABILITY %
3 SERVICE CONNECTED\n
^DPT(patient file)-- "ADIS"-- ^IBOVOP1: xref on login date/time - "DIS"--
^IBOVOP1: disposition node - 0;2 STATUS - 0;3 TYPE OF BENEFIT APPLIED FOR -
0;7 DISPOSITION - "S"-- ^IBECEA, ^IBOVOP, ^IBOVOP1 check appointments for a
C&P - "ACS"-- ^IBOVOP: means test status - .311 node-- ^IBEHCFA: insured's
info\n
PATIENT, #2-- "CN" cross-reference Billing of all current Category C
clients.\n\n", "", "", ""], ["188", "DBIA188-A", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "\n\n
STATUS^SDAMBAE4-- Incorporated current Ambulatory Procedure active status into
a CPT status function that also includes BASC and AMA status", "", "SDAMBAE4", ""], ["189", "DBIA189", "Routine", "REGISTRATION", "1992/08/03", "", "Retired", "Private", "", "
Record Tracking routines RTDPA31,RTSM and
^DD(195.9,.01,"V",,2) 'Ward location variable pointer screen' call\n
WIN^DGPMDDCF with DO=IFN of WARD LOCATION FILE to screen inactive wards as
borrowers/file areas.", "", "DGPMDDCF", ""], ["190", "DBIA190-A", "Routine", "ADVERSE REACTION TRACKING", "1992/08/06", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
The Medicine package has the permission of the Allergy Tracking System
developers to use the following items from ATS V2.2.\n
EN2^GMRAPEM0: This entry point is to be used by the Medicine package
to enter data into the Allergy Tracking System. The input variable
is DFN (pointer to file 2).", "", "GMRAPEM0", ""], ["191", "DBIA191-A", "Routine", "PHARMACY DATA MANAGEMENT", "1992/08/18", "", "Retired", "Private", "", "\n
^PSOPS: This entry point(and re-entry point) is the
functional Pharmacy Patient profile. This tool is used
for acquisition of display only data for use in
Rheumatology reports.", "", "PSOPS", ""], ["192", "DBIA192", "File", "1", "2005/06/20", "", "Retired", "Private", "", "
FileMan agrees that Quality Improvement Checklist can
call the following routine occurrences of ^DD references:\n
ROUTINE OCCURRENCES OF ^DD REFERENCES:\n
QIPEXT+2: I $D(QIPCUS) W !!,"This option displays the report
specifications",!,"for the QUIC",$P($P(";"_$P
(^DD(738.1,1,0),"^",3),";"_QIPCUS_":",2)," ;")," extract report(s).",! G EN\n
QIPEXTR+9: I $D(QIPCUS) S PNAME=$P($P(";"_$P(^DD(738.1,1,0),"^",3), CUS_":
",2),";")\n
QIPEXTR+18: K LOC,NAME,PM,PNAME S LOC=^QIP(738.1,OPTN,0),NAME=$P
(LOC,"^"),PM=$P(LOC,"^",2),PNAME=$P($P(";"_$P(^DD(738.1,1,0),"^",3),
";"_PM_":",2),"; ")\n
QIPEXTU1+21: W !?10,$J(CNT,2),". ",NAME," - ",$P($P(";"_$P(^DD
(738.1,1,0),"^",3),";"_PM_":",2),";")_$S($G(^QIP(738.1,OPTN,"NA"))
&(QIP'="V"):" <<NOT AVAILABLE>>",1:"")\n
GLOBAL LISTINGS OF THE REFERENCED DDs:\n
^DD("42",".03","0")="SERVICE^RSX^M:MEDICINE;S:SURGERY;P:PSYCHIATRY;
NH:NHCU;NE:NEUROLOGY;I:INTERMEDIATE MED;R:REHAB MEDICINE;SCI:SPINAL CORD
INJURY;D:DOMICILIARY;B:BLIND REHAB;NC:NON-COUNT;^0;3^Q"\n
^DD("738.1","1","0")="PARENT MENU^RS^L:LABORATORY;M:MAS;N:NURSING;
P:PHARMACY;S:SURGERY;Q:QUALITY MANAGEMENT;R:RADIOLOGY;^0;2^Q"\n\n", "", "", ""], ["193", "DBIA193", "Routine", "ACCOUNTS RECEIVABLE", "1992/09/15", "APPROVED", "Active", "Private", "", "
To activate the data extraction process of the Accounts
Receivable package, the MCCR National Database - Field Component, using
indirection, will issue the following call using parameter passing:\n
D EN1^PRCANRU(PRQDAT,PRQSTR,PRQIDN,.PRQERR)\n
Where: PRQDAT is a pieced variable, with ^ as the piece delimiter, as
follows: site number ^ batch number ^ from date ^ to date\n
PRQSTR is a variable which defines a global root where the
package extraction routine will place the data according to the
format below.\n
PRQIDN is a unique identifier number\n
PRQERR is an error flag which will be set to
"1 DATA COLLECTION ABORTED". The extract routine
must reset this variable so it evaluates to zero as an indicator
that the extraction process ran to completion.\n\n
Data is stored using the global root as follows:
PRQSTR_","_criteria#1_"-"_criteria#2)=#count^$amount
for example: ^TMP("PRQ","2020D611","1-1")=50^25000\n
The actual line of code in the MCCR National Database - Field Component will
appear as:
D @(extractor entry point) D DRIVER^PRQSD.\n
Finally, the code for invoking the routine will exist as an entry in the MCCR
Collections Routine file.\n
The AR package may directly enter an extractor routine into the MCCR
Collection Routines file (file #466), as part of its installation procedure.
The entry must include routine name and status, and proper cross-references
for these two fields. The routine name should include a "#" character to
indicate the proper position of the "^". Status may be either active or
inactive. Inactive extractors will not be invoked by the MCCR National
Database software.\n
The following extractor will be entered during installation of the MCCR
National Database - Field Component:
EN1#PRCANRU(PRQDAT,PRQSTR,PRQIDN,.PRQERR).\n
This entry may be modified, or other entries added, in subsequent AR releases
with prior notification to, and concurrence of, the San Francisco ISC.\n\n", "", "PRCANRU", ""], ["194", "DBIA194", "File", "LAB SERVICE", "1992/09/15", "APPROVED", "Active", "Private", "63", "\n\n
The Risk Assessment module of the Surgery package contains options that locate
and store lab test values for certain lab tests, which are later transmitted
to the Surgery Risk Assessment database at Hines for eventual analysis. These
options allow for the automatic input of pre-operative and post-operative lab
test values into the Surgery file. Each lab test and its associated specimen
is defined in one of the Surgery package files along with the site-specific
'Data Name(s)' associated with each test. The information in this file is
used to locate the latest pre-operative test value within 30 days of the
operation and the highest and/or the lowest test value within 30 days after
the operation.\n
The following files within the LABORATORY package are pointed to by Surgery:
- File 61 (TOPOGRAPHY FIELD)
- File 63 (LAB DATA)
Sub-File 63.04 (CHEM, HEM, TOX, RIA, SER, etc.)\n
Surgery reads data in the following fields within file 63 (LAB DATA):
- 63.04,.01 - DATE/TIME SPECIMEN TAKEN
Global Reference: ^LR(LRDFN,"CH",INVERSE DATE/TIME,0), piece #1\n
The INVERSE DATE/TIME subscript is determined by looping through
^LR(LRDFN,"CH",INVERSE DATE/TIME) for the inverse date/time range
based on the date/time of operation and the date/time of operation
+/- 30 days (minus 30 days for pre-operative data or plus 30 days for
post-operative data).\n
- 63.04,.03 - DATE REPORT COMPLETED
Global Reference: ^LR(LRDFN,"CH",INVERSE DATE/TIME,0), piece #3
- 63.04,.05 - SPECIMEN TYPE
Global Reference: ^LR(LRDFN,"CH",INVERSE DATE/TIME,0), piece #5
- 63.04,* All LAB TEST fields associated with Risk Assessment
Global Reference: ^LR(LRDFN,"CH",INVERSE DATE/TIME,DATA NAME), piece #1\n
The DATA NAME subscript is determined by looping through
^LR(LRDFN,"CH",INVERSE DATE/TIME,DATA NAME) checking for a match with
site specific Risk Assessment lab test data names stored in the
Surgery package.\n
Because the Surgery package will be making direct reference to data in the
Laboratory namespace, we request a Database Integration Agreement with the
developers of the Laboratory package permitting Surgery to reference the above
mentioned Laboratory data structures.\n", "", "", ""], ["195", "DBIA195", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
Display a patient's eligibility and disabilities the
same way MAS does on the routing sheet.\n
The subroutine DIS^SPROUT2 makes several global references:\n
^DPT(DFN,.372, ^DG(391, ^DIC(31,", "", "SDROUT2", ""], ["196", "DBIA196-A", "File", "LAB SERVICE", "1992/09/24", "APPROVED", "Active", "Private", "62.5", "
The Medicine Package has permission from the Lab
developers for read and write access to the ^LA node for the purpose of LSI
autoinstrument interfacing.\n
The Medicine Package has permission from the Lab developers for creating
entries in the Autoinstrument file for the purpose of LSI autoinstrument
interfacing.", "", "", ""], ["197", "DBIA197", "File", "LAB SERVICE", "1992/10/07", "APPROVED", "Active", "Private", "61.6", "
Oncology is granted LAYGO access to the SNOMED
Occupational File in Laboratory.", "", "", ""], ["198", "DBIA198", "File", "IFCAP", "1992/11/24", "APPROVED", "Active", "Controlled Subscription", "410", "
In an effort to provide a receiving mechanism for
Controlled Substances module, several look-ups and pointers are necessary for
an interim interface. For Purchase Order receipts, a lookup to PROCUREMENT &
ACCOUNTING TRANSACTIONS file 442, screened by cost center [822400] is used.
For Issue Receipts, a lookup occurs, screened by cost center [822400], in
CONTROL POINT ACTIVITY file 410. A connection between the DRUG file 50 and
ITEM MASTER file 441 is crucial for posting receipt information. This may be a
one-to-many relationship and therefore involves the creation of a multiple
IFCAP ITEM NUMBER field (#50.0441) in the DRUG file 50 pointing to the ITEM
MASTER file 441. This field includes an input transform similar to that found
in the NDC field in the ITEM MASTER file 441 preventing the linking of the
same item to more than one drug. It also includes an 'AB' whole file
cross-reference.\n
Pointer to CONTROL POINT ACTIVITY file 410 Pointer to ITEM MASTER file 441
Pointer to PROCUREMENT & ACCOUNTING TRANSACTIONS file 442\n
References information (Read only) from CONTROL POINT
ACTIVITY file 410
.01 TRANSACTION NUMBER
10 ITEM
.01 LINE ITEM NUMBER
1 DESCRIPTION
2 QUANTITY
3 UNIT OF PURCHASE
5 REPETITIVE (PR CARD) NO.
6 STOCK NUMBER
7 EST. ITEM (UNIT) COST
13 QUANTITY POSTED (WHSE)
14 QUANTITY REC'D (PRIMARY)\n
IFCAP files are used solely to gather and display receipt information and so
the Controlled Substances files 58.8 and 58.81 can accumulate a receipt
history.\n
DURATION: Till otherwise agreed, when the GIP & Drug Accountability interf ace
is available", "", "", ""], ["199", "DBIA199-A", "File", "QUALITY IMPROVEMENT CHECKLIST", "1992/12/04", "", "Retired", "Private", "736", "
1) The ALPHA PROJECT DATA file (#734) would like to
point to File 736,
QUIC SORT DATA file.
.01 VAMC in File 734 is a dinum pointer to File 736.\n
2) ALPHA routines access the following QUIC fields in a read-only manner:
File 736 QUIC SORT DATA
.01 STATION NAME", "", "", ""], ["200", "DBIA200", "File", "KERNEL", "1992/12/14", "APPROVED", "Active", "Private", "200", "
The ADP USER file 497.2 may have its top level .01
field DINUMed to the NEW PERSON file 200. The ADP USER file is limited to
distribution to the ISCs.", "", "", ""], ["201", "DBIA201", "Routine", "EXTERNAL PEER REVIEW", "1992/12/15", "APPROVED", "Active", "Private", "", "
Routine DGYEPRN makes a call to
$$QA^QIEQA($P(DGPT0,"^"),$P(DPT0,"^",2).$P(DGPT70,"^")). Resolving the $P
functions it equates to $$QA^QIEQA(DFN,ADM,DIS). DFN=patient, ADM=admit date,
DIS=discharge date. The function checks to see if the patient was referred to
peer review in the QA application. (See DBIA # 153 for agreement between EPRP
and QA for global access.)", "", "QIEQA", ""], ["202", "DBIA202", "Routine", "RECORD TRACKING", "1993/01/21", "APPROVED", "Active", "Controlled Subscription", "", "
IRT has permission to call in the following RT
routines:\n
MED^RTUTL3 calls LATEST^RTUTL3 where the doc is LATEST^RTUTL3
input variable is RTE entity DFN_";DPT("
output RTDATA=volume^borrower^phone/room#^date/time charged
RT = internal record number.\n\n\n", "", "RTUTL3", ""], ["203", "FEE BASIS PHARMACY INVOICE", "File", "FEE BASIS", "2006/01/31", "", "Retired", "Private", "162.1", "", "", "", ""], ["204", "DBIA204", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
Read Only access to the Hospital Location File (#44),
Field 1900 (Appointment), to read scheduling information from the global
^SC(D0,S,D1,1,D2,0). The information read will be stored in a Prosthetics
package file and used in the quarterly compilation of AMIS reports.\n
Read access to the ^SC(D0,"I") node to check the inactivate date (field #2505)
and the re-activate date (field #2506) to allow Prosthetics to Select an
active Clinic when entering Prosthetics Clinics in the Prosthetics Site
Parameter File.\n
Until V. 6.0 of Registration.", "", "", ""], ["205", "DBIA205", "File", "EVENT CAPTURE", "1993/01/29", "APPROVED", "Active", "Private", "723", "
Version 3.0 of the Surgery software had permission to
export the MEDICAL SPECIALTY file (#723) with data in the inits.", "", "", ""], ["206", "DBIA206", "Routine", "INPATIENT MEDICATIONS", "1993/01/29", "APPROVED", "Active", "Private", "", "
The Surgery package has permission to invoke the entry
point DCOR^PSIVACT, which is exported as part of the Inpatient Meds package.
This entry point allows surgery to discontinue all of a specific patient's IV
orders, and is documented in the version 4.0 Inpatient Meds will continue to
support this entry point until agreed. When DCOR^PSIVACT is invoked DFN, must
be set to the IEN for the patient whose orders are to be discontinued.
DCOR^PSIVACT uses the following variables: ON1, PSIVRES, PSIVREA,
PSIVDFN,PSIVON, PSIVLN. These variables are killed upon exit from the utility.
DFN is unchanged. In setting up the call to DCOR^PSIVACT, Surgery sets DFN
and PSIVRES. The other variables mentioned are set within PSIVACT.\n", "", "PSIVACT", ""], ["207", "DBIA207", "Routine", "LAB SERVICE", "1993/02/03", "APPROVED", "Active", "Private", "", "
Surgery is granted a database integration agreement
with Laboratory allowing Surgery to make a call to LRRP2 by executing
%ZOSF("TEST"), then calling LRRP2.", "", "LRRP2", ""], ["208", "PSSGIU", "Routine", "PHARMACY DATA MANAGEMENT", "1993/02/18", "APPROVED", "Active", "Private", "", "
The Surgery package is given formal permission from
Inpatient Medications to make calls to the routine PSGIU to mark and unmark
entries in the DRUG
file (#50) for anesthesia use. The entry points ENS^PSGIU and END^PSGIU are
the same entry points Surgery Version 2.12 has been using and we want to
continue using them in Version 3.0. Both entry points are documented in the
Inpatient Medications Technical Manual for Version 4.0.", "", "PSSGIU", ""], ["209", "DBIA209", "File", "NATIONAL DRUG FILE", "1993/02/18", "APPROVED", "Active", "Private", "50.6", "
Drug Accountability is granted this agreement to
connect the DRUG (#50) file to the ITEM MASTER (#441) file to make use of a
look-up to the NATIONAL DRUG (#50.6) file. If a selected DRUG file entry has
a NATIONAL DRUG FILE ENTRY (#20), a beloved path is followed to the NDC (#1)
multiple in the NATIONAL DRUG (#50.6) file. The user is allowed to check as
many of these NDCs as they choose for
a match in the ITEM MASTER (#441) file.\n
GLOBAL MAP DATA DICTIONARY #50 -- DRUG FILE STORED IN ^PSDRUG( SITE:
BIRMINGHAM ISC (#14) (VERSION 6)
-------------------------------------------------------------------------
^PSDRUG(D0,0)=(#.01) GENERIC NAME [1F] ^ ^PSDRUG(D0,441,0)=^50.0441P^^ (#441)
IFCAP ITEM NUMBER ^PSDRUG(D0,441,D1,0)= (#.01) ITEM NUMBER [1P] ^
^PSDRUG(D0,ND)= (#20) NATIONAL DRUG FILE ENTRY [1P] ^\n
GLOBAL MAP DATA DICTIONARY #50.6 -- NATIONAL DRUG FILE 02/11/93 STORED
IN ^PSNDF( (2269 ENTRIES) SITE: BIRMINGHAM ISC (#14)
-------------------------------------------------------------------------
^PSNDF(D0,0)= (#.01) VA GENERIC NAME [1F] ^
^PSNDF(D0,2,D1,3,D2,4,D3,5,D4,6,D5,7,0)=^50.67^^ (#1) NDC
^PSNDF(D0,2,D1,3,D2,4,D3,5,D4,6,D5,7,D6,0)= (#.01) NDC [1F] ^\n
Drug Accountability/Inventory Interface v3.0 interfaces with the prime vendor
invoice data. It uses the 12-digit NDC to match the invoice's line items to
drugs in the DRUG file (#50) if the NDC is not in the DRUG file. If the NDC
is found in the "NDC" cross-reference, the VA PRODUCT NAME POINTER field (#3)
is read to locate the VA PRODUCT NAMES field (#7). The DRUG file's "VAPN"
cross-reference is traversed to determine if any drugs have the same VA
product name. If so, the drugs are used as a suggested possible match to the
line item.\n\n
GLOBAL MAP DATA DICTIONARY #50.6 -- NATIONAL DRUG FILE
--------------------------------------------------------------------------
CROSS REFERENCED BY: NDC(NDC)\n
^PSNDF(D0,2,D1,3,D2,4,D3,5,D4,6,D5,7,D6,0)= (#.01) NDC [1F] ^^^ (#3) VA
==>PRODUCT NAME POINTER [4N] ^ ^PSNDF(D0,5,0)=^50.68A^^ (#7) VA
PRODUCT NAMES ^PSNDF(D0,5,D1,0)= (#.01) VA PRODUCT NAMES [1F] ^", "", "", ""], ["210", "DBIA210", "File", "LAB SERVICE", "1993/02/18", "APPROVED", "Active", "Private", "66", "
The Surgery package is granted permission from the
Laboratory package to read from the BLOOD PRODUCT file (#66) for purposes of
storing the blood components requested for surgical cases. Surgery will point
to the BLOOD PRODUCT file (#66), using a screen which looks at the CAN BE
REQUESTED field (#.15) to allow selection of only those blood products that
have been flagged for patient use.\n
In summary, Surgery will READ only, the NAME field (#.01) and the CAN BE
REQUESTED field (#.15) of the BLOOD PRODUCT file (#66).\n
The BLOOD PRODUCT file is stored in ^LAB(66).\n
The NAME is stored in $P(^LAB(66,DA,0),"^") where DA is the internal entry
number in the file for the blood product.\n
The CAN BE REQUESTED information is stored in $P(^LAB(66,DA,0),"^",15).\n", "", "", ""], ["211", "DBIA211-A", "File", "LAB SERVICE", "1993/02/18", "APPROVED", "Active", "Private", "60", "", "", "", ""], ["212", "DBIA212", "File", "OUTPATIENT PHARMACY", "1993/02/18", "APPROVED", "Active", "Private", "59", "", "", "", ""], ["213", "DBIA213", "Other", "AUTO REPLENISHMENT/WARD STOCK", "1993/02/18", "APPROVED", "Active", "Private", "", "\n\n
Permission is granted for Controlled Substances to:\n
Export AR/WS files
58.16 AOU INVENTORY TYPE
58.17 AOU ITEM LOCATION
58.2 AOU INVENTORY GROUP (partial file)
.01 NAME
2 GROUP DESCRIPTION
3 NARCOTIC AREA OF USE (NAOU)
.01 NARCOTIC AREA OF USE (NAOU)
1 INVENTORY TYPE
.01 INVENTORY TYPE
2 SORT KEY
"CS" X-REF ON NARCOTIC AREA OF USE (NAOU)\n
Pointer to AOU INVENTORY TYPE file 58.16 Pointer to AOU ITEM LOCATION file
58.17\n
GLOBAL MAP DATA DICTIONARY #58.16 -- AOU INVENTORY TYPE FILE\n
STORED IN ^PSI(58.16, (4 ENTRIES) SITE: BIRMINGHAM ISC (#14)
^PSI(58.16,D0,0)= (#.01) NAME [1F] ^ ^PSI(58.16,D0,1,0)=^58.18^^ (#1) TYPE
DESCRIPTION ^PSI(58.16,D0,1,D1,0)= (#.01) TYPE DESCRIPTION [1W] ^\n
GLOBAL MAP DATA DICTIONARY #58.17 -- AOU ITEM LOCATION FILE STORED IN
^PSI(58.17, (2 ENTRIES) SITE: BIRMINGHAM ISC (#14)
------------------------------------------------------------------------
^PSI(58.17,D0,0)= (#.01) ITEM ADDRESS CODE [1F] ^ ^ (#.5) CODE EXPANSION
==>[3F] ^ GLOBAL MAP DATA DICTIONARY #58.2 -- AOU INVENTORY
GROUP FILE\n
STORED IN ^PSI(58.2, (2 ENTRIES) SITE: BIRMINGHAM ISC (#14)
------------------------------------------------------------------------
^PSI(58.2,D0,0)= (#.01) NAME [1F] ^ ^PSI(58.2,D0,2,0)=^58.23^^ (#2) GROUP
DESCRIPTION ^PSI(58.2,D0,2,D1,0)= (#.01) GROUP DESCRIPTION [1W] ^
^PSI(58.2,D0,3,0)=^58.29P^^ (#3) NARCOTIC AREA OF USE (NAOU)
^PSI(58.2,D0,3,D1,0)= (#.01)NARCOTIC AREA OF USE (NAOU)[1P]^(#2)SORT KEY
==>[2N] ^ ^PSI(58.2,D0,3,D1,1,0)=^58.291PA^^ (#1)
INVENTORY TYPE ^PSI(58.2,D0,3,D1,1,D2,0)= (#.01) INVENTORY TYPE [1P] ^\n", "", "", ""], ["214", "DBIA214", "Other", "IFCAP", "1993/02/22", "APPROVED", "Active", "Controlled Subscription", "", "
The following is entered as DBIA until the next version
of DA:\n
All components indentified in this integration request involve reading
from IFCAP files. Drug Accountability does not write to any IFCAP files.
Looking toward an interface with the IFCAP Generic Inventory Package, Drug
Accountability (PSA) begins the process with a Connection Menu. The PSAINIT
creates in the DRUG file (#50) a multiple (#50.0441) pointing to the IFCAP
ITEM MASTER file (#441), enabling a direct link between the DRUG file (#50)
and the ITEM MASTER file (#441).\n
The first connecting tool provided in the Connection Menu is a sub- menu
using the National Drug Code (NDC) to attempt matching entries. In the ITEM
MASTER file (#441), the NDC field (#4) is located in the VENDOR multiple (#6).
This field has an input transform that prevents a user from using the same NDC
for more than one ITEM MASTER file entry. In studying an ITEM MASTER file
from a local site, it was discovered that there were several entries in their
ITEM MASTER file that did possess the same NDC. Since this situation might
lead a connector to link a drug to a potentially less active item, the first
option in the NDC Menu is the NDC Duplicates Report (ITEM file). This report
loops through the NDC ("F") x-ref in #441. If more than one item contains the
same NDC and is not inactive (field #16, '$G(^PRC(441,D0,3))), the duplicates
are listed. The report displays the NDC that has more than one item attached
to it, the item numbers attached, their SHORT DESCRIPTION (#.05), and the
VENDOR (#6) => VENDOR file (#440,#1) that contains the duplicated NDC.\n
The second item on the NDC Menu is the Report Potential NDC Matches
option. This report loops through the active, unlinked (to #441) entries in
the DRUG file (#50) that have an NDC. If a corresponding NDC is found in the
"F" x-ref in the ITEM MASTER file (#441), the NDC and drug name are listed
from the DRUG file (#50) and the ITEM NUMBER (#.01) and DESCRIPTION (#.1)
listed from the ITEM MASTER file (#441). Using the ITEM NUMBER ("AB") x-ref
in the DRUG file (#50), a check is made to see if the matched ITEM MASTER file
entry is already linked to another DRUG file entry. If so the user is
informed of the existing connection.\n
Using this same loop and display criteria, the Controlled Connection by
NDC Match allows the user the opportunity to actually link matched entries.
If the user approves the displayed match, a ^DIE stuff of the item number into
the item multiple (#50.0441) in the DRUG file occurs. Likewise, the Automated
DRUG/ITEM file link by NDC option uses the same loop and display criteria and
the ^DIE stuff for all matches in the loop.\n
In the event that the user requires more information about a selected drug
from either the DRUG file or the ITEM MASTER file before linking, the
Inquire/Compare DRUG file/ITEM file option is available. This option uses a
FM inquire with a no-link pointer jump from the DRUG file to the ITEM MASTER
file via the NDC "F" x-ref in #441. The user selects the drug from the DRUG
file and along with corresponding info from the DRUG file the DESCRIPTION
(#.1), NSN (#5), NDC (VENDOR (#6),#4) by which the jump occurred, and from
that same VENDOR multiple the UNIT COST (#1), UNIT OF PURCHASE (#1.5), DATE OF
UNIT PRICE (#2.5), PACKAGING MULTIPLE (#1.6), calculated unit cost = UNIT COST
(#1)/DISPENSE UNITS PER ORDER UNIT from the DRUG file, VENDOR (#.01), CREATED
BY (#15), and with a jump to #200 their OFFICE PHONE NUMBER. Using this same
jump, the DRUG file/ITEM file Comparison Report displays the same data with
the user selecting a range of drugs from the DRUG file.\n
The FSN Menu functions similar to the NDC Menu. The Report Potential FSN
Matches option loops through the active, unlinked (to #441) entries in the
DRUG file that have an FSN. If a corresponding NSN is found in the "BA" x-ref
in the ITEM MASTER file, the FSN and drug name are listed from the DRUG file
and the ITEM NUMBER (#.01) and DESCRIPTION (#.1) listed from the ITEM MASTER
file. Using the ITEM NUMBER ("AB") x-ref in the DRUG file, a check is made to
see if the matched ITEM MASTER file entry is already linked to another DRUG
file entry. If so the user is informed of the existing connection.\n
Using this same loop and display criteria the Controlled Connection by
FSN Match option allows the user to actually link matched entries. If the
user approves the displayed match, a ^DIE stuff of the item number into the
item multiple (#50.0441) in the DRUG file occurs. Likewise, the Automated
DRUG/ITEM File Link by FSN option uses the same loop and display criteria and
the ^DIE stuff for all matches in the loop.\n
The Single Drug Match option uses both the NDC and FSN/NSN tools
described previously to offer a connection for a single selection from the
DRUG file. If a link to an ITEM MASTER file entry already exists, it is
displayed to the user and they may edit the connection in the DRUG file.
Using the ITEM NUMBER multiple pointer (#50.0441) in the DRUG file, the user
can also do look-ups to the ITEM MASTER file via available x-refs (NSN (BA),
SHORT DESCRIPTION (C), VENDOR STOCK # (D), or NDC (F)) in order to select
additional connections.\n
The Report of Unlinked DRUG/ITEM File Entries lists active drugs from the
DRUG file which do not yet have any entries in the ITEM NUMBER multiple
(#50.0441). The Connect Unlinked DRUG/ITEM file Entries option loops through
these unlinked entries and offers all the tools described in the Single Drug
Match option to perform the links.\n
The Active, Unlinked Drugs in the ITEM File option allows the user to
select a purchase date from which to consider an ITEM MASTER file drug active.
It then loops through the ITEM MASTER file and when an entry's FSC (#2) = 6505
(Federal Supply Classification for drugs), is not an INACTIVATED ITEM? (#16),
is not linked to a drug('$O(^PSDRUG,"AB",ITEM,"")), has an entry in the FCP
(#1) multiple, and has within at least one FCP entry, an entry in the PURCHASE
ORDER (#1) multiple, the P.O. DATE(s) (#442,#.1) are checked against the user
selected purchase date. For entries that pass this criteria, the ITEM NUMBER
(#.01), SHORT DESCRIPTION (#.05), NSN (#5), LAST VENDOR ORDERED (#9), NDC
(#6,#4) (for the LAST VENDOR ORDERED), and the DESCRIPTION (#.1) are
displayed.\n
The Display Connected Drug option allows the user to print both a vendor
catalog for a selected item as well as a procurement history. The user
selects an entry from the DRUG file. If it is connected to more than one
entry in the ITEM MASTER file the user is asked to select one of the connected
entries from the ITEM NUMBER multiple (#50.0441). From the ITEM MASTER file,
the ITEM NUMBER (#.01), SHORT DESCRIPTION (#.05),and NSN are displayed. If the
selected ITEM MASTER file entry has only one VENDOR (#6) or has a MANDATORY
SOURCE (#10), then that vendor is displayed along with the VENDOR STOCK #
(#3), NDC (#4), PACKAGING MULTIPLE (#1.6), UNIT OF PURCHASE (#1.5), UNIT COST
(#1), MINIMUM ORDER (#8), DATE OF UNIT PRICE (#2.5), and REQUIRED ORDER
MULTIPLE (#9). If there is more than one vendor for the item, the LAST VENDOR
ORDERED (#9) is displayed as well as each available vendor sorted by DATE OF
UNIT PRICE (#2.5), beginning with the most recent date. For each vendor the
PACKAGING MULTIPLE (#1.6), UNIT OF PURCHASE (#1.5), UNIT COST (#1), DATE OF
UNIT PRICE(#2.5), and whether or not the vendor has a current contract is
listed. The contract verification is made by looping through the CONTRACT
NUMBER multiple (#6) in the VENDOR file (#440) and checking the EXPIRATION
DATE (#1). If there is an entry in the FCP (#1) multiple for the selected
item and any of the FCP entries have an entry in their PURCHASE ORDER (#1)
multiple, the user is offered a procurement history. They can enter a date
from which they wish to view the history. They must also select an FCP. For
each purchase order that passes the criteria, the PURCHASE ORDER NUMBER
(#.01), VENDOR (#5), P.O. DATE (#.1), QUANTITY (#40,#2) (LINE ITEM NUMBER
located using the "AE" x-ref in the ITEM (#40) multiple), UNIT OF PURCHASE
(#3), TOTAL COST(#15), and QUANTITY PREVIOUSLY RECEIVED (#11) are displayed.
Average ordered/month, total ordered, and total cost are also listed.
If the MANDATORY SOURCE (#10) for the selected item is flagged in the
VENDOR file (#440) with an "S" in the SUPPLY WHSE. INDICATOR (#.05), then the
user is informed that the Supply Warehouse is the mandatory source. Using the
"AD" x-ref in the INVENTORY TRANSACTION file (#445.2) a check is made for any
distribution by the warehouse of this item. If procurement history exists,
the user is informed and allowed to enter a date from which to view the
history. By looping through the "AD" x-ref in #445.2 and checking the
TRANSACTION ID (#1)?1"R".N and the DATE POSTED (#2.5) is not less than the
user entered date, a history is displayed. From the INVENTORY TRANSACTION
file (#445.2), the DATE POSTED (#2.5), TRANSACTION/P.O. NUMBER (#410),
-QUANTITY (#6), PACKAGING UNIT (#5), SELLING UNIT PRICE (#8), and OTHER
INVENTORY POINT AFFECTED (#14) are displayed.\n
The Unposted Procurement History and Posted Drug Procurement History
options are an effort to restore some of the drug accountability lost with the
disappearance of the LOG 036 report. For the Unposted Procurement History,
the user is asked to select a month to review. A loop through the PROCUREMENT
& ACCOUNTING TRANSACTION file (#442), using the P.O. DATE ("AB") x-ref
collects PO's for the user selected month. If the COST CENTER (#2) = 822400
(Pharmacy) and the SUPPLY STATUS (#.5)>14 & <45 (basically ordered), the PO's
are sorted into ^TMP by Station/FCP. For each Station/FCP the PO's are
listed, displaying PURCHASE ORDER NUMBER (#.01), P.O. DATE (#.1), FCP(#1),
VENDOR (#5), and TOTAL AMOUNT (#91). While looping through these PO's another
^TMP is created, sorted by the DESCRIPTION (#1) of each ITEM (#40) on each PO.
The user is asked if they would like to print item totals. If so, an
alphabetical listing occurs displaying each ITEM's (#40) DESCRIPTION (#1) and
REPETITIVE (PR CARD) NO. (#1.5) and each PURCHASE ORDER NUMBER (#.01), P.O.
DATE (#.1), FCP (#1), QUANTITY (#40,#2), ACTUAL UNIT COST (#40,#5), and TOTAL
COST (#40,#15). Finally, the user is if they would like a list of high dollar
items. They are invited to enter a cut-off dollar amount and each item
exceeding that amount is listed beginning with the highest total cost. The
total cost was determined by totaling the TOTAL COST (#40,#15) amounts for
each item listed in the previous display and building a ^TMP to sort from high
to low. Each ITEM's (#40) DESCRIPTION (#1), total TOTAL COST (#15), and
Station/FCP is shown.\n
The Posted Drug Procurement History option uses the TYPE OF INVENTORY
POINT ("AC") x-ref in the GENERIC INVENTORY file (#445) to locate a "W" or the
warehouse inventory. A loop through the INVENTORY ITEM (#1) multiple, using
the ITEM NO. (#.01) to check in the ITEM MASTER (#441) file for a FSC (#2) =
6505 (Federal Supply Classification for drugs) isolates the warehouse drugs in
^TMP. Looping through ^TMP a check is made using the INVENTORY POINT ("AD")
x-ref in the INVENTORY TRANSACTION (#445.2) file to isolate items that have
had distribution (TRANSACTION ID (#1)?"R".N) and fall within the user selected
month (DATE POSTED (#2.5)). These transactions are sorted by the OTHER
INVENTORY POINT AFFECTED (#14) and the OTHER INVENTORY POINT AFFECTED (#14) ,
-QUANTITY (#6), QUANTITY (#410,#10,#2) obtained by using the TRANSACTION /P.O.
NUMBER (#445.2,#410), PACKAGING UNIT (#5), SELLING UNIT PRICE (#8), total cost
(-QUANTITY (#6) * SELLING UNIT PRICE (#8)), DATE POSTED (#2.5), and
TRANSACTION/P.O. NUMBER (#410). Similar to the Unposted Procurement History,
a high dollar sort is also offered.\n
As stated in the opening paragraph, the Connection Menu lays the
groundwork for an interface with the IFCAP Generic Inventory Package. Phase
two of this process is contained in a Pharmacy Location Menu. With this menu
the Pharmacy user will create and edit the parameters of a Drug Accountability
location such as Inpatient, Outpatient, or a Combined (IP/OP) operation. The
purpose of the interface is to allow the receiving that occurs in the
Inventory Package to pass the converted dispensing unit quantity of a
connected drug (ITEM/DRUG file) from a Generic Inventory point (#445) to a
Drug Accountability location (#58.8). To establish a direct link between
these two files, a PRIMARY INVENTORY POINT field exists in the DRUG
ACCOUNTABILITY STATS file (#58.8). This field points to the GENERIC INVENTORY
file (#445) uses the TYPE OF INVENTORY POINT (#.7) = "P" and COST CENTER (#.9)
= 822400 (Pharmacy) fields as screens. The input transform also contains a
call to ^PSAUTL where the "E" x-ref in #58.8 is checked to prevent the linking
of one primary inventory point to more than one DA location. The Set up/edit
a Pharmacy Location option allows the user to edit this link. If a DA
location (#58.8)is linked to an Inventory point (#445), the INVENTORY ITEMS
(#1) are checked both against the "AB" x-ref in the DRUG (#50) file and the
"C" x-ref in the DA (#58.8) file to see if all Inventory items are tracked in
DA. If not the user is given the ability (^DIE) to add Inventory items to the
DA location. The Display Location option shows the PRIMARY INVENTORY POINT
(#11) currently linked to the selected DA location.\n
The Inventory Interface sub-menu contains three report options and a
populate option. The Report of Inventory items' link to DRUG file displays
from a selected GENERIC INVENTORY point (#445), selection screened by COST
CENTER (#.9) = 822400 and TYPE OF INVENTORY POINT (#.7) = "P", the ITEM NO.
(#445,#1,#.01), either the DESCRIPTION (#.7) or from the ITEM MASTER file
(#441), the SHORT DESCRIPTION (#.05)and if connected the DRUG (#50) name. The
Loadable Inventory Items Report operates exactly the same, however, only lists
connected items. The Populate Pharmacy Location with Inventory items option
uses the same criteria and if a connected drug within an inventory point does
not yet exist in the DRUG (#10) multiple in the selected DA location (#58.8),
a ^DIE stuff occurs with a list of drugs loaded displayed at a user selected
device. The Display Drugs Not Loaded in Primary option loops through the DRUG
(#10) multiple in a selected DA location (#58.8) and using the "AB" x-ref in
the DRUG (#50) file, checks the "AE" x-ref in the GENERIC INVENTORY (#445)
file for the existance of each drug in the linked Primary Inventory Point.
Those drugs not found in the Inventory point are displayed along with their
ITEM MASTER (#441) file NUMBER (#.01) and SHORT DESCRIPTION (#.05).\n\n
CONDENSED DATA DICTIONARY---DRUG FILE (#50) VERSION: 6\n
STORED IN: ^PSDRUG( 01/26/93
--------------------------------------------------------------------------\n
CROSS REFERENCED BY:
ITEM NUMBER(AB)\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.001 NUMBER (NJ5,0), [ ] .01 GENERIC NAME (RF), [0;1] 6 FSN
(F), [0;6] 12 ORDER UNIT (P51.5'), [660;2] 13 PRICE PER ORDER
UNIT (NJ7,2), [660;3] 14.5 DISPENSE UNIT (F), [660;8] 15 DISPENSE
UNITS PER ORDER UNIT (NJ4,0), [660;5] 16 PRICE PER DISPENSE UNIT
(NJ6,2), [660;6] 17 SOURCE OF SUPPLY (F), [660;7] 31 NDC (FX),
[2;4] 100 INACTIVE DATE (D), [I;1] 441 IFCAP ITEM NUMBER
(Multiple-50.0441), [441;0]
.01 ITEM NUMBER (M*P441'X), [0;1]\n
CONDENSED DATA DICTIONARY---ITEM MASTER FILE (#441)UCI: LTL,VAA\n
STORED IN: ^PRC(441, 01/26/93
--------------------------------------------------------------------------\n
CROSS REFERENCED BY:
SHORT DESCRIPTION(AC) INACTIVATED ITEM?(AD)
NUMBER(B) NSN(BA) NSN(BB) SHORT DESCRIPTION(C)
VENDOR STOCK #(D) NDC(F) NSN(G)\n\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.01 NUMBER (RNJ6,0X), [0;1] .05 SHORT DESCRIPTION (RFX), [0;2] .1
DESCRIPTION (Multiple-441.02), [1;0]
.01 DESCRIPTION (W), [0;1] 1 FCP (Multiple-441.03), [4;0]
.01 FCP (RFX), [0;1]
1 PURCHASE ORDER (Multiple-441.04), [1;0]
.01 PURCHASE ORDER (P442'X), [0;1]
3 PREFERRED VENDOR (*P440'), [0;3] 2 FSC (RP441.2'),
[0;3] 5 NSN (FX), [0;5] 6 VENDOR (Multiple-441.01), [2;0]
.01 VENDOR (MP440X), [0;1]
1 UNIT COST (RNJ10,3), [0;2]
1.5 UNIT OF PURCHASE (RP420.5'), [0;7]
1.6 PACKAGING MULTIPLE (RNJ6,0), [0;8]
2 CONTRACT (NJ6,0XO), [0;3]
2.2 CONTRACT EXP. DATE (CJ8), [ ; ]
2.5 DATE OF UNIT PRICE (RD), [0;6]
3 VENDOR STOCK # (FX), [0;4]
4 NDC (FX), [0;5]
8 MINIMUM ORDER (NJ6,0), [0;12]
9 REQUIRED ORDER MULTIPLE (NJ6,0), [0;11] 9 LAST VENDOR
ORDERED (P440'), [0;4] 10 MANDATORY SOURCE (*P440'), [0;8] 14
DATE ITEM CREATED (D), [0;9] 15 CREATED BY (P3'), [0;11] 16
INACTIVATED ITEM? (S), [3;1]\n
CONDENSED DATA DICTIONARY---VENDOR FILE (#440) UCI: LTL,VAA\n
STORED IN: ^PRC(440, 01/26/93
--------------------------------------------------------------------------\n
CROSS REFERENCED BY:
SUPPLY WHSE. INDICATOR(AC) NAME(AD) INACTIVATED VENDOR(AE)
NAME(B) SYNONYM(C)\n\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.001 NUMBER (NJ6,0), [ ] .01 NAME (RFX), [0;1] .05 SUPPLY
WHSE. INDICATOR (SX), [0;11] 6 CONTRACT NUMBER (Multiple-440.03),
[4;0]
.01 CONTRACT NUMBER (MFX), [0;1]
1 EXPIRATION DATE (RD), [0;2]\n
CONDENSED DATA DICTIONARY---NEW PERSON FILE (#200) VERSION: 6.5\n
STORED IN: ^VA(200, 01/27/93
--------------------------------------------------------------------------\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.01 NAME (RFX), [0;1] .132 OFFICE PHONE (F), [.13;2]\n
CONDENSED DATA DICTIONARY---PROCUREMENT & ACCOUNTING TRANSACTIONS FILE (#442)\n
STORED IN: ^PRC(442, 01/27/93
--------------------------------------------------------------------------\n
CROSS REFERENCED BY:
P.O. DATE(AB) FCP(AC) ISSUE VOUCHER NO.(SUPPLY)(AD)\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.01 PURCHASE ORDER NUMBER (RFX), [0;1] .1 P.O. DATE (RDX), [1;15]
.5 SUPPLY STATUS (*P442.3'), [7;1] 1 FCP (RFX), [0;3] 2
COST CENTER (FX), [0;5] 5 VENDOR (R*P440X), [1;1] 40 ITEM
(Multiple-442.01), [2;0]
.01 LINE ITEM NUMBER (RMNJ2,0X), [0;1]
1 DESCRIPTION (Multiple-442.05), [1;0]
.01 DESCRIPTION (W), [0;1]
1.5 REPETITIVE (PR CARD) NO. (*P441'X), [0;5]
2 QUANTITY (RNJ9,2), [0;2]
3 UNIT OF PURCHASE (RP420.5'X), [0;3]
5 ACTUAL UNIT COST (RNJ9,2X), [0;9]
11 QUANTITY PREVIOUSLY RECEIVED (NJ9,2), [2;8]
15 TOTAL COST (RNJ9,2), [2;1] 91 TOTAL AMOUNT (RNJ10,2),
[0;15]\n
CONDENSED DATA DICTIONARY---INVENTORY TRANSACTION FILE (#445.2)\n
STORED IN: ^PRCP(445.2, 01/27/93
--------------------------------------------------------------------------\n
CROSS REFERENCED BY:
DATE POSTED(ABEG) ITEM NO.(AC) INVENTORY POINT(AD)
ITEM NO.(AE) INVENTORY POINT(ANXT) INVENTORY POINT(B)
TRANSACTION/P.O. NUMBER(C) TRANSACTION ID(T)\n\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.01 INVENTORY POINT (RP445'), [0;1] 1 TRANSACTION ID (RF), [0;2]
2.5 DATE POSTED (D), [0;17] 5 PACKAGING UNIT (F), [0;6] 6
QUANTITY (NJ6,0), [0;7] 8 SELLING UNIT PRICE (NJ11,3), [0;9] 14
OTHER INVENTORY POINT AFFECTED (P445'), [0;18] 410 TRANSACTION/P.O.
NUMBER (F), [0;19]\n
CONDENSED DATA DICTIONARY---GENERIC INVENTORY FILE (#445)\n
STORED IN: ^PRCP(445, 01/27/93
--------------------------------------------------------------------------\n
CROSS REFERENCED BY:
DISTRIBUTION POINT(AB) TYPE OF INVENTORY POINT(AC)
INVENTORY USER(AD) ITEM NO.(AE) ABBREVIATED NAME(AF)
KEEP PERPETUAL INVENTORY?(AG) INVENTORY POINT(B)
INVENTORY POINT(C)\n\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.01 INVENTORY POINT (RFX), [0;1] .7 TYPE OF INVENTORY POINT
(R*SX), [0;3] .9 COST CENTER (P420.1'), [0;7] 1 INVENTORY ITEM
(Multiple-445.01), [1;0]
.01 ITEM NO. (MP441'X), [0;1]\n
CONDENSED DATA DICTIONARY---DRUG ACCOUNTABILITY STATS FILE (#58.8)\n
STORED IN: ^PSD(58.8, 01/27/93
--------------------------------------------------------------------------\n
CROSS REFERENCED BY:
DRUG(C)
PRIMARY INVENTORY POINT(E)\n
FILE STRUCTURE\n
FIELD FIELD NUMBER NAME\n
.01 PHARMACY LOCATION (RF), [0;1] 10 DRUG (Multiple-58.8001),
[1;0]
.01 DRUG (MR*P50'X), [0;1] 11 PRIMARY INVENTORY POINT
(*P445'X), [0;6]\n
This DBIA is effective until 18 months following Drug Accountability V2.0.\n", "", "", ""], ["215", "DBIA215", "Other", "CONTROLLED SUBSTANCES", "1993/02/24", "APPROVED", "Active", "Private", "", "
Export Drug Accountability files\n
58.8 DRUG ACCOUNTABILITY STATS 58.81 DRUG ACCOUNTABILITY TRANSACTION
58.16 AOU INVENTORY TYPE 58.83 CS COMPLETION STATUS 58.82 CS ORDER
STATUS 58.86 CS DESTRUCTION 58.84 DRUG ACCOUNTABILITY TRANSACTION TYPE\n
TEMPORARY FOR V1.0.", "", "", ""], ["218", "DBIA218-A", "File", "REGISTRATION", "1993/03/04", "APPROVED", "Active", "Controlled Subscription", "45.3", "", "", "", ""], ["219", "DBIA219", "Routine", "INCOMPLETE RECORDS TRACKING", "1993/03/04", "APPROVED", "Active", "Controlled Subscription", "", "
A DBIA with INCOMPLETE RECORD TRACKING is granted for
the following:\n
Purpose:\n
To allow the IRT file to be updated automatically with data generated through
the Discharge Summary or Test Integration Utilities Package whenever a
discharge or other deficiency type summary is dictated, transcribed, signed or
reviewed. Distribution of the IRT interface routine: DGJSUM.\n
Responsibilities:\n
It will be the Albany IRMFO's responsibility to maintain the interface routine
DGJSUM and make sure that it functions properly to lookup, create and update
IRT records. The Salt Lake IRMFO will be responsible to make sure that the
entry points to DGJSUM are accessed in an appropriate manner with good data
being passed. If any modification to either package is made that will affect
the functionality of this interface, then it will be necessary for the IRMFO
responsible for the change to communicate with the other IRMFO in order to
resolve any issues.", "", "DGJSUM", ""], ["220", "DBIA220", "File", "REGISTRATION", "1993/03/24", "APPROVED", "Active", "Private", "2", "\n\n
Outpatient Pharmacy has permission to edit fields in Patient File (#2):\n
Outpatient Pharmacy has used two input templates, PSO OUTPT and PSO OUTPTA in
the Patient File (#2) since about 1984.\n
PSO OUTPT template edits the following fields:
.03,.09,.111:.116, .131, 148, .172, .12105, .1211:.1213, .1219 and .091.\n
PSO OUTPTA template edits the following fields:
.12105, .1211:.1213, .1219 and .1214:.1218.\n
The MAS developers have agreed to allow the Outpatient Pharmacy package to
edit these fields using the above input templates under the following
conditions:
1. Patch per ZIP+4. There will soon be two new zip+4 fields associated
with Permanent and Temporary Address fields that should be used instead of the
zip code fields listed above.
2. MAS developers will provide a utility to edit the above information and
with the next release of Outpatient Pharmacy I will use their utility.\n
Outpatient Pharmacy developers agree to the above stated conditions of use.\n\n", "", "", ""], ["221", "DBIA221-A", "File", "PHARMACY DATA MANAGEMENT", "1999/05/24", "APPROVED", "Active", "Controlled Subscription", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 50 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.", "", "", ""], ["222", "DBIA222-A", "File", "CPT/HCPCS CODES", "1993/04/02", "", "Retired", "Private", "81", "
The DD for the CPT file (81) includes the following
node which causes the CPT code description to be displayed when a lookup is
done on the CPT file:
^DD(81,0,"ID",2)="W " ",$P(^(0),U,2) I $D(SRSITE) D ^SROCPT"\n
Part 1: An agreement is established for Surgery to call ^DD(81,0,"ID",2).
This DD node will remain in place to assist with CPT lookups from within the
Surgery package. Surgery will be responsible for support of the conditional
call to ^SROCPT.\n
Part 2: In the routine SROCPT, the DESCRIPTION multiple is accessed (READ
only). Surgery has permission to read the DESCRIPTION sub-fields. Each
description for a CPT code is stored in ^ICPT(X,"D",Y,0) where X is the
internal entry for the CPT code and Y is the internal entry for the
description. The Surgery package loops through ^ICPT(X,"D",Y,0) to get all
the descriptions for a CPT code.", "", "", ""], ["223", "DBIA223", "File", "DRUG ACCOUNTABILITY", "1993/04/21", "APPROVED", "Active", "Private", "58.8", "
Outpatient Pharmacy is given permission by Controlled
Substances to make the following calls:\n
GLOBAL MAP DATA DICTIONARY #58.8 -- DRUG ACCOUNTABILITY STATS FILE 2/26/93
---------------------------------------------
STORED IN ^PSD(58.8 SITE: ISC BIRMINGHAM
--------------------------------------------------------------------------
^PSD(58.8,D0,0)= (#20) OUTPATIENT SITE [10P] ^\n", "", "", ""], ["224", "DBIA224", "File", "KERNEL", "1993/04/21", "APPROVED", "Active", "Private", "200", "
Outpatient Pharmacy is given permission by Kernel to
make calls to the following:\n
GLOBAL MAP DATA DICTINARY #200 -- NEW PERSON FILE 2/25/93 STORED
IN ^VA(200, SITE: ISC BIRMINGHAM (VERSION 6.5)
----------------------------------------------------------------------
^VA(200,D0,PS)= (#53.1) AUTHORIZED TO WRITE MED ORDERS [1S] ^ (#53.2)
==>DEA# [2F] ^ (#53.3) VA# [3F] ^ (#53.4) INACTIVE DATE [4D] ^
==>(#53.5) PROVIDER CLASS [5P] ^ (#53.6) PROVIDER TYPE [6S] ^
==>(#53.7) REQUIRES COSIGNER [7S] ^ (#53.8) USUAL COSIGNER
==>[8P] ^ (#53.9) REMARKS/COMMENTS [9F] ^
^VA(200,D0,PS1,0)=^200.541P^^ (#54.1) LICENSING STATE ^VA(200,D0,PS1,D1,0)=
(#.01) LICENSING STATE [1P] ^ ^VA(200,D0,PS2,0)=^200.55P^^ (#54.2) STATE
ISSUING DEA NUMBER ^VA(200,D0,PS2,D1,0)= (#.01) STATE ISSUING DEA NUMBER [1P]
^\n
^VA(200,D0,TPB)= (#53.91) NON-VA PRESCRIBER [1S] ^ (#53.92) EXCLUSIONARY
==>CHECK PERFORMED [2S] ^ (#53.93) DATE EXCLUSIONARY LIST
==>CHECKED [3D] ^ (#53.94) ON EXCLUSIONARY LIST [4S] ^ (#53.95)
==>TAX ID [5F] ^ (#53.96) EXCLUSIONARY CHECKED BY [6P:200] ^", "", "", ""], ["225", "DBIA225-A", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
Prosthetics has permission from MAS to call the
following:\n
Addition of the Prosthetics Protocol RMPR SCHED EVENT as an item on the SDAM
APPOINTMENTS EVENTS Protocol in File 101. Below is a display of the RMPR
SCHED EVENT protocol:\n
RMPR SCH EVENT ITEM TEXT: Prosthetics Scheduling file update TYPE: action
PACKAGE: PROSTHETICS\n
Updates the Prosthetics Scheduling Events file whenever an appointment is
created or updated. The Clinic must be in the Prosthetics Site Parameter file
before the Prosthetics files can be updated by MAS.\n
ENTRY ACTION: D ^RMPRSC\n
SDAM APPOINTMENT EVENTS ITEM TEXT: Appointment Event Driver
TYPE: extended action CREATOR: POSTMASTER\n
This extended action contains all the actions that need to be performed when
an action is taken upon an appointment, such as checking in.\n
ITEM: SDAM LATE ENTRY SEQUENCE: 2 ITEM: IBACM OP LINK
SEQUENCE: 1 ITEM: RMPR SCH EVENT
SEQUENCE: 3 TIMESTAME: 55576,33406", "", "", ""], ["226", "DBIA226-A", "Routine", "REGISTRATION", "1993/05/03", "", "Retired", "Private", "", "", "", "DGPTFCR", ""], ["227", "DBIA227-A", "File", "IFCAP", "1993/05/05", "APPROVED", "Active", "Private", "445", "
Prosthetics is granted permission to make the following
calls to the IFCAP package (GIP and 1358 Modules). As stated below this is
until the next version of either IFCAP or Prosthetics.\n
For GIP (Items 1 - 3): Item 1 is needed so that we can check to see if an item
that is being returned from loan is in an inventory point, so that it can be
placed back into inventory. Item 2 is needed to so that we can do a lookup to
make sure that the user returning a loaned item is an Inventory User. Item 3
is needed so that we can make sure that the user returning an item is an
Inventory User for that particular Inventory Point.\n
Item 1 Description: Read Only access to File #445, GENERIC INVENTORY, to look
at the cross-referenced node ^PRCP(445,"AE",ITEM#,DA).\n
Item 2 Description: Read Only access to File #445, GENERIC INVENTORY, so
that we can look at the "AD" cross-reference in the file.\n
Item 3 Description: Read Only access File #445, field 6, INVENTORY USER.\n
Item 5 DIC lookup on File #445 Generic Inventory. Read access only to the .01
field. The variable PRCPPRIV may be set by Prosthetics.", "", "", ""], ["228", "DBIA228-A", "File", "INTEGRATED BILLING", "1993/05/12", "APPROVED", "Active", "Private", "353.1", "", "", "", ""], ["229", "DBIA229-A", "Routine", "1", "1993/05/18", "APPROVED", "Active", "Private", "", "\n\n
MailMan V7 has permission to make the following calls to FileMan:\n
1. MailMan has a special way of calling the FileMan editor. It calls EN^DIWE
and supplies DWPK, DWLW, DIA, DIC and DIA("P"). The way that MailMan calls
DIWE allows a slightly different set of functionalities. The transfer command
is defaulted to use the 3.9 (Message) file if no file is specified. DWPK
forces automatic wrapping of text at DWLW number of characters. Because of
this the variable DC must have the appropriate value and MailMan kills it to
may sure it is undefined. DWLW and DWPK have recently been released along
with EN^DIWE as a callable entry point, but the use of DIC and DIA together
still provide to MailMan special functionality in the FileMan line editor,
namely the ability to transfer lines of text in from other messages that the
user is the sender or a recipient of.", "", "DIWE", ""], ["230", "DBIA230", "Other", "KERNEL", "1993/05/18", "APPROVED", "Active", "Private", "", "\n\n
MailMan V7 has permission to make the following calls to Kernel:\n
1. The modules affected by this agreement are in the namespace:\n
o Device Handler (ZIS* & %ZIS*, not ZISL* & %ZISL*)\n
2. REQ^%ZTLOAD is called in the following manner to ensure a back-up task
exists if this one should fail:\n
I $L(ION) S ZTIO(1)="D",ZTIO=ION D REQ^%ZTLOAD\n
The result of this call leaves the task in the IO queue for the device it is
running on (and no other, even if the device is a member of a hunt group).\n
3. The Kernel Site Parameters file contains fields that are used by modules
in Kernel other than MailMan. The MailMan development team will maintain the
file and will reserve fields and field numbers in the range of 3000 to 3999
for the use of this module. No alpha subscripts will be used by non-MailMan
kernel packages without agreement from the MailMan development team except for
those already in use and noted below. The exception to the above are nodes
beginning with the Kernel namespace (ZI) which is reserved for this kernel
packages and cross references beginning with any letter, but having the above
namespace immediately follow that letter (EG. AZI5).\n
Any changes to this file require the notification of the MailMan development
team. A method for ensuring that the distribution of the file by MailMan will
then be negotiated.\n
The fields that are currently in use and are not *'ed for removal within 18
months are: (#=multiple)\n
Field Number # Description node;piece\n
31.1 Max spool lines SPL;1 31.2 Max
spool documents SPL;2 31.3 Max spool doc life
SPL;3\n
4. By agreement files 3.51, Spool Document [in ^XMB(3.51,] and file 3.519,
Spool Data [in ^XMBS(3.519,] can continue to exist in the MailMan namespaced
globals.\n", "", "", ""], ["231", "DBIA231", "Other", "KERNEL", "1993/05/18", "APPROVED", "Active", "Private", "", "
MailMan V7 has permission to make the following calls
from Kernel Task Manager V7:\n
1. The Kernel modules that this document refers to are:\n
o Task Management (ZTM* and %ZTM*)\n
2. REQ^%ZTLOAD is called in the following manner to ensure a back-up task
exists if this one should fail:\n
I $L(ION) S ZTIO(1)="D",ZTIO=ION D REQ^%ZTLOAD\n
The result of this call leaves the task in the IO queue for the device it is
running on (and no other, even if the device is a member of a hunt group).\n
3. The routine XMS5 tries to confirm that tasks exist by looking at:\n
$D(^%ZTSK(task,0)) ==> if the node exists the task exists
$D(^%ZTSCH("TASK",task)) ==> If the node exists, the task is running
"12345AG"[%ZTSCH("TASK",.1) $D(^%ZTSCH("IO",device,$h,task)) ==> The task is
scheduled\n
4. MailMan 7 looks at ^%ZTSK(task,"C",0) for a count of the times the task has
run. The next version will not use this any more.\n", "", "", ""], ["232", "DBIA232", "File", "KERNEL", "1993/05/18", "APPROVED", "Active", "Private", "200", "
The Inpatient Medications package requests a DBA
exemption to allow the .01 field of the INPATIENT USER PARAMETERS file (53.45)
to point to the NEW PERSON file (200). This file contains fields that are used
by Inpatient Medications to store data used in the order entry process, and
has been DINUMED to the NEW PERSON file as recommended in the peer review, to
allow these fields to be more easily moved to 200 if necessary in a future
release.\n", "", "", ""], ["233", "DBIA233", "Other", "1", "1993/05/18", "APPROVED", "Active", "Private", "", "
MAILMAN has permission to make the following calls to
VA Fileman:\n
1. FileMan has a special way of using the XMD interface and it also has
special calls into the XMP series of routines so that it can load INITs
directly into a message during a DIFROM. As such the variable DIFROM effects
that way some of these routines work so that the DIFROM procedure can use them
to enter data and routines reiteratively into messages.\n
o In the routine XMD, if $D(DIFROM) security keys are not ignored.\n
o In the routine XMD, if $D(DIFROM) will cause a call to XMD at either tag
EN1 or tag EN2 to quit after text is added to a message, but before the
message is delivered.\n
o In the routine XMD, if $D(DIFROM) before delivery, security will be added
automatically by a call to XMASEC.\n
o In the routine XMASEC, if $D(DIFROM) security is forced onto the message.\n
o In the routine XMP, if $D(DIFROM) the string " (DIFROM)" is added to the
1st line of the PackMan message to show how it was created.\n
o In the routine XMPH a special prompt is provided where DIFROM loading
into a message causes special help for the programmer.\n
2. Kernel modules to which this document refers are (even if they are at
some point separated from the Kernel and become independent modules of their
own): FileMan (DI*)", "", "", ""], ["234", "DBIA234", "Other", "KERNEL", "1993/05/18", "APPROVED", "Active", "Private", "", "
Mailman is given permission to make the following calls
to Kernel:\n
1. CHK^XM is an entry point set aside only for calls external from MailMan.
It is used by KERNEL routines to notify users of new messages for a user
during logon or as invoked from MenuMan. XMDUZ is used if supplied, otherwise
DUZ is a pointer to the user's Mailbox. The symbol table of the caller is
changed as the code currently stands. Y is output as a count of new messages.
% and D are also used and not killed by MailMan. The Kernel security routine
will continue to use this entry point, which also is necessary to make sure
that ^TMP("XMY",$J) is cleaned out on login and ensures that when job numbers
are reused after reboot, there is not data in ^TMP("XMY",$J) to include
recipients from old mail sessions in currently generated bulletins that come
from outside of MailMan. An example is the 'Dropping into Programmer Mode
bulletin'.\n
2. ^XM may be called in order to offer MailMan as a service directly to
users on logon.\n
3. The XMUSER and XMMGR menus may be used in high level menu structures.\n
4. Kernel modules to which this document refers are (even if they are at
some point separated from the Kernel and become independent modules of their
own) are System security (XU* and XT*).\n
5. Kernel security and user related modules currently can call NEW^XM to set
up an new user's or reactivated user's mail box. The entry point uses the
variables I, Y and K destructively. If it is called for a user who is being
reactivated, that user will not receive responses to messages he is a
recipient of and were created before his reinstatement, unless he is
explicitly forwarded them, or he 'owns' the original message in one of his
mail boxes.\n
6. XMPC is called by the Kernel routine comparer. All the proper set-up has
been done and MailMan will coordinate any changes in this area with the
programmer responsible for Kernel Utilities.\n
7. Kernel directly references the 5th piece of the Mail Basket multiple of
the Mail Box file (3.7) to get the number of messages in a mail basket.\n
8. Kernel directly references the 6th piece of the zero node of the Mail Box
file (3.7) to get the number of new messages in a mail box\n
9. There are some data fields in the Mail Box file (3.7) that are not used
in MailMan. They are used by sign-on security and should be maintained by
sign-on security routines also.\n
field # Description node;piece
20 Last Sign-on Date/Time .1;1
21 Last Terminal Type Used .2;1
22 Already Signed On To Devices 100 (multiple)\n
10. The Kernel Site Parameters file contains fields that are used by modules
in Kernel other than MailMan. The MailMan development team will maintain the
file and will reserve fields and field numbers in the range of 1000 to 1999
for the use of this kernel module. No alpha subscripts will be used by
non-MailMan kernel packages without agreement from the MailMan development
team except for those already in use and noted below. The exception to the
above are nodes beginning with the namespaces (XU amd XT) which are reserved
for non-MailMan kernel packages and cross references beginning with any
letter, but having the above namespaces immediately follow that letter (EG.
AXT5).\n
Any changes to this file require the notification of the MailMan development
team. A method for ensuring that the distribution of the file by MailMan will
then be negotiated.\n
Field Number # Description node;piece\n
11 Auto-generate access codes 3;1
12 User char Template 3;2
202 Default number of attempts XUS;2
203 Default lock-out time XUS;3
204 Default Multiple sign-ons XUS;4
205 Ask device at sign-on XUS;5
209 Default type-ahead XUS;9
211 Bypass Device lock-out XUS;10
212.1 Device to audit 4.33 (subfile)\n
240 INTRO text INTRO\n\n", "", "", ""], ["235", "DBIA235", "Routine", "MCCR BACKBILLING", "1993/06/02", "", "Retired", "Private", "", "
Call ^DGCRNS and DISP^DGCRNS to get and display the
names of all current insurance carriers for a Veteran.\n
Until approx. 18 mo. after release of MCCR V2", "", "DGCRNS", ""], ["236", "DBIA236", "Routine", "OUTPATIENT PHARMACY", "1993/06/15", "", "Retired", "Private", "", "
PIMS (MAS) users often have a need to print a Drug
Profile after printing the 10-10. PIMS, therefore, is given permission from
Outpatient Pharmacy to allow PIMS to call the line tag DFN^PSOSD1. This call
allows tasked or non-tasked Drug Profile printout. NOTE: This DBIA has been
replaced by DBIA #1281.", "", "PSOSD1", ""], ["237", "DBIA237-A", "Routine", "OUTPATIENT PHARMACY", "1993/06/15", "APPROVED", "Active", "Private", "", "
Integrated Billing is given permission from Outpatient
Pharmacy to call HD^PSOSD2 and PAT^PSOSD for the purpose of printing the
Action Profile and the Information Profile in batch.\n
CONDITIONS: The entry points may only be used in an approved fashion. The
following subroutine uses the entry points in an acceptable manner:\n
RXPROF ;For printing the Outpatient Pharmacy Action Profile or the
;Information Profile for a single patient whose DFN is defined.
;Does not ask for the device nor close the device.
;INPUTS:
;PSDAYS = number of days to print the medication profile for
;PSTYPE=1 for the Action Profile, =0 for the Information Profile
;DFN
;
N IBDFN,ADDR,ADDRFL,CLASS,CNDT,DRUG,HDFL,I,II,J,L,LINE,P,PAGE,
PSDOB,PSII X,PSNAME,PSOI,PSSN,PSIX,PGM,PRF,PSDATE,VAL,VAR,RX,
RX0,RX2,ST,ST0,PSDAY,RF,RFS,PSOPRINT,X1,X2,ZTSK,X,Y,PSII,PSDT,LMI
S IBDFN=DFN
S X1=DT,X2=-PSDAYS D C^%DTC S (PSDATE,PSDAY)=X
S LINE="" F I=1:1:132 S LINE=LINE_"-"
S PAGE=1
D HD^PSOSD2,PAT^PSOSD
W @IOF
S DFN=IBDFN
Q\n\n", "", "PSOSD2", ""], ["238", "DBIA238-A", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1993/06/15", "APPROVED", "Active", "Private", "70", "\n\n
Radiology has agreed for AMIE to make the following calls:\n
GLOBAL REF. NODE;PIECE USAGE\n
^RADPT 0 Zero node check", "", "", ""], ["239", "DBIA239-A", "File", "MAILMAN", "1993/06/15", "APPROVED", "Active", "Private", "4.3", "", "", "", ""], ["240", "DBIA240-A", "File", "LAB SERVICE", "1993/06/15", "APPROVED", "Active", "Private", "63", "
Laboratory Package has given permission to AMIE to make
the following calls:\n
GLOBAL REF. NODE;PIECE USAGE\n
^LR( "CH";11 Current Agreement number 95
"MI";11 Current Agreement number 95", "", "", ""], ["241", "DBIA241-A", "File", "KERNEL", "1993/06/15", "APPROVED", "Active", "Private", "4", "", "", "", ""], ["242", "DBIA242-A", "Routine", "HEALTH SUMMARY", "1993/06/15", "APPROVED", "Active", "Private", "", "
PIMS (MAS) users often have a need to print a Health
Summary after printing the 10-10. PIMS, therefore, is given permission for a
database integration agreement with Health Summary to allow PIMS to call the
line tag ENXQ^GMTSDVR. This call allows tasked or non-tasked Health Summary
printout. Prior to the call, the following two variables will be defined:", "", "GMTSDVR", ""], ["244", "AMIE Access to Patient File Fields", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Private", "2", "\n\n
ALL FIELDS ACCESSIBLE TO AMIE THROUGH THIS AGREEMENT ARE BASED ON FILEMAN
CALLS ONLY.\n
AMIE has permission from PIMS to make the following calls:\n
GLOBAL REF. NODE;PIECE USAGE\n
^DPT( .11;1 Street address line 1
.11;2 Street address line 2
.11;3 Street address line 3
.11;4 City
.11;5 State
.11;6 Zip Code
.11;7 County
.11;8 Province
.11;9 Postal Code
.11;10 Country
.11;12 Zip+4
.13;1 Residence PhoneNumber
.13;2 Work Phone Number
.29;1 Date Ruled Incompetent (VA)
.29;2 Date Ruled Incompetent(CIVIL)
.29;12 Rated Incompetent
.3;1 Service Connected
.31;2 Claim Folder Location
.31;3 Claim Number
.32;4 Service Discharge Type [LAST]
.32;5 Service Branch [LAST]
.32;6 Service Entry Date [LAST]
.32;7 Service Separation Date [LAST]
.36;1 Primary Eligibility Code
.36;2 Eligibility Status Date
.361;1 Eligibility Status
.362;12 Receiving A&A Benefits
.372;1 Rated Disabilities VA
.372;2 Disability Percentage
.372;3 Service Connected
"DIS"; Disposition Log-in Date
"S";1 Appointment Clinic
"S";16 Appointment Type\n
Directly edits the following fields in the Patient file:\n
.02 SEX
.03 DOB
.09 SSN
.111 Street Address 1
.1112 ZIP+4
.112 Street Address 2
.113 Street Address 3
.114 City
.115 State
.116 Zip Code
.117 County
.1171 Province
.1172 Postal Code
.1173 Country
.131 Phone Number Res.
.132 Phone Number Work
.301 Service Connected
.302 Ser. Con. Percentage
.313 Claim Number
.312 Claim Folder Location
.323 Period of Service
.324 Service Discharge Type [LAST]
.325 Service Branch [LAST]
.326 Service Entry Date [LAST]
.327 Service Separation Date [LAST]
.3611 Eligibility Status
.361 Primary Eligibility Code
.525 POW Status Indicated
.3612 Elig. Status Dat
1901 Veterab Yes/No\n
-Editing of the permanent address information
.111;.1112;.112;.113;.114;.115;.116; .1112;.117;.1171;.1172; .1173;.131; .132;\n
- Fields .1171, .1172, .1173 (Province, Postal Code, Country) will be set
using FM input template(s)\n
-AMIE also has LAYGO access to the Patient file per agreement with the MAS
SIUG.\n
Following release of patch DG*5.3*797, AMIE/CAPRI will use FileMan to edit the
following fields of File 2, Subfile .3216, Military Service Episode multiple:\n
.01 Service Entry Date .02 Service Separation Date .03
Service Branch .06 Service Discharge Type", "", "", "2010/12/08"], ["245", "DBIA245", "Other", "IFCAP", "1993/06/28", "APPROVED", "Active", "Private", "", "
Engineering version 7.0 has permission to export the
following:\n
FILE 446.4 BARCODE PROGRAM with two entries (ENNX and ENPM)
FILE 446.6 SPECIALTY COMMANDS with one entry (TRAKKER 9440)\n
These files and entries are necessary for uploading equipment
data from portable bar code readers into the Engineering
database.\n", "", "", ""], ["246", "DBIA246", "Other", "IFCAP", "1993/06/28", "APPROVED", "Active", "Private", "", "\n
Version 4.0 of IFCAP will call an Engineering routine whenever
an Engineering work order is entered into the SORT GROUP of a
Control Point Activity Transaction (Field 49 of File 410). The
effect of this call will be to enter a pointer to the Control
Point Activity Transaction in the Work Order File and to
update the work order status.\n
MUMPS cross-reference AR on Field 49 of File 410 will call
ACCX^ENLIB2. Before calling this foreign routine, the IFCAP
cross-reference will make sure that ^ENG("VERSION") is greater
than 6.4. This insures the existence of the foreign routine.\n", "", "", ""], ["247", "DBIA247", "File", "MAILMAN", "1991/12/01", "", "Retired", "Private", "3.9", "
Refenences to the MESSAGE File (3.9)\n
^XMB(3.9,i,0) Field .01 Subject
^XMB(3.9,i,2,j,0) Field 3 Text", "", "", ""], ["248", "DBIA248", "File", "MAILMAN", "1991/12/01", "APPROVED", "Active", "Controlled Subscription", "4.2", "
ROES acesses the following entities in Kernel:\n
1) DOMAIN - DIC 4.2
^DIC(4.2,i,0) Field .01 Name\n
(Cross-reference)
^DIC(4.2,"B",NAME,i) Name\n
2) KERNEL SITE PARAMETERS - DIC 4.3
^XMB(1,1,0) Field .01 Domain Name\n
3) SECURITY KEY - DIC 19.1
(Cross-reference)
^XUSEC(KEY,DUZ) Field 2 Holder", "", "", ""], ["249", "DBIA249", "Other", "EVENT CAPTURE", "1992/02/01", "APPROVED", "Active", "Private", "", "
Kernel is adding the field "COORDINATOR' to the
Service/Section File. It will be field 16000 located at node 16000.
The field will be exported with Kernel V7 in a post-init, and the entire
file for a 'virgin' install.", "", "", ""], ["250", "DBIA250", "File", "SURGERY", "1993/07/20", "APPROVED", "Active", "Private", "130", "
Occurrence Screen has permission from Surgery to make
the following calls:\n
Cross References on file 130:
AC - DATE OF OPERATION
ADT - DATE OF OPERATION\n
Fields: subscript;piece
130,.01 PATIENT
130,.011 IN/OUT-PATIENT STATUS (0;12)
130,.03 MAJOR/MINOR (0;3)
130,.09 DATE OF OPERATION (0;9)
130,10 SCHEDULED START TIME (31;4)", "", "", ""], ["251", "DBIA251-A", "File", "KERNEL", "1993/07/20", "APPROVED", "Active", "Private", "3.5", "
Clinical Monitoring System and Kernel have entered into
an agreement for access to the following data: The "B" cross-reference of the
device file. (To check that a free- text pointer value is still valid.)", "", "", ""], ["252", "DBIA252-A", "File", "LAB SERVICE", "1993/07/20", "APPROVED", "Active", "Private", "69", "
Cross References on file 69 - LAB ORDER ENTRY
AN - DATE/TIME RESULTS AVAILABLE", "", "", ""], ["253", "DBIA253-A", "File", "HEALTH SUMMARY", "1993/07/26", "APPROVED", "Active", "Controlled Subscription", "142", "
Integrated Billing has permission from Health Summary
to make the following calls:\n
1) Permission to do lookups on the HEALTH SUMMARY TYPE file (# 142) and to
store the IEN in an Integrated Billing file.\n
2) If ENX^GMTSDVR does not exist (version 2.5 or latter not installed),
permission to print Health Summaries by:\n
a) Accessing the file HEALTH SUMMARY TYPE (# 142), fields NAME (# .01) and
TITLE (# .02), to obtain the title to be used.", "", "", ""], ["254", "DBIA254", "File", "OUTPATIENT PHARMACY", "1993/07/26", "APPROVED", "Active", "Private", "52", "
Drug Accountability has permission from Outpatient
Pharmacy for the following:\n
To collect dispensing data, the Drug Accountability ^PSAOP* routines loop
through the "AL" (original & refills), "AJ" (return to stock), "AM" & "AN"
(partials), and "AR" (status) x-refs in the PRESCRIPTION (#52) file. A
date/time is stored as a starting point for each drug. Using these x-refs,
the 6th piece of ^PSRX(D0,0) is checked to see if the drug is stocked in a
Drug Accountability location and the 9th piece of ^PSRX(D0,2) is checked for
Outpatient site. Quantity for original prescriptions, the 7th piece of
^PSRX(D0,0) is used. For refills, the 4th piece of ^PSRX(D0,1,D1,0) is used.
For partials, the 4th piece of ^PSRX(D0,P,D1,0) is used.\n
GLOBAL MAP DATA DICTIONARY #52 -- PRESCRIPTION FILE STORED IN ^PSRX(
(VERSION 6.0)
--------------------------------------------------------------\n
CROSS REFERENCED BY: RETURNED TO STOCK(AJ),RETURNED TO STOCK(AJ1) RELEASED
DATE/TIME(AL), RELEASED DATE/TIME(AL1), RELEASED DATE/TIME(AM), RETURNED TO
STOCK(AN),\n
^PSRX(D0,0)= (#.01) RX # [1F] ^ (#6) DRUG [6P] ^ (#7) QTY [7N]
^PSRX(D0,1,0)=^52.1DA^^ (#52) REFILL ^PSRX(D0,1,D1,0)=^ (#1) QTY [4N] ^ (#14)
RETURNED TO STOCK[16D]
==>^ (#17) RELEASED DATE/TIME [18D] ^PSRX(D0,2)=^(#20) DIVISION
[9P] ^(#31) RELEASED DATE/TIME[13D]
==>^ (#32.1) RETURNED TO STOCK[15D] ^ ^PSRX(D0,P,0)=^52.2DA^^ (#60)
PARTIAL DATE ^PSRX(D0,P,D1,0)=^(#.04) QTY [4N] ^(#5)RETURNED TO STOCK [16D]
==>^ (#8) RELEASED DATE/TIME [19D] ^", "", "", ""], ["255", "DBIA255", "File", "1", "1993/07/28", "APPROVED", "Active", "Private", "", "
IVM is granted permission from FM Integration to make
the following calls:\n
Permission to add cross-references to the PATIENT file. The cross- references
have set and kill logic as follows:\n
S IVMX=X,X="IVMPXFR" X ^%ZOSF("TEST") D:$T DPT^IVMPXFR S X=IVMX K IVMX\n
The code in IVMPXFR looks as follows:\n
DPT ; Update transmit status if patient file fields are updated
;
N DFN
S DFN=+DA I '$D(^DPT(DFN,0)) Q
D IVM
Q
;
IVM ; check to see if patient needs to be retransmitted
N DA,I,NODE,X
Q:'$D(^IVM(301.5,"B",DFN))
F DA=0:0 S DA=$O(^IVM(301.5,"B",DFN,DA)) Q:'DA D
.S X=$G(^IVM(301.5,DA,0))
.S $P(^IVM(301.5,DA,0),"^",3)=0
.F I=0:0 S I=$O(^DD(301.5,.03,1,I)) Q:'I I $G(^(I,0))'["TRIGGER" D
..S X=1 X ^DD(301.5,.03,1,I,2) ; kill xfr
..S X=0 X ^DD(301.5,.03,1,I,1) ; set xfr
Q\n
Permission is also given to execute the DD nodes. At this point, there is a
single MUMPS cross-reference on the .03 field (TRANSMISSION STATUS) of the IVM
PATIENT file (301.5). Its logic is:\n
set I X=0 S ^IVM(301.5,"ATR",0,DA)=""
kill I X=0 K ^IVM(301.5,"ATR",0,DA)\n
The purpose is just to flag the record as needing to be transmitted and have
the cross-reference only set for those that require transmission.", "", "", ""], ["256", "DBIA256", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "1993/07/28", "APPROVED", "Active", "Private", "", "
Health Summary has permission to add the "GMTS"
application group to file 71, Radiology Procedures, in order to allow
selection of specific procedures to be displayed by the Selected Radiology
Component of Health Summary. Only verified results may be printed, although
results with the report status Released/Unverified may be viewed through
Health Summary. Unverified reports may not be viewed or printed through
Health Summary, in compliance with the Radiology Package's specifications.\n\n", "", "", ""], ["257", "DBIA257", "Routine", "INTEGRATED BILLING", "1993/07/28", "APPROVED", "Active", "Private", "", "
IVM is given permission from IB to use the following
code (routine IVMUFNC):\n
N DGCRINDT,DGCRINS,IBINDT,IBINS,X
S X="IBCNS" X ^%ZOSF("TEST") I $T S:$G(IVMDT) IBINDT=IVMDT D ^IBCNS G
IN SQ ; for IB 2.0 and higher
S X="DGCRNS" X ^%ZOSF("TEST") I $T S:$G(IVMDT) DGCRINDT=IVMDT D
^DGCRNS ; remove when IB 2.0 is required INSQ Q
$S($D(IBINS):IBINS,$D(DGCRINS):DGCRINS,1:"")\n
IVM needs this code to determine whether the patient has insurance. If he
does not, he is automatically sent to IVM for verification.\n", "", "IBCNS", ""], ["258", "DBIA258", "Other", "RECORD TRACKING", "1993/07/28", "APPROVED", "Active", "Private", "", "
The Scheduling package of PIMS v5.3 is granted
permission by the Record Tracking package for the following:\n
1. Permission to access following options:
o RT MAS-CHART-PROFILE -- Profile of Charts
o RT MAS-CHART-REQUEST -- Chart Request
o RT MAS-FILL-NEXT -- Fill Next Clinic Request
o RT MAS-RE-CHARGE -- Re-charge a Chart\n
2. The above options will be available under 'Appointment Management' option
only if the MAS INTERFACE STATUS field of the OVERALL PARAMETERS entry in the
RECORD TRACKING SYSTEM PARAMETERS file is set to 'UP'.\n
The following check will be made:
IF +$G(^DIC(195.4,1,"UP")...\n", "", "", ""], ["259", "DBIA259", "Routine", "IFCAP", "1993/08/03", "APPROVED", "Active", "Controlled Subscription", "", "
Drug Accountability, V2.0, has established agreement
with IFCAP to make the following calls:\n
IFCAP inventory provides a Primary Inventory Point with the SPECIAL INVENTORY
POINT TYPE = "D" for Drug Accountability, the ability to update a Drug
Accountability Location with all receiving activity. IFCAP has added two new
fields to the INVENTORY ITEM multiple in the GENERIC INVENTORY file (#445),
the DISPENSING UNIT and DISPENSING UNIT CONV FACTOR.\n
Each item that a Primary Inventory Point receives, the IFCAP routines
PRCPPOL1, PRCPWPL4, PRCPWPP3, and PRCPUUIW call EN^PSAGIP to update drug
accountability. It is here that Drug Accountability is called (EN^PSAGIP)
passing the Primary Inventory Point, the item, the quantity*dispensing unit
conv factor, the PO#, the CP transaction #, the inventory transaction #, and
the total price and in some cases the NDC. Drug Accountability adds each item
received to a temporary global. After the receipt is processed, the IFCAP
routines PRCPAWI1, PRCPPOL1, PRCPWPL5, and PRCPWPP3 call EX^PSAGIP to complete
the drug accountability update. At this time a task is started, looping
through the temporary global and either updating the Drug Accountability
Location or building and sending a mailman message listing those items that
could not be updated and why. In version 2.0 of Drug Accountability the cost
center screen on the Primary Inventory pointer in the DRUG ACCOUNTABILITY
STATS file (#58.8) has been replaced with the "D" for special inventory type.
Also the IFCAP security variable, PRCPPRIV is used to enable this pointer.\n
^DD(58.8445,.01,0) = PRIMARY INVENTORY POINT(S)^M*P445'X ^PRCP(445,^0;1^S
PRCPPRIV=1,DIC("S")="I $P(^(0),U,20)=""D""" D ^DIC K DIC S DIC=DIE,X=+Y K
PRCPPRIV K:Y<0 X S:$D(X) DINUM=X\n
Wherever available, calls to IFCAP extrinsics have replaced Drug
Accountability version 1.0 look-ups to ^PRC globals. The IFCAP inventory
routine PRCPUX1 is called extensively throughout the Drug Accountability
package at the following line tags:\n
UNITVAL(V1,V2,V3) ; unit per issue for values passed as follows
; v1=packaging multiple, v2=units da,
; v3=delimiter;\n
UNITCODE(V1) ; get 2 character unit code from file 420.5
; for entry v1;\n
NSN(V1) ; return nsn for item v1;\n
DESCR(V1,V2) ; description from inventory point or item
; master file for item v2 and inventory point
; v1;\n
INVNAME(V1) ; inventory point name for inventory point v1;\n
VENNAME(V1) ; return vendor name for da;global (445 or
; 440).\n", "", "PRCPUX1", ""], ["260", "DBIA260", "File", "REGISTRATION", "1993/08/09", "APPROVED", "Active", "Private", "2", "\n
REQUEST: "ARCDTH" CROSS-REFERENCE ON
DATE OF DEATH FIELD IN PATIENT
FILE\n\n
FILE NUMBER: 2
FILE NAME: PATIENT
FIELD NUMBER: .351
FIELD NAME: DATE OF DEATH
CROSS REF NUM: 7 CROSS REF NAME: "ARCDTH"
TYPE: MUMPS
NOT USED FOR SORTING OR LOOKUP\n\n
SET STATEMENT: S RCX=X,X="RCAMDTH" X ^%ZOSF("TEST") S X=RCX K RCX I D
SET^RCAMDTH\n\n
KILL STATEMENT: S RCX=X,X="RCAMDTH" X ^%ZOSF("TEST") S X=RCX K RCX I D
ERR^RCAMDTH\n\n
NO-DELETION MESSAGE: ACCOUNTS RECEIVABLE DEATH NOTIFICATION\n\n
DESCRIPTION: This cross-reference is used to notify the Accounts Receivable
package (v4 or higher) of a patient's death so that the patient's account may
be reviewed for appropriate action.", "", "", ""], ["261", "DBIA261-A", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The option HBHC Appointment uses the MAS routine ^SDM
as the Run Routine, and employs SDM^SDKILL in the exit action.\n
Select OPTION to edit: HBHC APPOINTMENT Make Appointment NAME: HBHC
APPOINTMENT// MENU TEXT: Make Appointment// PACKAGE: HOSPITAL BASED HOME
CARE// DESCRIPTION:
1>This option utilizes the MAS Scheduling Option, Make Appointment [SDM],
2>for entry of appointment data. The Exit Action on this option runs a
3>routine that creates records in the HBHC Visit File (HBHC(632)) using
4>the appointment data entered. Only data for clinics contained in the
5>HBHC Clinic File (HBHC(631.6)) will be added to the HBHC Visit File.\n
EDIT Option: TYPE: run routine// ENTRY ACTION: D:$T(HDLKILL^SDAMEVT)]""
HDLKILL^SDAMEVT EXIT ACTION: D SDM^SDKILL K ORACTION,ORVP,XQORQUIT W
!!,"Adding entries
to the visit file..." D WAIT^DICD,^HBHCAPPT
D:$T(HDLKILL^SDAMEVT)]"" HDLKILL^SDAMEVT
Replace ROUTINE: SDM//", "", "SDM", ""], ["262", "DBIA262", "Other", "1", "1993/08/09", "APPROVED", "Active", "Private", "", "
DataBase Integration Agreement between IFCAP V4.0
package and FileMan V19.0 for the use of and the KILLing of a local FileMan
variable in an Input Template.\n
The IFCAP Input Template uses the FileMan local variable D1 in the input
transform for field #40 in File #423, the CALM/LOG CODE SHEET file. The local
variable D1 is used as a counter for the multiple field 423.05, subfield .01.
IFCAP uses the counter within the Input Template to ensure that no more than
10 entries are made into the code sheet for this multiple. Prior to prompting
the user for entries into this field, the FileMan variable D1 is KILLed.\n
The reason or reasons for KILLing the FileMan local variable D1 and
subsequently using D1 as a counter have been obscured in the history of IFCAP
development.\n
The variable D1 is the internal record number within the multiple; it is
stored as piece 3 of the file or subfile header. It is not necessarily
accurate as the count of entries within the multiple. For example, the user
may make one or more deletions within the template, reducing the number of
entries. The user could then add more entries to the multiple. This scenario
could possibly increase the internal record number (D1) to a number greater
than 9, when there may actually be fewer than 9 entries. Based on the input
transform, the user would not be able to make the additional entries, although
in reality, more entries should be allowed.\n
In addition, piece 4 of the file or subfile header contains the number of
records in the file and/or subfile. Once again, this number cannot be
guaranteed as the accurate number of records in the file or subfile.\n
The use of D1 is an existing convention that has been in place for several
versions of IFCAP. We request the Integration Agreement with FileMan to
continue this use for IFCAP V4.0.\n
The Input Templates are used in the creation of CALM code sheets. Since FMS
will be replacing CALM, the use of the FileMan local variable will be needed
until all sites have converted from CALM to FMS. The next planned release of
IFCAP V5.0 will replace this function.\n
INTEGRATION POINT:\n
1. The IFCAP Input Template PRCFA TT982.00\n
FIRST EDIT FIELD: .1///CLM//
THEN EDIT FIELD: S Y=4//
THEN EDIT FIELD: STATION NUMBER//
THEN EDIT FIELD: TRANSACTION TYPE//
THEN EDIT FIELD: TRANSACTION DATE//
THEN EDIT FIELD: REFERENCE NUMBER//
THEN EDIT FIELD: YALD CODE//
THEN EDIT FIELD: K D1//
THEN EDIT FIELD: REC STA OR FCP//
THEN EDIT FIELD: REC STA OR FCP//
THEN EDIT FIELD: 1ST QTR AMOUNT//
THEN EDIT FIELD: 2ND QTR AMOUNT//
THEN EDIT FIELD: W !," "//
THEN EDIT FIELD: 3RD QTR AMOUNT//
THEN EDIT FIELD: I X="$" S Y=""//
THEN EDIT FIELD: 4TH QTR AMOUNT//
THEN EDIT FIELD: 998///$//\n
2. The Input Transform Using the FileMan Variable\n
STANDARD DATA DICTIONARY #423.05 -- REC STA OR FCP SUB-FILE 05/20/93
PAGE 1 STORED IN ^PRCF(423, (811
ENTRIES) SITE: IFA UCI: DVA,IFA\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
----------------------------------------------------------------\n
423.05,.01 REC STA OR FCP 0;1 FREE TEXT (Multiply
asked)\n
INPUT TRANSFORM: K:$L(X)>3!($L(X)<3)!'(X?3N) X
Q:'$D(X) I $D(D1),D1>9 W " ONLY
10 ENTRIES PER CODE SHEET ARE
PERMITTED",*7 K X
LAST EDITED: MAR 21, 1986
HELP-PROMPT: ANSWER MUST BE 3 CHARACTERS IN
LENGTH
DESCRIPTION: This is the 3 character receiving
station or fund control point.\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY
PROGRAMMER\n
3. FileMan Local Variable D1\n
When working below the main level of the file, DIE maintains the references to
the file hierarchy being handled in the variables DA and Dn (D0, D1, etc) in
which n varies according to the level of the file hierarchy.\n
DA always contains the item number of the record being handled. Dn indicates
the item numbers in the file hierarchy. D0 contains the main level record
number; D1 contains the first sub-file level sub-record number and D2 contains
the second sub-file level sub-record number.\n", "", "", ""], ["263", "DBIA263-A", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Supported", "", "", "", "VAFHLPID", ""], ["264", "DBIA264", "Other", "KERNEL", "1993/08/10", "APPROVED", "Active", "Private", "", "
VA FileMan has permission to export the Package file
and to update entries in the Package file for exporting and importing
packages.", "", "", ""], ["265", "DBIA265", "File", "SCHEDULING", "1993/08/17", "", "Retired", "Private", "", "\n\n
Clinical Monitoring System and MAS for read access to the following fields and
cross-references.\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
APPOINTMENT DATE/TIME PATIENT
1 1900 2
2 .001 2.98\n
APPOINTMENT STATUS PATIENT
1 1900 2
2 3 2.98\n
PURPOSE OF VISIT PATIENT
1 1900 2
2 9 2.98\n
APPOINTMENT TYPE PATIENT
1 1900 2
2 9.5 2.98\n
APPT. CANCELLATION REASON PATIENT
1 1900 2
2 16 2.98\n
CLINIC PATIENT
1 1900 2
2 .01 2.98\n
(The above fields related to field 1900 will be eliminated with the scheduling
redesign.)\n
COVERED BY HEALTH INSURANCE? PATIENT
1 .3192 2\n
DATE OF DEATH PATIENT
1 .351 2\n
DISPOSITION PATIENT
1 1000 2
2 6 2.101\n
LOG IN DATE/TIME PATIENT
1 1000 2
2 .01 2.101\n
LOG IN STATUS PATIENT
1 1000 2
2 1 2.101\n
LOG OUT DATE/TIME PATIENT
1 1000 2
2 5 2.101\n
REASON FOR LATE DISPOSITION PATIENT
1 1000 2
2 8 2.101\n
SERVICE CONNECTED PERCENTAGE PATIENT
1 .302 2\n
SERVICE CONNECTED? PATIENT
1 .301 2\n
SPINAL CORD INJURY PATIENT
1 57.4 2\n
TYPE OF BENEFIT APPLIED FOR PATIENT
1 1000 2
2 2 2.101\n
TYPE OF CARE APPLIED FOR PATIENT
1 1000 2
2 2.1 2.101\n
TYPE OF MOVEMENT PATIENT MOVEMENT
1 .04 405\n
WARD LOCATION PATIENT MOVEMENT
1 .06 405\n
TRANSACTION TYPE PATIENT MOVEMENT
1 .02 405\n
ROOM-BED PATIENT MOVEMENT
1 .07 405\n
ADMITTED FOR SC CONDITION? PATIENT MOVEMENT
1 .11 405\n
ADMITTING REGULATION PATIENT MOVEMENT
1 .12 405\n
ATTENDING PHYSICIAN PATIENT MOVEMENT
1 .19 405\n
DIAGNOSIS [SHORT] PATIENT MOVEMENT
1 .1 405\n
FACILITY TREATING SPECIALTY PATIENT MOVEMENT
1 .09 405\n
MAS MOVEMENT TYPE PATIENT MOVEMENT
1 .18 405\n
MOVEMENT DATE/TIME PATIENT MOVEMENT
1 .01 405\n
PRIMARY CARE PHYSICIAN PATIENT MOVEMENT
1 .08 405\n
PATIENT PTF
1 .01 45\n
PTF ADMISSION DATE PTF
1 2 45\n
PTF DISCHARGE DATE PTF
1 70 45\n
PTF DISCHARGE SPECIALTY PTF
1 71 45\n
PTF DRG PTF
1 9 45\n
PTF DXLS PTF
1 79 45\n
PTF ICD 10 PTF
1 79.24 45\n
PTF ICD 2 PTF
1 79.16 45\n
PTF ICD 3 PTF
1 79.17 45\n
PTF ICD 4 PTF
1 79.18 45\n
PTF ICD 5 PTF
1 79.19 45\n
PTF ICD 6 PTF
1 79.201 45\n
PTF ICD 7 PTF
1 79.21 45\n
PTF ICD 8 PTF
1 79.22 45\n
PTF ICD 9 PTF
1 79.23 45\n
PTF PROCEDURE 1 PTF
1 45.01 45\n
PTF PROCEDURE 2 PTF
1 45.02 45\n
PTF PROCEDURE 3 PTF
1 45.03 45\n
PTF PROCEDURE 4 PTF
1 45.04 45\n
PTF PROCEDURE 5 PTF
1 45.05 45\n
PTF TYPE OF DISPOSITION PTF
1 72 45\n
PTF WARD AT DISCHARGE PTF
1 2.2 45\n
SURGERY/PROCEDURE DATE PTF
1 401 45
2 .01 45.01\n
OPERATION CODE 1 PTF
1 401 45
2 8 45.01\n
OPERATION CODE 2 PTF
1 401 45
2 9 45.01\n
OPERATION CODE 3 PTF
1 401 45
2 10 45.01\n
OPERATION CODE 4 PTF
1 401 45
2 11 45.01\n
OPERATION CODE 5 PTF
1 401 45
2 12 45.01\n
MAS MOVEMENT TRANSACTION TYPE MAS MOVEMENT TRANSACTION TYPE
1 .01 405.3\n
NAME DISPOSITION
1 .01 37\n
NAME FACILITY TREATING SPECIALTY
1 .01 45.7\n
FACILITY TREATING SPECIALTY SERVICE
1 2 45.7\n
NAME MAS MOVEMENTT TYPE
1 .01 405.2\n
NAME APPOINTMENT TYPE
1 .01 409.1\n
CODE NUMBER ICD DIAGNOSIS
1 .01 80\n
CODE NUMBER ICD OPERATION/PROCEDURE
1 .01 80.1\n
PATIENT HOSPITAL LOCATION
1 1900 44
2 2 44.001
3 .01 44.003\n\n
CROSS REFERENCES:\n
DATE OF BIRTH PATIENT\n
XREF: ADOB\n
SEX PATIENT\n
XREF: ASX\n
DATE OF ENROLLMENT PATIENT\n
XREF: AEB\n
DATE OF DEATH PATIENT\n
XREF: AEXP1\n
LOG IN DATE/TIME PATIENT\n
XREF: ADIS\n
DATA GLOBAL HOSPITAL LOCATION\n
XREF: ^SC(D0,"S",D1,1,D2,...
^ ^
| |-- PATIENT
|-- APPOINTMENT\n
CLOSE OUT DATE PTF CLOSE OUT\n
XREF: AC\n
DATA GLOBAL PTF\n
XREF: ^DGPT(D0,"S",D1,...
^
|-- SURGERY/PROCEDURE DATE\n\n", "", "", ""], ["266", "LIST TEMPLATE FILE", "Other", "SCHEDULING", "1993/08/25", "APPROVED", "Active", "Supported", "409.61", "
The List Template file 409.61 may be populated with
entries that are namespaced (following the same principles as with the Option
file). Refer to List Manager documentation for current export utilities.
Entries should not be made to this file other than through VA FileMan and the
export utilities.", "", "", ""], ["267", "DBIA267", "Other", "KERNEL", "1993/08/25", "APPROVED", "Active", "Private", "", "
The PDX team is granted permission to add the following
protocols to the protocol file ^ORD(101. We also request permission to use
all generic protocols as listed in the List Managers development guide. The
protocol names are:
1 VAQ ADD PATIENT Add Patient
2 VAQ ADD/EDIT REQUEST Add/Edit Request
3 VAQ CHANGE PATIENT Change Patient
4 VAQ COPY REQUEST Copy Request
5 VAQ CREATE REATE REQUEST Create Request
6 VAQ DIS ALL SEGMENT Display all
7 VAQ DIS SELECTED SEG Display Selected
8 VAQ DIS1 (MENU) List Request Options
9 VAQ DISPLAY PDX Display PDX
10 VAQ DISPLAY SELECT Select Entry
11 VAQ DUPLICATE Select Entry
12 VAQ LOAD DATA Load Data (all)
13 VAQ LOAD EDIT Load/Edit
14 VAQ LOAD FIELD Load Field(s)
15 VAQ NEW PATIENT New Patient
16 VAQ PDX1 (MENU) CUSTOM ENTRIES FOR PDX1
17 VAQ PDX11 (MENU) MENU FOR DISPLAY SEGMENT
18 VAQ PDX12 (MENU) MENU OPTIONS FOR PDX DISPLAY
19 VAQ PDX2 (MENU) CUSTOM ENTRIES FOR PDX2
20 VAQ PDX3 (MENU) custom entries for PDX3
21 VAQ PDX4 (MENU) VAQ PDX4 MANUAANUAL PROCESS
22 VAQ PDX5 (MENU) VAQ LED STATUS MENU
23 VAQ PDX6 (MENU) VAQ LED DIFFERENCES MENU
24 VAQ PDX7 (MENU) VAQ LED ADD PT MENU
25 VAQ PDX8 (MENU) VAQ LED POSSIABLE MATCH MENU
26 VAQ PDX9 (MENU) OPTIONS MENU FOR PDX REQUEST
27 VAQ PROCESS MANUAL Procecess Manual
28 VAQ PROCESS REJECT Reject W/Comment
29 VAQ PROCESS RELEASE Release W/Comment
30 VAQ TRANSMIT REQUEST Transmit Request", "", "", ""], ["268", "DBIA268-A", "File", "REGISTRATION", "1993/08/25", "APPROVED", "Active", "Private", "2", "
The PDX team has permission to access the MAS Duplicate
Checker, DPTDUP. This routine will be used as a filter in adding new or
selecting existing patients.\n
The following fields are accessed by PDX for extract, display, edit and load.\n
[ MINIMAL ] Following is a list of fields used when creating a new
patient. Note: Temporary address is only filled in if
active and dates valid.\n
FILE NO. FIELD NO NONODE;PIECE DESCRIPT
2 .01 0;1 NAME
.02 0;2 SEX
.03 0;3 DATE OF BIRTH
.05 0;5 MARITAL STATUS
.08 0;8 RELIGIOUS PREFERENCE
.09 0;9 SOCIAL SECURITY NUMBER
.111 .11;1 STREET ADDRESS [LINE 1]
.112 .11;2 STREET ADDRESS [LINE 2]
.113 .11;3 STREET ADDRESS [LINE 3]
.114 .11;4 CITY
.115 .11;5 STATE
.116 .11;6 ZIP CODE
.117 .11;7 COUNTY
.131 .13;1 PHONE NUMBER [RESIDENCE]
.301 .3;1 SERVICE CONNECTED?
.302 .3;2 SERVICE CONNECTED PERCENTAGE
.323 .32;3 PERIOD OF SERVICE
.361 .36;1 PRIMARY ELIGIBILITY CODE
391 TYPE;1 TYPE
1901 VET;1 VETERAN (Y/N)?
.12105 .121;9 TEMPORARY ADDRESS ENTER/EDIT?
.1211 .121;1 TEMPORARY STREET [LINE 1]
.12111 .121;11 TEMPORARY ADDRESS COUNTY
.12112 .121;12 TEMPORARY ZIP+4
.1212 .121;2 TEMPORARY STREET [LINE 2]
.1213 .121;3 TEMPORARY STREET [LINE 3]
.1214 .121;4 TEMPORARY CITY
.1215 .121;5 TEMPORARY STATE
.1216 .121;6 TEMPORARY ZIP CODE
.1217 .121;7 TEMPORARY ADDRESS START DATE
.1218 .121;8 TEMPORARY ADRESS END DATE
.1219 .121;10 TEMPORARY PHONE NUMBER\n
[ MAS ] Following is the list of the MAS fields PDX extracts. These
fields are compared agianst the local database and the
differences are displayed. The user is given the choice to
update the local data with the PDX data. (Read/Write Access)\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2 .01 0;1 NAME
.02 0;2 SEX
.03 0;3 DATE OF BIRTH
.05 0;5 MARITAL STATUS
.07 0;7 OCCUPATION
.08 0;8 RELIGIOUS PREFERENCE
.09 0;9 SOCIAL SECURITY NUMBER
.091 0;10 REMARKS
.092 0;11 PLACE OF BIRTH [CITY]
.093 0;12 PLACE OF BIRTH [STATE]
.111 .11;1 STREET ADDRESS [LINE 1]
.112 .11;2 STREET ADDRESS [LINE 2]
.113 .11;3 STREET ADDRESS [LINE 3]
.114 .11;4 CITY
.115 .11;5 STATE
.116 .11;6 ZIP CODE
.117 .11;7 COUNTY
.1211 .121;1 TEMPORARY STREET [LINE 1]
.1212 .121;2 TEMPORARY STREET [LINE 2]
.1213 .121;3 TEMPORARY STREET [LINE 3]
.1217 .121;7 TEMPORARY ADDRESS START DATE
.1218 .121;8 TEMPORARY ADDRESS END DATE
.1219 .121;10 TEMPORARY PHONE NUMBER
.131 .13;1 PHONE NUMBER [RESIDENCE]
.132 .13;2 PHONE NUMBER [WORK]
.152 .15;2 INELIGIBLE DATE
.153 .15;3 MISSING PERSON DATE
.1651 INE;1 INELIGIBLE TWX SOURCE
.1653 INE;3 INELIGIBLE TWX CITY
.1654 INE;4 INELIGIBLE TWX STATE
.1656 INE;6 INELIGIBLE VARO DECISION
.1657 INE;7 MISSING PERSON TWX SOURCE
.1658 INE;8 MISSING PERSON TWX CICITY
.1659 INE;9 MISSING PERSON TWX STATE
.211 .21;1 K-NAME OF PRIMARY NOK
.212 .21;2 K-RELATIONSHIP TO PATIENT
.213 .21;3 K-STREET ADDRESS [LINE 1]
.214 .21;4 K-STREET ADDRESS [LINE 2]
.215 .21;5 K-STREET ADDRESS [LINE 3]
.216 .21;6 K-CITY
.217 .21;7 K-STATE
.218 .21;8 K-ZIP CODE
.219 .21;9 K-PHONE NUMBER
.2191 .211;1 K2-NAME OF SECONDARY NOK
.2192 .211;2 K2-RELATIONSHIP TO PATIENT
.2193 .211;3 K2-STREET ADDRESS [LINE 1]
.2194 .211;4 K2-STREET ADDRESS [LINE 2]
.2195 .211;5 K2-STREET ADDRESS [LINE 3]
.2196 .211;6 K2-CITY
.2197 .211;7 K2-STATE
.2198 .211;8 K2-ZIP CODE
.2199 .211;9 K2-PHONE NUMBER
.2401 .24;1 FATHER'S NAME
.2402 .24;2 MOTHER'S NAME
.2403 .24;3 MOTHER'S MAIDEN NAME
.251 .25;1 SPOUSE'S EMPLOYER NAME
.252 .25;2 SPOUSE'S EMP STREET [LINE 1]
.253 .25;3 SPOUSE'S EMP STREET [LINE 2]
.254 .25;4 SPOUSE'S EMP STREET [LINE 3]
.255 .25;5 SPOUSE'S EMPLOYER'S CITY
.256 .25;6 SPOUSE'S EMPLOYER'S STATE
.257 .25;7 SPOUSE'S EMP ZIP CODE
.258 .25;8 SPOUSE'S EMP PHONE NUMBER
.301 .3;1 SERVICE CONNECTED?
.302 .3;2 SERVICE CONNECTED PERCENTAGE
.3025 .3;11 RECEIVING VA DISABILITY?
.303 .3;3 AMOUNT OF VA DISABILITY
.306 .3;6 MONETARY BEN. VERIFY DATE
.307 .3;7 INELIGIBLE REASON
.3111 .311;1 EMPLOYER NAME
.31115 .311;15 EMPLOYMENT STATUS
.3112 .311;2 GOVERNMENT AGENCY
.3113 .311;3 EMPLOYER STREET [LINE 1]
.3114 .311;4 EMPLOYER STREET [LINE 2]
.3115 .311;5 EMPLOYER STREET [LINE 3]
.3116 .311;6 EMPLOYER CITY
.3117 .311;7 EMPLOYER STATE
.3118 .311;8 EMPLOYER ZIP CODE
.3119 .311;9 EMPLOYER PHONE NUMBER
.312 .31;2 CLAIM FOLDER LOCATION
.313 .31;3 CLAIM NUMBER
.32101 .321;1 VIETNAM SERVICE INDICATED?
.32102 .321;2 AGENT ORANGE EXPOS. INDICATED?
.32103 .321;3 RADIATION EXPOSURE INDICATED?
.32104 .321;4 VIETNAM FROM DATE
.32105 .321;5 VIETNAM TO DATE
.32107 .321;7 AGENT ORANGE REGISTRATION DATE
.32109 .321;9 AGENT ORANGE EXAM DATE
.3211 .321;10 AGENT ORANGE REGISTRATION #
.32111 .321;11 RADIATION REGISTRATION DATE
.3212 .321;12 RADIATION EXPOSURE METHOD
.322 .32;2 SERVICE VERIFICATION DATE
.323 .32;3 PERIOD OF SERVICE
.324 .32;4 SERVICE DISCHARGE TYPE [LAST]
.325 .32;5 SERVICE BRANCH [LAST]
.326 .32;6 SERVICE ENTRY DATE [LAST]
.327 .32;7 SERVICE SEPARATION DATE [LAST]
.328 .32;8 SERVICE NUMBER [LAST]
.329 .32;9 SERVICE DISCHARGE TYPE [NTL]
.3291 .32;10 SERVICE BRANCH [NTL]
.3292 .32;11 SERVICE ENTRY DATE [NTL]
.3293 .32;12 SERVICE SEPARATION DATE [NTL]
.3294 .32;13 SERVICE NUMBER [NTL]
.3295 .32;14 SERVICE DISCHARGE TYPE [NNTL]
.3296 .32;15 SERVICE BRANCH [NNTL]
.3297 .32;16 SERVICE ENTRY DATE [NNTL]
.3298 .32;17 SERVICE SEPARATION DATE [NNTL]
.3299 .32;18 SERVICE NUMBER [NNTL]
.331 .33;1 E-NAME
.3311 .331;1 E2-NAME OF SECONDARY CONTACT
.3312 .331;2 E2-RELATIONSHIP TO PATIENT
.3313 .331;3 E2-STREET ADDRESS [LINE 1]
.3314 .331;4 E2-STREET ADDRESS [LINE 2]
.3315 .331;5 E2-STREET ADDRESS [LINE 3]
.3316 .331;6 E2-CITY
.3317 .331;7 E2-STATE
.3318 .331;8 E2-ZIP CODE
.3319 .331;9 E2-PHONE NUMBER
.332 .33;2 E-RELATIONSHIP TO PATIENT
.333 .33;3 E-STREET ADDRESS [LINE 1]
.334 .33;4 E-STREET ADDRESS [LINE 2]
.335 .33;5 E-STREET ADDRESS [LINE 3]
.336 .33;6 E-CITY
.337 .33;7 E-STATE
.338 .33;8 E-ZIP CODE
.339 .33;9 E-PHONE NUMBER
.341 .34;1 D-NAME OF DESIGNEE
.342 .34;2 D-RELATIONSHIP TO PATIENT
.343 .34;3 D-STREET ADDRESS [LINE 1]
.344 .34;4 D-STREET ADDRESS [LINE 2]
.345 .34;5 D-STREET ADDRESS [LINE 3]
.346 .34;6 D-CITY
.347 .34;7 D-STATE
.348 .34;8 D-ZIP CODE
.349 .34;9 D-PHONE NUMBER
.361 .36;1 PRIMARY ELIGIBILITY CODE
.3611 .361;1 ELIGIBILITY STATUS
.3612 .361;2 ELIGIBILITY STATUS DATE
.3614 .361;4 ELIGIBILITY INTERIM RESPONSE
.3615 .361;5 ELIGIBILITY VERIF. METHOD
.3616 .361;6 ELIGIBILITY STATUS ENTERED BY
.362 .36;2 DISABILITY RET. FROM MILITARY?
.36205 .362;12 RECEIVING A&A BENEFITS?
.3621 .362;1 AMOUNT OF AID & ATTENDANCE
.36215 .362;13 RECEIVING HOUSEBOUND BENEFITS?
.3622 .362;2 AMOUNT OF HOUSEBOUND
.36225 .362;15 RECEIVING SOCIAL SECURITY?
.3623 .362;3 AMOUNT OF SOCIAL SECURITY
.36235 .362;14 RECEIVING A VA PENSION?
.3624 .362;4 AMOUNT OF VA PENSION
.3625 .362;5 AMOUNT OF MILITARY RETIREMENT
.36255 .362;16 RECEIVING MILITARY RETIREMENT?
.3626 .362;6 AMOUNT OF GI INSURANCE
.36265 .362;17 GI INSURANCE POLICY?
.3627 .362;7 AMOUNT OF SSI
.36275 .362;19 RECEIVING SUP. SECURITY (SSI)?
.3628 .362;8 AMOUNT OF OTHER RETIREMENT
.36285 .362;18 TYPE OF OTHER RETIREMENT
.3629 .362;9 AMOUNT OF OTHER INCOME
.368 .36;8 SERVICE DENTAL INJURY?
.369 .36;9 SERVICE TEETH EXTRACTED?
.525 .52;5 POW STATUS INDICATED?
.526 .52;6 POW CONFINEMENT LOCATION
.527 .52;7 POW FROM DATE
.528 .52;8 POW TO DATE
.5291 .52;11 COMBAT SERVICE INDICATED?
.5292 .52;12 COMBAT SERVICE LOCATION
.5293 .52;13 COMBAT FROM DATE
.5294 .52;14 COMBAT TO DATE
57.4 57;4 SPINAL CORD INJURY
391 TYPE;1 TYPE
1010.15 1010.15;5 RECEIVED VA CARE PREVIOUSLY?
1010.151 1010.15;1 MOST RECENT DATE OF CARE
1010.152 1010.15;2 MOST RECENT LOCATION OF CARE
1010.153 1010.15;3 2ND MOST RECENT DATE OF CARE
.21011 .21;11 K-WORK PHONE NUMBER
.211011 .211;11 K2-WORK PHONE NUMBER
.381 .38;1 ELIGIBLE FOR MEDICAID?
.3221 .322;1 LEBANON SERVICE INDICATED?
.3222 .322;2 LEBANON FROM DATE
.3223 .322;3 LEBANON TO DATE
.3224 .322;4 GRENADA SERVICE INDICATED?
.3225 .322;5 GRENADA FROM DATE
.3226 .322;6 GRENADA TO DATE
.3227 .322;7 PANAMA SERVICE INDICATED?
.3228 .322;8 PANAMA FROM DATE
.3229 .322;9 PANAMA TO DATE
.32201 .322;10 PERSIAN GULF SERVICE?
.322011 .322;11 PERSIAN GULF FROM DATE
.322012 .322;12 PERSIAN GULF TO DATE
.322013 .322;13 ENV CONTAM INDICATED?
.322014 .322;14 REGISTRATION DATE
.322015 .322;15 EXAM DATE
.322016 .322;16 SOMALIA SERVICE INDICATED?
.322017 .322;17 SOMALIA FROM DATE
.322018 .322;18 SOMALIA TO DATE
.304 .3;4 P&T
.305 .3;5 UNEMPLOYABLE
.3012 .3;12 SC AWARD DATE
.293 .29;12 RATED INCOMPETENT?
.292 .29;2 DATE RULED INCOMPETENT (CIVIL)
.291 .29;1 DATE RULED INCOMPETENT (VA)
.36205 .362;12 RECEIVING A&A BENEFITS?
.36215 .362;13 RECEIVING HOUSEBOUND BENEFITS?
.36235 .362;14 RECEIVING A VA PENSION?
.3025 .3;11 RECEIVING VA DISABILITY?
.36295 .36295;20 TOTAL ANNUAL VA CHECK AMOUNT\n
.36265 .362;17 GI INSURANCE POLICY?
.3626 .362;6 AMOUNT OF GI INSURANCE\n
.34011 .34;11 D-WORK PHONE NUMBER
.2514 .25;14 SPOUSE'S OCCUPATION
.2515 .25;15 SPOUSE'S EMPLOYMENT STATUS
1010.154 1010.15;4 2ND MOST RECENT LOCATION
1901 VET;1 VETERAN (Y/N)?
.33011 .33;11 E-WORK PHONE NUMBER
.331011 .331;11 E2-WORK PHONE NUMBER
.1112 .11;12 ZIP+4
.12105 .121;9 TEMPORARY ADDRESS ENTER/EDIT?
.12111 .121;11 TEMPORARY ADDRESS COUNTY
.12112 .121;12 TEMPORARY ZIP+4
.382 .38;2 DATE MEDICAID LAST ASKED\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.04 .01 0;1 RATED DISABILITIES (VA)
2 0;2 DISABILITY %
3 0;3 SERVICE CONNECTED\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.001 .01 0;1 ENROLLMENT CLINIC\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.16 .01 0;1 MISSING OR INELIGIBLE\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.01 .01 0;1 ALIAS
1 0;2 ALIAS SSN\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.05 .01 0;1 SERVICE CONNECTED CONDITIONS
.02 0;2 PERCENTAGE\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.101 .01 0;1 LOG IN DATE/TIME
2 0;3 TYPE OF BENEFIT APPLIED FOR
3 0;4 FACILITY APPLYING TO
20 2;1 NEED RELATED TO OCCUPATION
23 2;4 NEED RELATED TO AN ACCIDENT\n
[ ELIGIBILITY ]\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.0361 .01 0;1 ELIGIBILITY\n
[ DENTAL ] Extract the five most recent\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.11 .01 0;1 DATE OF DENTAL TREATMENT
2 0;2 CONDITION
3 0;3 DATE CONDITION FIRST NOTICED\n
[ APPOINTMENT ] Extract the five most recent\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
2.98 .01 0;1 CLINIC
3 0;2 STATUS
9 0;7 PURPOSE OF VISIT
9.5 0;16 APPOINTMENT TYPE\n
The PDX development team has permission to access ^DPT (directly) for the
verification of a valid DFN. This is done extensively through out PDX. Other
places ^DPT is accessed directly.
a) $O thru eligibility multiple
b) $O thru appointments multiple
c) $O thru dental appointments multiple", "", "", ""], ["269", "DBIA269", "File", "AUTO REPLENISHMENT/WARD STOCK", "1993/08/26", "APPROVED", "Active", "Private", "58.1", "
Version 2.0 of Drug Accountability will require
previous installation of Automatic Replenishment/Ward Stock version 2.3. The
^PSGWUAS routine contains a call to ^PSARWS. ^PSARWS will traverse the
^PSI(58.5,"AMIS") x-ref to update the AR/WS dispensing in Drug Accountability.
Using the sixth subscript, a look-up is made to ^PSI(58.1,D0,"SITE") to
determine the Inpatient Site.\n
GLOBAL MAP DATA DICTIONARY #58.1 -- PHARMACY AOU STOCK FILE STORED IN
^PSI(58.1, (1 ENTRY) SITE: BIRMINGHAM ISC (#14)
------------------------------------------------------------\n
^PSI(58.1,D0,SITE)= (#4) INPATIENT SITE [1P] ^", "", "", ""], ["270", "DBIA270-A", "File", "PHARMACY DATA MANAGEMENT", "1993/08/26", "APPROVED", "Active", "Private", "52.6", "
Drug Accountability will use the IV STATS (#50.8) file
to update IV dispensing activity in a Drug Accountability Location. To
correctly identify the DRUG (#50) file entry a look up is first made to the IV
ADDITIVES (#52.6) and/or the IV SOLUTION (#52.7) files. Looping through
^PS(50.8,D0), all IV Rooms are checked. Looping through ^PS(50.8,D0,2,D1),
dates are checked. Looping through ^PS(50.8,D0,2,D1,2,D2), drugs are checked
with support from the "AC" x-ref. Looping through
^PS(50.8,D0,2,D1,2,D2,3,D3), ward is checked. It is here that, if a match
occurs, $P($G(^PS(50.8,D0,2,D1,2,D2,3,D3,0)),U,2)-$P($G(^(0)),U,5) is used to
update the balance in Drug Accountability.\n
GLOBAL MAP DATA DICTIONARY #52.6 -- IV ADDITIVES FILE STORED IN ^PS(52.6, (1
ENTRY) SITE: BIRMINGHAM ISC
------------------------------------------------------------------------
CROSS REFERENCED BY: GENERIC DRUG(AC) ^PS(52.6,D0,0)= (#1) GENERIC DRUG [2P]", "", "", ""], ["271", "DBIA271-A", "Other", "INTEGRATED BILLING", "1993/08/27", "APPROVED", "Active", "Private", "", "
The following routines and file entries will be
exported by PDX with version 1.5:\n
IBAPDX IBAPDX0 IBAPDX1", "", "", ""], ["272", "DBIA272-A", "File", "PATIENT DATA EXCHANGE", "1993/08/27", "APPROVED", "Active", "Private", "394.61", "\n
a) The following fields are referenced by the global directly, NOT
by a fileman call.
- PDX Transaction File (394.61) field # .03 Patient Name", "", "", ""], ["273", "DBIA273-A", "File", "PHARMACY DATA MANAGEMENT", "1993/08/30", "", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
#50 DRUG FILE ^PSDRUG(
To maintain backward compatibility with
Outpatient Pharmacy V5.6 50,623001 DALLAS COMMENTS 623001;1
FREE TEXT 50,623002 LAB TEST MONITOR 623002;1 POINTER TO
LABORATORY
TEST FILE
(#60) 50,623003 MONITOR MAX
DAYS 623002;2 NUMBER 50,623004 SPECIMEN TYPE 623002;3
POINTER TO
TOPOGRAPHY
FIELD FILE
(#61) 50,623008 MONITOR
ROUTINE 623008;1 FREE TEXT\n
To maintain compatibility with
Outpatient Pharmacy V6.0 50,17.2 LAB TEST MONITOR CLOZ;1
POINTER TO
LABORATORY
TEST FILE
(#60) 50,17.3 MONITOR MAX
DAYS CLOZ;2 NUMERIC 50,17.4 SPECIMEN TYPE CLOZ;3
POINTER TO
TOPOGRAPHY
FIELD FILE
(#61) 50,17.5 MONITOR
ROUTINE CLOZ1;1 FREE TEXT", "", "", ""], ["274", "DBIA274", "Routine", "HEALTH SUMMARY", "1993/09/09", "APPROVED", "Active", "Private", "", "
Progress Note users have asked that notes printed for a
given location begin the print with big letter identification of location.
Since Health Summary has such lovely code for accomplishing this, and since PN
already relies on HS routines (to display the text of patient warnings), PN is
relying on HS code to print the big letters. Specifically, PN 2.5 is issuing
a patch in which routine GMRPNP1 news GMTSLTR, and checks for the existence of
routine GMTSLTR and calls it if exists, with GMTSLTR =a four letter string.", "", "GMTSLTR", ""], ["275", "DBIA275-A", "File", "KERNEL", "1993/09/09", "", "Retired", "Private", "101", "
Purpose:\n
Request an integration agreement between the Discharge Summary Team and the
OE/RR Team at the Salt Lake ISC for Discharge Summary version 1.0: 1. to
access protocol descriptions by direct reference to the ^ORD(101, and 2.
permission to call ^XQORM as described below.\n
Description: To allow the user to get a detailed description of the actions
that are executable from each of our menu-type protocols, we need to be able
to $ORDER through the subscript ^ORD(101,DO,10,D1,0) to get sub-fields #1
(ITEM) and # 3 (SEQUENCE) of the 101.01 multiple for each ITEM. Then get
field #1 (ITEM TEXT) and #3.5 (DESCRIPTION) for each PROTOCOL encountered in
the ITEM MULTIPLE for a given menu. To allow the user to retrieve Discharge
Summaries into the review screen based on Signature Status and Search Category
(e.g., by PATIENT, PROVIDER, or TREATING SPECIALTY), we need to be able to
execute a DIC call on file 101 to retrieve the zero node of a record and to
reference field # 24 (SCREEN) in order to set up the local variables to be
used to execute the ^XQORM call.", "", "", ""], ["276", "DBIA276-A", "File", "PHARMACY DATA MANAGEMENT", "1993/09/09", "", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
Mental Health V. 5.0 references the following Outpatient pharmacy files and
fields:
File #50 - Drug
Field #.01 - Generic Name - ^PSDRUG(D0,0) piece 1", "", "", ""], ["277", "DBIA277-A", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "13", "\n
File #13 - Religion
Field #.01 - Name - ^DIC(13,D0,0) piece 1", "", "", ""], ["278", "DBIA278", "File", "NURSING SERVICE", "1993/09/13", "APPROVED", "Active", "Private", "211.6", "
Mental Health V. 5.0 references the 'Nurs Tour of Duty'
file:\n
File #211.6 - Nurs Tour of Duty
Field #.01 - Tour of Duty - ^NURSF(211.6,D0,0) piece 1
"B" X-Ref - Tour of Duty", "", "", ""], ["279", "DBIA279", "Other", "TEXT INTEGRATION UTILITIES", "1993/09/13", "APPROVED", "Active", "Private", "", "
Mental Health V. 5.0 no longer contains its own
Progress Notes options, but references within two Mental Health options the
newly released 'generic' Progress Notes Package. Verbal agreement with the
Progress Notes developer has been made. Approval to include within the Mental
Health menu options references to the Progress Notes package options have been
agreed upon, these menu options replace the old MentalHealth Progress Notes
option.", "", "", ""], ["280", "DBIA280", "File", "DRG GROUPER", "1993/09/13", "APPROVED", "Retired", "Private", "80", "
We are requesting that a sharing agreement be
established between the Hospital Based Home Care software and the Global
^ICD9( for the following fields.
**********************************************************
******* Fields ********************************************
**********************************************************
FIELD .01 (node: 0, piece: 1) TYPE OF ACCESS READ GLOBAL
^ICD9(\n\n", "", "", ""], ["282", "DBIA282-A", "Routine", "IFCAP", "1993/09/20", "APPROVED", "Active", "Private", "", "", "", "PRCS58", ""], ["283", "DBIA283", "Other", "ACCOUNTS RECEIVABLE", "1993/10/05", "APPROVED", "Active", "Private", "", "
The Electronic Signature encode created for IFCAP V4.0
for the Electronic Signature codes will work with AR V3.7 code sheet creator
without having to modifiy any AR routines.\n
The exception to the above is, the 'Forward IRS Offsets to Austin' option in
the AR package. This option is used thru the 15th - 21st days of the month.
Since this option generates code sheets in the background AR uses the PRCAOFF2
routine to create code sheets. This one routine is not compatible with IFCAP
V4.0\n
AR plans to create a patch (not to be released till IFCAP V4.0 is released) to
include the change. This patch was forwarded to the IFCAP V4.0 test sites and
were considered as test sites for the AR patch. Since the sites have until the
21st of the month to send the IRS code sheets, this patch should not delay the
implementation plans for IFCAP V4.0.\n
The patch number is PRCA*3.7*17\n
IFCAP version 4 will export this routine in the IFCAP namespace as routine
PRC4OFF2 and renamed back to PRCAOFF2 during the pre- initialization routine.", "", "", ""], ["284", "DBIA284", "File", "ACCOUNTS RECEIVABLE", "1993/10/05", "APPROVED", "Active", "Private", "340", "
Data Dictionary integration - IFCAP calls to AR\n
IFCAP FILES FIELD - RELATION TO IFCAP\n
CALM/LOG Code Sheet File 423 VA IDENT NO. Field 1005.17 (1005;17) - points to
the AR Debtor File (#340)\n
Procurement & Accounting Transaction File 442 Debtor Field 5.1 (1;16) - points
to the AR Debtor File 340 Purchase Order Number Field .01 (0;1) - Executable
Help checks for AR variable $D(PRCAREF)", "", "", ""], ["285", "DBIA285-A", "File", "IFCAP", "2003/09/02", "", "Retired", "Private", "442", "
Also see DBIA's 804-810 Most of the calls below are
interfaces between AR and IFCAP for the creation of CALM code sheets. After
all of the sites convert to FMS, these calls will no longer be needed. These
calls will need to be supported in future versions of the packages or until
all of the sites convert to FMS.\n
Integration agreements between IFCAP and AR for use of tje IFCAP Vendor File
440 will be needed through-out the life of the AR package. The AR routine
calls to IFCAP to support the CALM code sheets.\n
Fields that AR routines set and/or reference in the Procurement & Accounting
Transaction File (#442) of IFCAP include:\n
442,.01 - Purchase Order Number (0;1) 442.09 -
Obligation Data sub-file 442.09,.01 - TT/DATE/REF
(0;1) 442.09,1 - Obligated By (0;2) 442.09,3
- Code Sheet Number (0;4) 442,.1 - P.O. Date
(1;15)\n
442,.02 - Method of Processing (0;2) 442,5.1 -
Debtor (1;16)\n
442,19 - Agent Assigned P.O. (12;4) 442,19.2 - Date
P.O. Assigned (12;5) 442,102 - Document
Identifier/Common No. (18;3) Fiscal Year sub-file 430.01, Pat Ref. No. Field
430.01,2 (0;3) -
points to Procurement & Accounting Transaction File (#442)\n", "", "", ""], ["286", "DBIA286", "File", "MAILMAN", "1993/10/05", "APPROVED", "Active", "Private", "4.2", "
MailMan v 7.1 will invoke a QA conversion in MailMan's
post init. It will manipulate the fields as follows:\n
DBIA for MailMan with the QUALITY ASSURANCE SITE PARAMETERS file (#740). This
DBIA is for the purpose of a post-init conversion of two free-text pointers to
the DOMAIN file (#4.2).\n
Read/write access to the following fields:
740,740.02 EWS DOMAIN (0;3)
740,740.04 NQADB DOMAIN (0;5)\n", "", "", ""], ["287", "DBIA287", "Routine", "FEE BASIS", "1993/10/05", "APPROVED", "Active", "Controlled Subscription", "", "
IFCAP needs to determine the appropriate header for FEE
code sheets based on the version of Fee Basis. In the past the header was
altered by a coordinated patch between the two packages. A new call has been
added, in fee, which will eliminate the need for patches.\n
IFCAP version 4 will be using the following function call to determine the
codesheet header. If the routine FBAAUTL3 does not exist the header will be
FEN. Otherwise the following call, being sent with version 3 of Fee Basis will
return the appropriate header (FEE or FEN).\n
$$HDR^FBAAUTL3()\n", "", "FBAAUTL3", ""], ["288", "DBIA288-A", "Routine", "HEALTH SUMMARY", "1993/10/05", "APPROVED", "Active", "Private", "", "
Discharge Summary adds two new components to the HS
Component file (#142.1), which present detailed and brief Discharge Summary
information, while respecting Time and Occurrence limits. These are added by
the Discharge Summary post-init as record #'s 57 and 58, and you can see them
in either the SIUG or OE/RR accounts. The post-init also adds these
components to the GMTS HS ADHOC OPTION Health Summary Type by calling the
subroutine ENPOST^GMTSLOAD, and installs the routines GMRDHSDS as GMTSDS and
GMRDHSDB as GMTSDSB (these are the driver routines for the respective
components).", "", "GMTSLOAD", ""], ["289", "DBIA289-A", "Other", "KERNEL", "1993/10/12", "APPROVED", "Active", "Private", "", "
Manage Security Keys [GMRD KEY -------1 Allocation of
Security Keys MANAGEMENT] [XUKEYALL]\n
|---------------------------------2 De-allocation of Security Keys
| [XUKEYDEALL]\n
|---------------------------------3 Delegate keys [XQKEYDEL]\n
|---------------------------------4 Remove delegated keys
| [XQKEYRDEL]
------------------------------------------------------------------------\n
|---------------------------------5 List users holding a certain
key [XQSHOKEY]\n
Discharge Summary will export the above menu until a corresponding delegatable
menu is provided in Kernel. Discharge Summary will indicate in its manuals
(User, Technical, and Security), references to the appropriate Kernel
chapters, and indicate that keys cannot be allocated (for end user use) until
they are delegated to the person doing the allocating. And IRM must delegate
individual keys before a delegated key can be delegated or allocated.\n
DURATION: Till otherwise agreed--UNTIL KERNEL CHANGES MENU", "", "", ""], ["290", "DBIA290-A", "File", "KERNEL", "1993/10/12", "APPROVED", "Active", "Controlled Subscription", "3.5", "\n
=============================================================
Field 33, Unauthorized Claim Printer, in file 161.4 (Fee Basis Site Parameters
file) references the device (%ZIS(1) and terminal type (%ZIS(2) files in the
Input transform (extrinsic function), Executable help (routine call) and
Screen. Fee routine is FBUCDD1.\n
The Screen is: S DIC("S")= "S
Z=$G(^%ZIS(1,+Y,""SUBTYPE"")),Z=$G(^%ZIS(2,Z,0)) I $E($P(Z,U),1)=""P""K Z"\n
Global references in the routine calls are:\n
%ZIS(1,"B" %ZIS(1,ien,0 (XHELP only)
%ZIS(1,ien,"SUBTYPE" %ZIS(1,ien,1 (XHELP only)
%ZIS(2,ien,0
where $E(0 node,1)="P" is checked\n", "", "", ""], ["291", "DBIA291", "File", "1", "1993/10/18", "", "Retired", "Private", "", "
The Allergy Tracking System V3.0 uses ^DD(142.1,0,"VR")
to determine which version of the Health Summary package is currently running.
This information is needed to determine which array will be returned by the
GMTSLROE and GMTSLRSE utilities.\n", "", "", ""], ["292", "DBIA292", "Routine", "HEALTH SUMMARY", "1993/10/18", "", "Retired", "Private", "", "
The Allergy Tracking System V3.0 uses a call to
XTRCT^GMTSLROE to extract lab order data. A call to ^%ZOSF("TEST") is used to
check for the existence of this routine on the system before it is called.\n
The input variables are: DFN = IFN of patient in Patient file. SEX = Sex of
patient. GMTS1 = Inverse end date of search for lab orders. GMTS2 = Inverse
start date of search for lab orders. MAX = Maximum number of lab orders to be
extracted The data is returned in the following array:
@REF@("LRO",$J,IDT,SN_FN)=CDT^TST^SPC^URG^OS^MD^ODT
^ACC^RDT^COL^CD where: REF = "^UTILITY" if Health
Summary V1.2, or
"^TMP" if Health Summary V2.5+. IDT = Inverse collection date/time
of order. SN = IFN in Specimen # (1) multiple of Lab Order
Entry (69) file. FN = IFN in Test (6) multiple of Specimen # (1)
multiple of Lab Order Entry (69) file. CDT = Collection date/time of
order. TST = Lab test ordered. This variable has format
A;B where A is the internal pointer and B
is external printable form. SPC = Specimen for lab order. This
variable has
format A;B where A is the internal pointer
and B is external printable form. URG = Urgency of lab order. OS =
Status of lab order. MD = Provider. This variable has format A;B
where A is the internal pointer and B is
external printable form. ODT = Date/Time lab ordered. ACC = Accession
number of lab order. RDT = Date/Time results for this lab order
available. COL = Lab or ward collect. CD = IFN in Lab Order Entry (69)
file.\n", "", "GMTSLROE", ""], ["293", "DBIA293", "Routine", "HEALTH SUMMARY", "1993/10/18", "", "Retired", "Private", "", "
The Allergy Tracking System V3.0 uses a call to
XTRCT^GMTSLRSE to extract lab results. A call to ^%ZOSF("TEST") is used to
check for the existence of this routine on the system before it is called.\n
The input variables are:
LRDFN = IFN of patient in Lab Data (63) file.
SEX = Sex of patient.
GMTS1 = Inverse end date of search for lab results.
GMTS2 = Inverse start date of search for lab results.
MAX = Maximum number of lab results to be extracted
TEST = IFN of lab test which results are sought in
Laboratory Test (60) file. The data is returned in the following
array: @REF@("LRS",$J,NUM,IDT)=DDT^SPC^TST^RSL^FLG^UNT^LO^HI where:
REF = "^UTILITY" if Health Summary V1.2, or
"^TMP" if Health Summary V2.5+.
NUM = Order (1 to MAX).
IDT = Inverse draw date/time of result.
DDT = Draw date/time of result.
SPC = Specimen for lab order. This variable has
format A;B where A is the internal pointer
and B is external printable form. TST = Lab test ordered. This
variable has format
A;B where A is the internal pointer and B
is external printable form. RSL = Numeric result of test. FLG =
Reference flag (H,*H,L,*L). UNT = Unit of measure (external format). LO =
Reference/Therapeutic Lower bound. HI = Reference/Therapeutic Upper bound.\n", "", "GMTSLRSE", ""], ["294", "DBIA294", "File", "REGISTRATION", "1993/10/21", "APPROVED", "Active", "Private", "2", "
A DBIA is established between the Hospital Based Home
Care system and the Patient file (#2), for read access to the following.\n
*****************************************************************
********** FIELDS ***********************************************
*****************************************************************
FIELD NODE PIECE TITLE
-----------------------------------------------------------------
.01 0 1 Name .02 0 2
Sex .03 0 3 Date of Birth .05 0
5 Marital Status .06 0 6 Race .131
.13 1 Phone Number [Residence] .323 .32 3
Period of Service .361 .36 1 Primary Eligibility
Code\n
All seven fields in the .11 node (address information).\n
****************************************************************
In addition reference is made to "^DPT(IEN,"S"," in the routine HBHCCAN.\n", "", "", ""], ["295", "DBIA295", "Other", "KERNEL", "1993/10/21", "APPROVED", "Active", "Private", "", "
Integration Agreement Request between Toolkit (all
versions) and Kernel (all versions).\n
Toolkit and Kernel agree that both packages shall distribute all routines and
data for M operating system interfaces (e.g. ZOSF, ZOSV*, ZTBK). These two
packages also agree that both shall distribute the function library as
designated by the routine namespace XLF.\n
Toolkit and Kernel also agree that the menus, XUPROG, XTMENU, and XUCM MAIN,
can be attached to the Kernel menu EVE.", "", "", ""], ["296", "DBIA296", "File", "INPATIENT MEDICATIONS", "1993/10/21", "APPROVED", "Active", "Private", "50.8", "
Outpatient Pharmacy 6.0v will be printing a management
report. In order to complete the report, we need to read ^PS(50.8 (IV STATS
FILE). We are reporting the outpatient ward's number of dispensed units,
average cost of the dispensed units, and the total costs of the dispensed
units.\n
To obtain this data, we need to read the 0 node in subfile 50.804, the Average
Drug Cost Per Unit field (#4) on the 0 node piece 5 in subfile 50.805, the
Dispensed Units (Ward) field (#2) on the 0 node piece 2 in the subfile 50.808,
and the B cross-reference in subfile 50.808.\n\n
GLOBAL MAP DATA DICTIONARY #50.8 -- IV STATS FILE STORED IN ^PS(50.8,
SITE: BIRMINGHAM ISC
--------------------------------------------------------------------------
^PS(50.8 D0,2,D1,1,0)=^50.804P^^ (#1) WARD ^PS(50.8,D0,2,D1,2,D2,0)=^^^^ (#4)
AVERAGE DRUG COST PER UNIT [5N] ^PS(50.8,D0,2,D1,2,D2,3,D3,0)=^ (#2) DISPENSED
UNITS (WARD) [2N] ^", "", "", ""], ["297", "DBIA297-A", "Other", "HEALTH SUMMARY", "1993/10/25", "APPROVED", "Active", "Private", "", "
The routine GMTSPDX will be exported by version 1.5 of
PDX. Installation of GMTSPDX will only be done if the routine does not exist
on the installing system.\n
A partial data dictionary for the HEALTH SUMMARY PARAMETERS file (#142.99)
will be exported by version 1.5 of PDX. The partial data dictionary will
export the SPOOL DEVICE NAME field (#.04).\n
The PDX application is grynted permission to include instructions for editing
the GMTS IRM/ADPAC PARAMETER EDIT option. These instructions explain how to
add the SPOOL DEVICE NAME field to the existing DR string contaioed in the DR
{DIE} field (#51).\n
The PDX application is granted pesmission to included instructions for editing
the SPOOL DEVICE NAME field (#.04) of the HEALTH SUMMARY PARAMETERS file
(#142.99) using the GMTS IRM/ADPAC PARAMETER EDIT option. These instructions
explain how to enter the name of the spooling device used at the installing
facility.", "", "", ""], ["298", "DBIA298-A", "File", "PATIENT DATA EXCHANGE", "1993/10/25", "APPROVED", "Active", "Private", "394.61", "
The Health Summary application is granted read access
to the following fields and, if listed, their associated cross references:\n
File Field Node;Piece Description (Field name) X-Refs
------ ----- ---------- ------------------------------ ------
394.61 .01 0;1 Transaction Number B
.03 0;3 Patient Ptr", "", "", ""], ["299", "DBIA299-A", "File", "1", "1993/10/25", "APPROVED", "Active", "Private", "", "
The PDX (V 1.5) application is granted read access to
the DD and DIC globals to accomplish the following tasks:\n
1) See DBIA 821\n
2) Get node a field/multiple is stored on
$P($P(^DD(FILE,FIELD,0),"^",4),";",1)\n
3) Get field name
$P(^DD(FILE,FIELD,0),"^",1)\n
4) Determine if a field is date valued
$P(^DD(FILE,FIELD,0),"^",2)["D"\n
5) Determine if a subfile is a word processing field
$P(^DD(SUBFILE,.01,0),"^",2)["W"\n
6) Determine what file a field points to
+$P($P(^DD(FILE,FIELD,0),"^",2),"P",2)\n
7) Determine if a file is a subfile
$G(^DD(FILE,0,"UP"))'=""\n
8) Determine main file number for a subfile
$G(^DD(SUBFILE,0,"UP"))\n
9) Determine main field number for a subfile
$O(^DD(MAINFILE,"SB",SUBFILE,""))\n
10) Determine subfile number
+$P(^DD(FILE,FIELD,0),"^",2)\n
11) Check for valid file number
$D(^DD(FILE))\n
12) Check for valid field number
$D(^DD(FILE,FIELD))", "", "", ""], ["300", "DBIA300", "Routine", "INTEGRATED BILLING", "1993/10/25", "APPROVED", "Active", "Private", "", "
Routine call to SVDT^IBRFN returns service dates for a
specific bill.\n
Input Variable: BN, bill number (external form)
VDT, name of array to hold outpatient
visit dates, pass by value
if needed.\n
Output Variable:
_________________________________________________________________
| Piece | Bill not found | Inpatient | Outpatient
|-----------------------------------------------------------------|
| 1 | 0 | 1 | 2
| 2 | -- | event Date | Event Date
| 3 | -- | stmt from date | stmt from Date
| 4 | -- | stmt to date | stmt to Date
| 5 | -- | LOS (I) | LOS (I)
| 6 | -- | # of visit date |# of visit date
-----------------------------------------------------------------\n\n
all are internal form, any piece may be null if not defined for the bill array
containing outpatient visit dates as subscripts/no data, if VDT passed by
value.\n", "", "IBRFN", ""], ["301", "DBIA301", "Routine", "INTEGRATED BILLING", "1993/10/25", "APPROVED", "Active", "Private", "", "\n
Routine Call to STMT^IBRFN1 to pass clinical data to AR for
the patient statement.\n\n
INPUT VARIABLE: TRAN, AR Transaction Number, the pointer file 433.\n\n
OUTPUT VARIABLE: Returns ^TMP("IBRFN1",$J,n)=1^2^3^4^5^6^7^8, where\n
_________________________________________________________________
| | Transaction Type
|___________ |____________________________________________________
| Piece | Pharmacy |Outpatient | Inpatient
|-----------------------------------------------------------------|
| 1 | IB REF # | IB REF # | IB REF #
| 2 | Rx # | Visit Date | Adm Date
| 3 | Drug | -- | Bill From Date
| 4 | Day Supply | -- | Bill To Date
| 5 | Physician | -- | Disc Date
| 6 | Quantity | -- | --
| 7 |Fill/Refill Date | -- | --
| 8 | Charge Amt | Charge Amt | Charge Amt
-----------------------------------------------------------------\n", "", "IBRFN1", ""], ["302", "DBIA302-A", "File", "PHARMACY DATA MANAGEMENT", "1993/10/25", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.\n
The PDX application is granted read access to the following fields and, if
listed, their associated cross references:\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
50 .01 0;1 GENERIC NAME B
20 ND;1 NATIONAL DRUG FILE ENTRY", "", "", ""], ["303", "DBIA303-A", "File", "LAB SERVICE", "2005/06/20", "", "Retired", "Private", "60", "
QUIC is granted an integration agreement with
Laboratory to obtain the rate of completion of at least one Glycosalated
Hemoglobin measurement within one year for diabetic patients on a medication
regimen.", "", "", ""], ["304", "DBIA304", "Routine", "INTEGRATED BILLING", "1993/10/27", "APPROVED", "Active", "Private", "", "
Call to routine IB^IBRUTL to find if there are any IB
Actions on hold for this bill.\n
Input Variables: IEN - internal entry number of bill (#399)
internal entry number of bill (#430)
RETN (OPT) - want array of IB Actions?
1=yes, 0=no
if yes, returns IBA(num)=ibn\n
Output Variable: 1=Yes, 0=N0\n", "", "IBRUTL", ""], ["305", "DBIA305", "File", "KERNEL", "1993/10/27", "APPROVED", "Active", "Private", "4.281", "
MailMan should be allowed the use of the %ZISL file as
follows:\n
MailMan uses the 4.281 file whose global root is ^%ZISL(4.281, to facilitate
InterUCI transfers. This file is part of the MailMan file set. MailMan may
distribute and use this file.\n", "", "", ""], ["306", "DBIA306", "Routine", "INTEGRATED BILLING", "1993/10/27", "APPROVED", "Active", "Private", "", "
This option allows the agent cashier to release 'holds'
on Means Test Bills.\n
ENTRY ACTION: D ^IBRREL\n", "", "IBRREL", ""], ["307", "DBIA307", "Routine", "INTEGRATED BILLING", "1993/10/27", "APPROVED", "Active", "Private", "", "
Routine call to REPRNT^IBCF13 to print 2nd and 3rd
notice UB-82's.\n
INPUT VARIABLES: PRCASV("ARREC")=internal number of bill
PRCASV("NOTICE")=number of notice\n
OUTPUT VARIABLES: IBAR("ERR")=ERROR MESSAGE
IBAR("OKAY")=1 normal finish, 0 not finished", "", "IBCF13", ""], ["308", "DBIA308", "Routine", "INTEGRATED BILLING", "1993/10/27", "APPROVED", "Active", "Private", "", "
This option prints totals of Revenue Code amounts by
Rate Type to collect data for AMIS Segments 295 and 296.\n
ENTRY ACTION: D ^IBOAMS K DTOUT\n", "", "IBOAMS", ""], ["309", "DBIA309", "Routine", "INTEGRATED BILLING", "1993/10/27", "APPROVED", "Active", "Private", "", "
Routine call to IBCAMS to determine amis segment for
reimbursable insurance bills.\n
249 = NSC - outpatient
292 = SC - inpatient
293 = SC - outpatient
297 = NSC - inpatient\n
INPUT VARIABLE: X = internal entry number in #399.\n
OUTPUT VARIABLE: Y= amis segment number or -1 if can't
determine.\n
(With the 1st release 18 months)\n", "", "IBCAMS", ""], ["310", "DBIA310", "Routine", "INTEGRATED BILLING", "1993/10/27", "APPROVED", "Active", "Private", "", "
Routine call to MESS^IBRFN to return an error message
from File 350.8.\n
INPUT VARIABLE: Y=error code - from File 350.8 (piece 3)\n
OUTPUT: error message from piece 2 file 350.8.", "", "IBRFN", ""], ["311", "DBIA311-A", "File", "REGISTRATION", "1993/11/01", "APPROVED", "Active", "Private", "45.7", "
The Discharge Summary package has permission to access
the Patient Information Management System package in the following ways:\n
1. The Discharge Summary contains a field which is a pointer to the Facility
Treating Specialty File (#45.7), to keep track of the Treating Specialty from
which a patient was discharged (for searches and sorts). This field value is
set to the treating specialty returned by the IN5^VADPT call.\n
2. Discharge Summary allows the user to do a lookup to get all Discharge
Summaries for a given treating specialty by signature status and dictation
date. To do this query we need to identify the treating specialty, using a
^DIC call with DIC=45.7, DIC(0)="AEMQ", DIC("A")="TREATING SPECIALTY".", "", "", ""], ["312", "DBIA312-A", "File", "REGISTRATION", "1993/11/01", "APPROVED", "Active", "Private", "45", "\n\n
The Discharge Summary has permission to access the Patient Information
Management System package in the following ways:\n
1. Upon record creation, Discharge Summary will perform a screened look-up on
the PTF File to associate the new discharge summary with a valid admission.
The screening logic will exclude Census PTF records. Discharge Summary also
offers a site parameter to allow selection of Open PTF records only. To that
end, the DIC("S") screen will make direct reference to the ^DGPT( global as
follows:\n
S DIC=45,DIC(0)=$S($D(GMRDBG):"MXZ",1:"IEZ")
; Exclude "Census" PTF records
S DIC("S")="I +$P(^DGPT(+Y,0),U,11)=1"
; If an admission date has been specified, find the corresponding
; PTF record
S:$D(GMRDADT) DIC("S")=DIC("S")_",($P($P(^DGPT(+Y,0),U,2),""."")=G
MRDADT)"
; If site allows OPEN PTF selection only, then exclude closed or
; transmitted records
S:+$P(GMRDPRM0,U,8) DIC("S")=DIC("S")_",'$P(^DGPT(+Y,0),U,6)"\n
where GMRDBG is a boolean flag, indicating that the look-up is being
called non-interactively, with a patient SSN
and admission date,
GMRDADT is the patient's admission date, as dictated by
the physician, to be passed in by the non-interactive
call, and
GMRPRM0 is the zero-node of the GMRD PARAMETERS FILE (#128.99),
the eighth piece of which specifies whether the site will
allow selection of open PTF records only.\n
Note that this screen will always refer to the 11th piece of the zero node of
the PTF record to exclude non-PTF types, and will conditionally refer to the
2nd and 6th pieces, to match the admission date and exclude non-open records,
as the site specifies.\n
2. The Discharge Summary database contains a field that is a pointer to the
PTF file (#45), which is stored upon creation of the discharge summary record.\n
3. Discharge Summary calls the documented IN5^VADPT entry-point to get
information on the patient. Using the PTF record number retained in our
database, the input variable VAIP("E") is set to the value of field #2.1
(INTERNAL Admission #), which is obtained by a call to EN^DIQ1 after setting
DIC=45, DR=2.1, and DA = PTF record number.", "", "", ""], ["313", "DBIA313", "File", "REGISTRATION", "1993/11/01", "APPROVED", "Active", "Controlled Subscription", "393", "
Discharge Summary has permission to reference the
Incomplete Records File (#393), from the GMR REPORTS FILE (#128), IRT RECORD
field (#.13).\n", "", "", ""], ["314", "DBIA314-A", "File", "1", "1993/11/01", "APPROVED", "Active", "Private", "", "
To support the table-driven upload of transcribed text
to various DHCP files, the Discharge Summary application has permission to
access the Data Dictionary and File of Files in the following ways:\n
1. In order to allow the site to specify the target file, fixed-field header
elements, and word-processing field for each report type, Discharge Summary
version 1 will make several references to either the File of Files or ^DD(.
These are ONLY done in setting up a ^DIC call (to look-up a given field in the
target file), or in screening logic (e.g., to exclude the programmer at the
site from choosing a non-Word-Processing field in the target file as the
destination for the body of a report). Needless to say, NO SETs or KILLs are
ever executed on any of FileMan's supporting data structures (i.e., ^DD( or
^DIC(). All hard-coded references to ^DIC( or ^DD( are made from within the
following code:\n
GMRDUPAR ; SLC/JER - Upload Parameter Edit ;4/23/93 14:53
;;1.0V2;Discharge Summary;;Sep 02, 1993 MAIN ; Controls branching
N DIC,DA,DIE,DLAYGO,DR,GMRDPRM0,GMRDPRM1,GMRDPRM3,GMRDUSRC,GMRD1ST,X,Y
D:'$D(GMRDPRM0) SETPARM^GMRDLIBE
W !,"First edit Division-wide upload parameters:",!
S (DIC,DLAYGO)=128.99,DIC(0)="AEMQL",DIC("A")="Select DIVISION: "
D ^DIC K DLAYGO Q:+Y'>0 S DA=+Y
S DIE=128.99,DR="[GMRD UPLOAD PARAMETER EDIT]"
D ^DIE
D SETPARM^GMRDLIBE
W !!,"Now edit the REPORT TYPE file:",!
F D Q:+$G(Y)'>0
. N GMRDREP,GMRDX
. S DIC="^GMR(128.1,",DIC(0)="AEMQZ",DIC("A")="Select REPORT TYPE: "
. I $D(^DISV(DUZ,DIC)),'$D(GMRD1ST) S DIC("B")=$G(^DISV(DUZ,DIC)),
GMRD1ST=1
. D ^DIC K DIC Q:+Y'>0 S DA=+Y,GMRDREP=Y,GMRDREP(0)=Y(0)
. S DIE=128.1,DR="[GMRD UPLOAD PARAMETER EDIT]"
. D ^DIE S Y=1
. I $D(^GMR(128.1,+DA,"HEAD"))>9!($D(^GMR(128.1,+DA,"ITEM"))>9) D
. . W !!,"The header for the ",$P(GMRDREP,U,2)," Report type is now
defined as:"
. . I $P(GMRDPRM0,U,16)="D" D DHDR^GMRDTHLP(.GMRDREP,GMRDPRM0,GMRDPRM1)
. . I $P(GMRDPRM0,U,16)="C" D CHDR^GMRDTHLP(.GMRDREP,GMRDPRM0,GMRDPRM1)
. . W !
Q TXTFLD(TFILE,GMRDFLT) ; Get Text Field # from ^DD(Target file #,
N DIC,X,Y
S DIC="^DD("_TFILE_",",DIC(0)="AEMQZ",DIC("A")="Select TARGET TEXT FIELD
: "
S DIC("S")="I +$$ISWP^GMRDUPAR(TFILE,+Y)"
I $D(GMRDFLT) S DIC("B")=GMRDFLT
D ^DIC G:+Y'>0 TXTFLDX
S Y=+Y_";"_$P($P(Y(0),U,4),";") TXTFLDX Q Y ISWP(TFILE,TFLD) ; Is a
given field a Word-processing type field
N X,Y S Y=0
I +$P(^DD(TFILE,TFLD,0),U,2)>0 D
. N SFILE S SFILE=+$P(^DD(TFILE,TFLD,0),U,2)
. S Y=$S($P(^DD(SFILE,.01,0),U,2)="W":1,1:0)
Q Y\n\n
2. The input transform for the TARGET FILE field (#.05) in the GMR REPORT TYPE
file, which is a pointer to the File of Files, assures that only files which
include the "GMRD" application group may be chosen for inclusion in the
upload. This was done to assure that the site could not inadvertently choose
an inappropriate target file (NOTE: the only file exported with this
Application Group is the GMR REPORTS FILE (#128), where Discharge Summaries
themselves are housed). The input transform looks like this:\n
S DIC("S")="I $D(^DIC(+Y,""%"",""B"",""GMRD""))" D ^DIC K DIC S
DIC=DIE,X=+Y K:Y<0 X\n", "", "", ""], ["315", "DBIA315-A", "Routine", "IFCAP", "1993/11/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PRCS58", ""], ["316", "DBIA316-A", "File", "1", "1993/11/01", "APPROVED", "Active", "Private", "", "
1. When a new file is configured for use with MTLU, the
variable-pointer 'ENTRY' field is automatically updated in the LOCAL KEYWORD
and LOCAL SHORTCUT files to reflect the new file. This must be handled via
DIC/DIE calls with DIC/DIE being set to ^DD(file,.02,"V", It is fully
compatible with the interactive way of creating variable pointer type fields.\n
2. MTLU uses the string maintained in ^DD("KWIC"). There is currently no way
of retrieving this information without directly referencing this node. As
stated there is currently no way of extracting data stored in the node except
by direct global hit.\n
*Amendment 5/11/94*\n
Toolkit DBIA 316 has been amended to include the $order of ^DD in line
QU+5^XTLKEFOP. This code identifies the variable pointer prefix associated
with the selected lookup file and was inadvertently ommitted.\n
S XTLKY=Y,XTLKPF=+$O(^DD(8984.2,.02,"V","B",+Y,"")) G:'XTLKPF KL
S XTLKPF=$P(^DD(8984.2,.02,"V",XTLKPF,0),U,4),XTLKUT=1", "", "", ""], ["317", "DBIA317-A", "Routine", "VETERANS ADMINISTRATION", "1993/11/02", "APPROVED", "Active", "Private", "", "", "", "VALM1", ""], ["318", "DBIA318", "Other", "IFCAP", "1993/11/03", "APPROVED", "Active", "Private", "", "
See DBIA #315.", "", "", ""], ["319", "DBIA319", "Routine", "IFCAP", "1993/11/02", "APPROVED", "Active", "Private", "", "\n
Version 7.0 of the Engineering Work Order Module will call IFCAP
to display Control Point Activity information related to specific
Engineering work orders.\n
Routine ^ENWOD will call ^PRCSP13. Before calling this foreign
routine, ^ENWOD will execute ^%ZOSF("TEST") to make sure that
^PRCSP13 exists.\n
Upon entry into ^PRCSP13, local variable DA must contain the internal entry
number of the Control Point Activity that is to be displayed.\n
Local variable DA is not returned by ^PRCSP13.\n
If local variables DIWL, DIWR, and/or DIWF are defined when the call to
^PRCSP13 is made, they will not be preserved.\n", "", "PRCSP13", ""], ["320", "DBIA320", "Other", "1", "1993/11/23", "", "Retired", "Private", "", "
An integration agreement is approved to use the VA
FileMan undocumented variable DIWESUB. This variable will be set in the
Enter/Edit option of all objects and sub-objects of the ADP Plan Manager
Version 10 software. The variable will be used in conjunction the a VA
FileMan call to EN^DIWE for users to edit both the Initiative Description and
the Equipment Justification. When using the full screen editor to edit word
processing fields, the entire screen is blanked, and could be potentially
confusing to the user. In all cases the variable will be set immediately
prior to the call to EN^DIWE, and will be killed immediately afterword.
Following is a short sample of the code which is used to edit the Initiative
Description.\n
EDIT;
S DIWEPSE=1
S DIC="^PRAPIN(PRASTN,""IN"",PRASIN,""ID"","
S DWLW="75",DWPK="1"
S DIWESUB="Description"
D EN^DIWE K DIWESUB\n", "", "", ""], ["321", "MODIFY 'B' XREF OF 757.01", "File", "1", "1993/12/01", "", "Expired", "Private", "757.01", "
The FM team grants the request of the Clinical Lexicon
package to modify the "B" index of file 757.01 as follows:\n
S ^GMP(757.01,"B",$E($$UP^XLFSTR(X),1,63),DA)="" K
^GMP(757.01,"B",$E($$UP^XLFSTR(X),1,63),DA)\n
It is further agreed that the following tools will not be used with this file:
DIFROM, COMPARE/MERGE and TRANSFER. These tools rely on an unmodified 'B'
index to function properly. Using the modified 'B' index of file 757.01 along
with any of the named tools may produce unexpected results.\n", "", "", ""], ["322", "DBIA322", "File", "REGISTRATION", "1993/12/07", "APPROVED", "Active", "Controlled Subscription", "45.7", "
DSS is granted permission to make the following call:
After callilng IN5^VADPT using the first ^ piece of VAIP(8) Read access to the
following field.\n
File Field Name Global
Location
---- ----- ---- --------
45.7 1 Specialty 0;2\n", "", "", ""], ["323", "DBIA323-A", "File", "KERNEL", "1993/12/16", "APPROVED", "Active", "Private", "3.2", "\n
To support bar code label printing and downloading/uploading, the
Controlled Substances package has found it necessary to develop hardware
specific parameters for the TERMINAL TYPE and DEVICE file. Centralized
procurements of Hewlett Packard and Kyocera laser printers and Intermec
trakkers have steered this package toward the use of these hardware types. As
testing has proceeded, the need to accurately communicate complex strings for
insertion into the TERMINAL TYPE file has proved difficult. An l
misinterpreted as a 1, a 0 mininterpreted as a O, or an inadvertant space or
lack thereof all can render a device inoperable.
It is therefore agreed that IRM utility routines (PSDTER*) be exported
which would allow ^DIC look-ups to the TERMINAL TYPE and DEVICE files, ^DIR
verification of the selections, and ^DIE stuffs to the necessary fields
identified as follows:\n
GLOBAL MAP DATA DICTIONARY #3.2 -- TERMINAL TYPE FILE STORED IN ^%ZIS(2,
(VERSION 7.1)
--------------------------------------------------------------------------
^%ZIS(2,D0,0)= (#.01) NAME [1F] ^ ^%ZIS(2,D0,1)= (#1) RIGHT MARGIN [1N] ^ (#2)
FORM FEED [2F] ^ (#3) PAGE
==>LENGTH [3N] ^ ^%ZIS(2,D0,1)= (#4) BACK SPACE [4F] ^
^%ZIS(2,D0,2)= (#6) OPEN EXECUTE [E1,245K] ^ ^%ZIS(2,D0,9)= (#99) DESCRIPTION
[1F] ^ ^%ZIS(2,D0,10)= (#110) OPEN PRINTER PORT [E1,245K] ^ ^%ZIS(2,D0,11)=
(#111) CLOSE PRINTER PORT [E1,245K] ^ ^%ZIS(2,D0,BAR0)= (#61) BAR CODE OFF
[E1,245F] ^ ^%ZIS(2,D0,BAR1)= (#60) BAR CODE ON [E1,245F] ^", "", "", ""], ["324", "DBIA324", "Routine", "INTEGRATED BILLING", "1993/12/23", "APPROVED", "Active", "Private", "", "
IVM has permission to use the following routine call in
the Integrated Billing (IB) package:\n
Means Test Billing module: $$IGN^IBEFUNC(Appt Type, Visit Date)\n
The call is being made to determine if a patient may be billed the Means Test
Outpatient copayment, given the visit date and the appointment Type for the
visit.\n
Function Call: $$IGN^IBEFUNC(Appt Type, Visit Date)\n
Input Parameters:\n
Appt Type: Pointer to file #409.1, APPOINTMENT TYPE.
For a specific patient appointment, this specifies
the type of appointment (Regular, Research, Employee,.)
Visit Date: Fileman date. For a specific patient appointment,
this is the date of the appointment.\n
Output from the call:\n
1 : On the specified date, for an appointment with the
specified appointment type, Means Test billing
should be IGNORED (so the Means Test copay should NOT
be billed)
0 : On the specified date, for an appointment with the
specified appointment type, Means Test billing
should NOT be IGNORED (so the Means Test copay
SHOULD be billed)\n", "", "IBEFUNC", ""], ["325", "DBIA325-A", "Routine", "REGISTRATION", "1993/12/23", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VADPT2", ""], ["326", "DBIA326", "File", "INDIAN HEALTH SERVICE", "1994/01/11", "APPROVED", "Active", "Private", "9000011", "
The following is the Problem File as it has been
designed for the DHCP Problem List Application.\n
STANDARD DATA DICTIONARY #9000011 -- PROBLEM FILE 2/9/94 STORED IN
^AUPNPROB( (VERSION 2.0V2)\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
-----------------------------------------------------------------
This file contains patient specific problems entered by the various providers
of service. The PATIENT NAME field (.02) is a backward pointer to the IHS
PATIENT file. This file contains one record for each problem for each
patient, therefore, the KEY field (.01) is duplicated.\n
As of March 17, 1986 the FACILITY must be entered prior to the NUMBER. If the
NUMBER is entered without previously entering the FACILITY the "AA" index is
created with no FACILITY pointer.\n\n
DD ACCESS: @
DEL ACCESS: @\n
IDENTIFIED BY: PATIENT NAME (#.02),FACILITY (#.06),NMBR (#.07)\n
POINTED TO BY: PROBLEM field (#.01) of the PROBLEM LIST AUDIT File
(#125.8)\n
CROSS REFERENCED BY: NMBR(AA),
PATIENT NAME(AATOO),
FACILITY(AATOO2),
PATIENT NAME(AC),
STATUS(ACTIVE),
PATIENT NAME(ACTIVE1),
FACILITY(AV1),
DIAGNOSIS(AV9),
DIAGNOSIS(B),
PROBLEM(C)\n\n
9000011,.01 DIAGNOSIS 0;1 POINTER TO ICD DIAGNOSIS
FILE (#80)
(Required)\n
INPUT TRANSFORM: S DIC("S")="I 1
Q:$G(DUZ(""AG""))=""V"" I $E(^(0))'="E",
$P(^(0),U,9)="""" Q:$P(^(0),U,10)="""" I
$P(^(0),U,10)=AUPNSEX" D ^DIC K DIC S DIC=DIE,
X=+Y K:Y<0 X
LAST EDITED: JAN 10, 1994
HELP-PROMPT: Enter the ICD Code for this
problem.
DESCRIPTION: This is the ICD coded diagnosis of
the narrative entered describing
this problem.\n
TECHNICAL DESCR: The DHCP Problem List application
derives its entries from a lookup
into the Clinical Lexicon Utility
rather than the ICD Diagnosis file.
If the term selected from the CLU
is not coded to ICD, then code
799.99 "Other Unknown or
Unspecified Cause, NEC" will be
used here in order to be able to
create a new entry. This field may
later be edited.\n
SCREEN: S DIC("S")="I 1
Q:$G(DUZ(""AG""))=""V"" I $E(^(0))'="E",
$P(^(0),U,9)="""" Q:$P(^(0),U,10)="""" I
$P(^(0),U,10)=AUPNSEX" D ^DIC K DIC S DIC=DIE,
X=+Y K:Y<0 X\n
EXPLANATION: Cannot be an E code or an inactive
code and must be appropriate for
the sex of the Patient.\n
CROSS-REFERENCE: 9000011^B
1)= S^AUPNPROB("B",$E(X,1,30),DA)=""
2)= K ^AUPNPROB("B",$E(X,1,30),DA)\n
CROSS-REFERENCE: 9000011^AV9^MUMPS
1)= S:$D(APCDLOOK) DIC("DR")=""
2)= Q
Controls the behaviour of the
input templates used by IHS to
populate and maintain this file.\n
9000011,.02 PATIENT NAME 0;2 POINTER TO PATIENT/IHS
FILE (#9000001)
(Required)\n
LAST EDITED: SEP 9, 1993
HELP-PROMPT: Enter the name of the patient for
whom this problem has been
observed.
DESCRIPTION: This is the patient for whom this
problem has been observed and
recorded.\n
UNEDITABLE
CROSS-REFERENCE: 9000011^AC
1)= S ^AUPNPROB("AC",$E(X,1,30),DA)=""
2)= K ^AUPNPROB("AC",$E(X,1,30),DA)\n
CROSS-REFERENCE: 9000011^AATOO^MUMPS
1)= I $P(^AUPNPROB(DA,0),U,6)]"",$P(^(0),U,7)]"
" S X1=$P($P(^(0),U,7),"."),X2=$P($P(^(0),U,7),
".",2),^AUPNPROB("AA",X,$P(^(0),U,6)," "_$E("00\n\n
0",1,4-$L(X1)-1)_X1_"."_X2_$E("00",1,3-$L(X2)-1
),DA)="" K X1,X2\n
2)= I $P(^AUPNPROB(DA,0),U,6)]"",$P(^(0),U,7)]"
" S X1=$P($P(^(0),U,7),"."),X2=$P($P(^(0),U,7),
".",2) K ^AUPNPROB("AA",X,$P(^(0),U,6)," "_$E("
000",1,4-$L(X1)-1)_X1_"."_X2_$E("00",1,3-$L(X2)
-1),DA),X1,X2
Allows problem retrieval by
patient, facility, and problem
number (Nmbr); the number is used
as a string in " 000.00" format to
assure a consistent ordering.\n
CROSS-REFERENCE: 9000011^ACTIVE1^MUMPS
1)= S:$L($P(^AUPNPROB(DA,0),U,12))
^AUPNPROB("ACTIVE",X,$P(^(0),U,12),DA)=""
2)= K:$L($P(^AUPNPROB(DA,0),U,12)) ^AUPNPROB("A
CTIVE",X,$P(^(0),U,12),DA)
Allows problem retrieval by patient
and status, in order of entry.\n
9000011,.03 DATE LAST MODIFIED 0;3 DATE (Required)\n
INPUT TRANSFORM:
S %DT="EX" D ^%DT S X=Y K:DT<X!(2000000>X) X
LAST EDITED: JUL 6, 1993
HELP-PROMPT: TYPE A DATE BETWEEN 1900 AND TODAY
DESCRIPTION: This is the last date/time this
problem was changed.\n
SOURCE OF DATA: 018/PRCOND\n
9000011,.04 CLASS 0;4 SET\n
'P' FOR PERSONAL HISTORY;
'F' FOR FAMILY HISTORY;
LAST EDITED: OCT 7, 1987
HELP-PROMPT: If this problem is historical,
indicate if it is Personal or
Family history.
DESCRIPTION: This flag is used by the IHS
Problem List to indicate if this
problem is documented for
historical purposes.\n
TECHNICAL DESCR: VA sites using the DHCP Problem
List application will not be
prompted for this information.\n\n
9000011,.05 PROVIDER NARRATIVE 0;5 POINTER TO PROVIDER
NARRATIVE FILE
(#9999999.27) (Required)\n
INPUT TRANSFORM:
S DIC(0)=$S($D(APCDALVR):"LO",1:"EMQLO") D ^DIC
K DIC S DIC=DIE,X=+Y K:Y<0 X
LAST EDITED: NOV 28, 1988
HELP-PROMPT: Enter a description of this
patient's problem.
DESCRIPTION: This contains the actual text used
by the provider to describe this
problem.\n
SCREEN:
S DIC(0)=$S($D(APCDALVR):"LO",1:"EMQLO")
EXPLANATION: OLD LOOKUP\n
9000011,.06 FACILITY 0;6 POINTER TO LOCATION FILE
(#9999999.06)
(Required)\n
LAST EDITED: JAN 10, 1994
HELP-PROMPT: Enter the location at which this
problem was first observed and
recorded.
DESCRIPTION: This is the facility at which this
problem was originally observed and
documented.\n
UNEDITABLE
CROSS-REFERENCE: 9000011^AV1^MUMPS
1)= Q
2)= Q
No longer in use.\n
CROSS-REFERENCE: 9000011^AATOO2^MUMPS
1)= I $P(^AUPNPROB(DA,0),U,2)]"",$P(^(0),U,7)]"
" S X1=$P($P(^(0),U,7),"."),X2=$P($P(^(0),U,7),
".",2),^AUPNPROB("AA",$P(^(0),U,2),X," "_$E("00
0",1,4-$L(X1)-1)_X1_"."_X2_$E("00",1,3-$L(X2)-1
),DA)="" K X1,X2
2)= I $P(^AUPNPROB(DA,0),U,2)]"",$P(^(0),U,7)]"
" S X1=$P($P(^(0),U,7),"."),X2=$P($P(^(0),U,7),
".",2) K ^AUPNPROB("AA",$P(^(0),U,2),X," "_$E("
000",1,4-$L(X1)-1)_X1_"."_X2_$E("00",1,3-$L(X2)
-1),DA),X1,X2
Allows problem retrieval by
patient, facility, and problem
number (Nmbr); the number is used
as a string in " 000.00" format to
assure a consistent ordering.\n
9000011,.07 NMBR 0;7 NUMBER (Required)\n
INPUT TRANSFORM:
K:+X'=X!(X>999.99)!(X<1)!(X?.E1"."3N.N) X Q:'$D
(X) K:$D(^AUPNPROB("AA",$P(^AUPNPROB(DA,0),U,2
),$P(^(0),U,6)," "_$E("000",1,4-$L($P(X,".",1))
-1)_$P(X,".",1)_"."_$P(X,".",2)_$E("00",1,3-$L(
$P(X,".",2))-1))) X
LAST EDITED: JUL 26, 1993
HELP-PROMPT: TYPE A NUMBER BETWEEN 1 AND 999.99
DESCRIPTION: This is a number which, together
with the Patient (#.02) and
Facility (#.06) fields,
serves as a unique identifier for
this problem.
Up to 2 decimal places may be used
to indicate that a problem is a
result of, or related to,
another problem.\n
SOURCE OF DATA: 018/PRNUMB
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY
PROGRAMMER\n
CROSS-REFERENCE: 9000011^AA^MUMPS
1)= S ^AUPNPROB("AA",$P(^AUPNPROB(DA,0),U,2),$P
(^(0),U,6)," "_$E("000",1,4-$L($P(X,".",1))-1)_
$P(X,".",1)_"."_$P(X,".",2)_$E("00",1,3-$L($P(X
,".",2))-1),DA)=""\n
2)= K ^AUPNPROB("AA",$P(^AUPNPROB(DA,0),U,2),$P
(^(0),U,6)," "_$E("000",1,4-$L($P(X,".",1))-1)_
$P(X,".",1)_"."_$P(X,".",2)_$E("00",1,3-$L($P(X
,".",2))-1),DA)
Allows problem retrieval by
patient, facility, and problem
number (Nmbr); the number is used
as a string in " 000.00"
format to assure a consistent
ordering.\n
9000011,.08 DATE ENTERED 0;8 DATE (Required)
INPUT TRANSFORM:
S %DT="EX" D ^%DT S X=Y K:DT<X!(2000000>X) X
LAST EDITED: MAR 7, 1988
HELP-PROMPT: TYPE A DATE BETWEEN 1900 AND TODAY
DESCRIPTION: This is the date this problem was
entered into this file.\n
SOURCE OF DATA: 018/PREDAT
UNEDITABLE\n
9000011,.12 STATUS 0;12 SET (Required)\n
'A' FOR ACTIVE;
'I' FOR INACTIVE;
LAST EDITED: JUL 6, 1993
HELP-PROMPT: Enter the current status of this
problem, active or inactive.
DESCRIPTION: This is the current activity status\n
of this problem, whether active or
inactive; if more detail is needed,\n
a notation may be filed with
this problem.\n
SOURCE OF DATA: 018/PRSTAT
CROSS-REFERENCE: 9000011^ACTIVE^MUMPS
1)= S:$P(^AUPNPROB(DA,0),U,2) ^AUPNPROB("ACTIVE
",+$P(^(0),U,2),X,DA)=""\n
2)= K ^AUPNPROB("ACTIVE",+$P(^AUPNPROB(DA,0),U,
2),X,DA)
Allows problem retrieval by patient\n
and status, in order of entry.\n
9000011,.13 DATE OF ONSET 0;13 DATE\n
INPUT TRANSFORM:
S %DT="E" D ^%DT S X=Y K:DT<X!(1800000>X) X
LAST EDITED: JUN 13, 1993
HELP-PROMPT: TYPE A DATE BETWEEN 1880 AND TODAY
DESCRIPTION: This is the approximate date this
problem appeared, as precisely as
known.\n\n
9000011,1.01 PROBLEM 1;1 POINTER TO EXPRESSIONS
FILE (#757.01)\n
LAST EDITED: JUL 28, 1993
HELP-PROMPT: Enter the problem observed for this\n
patient.
DESCRIPTION: This field contains the
standardized text stored in the
Clinical Lexicon for this
problem.\n\n\n\n
CROSS-REFERENCE: 9000011^C
1)= S ^AUPNPROB("C",$E(X,1,30),DA)=""
2)= K ^AUPNPROB("C",$E(X,1,30),DA)\n\n
9000011,1.02 CONDITION 1;2 SET\n
'T' FOR TRANSCRIBED;
'P' FOR PERMANENT;
'H' FOR HIDDEN;
LAST EDITED: JUL 26, 1993
DESCRIPTION: This reflects the current condition
of this entry, whether transcribed
by a clerk from the paper chart,
entered or verified by a provider,
or marked as removed from the
patient's list.\n
TECHNICAL DESCR: This flag is used internally by the
DHCP Problem List; entries having
an H in this field have been
"deleted" and are maintained for
historical use but are generally
ignored. If the parameter "Verify
Transcribed Entries" is turned on
in File #125.99, entries made by a
clerk will have a T here, and a
flag will appear on the clinician's
display of the list.
P entries have been entered or
verified by a provider.\n\n
9000011,1.03 ENTERED BY 1;3 POINTER TO NEW PERSON FILE\n
(#200)\n
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter the name of the current user.\n
DESCRIPTION: This is the user who actually
entered this problem into this
file.\n\n
9000011,1.04 RECORDING PROVIDER 1;4 POINTER TO NEW PERSON FILE
(#200)\n
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter the name of the provider
responsible for the recording of
this data.\n\n
DESCRIPTION: This is the provider who either
directly entered this problem into
the file or requested it be
entered, and is initially
responsible for this problem's
inclusion on the problem list.\n\n
9000011,1.05 RESPONSIBLE PROVIDER 1;5 POINTER TO NEW PERSON FILE
(#200)\n
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter the name of the local
provider treating this problem.
DESCRIPTION: This is the provider currently
responsible for treating this
problem.\n\n
9000011,1.06 SERVICE 1;6 POINTER TO SERVICE/SECTION
FILE (#49)\n
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter the service to be associated
with this problem.
DESCRIPTION: This is the service primarily
involved in the treatment of this
problem; the DHCP Problem List
defaults this field to the service
defined in File #200 for the
Recording Provider of this
problem, upon entry of the problem.
It may later be used to categorize
problems for screening and sorting.\n\n\n\n
9000011,1.07 DATE RESOLVED 1;7 DATE\n
INPUT TRANSFORM:
S %DT="E" D ^%DT S X=Y K:Y<1 X
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter the date this problem became
resolved or inactive, as precisely
as known.
DESCRIPTION: This is the date this problem was
resolved or inactivated, as
precisely as known.\n\n\n\n
9000011,1.08 CLINIC 1;8 POINTER TO HOSPITAL
LOCATION FILE (#44)\n\n
INPUT TRANSFORM:
I $P(^(0),U,3)="C" D ^DIC K DIC S DIC=DIE,X=+Y
K:Y<0 X
LAST EDITED: DEC 23, 1993
HELP-PROMPT: Enter the clinic in which the
patient is being seen for this
problem.
DESCRIPTION: This is the clinic in which this
patient is being seen for this
problem. The problem list
may be screened based on this
value, to change one's view of the
list.\n
SCREEN: I $P(^(0),U,3)="C"
EXPLANATION: Only clinics are allowed here.\n
9000011,1.09 DATE RECORDED 1;9 DATE\n
INPUT TRANSFORM:
S %DT="E" D ^%DT S X=Y K:DT<X!(2000000>X) X
LAST EDITED: JAN 11, 1994
HELP-PROMPT: TYPE A DATE BETWEEN 1900 AND TODAY
DESCRIPTION: This is the date this problem was
originally recorded, either online
or in the paper chart; it may be
the same as, or earlier than, the
Date Entered.\n\n
9000011,1.1 SERVICE CONNECTED 1;10 SET\n
'1' FOR YES;
'0' FOR NO;
LAST EDITED: JUL 26, 1993
HELP-PROMPT: If this problem is service
connected, enter YES here.
DESCRIPTION: If the patient has service
connection on file in the DHCP
Patient file #2, this problem
specifically may be flagged as
being service connected.\n
TECHNICAL DESCR: This data will be prompted for in
the DHCP Problem List only if the
patient is indicated for service\n
connection. Non-VA sites will not
be prompted for this information.\n\n\n
9000011,1.11 AGENT ORANGE EXPOSURE 1;11 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter YES if this problem is
related to exposure to Agent
Orange.
DESCRIPTION: If this problem is related to a
patient's exposure to Agent Orange,\n
it may be flagged here.\n
TECHNICAL DESCR: This data will be prompted for in
the DHCP Problem List only if a
patient has Agent Orange exposure
indicated. Non-VA sites will not
be prompted for this information.\n\n\n
9000011,1.12 IONIZING RADIATION EXPOSURE 1;12 SET\n
'1' FOR YES;
'0' FOR NO;
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter YES if this problem is
related to exposure to ionizing
radiation.
DESCRIPTION: If this problem is related to a
patient's exposure to ionizing
radiation, it may be flagged here.\n
TECHNICAL DESCR: This data will be prompted for in
the DHCP Problem List only if the
patient has ionizing radiation
exposure indicated. Non-VA sites
will not be prompted for this
information.\n\n
9000011,1.13 PERSIAN GULF EXPOSURE 1;13 SET\n
'1' FOR YES;
'0' FOR NO;\n\n
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Enter YES if this problem is
related to a Persian Gulf exposure.\n
DESCRIPTION: If this problem is related to a
patient's service in the Persian
Gulf, it may be flagged here.
TECHNICAL DESCR: This data will be prompted for only
if a patient has Persian Gulf
service indicated. Non-VA sites
will not be prompted for this
information.\n\n
9000011,1.14 PRIORITY 1;14 SET\n
'A' FOR ACUTE;
'C' FOR CHRONIC;
LAST EDITED: FEB 1, 1994
HELP-PROMPT: You may further refine the status
of this problem by assigning it a
priority; acute problems will be
flagged on the list display.
DESCRIPTION: This is a flag to indicate how
critical this problem is for this
patient; problems marked as
Acute will be flagged on the
Problem List display.\n\n
9000011,1101 NOTE FACILITY 11;0 POINTER Multiple
#9000011.11
(Add New Entry without Asking)\n
DESCRIPTION: This is the location at which the
notes in this multiple originated.\n\n
9000011.11,.01 NOTE FACILITY 0;1 POINTER TO LOCATION FILE\n
(#9999999.06)
(Multiply asked)\n
LAST EDITED: SEP 9, 1993
HELP-PROMPT: Enter the location at which these
notes originated.
DESCRIPTION: This is the location at which the
notes in this multiple originated.\n\n\n\n\n
CROSS-REFERENCE: 9000011.11^B
1)= S ^AUPNPROB(DA(1),11,"B",$E(X,1,30),DA)="
"\n
2)= K ^AUPNPROB(DA(1),11,"B",$E(X,1,30),DA)\n\n
9000011.11,1101 NOTE 11;0 Multiple #9000011.1111
(Add New Entry without Asking)\n
DESCRIPTION: Each entry in this multiple is a
notation appended to a problem
for further clarification or
information. Data includes a
note number and status, the date
the note was added, the provider
who added it, and the actual text\n
of the note.\n
IDENTIFIED BY: NOTE NARRATIVE(#.03),\n
9000011.1111,.01 NOTE NMBR 0;1 NUMBER (Required)\n
INPUT TRANSFORM:
K:+X'=X!(X>999)!(X<1)!(X?.E1"."1N.N) X
LAST EDITED: JAN 25, 1994
HELP-PROMPT: Type a Number between 1 and
999, 0 Decimal Digits
DESCRIPTION:
This is the unique note
identifier.\n
CROSS-REFERENCE: 9000011.1111^B
1)= S ^AUPNPROB(DA(2),11,DA(1),11,"B",$E(X,
1,30),DA)=""\n
2)= K ^AUPNPROB(DA(2),11,DA(1),11,"B",$E(X,
1,30),DA)\n
CROSS-REFERENCE: 9000011.1111^AV9^MUMPS
1)=S:$D(APCDLOOK) DIC("DR")=""
2)= Q
Controls the behaviour of the
input templates used by IHS to
populate and maintain this file.\n
9000011.1111,.03 NOTE NARRATIVE 0;3 FREE TEXT (Required)
INPUT TRANSFORM:
K:$L(X)>60!($L(X)<3) X\n\n
LAST EDITED: JUL 26, 1993
HELP-PROMPT: Answer must be 3-60 characters
in length.
DESCRIPTION: Additional comments may be
entered here to further
describe this problem.\n\n\n
9000011.1111,.04 STATUS 0;4 SET (Required)\n
'A' FOR ACTIVE;
LAST EDITED: MAY 1, 1990
HELP-PROMPT: If this note is currently
ACTIVE, indicate it here.
DESCRIPTION: This flag indicates if this
note is currently active.\n
9000011.1111,.05 DATE NOTE ADDED 0;5 DATE\n
INPUT TRANSFORM:
S %DT="EX" D ^%DT S X=Y K:DT<X!(1800000>X)
X
LAST EDITED: JUL 26, 1993
HELP-PROMPT: TYPE A DATE BETWEEN 1880 AND
TODAY
DESCRIPTION: This is the date this note was
entered into this file.\n\n
9000011.1111,.06 AUTHOR 0;6 POINTER TO NEW PERSON
FILE (#200)\n
LAST EDITED: MAR 30, 1993
HELP-PROMPT: Enter the name of the provider
who authored the text of this
note.
DESCRIPTION: This is the provider who
authored the text of this note.\n\n
FILES POINTED TO FIELDS\n
EXPRESSIONS (#757.01) PROBLEM (#1.01)\n
HOSPITAL LOCATION (#44) CLINIC (#1.08) ICD DIAGNOSIS (#80)
DIAGNOSIS (#.01)\n\n
LOCATION (#9999999.06) FACILITY (#.06)
NOTE FACILITY:NOTE FACILITY
(#.01)\n
NEW PERSON (#200) ENTERED BY (#1.03)
RECORDING PROVIDER (#1.04)
RESPONSIBLE PROVIDER (#1.05)
NOTE:AUTHOR (#.06)\n
PATIENT/IHS (#9000001) PATIENT NAME (#.02)\n
PROVIDER NARRATIVE (#9999999.27) PROVIDER NARRATIVE (#.05)\n
SERVICE/SECTION (#49) SERVICE (#1.06)\n
INPUT TEMPLATE(S): APCD FUD PROB OCT 23, 1987 USER #0
PCC Data Entry - Used to edit uncoded ICD diagnoses in the
Problem file.\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):", "", "", ""], ["327", "DBIA327", "File", "1", "1994/01/11", "APPROVED", "Active", "Private", ".401", "
Laboratory V5.2 (only V5.2) is granted the following
exemption:\n
The laboratory is supplying a pre release 5.2 patch. The patch will allow the
site to mimic the conversion process required for V5.2 install. As a part of
the process a FileMan sort template is created of all providers the software
was unable to repoint to VA(200.\n
The creation of the sort template is done with a DIC call and a DR string. We
are not aware of a method to load the actual data. Therefore, this function is
hard coded.\n
The exemption is only required for the one time conversion process. Listed
below is the actual code involved. Please advise of any suggestion you feel
will be of benefit.\n
EXCEPT(LRFILE,LRD0) ;- LOGS EXCEPTIONS FROM THE CONVERSIONS OF DATA FROM 6
A ND 16
; exceptions are put into a SORT template so the the site can
; then use fileman enter edit to correct problems found.
;
N DIC,LRSORT,X,Y
I '$D(^DIBT("B",LRFILE_"-EXCEPTIONS")) D ADD
I '$D(LRSORT) S LRSORT=$O(^DIBT("B",LRFILE_"-EXCEPTIONS",0))
S ^DIBT(LRSORT,1,LRD0)=""
Q
;
ADD ; add a new sort template to be used for exception logging and editing
N X,Y
S DIC="^DIBT(",DIC(0)="L",DIC("DR")="2///^S X=""T"";4///^S X=$P(LR
FILE," "-"",2);5///^S X=0;"
S X=LRFILE_"-EXCEPTIONS" D FILE^DICN S LRSORT=+Y
Q\n", "", "", ""], ["328", "DBIA328", "Routine", "OUTPATIENT PHARMACY", "1994/01/11", "APPROVED", "Active", "Private", "", "
Routine call to POT^PSOCOPAY to pass the DFN, the
internal entry number for the patient and returns a number for 30 days Rx
supplies.\n\n
Input Variable: DFN-the patient's internal entry number\n
Output Variable: X-a number, of 30 day supplies that a patient has
for potential bills.\n", "", "PSOCOPAY", ""], ["329", "DBIA329-A", "Routine", "1", "1994/01/12", "APPROVED", "Active", "Private", "", "", "", "DIP", ""], ["330", "PSOHCSUM", "Routine", "OUTPATIENT PHARMACY", "1994/01/12", "APPROVED", "Active", "Controlled Subscription", "", "
Provides a list of active Rxs
(Active/Non-Verified/Hold/Suspend/Provider Hold) and Non-VA MEDS (Not
dispensed by VA) sorted in the reverse fill date order for a given DFN.\n
Revision History:
- Added 3/4/25 effective with PSO*7*650 and OR*3*561 to add the Complex Doses
for Non-VA medications.", "", "PSOHCSUM", "2025/03/04"], ["331", "DBIA331", "Other", "KERNEL", "1994/01/12", "APPROVED", "Active", "Private", "", "
An enhancement patch will be issued to add the most
recent lab results to the Action Profile. If the pharmacy supervisor wants the
lab data printed, he/she selects the new option to select the drug, specimen
type, and number of days back to search for lab test results. An option will
be added to the pharmacy supervisor's menu. Since only one option and menu
item need to be added to the OPTION (#19) file, we would like to add them by
using DIC calls. We would prefer not to send inits only to add the option.\n
Checks are made in the routine to assure that the site is running version 6.0,
the option is installed only once, there are no other options with the same
name, and the supervisor's menu exist. The user may run the routine many times
and only install the option and menu item once.", "", "", ""], ["332", "DBIA332", "File", "KERNEL", "1994/01/14", "APPROVED", "Active", "Private", "200", "
The Radiology/Nuclear Medicine package is granted this
DBIA to use field 53.4 of the New Person File(#200).\n", "", "", ""], ["333", "DBIA333-A", "File", "LAB SERVICE", "1994/01/14", "APPROVED", "Active", "Controlled Subscription", "60", "
Outpatient Pharmacy is granted a temporary integration
agreement with Laboratory to obtain results for a given lab test specimen type
within a date range. This data may be used many different ways. Current uses
are clozapine monitoring, printing on action profile, and drug usage
evaluation.\n
GLOBAL MAP DATA DICTIONARY #60 -- LABORATORY TEST FILE STORED IN ^LAB(60,
SITE: BIRMINGHAM ISC
^--------------------------------------------------------------------------
^LAB(60,D0,0)= (#.01) NAME [1F] ^^^^ (#5) LOCATION (DATA NAME) [5F] ^
^LAB(60,D0,.2)= (#400) DATA NAME [1P] ^ ^LAB(60,D0,1,D1,0) = ^^^^^^ (#6) UNITS
[7F] ^\n
DURATION: Till next version--LAB will incorporate an HL7 exchange", "", "", ""], ["334", "DBIA334", "File", "KERNEL", "1994/01/14", "APPROVED", "Active", "Private", "200", "\n\n
Outpatient Pharmacy is granted permission to enter/edit the following fields.\n
File: New Person (#200)\n
Field # Node;Piece Field Name
.111 .11;1 STREET ADDRESS 1
.112 .11;2 STREET ADDRESS 2
.113 .11;3 STREET ADDRESS 3
.114 .11;4 CITY
.115 .11;5 STATE
.116 .11;6 ZIP CODE
.131 .13;1 PHONE
.132 .13;2 OFFICE PHONE
.133 .13;3 PHONE #3
.134 .13;4 PHONE #4
.141 .14;1 ROOM\n", "", "", ""], ["335", "DBIA335-A", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
Pharmacy Prescription Practices Prototype is granted
this DBIA with Scheduling to make the following calls:\n
I. Direct read access to the SC global.\n
A. ^SC("AC","C",CLINIC) -> Used to obtain a list of all
clinics currently in the file.\n
B. ^SC(CLINIC,"S",DATE) -> Used to check for patients
scheduled for clinic on a specified date.", "", "", ""], ["336", "DBIA336", "Routine", "AUTOMATED INFO COLLECTION SYS", "1994/01/18", "APPROVED", "Active", "Private", "", "
The Problem List Application is granted permission to
use the function calls, "$$GETFORM^IBDF18" and "$$COPYFORM^IBDF18". These
calls are used to collect common problem lists defined under the Encounter
Form Utility. By replicating the previously entered lists, the clinician is
spared duplicate entry.
$$GETFORM^IBDF18()
Input: NONE
Returned: <form iew>^<form name>
$$COPYFORM^IBDF18(FORM,ARY)
Input: FORM= ien of form that has clinic common problem list
ARY= Location where clinic common problem list should
be copied to. ARY is accessed via indirection,
as in @ARY@(1) for the first entry
Returns: Length of the list\n", "", "IBDF18", ""], ["337", "DBIA337", "Routine", "HEALTH SUMMARY", "1994/01/18", "APPROVED", "Active", "Private", "", "
The Problem List Application will produce three (3)
Problem List components for the Health Summary Application. These components
are: ACTIVE PROBLEMS, INACTIVE PROBLEMS, and FULL PROBLEM LIST. In order to
load the new components of the Ad Hoc Summary on to existing systems, the
Problem List Application requests permission to use the entry point:
ENPOST^GMTSLOAD
Input: INCLUDE=0
Returned: Nothing", "", "GMTSLOAD", ""], ["338", "DBIA338", "File", "HEALTH SUMMARY", "1994/01/18", "APPROVED", "Active", "Private", "142.1", "
The Problem List Application is granted permission to
add three (3) components to the Health Summary Application's Health Summary
Component File (142.1). They are: ACTIVE PROBLEMS, INACTIVE PROBLEMS and FULL
PROBLEM LIST. The new components will be added in a post-init using ^DIC.
The components are installed using code provided to us by the Health Summary
developers. FileMan variables DIC, DIC(0), DLAYGO, DINUM, and X are set to
add each component to the Health Summary Component file if it's not already
there; entry numbers 59-61 were given to the Problem List pkg to use for these
components. Once entered into the file, DR is set and DIE called to stuff in
the values of the other fields.\n
The following was added on 4/12/94:\n
To support the addition of new components to the Health Summary Application,
the following actions are taken in the post-init.\n
1. Routine GMPLHSPL is renamed to GMTSPLST.\n
2. The post-init sets ^GMT(142.1,DA,3.5 nodes.", "", "", ""], ["339", "DBIA339", "Routine", "LEXICON UTILITY", "2003/05/19", "", "Retired", "Private", "", "\n
The Problem List Application has permission to use the entry point ^GMPTDUSR.
This entry point will be used to setup user-specific look-up defaults.\n", "", "GMPTDUSR", ""], ["340", "DBIA340", "Routine", "LEXICON UTILITY", "2003/05/19", "", "Retired", "Private", "", "", "", "GMPTSET", ""], ["341", "DBIA341", "Routine", "SCHEDULING", "2003/06/25", "APPROVED", "Active", "Private", "", "
The Problem List Application is granted permission from
Scheduling to use the entry point "DIS^SDROUT2". This will display a
patient's service connected data for the clinician.
DIS^SDROUT2
Input: DFN
Returned: Display of patient's service-connected data.\n", "", "SDROUT2", ""], ["342", "DBIA342", "File", "KERNEL", "1994/01/24", "APPROVED", "Active", "Private", "200", "
The Problem List Application is granted permission for
the addition of the following fields to the NEW PERSON FILE (^VA(200,)). Also
granted is permission to read and write to these fields as appropriate. These
fields are used to tailor the Problem List Application for individual use.\n
125 PRIMARY VIEW
125.01 PROBLEM LIST SEARCH FILTER
125.02 PROBLEM LIST DISPLAY CODES
125.03 PROBLEM VOCABULARY
125.1 PROBLEM SELECTION LIST\n", "", "", ""], ["343", "DBIA343", "Routine", "KERNEL", "1994/01/25", "APPROVED", "Active", "Private", "", "
It is agreed that MailMan can call XQSRV for servers.\n
MailMan sends XQSRV: XMZ, XMXX, XMFROM, XMCHAN, XMSEN, XMREC & XMB("TYPE").\n", "", "XQSRV", ""], ["344", "DBIA344-A", "File", "KERNEL", "1994/01/31", "", "Retired", "Private", "101", "
The following DBIA is granted between the Unwinder and
OE/RR.\n
Read Access to File 101: The XQOR routines navigate the Protocol file (101).
To provide this navigation, XQOR needs read access to File 101.", "", "", ""], ["345", "DBIA345-A", "File", "1", "1994/02/02", "APPROVED", "Active", "Private", "", "\n
Read only access for the ^DD( Global\n
Read ^DD(FN), where FN is a file number, to determine the
existence of a file prior to initiating a look-up (GMPTA4).\n
Read ^DD(757*,FLD in indexing routines to obtain the location
(node/piece) of data in Clinical Lexicon files 757-757.3 prior to eXecuting
Set/Kill logic (GMPTNDX2).", "", "", ""], ["346", "DBIA346-A", "File", "TOOLKIT", "1994/02/04", "APPROVED", "Active", "Private", "8984.1", "\n
Read only access to ^XT(8984.* globals for $D checks in the Environment
Check routine prior to installing the Clinical Lexicon (GMPTIENV).\n
i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not
found" K DIFQ Q\n
Read/Write access to ^XT(8984.* global in Post-Init routines to setup
the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST).\n
i.e.,\n
a. Seeding the Local Look-Up file #8984.4 with the Clinical
Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT
display routine.\n
b. Seeding the Synonym file #8984.3 with Cancer as a sample
synonym for Carcinoma\n
c. Seeding the Short Cut file #8984.2 with DM II as a sample
short cut for Diabetes Mellitus, Non-Insulin Dependent", "", "", ""], ["347", "DBIA347", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/02/07", "APPROVED", "Active", "Private", "", "
The Problem List Application has permission to use of
the entry point "IN^OR" for patient selection, using the OE/RR patient lookup
engine and resetting of all needed OE/RR patient variables within the OE/RR
context. The OE/RR variable ORVP is checked for (via $D) to see if PL was
invoked from within OE/RR; if so, and the user wishes to switch to a different
patient, this call will pass control to OE/RR to do the prompting and
resetting of any important OE/RR patient variables. Problem List only
references ORVP on return. It should be noted that the call to IN^OR is only
made if the Problem list application is being selected from within the Order
Entry application itself. Therefore the PL application simply has a screen to
check for ORVP. If it exists it knows that it is within OE/RR and and only
calls IN^OR if the SP (select Patient) action is selected before exiting the
PL mode. This call updates the variables within OE so that it will not return
to the previous patient when PL is exited. OE/RR is responsible for setting
and killing all OR variables.\n
IN^OR
Input: ORVP
Returned: ORVP", "", "ORVP", ""], ["348", "DBIA348", "File", "REGISTRATION", "1994/02/11", "APPROVED", "Active", "Private", "2", "
Problem List has permission to access File #2, Field
#.32201. This will allow supported reference to draw Persian Gulf duty
information from the Patient File.", "", "", ""], ["349", "DBIA349", "Routine", "HEALTH SUMMARY", "1994/02/17", "APPROVED", "Active", "Private", "", "", "", "GMTSDVR", ""], ["350", "DBIA350", "File", "REGISTRATION", "1994/02/28", "APPROVED", "Active", "Private", "2", "
I. Direct read access to the DPT global.\n
A. ^DPT("SSN") -> Used to obtain a list of all patient SSN's
currently on file. These SSN's are then compared to the
SSN's on the MPD CDROM to check for visits to other
hospitals.\n
B. ^DPT(DFN) -> Used to verify that a patient is in the
file.\n
C. ^DPT(DFN,"S",DATE,0) -> Used to verify that a clinic
appointment has not been canceled.\n
II. The addition of a Mumps cross-reference to the SSN field for
the purpose of setting the SSN in the PPP NEW SSN file. Any
new SSN's will be checked at night for visits to other
hospitals and then deleted from the PPP NEW SSN file.\n
We suggest the Mumps cross-reference be implemented as
follows:\n
SET -> S PPP=X,X="PPPFMX" X ^%ZOSF("TEST") D:$T SNSSN^PPPFMX
S X=PPP K PPP
KILL -> S PPP=X,X="PPPFMX" X ^%ZOSF("TEST") D:$T KNSSN^PPPFMX
S X=PPP K PPP\n
The referenced routines are as follows:\n
SNSSN ;
N PPPNOD0,PPPTR
N ZTRTN,ZTIO,ZTDTH,ZTDESC,ZTSAVE
;
; Check that this is either an edit or a new entry to avoid
; setting during a re-index of the Patient file.
; PPPOK is defined in the kill logic below if the new entry
; does not equal the old.
; DPTDFN is defined in the Patient Registration routines.
;
I ($D(PPPOK))!($D(DPTDFN)) D
.S PPPNOD0=$G(^PPP(1020.7,0))
.Q:PPPNOD0=""
.;
.; Get the File Descriptor Node for updating.
.;
.S PPPTR=$P(PPPNOD0,"^",4)
.;
.; Set the entry and the "B" Xref
.;
.S ^PPP(1020.7,DA,0)=X
.S ^PPP(1020.7,"B",X,DA)=""
.;
.; Update the Descriptor node.
.;
.S $P(PPPNOD0,"^",3)=DA
.S $P(PPPNOD0,"^",4)=PPPTR+1
.S ^PPP(1020.7,0)=PPPNOD0
.;
.; Task out the MPD lookup.
.;
.S ZTRTN="NEWSSN^PPPBLD5"
.S ZTIO=""
.S ZTDTH=$H
.S ZTDESC="NEW SSN/MPD ROUTINE"
.S ZTSAVE("PPPSSN")=PPP
.S ZTSAVE("PPPIFN")=DA
.D ^%ZTLOAD
;
K PPPOK
Q\n\n
KNSSN ;
N PPPNOD0
;
; Check that this is an edit and not a re-index.
;
I X'=$P($G(^DPT(DA,0)),"^",9) D
.S PPPOK=1
.;
.; Check that the node currently exists, kill it if it does.
.;
.I $D(^PPP(1020.7,"B",PPP)) D
..K:$D(^PPP(1020.7,DA)) ^(DA)
..K:$D(^PPP(1020.7,"B",PPP,DA)) ^(DA)
..;
..; If the record count is alredy 0 then quit.
..;
..S PPPNOD0=^PPP(1020.7,0)
..Q:+$P(PPPNOD0,"^",4)=0
..S $P(PPPNOD0,"^",4)=$P(PPPNOD0,"^",4)-1
..S ^PPP(1020.7,0)=PPPNOD0", "", "", ""], ["351", "DBIA351-A", "File", "KERNEL", "1994/02/28", "", "Retired", "Private", "19", "
Read Access to File 19: When an Option that is a
protocol (O) or protocol menu (Q) is encountered by menu manager, control is
turned over to XQOR. XQOR needs to have read access to File 19 to be able to
provide the navigation of these protocols. This agreement would replace DBIA
#5, which was between OE/RR and Menu Driver.", "", "", ""], ["352", "DBIA352", "File", "1", "1994/02/28", "APPROVED", "Active", "Private", "", "
PCE (PX) is granted permission to execute the DD nodes
for completing cross-references in the 9000001 file from within
cross-reference logic on the Social Security (.09) field in the Patient file.
There is a Regular "B" cross-reference on the .01 field (NAME) of the
PATIENT/IHS file (9000001). There is also a Regular "D" cross- reference on
the .02 field of the 9000001.41 Health Record Number multiple. Since the
fields in the 9000001 file are being populated from during the execution of
the Patient File (2) PX09 cross- reference, the DD logic for setting these
cross-references is being handled by executing the 9000001 and 9000001.41 DD
nodes with the set and kill logic.\n
Routine PXXDPT executes the set logic of the 'B' cross reference of file
9000001, (Patient/IHS File), field .01 (Name).\n
It also executes the set and kill logic of the 'D' whole file cross reference
of subfile 9000001.41, (Health Record Fac), field .02 (Health Record No.)\n
In V21 of FileMan, the entry points in ^DIK that reindex cross references are
reentrant. Thus, direct execution of set/kill logic will not be necessary.\n
Also PCE's Debugging Utility does a Global Read in the form of
'$D(^DD(2,.09,1,800)) to check that the cross reference to update the
PATIENT/IHS file (#9000001) exists.", "", "", ""], ["353", "DBIA353", "Routine", "IFCAP", "1994/02/28", "APPROVED", "Active", "Private", "", "", "", "PRCPUX1", ""], ["354", "DBIA354", "Routine", "PROBLEM LIST", "1994/02/28", "APPROVED", "Active", "Private", "", "", "", "GMPLENFM", ""], ["355", "DBIA355", "File", "SCHEDULING", "1994/03/03", "APPROVED", "Active", "Private", "2", "
Read access to the following fields and
cross-references:\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
**APPOINTMENT DATE/TIME PATIENT
1 1900 2
2 .001 2.98\n
**APPOINTMENT STATUS PATIENT
1 1900 2
2 3 2.98\n
**APPOINTMENT TYPE PATIENT
1 1900 2
2 9.5 2.98\n
**APPT. CANCELLATION REASON PATIENT
1 1900 2
2 16 2.98\n
**CLINIC PATIENT
1 1900 2
2 .01 2.98\n
(The above fields related to field 1900 will be eliminated with the scheduling
redesign.) **DATE OF ENROLLMENT PATIENT\n
XREF: AEB", "", "", ""], ["356", "DBIA356", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
Read access to the following fields and
cross-references.\n\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
**PATIENT HOSPITAL LOCATION
1 1900 44
2 2 44.001
3 .01 44.003\n
**DATA GLOBAL HOSPITAL LOCATION\n
XREF: ^SC(D0,"S",D1,1,D2,...
^ ^
| |-- PATIENT
|-- APPOINTMENT\n", "", "", ""], ["357", "DBIA357", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Private", "2", "
Read access to the following fields and
cross-references.\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
DATE OF DEATH PATIENT
1 .351 2\n
DISPOSITION PATIENT
1 1000 2
2 6 2.101\n
LOG IN DATE/TIME PATIENT
1 1000 2
2 .01 2.101\n
LOG IN STATUS PATIENT
1 1000 2
2 1 2.101\n
LOG OUT DATE/TIME PATIENT
1 1000 2
2 5 2.101\n
PURPOSE OF VISIT PATIENT
1 1900 2
2 9 2.98\n
REASON FOR LATE DISPOSITION PATIENT
1 1000 2
2 8 2.101\n
SERVICE CONNECTED PERCENTAGE PATIENT
1 .302 2\n
SERVICE CONNECTED? PATIENT
1 .301 2\n
SPINAL CORD INJURY PATIENT
1 $ 57.4 2\n
TYPE OF BENEFIT APPLIED FOR PATIENT
1 1000 2
2 2 2.101\n
TYPE OF CARE APPLIED FOR PATIENT
1 1000 2
2 2.1 2.101\n
CROSS REFERENCES:\n
DATE OF BIRTH PATIENT\n
XREF: ADOB\n
SEX PATIENT\n
XREF: ASX\n
**DATE OF ENROLLMENT PATIENT\n
XREF: AEB\n
DATE OF DEATH PATIENT\n
XREF: AEXP1\n
LOG IN DATE/TIME PATIENT\n
XREF: ADIS\n", "", "", ""], ["358", "DBIA358", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Controlled Subscription", "405", "
Read access to the following fields and
cross-references.\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
TYPE OF MOVEMENT PATIENT MOVEMENT
1 .04 405\n
WARD LOCATION PATIENT MOVEMENT
1 .06 405\n
TRANSACTION TYPE PATIENT MOVEMENT
1 .02 405\n
ROOM-BED PATIENT MOVEMENT
1 .07 405\n
ADMITTED FOR SC CONDITION? PATIENT MOVEMENT
1 .11 405\n
ADMITTING REGULATION PATIENT MOVEMENT
1 .12 405\n
ATTENDING PHYSICIAN PATIENT MOVEMENT
1 .19 405\n
DIAGNOSIS [SHORT] PATIENT MOVEMENT
1 .1 405\n
FACILITY TREATING SPECIALTY PATIENT MOVEMENT
1 .09 405\n
MAS MOVEMENT TYPE PATIENT MOVEMENT
1 .18 405\n
MOVEMENT DATE/TIME PATIENT MOVEMENT
1 .01 405\n
PRIMARY CARE PHYSICIAN PATIENT MOVEMENT
1 .08 405\n", "", "", ""], ["359", "DBIA359", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Private", "45", "\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
PATIENT PTF
1 .01 & 45\n
PTF ADMISSION DATE PTF
1 2 45\n
PTF DISCHARGE DATE PTF
1 70 45\n
PTF DISCHARGE SPECIALTY PTF
1 71 45\n
PTF DRG PTF
1 9 45\n
PTF DXLS PTF
1 79 45\n
PTF ICD 10 PTF
1 79.24 45\n
PTF ICD 2 PTF
1 79.16 45\n
PTF ICD 3 PTF
1 79.17 45\n
PTF ICD 4 PTF
1 79.18 45\n
PTF ICD 5 PTF
1 79.19 45\n
PTF ICD 6 PTF
1 79.201 45\n
PTF ICD 7 PTF
1 79.21 45\n
PTF ICD 8 PTF
1 79.22 45\n
PTF ICD 9 PTF
1 79.23 45\n
PTF PROCEDURE 1 PTF
1 45.01 45\n
PTF PROCEDURE 2 PTF
1 45.02 45\n
PTF PROCEDURE 3 PTF
1 45.03 45\n
PTF PROCEDURE 4 PTF
1 45.04 45\n
PTF PROCEDURE 5 PTF
1 45.05 45\n
PTF TYPE OF DISPOSITION PTF
1 72 45\n
PTF WARD AT DISCHARGE PTF
1 2.2 45\n
SURGERY/PROCEDURE DATE PTF
1 401 45
2 .01 45.01\n
OPERATION CODE 1 PTF
1 401 45
2 8 45.01\n
OPERATION CODE 2 PTF
1 401 45
2 9 45.01\n
OPERATION CODE 3 PTF
1 401 45
2 10 45.01\n
OPERATION CODE 4 PTF
1 401 45
2 11 45.01\n
OPERATION CODE 5 PTF
1 401 45
2 12 45.01\n
CROSS REFERENCES:\n
CLOSE OUT DATE PTF CLOSE OUT\n
XREF: AC\n
DATA GLOBAL PTF\n
XREF: ^DGPT(D0,"S",D1,...
^
|-- SURGERY/PROCEDURE DATE", "", "", ""], ["360", "DBIA360", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Private", "405.3", "
Read access to the following fields:\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n\n
MAS MOVEMENT TRANSACTION TYPE MAS MOVEMENT TRANSACTION TYPE
1 .01 405.3\n", "", "", ""], ["361", "DBIA361", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Private", "37", "
Read access to the following fields:\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n\n
NAME DISPOSITION
1 .01 37\n", "", "", ""], ["362", "DBIA362", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Controlled Subscription", "45.7", "
Read access to the following fields:\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
NAME FACILITY TREATING SPECIALTY
1 .01 45.7\n
FACILITY TREATING SPECIALTY SERVICE
1 2 45.7\n\n", "", "", ""], ["363", "DBIA363", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Controlled Subscription", "405.2", "
Read access to the following fields:\n\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
NAME MAS MOVEMENT TYPE
1 .01 405.2\n", "", "", ""], ["364", "DBIA364", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "409.1", "
Read access to the following fields:\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
NAME APPOINTMENT TYPE
1 .01 409.1\n", "", "", ""], ["365", "DBIA365", "File", "DRG GROUPER", "1994/03/03", "APPROVED", "Retired", "Private", "80", "
Read access to the following fields:\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
CODE NUMBER ICD DIAGNOSIS
1 0 .01 80\n", "", "", ""], ["366", "DBIA366", "File", "REGISTRATION", "1994/03/03", "APPROVED", "Active", "Private", "80.1", "
Read access to the following Fields:\n
FIELDS:\n
ELEMENT FILE
DD LEVEL FIELD # DD NUMBER\n
CODE NUMBER ICD OPERATION/PROCEDURE
1 .01 80.1", "", "", ""], ["367", "DBIA367", "Routine", "LIST MANAGER", "1994/03/09", "APPROVED", "Active", "Private", "", "
Request: Use of the routine calls REFRESH^VALM and
RESET^VALM4:VALMCC\n
Input: none
Output: none Purpose: These calls are used to refresh the screen and reset
the
scrolling area while program control remains within an
action (as opposed to performing the same action when exiting
an action, which is accomplished by setting VALMBCK="R").\n
Request permission to set the variable VALM("PROTOCOL"). The purpose of
setting this variable is to be able to define the specific protocol to be
executed for a list template, as opposed to defining three identical list
templates, all with different protocol menus.\n
Resetting VALM("PROTOCOL") resets the protocol menu. This allows having the
same list manager definitions for a screen that may have different input
capabilities, for example one with input and one just view only actions.\n
RESET^VALM4 can ONLY be called if VALMCC is high(1)\n
The context for these calls are as follows: The calls will be made within a
List Manager application, specifically within various options of the Encounter
Form Utilities. The reason for making the calls is that we want to be able to
display an encounter form in the top part of the screen while having a
dialogue with the user in the bottom part of the screen. The problem is that
it is necessary to call FileMan at certain points within the dialogue. FileMan
assumes it has the entire screen at its disposal, so when it communicates with
the user the display#is likely to scroll out of the scrolling area on the
bottom of the screen, so the user is unable to read what FileMan displays. To
avoid that, what we do is: 1) Everywhere FileMan is called in the situation
described above we call FULL^VALM1. That sets the scrolling area to the entire
screen. 2) When the problem point is passed and we want to continue the
dialogue with the encounter form displayed at the top we call REFRESH^VALM to
redraw the screen. Then we call RESET^VALM4 to reset the scrolling area so
that the dialogue can occur on the bottom of the screen with the form
displayed at the top.\n
VALMCC is an input variable to RESET^VALM4. VALMCC must test true or
RESET^VALM4 should not be called. There are dozens of variables that are set
by the List Manager, but those are part of the internal workings of the List
Manager and are not the concern of this application. There are some List
Manager variables that the application is responsible for setting, but those
are well documented by the List Manager, i.e., they are not specific to
calling these entry points.\n
The context is that the List Manager has been called. Then, from within the
List Manager, the user has selected an action, which invokes a protocol. The
protocol invokes a routine, which is where those calls are made.", "", "VALM", ""], ["368", "DBIA368", "File", "DRG GROUPER", "1994/03/09", "", "Retired", "Private", "80", "\n
Request to directly reference the following fields in the ICD DIAGNOSIS
(#80) file:\n
Field Name (#) Location Reason
===================================================================
DIAGNOSIS (3) 0;3 Print and display the diagnosis name
USE ONLY WITH SEX (9.5) 0;10 Bill diagnoses appropriate for the
patient's sex
DESCRIPTION (10) 1;1 Print and display the diagnosis
description
INACTIVE FLAG (100) 0;9 Only active diagnoses can be billed\n", "", "", ""], ["369", "DBIA369", "File", "DRG GROUPER", "1994/03/09", "", "Retired", "Private", "80.1", "\n
Request to directly reference the following fields in the ICD
OPERATION/PROCEDURE (#80.1) file:\n
Field Name (#) Location Reason
===================================================================
OPERATION/PROCEDURE (4) 0;4 Print and display the procedure name
INACTIVE DATE (102) 0;11 Only active procedures are billable\n", "", "", ""], ["370", "DBIA370", "File", "DRG GROUPER", "1994/03/09", "APPROVED", "Retired", "Private", "80.2", "\n
Request to store pointers to the DRG (#80.2) file from
Integrated Billing. The pointers are needed to retrieve
data from the file at the time that claims are generated.\n
Request to directly reference the following fields in the DRG (#80.2)
file:\n
Field Name (#) Location Reason
===================================================================
NAME (.01) 0;1 Print and display the DRG number
DESCRIPTION (1) ^ICD(ien,1,1,0) Print and display the DRG name\n", "", "", ""], ["371", "DBIA371", "Routine", "DRG GROUPER", "1994/03/09", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ICDDRG", "2014/07/18"], ["372", "DBIA372", "File", "KERNEL", "1994/03/09", "APPROVED", "Active", "Private", "4", "
Integrated Billing requests permission to add entries
to the INSTITUTION (#4) when creating bills. The user is
required to hold the IB SUPERVISOR security key to add entries into file
#4.", "", "", ""], ["373", "DBIA373", "File", "PROSTHETICS", "1994/03/15", "APPROVED", "Active", "Private", "660", "", "", "", ""], ["374", "DBIA374", "File", "PROSTHETICS", "1994/03/15", "APPROVED", "Active", "Controlled Subscription", "661", "", "", "", ""], ["375", "DBIA375", "File", "IFCAP", "2003/09/02", "", "Retired", "Private", "424", "\n
Request a one time DBA agreement for patch RMRP*2*4.\n
When a Prosthetics New Purchase is initiated the estimated
amount of the Purchase is calculated using the %Discount
and the total cost for all items or services. On occasion
the estimated amount may be a four decimal digit
(e.g. 165.4321) after the calculation is done. Once the
calculation is completed the New Purchase is posted to
IFCAP and a 1358 Daily Record entry is created.
When the Prosthetics New Purchase Estimated amount is
posted to IFCAP it is rejected by Fileman because the Data
Dictionary for the Authorization amount field for file 424 will
only accept a two decimal digit number. A incomplete 1358
Daily Record is created and the Authorization number is
passed back to the Prosthetics New Purchase.\n
Upon Close out of the Prosthetics Purchase an error message
'Insufficient authorization funds to post payment' is
displayed and the Prosthetics Purchase cannot be closed out
because the estimated amount was not posted when the
Purchase was initiated.\n
Patch RMPR*2*4 corrects this problem by using $JUSTIFY to
ensure that the Estimated amount for the initial Prosthetics
Purchase is rounded to a two decimal digit.\n
Patch RMPR*2*4 also has a conversion routine that will
correct the Phantom 1358 entries and allow the Prosthetics
Service to close out purchases associated with the
incomplete 1358 Daily Record entries.\n
The Conversion Routine RMPSCON finds all 1358 daily record
entries created by the DHCP Prosthetics Package that are
missing the authorization balance. Routine RMPSCON reads
and updates the following fields in Files #442 (PROCUREMENT
AND ACCOUNTING TRANSACTIONS), 442.3 (PURCHASE ORDER STATUS),
424 (1358 DAILY RECORD FILE), and 424.1 (1358 AUTHORIZATION
DETAIL).", "", "", ""], ["376", "DBIA376", "File", "IFCAP", "1994/03/15", "APPROVED", "Active", "Private", "442.3", "
See DBIA375.", "", "", ""], ["377", "DBIA377", "File", "IFCAP", "1994/03/15", "APPROVED", "Active", "Private", "424.1", "
See DBIA375", "", "", ""], ["378", "DBIA378", "Routine", "IFCAP", "1994/03/15", "APPROVED", "Active", "Private", "442", "
See DBIA375", "", "PRCH58", ""], ["379", "DBIA379", "Routine", "HINQ", "1994/03/15", "APPROVED", "Active", "Private", "", "
This call allows billing clerks to place requests for
HINQs for patients with unverified eligibility who are going to be billed.\n", "", "DVBHQZ4", ""], ["380", "DBIA380", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
The following function calls are made to the routine
PRCAFN. The input X for each call is the internal entry number of an entry in
the BILL/CLAIMS (#399) file, which is dinumed to the ACCOUNTS RECEIVABLE
(#430) file. Each function will return -1 if a legitimate value cannot be
returned. Also note that these functions only work for categories of
receivables which are not PATIENT or MEANS TEST PATIENT (except for the PST,
PUR, and CATN functions).", "", "PRCAFN(X)", ""], ["381", "DBIA381", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
This Accounts Receivable routine is the entry point for
the Returned Bill List output. The routine is invoked by the Integrated
Billing option IB RETURN BILL LIST.", "", "PRCALST", ""], ["382", "DBIA382", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
This routine call displays the number of bills that
have been returned to the service from Fiscal. There is no variable input
required to make the call. This routine is invoked as an Entry Action of the
following Integrated Billing menu options:\n
IB BILLING CLERK MENU IB BILLING SUPERVISOR MENU IB RETURN BILL MENU", "", "PRCAUT2", ""], ["383", "DBIA383", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
This call is used in Pharmacy copay exemption
processing to cancel Pharmacy copay charges who become exempt from copay.", "", "PRCAX(DFN,BEG,END,.ERR)", ""], ["384", "DBIA384", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
This call is made just prior to passing a claim to the
Accounts Receivable package. This routine call performs a check on all data
required to establish a receivable and passes errors back to Integrated
Billing.", "", "PRCASVC6", ""], ["385", "DBIA385", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
This call is used to pass a new or returned bill to the
Accounts Receivable package.\n
This call is made right after the call D ^PRCASVC6, if that call returns
PRCASV("OKAY") as a positive number.", "", "PRCASVC", ""], ["386", "DBIA386", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
This call sets up a stub receivable in Accounts
Receivable. The internal entry number for the receivable is used as the
internal entry number of the bill in the BILL/CLAIMS (#399) file.", "", "PRCASVC3", "2010/08/06"], ["387", "DBIA387", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
These calls are made when a bill is cancelled in
Integrated Billing. If the receivable has the AR Status of New Bill, Bill
Incomplete, or Returned From AR (NEW), the bill is cancelled using the call D
CANCEL^PRCASVC1; otherwise, the bill is amended using the call D
AMEND^PRCASVC1.", "", "PRCASVC1", ""], ["388", "DBIA388", "Routine", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "", "
This call is used to find the internal entry number for
a bill in file #430, so it may be used as input to the function
$$PUR^PRCAFN(X). Note that a check is done to determine if the routine RCFN03
exists on the system before the call is made.", "", "RCFNO3(X)", ""], ["389", "DBIA389", "File", "ACCOUNTS RECEIVABLE", "1994/03/15", "APPROVED", "Active", "Private", "430", "
Integrated Billing has permission to reference this
file in a ^DIC call to do a look-up on the bill number. It also has
permission to access the following fields and cross-references:\n
Revision History:
11/22/24 - Added CURRENT STATUS Field (#8) to ^PRCA(430,BN,0) Global
Reference for Automated Community Claims (ACC) project for use in IB*2.0*770.", "", "", ""], ["390", "DBIA390", "File", "IFCAP", "1994/03/16", "APPROVED", "Active", "Private", "442", "
See DBIA 375.", "", "", ""], ["391", "DBIA391", "File", "TOOLKIT", "1994/03/16", "APPROVED", "Active", "Private", "8984.1", "
AMIE v2.6 will be using the MTLU functionality from the
Kernel tool kit in order to do a look up on the Disability Condition file
(#31). As part of the functionality provided to the users, there needs to be
a set of distributed Keywords, Synonyms and short cuts. AMIE would like to
distribute these lists in,a post init fashion with little to no user
intervention.", "", "", ""], ["392", "DBIA392", "File", "TOOLKIT", "1994/03/16", "APPROVED", "Active", "Private", "8984.2", "
AMIE v2.6 will be using the MTLU functionality from the
Kernel tool kit in order to do a look up on the Disability Condition file
(#31). As part of the functionality provided to the users, there needs to be
a set of distributed Keywords, Synonyms and short cuts. AMIE would like to
distribute these lists in a post init fashion with little to no user
intervention.", "", "", ""], ["393", "DBIA393", "File", "TOOLKIT", "1994/03/16", "APPROVED", "Active", "Private", "8984.3", "
AMIE v2.6 will be using the MTLU functionality from the
Kernel tool kit in order to do a look up on the Disability Condition file
(#31). As part of the functionality provided to the users, there needs to be
a set of distributed Keywords, Synonyms and short cuts. AMIE would like to
distribute these lists in a post init fashion with little to no user
intervention.", "", "", ""], ["394", "DBIA394", "File", "TOOLKIT", "1994/03/16", "APPROVED", "Active", "Private", "8984.4", "
AMIE v2.6 will be using the MTLU functionality from the
Kernel tool kit in order to do a look up on the Disability Condition file
(#31). As part of the functionality provided to the users, there needs to be
a set of distributed Keywords, Synonyms and short cuts. AMIE would like to
distribute these lists in a post init fashion with little to no user
intervention.", "", "", ""], ["395", "DBIA395", "File", "1", "1994/03/23", "APPROVED", "Active", "Private", "", "
VA FileMan grants this integration request.\n
The following calls are allowed within the AMIE package. CHK+13^DVBAPLL S
DIC="^DD(8984.1,.02,""V"",",DIC(0)="Z",D="P",X=VAR1 D IX^DIC\n
CHK+19^DVBAPLL S DIC="^DD(8984.2,.02,""V"",",DIC(0)="Z",D="P",X=VAR1 D IX^DIC\n
ADDV+1^DVBAPLL Calls using ^DIC and ^DIE to update the variable pointer field
in the Local Keyword and Local Synonym file for use with MTLU. The ^DIE call
is fully compatible with the interactive way of creating variable pointer type
fields.", "", "", ""], ["396", "DBIA396", "Routine", "INTEGRATED BILLING", "1994/04/04", "APPROVED", "Active", "Private", "", "
This agreement was updated on 3/3/97 to convert it from
an 'Other' type agreement (to support IB v2.0 installation requirements with
Fee Basis) to a 'Routine' type agreement to support IB's callable routine
IBCNSP2.\n
Please note that this agreement also supercedes agreement DBIA226-C which Fee
Basis held with the Registration package.\n\n
The terms under which IB exported the Fee Basis patch FB*3*5 are listed below,
so they are not lost:\n\n
IB will transport routine FBUINS in routine IB20PT8C, and ZSave as FBUINS
during the installation process if version 3 is running and patch 5 has not
been installed.\n
Patch 5 of Fee contains the following special instructions:
- Do not apply if version 3 of Fee is installed but Version 2 has not been
installed.
- If version 3 of Fee has been installed, IB 2 will automatically apply this
patch. There is no need to apply.
- If you install version 2 of IB prior to installing version 3 of Fee, then
this patch needs to be applied prior to allowing Fee users back on the system.\n
Verification of FB*3*5 is pending this agreement.", "", "IBCNSP2", ""], ["397", "DBIA397", "File", "SCHEDULING", "1994/04/04", "APPROVED", "Active", "Private", "409.95", "\n
Request to export the following Scheduling files with the release
of Integrated Billing v2.0:\n
#409.95 PRINT MANAGER CLINIC SETUP\n
Also request read and write access for all fields in these files.
These files are used by the Print Manager to determine which
forms should be printed for each clinic.", "", "", ""], ["398", "DBIA398", "File", "SCHEDULING", "1994/04/04", "APPROVED", "Active", "Private", "409.96", "\n
Request to export the following Scheduling files with the release
of Integrated Billing v2.0:\n
#409.96 PRINT MANAGER DIVISION SETUP\n
Also request read and write access for all fields in these files.
These files are used by the Print Manager to determine which
forms should be printed for each clinic.", "", "", ""], ["399", "DBIA399", "File", "SCHEDULING", "1994/04/04", "APPROVED", "Active", "Private", "2", "", "", "", ""], ["400", "DBIA400", "File", "SCHEDULING", "1994/04/04", "APPROVED", "Active", "Private", "40.7", "", "", "", ""], ["401", "DBIA401", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
It is understood that these references will need to be
changed when Scheduling's new APIs are available.", "", "", ""], ["402", "DBIA402", "File", "SCHEDULING", "1994/04/04", "", "Under Revision", "Controlled Subscription", "409.68", "
This pointer is needed to retrieve data from this file
when a claim is being generated.", "", "", ""], ["403", "DBIA403", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "", "", "SDCO3", ""], ["404", "DBIA404", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "", "", "SDCO4", ""], ["405", "DBIA405", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "", "", "SDROUT1", ""], ["406", "DBIA406", "Routine", "SCHEDULING", "2003/06/30", "APPROVED", "Active", "Controlled Subscription", "", "", "", "SDCO21", ""], ["407", "DBIA407", "Routine", "SCHEDULING", "1994/04/04", "APPROVED", "Active", "Private", "", "", "", "SDCOU2", "2007/03/15"], ["408", "DBIA408", "File", "SCHEDULING", "1994/04/04", "", "Retired", "Private", "409.5", "
It is understood that these references will need to be
changed when Scheduling's new APIs are available.", "", "", ""], ["409", "DBIA409", "File", "SCHEDULING", "1994/04/04", "APPROVED", "Active", "Controlled Subscription", "409.42", "", "", "", ""], ["410", "DBIA410", "File", "SCHEDULING", "1994/04/04", "APPROVED", "Active", "Private", "409.72", "", "", "", ""], ["411", "DBIA411", "File", "SCHEDULING", "1994/04/04", "", "Retired", "Private", "409.43", "", "", "", ""], ["412", "DBIA412", "File", "HINQ", "1994/04/05", "APPROVED", "Active", "Private", "31", "
AMIE v2.6 will use the Disability Condition file
extensively in a portion of its new functionality. AMIE will need to change
and access the file in various ways that will require an integration
agreement.\n
In order to use MTLU to its fullest extent AMIE would need to add a new field
'LONG DESCRIPTION' to the Disability Condition file (#31). This field would
be a free text field 1-200 characters, on the '1' node. It would not be a
multiple or used during lookup. There would be a MUMPS cross reference (ADVB)
in order to enhance an MTLU look up. This MUMPS cross reference would be of
the format defined in the Kernel 7.2 Tool Kit manual.\n
Ability to carry the new field in the AMIE init. Ability to populate the LONG
DESCRIPTION field during the AMIE post init. Access to the 'C' cross
reference and LONG DESCRIPTION field for quick look up and comparison during
the post init.", "", "", ""], ["413", "DBIA413", "Routine", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGRPU1", ""], ["414", "DBIA414", "Other", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "\n
Request to export the INSURANCE TYPE (#.3121) multiple of the PATIENT
(#2) file with the release of Integrated Billing v2.0. This
sub-dictionary is maintained in the PATIENT file for Integrated
Billing, and may be addressed by Integrated Billing as needed.
Integrated Billing agrees to maintain supported references to
this data for other applications, as well as Registration. This
would.include the "AB" cross reference on the .01 field of the
sub-dictionary (^DPT("AB",).", "", "", ""], ["415", "DBIA415", "Other", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "\n
The INSURANCE COMPANY (#36) file will now be released exclusively
by Integrated Billing unless otherwise agreed upon.", "", "", ""], ["416", "DBIA416", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "37", "", "", "", ""], ["417", "DBIA417", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "40.8", "", "", "", ""], ["418", "DBIA418", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "45", "
This ICR supports access to PTF (#45) file
cross-references and data fields. Data fields may be accessed using a Direct
Global Read or with Fileman.\n
NOTE: Existing subscribers to this ICR are grandfathered in for accessing PTF
(#45) Diagnosis, Present on Admission (POA), Procedure code, and Surgical code
data fields. However, current subscribers are encouraged to use ICR 6130 in
the future. ICR 6130 supports the use of PTF Utility API's to access PTF
(#45) Diagnosis, Present on Admission (POA) indicators, Procedure code, and
Surgical code fields, instead of accessing fields directly or using Fileman.
New subscribers should not be added to this ICR if PTF (#45) file data fields
may be obtained using the PTF Utility API's supported by ICR 6130.", "", "", ""], ["419", "DBIA419", "File", "REGISTRATION", "1994/04/05", "", "Under Revision", "Controlled Subscription", "405", "", "", "", ""], ["420", "DBIA420", "Routine", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "", "", "DGMTU", ""], ["421", "DBIA421", "Routine", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "", "", "DGUTL2", ""], ["422", "DBIA422", "Routine", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "", "", "DGPTUTL", ""], ["423", "DGMTCOU1 - Medication Copay Exemption API", "Routine", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "", "", "DGMTCOU1", "2011/03/04"], ["424", "DBIA424", "Routine", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "", "", "DGMTU11", ""], ["425", "DBIA425", "Routine", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "", "", "", "DGMTU1", ""], ["426", "DBIA426", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "2", "", "", "", ""], ["427", "DBIA427", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "8", "", "", "", ""], ["428", "DBIA428", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "11", "", "", "", ""], ["429", "DBIA429", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "41.1", "", "", "", ""], ["430", "DBIA430", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "42.4", "", "", "", ""], ["431", "DBIA431", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Private", "43", "", "", "", "2013/04/09"], ["432", "DBIA432", "File", "KERNEL", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "49", "", "", "", ""], ["433", "DBIA433", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "405.3", "", "", "", ""], ["434", "DBIA434", "File", "REGISTRATION", "1994/04/05", "APPROVED", "Active", "Controlled Subscription", "408.31", "", "", "", ""], ["435", "DBIA435", "File", "INPATIENT MEDICATIONS", "1994/04/11", "APPROVED", "Active", "Private", "50.8", "", "", "", ""], ["436", "DBIA436", "File", "PHARMACY DATA MANAGEMENT", "1994/04/11", "APPROVED", "Active", "Controlled Subscription", "52.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.", "", "", ""], ["437", "DBIA437", "File", "PHARMACY DATA MANAGEMENT", "1994/04/11", "APPROVED", "Active", "Controlled Subscription", "52.7", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.", "", "", ""], ["438", "DBIA438", "File", "INPATIENT MEDICATIONS", "1994/04/11", "APPROVED", "Active", "Private", "57.6", "", "", "", ""], ["439", "DBIA439-A", "File", "PATIENT DATA EXCHANGE", "1994/04/11", "", "Retired", "Private", "394.61", "", "", "", ""], ["440", "DBIA439-B", "Routine", "PATIENT DATA EXCHANGE", "1994/04/11", "", "Retired", "Private", "", "", "", "VAQUPD25", ""], ["441", "DBIA439-C", "Routine", "PATIENT DATA EXCHANGE", "1994/04/11", "APPROVED", "Active", "Supported", "", "", "", "VAQUIN01", ""], ["442", "DBIA439-D", "Routine", "PATIENT DATA EXCHANGE", "1994/04/11", "APPROVED", "Retired", "Private", "", "", "", "PPPFMX2", ""], ["443", "DBIA439-E", "File", "PATIENT DATA EXCHANGE", "1994/04/11", "", "Retired", "Private", "394.71", "
Used to extract segment pointer information", "", "", ""], ["444", "DBIA439-F", "File", "PATIENT DATA EXCHANGE", "1994/04/11", "", "Retired", "Private", "394.62", "
Used to extract segment data from data file", "", "", ""], ["445", "DBIA439-G", "File", "PATIENT DATA EXCHANGE", "1994/04/11", "", "Retired", "Private", "394.85", "
Used to extract PDX status", "", "", ""], ["446", "DBIA446", "File", "PCE PATIENT CARE ENCOUNTER", "1994/04/12", "APPROVED", "Active", "Private", "9999999.27", "
Access to the IHS Provider Narrative File (^AUTNPOV).
Access is defined as the ability to READ to and WRITE from this file. The
Problem List Application stores the original problem narrative entered by the
clinician in ^AUTNPOV. The natural language narrative, along with the
accompanying coded data, is displayed for use by the clinician.", "", "", ""], ["447", "DBIA447", "File", "PCE PATIENT CARE ENCOUNTER", "1994/04/12", "APPROVED", "Active", "Controlled Subscription", "9000001", "
READ only access to the Patient/IHS File (^AUPNPAT).
This file is a subset of the IHS Patient File. It is required to be installed
as all VAMCs wishing to use the Problem List Application. Use of this file
assures backward compatibility with IHS software.\n
The patient's name and IFN is initially selected from this file. Then used
for look-up purposes with the VA's Patient File (^DPT).", "", "", ""], ["448", "DBIA448", "File", "PCE PATIENT CARE ENCOUNTER", "1994/04/12", "", "Retired", "Private", "9000011", "
READ only access to the Patient/IHS File (^AUPNPAT).
This file is a subset of the IHS Patient File. It is required to be installed
as all VAMCs wishing to use the Problem List Application. Use of this file
assures backward compatibility with IHS software.\n
The patient's name and IFN is initially selected from this file. Then used
for look-up purposes with the VA's Patient File (^DPT).", "", "", ""], ["449", "DBIA449", "Other", "1", "1994/04/12", "APPROVED", "Active", "Private", "", "
The CPT package currently has five table files which
reside in the DIC global. These are as follows:\n
o CPT CATEGORY (#81.1) data is in ^DIC(81.1,
o CPT COPYRIGHT (#81.2) data is in ^DIC(81.2,
o CPT MODIFIER (#81.3) data is in ^DIC(81.3,
o CPT MODIFIER CATEGORY (#81.4) data is in ^DIC(81.4,
o CPT SOURCE (#81.5) data is in ^DIC(81.5,\n", "", "", ""], ["450", "DBIA450", "Other", "SCHEDULING", "1995/05/09", "", "Retired", "Private", "", "
The CPT package would like to make the following
integration request with the Scheduling package:\n
Request to export the following scheduling routine
change to Scheduling v5.3 with the CPT annual release:\n
Routine Reason
-----------------------------------------------------------------------
SDAMBAE3 Update the effective date reference for current
release.", "", "", ""], ["451", "DBIA451", "File", "SCHEDULING", "1994/04/12", "", "Retired", "Private", "409.71", "
Reason: To populate the Ambulatory Procedure file with
all the CPT codes.", "", "", ""], ["452", "DBIA452", "File", "SCHEDULING", "1994/04/12", "APPROVED", "Active", "Private", "409.72", "
Reason: To populate the Ambulatory Procedure Time
Sensitive file with current CPT codes.", "", "", ""], ["453", "DBIA453", "File", "PROGRESS NOTES", "1994/04/12", "", "Retired", "Private", "121.2", "
The Adverse Reaction Tracking package (ART) needs to be
able to check for the existence of the ALLERGY/ADVERSE REACTION entry in the B
cross reference in the Generic Progress Notes Title (#121.2) file. The ART
v4.0 post-init routine will change the .01 value of this File 121.2 entry to
ADVERSE REACTION/ALLERGY. After ART v4.0 is installed, ART will check for the
existence of the new value in the B cross reference of File 121.2.\n
Also, ART needs to do a direct global read of the second piece of the zero
node of this File 121.2 entry to determine the PROGRESS NOTE TYPE value.", "", "", ""], ["454", "DBIA453", "File", "PROGRESS NOTES", "1994/04/12", "", "Retired", "Private", "121.1", "
The Adverse Reaction Tracking (ART) package needs to
look at first piece of the Generic Progress Notes Type (121.1) file to find
the GENERAL NOTE entry.", "", "", ""], ["455", "GMRPART", "Routine", "PROGRESS NOTES", "1996/02/13", "", "Retired", "Private", "", "
The Adverse Reaction Tracking (ART) package will use
the GMRPART utility to generate a progress note with a title of
ALLERGY/ADVERSE REACTION. ART will pass the necessary data, by reference, to
the GMRPART routine with the exception of the text of the progress note which
will exist in the TMP global (^TMP("GMRP",$J,) at the time GMRPART is called.", "", "GMRPART", ""], ["456", "DBIA456", "File", "AUTO REPLENISHMENT/WARD STOCK", "1994/04/12", "APPROVED", "Active", "Private", "58.5", "
Used to extract the AR/WS statistics for a selected
time frame.", "", "", ""], ["457", "CLINICAL LEXICON EXPRESSIONS", "File", "LEXICON UTILITY", "1994/04/26", "APPROVED", "Active", "Supported", "757.01", "
The Clinical Lexicon Utility will maintain static
internal entry numbers (IENs) for the Expression file (#757.01). As a result,
this file may be pointed to to retrieve the Display Text (.01) for both
current Expressions and formerly used (deleted) Expressions.", "", "", ""], ["458", "DBIA458", "Routine", "IMAGING", "1994/04/25", "APPROVED", "Active", "Private", "", "\n\n
MailMan 7.1 is permitted to the make calls to MAGAPI routine in the imaging
package:\n\n", "", "MAGAPI", ""], ["459", "DBIA459", "File", "IMAGING", "1994/04/25", "APPROVED", "Active", "Private", "2005", "\n\n
This agreement describes data that MailMan can access from the imaging
package.\n\n", "", "", ""], ["460", "DBIA460", "File", "IMAGING", "1994/04/25", "APPROVED", "Active", "Private", "2005.2", "\n\n
MailMan has permission to access file 2005.2 so that it can find where images
are and record their position appropriately.\n\n", "", "", ""], ["461", "DBIA461", "File", "IMAGING", "1994/04/25", "APPROVED", "Active", "Private", "2005.02", "\n\n
Before an image can be displayed, the type of file it is stored in must be
known.\n\n", "", "", ""], ["462", "DBIA462", "Routine", "IMAGING", "1994/05/03", "APPROVED", "Active", "Private", "", "\n\n
MailMan has permission to call MAGAPI for 3 purposes.\n\n", "", "MAGAPI", ""], ["463", "DBIA463", "Routine", "IMAGING", "1994/05/03", "APPROVED", "Active", "Private", "", "
MailMan has permission to call MAGBAPI so that images
that are imported can be moved into a permanent storage location.", "", "MAGBAPI", ""], ["464", "DBIA464", "Routine", "IMAGING", "1994/04/25", "APPROVED", "Active", "Private", "", "\n\n
MailMan has permission to call MAGOBJ in order to display an image on a screen
while a user is reading a message.\n\n", "", "MAGOBJ", ""], ["465", "DBIA465", "File", "OUTPATIENT PHARMACY", "1994/04/26", "APPROVED", "Active", "Private", "52", "
The Pharmacy Benefits Management software will use the
prescription file to extract drug statistics for a selected time frame.", "", "", ""], ["466", "DBIA466", "Routine", "IMAGING", "2003/10/20", "", "Retired", "Private", "", "
The Medicine package has been given permission by the
Imaging package to do the following:\n
Make calls to the ^MAGMIM routine through the ^MCMAG routine.", "", "MAGMIM", ""], ["467", "DBIA467", "Routine", "IMAGING", "2003/10/20", "", "Retired", "Private", "", "
The Medicine package has been given permission by the
Imaging package to do the following:\n
Make calls to the ^MAGDISP routine through the ^MCMAG routine.", "", "MAGDISP", ""], ["468", "DBIA468", "Routine", "IMAGING", "2003/10/20", "", "Retired", "Private", "", "
The Medicine package has been given permission by the
Imaging package to the following:\n
Make calls to the ^MAGSUM routine through the ^MCMAG routine.", "", "MAGSUM", ""], ["469", "DBIA469", "Other", "IMAGING", "2003/10/20", "", "Retired", "Private", "", "
The Medicine package has permission by the Imaging
package to Kill the ^TMP("MAG",$J,"COL") and ^TMP("MAG",$J,"ROW") globals
within the Medicine package upon exiting the Summary of Patient Procedures
options.", "", "", ""], ["470", "DBIA470", "File", "IMAGING", "2003/10/20", "APPROVED", "Active", "Private", "2005", "
The Medicine package has been given permission by the
Imaging package to do the following:\n
Point to the Imaging File (#2005) to reference each Medicine Procedure that
has images.", "", "", ""], ["472", "DBIA472", "File", "INPATIENT MEDICATIONS", "1994/04/26", "APPROVED", "Active", "Private", "50.8", "
D&PPM extracts drug data from the IV Statistics file
for a selected time frame.", "", "", ""], ["473", "DBIA473", "File", "PHARMACY DATA MANAGEMENT", "1994/04/26", "", "Retired", "Private", "52.6", "
D&PPM uses the IV Additives file to obtain the Generic
Drug name.", "", "", ""], ["474", "DBIA473", "File", "PHARMACY DATA MANAGEMENT", "1994/04/26", "", "Retired", "Private", "52.7", "
Pharmacy Benefits Management uses the IV solutions file
to obtain the generic drug name.", "", "", ""], ["475", "DBIA475", "File", "INPATIENT MEDICATIONS", "1994/04/26", "APPROVED", "Active", "Private", "57.6", "
Pharmacy Benefits Management extracts drug usage
statistics for a selected time frame from the UNIT DOES PICK LIST STATS file.", "", "", ""], ["476", "DBIA476", "File", "REGISTRATION", "1994/05/10", "", "Withdrawn", "Private", "2", "
The DSS operations committee has identified several
data elements in the patient file to be extracted and sent to the commercial
software. We request read access to these fields.", "", "", ""], ["477", "DBIA477", "File", "PHARMACY DATA MANAGEMENT", "1994/06/13", "", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
DSS Extracts will reference the following data from the DRUG file (#50).\n
DSS uses the "B" cross reference on the GENERIC NAME field.\n
The DSS Extracts IV EXTRACT DATA file (#728.113) and UNIT DOSE EXTRACT DATA
file (#728.904) contain a field, DRUG, which is a pointer to the DRUG file
(#50).", "", "", ""], ["478", "DBIA478", "File", "KERNEL", "1994/06/13", "", "Retired", "Private", "3.1", "
Read access to the .01 field of the title file for
provider identificaiton for DSS", "", "", ""], ["479", "DBIA479", "File", "SCHEDULING", "1994/05/02", "APPROVED", "Active", "Private", "40.7", "\n
Visit Tracking (PIMS/MAS)\n
Entries used by Visit Tracking are passed by package developers
making calls to the Visit Tracking package.\n
The Visit Tracking package requests permission to read
and point to the following file:\n\n\n
Visit File Fields
-----------------
#08 Clinic Pointer to the Clinic Stop File #40.7\n\n", "", "", ""], ["480", "DBIA480", "File", "REGISTRATION", "1994/05/02", "APPROVED", "Active", "Private", "8", "\n
Visit File Field
----------------\n
#21 Eligibility Pointer to the Eligibility Code File #8
Visit Tracking software references the
Eligibility Code file for the
patient's eligibility.\n", "", "", ""], ["481", "DBIA481", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "\n
Visit Tracking (PIMS/MAS)\n
Entries used by Visit Tracking are passed by package developers
making calls to the Visit Tracking package.\n
The Visit Tracking package requests permission to read
and point to the following file:\n
Visit File Field
----------------
#22 Hospital Location Pointer to the Hospital Location File #44
Visit Tracking code checks the following fields
in the Hospital Location file:\n
Field / Name
-----------------------
2 Type
3.5 Division
8 Stop Code
1916 Principal Clinic\n\n", "", "", ""], ["482", "DBIA482", "File", "REGISTRATION", "1994/05/02", "APPROVED", "Active", "Private", "405", "\n
Visit Tracking (PIMS/MAS)\n
Entries used by Visit Tracking are passed by package developers
making calls to the Visit Tracking package.\n
The Visit Tracking package requests permission to read
the following file:\n
File Field
------------------------------------------------
Patient Movement #405 Date/Time #.01
VT Entry #.27
Ward Location #.06\n\n", "", "", ""], ["483", "DBIA483", "File", "REGISTRATION", "1994/05/02", "APPROVED", "Active", "Controlled Subscription", "43", "\n
Visit Tracking (PIMS/MAS)\n
Entries used by Visit Tracking are passed by package developers
making calls to the Visit Tracking package.\n
The Visit Tracking package requests permission to read
the following file:\n\n
File Field
------------------------------------------------
MAS Parameter #43 Domiciliary Wards #16\n", "", "", ""], ["484", "DBIA484", "File", "REGISTRATION", "1994/05/02", "APPROVED", "Active", "Private", "40.8", "\n
Visit Tracking (PIMS/MAS)\n
Entries used by Visit Tracking are passed by package developers
making calls to the Visit Tracking package.\n
The Visit Tracking package requests permission to read
the following file:\n
File Field
--------------------------------------------------------------
Medical Center Division #40.8 Institution File Pointer #.07\n", "", "", ""], ["485", "DBIA485", "File", "REGISTRATION", "1994/05/02", "APPROVED", "Active", "Private", "2", "\n
Visit Tracking (PIMS/MAS)\n
Entries used by Visit Tracking are passed by package developers
making calls to the Visit Tracking package.\n
The Visit Tracking package requests permission to read
the following file:", "", "", ""], ["486", "PSJEEU0", "Routine", "INPATIENT MEDICATIONS", "1994/06/24", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PSJEEU0", ""], ["488", "DBIA488", "File", "1", "1994/05/11", "APPROVED", "Active", "Private", "", "
1. DLL^XTLKMGR: This procedure non-interactively
removes an entry from file 8984.4 and the associated variable pointer in the
DD of 8984.1 and 8984.2. Line DLL+7 $orders on the variable pointer node to
set DA, then ^DIK is called to remove the entry.", "", "", ""], ["489", "DBIA489", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/09/18", "APPROVED", "Active", "Controlled Subscription", "", "
Interface with Visit Tracking to create Visits.", "", "VSIT", ""], ["490", "DBIA490", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/09/19", "", "Retired", "Controlled Subscription", "", "
This is an entry point for getting a list of visits
that match defined criteria.", "", "vsitoe", ""], ["491", "DBIA491", "File", "KERNEL", "1994/06/13", "APPROVED", "Active", "Controlled Subscription", "7", "
Read access to the .01 field of the provider class file
for provider identification.", "", "", ""], ["492", "DBIA492", "File", "IFCAP", "1994/06/13", "APPROVED", "Active", "Private", "420.1", "
DMMS units must be associated with a cost center to
make it possible associate the work for the unit as gathered in DHCP with
financial data contained in reports from the AAC. To this end, we request
read access to the COST CENTER file (420.1).\n
Currently the CC field is a 6 digit code with the first 4 being Cost Center
and the last two being Sub-cost center. Thats how it is broken up to pass to
FMS for IFCAP V5.0. Current plans are to increase the code to 8 digits.
There are discussions going on between OF&IRM and VAH's CFO's office. At some
point IFCAP will be changing the content of the file. When that happens, this
DBIA will have to be revisited.", "", "", ""], ["493", "DBIA493", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "40.9", "
The patient oriented extracts in DSS distinguish
between inpatients and outpatients. To make this distinction, a field in the
extract log points to the LOCATION TYPE file (40.9).", "", "", ""], ["494", "DBIA494", "File", "REGISTRATION", "1994/06/13", "", "Retired", "Private", "13", "
Among the demographic data extracted for DSS, patient
religion is one element. To this end, we request read access to the .01 field
of the RELIGION file (13)\n
The DSS Extracts ADMISSIONS EXTRACT file (#727.802) and ADMISSION SETUP
EXTRACT file (#727.82) contain a field, RELIGION, which is a pointer to the
RELIGION file (#13).", "", "", ""], ["500", "DBIA15-B", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1990/02/23", "APPROVED", "Active", "Private", "72", "
EXAMINATION STATUS", "", "", ""], ["501", "DBIA15-C", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1990/02/23", "APPROVED", "Active", "Controlled Subscription", "74", "
RADIOLOGY REPORTS FILE
Amended: 11/25/22 to add Field 7 VERIFIED DATE for COMPREHENSIVE
CARE COORDINATION", "", "", ""], ["502", "DBIA15-D", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1990/02/23", "APPROVED", "Active", "Private", "71", "
RADIOLOGY PROCEDURES FILE", "", "", ""], ["503", "DBIA15-E", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1990/02/23", "APPROVED", "Active", "Private", "71.2", "
PROCEDURE MODIFIERS FILE", "", "", ""], ["504", "DBIA15-F", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1990/02/23", "APPROVED", "Active", "Private", "75.1", "
RADIOLOGY ORDERS FILE", "", "", ""], ["505", "DBIA5-B", "File", "KERNEL", "1989/07/27", "", "Active", "Private", "19.1", "
This ICR had been retired, but was reactivated due to a
review of patch OR*3*397, where SQA found ORUPREF1 had some pre-existing code
(probably going back to the original package release) that reads from file
19.1. The reads are to:
1. ^DIC(19.1,"B",X,D0) ? B cross-reference
2. ^DIC(19.1,D0,1,D1,0) ? Description", "", "", ""], ["506", "DBIA5-C", "File", "KERNEL", "1989/07/27", "", "Retired", "Private", "3", "", "", "", ""], ["507", "DBIA4-B", "File", "KERNEL", "1989/07/27", "APPROVED", "Active", "Private", "", "", "", "", ""], ["508", "DBIA6-B", "File", "1", "1989/07/27", "APPROVED", "Active", "Private", "", "", "", "", ""], ["509", "DBIA6-C", "File", "1", "2005/11/07", "", "Retired", "Private", "", "
Fileman calls.", "", "", ""], ["510", "DISV", "File", "1", "1989/07/27", "APPROVED", "Active", "Controlled Subscription", "", "
Used to process 'space-bar return' on user input.", "", "", "2012/02/29"], ["511", "DBIA6-D", "File", "1", "1989/07/27", "APPROVED", "Active", "Controlled Subscription", "", "\n
^DIC("AC" - Screen lookup on files of a particular application group.", "", "", ""], ["512", "DBIA17-B", "Routine", "REGISTRATION", "1990/03/12", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGPMLOS", ""], ["513", "DBIA30-B", "File", "REGISTRATION", "1994/03/01", "APPROVED", "Active", "Private", "45.7", "", "", "", ""], ["514", "DBIA31-B", "File", "REGISTRATION", "1989/11/14", "APPROVED", "Active", "Private", "42.5", "", "", "", ""], ["515", "DBIA31-C", "File", "SCHEDULING", "1989/11/14", "APPROVED", "Active", "Private", "44", "", "", "", ""], ["516", "DBIA34-B", "File", "PHARMACY DATA MANAGEMENT", "1989/03/13", "", "Retired", "Private", "50", "
Direct references are made to the globals to get
allergy information.", "", "", ""], ["517", "DBIA34-C", "File", "OUTPATIENT PHARMACY", "1989/03/13", "", "Retired", "Private", "57", "
Direct references are made to the globals to get
allergy information.", "", "", ""], ["518", "DBIA36-B", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "\n
^SC( Used to get patient variables", "", "", ""], ["519", "FACILITY TREATING SPECIALTY (#45.7) File Access", "File", "REGISTRATION", "1989/03/22", "APPROVED", "Active", "Private", "45.7", "\n
^DIC(45.7 Used to lookup treating specialty and print name", "", "", "2015/07/17"], ["520", "DBIA59-B", "Routine", "LAB SERVICE", "2005/05/25", "", "Retired", "Private", "", "
- ECT namspaced option runs routine ^LRUPACA
Enter ACTION: S DIC=68,DIC(0)="QEAM" D ^DIC K DIC I Y>0 S LRAA=+Y,
LRAA(1)=$P(Y,U,2)\n
SEE DBIA59-A", "", "LRUPACA", ""], ["521", "DBIA59-C", "Routine", "LAB SERVICE", "2005/05/25", "", "Retired", "Private", "", "
- ECT namespaced option runs routine ^LRCAPS.\n
- Refences file 68 Accession (read only)
2 DATE
.01 DATE
1 ACCESSION NUMBER
.01 LRDFN
11 TESTS
.01 TESTS\n
SEE DBIA59-A", "", "LRCAPS", ""], ["522", "DBIA60-B", "File", "PHARMACY DATA MANAGEMENT", "1990/12/11", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006", "", "", ""], ["523", "DBIA60-C", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
This agreement will be retired on 12/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSO*7*213. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["524", "DBIA67-B", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Controlled Subscription", "61", "", "", "", "2012/05/24"], ["525", "DBIA67-C", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Controlled Subscription", "63", "
This DBIA needed to be updated for HS 2.7 to include
additional data for several of the HS components. This was done on June 12,
1995.\n
For the next version of either Lab or Health Summary a LAB API will need to be
set up to access this data.\n
^TMP("LRA",$J, may be Set and Killed during collection of field data.
ditto ^TMP("LRCY",$J,
ditto ^TMP("LRM",$J,\n
Revisions:
Added 10/12/23, effective with OR*3*535\n
GLOBAL REFERENCE:
^LR(D0,'CH',D1,'ORUT',D2,0)
3 CPRS ORDER # 0;3 Direct Global Read & w/Fileman\n
GLOBAL REFERENCE:
^LR(D0,'CY',D1,'ORUT',D2,0)
3 CPRS ORDER # 0;3 Direct Global Read & w/Fileman\n
GLOBAL REFERENCE:
^LR(D0,'EM',D1,'ORUT',D2,0)
3 CPRS ORDER # 0;3 Direct Global Read & w/Fileman\n
GLOBAL REFERENCE:
^LR(D0,'MI',D1,'ORUT',D2,0)
3 CPRS ORDER # 0;3 Direct Global Read & w/Fileman\n
GLOBAL REFERENCE:
^LR(D0,'SP',D1,'ORUT',D2,0)
3 CPRS ORDER # 0;3 Direct Global Read & w/Fileman\n\n\n\n\n", "", "", "2023/10/13"], ["526", "DBIA67-D", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Private", "61.2", "", "", "", ""], ["527", "DBIA67-E", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Private", "65", "
This agreement allows the Health Summary package to
look at specified fields in the Lab Package in order to display Blood Bank
related information on a patient.\n
Amended 7-18-97 to include field .16, DIVISION on some reports.", "", "", ""], ["528", "DBIA67-F", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Private", "66", "
Note: This IA will become void upon the release of
VBECS.", "", "", ""], ["529", "DBIA67-G", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Private", "61.1", "", "", "", ""], ["530", "DBIA67-H", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Private", "62.05", "", "", "", ""], ["531", "DBIA67-I", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Controlled Subscription", "68", "", "", "", ""], ["532", "DBIA67-J", "File", "LAB SERVICE", "1991/01/31", "APPROVED", "Active", "Controlled Subscription", "69", "
Data is passed in ^TMP("LRO",$J, which may be killed
before and after its use.", "", "", ""], ["533", "DBIA68-B", "File", "PHARMACY DATA MANAGEMENT", "1991/01/31", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 50 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
The following fields are accessed from ^PS( and ^PSDRUG( in a read-only
manner:\n
For verified orders:\n
^PS( 55 PHARMACY PATIENT FILE
55.06 1 Provider
3 Medicinal Route (pointer to ^PS(51.2,)
7 Schedule Type
10 Start Date/Time
26 Schedule
28 Status
34 Stop Date/Time
55.07 .01 Drug (pointer to ^PSDRUG()
1 Dosage Ordered\n
The following cross-references are used:\n
^PS( 55.06 "AUS" Stop Date/Time\n", "", "", ""], ["534", "DBIA68-C", "File", "INPATIENT MEDICATIONS", "1991/01/31", "APPROVED", "Active", "Private", "53.1", "", "", "", "2023/03/03"], ["535", "DBIA69-B", "File", "PHARMACY DATA MANAGEMENT", "2005/11/14", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
The following fields are accessed from ^PS( and ^PSDRUG( in a read-only
manner:\n
^PS(55, PHARMACY PATIENT FILE
55.01 .02 Start Date/Time
.03 Stop Date/Time
.06 Physician
.08 Infusion Rate
.09 Schedule
100 Status
55.02 .01 Additive (Pointer to ^PS(52.6,)
.02 Strength
55.11 .01 Solution (Pointer to ^PS(52.7,)
1 Volume\n", "", "", ""], ["536", "DBIA69-C", "File", "PHARMACY DATA MANAGEMENT", "1991/01/31", "", "Retired", "Private", "52.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
^PS(52.6, IV ADDITIVE FILE
52.6 .01 Additive Name", "", "", ""], ["537", "DBIA69-D", "File", "PHARMACY DATA MANAGEMENT", "1991/01/31", "APPROVED", "Active", "Private", "52.7", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
^PS(52.7, IV SOLUTION FILE
52.7 .01 Solution Name", "", "", ""], ["538", "DBIA74-B", "File", "PROGRESS NOTES", "1991/02/04", "", "Retired", "Private", "121.1", "
Health Summary is accessing fields in the Generic
Progress Notes Type file, GMR(121.1, to retrieve the Title for display on
various components.", "", "", ""], ["539", "DBIA75-B", "File", "MENTAL HEALTH", "1991/02/04", "APPROVED", "Active", "Private", "606.5", "
Agreement has been made for Health Summary to access
the following fields in the Mental Health Progress Notes files.\n
- Globals accessed are:
^YSP(606.5, Prgress Note Type\n
- The following fields are accessed:
^YSP(606.5, 606.5 .01 TYPE", "", "", ""], ["540", "DBIA80-B", "File", "CLINICAL PROCEDURES", "1991/02/05", "APPROVED", "Active", "Private", "699", "
The Health Summary exports and calls the routine
GMTSMCPS, which generates the output for the Health Summary Medicine
component. The following fields and cross references are being referenced:\n
^MCAR(699, Endoscopy File
Fields: 1 Procedure
20 Summary", "", "", ""], ["541", "DBIA80-C", "File", "CLINICAL PROCEDURES", "1991/02/05", "APPROVED", "Active", "Private", "694", "
The Health Summary exports and calls the routine
GMTSMCPS, which generates the output for the Health Summary Medicine
component. The following fields and cross references are being referenced:\n
^MCAR(694, Hematology File
Fields: 2 Procedure
1.5 Summary\n", "", "", ""], ["542", "DBIA80-D", "File", "CLINICAL PROCEDURES", "1991/02/05", "APPROVED", "Active", "Private", "697.2", "
The Health Summary exports and calls the routine
GMTSMCPS, which generates the output for the Health Summary Medicine
component. The following fields and cross references are being referenced:\n
^MCAR(697.2, Procedure Location File
Fields: .01 Name
1 Global Location
Uses "C" cross reference on Global Location field.
The "C" cross reference could result in pointing
to global locations in the Global Location field which
currently contains global roots for the range on files
from ^MCAR(691, through ^MCAR(699,.", "", "", ""], ["543", "DBIA85-B", "File", "RECORD TRACKING", "1991/07/09", "APPROVED", "Active", "Private", "190.1", "\n
1. Activation interface
2. Make an appointment
Checkin/unscheduled visit
3. Cancel an appointment
4. Changing clinic names\n
1. Use of the Record Tracking System Parameter file # 195.4
SD calls RT if the field 'MAS INTERFACE STATUS' is 'UP'
^DIC(195.4,1,"UP")=1^\n
2. When a clinic appointment is made if the appointment is 'today'
or if the Record Tracking System Parameter 'Batch requests' is
set to 'No' or if records are requested for an unscheduled visit.\n
A. An entry is made in the Requested Records file #190.1
^RTV(190.1,n)
by a call from RT^SDUTL to a tasked job QUE^RTQ
or RT^SDI\n
B. After the entry is added to the Requested Records file #190.1
an entry is made in Parent Record Request field
of the Patient subfield of the Hospital Location file #44
^SC(n,"S",,,,"RTR")=n^
by a return call from CREATE+11^RTQ2 to RTSET^SDUTL\n
3. When a clinic appointment is canceled:
If there is a Requested Records entry in file #190.1
the status is changed to 'canceled' by a call
RTV(190.1,n)=^^^^^x^
from RT+2^SDUTL to CANCEL^RTQ2.\n
4. When the name of a clinic is changed the corresponding names
of entries in the Pull List file #194.2 are changed by a trigger
on the .01 field of the Hospital Location file #44. Clinic
^SC(1,0)=DJones Medical Clinic^
^RTV(194.2,n)=Dr Jones Medical Clinic [04/01/91]^
Clinic names are changed in a compiled input template. To
insure the use of this trigger the following action is taken:
The Record Tracking package includes the .01 field of the
Hospital Location file #44 so that the SDB template is
re-compiled when the Record Tracking package is initialized.", "", "", ""], ["544", "DBIA85-C", "Routine", "RECORD TRACKING", "1991/07/09", "APPROVED", "Active", "Private", "", "\n
1. Activation interface
2. Make an appointment
Checkin/unscheduled visit
3. Cancel an appointment
4. Changing clinic names\n
1. Use of the Record Tracking System Parameter file # 195.4
SD calls RT if the field 'MAS INTERFACE STATUS' is 'UP'
^DIC(195.4,1,"UP")=1^\n
2. When a clinic appointment is made if the appointment is 'today'
or if the Record Tracking System Parameter 'Batch requests' is
set to 'No' or if records are requested for an unscheduled visit.\n
A. An entry is made in the Requested Records file #190.1
^RTV(190.1,n)
by a call from RT^SDUTL to a tasked job QUE^RTQ
or RT^SDI\n
B. After the entry is added to the Requested Records file #190.1
an entry is made in Parent Record Request field
of the Patient subfield of the Hospital Location file #44
^SC(n,"S",,,,"RTR")=n^
by a return call from CREATE+11^RTQ2 to RTSET^SDUTL\n
3. When a clinic appointment is canceled:
If there is a Requested Records entry in file #190.1
the status is changed to 'canceled' by a call
RTV(190.1,n)=^^^^^x^
from RT+2^SDUTL to CANCEL^RTQ2.\n
4. When the name of a clinic is changed the corresponding names
of entries in the Pull List file #194.2 are changed by a trigger
on the .01 field of the Hospital Location file #44. Clinic
^SC(1,0)=DJones Medical Clinic^
^RTV(194.2,n)=Dr Jones Medical Clinic [04/01/91]^
Clinic names are changed in a compiled input template. To
insure the use of this trigger the following action is taken:
The Record Tracking package includes the .01 field of the
Hospital Location file #44 so that the SDB template is
re-compiled when the Record Tracking package is initialized.", "", "RTQ", ""], ["545", "DBIA85-D", "Routine", "RECORD TRACKING", "1991/07/09", "APPROVED", "Active", "Private", "", "\n
1. Activation interface
2. Make an appointment
Checkin/unscheduled visit
3. Cancel an appointment
4. Changing clinic names\n
1. Use of the Record Tracking System Parameter file # 195.4
SD calls RT if the field 'MAS INTERFACE STATUS' is 'UP'
^DIC(195.4,1,"UP")=1^\n
2. When a clinic appointment is made if the appointment is 'today'
or if the Record Tracking System Parameter 'Batch requests' is
set to 'No' or if records are requested for an unscheduled visit.\n
A. An entry is made in the Requested Records file #190.1
^RTV(190.1,n)
by a call from RT^SDUTL to a tasked job QUE^RTQ
or RT^SDI\n
B. After the entry is added to the Requested Records file #190.1
an entry is made in Parent Record Request field
of the Patient subfield of the Hospital Location file #44
^SC(n,"S",,,,"RTR")=n^
by a return call from CREATE+11^RTQ2 to RTSET^SDUTL\n
3. When a clinic appointment is canceled:
If there is a Requested Records entry in file #190.1
the status is changed to 'canceled' by a call
RTV(190.1,n)=^^^^^x^
from RT+2^SDUTL to CANCEL^RTQ2.\n
4. When the name of a clinic is changed the corresponding names
of entries in the Pull List file #194.2 are changed by a trigger
on the .01 field of the Hospital Location file #44. Clinic
^SC(1,0)=DJones Medical Clinic^
^RTV(194.2,n)=Dr Jones Medical Clinic [04/01/91]^
Clinic names are changed in a compiled input template. To
insure the use of this trigger the following action is taken:
The Record Tracking package includes the .01 field of the
Hospital Location file #44 so that the SDB template is
re-compiled when the Record Tracking package is initialized.", "", "RTQ2", ""], ["546", "DBIA85-E", "File", "RECORD TRACKING", "1991/07/09", "APPROVED", "Active", "Private", "194.2", "\n
1. Activation interface
2. Make an appointment
Checkin/unscheduled visit
3. Cancel an appointment
4. Changing clinic names\n
1. Use of the Record Tracking System Parameter file # 195.4
SD calls RT if the field 'MAS INTERFACE STATUS' is 'UP'
^DIC(195.4,1,"UP")=1^\n
2. When a clinic appointment is made if the appointment is 'today'
or if the Record Tracking System Parameter 'Batch requests' is
set to 'No' or if records are requested for an unscheduled visit.\n
A. An entry is made in the Requested Records file #190.1
^RTV(190.1,n)
by a call from RT^SDUTL to a tasked job QUE^RTQ
or RT^SDI\n
B. After the entry is added to the Requested Records file #190.1
an entry is made in Parent Record Request field
of the Patient subfield of the Hospital Location file #44
^SC(n,"S",,,,"RTR")=n^
by a return call from CREATE+11^RTQ2 to RTSET^SDUTL\n
3. When a clinic appointment is canceled:
If there is a Requested Records entry in file #190.1
the status is changed to 'canceled' by a call
RTV(190.1,n)=^^^^^x^
from RT+2^SDUTL to CANCEL^RTQ2.\n
4. When the name of a clinic is changed the corresponding names
of entries in the Pull List file #194.2 are changed by a trigger
on the .01 field of the Hospital Location file #44. Clinic
^SC(1,0)=DJones Medical Clinic^
^RTV(194.2,n)=Dr Jones Medical Clinic [04/01/91]^
Clinic names are changed in a compiled input template. To
insure the use of this trigger the following action is taken:
The Record Tracking package includes the .01 field of the
Hospital Location file #44 so that the SDB template is
re-compiled when the Record Tracking package is initialized.", "", "", ""], ["547", "DBIA87-B", "File", "REGISTRATION", "1991/07/10", "APPROVED", "Active", "Private", "45", "
PTF FILE: Looks at 70 node (Discharge and ICD
diagnosis info) and
M multiple (movement data) and its ICD 1 field. (routine YSCEN32)", "", "", ""], ["548", "DBIA87-C", "File", "REGISTRATION", "1991/07/10", "APPROVED", "Active", "Controlled Subscription", "8", "
ELIGIBILITY CODE: Looks at .01. (routines: YSCEN23,
YSCEN54,
YSDGDEM, YSPP1A)\n
Quality: Audiology and Speech Pathology Audit and Review (QUASAR) Package,
A&SP CLINIC VISIT File (#509850.6), VISIT ELIGIBILITY Field (#80) points to
the ELIGIBILITY CODE File (#8) to accommodate recording, tracking and
reporting workload by visit eligibility.\n
Quality: Audiology and Speech Pathology Audit and Review (QUASAR) Package,
A&SP CLINIC VISIT File (#509850.6), PATIENT ELIGIBILITY Field (#2) points to
the ELIGIBILITY CODE File (#8) to accommodate recording, tracking and
reporting workload by patient eligibility.", "", "", ""], ["549", "DBIA87-D", "File", "REGISTRATION", "1991/07/10", "APPROVED", "Active", "Private", "37", "
DISPOSITION FILE: (routine: YSPP4)", "", "", ""], ["550", "DBIA87-E", "File", "REGISTRATION", "1991/07/10", "APPROVED", "Active", "Private", "2", "
PATIENT FILE (listed by field or node referenced. If a
node is referenced,
it will follow in ()s):
CLAIM NUMBER and CLAIM FOLDER LOCATION (YSCEN23, YSDGDEM,YSCEN54,
and YSPP1)
RELIGION (YSCEN23, YSDGDEM, and YSCEN54)
ELIGIBILITY CODE (YSCEN23, YSDGDEM, YSCEN54, and YSPP1A)
EMERGENCY CONTACT NODE (.33) (YSCEN23, YSCEN54, and YSPP)
NEXT OF KIN NODE (.21) (YSPP1)
DESIGNEE NODE (.34) (YSPP1)
ADDRESS NODE (.11) (YSCEN23 and YSDGDEM)
PHONE NODE (.13) (YSCEN23, YSDGDEM, and YSPP)
TEMPORARY ADDRESS NODE (.121) (YSCEN23 and YSDGDEM)
ELIGIBILITY STATUS NODE (.361) (YSCEN23, YSDGDEM, and YSPP1A)
SERIOUSLY ILL (YSDGDEM0)
ENROLLMENT MULTIPLE (YSDGDEM0)
APPOINTMENT MULTIPLE (YSDGDEM0)
DISPOSITION MULTIPLE (YSPP4)
INELIGIBLE DATE (YSPP, YSPP1)
EMPLOYER NODE (.311) (YSPP1)
SERVICE CONNECTED? (YSPP1)
SERVICE CONNECTED PERCENTAGE (YSPP1)
PARENTS' NAMES NODE (.24) (YSPP1)
PRIOR CARE RECIEVED NODE (1010.15) (YSPP2)
SERVICE RECORD NODE (.32) (YSPP2)
AGENCY/ALLIED COUNTRY (YSPP2)
COMBAT DATA (.52) (YSPP2)
POW DATA (.52) (YSPP2)
IONIZING RADIATION DATA (.321) (YSPP2)
VIETNAM SERVICE DATA (.321) (YSPP3)
AGENT ORANGE DATA (.321) (YSPP3)
SERVICE DENTAL INJURY (YSPP3)
SERVICE TEETH EXTRACTED? (YSPP3)", "", "", ""], ["551", "DBIA88-B", "Routine", "GRECC", "1991/08/06", "APPROVED", "Active", "Private", "", "
1. The 'DG' post-init for MAS v5.1 will be calling the
Generic
Code Sheet routine A^GECSX5 to re-build the template maps
for the input templates listed above.", "", "GECSX5", ""], ["552", "DBIA90-B", "File", "PHARMACY DATA MANAGEMENT", "1993/11/01", "", "Retired", "Controlled Subscription", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any
additional code that utilizes this Integration Agreement. APIs have been
created that can be used in place of any code needing to make use of this
agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code
that currently utilizes this Integration Agreement must be converted to
use the new API's. If any part of this Integration Agreement cannot be
satisfied with the APIs, please contact the PRE development team mail
group at EMAIL GROUP DEV using Microsoft Outlook.\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy
packages are still allowed to utilize this agreement past the expiration
date of December 31, 2006.", "", "", ""], ["553", "DBIA90-C", "File", "PHARMACY DATA MANAGEMENT", "1993/11/01", "", "Retired", "Controlled Subscription", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
Amended August 30, 1994.", "", "", ""], ["554", "DBIA91-B", "File", "LAB SERVICE", "1997/10/28", "APPROVED", "Active", "Controlled Subscription", "63", "
Amended October 28, 1997.", "", "", ""], ["555", "DBIA91-C", "File", "LAB SERVICE", "1997/10/28", "APPROVED", "Active", "Controlled Subscription", "61", "
Amended October 28, 1997.\n
Data from the following fields are accessed for read only (Read w/FileMan or
Direct Global Read):\n
^LAB(61 TOPOGRAPHY FIELD File
.01 NAME", "", "", ""], ["556", "DBIA93-B", "File", "SCHEDULING", "1991/09/11", "", "Retired", "Controlled Subscription", "409.5", "", "", "", ""], ["557", "DBIA93-C", "File", "SCHEDULING", "1991/09/11", "APPROVED", "Active", "Controlled Subscription", "40.7", "", "", "", ""], ["558", "DBIA95-B", "Routine", "LAB SERVICE", "1991/09/24", "APPROVED", "Active", "Private", "", "
Request an agreement with the lab developers for usage
of the following:\n
variables:
Only those associated with the routines below\n
Routines from indicated entry points:\n
PT^LRX", "", "LRX", ""], ["559", "DBIA95-C", "Routine", "LAB SERVICE", "1991/09/24", "APPROVED", "Active", "Private", "", "
Request an agreement with the lab developers for usage
of the following:\n
variables:
Only those associated with the routines below\n
Routines from indicated entry points:\n
SWITCH^LRRP2", "", "LRRP2", ""], ["560", "DBIA97-B", "File", "KERNEL", "1991/08/26", "APPROVED", "Active", "Private", "49", "
The DSS developers have agreed that the IMS developers
may export file 730 (NATIONAL SERVICE) with data and field 730 (NATIONAL
SERVICE) in file 49 (SERVICE/SECTION) with no data.", "", "", ""], ["561", "DBIA98-B", "File", "KERNEL", "1991/03/20", "APPROVED", "Active", "Private", "", "
Version 5.1 of the laboratory package has a temporary
agreement for the following:
2) To reference the global %ZTSK directly to display the error trap data.
(Rick has been notified of our usage of the %ZTSK global)\n
When Kernel release their error trapping system, Lab will convert to the
Kernel supported methodology.", "", "", ""], ["562", "DBIA102-B", "File", "DENTAL", "2005/11/09", "", "Retired", "Private", "220.4", "
The following fields are accessed in a read-only
manner:\n
^DIC(220.4
.01 Dental Bed Section", "", "", ""], ["563", "DBIA103-B", "File", "SURGERY", "1991/07/28", "APPROVED", "Active", "Private", "131.9", "", "", "", ""], ["564", "DBIA104-B", "File", "REGISTRATION", "2005/06/20", "", "Retired", "Controlled Subscription", "45", "
#45 PTF file\n
^DGPT("ADS", cross-reference: When using the ^DGPT(PTF,0) node, the software
checks the 11th piece for the type of record (i.e., PTF or CENSUS). For
example: Q:$P(^DGPT(QI P1IFN,0),U,11)'=1 ".\n
^DGPT("AAD", cross-reference The following nodes and multiples from File 45:
0 node
70 node
401 multiple
501 multiple
601 multiple\n
Other referenced nodes:
^DGPT(,"S"
^DGPT(,"M","AM" x-ref\n
The internal entry number (D1) of the sub-file entry is obtained
(^DGPT(D0,"M",D1)) and used to find the zero node. The zero node of the "M"
multiple (^DGPT(D0,"M",D1,0)) contains the movement records (1-1000) for this
episode of care. Two pieces of information are obtained from the movement
record. First, is the losing specialty (field #2). This field contains the
losing bedsection for this movement and is a pointer to the SPECIALTY file
(#42.4). If the description of the losing specialty does not contain "NHCU"
or "DOMICILIARY", routine execution continues. The second field obtained is
the ICD 1 field (#5) which contains the diagnosis responsible for the greatest
length of stay in this bedsection. It is a pointer to the ICD DIAGNOSIS file
(#80). If the diagnosis is a substance abuse diagnosis, the entry is stored
to a temporary file (^TMP) and the patient is listed on the report. All
movement records for a patient will be checked until a match is found at which
time routine execution will proceed to the next patient. If no matches are
found, the patient is not reported and execution proceeds to the next
patient.", "", "", ""], ["565", "DBIA104-C", "File", "REGISTRATION", "2005/06/22", "APPROVED", "Active", "Controlled Subscription", "405", "
The listed references will be made from the QIP1* &
QIP3SR* routines which, while belonging to the QIP namespace, will be
maintained by the PIMS developers (for QIP1*) and surgery developers (for
QIP3SR*). Coordination of release and patches will be through the QIP
custodial ISC.\n
To determine the associated admission for perioperative extracts, the
following cross-reference is used: ^DGPM("APTT1"", "", "", ""], ["566", "DBIA106-B", "File", "OUTPATIENT PHARMACY", "2005/06/20", "", "Retired", "Private", "52", "
Routine QIP3POLY reads the following fields:\n
In file 52, PRESCRIPTION
6 - DRUG
101 - LAST DISPENSED DATE Amendment to DBIA 106 approved 10/10/93:\n
QUIC is requesting the following be added to DBIA #106. The additional
files/fields will be used to report the rate of completion of at least one
Glycosalated Hemoglobin measurement within one year for diabetic patients on a
medication regimen. Add under #52 PRESCRIPTION file
100 STATUS", "", "", ""], ["567", "DBIA106-C", "File", "PHARMACY DATA MANAGEMENT", "2005/06/20", "", "Retired", "Private", "55", "
Routine QIP3POLY reads the following fields: In file
55, PHARMACY PATIENT, the cross reference
^PS(55,DFN,"P","A",DATE,RX)\n
The above references will be made from the QIP3POLY routine which, while
belonging to the QIP namespace, will be maintained by the pharmacy developers.
Coordination of release and patches will be through the QIP custodial ISC.\n
Amendment to DBIA 106 approved 10/10/93:\n
QUIC is requesting the following be added to DBIA #106. The additional
files/fields will be used to report the rate of completion of at least one
Glycosalated Hemoglobin measurement within one year for diabetic patients on a
medication regimen. #55, PHARMACY PATIENT file
.01 NAME
55.06,55.02,.01 DISPENSED DRUG
55.06,28 STATUS
55.01,55.02,.01 ADDITIVES
55.01,100 STATUS
Cross reference ^PS(55,DFN,5,"AUS",DATE/TIME,DA)\n
With the "AUS" cross reference, I am referencing the DISPENSE DRUG and TATUS
(#28) fields. 5,D0,5,D1,0)=^^^^^^^^ (#28) STATUS [9S] ^ (55,D0,5,D1,1,D2,0)=
(#.01) DISPENSE DRUG [1P] ^\n", "", "", ""], ["568", "DBIA106-D", "File", "PHARMACY DATA MANAGEMENT", "2005/06/20", "", "Retired", "Private", "52.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
Amendment to DBIA 106 approved 10/10/93:\n
QUIC is requesting the following be added to DBIA #106. The additional
files/fields will be used to report the rate of completion of at least one
Glycosalated Hemoglobin measurement within one year for diabetic patients on a
medication regimen.\n
#52.6, IV ADDITIVES file
.01 PRINT NAME", "", "", ""], ["569", "DBIA107-B", "File", "SURGERY", "2005/06/20", "", "Retired", "Private", "132.9", "
Custodial package - Surgery:
----------------------------
Routine QIP3SR accesses the following fields: In file 132.9, ATTENDING CODES
1 - CODE\n
The above references will be made from the QIP3SR* routines which, while
belonging to the QIP namespace, will be maintained by the surgery developers.
Coordination of release and patches will be through the QIP custodial ISC.", "", "", ""], ["570", "DBIA108-B", "File", "NURSING SERVICE", "2005/06/20", "", "Retired", "Private", "210", "
NURS STAFF FILE #210\n
.01 Employee Name\n
3 Assignment (multiple)
1 Service Position
3 Location\n
5 Status\n
20 Date of Seperation from Hospital\n
Version 2.5:\n
NURS STAFF FILE #210\n
.01 Employee Name\n
5 Status\n
The above references will be made from the QIP4* routines which, while
belonging to the QIP namespace, will be maintained by the nursing developers.
Coordination of release and patches will be through the QIP custodial ISC.", "", "", ""], ["571", "DBIA108-C", "File", "NURSING SERVICE", "1991/10/04", "", "Retired", "Private", "211.8", "
NURS POSITION CONTROL FILE #211.8\n
.01 Location\n
2 Occupancy/Transferred Date (Multiple)
.03 Service Position
3 Vacancy Date\n
The above references will be made from the QIP4* routines which, while
belonging to the QIP namespace, will be maintained by the nursing developers.
Coordination of release and patches will be through the QIP custodial ISC.", "", "", ""], ["572", "DBIA109-B", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "68", "
68 ACCESSION FILE
68.01,.01 DATE
68.02,12 LAB ARRIVAL TIME
68.02,13 DATE/TIEM RESULTS AVAILABLE
68.04,.01 TESTS
68.04,1 URGENCY OF TEST
68,.02 LR SUBSCRIPT
68.02,.01 LRDFN
68.02,1 FILE #
68.02,94 ORDERING LOCATION
68.02,9 DRAW TIME
68.02,13.5 INVERSE DATE
68.05,.01 SPECIMEN\n
The above references will be made from the QIP5* routines which, while
belonging to the QIP namespace, will be maintained by the lab developers.
Coordination of release and patches will be through the QIP custodial ISC.", "", "", ""], ["573", "DBIA109-C", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "61.2", "", "", "", ""], ["574", "DBIA109-D", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "62.06", "", "", "", ""], ["575", "DBIA109-E", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "63", "
63 LAB DATA
63,.01 LRDFN
63,.02 PARENT FILE
63,.03 NAME
63.04,.01 DATE/TIME SPECIMEN TAKEN
63.3,.01 ORGANISM
63.3,* FIELDS FOR ANTIBIOTICS
63.017,.01 TRANSFUSION DATE/TIME
63.017,.02 COMPONENT
63.017,.08 TRANSFUSION REACTION
63.04,* ALL LAB TEST FIELDS\n
The above references will be made from the QIP5* routines which, while
belonging to the QIP namespace, will be maintained by the lab developers.
Coordination of release and patches will be through the QIP custodial ISC.", "", "", ""], ["576", "DBIA109-F", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "66", "", "", "", ""], ["577", "DBIA109-G", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "62", "", "", "", ""], ["578", "DBIA109-H", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "60", "
60 LABORATORY TEST FILE
60,3 TYPE
60,4 SUBSCRIPT
60,400 DATA NAME\n
The above references will be made from the QIP5* routines which, while
belonging to the QIP namespace, will be maintained by the lab developers.
Coordination of release and patches will be through the QIP custodial ISC.", "", "", ""], ["579", "DBIA109-I", "File", "LAB SERVICE", "1991/10/04", "", "Retired", "Private", "61", "", "", "", ""], ["580", "DBIA110-B", "File", "SCHEDULING", "2005/06/20", "", "Retired", "Private", "40.7", "", "", "", ""], ["581", "DBIA111-B", "Routine", "REGISTRATION", "1991/05/14", "APPROVED", "Active", "Private", "", "", "", "DGANHD3", ""], ["582", "DBIA113-B", "File", "DRG GROUPER", "2003/04/21", "APPROVED", "Retired", "Private", "80", "", "", "", ""], ["583", "DBIA115-B", "Routine", "RECORD TRACKING", "1991/08/24", "APPROVED", "Active", "Private", "", "
Radiology uses a call to APL1^RTPSET to access the
RTAPL variable (record tracking system wide application variable) to insure
the radiology application of record tracking is set prior to making a record
request or displaying record information", "", "RTPSET", ""], ["584", "DBIA115-C", "Routine", "RECORD TRACKING", "1991/08/24", "APPROVED", "Active", "Private", "", "
When registering a patient exam, requests for records
from the radiology application of Record Tracking can be made by a call from
the Radiology/Nuclear Medicine package to ^RTQ5.", "", "RTQ5", ""], ["585", "DBIA115-D", "Routine", "RECORD TRACKING", "1991/08/24", "APPROVED", "Active", "Private", "", "
When displaying exam profiles, location and record
information is displayed by a call from RT^RAPROQ to ^RTUTL2. Paging
assistance is provided by variable RTESC from a call to ESC^RTRD.", "", "RTRD", ""], ["586", "DBIA118-B", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1991/10/30", "APPROVED", "Active", "Controlled Subscription", "71", "", "", "", ""], ["587", "DBIA118-C", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1991/10/30", "APPROVED", "Active", "Controlled Subscription", "71.2", "", "", "", ""], ["588", "DBIA120-B", "Routine", "RECORD TRACKING", "2003/04/21", "", "Retired", "Private", "", "\n
2. When a patient is registered, records may be requested by a
call from REFILE+2^DGREG0 to ADM^RTQ3 ^RTV(190.1,n)", "", "RTQ3", ""], ["589", "DBIA124-B", "Other", "OUTPATIENT PHARMACY", "1991/11/06", "", "Retired", "Private", "", "\n
Export of options PSOCP TRANSACTION and PSOCP RESET COPAY STATUS in
version 1 of the Integrated Billing Package.Export of the IB
SERVICE/SECTION field of the Pharmacy Site file (59) and the CO-PAY
TRANSACTION TYPE, IB NUMBER and REFILL DATE (entire multiple) fields of the
Prescription file in version 1 of the
Integrated Billing Package. Export of routines PSOCP, PSOCPA, PSOCPB,
PSOCPC, PSOCPD, PSOCPVW, PSOLBL, PSONEW, PSONEW3,PSORENW1, PSORXDL, PSORXED,
PSORXL, PSOSD0, PSOSD1,PSOSD 2, PSOSULB1, and PSOSULBL. Export PSO NEWSITE
input template of the Pharmacy Site file (59).", "", "", ""], ["590", "DBIA124-C", "File", "PHARMACY DATA MANAGEMENT", "1991/11/06", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n\n
C. Direct reference to ^PSRX(n,0) and ^PSDRUG(n,0) by Integrated Billing
for use to determine prescription number and drug name when calculating the
Brief Description field. The MUMPS code to do this is stored in the
IB ACTION TYPE file.\n\n
D. Direct reference to ^PSRX by Integrated Billing to determine if the link
between Integrated Billing and the Prescription file is intact.", "", "", ""], ["591", "DBIA124-D", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "\n\n
Direct reference to ^PSRX(n,0) and ^PSDRUG(n,0) by Integrated Billing for use
to determine prescription number and drug name when calculating the Brief
Description field. The MUMPS code to do this is stored in the IB ACTION TYPE
file.\n\n
Direct reference to ^PSRX by Integrated Billing to determine if the link
between Integrated Billing and the Prescription file is intact.\n
Direct global reads of the ICD DIAGNOSIS multiple's fields.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["592", "DBIA125-B", "File", "INTEGRATED BILLING", "1991/11/06", "APPROVED", "Active", "Private", "350.1", "
5. Direct reference to ^IBE(350.1,"B" to automatically
determine the IB CHARGE REMOVAL REASON of "RX DELETED" when a prescription is
deleted.\n
.
6. Look-up by Outpatient Pharmacy to the IB CHARGE REMOVAL REASON file, as
this is passed back to Integrated Billing with cancel transactions.\n\n
The OUTPATIENT SITE File (#59) has a pointer field to the SERVICE/SECTION File
(#49). For Pharmacy Copay to work, this field must match the SERVICE Field
(#.04) for pharmacy action types in the IB ACTION TYPE File (#350.1). This is
done by checking the "ANEW" cross reference on the SERVICE Field (#.04) in
File 350.1 with a Direct Global read:
I '$D(^IBE(350.1,"ANEW",pharmacy pointer,1,1))...", "", "", ""], ["593", "DBIA127-B", "Routine", "IFCAP", "1991/11/06", "APPROVED", "Active", "Private", "", "
This routine is used for making transactions to an
already existing bill. This would be used, for example, if a Pharmacy Co-Pay
was charged and later canceled because the patient did not receive the RX.\n
INPUT Variable: X
$P1: Transaction type. This is the pointer to the Accounts Receivable
Trans.Type file (430.3. Currently this program will support two types of
transactions:\n
INCREASE ADJUSTMENT Number: 1
DECREASE ADJUSTMENT Number: 21\n
This piece should be set to the internal value for these types, this may be
found by direct accessing the "AC" cross-reference on the Number to determine
the internal value.\n
$P2: Amount. This would be the amount of the transaction. This number must
be greater than 0 and less than 9999999.99.\n
$P3: Bill Number. This must be the .01 value of the bill from the Accounts
Receivable file (430) and must be 10 characters in length. (ex: 503-K10001).\n
$P4: User. this is the person who is making the adjustment. Pointer to the
User file (3).\n
$P5: Adjustment Date. This is the internal VA FileMan date when the
adjustment occurred.\n
$P6: Reason. This is the free text reason that the adjustment took place
(optional).\n
Output Variable: Y
$P1: Success flag. Equals 1 if successful, -1 if unsuccessful\n
$P2: Error Code. This is the error code from the IB Error file.\n
$P3: Addition Text. If additional text is required to describe the error
then it is in the third piece.", "", "PRCASER1", ""], ["594", "DBIA127-C", "File", "IFCAP", "1991/11/06", "APPROVED", "Active", "Private", "430.2", "
Integrated Billing has permission to access the
following fields:\n", "", "", ""], ["595", "DBIA127-D", "File", "IFCAP", "1991/11/06", "", "Retired", "Private", "430", "
Look-up of the Accounts Receivable file (430) by
Integrated Billing for an option to print by Coarge ID (bill number).", "", "", ""], ["596", "DBIA127-E", "Other", "IFCAP", "1991/11/06", "APPROVED", "Active", "Private", "", "
Export of data, files, functions, options, routines,
templates and security keys by Version 1 of Integrated Billing as necessary to
successfully implement the Pharmacy Co-pay project as follows:\n
File Data
ACCOUNTS RECEIVABLE (partial) (430) NO
ACCOUNTS RECEIVABLE CATEGORY (430.2) YES
ACCOUNTS RECEIVABLE TRANS.TYPE (430.3) YES
ACCOUNTS RECEIVABLE FORM LETTER (434) YES
BATCH TRANSACTION (435) YES
AR DEBTOR (412) NO
VENDOR (partial) (440) NO\n
Functions
PRCADDR1, PRCADDR2, PRCACITY, PRCASTATE, PRCAZIP\n
Security keys
PRCAY PAYMENT SUP\n
Options
PRCAL LIST MENU Accounts Receivable Status Reports
PRCAD REPORT MENU Report Menu for Accounts Receivable
PRCA CLERK`MENU Clerk's AR Menu
PRCAC TR PAYMENT Enter a Payment Transaction
PRCAC PROFILE Profile of Accounts Receivable
PRCAE FOLLOW-UP Follow-up Letter Menu
PRCAC TRANSACTION Adjustment to Accounts Receivable
PRCAC CHANGE Update Accounts Receivable
PRCAA SET/AUDIT NEW BILL Audit/Set up a New Accounts Receivable
PRCAD RECON CASHIER Agent Cashier Report
PRCAL REFER DC DC Pending Referral AR Listing
PRCAL REF DOJ DOJ Pending Referral AR Listing
PRCAL STATUS LIST Status listing for Bills
PRCAB PRINT BILLS New Bill Forms Print
PRCAA OLD BILL Establish/Edit Old Bills
PRCAC TRANS PROFILE Transaction Profile
PRCAL MEANS LIST Means Test AR List
PRCAL OTHER LIST Other Category AR List
PRCA FORWARD IRS OFFSETS Forward IRS OFFSETs to Austin
PRCAY CREATE/EDIT BATCH Create/Edit Payment Batch
PRCAT CREATE CALM Create CALM Code Sheet for Other AR Transactions
PRCAT LIST NEW TRANSACTION Other Bills pending CALM Transaction (Print)
PRCAT PAT REF NUMBER AR (New) Processing
PRCAT USER AR - Accounts Receivable Menu
PRCAT PAT COMMON Establish PAT Common Number Series
PRCAY APPROVE BATCH Approve Batch
PRCAY POST TRANS Post an approved batch to A/R
PRCAY MASTER Agent Cashier
PRCAY BATCH STATUS Batch Status Report
PRCAY ENTER A PAYMENT Enter a Payment (Agent Cashier)\n
Routines
PRCAAD, PRCABIL, PRCABD, PRCABP1, PRCABP2, PRCABP3, PRCABP31, PRCACLM,
PRCADJ, PRCADR, PRCADR1, PRCALST, PRCALT, PRCALT1, PRCAOFF, PRCAOFF2, PRCAPAT,
PRCAPAY, PRCAPAY1, PRCAPAY2, PRCAPCL, PRCAPRO, PRCAPTR, PRCAREPT, PRCARLT,
PRCASER, PRCASER1 , PRCASTA, PRCASVC3, PRCASVC4, PRCASVC5, PRCAUDT, PRCAUT1,
PRCAWO, PRCAY, PRCAYAPP, PRCAYE, PRCAYHLP, PRCAYPT, PRCAYUT, PRCFACX0\n
Templates Type File
---------------------------------------
PRCABILLVEN Input VENDOR
PRCA FY ADJ2 BATCH Input AR TRANSACTION
PRCA FY ADJ1 Input AR TRANSACTION
PRCA FY ADJ2 Input AR TRANSACTION
PRCA BATCH PAYMENT Input AR TRANSACTION
PRCA PAYMENT Input AR TRANSACTION
PRCA OLD SET Input ACCOUNTS RECEIVABLE
PRCA SET Input ACCOUNTS RECEIVABLE
PRCASVC STATUS Input ACCOUNTS RECEIVABLE
PRCASV REL Input ACCOUNTS RECIEVABLE
PRCAE AUDIT Input ACCOUNTS RECEIVABLE
PRCAC LOCATE DEBTOR Input ACCOUNTS RECEIVABLE
PRCAY TRANSACTION EDIT Input BATCH TRANSACTION
PRCAY BATCH STATUS Print BATCH TRANSACTION
PRCAR CASH Print AR TRANSACTION", "", "", ""], ["597", "DBIA127-F", "Other", "IFCAP", "1991/11/06", "", "Retired", "Private", "", "
Updating of pointer values in data by Version 1 of
Integrated Billings
post-initialization routine as necessary.", "", "", ""], ["598", "DBIY127-G", "File", "IFCAP", "2003/09/02", "", "Retired", "Private", "412", "
Direct reference to the global ^PRC(412 in the Version
1 post
initialization routine to set the STATEMENT DAY field.", "", "", ""], ["599", "DBIA127-H", "File", "IFCAP", "1991/11/06", "APPROVED", "Active", "Private", "430.6", "
Direct reference to
the global ^PRCA(430.6, to add a new entry in version 1 on the post
initialization routine.\n
Direct refe rence to global
^PRCA(430.6 to determine and set pointer values in the ACCOUNTS RECEIVABLE
CATEGORY file and in the IB ACTION TYPE file in the post initialization
routine.", "", "", ""], ["600", "DBIA127-I", "File", "IFCAP", "1991/11/06", "APPROVED", "Active", "Private", "430.3", "
Direct reference to global ^PRCA(430.3, to determine
the internal number of the decrease adjustment type when doing a decrease
adjustment and to determing the internal number of the increase adjustment
type when doing an increase adjustment type (required for input to supported
call PRCASER1).", "", "", ""], ["601", "DBIA128-B", "File", "KERNEL", "1991/11/20", "APPROVED", "Active", "Private", "4", "
New Bill and Edit Bill options have been modified to
prompt the user "Edit Debtor Address" after he/she has entered/edited the
bill. This prompt as well as the Edit AR Debtor Address option allow edits to
the NEW PERSON and INSTITUTION file.\n
for the INSTITUTION file ^DIC(4,
1) 4,1.01 - Street Address 1
2) 4,1.02 - Street Address 2
3) 4,1.03 - City
4) 4,.02 - State
5) 4,1.04 - Zip Code
6) 4.03,.03 - Phone\n
Please keep in mind that "all users" with access to the Billing menu will be
able to edit the debtor address fields (option 2).", "", "", ""], ["602", "DBIA130-B", "File", "REGISTRATION", "1991/12/04", "APPROVED", "Active", "Controlled Subscription", "8", "
Read only access to the following Files, Fields, &
X-References:\n
FILE: Eligibility Code (DIC 8) FIELDS: Name (.01) ^DIC(8,i,0)\n
Uses the "B" X-reference ^DIC(8,"B",NAME,i)\n
*this is being requested by other packages and may be incorporated
into VADPT at which time we will ask packages to use the utility", "", "", ""], ["603", "DBIA130-C", "File", "HINQ", "1991/12/04", "APPROVED", "Active", "Private", "31", "
Read only access to the following Files, Fields, &
X-References:\n
FILE: DISABILITY CONDITION (31)
^DIC(31,i,0) Field .01 Name\n
"C" X-ref ^DIC(31,"C",DX CODE,i) Field 2 DX Code
(The diagonostic codes that may be used for eligibility
determinations for ROES are stored in ^RMPFL(791810.3,. ROES
$O's through these disabilities and looks them up in ^DIC 31
using the "C" c ross-reference. The array RMPFL is built to
hold the disability conditions found.)\n
*this is being requested by other packages and may be incorporated
into VADPT at which time we will ask packages to use the utility", "", "", ""], ["604", "DBIA130-D", "File", "REGISTRATION", "1991/12/04", "APPROVED", "Active", "Private", "35", "
Read only access to the following Files, Fields, &
X-References:\n
FILE: OTHER FEDERAL AGENCY (35)
^DIC(35,i,0) FIELD .01 NAME\n
*this is being requested by other packages and may be incorporated
into VADPT at which time we will ask packages to use the utility", "", "", ""], ["605", "DBIA131-B", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
Read access to File 44 field .01 and Appointment
sub-fields 'Clinic Stop Code' and 'Patient Name'", "", "", ""], ["606", "DBIA132-B", "File", "REGISTRATION", "1991/12/05", "APPROVED", "Active", "Private", "2", "\n
For a 'death' movement: Inpatient Meds has a MUMPS cross-reference (#6)
under DATE OF DEATH field (#.351) of the PATIENT file. This cross-reference
also uses the PSJADT routines, first checking for the existence of the routine
PSJADT.", "", "", ""], ["607", "DBIA140-B", "Routine", "IFCAP", "1992/01/07", "", "Retired", "Private", "", "
2. ^PRCS58CC - Support for the close/complete action on
a 1358 daily record.
Variables:
PRCSX - 5-piece variable delimited by '^'
piece 1 = Internal daily reference no.
piece 2 = Date/Time (internal format)
piece 3 = Amount of Payment
piece 4 = Comments (limited to 78 characters)
piece 5 = Completed flag\n
Y - a one or two '^'-piece delimited variable where
piece 1 = 0 (zero) or 1 (0ne)
piece 2 = a free-text error message.", "", "PRCS58CC", ""], ["608", "DBIA140-C", "File", "IFCAP", "1992/01/07", "", "Retired", "Private", "420.5", "
3. Read access to file 420.5 (Unit of Issue)", "", "", ""], ["609", "DBIA140-D", "File", "IFCAP", "1992/01/07", "", "Retired", "Private", "440", "
4. Prosthetics to have Read, Write, and LAYGO access
to files 440 (vendor) and 441 (Item Master), thru options PRCHPC ITEM EDIT and
PRCHRC VEN EDIT, restricted through assignment of the RMPRSUPERVISOR key.
This key will be issued to a prosthetics clerk who has completed training by
Supply Service on the IFCAP conventions and procedures for entering data into
the above named files.", "", "", ""], ["610", "DBIA140-E", "File", "IFCAP", "1992/01/07", "", "Retired", "Private", "441", "
4. Prosthetics to have Read, Write, and LAYGO access
to files 440 (vendor) and 441 (Item Master), thru options PRCHPC ITEM EDIT and
PRCHRC VEN EDIT, restricted through assignment of the RMPRSUPERVISOR key.
This key will be issued to a prosthetics clerk who has completed training by
Supply Service on the IFCAP conventions and procedures for entering data into
the above named files.", "", "", ""], ["611", "DBIA140-F", "File", "IFCAP", "1992/01/07", "", "Retired", "Private", "410", "
Read access to file 410 (Control Point Activity) -
Access required to check the status of 2237's.", "", "", ""], ["612", "DBIA142-B", "File", "INTEGRATED BILLING", "1992/01/23", "APPROVED", "Active", "Private", "36", "", "", "", ""], ["613", "DBIA142-C", "File", "REGISTRATION", "1992/01/23", "APPROVED", "Active", "Private", "2", "", "", "", ""], ["614", "DBIA145-B", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/03/05", "APPROVED", "Active", "Private", "", "", "", "OR", ""], ["615", "DBIA147-B", "Routine", "CLINICAL PROCEDURES", "1992/03/11", "APPROVED", "Active", "Private", "", "
2. This results pointer is updated via calls from the
Medicine options which enter/edit results to EN^GMRCR and RESULT^GMRCR, which
are documented in the Consult/Request Tracking package.
Once the results variable pointer is defined, the Medicine Package has
provided Consult/Request Tracking with an entry point PRINT^MCOR which
extracts results information and stores them in an ^TMP array for display
purposes in OE/RR and Consult/Request Tracking.
In order to call PRINT^MCOR the Consult/Request Tracking package must define
the following variables.
ORACTION=8
GMRCSR=variable pointer to results file
GMRCPRNM=Name of procedure type, which should equal one of the Procedure
Types in File 697.2, the eighth piece.\n
The call to get the Medicine Results formats the
results in ^TMP("MC",$J,...\n
The ^TMP("MC",$J temporary global may be deleted
upon completion of use.", "", "MCOR", ""], ["616", "DBIA147-C", "File", "CLINICAL PROCEDURES", "1992/03/11", "APPROVED", "Active", "Private", "697.2", "
3. In addition to the interface the Medicine Package
has provided, an alternative method for the Medicine Package Users is provided
in a stand alone option provided by the Consult/Request Tracking Package.
This option functions as follows:
- The user selects the Medicine Procedure Type from a Protocol Menu
- The service related to the Procedure Type defined in the FILE LINK
field in Protocol File is determined
- The patient is selected.
- Consults/Request for the Service and Patient are displayed.
- At the Select Action: prompt, the user may select "AR" for associate
results
- The PRINT NAME field, in the 8th piece of the ^MCAR(697.2,D0,0) node
is the text that the Consults package uses to do a look up on the "BA"
cross-reference. The consult package gets the text for the look-up from the
Protocol name by removing the "GMRCR " prefix. The result of the "BA" lookup
allows us to find the entry in 697.2 that represents the type of procedure
that consults is processing. The GLOBAL LOCATION, the 2nd piece of the
^MCAR(697.2,D0,0) global node tells Consults what file to look for the results
in. A look-up in the GLOBAL LOCATION file allows the user to "ASSOCIATE
RESULTS" with a consult, and provide the Medicine package with the consult it
is linked to.
- The user is allowed to select from the list of Results in this results
file for the Patient. (Using Medicine "C" cross-ref.)
- Once a result entry is selected, it may be viewed using the
PRINT^MCOR, to verify these are the correct results to associate with the
request.
- The user is asked if the order status should be updated to 'Completed'
(default is yes, if no, ORSTS is incomplete)
- The user is asked to enter the name of the clinician responsible for
the results.", "", "", ""], ["617", "DBIA149-B", "File", "NATIONAL DRUG FILE", "1995/02/27", "APPROVED", "Active", "Private", "50.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.\n
The Adverse Reaction Tracking (ART) package will point to the National Drug
(50.6) file.\n
The ART package will do a direct global read of the VA DRUG CLASSIFICATION (3)
field of the DOSAGE FORM subfield (2) multiple of the NATIONAL DRUG (50.6)
file to get all the VA Drug Classes for an entry, e.g.,
D0=$O(^PSNDF(DA,2,D0)) ;loop through DOSAGE FORM subfield
Drug Class=$P(^PSNDF(DA,2,D0,0),"^",3)\n
The ART package can loop through the "B" and "T" cross-references. The "T"
cross-reference is on the TRADE NAME field which is field #2 on the subfile
50.67.", "", "", ""], ["618", "DBIA149-C", "File", "NATIONAL DRUG FILE", "1995/02/27", "", "Retired", "Private", "50.605", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
The Adverse Reaction Tracking (ART) package will point to the VA Drug Class
(50.605) file.\n
The ART package can do lookups on this file using the "C" cross-reference.
The package can do a direct global read of the the "C" cross-reference node.\n
The ART package will:
a. Use the "B" cross-reference of the VA Drug Class (50.605) file to
find the internal entry number (IEN) of a record, e. g.,
IEN=$O(^PS(50.605,"B",Class_Code,"")).\n
b. Use a direct global read on the CLASSIFICATION CODE (.01) field in
the VA Drug Class (50.605), e.g.,
Class_code=$P(PS(50.605,IEN,0),"^").\n
c. Use a direct global read on the CLASSIFICATION (1) field in the VA
Drug Class (50.605), e. g.,
Class=$P(^PS(50.605,IEN,0),"^",2).", "", "", ""], ["619", "DBIA149-D", "File", "PHARMACY DATA MANAGEMENT", "1995/02/27", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
The Adverse Reaction Tracking (ART) package will point to the Drug (50) file.\n
The ART package will:
a. Use a direct global read on the GENERIC NAME (.01) field of the
DRUG (50) file to get the Name of an entry, e.g.,
Name=$P(^PSDRUG(DA,0),"^").\n
b. Use a direct global read on the VA CLASSIFICATION (2) field of the
DRUG (50) file to get the VA Drug Class of an entry, e.g.,
VA Class=$P(^PSDRUG(DA,0),"^",2).\n
c. Use a direct global read on the NATIONAL DRUG CLASS (25) field of
the DRUG (50) file to get the VA Drug Class of an entry, e.g.,
Drug Class=$P(^PSDRUG(DA,"ND"),"^",6).\n
In each of these examples DA is an entry in the DRUG (50) file.", "", "", ""], ["620", "DBIA153-B", "File", "QUALITY ASSURANCE INTEGRATION", "1992/04/20", "APPROVED", "Active", "Private", "741.2", "
Read access to find patients who have had a QA
occurrence which was refered to peer review associated with a particular
admission.\n
FILE 741.2 QA OCCURRENCE REVIEW LEVEL
Field 1 REVIEW LEVEL NUMBER", "", "", ""], ["621", "DBIA159-B", "File", "OCCURRENCE SCREEN", "1992/06/02", "", "Retired", "Private", "741.1", "
The following references will be made from the QIP4QAO*
routines which, while belonging to the QIP namespace, will be maintained by
the occurrence screen developers. Coordination of release and patches will be
through the QIP custodial ISC.\n
#741.1 QA OCCURRENCE SCREEN CRITERIA file
.01 Code
100 Screen Status", "", "", ""], ["622", "DBIA159-C", "File", "OCCURRENCE SCREEN", "1992/06/02", "", "Retired", "Private", "741.2", "
The following references will be made from the QIP4QAO*
routines which, while belonging to the QIP namespace, will be maintained by
the occurrence screen developers. Coordination of release and patches will be
through the QIP custodial ISC.\n
#741.2 QA OCCURRENCE REVIEW LEVEL file
1 Review Level Number", "", "", ""], ["623", "DBIA159-D", "File", "OCCURRENCE SCREEN", "1992/06/02", "", "Retired", "Private", "741.6", "
The following references will be made from the QIP4QAO*
routines which, while belonging to the QIP namespace, will be maintained by
the occurrence screen developers. Coordination of release and patches will be
through the QIP custodial ISC. #741.6 QA OCCURRENCE FINDINGS file
.01 Code", "", "", ""], ["624", "DBIA159-E", "Routine", "OCCURRENCE SCREEN", "1992/06/02", "", "Retired", "Private", "", "
The following references will be made from the QIP4QAO*
routines which, while belonging to the QIP namespace, will be maintained by
the occurrence screen developers. Coordination of release and patches will be
through the QIP custodial ISC. Call to EXTDIS^QIP1DIS to get discharge data.", "", "QIP1DIS", ""], ["625", "DBIA160-B", "File", "REGISTRATION", "1992/06/08", "APPROVED", "Active", "Private", "45", "
Pulling over the following MAS data:\n
2) Automatic Casefinding PTF file Oncology is looking at the ^DGPT("ADS")
cross-reference and accessing the ^DGPT(D0,70) NODE to find the malignant ICD9
discharge codes.\n
Accessing pieces 10,16-19 and 20-24 on node 70.", "", "", ""], ["626", "DBIA163-B", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1992/06/08", "APPROVED", "Active", "Private", "70", "
For Automatic Casefinding Radiology: Oncology looking
at:\n
^RA(78.3 for a defined diagnostic code containing the word Malignancy...\n
Check the ^RADPT("AR") cross-reference for date.\n
Look at; ^RADPT(D0,"DT",D1,"P",D2,0) NODES for procedures which have the
diagnostic code found above in ^RA(78.3 - we capture those patients and the
date of the "suspicious procedures"", "", "", ""], ["627", "DBIA165-B", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/15", "APPROVED", "Active", "Private", "", "", "", "ORUHDR", ""], ["628", "DBIA165-C", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/15", "APPROVED", "Active", "Private", "", "", "", "OR6", ""], ["629", "DBIA165-D", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/15", "APPROVED", "Active", "Private", "", "", "", "ORX4", ""], ["630", "DBIA165-E", "Other", "ORDER ENTRY/RESULTS REPORTING", "1992/06/15", "APPROVED", "Active", "Private", "", "
PRINT TEMPLATES:\n
GMRC PROTOCOL LIST - This template uses the following fields to print a list
of GMRC protocols defined in the Protocol File
NAME
ITEM TEXT\n
GMRC PROTOCOL RPT - This template(uses the following fields to print details
about GMRC protocols defined in the Protocol File
NAME
ITEM TEXT
TYPE
PRINT NAME
PACKAGE
FILE LINK
DESCRIPTION
SYNONYM
ITEM SEQUENCE MNEMONIC\n
GMRC PROTOCOL RPT HDR - This template is the HEADING for the GMRC PROTOCOL RPT
print template. It includes a namespaced key for users to understand the
namespacing of Protocol file entries used by the Consult/ Request Tracking
package.", "", "", ""], ["631", "DBIA165-F", "Other", "ORDER ENTRY/RESULTS REPORTING", "1992/06/15", "APPROVED", "Active", "Private", "", "\n
SORT TEMPLATE:\n
GMRC PROTOCOLS - This sort template is used for printing the Print Templates
GMRC PROTOCOL LIST, and GMRC PROTOCOL RPT. The NAME field is used to extract
all Protocol entries with a Prefix of GMRC.\n\n", "", "", ""], ["632", "DBIA169-B", "Routine", "KERNEL", "1992/06/17", "", "Retired", "Private", "", "
DISP^XQORM1 If the standard menu help has been
replaced by defining XQORM(??),DISP^XQORM1 may be called by the help code to
display the selections on the menu. Remember DISP^XQORM1 may only be called
by the code used in XQORM(??) and X must be "?" when it is called.", "", "XQORM1", ""], ["633", "DBIA170-B", "File", "KERNEL", "1992/06/17", "APPROVED", "Active", "Private", "3", "
In the AMIE package a direct reference is made to the
USER file ^DIC(3,X,2,X1) to determine if a user has the division in question.
When this code is run in a Kernel 7 account it will not work properly.", "", "", ""], ["634", "DBIA172-B", "Routine", "INPATIENT MEDICATIONS", "2005/09/21", "", "Retired", "Private", "", "
DSS Extracts needs data from the Inpatient Medications
package which cannot be extracted from any file. The Inpatient Medications
team has agreed to modify two routines (PSGPLF and PSGAMSA) to call, after
executing %ZOSF("TEST"), routine ECXUD1 to place data into a DSS file for
future extract by DSS.\n
The requested data is placed in the ECUD variable, which the ECXUD1 routine
uses to store the data in the UNIT DOSE EXTACTS file (#720.904).", "", "PSGAMSA", ""], ["635", "DBIA181-B", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/19", "APPROVED", "Active", "Private", "", "", "", "ORUPREF2", ""], ["636", "DBIA181-C", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/19", "APPROVED", "Active", "Private", "", "", "", "ORUTL", ""], ["637", "DBIA181-D", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/19", "APPROVED", "Active", "Private", "", "", "", "ORX", ""], ["638", "DBIA181-E", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/19", "APPROVED", "Active", "Private", "", "", "", "ORX3", ""], ["639", "DBIA181-F", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/19", "APPROVED", "Active", "Private", "", "", "", "ORX8", ""], ["640", "DBIA181-G", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1992/06/19", "APPROVED", "Active", "Private", "", "", "", "ORX5", ""], ["641", "DBIA185-B", "File", "SURGERY", "1992/07/16", "APPROVED", "Active", "Private", "130", "
An E3R has been issued, asking to modify the Health
Summary Print by location option to allow selection of an Operating Room, and
to queue the selected Health Summary Type to print for all patients scheduled
for surgery in that OR on a user-specified date. To that end, the Print by
Location driver has been modified to look at the "B" cross reference of the
Operating Room File (i.e., ^SRS("B",+LOC,ORLOC)) to get the record number of
the selected OR, and then traverse the "AOR" cross reference of the Surgery
File (i.e., ^SRF("AOR",+ORLOC,SDT,SRN) to get the record number of each
surgery. It then visits the zero-node of each Surgery record to get the
patient, whom it adds to the list of patients for Health Summaries to be
printed.\n
Health Summary makes direct references to the above cited globals and cross
references.", "", "", ""], ["642", "DBIA186-B", "Routine", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGMTU", ""], ["643", "DBIA186-C", "Routine", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Controlled Subscription", "", "
Revision History:
- 9/19/24: Integrated Billing (IB) has asked Registration (DG) to
modify routine DGMTUB to include the Means Test status of 3 - No
Longer Required to the $$CK tag and to return a 1 only when called by
menu option "IB CANCEL/EDIT/ADD CHANGES".", "", "DGMTUB", "2019/02/15"], ["644", "DBIA186-D", "Routine", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "", "", "", "VADPT", ""], ["645", "DBIA186-E", "File", "INTEGRATED BILLING", "1992/07/22", "APPROVED", "Active", "Private", "36", "", "", "", ""], ["646", "DBIA186-F", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "40.8", "
40.8 DG(40.8, MEDICAL CENTER DIVISION FILE -- Printed
as part of BASC Locality Modifier entry/edit, the user is allowed to specify
which division Check-off Sheets will be printed for, the user is allowed to
choose clinics by division in the 'Clinic CPT Usage'report, pointed to by
DIVISION field in the BASC Locality Modifier file (350.5), division is used in
the BASC charge calculation\n
.01 NAME 45 DGPT PTF -- Printed on the patient appointment
Check-off Sheet\n
70 DISCHARGE DATE
79 DXLS
79.16 ICD 2
79.17 ICD 3\n
X-REF: AAD", "", "", ""], ["647", "DBIA186-G", "File", "DRG GROUPER", "1992/07/22", "", "Retired", "Private", "80", "
80 ICD9 ICD DIAGNOSIS--Used when diagnosis (PTF
and Billing) are printed on the patient appointment Check-off Sheet\n
.01 CODE NUMBER
3 DIAGNOSIS", "", "", ""], ["648", "DBIA186-H", "File", "CPT/HCPCS CODES", "1992/07/22", "APPROVED", "Retired", "Private", "81", "
Now covered by supported ICR #5408,CPT/HCPCS Procedure
File 81. 81 ICPT CPT FILE-- Since the new form of billing is based on
CPTs this file is used throughout the BASC functionality: used to create the
new table files, the Check-off Sheets, and reports on billing activity,
pointed to by PROCEDURE field in the UPDATE BILLABLE AMBULATORY SURGICAL CODE
file (350.41)", "", "", ""], ["649", "DBIA186-I", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Controlled Subscription", "391", "", "", "", ""], ["650", "DBIA186-J", "File", "REGISTRATION", "2003/06/10", "", "Retired", "Private", "5", "", "", "", ""], ["651", "DBIA186-K", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "41.3", "
Date of Test multiple Conversion of Month/Year multiple
MT billing data.", "", "", ""], ["652", "DBIA186-L", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "42", "
0th node-- Determine ward type, division of ward.", "", "", ""], ["653", "DBIA186-M", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "45.7", "
0th node-- Determine billable SPECIALTY, #42.4 0th
node-- bedsection", "", "", ""], ["654", "DBIA186-N", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "45", "
101 node-- Determine if admitted VA ADM. REG., #43.4
"D" cross-reference for Observation & SOURCE OF ADM.,#45.1 "B"
cross-reference Examination", "", "", ""], ["655", "DBIA186-O", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "405", "
PATIENT MOVEMENT, #405 0th nod-- Determine whether to
bill patient. -- "ATT1" cross-reference Determine whether -- "APCA"
cross-reference patients have been -- "APTT1" cross-reference cont.
hospitalized", "", "", ""], ["656", "DBIA186-P", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "405.1", "
FAC. MVMT TYPE, #405.1 0th node-- List movement type", "", "", ""], ["657", "DBIA186-Q", "File", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Private", "40", "
IB DIVISION DISPLAY on file 40.-- Displays a division's
billing
fields: .01 NAME-- history", "", "", ""], ["658", "DBIA187-B", "File", "HINQ", "1992/07/22", "APPROVED", "Active", "Controlled Subscription", "31", "", "", "", ""], ["659", "DBIA188-B", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
If outpatient, get appointment status", "", "SDAM1", ""], ["660", "DBIA188-C", "Routine", "SCHEDULING", "1992/07/22", "", "Retired", "Private", "", "", "", "SDUL", ""], ["661", "DBIA188-D", "Routine", "SCHEDULING", "1992/07/22", "", "Retired", "Private", "", "", "", "SDUL1", ""], ["662", "DBIA188-E", "Routine", "SCHEDULING", "1992/07/22", "", "Retired", "Private", "", "", "", "SDUL2", ""], ["663", "DBIA188-F", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "", "", "VADPT", ""], ["664", "VA UTILITY ONE/MANY/ALL", "Routine", "REGISTRATION", "1992/07/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VAUTOMA", "2009/06/03"], ["665", "DBIA188-H", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
Used in finding and printing Check-off Sheets for
patient appointments, the user is allowed to select all Check-off Sheets for a
particular clinic\n
.01 NAME -- Used in searching, sorting, and printing the Clinic CPT
Usage' report\n
2 TYPE -- Used in searching, sorting, and printing the'Clinic CPT
Usage' report\n
15 MEDICAL CENTER DIVISION -- Used in BASC charge calculation on
the Check-off Sheet and the 'Clinic CPT Usage' report\n
25 PROCEDURE CHECK-OFF SHEET -- New field, associates a clinic and
a Check-off Sheet\n
1900 APPOINTMENT SUBFILE -- Printed on a patients Check-off Sheet
.01 APPOINTMENT DATE/TIME
1 PATIENT\n
X-REF: AF\n", "", "", ""], ["666", "DBIA188-I", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "409.1", "\n
SD(409.1 APPOINTMENT TYPE FILE\n
.01 NAME
Printed on a patients Check-off Sheet\n", "", "", ""], ["667", "DBIA188-J", "File", "SCHEDULING", "1992/07/22", "", "Retired", "Private", "409.5", "
SDV SCHEDULING VISITS-- Used to sort, search and
print the 'Unbilled BASC for Insured Patient Appointment' and the 'Clinic CPT
Usage' reports.\n
2 PATIENT
21 PROCEDURE 1
22 PROCEDURE 2
23 PROCEDURE 3
24 PROCEDURE 4
25 PROCEDURE 5\n
X-REF: AP\n", "", "", ""], ["668", "DBIA188-K", "File", "SCHEDULING", "1992/07/22", "APPROVED", "Active", "Private", "409.71", "
SD(409.71 AMBULATORY PROCEDURE--Pointed to by
PROCEDURE field in the BILLABLE AMBULATORY SURGICAL CODE file (350.4), pointed
to by PROCEDURE field in the AMBULATORY SURG.CHECK-OFF SHEET PRINT FIELDS file
(350.71)\n
409.71 SD(409.71 AMBULATORY PROCEDURE\n
.01 CODE-- When BASC codes are added to 350.4 the CPT is added to
409.71 if its not already there\n
[SD-AMB-PROC-EDIT] Edit template used if new entry is added to file
409.71 during interactive edit of file 350.4\n
100 SYNONYMS SUBFILE (ALL)", "", "", ""], ["669", "DBIA188-L", "File", "SCHEDULING", "1992/07/22", "APPROVED", "Active", "Private", "40.7", "
^DIC(40.7,Clinic Stop)-- ^IBOVOP1: get clinic name -
0;1 NAME\n", "", "", ""], ["670", "DBIA188-M", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
^SC(HOSPITAL LOCATION-- ^IBOVOP1: scan clinic visits
^SDV(Scheduling Visits file) ^IBECEA3: check stop codes for a c&p
- "CS" CLINIC STOP
- "B" xref
- 0;5 APPOINTMENT TYPE
- "ADT" appointment date ^IBECEA3 ^SD(409.1,APPOINTMENT TYPE--
^IBOVOP1: get appointment type name\n
SC HOSPITAL LOCATION FILE-- Pointer to the Check-off sheet associated
with this clinic\n
25 PROCEDURE CHECK-OFF SHEET\n
x-ref: AF", "", "", ""], ["671", "DBIA188-N", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
IB Templates that look at MAS Files\n
IB CPT RG DISPLAY on file 409.71-- Displays a procedures billing fields:
.01 CODE history
.015 SHORT NAME
205 CURRENT ACTIVE STATUS", "", "", ""], ["672", "DBIA190-B", "File", "ADVERSE REACTION TRACKING", "1992/08/06", "APPROVED", "Active", "Controlled Subscription", "120.8", "\n
The Medicine package also needs to reference the following data
elements:
Patient Allergies (120.8) file:
REACTION:REACTION (10,.01) and REACTION:OTHER REACTION (10,1)
which is located in $P(^GMR(120.8,D0,10,D1,0),U,1,2).
-D0 would be obtained from a call to ^GMRADPT, and D1 would be
obtained by looping through the multiple.", "", "", ""], ["673", "DBIA190-C", "File", "ADVERSE REACTION TRACKING", "1992/08/06", "APPROVED", "Active", "Controlled Subscription", "120.83", "\n
"B" xref on NAME (.01) field which is located in ^GMRD(120.83,"B")
-This is used to determine if an entry in the REACTIONS
multiple, described above, points to the entry "OTHER REACTION".\n\n\n", "", "", ""], ["674", "DBIA191-B", "Routine", "PHARMACY DATA MANAGEMENT", "1992/08/18", "APPROVED", "Active", "Private", "", "\n
^PSODEM: This is Pharmacy's MAS patient demographic
function which is used in conjunction with the Pharmacy
Patient profile. The input variable is DA and is the
internal entry number of the VA Patient file and is
equivalent to the DFN.", "", "PSODEM", ""], ["675", "DBIA191-C", "Routine", "OUTPATIENT PHARMACY", "1992/08/18", "APPROVED", "Active", "Private", "", "\n
STAT^PSOFUNC: This is the Pharmacy treatment status
function and is used in the Pharmacy patient profile.
The required variables are RX0, RX2, and J.", "", "PSOFUNC", ""], ["676", "DBIA191-D", "Routine", "PHARMACY DATA MANAGEMENT", "1992/08/18", "APPROVED", "Active", "Private", "", "\n
DOIT^PSOP: This is the Pharmacy queue report entry point.", "", "PSOP", ""], ["677", "DBIA191-E", "File", "PHARMACY DATA MANAGEMENT", "1992/08/18", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006\n
^PS(55,DA,"P") and ^PS(55,DA,"ARC") in order to screen the
file for relevant data.", "", "", ""], ["678", "DBIA191-F", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "\n
^PSRX(DA, for prescription data.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["679", "DBIA191-G", "File", "PHARMACY DATA MANAGEMENT", "1992/08/18", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
^PSDRUG(DA, for drug data.", "", "", ""], ["680", "DBIA196-B", "File", "LAB SERVICE", "1992/09/24", "APPROVED", "Active", "Private", "61.5", "
The Medicine package has permission from the Lab
developers to correct the double entry (CARDIOASSIST, AORTIC BALLOON PUMP) in
the Lab SNOMED file.\n
The Medicine package has permission from the Lab developers to create pointer
values to the Lab SNOMED code file entries.", "", "", ""], ["681", "DBIA196-C", "File", "LAB SERVICE", "1992/09/24", "APPROVED", "Active", "Private", "63", "
The Medicine package has permission from the Lab
developers to use the following root for Fileman access to Lab chemistry
values: ^LR(DFN,""CH"", (for display only) .\n", "", "", ""], ["682", "DBIA198-B", "File", "IFCAP", "1992/11/24", "APPROVED", "Active", "Private", "442", "
In an effort to provide a receiving mechanism for
Controlled Substances module, several look-ups and pointers are necessary for
an interim interface. For Purchase Order receipts, a lookup to PROCUREMENT &
ACCOUNTING TRANSACTIONS file 442, screened by cost center [822400] is used.
For Issue Receipts, a lookup occurs, screened by cost center [822400], in
CONTROL POINT ACTIVITY file 410. A connection between the DRUG file 50 and
ITEM MASTER file 441 is crucial for posting receipt information. This may be a
one-to-many relationship and therefore involves the creation of a multiple
IFCAP ITEM NUMBER field (#50.0441) in the DRUG file 50 pointing to the ITEM
MASTER file 441. This field includes an input transform similar to that found
in the NDC field in the ITEM MASTER file 441 preventing the linking of the
same item to more than one drug. It also includes an 'AB' whole file
cross-reference.\n
Pointer to CONTROL POINT ACTIVITY file 410 Pointer to ITEM MASTER file 441
Pointer to PROCUREMENT & ACCOUNTING TRANSACTIONS file 442\n
References information (Read only) from PROCUREMENT & ACCOUNTING
TRANSACTIONS file 442
.01 PURCHASE ORDER NUMBER
.6 PARTIAL
40 ITEM
.01 LINE ITEM NUMBER
1 DESCRIPTION
1.5 REPETITIVE (PR CARD) NO.
3.1 PACKAGING MULTIPLE
9 VENDOR STOCK NUMBER
5 ACTUAL UNIT COST
20 DATE RECEIVED
1 QTY BEING RECEIVED
"AB" X-REF ON P.O. DATE (FIELD .1)\n
IFCAP files are used solely to gather and display receipt information and so
the Controlled Substances files 58.8 and 58.81 can accumulate a receipt
history.\n
DURATION: Till otherwise agreed, when the GIP & Drug Accountability interf ace
is available", "", "", ""], ["683", "DBIA199-B", "File", "QUALITY IMPROVEMENT CHECKLIST", "1992/12/04", "", "Retired", "Private", "738", "
1) ALPHA routines access the following QUIC fields in a
read-only manner:
File 738 QUALITY IMPROVEMENT CHECKLIST
.01 STATION NAME\n", "", "", ""], ["684", "DBIA211-B", "File", "LAB SERVICE", "1993/02/18", "APPROVED", "Active", "Private", "63", "
The current verification cycle of Health Summary (v2.5)
has identified a number of references to fields in Laboratory files, most of
which were present in our previous version (v1.2), but which were not
documented in our DBIA's (#67, #71, or #155) with the LAB SERVICE Package.
All Health Summary components which present Laboratory data have continued to
function without incident at all sites where Health Summary is known to be in
use, but we wanted to be sure that all of our external references were known
to the developers of the custodial packages, if only to avoid the potential
for future surprises. So, the previously undocumented references include:\n
Global: ^LR( File #: 63 File Name: LAB DATA File\n
In all cases, before calling the appropriate extract routine, we check for the
existence of Laboratory data for the patient in question by evaluating the
condition: I '$D(^LR(LRDFN)) D NOLABS Q, where LRDFN is derived from: S
LRDFN=+^DPT(DFN,"LR"). These references were not expicitly documented in
existing DBIA's.\n
Node: "MI" Sub-file #: 63.05 Sub-File Name: MICROBIOLOGY\n
Sub-node: 3 Sub-Sub-file: 63.3 Sub-Sub-file Name: ORGANISM\n
Before extrancting antibiotic susceptibilities, we test for results
using the condition: I $O(^LR(LRDFN,"MI",IX,3,ISO,1)). Reference to this
multiple was not documented in existing DBIA's.\n
Sub-nodes: 5 & 6 Sub-Sub-file: 63.34 Sub-Sub-file Name: PARASITE\n
Before extracting parasitology data, we test for results using the condition:
Q:'($D(^LR(LRDFN,"MI",IX,5))&($D(^(6)))). (i.e., we only proceed when data
are available). Reference to these nodes was not documented in existing
DBIA's.\n
Sub-nodes: 8&9 Sub-Sub-file: 63.37 Sub-Sub-file Name: FUNGUS/YEAST\n
Before extracting mycology data, we test for results using the condition:
Q:'($D(^LR(LRDFN,"MI",IX,8))&($D(^(9)))). (i.e., we only proceed when data
are available). Reference to these nodes was not documented in existing
DBIA's.\n
Sub-nodes: 11&12 Sub-Sub-file: 63.39 Sub-Sub-file Name: MYCOBACTERIUM\n
Before extracting mycobacteriology data, we test for results using the
condition: Q:'($D(^LR(LRDFN,"MI",IX,11))&($D(^(12)))). (i.e., we only proceed
when data are available). Reference to these nodes was not documented in
existing DBIA's.\n
Sub-nodes: 16&17 Sub-Sub-file: 63.43 Sub-Sub-file Name: VIRUS\n
Before extracting virology data, we test for results using the condition:
Q:'($D(^LR(LRDFN,"MI",IX,16))&($D(^(17)))). (i.e., we only proceed when data
are available). Reference to these nodes was not documented in existing
DBIA's.\n
Sub-node: 14 Sub-Sub-file: 63.42 Sub-Sub-file Name: ANTIBIOTIC LEVEL\n
Sub-Sub-node piece Sub-Sub-fld Sub-Sub-Fld Name
0 1 .01 ANTIBIOTIC (for SERUM LEVEL)
0 2 1 DRAW TIME
0 3 2 CONC(ug/ml)\n
Before checking for antibiotic serum levels under this multiple, we test for
results using the condition: I $D(^LR(LRDFN,"MI",IX,14)). This was added to
accommodate those sites which still store peak and trough antibiotic levels in
this manner, rather than under the "CH" subscript (e.g., Hines VAMC).\n
Node: "SP" Sub-file #: 63.08 Sub-File Name: SURGICAL PATHOLOGY\n
Sub-node piece Sub-fld Sub-Fld Name\n
0 11 .11 REPORT RELEASE DATE\n
(This sub-field was documented in DBIA #67, but was referred
to under its old field name "RELEASE REPORT")", "", "", ""], ["685", "DBIA211-C", "File", "LAB SERVICE", "1993/02/18", "APPROVED", "Active", "Private", "65", "
The current verification cycle of Health Summary (v2.5)
has identified a number of references to fields in Laboratory files, most of
which were present in our previous version (v1.2), but which were not
documented in our DBIA's (#67, #71, or #155) with the LAB SERVICE Package.
All Health Summary components which present Laboratory data have continued to
function without incident at all sites where Health Summary is known to be in
use, but we wanted to be sure that all of our external references were known
to the developers of the custodial packages, if only to avoid the potential
for future surprises. So, the previously undocumented references include:\n
Global: ^LRD(65, File #: 65 File Name: BLOOD INVENTORY File\n
Node piece field # Field Name
0 4 .04 COMPONENT
8 3 8.3 DONATION TYPE
(we check for the existence of the "8-node prior" to calling
EN^DIQ1 to get the external format of the DONATION TYPE field)\n
Node: 3 Sub-file #: 65.03 Sub-File Name: DATE/TIME UNIT RELOCATION\n
Sub-node piece Sub-fld Sub-Fld Name
0 4 .04 LOCATION
(this sub-field is accessed to determine the last known location
of a given unit).", "", "", ""], ["686", "DBIA211-D", "File", "LAB SERVICE", "1993/02/18", "APPROVED", "Active", "Private", "69", "
The current verification cycle of Health Summary (v2.5)
has identified a number of references to fields in Laboratory files, most of
which were present in our previous version (v1.2), but which were not
documented in our DBIA's (#67, #71, or #155) with the LAB SERVICE Package.
All Health Summary components which present Laboratory data have continued to
function without incident at all sites where Health Summary is known to be in
use, but we wanted to be sure that all of our external references were known
to the developers of the custodial packages, if only to avoid the potential
for future surprises. So, the previously undocumented references include:\n
Global: ^LRO(69, File #: 69 File Name: LAB ORDER ENTRY File\n
Node: 1 Sub-file #: 69.01 Sub-File Name: SPECIMEN #\n
Sub-node piece Sub-fld Sub-Fld Name
3 1 .01 LAB ARRIVAL TIME
3 2 .02 DATE/TIME RESULTS AVAILABLE
(these fields are accessed to determine the status of a given
lab order). Sub-node: 4 Sub-sub-file #: 69.02 Sub-sub-file Name:
SPECIMEN
Sub-sub-node piece Sub-sub-fld Sub-sub-fld Name
0 1 .01 SPECIMEN", "", "", ""], ["687", "DBIA211-E", "File", "LAB SERVICE", "1993/02/18", "APPROVED", "Active", "Private", "68", "
The current verification cycle of Health Summary (v2.5)
has identified a number of references to fields in Laboratory files, most of
which were present in our previous version (v1.2), but which were not
documented in our DBIA's (#67, #71, or #155) with the LAB SERVICE Package.
All Health Summary components which present Laboratory data have continued to
function without incident at all sites where Health Summary is known to be in
use, but we wanted to be sure that all of our external references were known
to the developers of the custodial packages, if only to avoid the potential
for future surprises. So, the previously undocumented references include:
Global: ^LRO(68, File #: 68 File Name: ACCESSION File\n
Node: 1 Sub-file #: 68.01 Sub-File Name: DATE Sub-node: 1 Sub-sub-file
#: 68.02 Sub-sub-file Name: ACCESSION #
Sub-sub-node piece Sub-sub-fld Sub-sub-fld Name
.2 1 15 ACCESSION\n
We determine the Accession number using the following code: S
ACC=$S($D(^LRO(68,+ACCA,1,+ACCD,1,+ACCN,.2)):^(.2),1:"NONE")\n", "", "", ""], ["688", "DBIA218-B", "Routine", "REGISTRATION", "1993/03/04", "APPROVED", "Active", "Private", "", "
The Surgery package has permission from the MAS package
to do the following:\n
Make a call to the routine VACPT. The call to ^VACPT is made upon entry into
the Surgery package to display the CPT copyright message. Surgery executes
^%ZOSF("TEST") before calling ^VACPT.\n", "", "VACPT", ""], ["689", "DBIA218-C", "File", "REGISTRATION", "1993/03/04", "APPROVED", "Active", "Private", "2", "
Surgery is also granted permission from the MAS package
to make the following references (READ only) to MAS data.\n
The first two references listed are used in conjunction with the Surgery
Mortality Report. ^DPT("AEXP1",DATE OF DEATH,DFN) The Surgery Mortality
Report loops through the "AEXP1" cross reference to locate patients who
expired within a selected date range.\n
Surgery also has permission to call the following: The Surgery Waiting List
reports include items from the PATIENT file (#2) almost all of which we are
able to retrieve by means of supported calls to VADPT. One item that is not
returned by VADPT is the patient's telephone number at work, which is stored
in the PHONE NUMBER [WORK] field (#.132), located in $P(^DPT(DFN,.13),"^",2).
Surgery has permission to READ only the second piece of the .13 node for the
patient's work telephone number.", "", "", ""], ["690", "DBIA218-D", "File", "REGISTRATION", "1993/03/04", "APPROVED", "Active", "Private", "45", "
Surgery is also granted permission from the MAS package
to make the following references (READ only) to MAS data.\n
3rd piece of ^DGPT(INTERNAL ENTRY IN FILE 45,70) Once the patient's last
admission is determined, the Mortality Report checks this piece, which stores
the TYPE OF DISPOSITION, to determine whether an autopsy was performed. If
the TYPE OF DISPOSITION is 6, an autopsy was performed; if 7, no autopsy was
performed; if not 6 or 7, the autopsy information is not available.", "", "", ""], ["691", "DBIA218-E", "File", "REGISTRATION", "1993/03/04", "APPROVED", "Active", "Private", "41.1", "
Surgery is also granted permission from the MAS package
to make the following references (READ only) to MAS data.\n
The following two items are used together on several reports.\n
^DGS(41.1,"B",DFN,INTERNAL ENTRY IN FILE 41.1) The various Surgery Schedule
reports loop through the B cross reference to locate scheduled admissions for
the patient if the patient is not an inpatient already.\n
Second piece of ^DGS(41.1,INTERNAL ENTRY IN FILE 41.1,0) This piece, which
holds the RESERVATION DATE/TIME of the scheduled admission, is checked for
each scheduled admission found in the B cross reference to determine if the
RESERVATION DATE/TIME is future. If there is a future scheduled admission, the
report prints "ADM. PENDING" for the patient.", "", "", ""], ["692", "DBIA221-B", "File", "NATIONAL DRUG FILE", "1993/04/21", "APPROVED", "Active", "Private", "50.416", "
Outpatient Pharmacy is given permission by Pharmacy to
make the following calls:\n
GLOBAL MAP DATA DICTIONARY #50.416 -- DRUG INGREDIENTS FILE 2/26/93 STORED
IN ^PS(50.416, SITE: ISC BIRMINGHAM
-----------------------------------------------------------------------
^PS(50.416,D0,0)= (#.01) NAME [1F] ^ ^PS(50.416,D0,1,0)=^50.4161A^^ (#1) DRUG
IDENTIFIER ^PS(50.416,D0,1,D1,0)= (#.01) DRUG IDENTIFIER [1F] ^\n\n", "", "", ""], ["693", "DBIA221-C", "File", "PHARMACY DATA MANAGEMENT", "1993/04/21", "", "Retired", "Private", "55", "
Outpatient Pharmacy is given permission by Pharmacy to
make the following calls:\n
GLOBAL MAP DATA DICTIONARY #55 -- PHARMACY PATIENT FILE 2/26/93
STORED IN ^PS(55, SITE: ISC BIRMINGHAM
----------------------------------------------------------------------
^PS(55,D0,0)= (#.01) NAME [1P] ^ (#.02) CAP [2S] ^ (#.03) MAIL [3S] ^
==>(#.04) DIALYSIS PATIENT [4S] ^ ^PS(55,D0,1)= (#1) NARRATIVE [1F]
^ ^PS(55,D0,40)= (#40) COMMUNITY NURSING HOME [1S] ^ (#40.1) NURSING HOME
==>CONTRACT [2S] ^ (#40.2) LAST DATE OF CONTRACT [3D] ^
==>(#41) RESPITE PATIENT START DATE [4D] ^ (#41.1) RESPITE
==>PATIENT END DATE [5D] ^ ^PS(55,D0,ARC,0)=^55.13DA^^ (#101) ARCHIVE
DATE ^PS(55,D0,ARC,D1,0)= (#.01) ARCHIVE DATE [1D] ^ ^PS(55,D0,P,0)=^55.03P^^
(#52) PRESCRIPTION PROFILE ^PS(55,D0,P,D1,0)= (#.01) PRESCRIPTION PROFILE [1P]
^ ^PS(55,D0,PS)= (#3) PATIENT STATUS [1P] ^ ^PS(55,D0,SAND)= (#53) CLOZAPINE
REGISTRATION NUMBER [1F] ^ (#54)
==>CLOZAPINE STATUS [2S] ^ (#55) DATE OF LAST CLOZAPINE RX [3D] ^
==>(#56) DEMOGRAPHICS SENT [4S] ^ (#57) RESPONSIBLE PROVIDER
==>[5P] ^ (#58) REGISTRATION DATE [6D] ^", "", "", ""], ["694", "READ AND WRITE ACCESS TO FILE 59.7", "File", "PHARMACY DATA MANAGEMENT", "1993/04/21", "APPROVED", "Active", "Controlled Subscription", "59.7", "
Outpatient Pharmacy is given permission by Pharmacy
Data Mgmt for direct global read/write access and read/write access with
Fileman to the fields listed explicitly in this agreement which reside on the
47 multiple.\n
CMOP and OPT PS are given read with FM/DGR access permission to all other
fields listed explicitly in this agreement.", "", "", "2007/04/17"], ["695", "DBIA221-E", "File", "PHARMACY DATA MANAGEMENT", "2005/07/27", "", "Retired", "Private", "59.9", "
Outpatient Pharmacy is given permission by Pharmacy to
make the following calls:\n
GLOBAL MAP DATA DICTIONARY #59.9 -- *PHARMACY FUNCTIONS FILE STORED IN
^DIC(59.9 SITE: ISC BIRMINGHAM all fields in the file.", "", "", ""], ["696", "DBIA221-F", "File", "NATIONAL DRUG FILE", "1993/04/21", "APPROVED", "Active", "Private", "50.605", "
Outpatient Pharmacy is given permission by Pharmacy to
make the following calls: GLOBAL MAP DATA DICTIONARY #50.605 -- VA DRUG CLASS
FILE STORED IN ^PS(50.605 SITE: ISC BIRMINGHAM
-----------------------
All fields in the file.\n", "", "", ""], ["697", "DBIA222-B", "File", "CPT/HCPCS CODES", "1993/04/02", "", "Retired", "Private", "81", "
The DD for the CPT file (81) includes the following
node which causes the CPT code description to be displayed when a lookup is
done on the CPT file:
^DD(81,0,"ID",2)="W " ",$P(^(0),U,2) I $D(SRSITE) D ^SROCPT"\n
An agreement is established for Surgery to call ^DD(81,0,"ID",2). This DD
node will remain in place to assist with CPT lookups from within the Surgery
package. Surgery will be responsible for support of the conditional call to
^SROCPT.\n", "", "", ""], ["698", "DBIA225-B", "File", "IFCAP", "1993/04/21", "APPROVED", "Active", "Private", "445", "
Read only access to the .01 field of File 445 to get
the IEN of the Inventory Point so that we can set it in variable PRCP("I") and
use it to a call to routine PRCPUSA. The look-up to the .01 field would be
through a Fileman call to ^DIC, and a successful lookup would return the IEN
which would then be used in setting the above IFCAP variable.", "", "", ""], ["699", "DBIA226-B", "Routine", "REGISTRATION", "1993/05/03", "APPROVED", "Active", "Private", "", "", "", "DGREG", ""], ["700", "DBIA226-C", "Routine", "REGISTRATION", "1993/05/03", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGRPDB", ""], ["701", "DBIA226-D", "Routine", "REGISTRATION", "1993/05/03", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGMTU", ""], ["702", "DBIA226-E", "File", "REGISTRATION", "1993/05/03", "APPROVED", "Active", "Private", "21", "
Point to the following file\n
PERIOD OF SERVICE - 21", "", "", ""], ["703", "DBIA226-F", "File", "REGISTRATION", "1993/05/03", "APPROVED", "Retired", "Private", "2", "
Input Template in file 2 for patient address\n
[FBAA ADDRESS EDIT]\n
Ability to add insurance company information into the patient file. This does
NOT include the editing current insurance data on file.", "", "", ""], ["704", "DBIA227-B", "File", "IFCAP", "1993/05/05", "APPROVED", "Active", "Private", "442", "
Prosthetics is granted permission to make the following
calls to the IFCAP package (GIP and 1358 Modules). As stated below this is
until the next version of either IFCAP or Prosthetics.\n
For the 1358 Module: Item 4 is needed so that Prosthetics can calculate the
amount remaining on the original 1358 obligation by subtracting Field #94 from
field #96.\n
Item 4 Description: Read Only access to File #442, PROCUREMENT & TRANSACTIONS
FILE, fields 94, ACTUAL 1358 BALANCE, and 96, ESTIMATED 1358 BALANCE.", "", "", ""], ["705", "DBIA228-B", "File", "INTEGRATED BILLING", "1993/05/12", "APPROVED", "Active", "Private", "353.2", "", "", "", ""], ["706", "DBIA229-B", "Other", "1", "1993/05/18", "APPROVED", "Active", "Private", "", "\n\n
MailMan V7 has permission to make the following calls to FileMan:\n
2. MailMan has always used its text field such that non-integer nodes are
not a problem to it. This is explicitly done for network mail headers, which
are not expected to be in any way handled by FileMan. In this case the lines
.001 through .999 are reserved for recording information passed by the network
on message deliveries.\n
3. While editing the Message file users have a capability to 'transfer text'
from other text processing fields. Currently they can reference the text
fields of other messages that they either sent or are a recieient of and the
responses to these messages. Other prospective files from which textual
information may be extracted via this method include the Help Frame file.
Security is kept for the privacy of each user by using the screen on the file
during the look-up when transfering text from the Message file.\n", "", "", ""], ["707", "DBIA237-B", "Routine", "OUTPATIENT PHARMACY", "1993/06/15", "APPROVED", "Active", "Private", "", "
Integrated Billing is given permission from Outpatient
Pharmacy to call HD^PSOSD2 and PAT^PSOSD for the purpose of printing the
Action Profile and the Information Profile in batch.\n
CONDITIONS: The entry points may only be used in an approved fashion. The
following subroutine uses the entry points in an acceptable manner:\n
RXPROF ;For printing the Outpatient Pharmacy Action Profile or the
;Information Profile for a single patient whose DFN is defined.
;Does not ask for the device nor close the device.
;INPUTS:
;PSDAYS = number of days to print the medication profile for
;PSTYPE=1 for the Action Profile, =0 for the Information Profile
;DFN
;
N IBDFN,ADDR,ADDRFL,CLASS,CNDT,DRUG,HDFL,I,II,J,L,LINE,P,PAGE,
PSDOB,PSII X,PSNAME,PSOI,PSSN,PSIX,PGM,PRF,PSDATE,VAL,VAR,RX,
RX0,RX2,ST,ST0,PSDAY,RF,RFS,PSOPRINT,X1,X2,ZTSK,X,Y,PSII,PSDT,LMI
S IBDFN=DFN
S X1=DT,X2=-PSDAYS D C^%DTC S (PSDATE,PSDAY)=X
S LINE="" F I=1:1:132 S LINE=LINE_"-"
S PAGE=1
D HD^PSOSD2,PAT^PSOSD
W @IOF
S DFN=IBDFN
Q\n\n", "", "PSOSD", ""], ["708", "DBIA238-B", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1993/06/15", "APPROVED", "Active", "Private", "", "", "", "RAUTL3", ""], ["709", "DBIA239-B", "Routine", "MAILMAN", "1993/06/15", "", "Retired", "Private", "", "", "", "XMA21", ""], ["710", "DBIA240-B", "Routine", "LAB SERVICE", "1993/06/15", "APPROVED", "Active", "Private", "", "
Laboratory Package has given permission to AMIE to make
the following calls: Routine Calls:
CH^LRRP2
MI^LRRP2
PT^LRX Current Agreement number 95 Per our phone conversation on
6/7/93. No more setting of the ZTSK AND ZTQUEUED variables. Call the
following entry points: D DT^LRX,EN^LRPARAM. This will work for any version
of Lab.\n", "", "LRRP2", ""], ["711", "DBIA241-B", "File", "MAILMAN", "1993/06/15", "APPROVED", "Active", "Private", "4.2", "", "", "", ""], ["712", "DBIA241-C", "File", "KERNEL", "2003/06/10", "", "Retired", "Private", "5", "", "", "", ""], ["713", "DBIA241-D", "File", "KERNEL", "1993/06/15", "APPROVED", "Active", "Private", "200", "", "", "", ""], ["714", "DBIA241-E", "Routine", "KERNEL", "1993/06/15", "APPROVED", "Active", "Private", "", "", "", "WPSEFM", ""], ["715", "DBIA240-C", "Routine", "LAB SERVICE", "1993/06/15", "APPROVED", "Active", "Private", "", "
Laboratory Package has given permission to AMIE to make
the following calls: Routine Calls:
PT^LRX Current Agreement number 95 Per our phone conversation on
6/7/93. No more setting of the ZTSK AND ZTQUEUED variables. Call the
following entry points: D DT^LRX,EN^LRPARAM. This will work for any version
of Lab.\n", "", "LRX", ""], ["716", "DBIA240-D", "Routine", "LAB SERVICE", "1993/06/15", "APPROVED", "Active", "Private", "", "
Laboratory Package has given permission to AMIE to make
the following calls: Per our phone conversation on 6/7/93. No more setting of
the ZTSK AND ZTQUEUED variables. Call the following entry points: D
DT^LRX,EN^LRPARAM. This will work for any version of Lab.\n", "", "LRPARAM", ""], ["717", "DBIA242-B", "File", "HEALTH SUMMARY", "1993/06/15", "APPROVED", "Active", "Controlled Subscription", "142", "
PIMS will also store the DEFAULT HEALTH SUMMARY (Field
#43) in the MAS PARAMETERS File (File #43) which will be a pointer to the
HEALTH SUMMARY TYPE File (#142). Access to the .01 field of File #142 will be
read- only. Data will be retrieved via KERNEL utilities.\n", "", "", ""], ["719", "DBIA243-C", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "45", "
PTF file (#45)\n
^DGPT(D0,0)= (#.01) PATIENT [1P] ^ (#2) ADMISSION DATE [2D] ^ (#3)
FACILITY [3N] ^ (#5) SUFFIX [5F] ^ (#11) TYPE OF RECORD
[11S]\n
^DGPT(D0,70)= (#71) DISCHARGE SPECIALTY [2P] ^ (#75) PLACE OF DISPOSITION
[6P] ^ (#79) DXLS [10P] ^ (#79.16) ICD 2 [16P] ^ (#79.17)
ICD 3 [17P] ^ (#79.18) ICD 4 [18P] ^ (#79.19) ICD 5 [19P] ^
(#79.201) ICD 6 [20P] ^ (#79.21) ICD 7 [21P] ^ (#79.22) ICD
8 [22P] ^ (#79.23) ICD 9 [23P] ^ (#79.24) ICD 10 [24P]\n
^DGPT(D0,101)= (#20) SOURCE OF ADMISSION [1P]", "", "", ""], ["720", "DBIA243-D", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "405.2", "
MAS Movement Type file (#405.2)\n
^DG(405.2,D0,0) - $D check on zero node", "", "", ""], ["721", "DBIA243-E", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "42.4", "
Specialty file (#42.4)\n
^DIC(42.4,D0,0) - $D check on zero node", "", "", ""], ["722", "DBIA243-F", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "405.4", "
Room-Bed file (#405.4)\n
^DG(405.4,D0,0)= (#.01) NAME [1F]", "", "", ""], ["723", "DBIA243-G", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Controlled Subscription", "42", "
^DIC(42,D0,0)= (#.03) SERVICE [3S] Direct Global
Read", "", "", ""], ["724", "DBIA243-H", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "45.1", "
Source of Admission file (#45.1)\n
^DIC(45.1,D0,0)= (#.01) PTF CODE [1F]", "", "", ""], ["725", "DBIA243-I", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "45.7", "
^DIC(45.7,D0,0)= (#1) SPECIALTY [2P]", "", "", ""], ["726", "DBIA243-J", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "45.6", "
Place of Disposition file (#45.6)\n
^DIC(45.6,D0,0)= (#2) CODE [2F]", "", "", ""], ["727", "DBIA243-K", "File", "REGISTRATION", "1993/06/15", "", "Retired", "Private", "80", "
ICD Diagnosis file (#80)\n
^ICD9(D0,0)= (#.01) CODE NUMBER [1F]", "", "", ""], ["728", "DBIA244-B", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Controlled Subscription", "40.8", "", "", "", ""], ["729", "DBIA244-C", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Controlled Subscription", "405.2", "
^DG(405.2, 0;1 MAS Movement Type", "", "", ""], ["730", "DBIA244-D", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Private", "405", "
^DGPM( 0;1 Date/Time of Movement
0;2 Transaction
0;17 Discharge/Check out Movement
0;18 MAS Movement Type
^DGPM("AMV1"
^DGPM("APTT1"
^DGPM("APID"
^DGPM("AMV3"", "", "", ""], ["731", "DBIA244-E", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Controlled Subscription", "8", "
^DIC(8, 0;6 Print Name of elig. code
^DIC(8,"D"", "", "", ""], ["732", "DBIA244-F", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Private", "21", "
^DIC(21, 0;1 Period Service name
^DIC(21,"D"", "", "", ""], ["733", "READ ACCESS TO ICD9 CODE INFORMATION", "File", "HINQ", "1993/06/15", "APPROVED", "Active", "Controlled Subscription", "31", "", "", "", "2007/09/27"], ["734", "DBIA244-H", "File", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Private", "42", "
^DIC(42, 0;2 Bedsection", "", "", ""], ["735", "DBIA244-I", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
^SC( 0;1 Hopital Location name
^SC("C"", "", "", ""], ["736", "DBIA244-J", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "409.1", "
^SD(409.1 0;1 Appointment Type name", "", "", ""], ["737", "DBIA244-K", "File", "SCHEDULING", "1993/06/15", "", "Retired", "Private", "409.5", "
^SDV( 0 Checks for the existence
of", "", "", ""], ["738", "DBIA244-L", "File", "KERNEL", "1993/06/15", "APPROVED", "Active", "Controlled Subscription", "40.5", "
^HOLIDAY Check if date is a
holiday", "", "", ""], ["739", "DBIA244-M", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "", "", "SDM", ""], ["740", "DBIA244-N", "Routine", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Private", "", "", "", "DGRPD", ""], ["741", "DBIA244-O", "Routine", "REGISTRATION", "1993/06/15", "APPROVED", "Active", "Private", "", "
Variables:
MAS variables used: DGCHANGE
0 DGCODE
DGDR
DGERR
DGNODE
DGPC
DGPTND
DGPTND(
DGQ
DGQCODE
DGQNODES
DGRPS
DGX The call to DGRPE and the DG variables are part of an
PIMS routine and call to edit the patient address information. It will be
under the AMIE namespace until which time the routine is released with PIMS.", "", "DGRPE", ""], ["742", "DBIA251-B", "File", "KERNEL", "1993/07/20", "APPROVED", "Active", "Private", "19", "
Read/write access to the following fields in the OPTION
file (#19). (To save/restore these values upon an installation.) 200 QUEUED
TO RUN AT WHAT TIME 201 DEVICE FOR QUEUED JOB OUTPUT 202 RESCHEDULING
FREQUENCY 203 QUEUED TO RUN ON VOLUME SET", "", "", ""], ["743", "DBIA252-B", "File", "LAB SERVICE", "1993/07/20", "APPROVED", "Active", "Controlled Subscription", "63", "
Fields: subscript;piece
63,.02 PARENT FILE 0;2
63,.03 NAME 0;3\n
The ^LR(D0,"CH",D1,Node) nodes for read access to the lab test results.", "", "", ""], ["744", "DBIA253-B", "Routine", "HEALTH SUMMARY", "1993/07/26", "APPROVED", "Active", "Controlled Subscription", "", "
Integrated Billing has permission from Health Summary
to make the following calls:\n
1) Permission to print Health Summaries by calling ENX^GMTSDVR if it exists.", "", "GMTSDVR", ""], ["745", "DBIA253-C", "Routine", "HEALTH SUMMARY", "1993/07/26", "APPROVED", "Active", "Controlled Subscription", "", "
Integrated Billing has permission from Health Summary
to make the following calls:\n
1) If ENX^GMTSDVR does not exist (version 2.5 or latter not installed),
permission to print Health Summaries by:\n
b) Calling SELTYP1^GMTS and then EN^GMTS1 to print the Health Summary.", "", "GMTS", ""], ["746", "DBIA253-D", "Routine", "HEALTH SUMMARY", "1993/07/26", "APPROVED", "Active", "Controlled Subscription", "", "
Integrated Billing has permission from Health Summary
to make the following calls:\n
1) If ENX^GMTSDVR does not exist (version 2.5 or latter not installed),
permission to print Health Summaries by:\n
A) Calling SELTYP1^GMTS and then EN^GMTS1 to print the Health Summary.", "", "GMTS1", ""], ["747", "DBIA261-B", "Routine", "SCHEDULING", "1993/08/09", "", "Retired", "Private", "", "
The option HBHC Appointment uses the MAS routine ^SDM
as the Run Routine, and employs SDM^SDKILL in the exit action. The option
HBHC Cancel Appointment uses ^SDCNP as the Run Routine, and the SDCNP^SDKILL
in the Exit Action.\n
Select OPTION to edit: HBHC APPOINTMENT Make Appointment NAME: HBHC
APPOINTMENT// MENU TEXT: Make Appointment// PACKAGE: HOSPITAL BASED HOME
CARE// DESCRIPTION:
1>This option utilizes the MAS Scheduling Option, Make Appointment [SDM],
2>for entry of appointment data. The Exit Action on this option runs a
3>routine that creates records in the HBHC Visit File (HBHC(632)) using
4>the appointment data entered. Only data for clinics contained in the
5>HBHC Clinic File (HBHC(631.6)) will be added to the HBHC Visit File.\n
EDIT Option: TYPE: run routine// ENTRY ACTION: D:$T(HDLKILL^SDAMEVT)]""
HDLKILL^SDAMEVT EXIT ACTION: D SDM^SDKILL K ORACTION,ORVP,XQORQUIT W
!!,"Adding entries
to the visit file..." D WAIT^DICD,^HBHCAPPT
D:$T(HDLKILL^SDAMEVT)]"" HDLKILL^SDAMEVT
Replace ROUTINE: SDM//\n\n
Select OPTION to edit: HBHC CANCEL APPOINTMENT Cancel Appointment
NAME: HBHC CANCEL APPOINTMENT Replace MENU TEXT: Cancel Appointment//
PACKAGE: HOSPITAL BASED HOME CARE DESCRIPTION:
1>This option utilizes the MAS Scheduling Option, Cancel Appointment
2>[SD CANCEL APPOINTMENT], for cancelling appointments. The Exit Action
3>on this option runs a routine that updates records in the HBHC Visit
4>File (HBHC(632)) using the cancellation data entered. EDIT Option:\n
TYPE: run routine// ENTRY ACTION: D:$T(HDLKILL^SDAMEVT)]"" HDLKILL^SDAMEVT
EXIT ACTION: D SDCNP^SDKILL W !!,"Updating entries in the visit
file..." D WAIT^DICD,^HBHCCAN D:$T(HDLKILL^SDAMEVT)]"" HDLKILL^SDAMEVT
Replace ROUTINE: SDCNP//", "", "SDKILL", ""], ["748", "DBIA261-C", "Routine", "SCHEDULING", "1993/08/09", "", "Retired", "Private", "", "
The option HBHC Cancel Appointment uses ^SDCNP as the
Run Routine, and the SDCNP^SDKILL in the Exit Action.\n\n
Select OPTION to edit: HBHC CANCEL APPOINTMENT Cancel Appointment
NAME: HBHC CANCEL APPOINTMENT Replace MENU TEXT: Cancel Appointment//
PACKAGE: HOSPITAL BASED HOME CARE DESCRIPTION:
1>This option utilizes the MAS Scheduling Option, Cancel Appointment
2>[SD CANCEL APPOINTMENT], for cancelling appointments. The Exit Action
3>on this option runs a routine that updates records in the HBHC Visit
4>File (HBHC(632)) using the cancellation data entered. EDIT Option:\n
TYPE: run routine// ENTRY ACTION: D:$T(HDLKILL^SDAMEVT)]"" HDLKILL^SDAMEVT
EXIT ACTION: D SDCNP^SDKILL W !!,"Updating entries in the visit
file..." D WAIT^DICD,^HBHCCAN D:$T(HDLKILL^SDAMEVT)]"" HDLKILL^SDAMEVT
Replace ROUTINE: SDCNP//", "", "SDCNP", ""], ["749", "DBIA261-D", "File", "SCHEDULING", "1993/08/09", "", "Retired", "Private", "44", "
In routine HBHCAPPT
$O(^SC(HBHCCLN,"S",HBHCAPDT))
$O(^SC(HBHCCLN,"S",HBHCAPDT,1,HBHCSCN))", "", "", ""], ["750", "DBIA263-B", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "", "", "VAFHLZCT", ""], ["751", "DBIA263-C", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "", "", "VAFHLZDP", ""], ["752", "DBIA263-D", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Controlled Subscription", "", "
Supported calls for building of HL7 ZPD segment (VA
Specific Patient Demographics).", "", "VAFHLZEL", "2010/06/20"], ["753", "DBIA263-E", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "", "", "VAFHLZEM", ""], ["754", "DBIA263-F", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "", "", "VAFHLZGD", ""], ["755", "DBIA263-G", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "", "", "VAFHLZIC", ""], ["756", "DBIA263-H", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "", "", "VAFHLZMT", ""], ["757", "DBIA263-I", "Routine", "REGISTRATION", "1993/08/10", "", "Retired", "Private", "", "
duplicate of IA 751", "", "VAFHLZDP", ""], ["758", "DBIA263-J", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Controlled Subscription", "", "
This generic extrinsic function returns the HL7
VA-Specific Temporary Address (ZTA) segment.", "", "VAFHLZTA", ""], ["759", "DBIA263-K", "Routine", "REGISTRATION", "1993/08/10", "", "Retired", "Private", "", "", "", "VASITE", ""], ["760", "DBIA263-L", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "
Means Test integration: IVM uses means test
extensively as means test is the vehicle by which patients are determined to
require income verification. We request the following integration with the
means test module:\n
Routines: $$LYR^DGMTSCU1", "", "DGMTSCU1", ""], ["761", "DBIA263-M", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "
Means Test integration: IVM uses means test
extensively as means test is the vehicle by which patients are determined to
require income verification. We request the following integration with the
means test module:\n
Routines: $$LST^DGMTU", "", "DGMTU", ""], ["762", "DBIA263-N", "Routine", "REGISTRATION", "1993/08/10", "APPROVED", "Other", "Controlled Subscription", "", "
Means Test integration: IVM uses means test
extensively as means test is the vehicle by which patients are determined to
require income verification. We request the following integration with the
means test module:\n
Routines: ALL^DGMTU21", "", "DGMTU21", ""], ["763", "DBIA263-O", "File", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "408.31", "\n
^DGMT(408.31,: - "B" x-ref used to loop through means tests since
January 1 in 2 places (one is a counter, one is the
bulk transmission code). It then looks at piece 2
(DFN). These references will be removed after this
version.
- 0 node used to retrieve the following other fields:
.03 STATUS - used in determining if pt meets IVM
transmission criteria...checks for 4
or 6.
.04 INCOME \\ used to determine if
.1 ADJUDICATION DATE/TIME > pts income changed
.12 THRESHOLD A / from C to A", "", "", ""], ["764", "DBIA263-P", "Other", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "
IVM attaches a protocol to the event driver.", "", "", ""], ["765", "DBIA263-Q", "Other", "REGISTRATION", "1993/08/10", "APPROVED", "Active", "Private", "", "
IVM exports VAFHL* routines", "", "", ""], ["766", "DBIA268-B", "File", "INTEGRATED BILLING", "1993/08/25", "APPROVED", "Active", "Private", "36", "\n
FILE NO. FIELD NO NODE;PIECE DESCRIPT
36 .111 .11;1 STREET ADDRESS [LINE 1]
.112 .11;2 STREET ADDRESS [LINE 2]
.113 .11;3 STREET ADDRESS [LINE 3]
.114 .11;4 CITY
.115 .11;5 STATE
.116 .11;6 ZIP CODE
.131 .13;1 PHONE NUMBER", "", "", ""], ["767", "DBIA268-C", "File", "REGISTRATION", "1993/08/25", "APPROVED", "Active", "Controlled Subscription", "38.1", "
This DBIA allows access to the DG SECURITY LOG file to
determine whether a patient is considered sensitive.\n
Since this file is DINUMed to the PATIENT file, security can be checked by
ensuring that the 2nd piece of the 0 node is equal to 1:\n
I $P($G(^DGSL(38.1,DFN,0)),"^",2)", "", "", ""], ["768", "DBIA268-D", "Routine", "REGISTRATION", "1993/08/25", "APPROVED", "Active", "Private", "", "
Parts of the following routines have been copied and
altered from DGMTSC* routines. This was done in order to include Means Test
data for PDX. All DG variables are newed. The alterations mainly consist of
changing writes to sets. The PDX routines are based on the following
routines:
a) HD^DGMTSCU
b) DIS^DGMTSC1
c) CHILD^DGMTSC11
d) DIS^DGMTSC2
e) FLD^DGMTSC2
f) DIS^DGMTSC3
g) CHILD^DGMTSC31
h) DIS^GDMTSC4
i) FLD^DGMTSC4\n
Within these routines the following entry points are accessed:
a) $$LST^DGMTU
b) SETUP^DGMTSCU
c) $$LYR^DGMTSCU1
d) ALL^DGMTU21
e) $$YN^DGMTSCU1
f) $$AMT^DGMTSCU1
g) $$NAME^DGMTU1
h) $$SSN^DGMTU1
i) $$DOB^DGMTU1
j) CHILD^DGMTSC11
k) DIS^DGMTSC2
l) DEP^DGMTSCU2
m) INC^DGMTSCU3
n) FLD^DGMTSC2
o) DIS^DGMTSCSC3
p) SET^DGMTSC31
q) CHILD^DGNTSC4
r) DIS^DGMTSC4
s) FLD^DGMTSC4", "", "SEE DESCRIPTION", ""], ["769", "DBIA268-E", "Routine", "REGISTRATION", "1993/08/25", "", "Retired", "Private", "", "
The PDX development team request permission to use the
$$SITE^VASITE entry point in determining site.", "", "VASITE", ""], ["770", "DBIA270-B", "File", "PHARMACY DATA MANAGEMENT", "1993/08/26", "APPROVED", "Active", "Private", "52.7", "
Drug Accountability will use the IV STATS (#50.8) file
to update IV dispensing activity in a Drug Accountability Location. To
correctly identify the DRUG (#50) file entry a look up is first made to the IV
ADDITIVES (#52.6) and/or the IV SOLUTION (#52.7) files. Looping through
^PS(50.8,D0), all IV Rooms are checked. Looping through ^PS(50.8,D0,2,D1),
dates are checked. Looping through ^PS(50.8,D0,2,D1,2,D2), drugs are checked
with support from the "AC" x-ref. Looping through
^PS(50.8,D0,2,D1,2,D2,3,D3), ward is checked. It is here that, if a match
occurs, $P($G(^PS(50.8,D0,2,D1,2,D2,3,D3,0)),U,2)-$P($G(^(0)),U,5) is used to
update the balance in Drug Accountability.\n
GLOBAL MAP DATA DICTIONARY #52.7 -- IV SOLUTIONS FILE STORED IN ^PS(52.7, ***
NO DATA STORED YET *** SITE: BIRMINGHAM ISC
------------------------------------------------------------------------
CROSS REFERENCED BY: GENERIC DRUG(AC) ^PS(52.7,D0,0)= (#1) GENERIC DRUG [2P]", "", "", ""], ["771", "DBIA271-C", "File", "INPATIENT MEDICATIONS", "1993/08/26", "APPROVED", "Active", "Private", "50.8", "
Drug Accountability will use the IV STATS (#50.8) file
to update IV dispensing activity in a Drug Accountability Location. To
correctly identify the DRUG (#50) file entry a look up is first made to the IV
ADDITIVES (#52.6) and/or the IV SOLUTION (#52.7) files. Looping through
^PS(50.8,D0), all IV Rooms are checked. Looping through ^PS(50.8,D0,2,D1),
dates are checked. Looping through ^PS(50.8,D0,2,D1,2,D2), drugs are checked
with support from the "AC" x-ref. Looping through
^PS(50.8,D0,2,D1,2,D2,3,D3), ward is checked. It is here that, if a match
occurs, $P($G(^PS(50.8,D0,2,D1,2,D2,3,D3,0)),U,2)-$P($G(^(0)),U,5) is used to
update the balance in Drug Accountability.\n
GLOBAL MAP DATA DICTIONARY #50.8 -- IV STATS FILE STORED IN ^PS(50.8, (1
ENTRY) SITE: BIRMINGHAM ISC (#14)
--------------------------------------------------------------------------\n
CROSS REFERENCED BY: IV DRUG(AC) ^PS(50.8,D0,0)= (#.01) IV ROOM [1P] ^
^PS(50.8,D0,2,0)=^50.803D^^ (#2) DATE ^PS(50.8,D0,2,D1,0)= (#.01) DATE [1D] ^
^PS(50.8,D0,2,D1,2,0)=^50.805A^^ (#2) IV DRUG ^PS(50.8,D0,2,D1,2,D2,0)=
(#.01) IV DRUG [1F]\n
CROSS-REFERENCE: 50.8^AC^MUMPS
1)= I '$D(PSIVV),$D(^PS(50.8)) D ^PSIVXREF Q
2)= Q\n
^PS(50.8,D0,2,D1,2,D2,3,0)=^50.808P^^ (#10) WARD
^PS(50.8,D0,2,D1,2,D2,3,D3,0)= (#.01) WARD [1P] ^ (#2) DISPENSED UNITS
==>(WARD) [2N] ^ (#5) CANCELED UNITS [5N] ^", "", "", ""], ["772", "DBIA271-D", "File", "INPATIENT MEDICATIONS", "1993/08/26", "APPROVED", "Active", "Private", "57.6", "
Drug Accountability will use the UNIT DOSE PICK LIST
STATS (#57.6) file to update UD dispensing activity in a Drug Accountability
Location. Looping through ^PS(57.6,D0), each date since the last update is
checked. Looping through ^PS(57.6,D0,1,D1), wards are checked. Looping
through ^PS(57.6,D0,1,D1,1,D2), providers are checked. Looping through
^PS(57.6,D0,1,D1,1,D2,1,D3), drugs checked. It is here that, if a match
occurs, $P($G(^PS(57.6,D0,1,D1,1,D2,1,D3,0)),U,2)-$P($G(^(0)),U,4) is used to
update the balance in Drug Accountability.\n
GLOBAL MAP DATA DICTIONARY #57.6 -- UNIT DOSE PICK LIST STATS FILE STORED IN
^PS(57.6,
------------------------------------------------------------------
Contains medication amounts and costs for the Unit Dose package. Data is
entered into this file when pick lists are filed away, and when pre- exchange
units, extra units dispensed, and returns are entered through the package.
Most of the cost reports gather their data from this file.\n
^PS(57.6,D0,0)= (#.01) DATE [1D] ^ ^PS(57.6,D0,1,0)=^57.61PA^^ (#1) WARD
^PS(57.6,D0,1,D1,0)= (#.01) WARD [1P] ^ ^PS(57.6,D0,1,D1,1,0)=^57.62PA^^ (#1)
PROVIDER ^PS(57.6,D0,1,D1,1,D2,0)= (#.01) PROVIDER [1P] ^
^PS(57.6,D0,1,D1,1,D2,1,0)=^57.63PA^^ (#1) DRUG
^PS(57.6,D0,1,D1,1,D2,1,D3,0)=(#.01) DRUG [1P] ^ (#1) DISPENSED AMOUNT [2N]
==>^ (#2) DISPENSED COST [3N] ^ (#3) RETURNED
==>AMOUNT [4N] ^ (#4) RETURNED COST [5N] ^", "", "", ""], ["773", "DBIA271-B", "Routine", "INTEGRATED BILLING", "1993/08/27", "APPROVED", "Active", "Private", "", "
IBAPDX - Extraction means test billing data for PDX
Entry: $$EXTR^IBAPDX(TRAN,DFN,ROOT)
Input: TRAN -- pointer to transaction file 394.61
DFN -- pointer to patient file 2
ROOT -- root for the output extraction array
Output: 0 -- extraction was successful, or
-1^err -- if an error was encountered during extraction", "", "IBAPDX", ""], ["774", "DBIA271-C", "Routine", "INTEGRATED BILLING", "1993/08/27", "APPROVED", "Active", "Private", "", "
IBAPDX1 - Build display set for extracted PDX billing
data
Entry: $$DISP^IBAPDX(XTRACT,ROOT,SEGPTR,OFFSET)
Input: XTRACT -- root for the input extract array
ROOT -- root for the output display array
SEGPTR -- pointer to extracted segment in file 394.71
OFFSET -- offset to begin line numbering
Output: NUM -- number of lines in the output display
array, or
-1^ERR -- if an error was encountered", "", "IBAPDX", ""], ["775", "DBIA272-B", "File", "PATIENT DATA EXCHANGE", "1993/08/27", "APPROVED", "Active", "Private", "394.71", "\n
a) The following fields are referenced by the global directly, NOT
by a fileman call.
- PDX Segment File (394,71) field # .01 Data Segment Name", "", "", ""], ["776", "DBIA272-C", "Routine", "PATIENT DATA EXCHANGE", "1993/08/27", "APPROVED", "Active", "Private", "", "", "", "VAQULT3", ""], ["777", "DBIA272-D", "Routine", "PATIENT DATA EXCHANGE", "1993/08/27", "APPROVED", "Active", "Private", "", "", "", "VAQUTL2", ""], ["778", "DBIA272-E", "Routine", "PATIENT DATA EXCHANGE", "1993/08/27", "APPROVED", "Active", "Private", "", "", "", "VAQCON2", ""], ["779", "DBIA272-F", "Routine", "PATIENT DATA EXCHANGE", "1993/08/27", "APPROVED", "Active", "Private", "", "", "", "VAQDIS20", ""], ["780", "DBIA273-B", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
#52 PRESCRIPTION FILE ^PSRX(\n
52,.01 RX # 0;1 FREE TEXT
(Required) 52,4 PHYSICIAN
0;4 POINTER TO PROVIDER
FILE (#6) 52,6 DRUG
0;6 POINTER TO DRUG
FILE (#50)
(Required) 52,20 DIVISION
2;9 POINTER TO PHARMACY
SITE FILE (#59) 52,301
CLOZAPINE DOSAGE (MG/DAY) SAND;1 NUMBER 52,302 WBC RESULTS
SAND;2 NUMBER 52,303 DATE OF WBC TEST SAND;3 DATE\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["781", "DBIA273-C", "File", "PHARMACY DATA MANAGEMENT", "1993/08/30", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
#55 PHARMACY PATIENT FILE ^PS(55\n
55,53 CLOZAPINE REGISTRATION NUMBER SAND;1 FREE TEXT 55,54
CLOZAPINE STATUS SAND;2 SET 55,55 DATE OF LAST CLOZAPINE RX
SAND;3 DATE 55,56 DEMOGRAPHICS SENT SAND;4 SET 55,57
RESPONSIBLE PHYSICIAN SAND;5 POINTER TO
PROVIDER FILE
(#6) 55,58 REGISTRATION
DATE SAND;6 DATE", "", "", ""], ["782", "DBIA273-D", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52.52", "
#52.52 CLOZAPINE PRESCRIPTION OVERRIDES FILE
^PS(52.52\n
Entire File\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["783", "DBIA273-E", "File", "OUTPATIENT PHARMACY", "1993/08/30", "", "Retired", "Private", "59", "
This agreement will be retired on 12/31/2006. Please do
not add any
additional code that utilizes this Integration Agreement. APIs have been
created that can be used in place of any code needing to make use of this
agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code
that currently utilizes this Integration Agreement must be converted to
use the new API's. If any part of this Integration Agreement cannot be
satisfied with the APIs, please contact the PRE development team mail
group at EMAIL GROUP DEV using Microsoft Outlook.\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy
packages are still allowed to utilize this agreement past the expiration
date of December 31, 2006. #59 -- PHARMACY SITE FILE ^PS(59\n
59,1 SITE DEA NUMBER SAND;1 FREE TEXT 59,2 SITE
(NATIONAL NAME) SAND;2 POINTER TO QUIC
SORT DATA FILE
(#736)", "", "", ""], ["784", "DBIA275-B", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1993/09/09", "", "Retired", "Private", "", "
Purpose:\n
Request an integration agreement between the Discharge Summary Team and the
OE/RR Team at the Salt Lake ISC for Discharge Summary version 1.0: 1. to
access protocol descriptions by direct reference to the ^ORD(101, and 2.
permission to call ^XQORM as described below.\n
Description: To allow the user to get a detailed description of the actions
that are executable from each of our menu-type protocols, we need to be able
to $ORDER through the subscript ^ORD(101,DO,10,D1,0) to get sub-fields #1
(ITEM) and # 3 (SEQUENCE) of the 101.01 multiple for each ITEM. Then get
field #1 (ITEM TEXT) and #3.5 (DESCRIPTION) for each PROTOCOL encountered in
the ITEM MULTIPLE for a given menu. To allow the user to retrieve Discharge
Summaries into the review screen based on Signature Status and Search Category
(e.g., by PATIENT, PROVIDER, or TREATING SPECIALTY), we need to be able to
execute a DIC call on file 101 to retrieve the zero node of a record and to
reference field # 24 (SCREEN) in order to set up the local variables to be
used to execute the ^XQORM call.", "", "XQORM", ""], ["785", "DBIA276-B", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
This agreement will be retired on 12/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSO*7*213. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["786", "DBIA785-C", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "52.5", "
This agreement will be retired on 12/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSO*7*213. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["787", "DBIA786-D", "File", "PHARMACY DATA MANAGEMENT", "1993/09/09", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006\n
File #55 - Pharmacy Patient
Field #52 - Prescription Profile - ^PS(55,D0,P,0)=^55.03^^
Field #.01 - Prescription Profile - ^PS(55,D0,P,D1,0) 1
Pointer to the Prescription file #52\n", "", "", ""], ["788", "DBIA277-B", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "22", "\n
File #22 - POW Period
Field #.01 - Name - ^DIC(22,D0,0) piece 1", "", "", ""], ["789", "DBIA277-C", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "23", "\n
File #23 - Branch of Service
Field #.01 - Name - ^DIC(23,D0,0) piece 1", "", "", ""], ["790", "DBIA277-D", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "24", "\n
File #24 - Non-Veterans Class
Field #.01 - Name - ^DIC(24,D0,0) piece 1", "", "", ""], ["791", "DBIA277-E", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "25", "\n
File #25 - Type of Discharge
Field #.01 - Name - ^DIC(25,D0,0) piece 1", "", "", ""], ["792", "DBIA277-F", "File", "SCHEDULING", "1993/09/13", "APPROVED", "Active", "Controlled Subscription", "31", "\n
File #31 - Disability Condition
Field #.01 - Name - ^DIC(31,D0,0) piece 1", "", "", ""], ["793", "DBIA277-G", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "35", "\n
File #35 - Other Federal Agency
Field #.01 - Name - ^DIC(35,D0,0) piece 1", "", "", ""], ["794", "DBIA277-H", "File", "INTEGRATED BILLING", "1993/09/13", "APPROVED", "Active", "Controlled Subscription", "36", "", "", "", ""], ["795", "DBIA277-I", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "42.4", "\n
File #42.4 - Specialty
Field #.01 - Name - ^DIC(42.4,D0,0) piece 1", "", "", ""], ["796", "DBIA277-J", "File", "REGISTRATION", "1993/09/13", "APPROVED", "Active", "Private", "45.7", "\n
File #45.7 - Treating Specialty
Field #.01 - Name - ^DIC(45.7,D0,0) piece 1", "", "", ""], ["797", "DBIA282-B", "Routine", "IFCAP", "1993/09/20", "APPROVED", "Active", "Private", "", "", "", "PRCS58", ""], ["798", "DBIA282-C", "Routine", "IFCAP", "1993/09/20", "APPROVED", "Active", "Private", "", "", "", "PRCS58CC", ""], ["799", "DBIA282-D", "File", "IFCAP", "1993/09/20", "APPROVED", "Active", "Controlled Subscription", "420.5", "
Read access to file 420.5 (Unit of Issue)", "", "", ""], ["800", "DBIA282-E", "File", "IFCAP", "1993/09/20", "APPROVED", "Active", "Controlled Subscription", "440", "
Prosthetics to have Read, Write, and LAYGO access to
files 440 (vendor) and 441 (Item Master), through options PRCHPC ITEM EDIT and
PRCHRC VEN EDIT, restricted through assignment of the RMPRSUPERVISOR key.
This key will be issued to a prosthetics clerk who has completed training by
Supply Service on the IFCAP conventions and procedures for entering data into
the above named files.\n
Read access to file 440 VENDOR FILE - Field #.01 NAME and Field #6 CONTRACT
NUMBER MULTIPLE, global node ^PRC(440,D0,4) and Global Node
^PRC(440,D0,4,D1,0). Display Vendor Name and check for valid or expired
contract number.", "", "", ""], ["801", "DBIA282-F", "File", "IFCAP", "1993/09/20", "APPROVED", "Active", "Controlled Subscription", "441", "
Prosthetics to have Read, Write, and LAYGO access to
files 440 (vendor) and 441 (Item Master), through options PRCHPC ITEM EDIT and
PRCHRC VEN EDIT, restricted through assignment of the RMPRSUPERVISOR key.
This key will be issued to a prosthetics clerk who has completed training by
Supply Service on the IFCAP conventions and procedures for entering data into
the above named files.\n
Read access to file 441 IFCAP ITEM MASTER FILE Field #.05 SHORT DESCRIPTION,
global node ^PRC(441,D0,0) and Index ^PRC(441,"C",X,DA). Display IFCAP ITEM
MASTER Short Description.", "", "", ""], ["802", "DBIA282-G", "File", "IFCAP", "1993/09/20", "APPROVED", "Active", "Controlled Subscription", "410", "
Read access to file 410 (Control Point Activity) -
Access required to check the status of 2237's.", "", "", ""], ["803", "DBIA282-H", "File", "IFCAP", "1993/09/20", "APPROVED", "Active", "Private", "442", "
Read access to file 442 PROCUREMENT & ACCOUNTING
TRANSACTION To get Obligation number through a ^DIC lookup. Obligation # is
returned in Y(0).\n", "", "", ""], ["804", "DBIA285-B", "File", "IFCAP", "1993/10/05", "APPROVED", "Active", "Private", "423", "
CALM/LOG Code Sheet File (#423) of IFCAP sets and/or
references to the entire file are under this agreement.\n
Access to the CALM/LOG Code Sheet File 423 and the Procurement & Accounting
Transaction File 442 is needed to repoint AR Debtor File 412 pointers to the
AR V4.0 AR Debtor File 340. (included in inits)", "", "", ""], ["805", "DBIA285-C", "File", "IFCAP", "1993/10/05", "APPROVED", "Active", "Private", "440", "
AR Debtor File 340
Debtor Field .01V5 (0;1) - variable pointer to the Vendor File (#440)", "", "", ""], ["806", "DBIA285-D", "File", "IFCAP", "1993/10/05", "APPROVED", "Active", "Private", "442", "
AR File 430
Fiscal Year sub-file 430.01, Pat Ref. No. Field 430.01,2 (0;3) -
points to Procurement & Accounting Transaction File (#442)", "", "", ""], ["807", "DBIA285-E", "Routine", "IFCAP", "1993/10/05", "APPROVED", "Active", "Private", "", "
Appropriation Symbol Field 430.01,3 (0;4) - input
transform
calls EN1^PRCHPAT", "", "PRCHPAT", ""], ["808", "DBIA285-F", "File", "IFCAP", "1993/10/05", "APPROVED", "Active", "Private", "420.3", "\n
Ald Code Field 430.01,4 (0;5) - points to the Ald Code File (#420.3)
Ald Code Field 4 (0;5) - points to the Ald Code File (#420.3)\n", "", "", ""], ["809", "DBIA285-G", "File", "IFCAP", "1993/10/05", "APPROVED", "Active", "Private", "420.5", "
Unit Field 430.02,5 (0;5) - points to the Unit of Issue
File (#420.5)", "", "", ""], ["810", "DBIA285-H", "File", "IFCAP", "1993/10/05", "APPROVED", "Active", "Private", "411", "
The AR V4.0 PRCACV* Conversion routines call to IFCAP.\n
Access to the Admin. Activity Site Parameter File, #411, is needed to populate
the AR V4.0 AR Site Parameter File 342. Admin. Activity Site Parameter File
411 Station Number Filed .01 (0;1) - Global reference Primary Station Field 21
(0;2) - "AC" Cross-reference global reference Admin. Activity Site
Parameter File 411, Printer Location sub-file 411.02 Printer Location Field
411.02,.01 (0;1) - Global references UB for UB-82 and A for Accounts
Receivable\n
Device Field 411.02,1 (0;2) - Global reference", "", "", ""], ["811", "DBIA288-B", "Routine", "DISCHARGE SUMMARY", "1993/10/05", "", "Retired", "Private", "", "
Discharge Summary hereby grants permission for Health
Summary to call into the routine MAIN^GMRDXTRT with the formal parameters DFN,
TIME1 (inverted late dictation date/time), TIME2 (inverted early dictation
date/time), OCCLIM (occurrence limit), and TEXT (a boolean flag indicating
whether or not to include the textual report). This entry point is called by
both GMTSDS and GMTSDSB to extract the information appropriately, and will be
supported by Discharge Summary as described here until otherwise agreed.\n
In fact, rather than creating a GMRD namespaced option to call the ad hoc
Health Summary, we're letting DIFROM attach the GMTS HS ADHOC option to the
GMRD DICTATION HELP MENU option. The return array for Discharge Summary's
extract routine, GMRDXTRT, will look like this:\n
^TMP("GMRD",$J,INVERSE DICT DATE,COUNT)=ADM DATE^DISCH DATE
^DICTATING PHYS^ATTENDING PHYS^TREATING SPECIALTY
^SIGNATURE STATUS^COSIGNATURE DATE/TIME ^TMP("GMRD",$J,INVERSE
DICT DATE,COUNT,"TEXT",LINE,0)=EACH LINE OF THE REPORT TEXT\n
This structure for the return array will be maintained indefinitely, until
otherwise agreed.\n\n", "", "GMRDXTRT", ""], ["812", "DBIA290-B", "File", "KERNEL", "1993/10/12", "APPROVED", "Active", "Private", "3.2", "\n
=============================================================
Unauthorized Claim Printer, field 33 in file 161.4 (Fee Basis Site Parameters
file) references the device (%ZIS(1) and terminal type (%ZIS(2) files in the
Input transform (extrinsic function), Executable help (routine call) and
Screen. Fee routine is FBUCDD1.\n
The Screen is: S DIC("S")= "S
Z=$G(^%ZIS(1,+Y,""SUBTYPE"")),Z=$G(^%ZIS(2,Z,0)) I $E($P(Z,U),1)=""P""K Z"\n
This IA grants the subscribing packages direct global read of\n
%ZIS(1,"B" %ZIS(1,IEN,0 %ZIS(1,IEN,1 %ZIS(1,IEN,90 %ZIS(1,IEN,91 %ZIS(1,IEN,95
%ZIS(1,IEN,SUBTYPE %ZIS(1,IEN,TIME %ZIS(1,IEN,TYPE %ZIS(2,IEN,0", "", "", ""], ["813", "DBIA297-B", "File", "HEALTH SUMMARY", "1993/10/25", "APPROVED", "Active", "Private", "142", "
The PDX application is granted read access to the
following fields and, if listed, their associated cross references:\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
142 .01 0;1 NAME B
1 (multiple in STRUCTURE
file 142.01)\n\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
142.01 .01 0;1 SUMMARY ORDER B
.02 0;2 COMPONENT NAME C
2 0;3 OCCURRENCE LIMIT
3 0;4 TIME LIMIT", "", "", ""], ["814", "DBIA297-C", "File", "HEALTH SUMMARY", "1993/10/25", "APPROVED", "Active", "Private", "142.1", "\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
142.1 .01 0;1 NAME B
3 0;4 ABBREVIATION C
2 0;3 TIME LIMITS APPLICABLE
4 0;5 MAXIMUM OCCURRENCES APPLICABLE", "", "", ""], ["815", "DBIA297-D", "Routine", "HEALTH SUMMARY", "1993/10/25", "APPROVED", "Active", "Private", "", "
The PDX application is granted permission to use the
function call $$GET^GMTSPDX(TRAN,DFN,SEGPTR,ROOT,GMTSLCNT,GMTSDLM,GMTSNDM) in
order to extrqct Health Summary Components. Input:
TRAN - Pointer to the VAQ - TRANSACTION file. If passed, the
patient referenced in the transaction will be used when
extracting the Health Summary Component.
DFN - Pointer to the PATIENT file. If TRAN is not passed, the
patient referenced by this pointer will be used when
extracting the Health Summary Component.
SEGPTR - Pointer to the VAQ - DATA SEGMENT file. This is the
PDX Data Segment being extracted.
ROOT - Root for the output extraction array (full global reference)
GMTSLCNT - Offset in ROOT to begin placing information into
(defaults to 0)
GMTSDLM - Time limit to use for extraction (if applicable)
GMTSNDM - Occurrence limit to use for extraction (if applicable) Output:
A^B - Health Summary Component successfully extracted.
A - Total number of lines inserted into ROOT
B - Last line number inserted into ROOT
-1^Err - Error occurred while extracting Health Summary Component.
Err - Printable error text (reason for failure) Notes:
a) Currently, output begins with GMTSLCNT+1
b) If TRAN is passed
The patient pointer of the transaction will be used
Encryption will be based on the transaction
If DFN is passed
Encryption will be based on the site parameter
c) Use of TRAN takes precedence over DFN. If TRAN>0 the extraction
will be based on the patient contained in the transaction.", "", "GMTSPDX", ""], ["816", "HEALTH SUMMARY COMPONENTS FOR PDX", "Other", "HEALTH SUMMARY", "1993/10/25", "APPROVED", "Active", "Private", "", "
The PDX application is granted permission to extract
the following Health Summary Components using the function documented in
integration agreement #815:\n
Health Summary Component Abbreviation
--------------------------- ------------
ADVERSE REACTIONS/ALLERGIES ADR
CLINICAL WARNINGS CW
CRISIS NOTES CN
DIETETICS DI
EKG EKG
LAB BLOOD AVAILABILITY BA
LAB BLOOD TRANSFUSIONS BT
LAB CHEMISTRY & HEMATOLOGY CH
LAB CUMULATIVE SELECTED SCLU
LAB CUMULATIVE SELECTED 1 SCL1
LAB CUMULATIVE SELECTED 2 SCL2
LAB CUMULATIVE SELECTED 3 SCL3
LAB CUMULATIVE SELECTED 4 SCL4
LAB CYTOPATHOLOGY CY
LAB MICROBIOLOGY MIC
LAB MICROBIOLOGY BRIEF BMIC
LAB ORDERS LO
LAB ORDERS BRIEF BLO
LAB SURGICAL PATHOLOGY SP
LAB TESTS SELECTED SLT
MAS ADMISSIONS/DISCHARGES ADC
MAS ADT HISTORY ADT
MAS CLINIC VISITS FUTURE CVF
MAS CONTACTS CON
MAS CLINIC VISITS PAST CVP
MAS DEMOGRAPHICS DEM
MAS DEMOGRAPHICS BRIEF BDEM
MAS DEMOGRAPHICS OTHER CDEM
MAS DISABILITIES DS
MAS DISCHARGE DIAGNOSIS DD
MAS DISCHARGES DC
MAS MH CLINIC VISITS FUTURE MHFV
MAS PROCEDURES ICD CODES PRC
MAS SURGERIES ICD CODES OPC
MAS TRANSFERS TR
MAS TREATING SPECIALTY TS
MEDICINE SUMMARY MED
MEDS BY DRUG CLASS RXDC
MEDS BY RX ORD ITEM RXOI
MH HIGH RISK PRF HX MHRF
MH TREATMENT COORDINATOR MHTC
ORDERS CURRENT ORC
ORDERS PENDING ORP
PCE IMMUNIZATIONS IM
PCE IMMUNIZATIONS DETAILED DIM
PHARMACY (OP BY DRUG CLASS) RXDC
PHARMACY (OP BY RX ORD ITEM) RXOI
PHARMACY INTRAVENOUS RXIV
PHARMACY OUTPATIENT RXOP
PHARMACY UNIT DOSE RXUD
PROGRESS NOTES PN
PROGRESS NOTES BRIEF BPN
PROGRESS NOTES SELECTED TITLE SPNT
RADIOLOGY IMPRESSION RI
RADIOLOGY PROFILE RP
RADIOLOGY STATUS RS
SURGERY ONLY REPORTS SRO
SURGERY NON OR PROCEDURES NSR
SURGERY REPORTS SR
SURGERY REPORTS BRIEF BSR
SURGERY SEL NON OR PROCEDURES SNSR
VITAL SIGNS VS
VITAL SIGNS SELECTED SVS
WH PREGNANCY DOCUMENTATION WHP
WH LACTATION DOCUMENTATION WHL
WH PREGNANCY & LACTATION DOC WHPL\n
Amended 5/13/2022: Added MAS DEMOGRAPHICS OTHER for sexual orientation.", "", "", "2015/06/12"], ["817", "DBIA298-B", "Routine", "PATIENT DATA EXCHANGE", "1993/10/25", "APPROVED", "Active", "Private", "", "
The Health Summary application is granted permission to
use the function call $$TRANENC^VAQUTL3(TRAN,0) in order to determine if
encryption for a PDX Transaction has been turned on. Input:
TRAN - Pointer to the VAQ - TRANSACTION file
0 - Input of 0 as second parameter will only be supported Output:
0 - Encryption for the transaction has been turned off
1 - Encryption for the transaction has been turned on Notes:
a) Existence of VAQIGNC will be checked. If it exists and is
set to 1 encryption will be ignored for this transaction.
b) If encryption is on and the transaction does not include
an encryption method, the default encryption method will
be used.
c) Encryption off will be returned on error.", "", "VAQUTL3", ""], ["818", "DBIA298-C", "Routine", "PATIENT DATA EXCHANGE", "1993/10/25", "APPROVED", "Active", "Private", "", "
The Health Summary application is granted permission to
use the function call $$NCRYPTON^VAQUTL2(0) in order to determine the default
encryption method for a facility. Input:
0 - Input of 0 (the default value) will only be supported Output:
0 - Encryption has been turned off at the facility
X - Pointer to VAQ - ENCRYPTION METHOD file (#394.72) Notes:
a) Existence of VAQIGNC will be checked. If it exists and is
set to 1 encryption will be ignored.
b) Encryption off will be returned on error.", "", "VAQUTL2", ""], ["819", "DBIA298-D", "Routine", "PATIENT DATA EXCHANGE", "1993/10/25", "APPROVED", "Active", "Private", "", "
The Health Summary application is granted permission to
use the function call $$ENCDSP^VAQHSH(TRAN,ROOT,ENCPTR,DSPOFF,DSPCNT) in order
to encrypt a Health Summary component that has been extracted in display ready
format. Input:
TRAN - Pointer to VAQ - TRANSACTION file
ROOT - Where the Display Array is (full global reference)
ENCPTR - Pointer to VAQ - ENCRYPTION METHOD file
DSPOFF - Offset into Display Array to begin at (defaults to 0)
DSPCNT - Number of lines in Display Array (defaults to all lines) Output:
0 - Success
-1^Text - Error Notes:
a) If TRAN>0
Encryption will be based on the transaction
Encryption keys will be based on the transaction
Else
Encryption will be based on ENCPTR
Encryption keys based on current user
b) Existence of TRAN takes precedence over ENCPTR", "", "VAQHSH", ""], ["820", "DBIA298-E", "File", "PATIENT DATA EXCHANGE", "1993/10/25", "APPROVED", "Active", "Private", "394.71", "
The Health Summary application is granted read access
to the following fields and, if listed, their associated cross references:\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
394.71 .01 0;1 Data Segment Name B
.04 0;4 Health Summary Component\n", "", "", ""], ["821", "DBIA299-B", "File", "1", "1993/10/25", "APPROVED", "Active", "Private", "", "
The PDX (V 1.5) application is granted read access to
the DD and DIC globals to accomplish the following tasks:\n
1) Get global location for a file
^DIC(FILE,0,"GL")", "", "", ""], ["822", "DBIA302-B", "File", "NATIONAL DRUG FILE", "1993/10/25", "", "Retired", "Private", "50.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
The PDX application is granted read access to the following fields and, if
listed, their associated cross references:\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
50.6 .01 0;1 VA GENERIC NAME B", "", "", ""], ["823", "DBIA302-C", "File", "PHARMACY DATA MANAGEMENT", "1993/10/25", "APPROVED", "Active", "Private", "51", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
51 .01 0;1 NAME B,A
.5 0;3 SYNONYM AD
1 0;2 EXPANSION 0 AB
9 9;1 PLURAL AC", "", "", ""], ["824", "DBIA302-D", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
52 .01 0;1 RX # B
1 0;13 ISSUE DATE
4 0;4 PROVIDER
6 0;6 DRUG << see note (i) >>
7 0;7 QTY
8 0;8 DAYS SUPPLY
9 0;9 # OF REFILLS
10 0;10 SIG << see note (ii) >>
12 3;7 REMARKS
16 0;16 CLERK CODE
20 2;9 DIVISION
22 2;2 FILL DATE
26 2;6 EXPIRATION DATE
52 (multiple in REFILL B
file 52.1)
100 0;15 STATUS << see note (iii) >>
101 3;1 LAST DISPENSED DATE << see note (iv) >>\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
52.1 .01 0;1 REFILL DATE B\n
Notes:
(i) Points to the DRUG file (#50), not the NATIONAL DRUG
file (#50.6). This could give incorrect drug name if pointer
is in the NATIONAL DRUG file.
(ii) This is parsed by spaces within the free text. If an entry
is not found in the MEDICATION INSTRUCTION file (#51), the
& free text is used.
(iii) This is calculated using the module STAT^PSOEXDT
(iv) This will always be the last fill, not just last refill\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["825", "DBIA302-E", "File", "PHARMACY DATA MANAGEMENT", "1993/10/25", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
55 .01 0;1 NAME B
1 1;1 NARRATIVE
52 (multiple in PRESCRIPTION PROFILE
file 55.03)\n
File Field Node;Piece Description (Field name) X-Refs
----- ----- ---------- ------------------------------ ------
55.03 .01 0;1 PRESCRIPTION PROFILE B,A", "", "", ""], ["826", "DBIA303-B", "File", "LAB SERVICE", "2005/06/20", "", "Retired", "Private", "61", "
QUIC is granted an integration agreement with
Laboratory to obtain the rate of completion of at least one Glycosalated
Hemoglobin measurement within one year for diabetic patients on a medication
regimen. The lab files/fields used in the QIP3* routines are:\n\n
GLOBAL MAP DATA DICTIONARY #61 -- TOPOGRAPHY FIELD FILE TORED IN ^LAB(61,
SITE: ISC BIRMINGHAM
-------------------------------------------------------------------------
^LAB(61,D0,0)= (#.01) NAME [1F] ^\n", "", "", ""], ["827", "DBIA303-C", "File", "LAB SERVICE", "2005/06/20", "", "Retired", "Private", "63", "
QUIC is granted an integration agreement with
Laboratory to obtain the rate of completion of at least one Glycosalated
Hemoglobin measurement within one year for diabetic patients on a medication
regimen. The lab files/fields used in the QIP3* routines are:\n
GLOBAL MAP DATA DICTIONARY #63 -- LAB DATA FIELD STORED IN ^LR(
SITE: ISC BIRMINGHAM
--------------------------------------------------------------------------
^LR(D0,CH,D1,0)= (#.01) DATE/TIME SPECIMEN TAKEN [1D] ^^ (#.03) DATE
REPORT COMPLETED [3D] ^^ (#.05) SPECIMEN TYPE [5P] ^
^LR(D0,CH,D1,data name#)= (#data name) results of patient's Glycosalated
Hemoglobin test ^\n", "", "", ""], ["828", "DBIA311-B", "File", "REGISTRATION", "1993/11/01", "APPROVED", "Active", "Private", "42", "
The Discharge Summary package has permission to access
the Patient Information Management System package in the following ways:\n
3. When printing VA Form 10-1000 Discharge Summary uses the externally
formatted name of the Division from which the patient was discharged, as found
in field .015 of the Ward Location File (#42). The division is obtained by a
call to EN^DIQ1 with DIC=42, DR=.015, and DA = WARD LOCATION record # returned
from the IN5^VADPT call.", "", "", ""], ["829", "DBIA311-C", "File", "REGISTRATION", "1993/11/01", "APPROVED", "Active", "Controlled Subscription", "40.8", "", "", "", ""], ["830", "DBIA314-B", "File", "1", "1993/11/01", "APPROVED", "Active", "Private", "", "
To support the table-driven upload of transcribed text
to various DHCP files, the Discharge Summary application has permission to
access the Data Dictionary and File of Files in the following ways:\n
1. In order to allow the site to specify the target file, fixed-field header
elements, and word-processing field for each report type, Discharge Summary
version 1 will make several references to either the File of Files or ^DD(.
These are ONLY done in setting up a ^DIC call (to look-up a given field in the
target file), or in screening logic (e.g., to exclude the programmer at the
site from choosing a non-Word-Processing field in the target file as the
destination for the body of a report). Needless to say, NO SETs or KILLs are
ever executed on any of FileMan's supporting data structures (i.e., ^DD( or
^DIC(). All hard-coded references to ^DIC( or ^DD( are made from within the
following code:\n
GMRDUPAR ; SLC/JER - Upload Parameter Edit ;4/23/93 14:53
;;1.0V2;Discharge Summary;;Sep 02, 1993 MAIN ; Controls branching
N DIC,DA,DIE,DLAYGO,DR,GMRDPRM0,GMRDPRM1,GMRDPRM3,GMRDUSRC,GMRD1ST,X,Y
D:'$D(GMRDPRM0) SETPARM^GMRDLIBE
W !,"First edit Division-wide upload parameters:",!
S (DIC,DLAYGO)=128.99,DIC(0)="AEMQL",DIC("A")="Select DIVISION: "
D ^DIC K DLAYGO Q:+Y'>0 S DA=+Y
S DIE=128.99,DR="[GMRD UPLOAD PARAMETER EDIT]"
D ^DIE
D SETPARM^GMRDLIBE
W !!,"Now edit the REPORT TYPE file:",!
F D Q:+$G(Y)'>0
. N GMRDREP,GMRDX
. S DIC="^GMR(128.1,",DIC(0)="AEMQZ",DIC("A")="Select REPORT TYPE: "
. I $D(^DISV(DUZ,DIC)),'$D(GMRD1ST) S DIC("B")=$G(^DISV(DUZ,DIC)),
GMRD1ST=1
. D ^DIC K DIC Q:+Y'>0 S DA=+Y,GMRDREP=Y,GMRDREP(0)=Y(0)
. S DIE=128.1,DR="[GMRD UPLOAD PARAMETER EDIT]"
. D ^DIE S Y=1
. I $D(^GMR(128.1,+DA,"HEAD"))>9!($D(^GMR(128.1,+DA,"ITEM"))>9) D
. . W !!,"The header for the ",$P(GMRDREP,U,2)," Report type is now
defined as:"
. . I $P(GMRDPRM0,U,16)="D" D DHDR^GMRDTHLP(.GMRDREP,GMRDPRM0,GMRDPRM1)
. . I $P(GMRDPRM0,U,16)="C" D CHDR^GMRDTHLP(.GMRDREP,GMRDPRM0,GMRDPRM1)
. . W !
Q TXTFLD(TFILE,GMRDFLT) ; Get Text Field # from ^DD(Target file #,
N DIC,X,Y
S DIC="^DD("_TFILE_",",DIC(0)="AEMQZ",DIC("A")="Select TARGET TEXT FIELD
: "
S DIC("S")="I +$$ISWP^GMRDUPAR(TFILE,+Y)"
I $D(GMRDFLT) S DIC("B")=GMRDFLT
D ^DIC G:+Y'>0 TXTFLDX
S Y=+Y_";"_$P($P(Y(0),U,4),";") TXTFLDX Q Y ISWP(TFILE,TFLD) ; Is a
given field a Word-processing type field
N X,Y S Y=0
I +$P(^DD(TFILE,TFLD,0),U,2)>0 D
. N SFILE S SFILE=+$P(^DD(TFILE,TFLD,0),U,2)
. S Y=$S($P(^DD(SFILE,.01,0),U,2)="W":1,1:0)
Q Y\n\n
2. The input transform for the TARGET FILE field (#.05) in the GMR REPORT TYPE
file, which is a pointer to the File of Files, assures that only files which
include the "GMRD" application group may be chosen for inclusion in the
upload. This was done to assure that the site could not inadvertently choose
an inappropriate target file (NOTE: the only file exported with this
Application Group is the GMR REPORTS FILE (#128), where Discharge Summaries
themselves are housed). The input transform looks like this:\n
S DIC("S")="I $D(^DIC(+Y,""%"",""B"",""GMRD""))" D ^DIC K DIC S
DIC=DIE,X=+Y K:Y<0 X\n", "", "", ""], ["831", "DBIA315-B", "Routine", "IFCAP", "1993/11/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PRCS58CC", "2012/04/26"], ["832", "DBIA315-C", "Routine", "IFCAP", "1993/11/01", "APPROVED", "Active", "Private", "", "", "", "PRCSUT31", ""], ["833", "DBIA316-B", "Routine", "1", "1993/11/01", "APPROVED", "Active", "Private", "", "
3. The lookup routine, XTLKDICL, is often executed
recursively by Fileman. under some conditions, it is not appropriate to
proceed with the lookup and processing must pass back to DIC at the
appropriate entry point. MTLU therefore needs support for the entry points,
ASK^DIC and RTN^DIC. Some of the variables that are used by the ASK^DIC and
RTN^DIC calls are:\n
Variables: Used in:
DO(2 EN2+3,EN2+5
DIC TS+1
DIC(0 XTLKDICL+3,EN1+2
DIE XTLKDICL+3
DIPGM(0 XTLKDICL+3,XTLKDICL+5
DO TS
DO(2 TS,TS+1,TS+2
X XTLKDICL+4,EN2+1,EN2+3,EN2+5,TS+1,TS+4,TS+8,TS+9
Y EN2+1,TS,TS+8,TS+9 Label References:
EN1 TS+9
EN2 XTLKDICL+5,TS+8\n
External References:
ASK^DIC EN1+2
RTN^DIC XTLKDICL+3,EN2+3,EN2+5\n
The calls to RTN^DIC and ASK^DIC are granted for the exclusive use of the
Kernel's Toolkit package.", "", "DIC", ""], ["834", "DBIA317-B", "Routine", "VETERANS ADMINISTRATION", "1993/11/02", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VALM2", ""], ["835", "DBIA323-B", "File", "KERNEL", "1993/12/16", "APPROVED", "Active", "Private", "3.5", "\n
To support bar code label printing and downloading/uploading, the
Controlled Substances package has found it necessary to develop hardware
specific parameters for the TERMINAL TYPE and DEVICE file. Centralized
procurements of Hewlett Packard and Kyocera laser printers and Intermec
trakkers have steered this package toward the use of these hardware types. As
testing has proceeded, the need to accurately communicate complex strings for
insertion into the TERMINAL TYPE file has proved difficult. An l
misinterpreted as a 1, a 0 mininterpreted as a O, or an inadvertant space or
lack thereof all can render a device inoperable.
It is therefore agreed that IRM utility routines (PSDTER*) be exported
which would allow ^DIC look-ups to the TERMINAL TYPE and DEVICE files, ^DIR
verification of the selections, and ^DIE stuffs to the necessary fields
identified as follows:\n
GLOBAL MAP DATA DICTIONARY #3.5 -- DEVICE FILE STORED IN ^%ZIS(1, (VERSION
7.1)
--------------------------------------------------------------------------
^%ZIS(1,D0,0)= (#.01) NAME [1F] ^ (#1) $I [2F] ^ (#4) ASK DEVICE [3S] ^
==>(#5) ASK PARAMETERS [4S] ^
==> ^ (#1.95) SIGN-ON/SYSTEM DEVICE [11S] ^ ^%ZIS(1,D0,1)= (#.02)
LOCATION OF TERMINAL [1F] ^ ^%ZIS(1,D0,91)= (#9) MARGIN WIDTH [1N] ^ (#10)
FORM FEED [2F] ^ (#11) PAGE
==>LENGTH [3N] ^ (#12) BACK SPACE [4F] ^ ^%ZIS(1,D0,SUBTYPE)=
(#3) SUBTYPE [1P] ^ ^%ZIS(1,D0,TYPE)= (#2) TYPE [1S] ^ ^%ZIS(1,D0,VMS)= (#61)
LAT SERVER NODE [1F] ^ (#62) LAT SERVER PORT [2F] ^
==>(#63) VMS DEVICE TYPE [3S] ^ (#64) LAT PORT SPEED [4S] ^", "", "", ""], ["836", "DBIA325-B", "File", "REGISTRATION", "1993/12/23", "APPROVED", "Active", "Private", "405", "\n
Globals -- For the PATIENT MOVEMENT (#405) file:\n
Zeroth node (^DGPM(ien,0)):\n
Field Name/#/Piece on node Reason Needed
============================ =============
DATE/TIME (#.01) (1) Determine the movement
date/time
TRANSACTION (#.02) (2) Determine if the movement
is an admission
PATIENT (#.03) (3) Determine the pointer to
the patient whose movement
it is
ADMISSION/CHECK-IN MOVEMENT (#.14) (14) Determine the pointer to
the admission for a
particular movement
DISCHARGE/CHECK-OUT MOVEMENT (#.17) (17) Determine the pointer to
the discharge for a
particular movement
MAS MOVEMENT TYPE (#.18) (18) Determine the movement type
ASIH TRANSFER (#.21) (21) Determine if the movement
was due to ASIH\n
"APCA" cross reference (^DGPM("APCA",DFN,Adm Ptr,Mvmt Date,ien)):\n
This cross-reference is used to find all of the movements, as of
a specified date, for a specific admission for a patient.\n
"ATID1" cross reference (^DGPM("ATID1",DFN,Inv Adm Date,ien)):\n
This cross-reference is used to find all of a patient's admissions
as of a specific date.\n\n
Please note that all of these references may be found in the
routine IVMUFNC1.", "", "", ""], ["837", "DBIA325-C", "File", "SCHEDULING", "1993/12/23", "APPROVED", "Active", "Private", "2", "\n
Globals -- For the APPOINTMENT (#1900) field (sub-file #2.98)
of the PATIENT (#2) file:\n
Zeroth node (^DPT(DFN,"S",Visit Date/Time,0)):\n
Field Name/#/Piece on node Reason Needed
============================ =============
APPOINTMENT DATE/TIME (#.001) (ien) Determine the visit date
CLINIC (#.01) (1) Need clinic to see of it
is non-count
STATUS (#3) (2) Need to see if visit was
cancelled
APPOINTMENT TYPE (#9.5) (16) Need to see if Appointment
Type is billable
OUTPATIENT ENCOUNTER (#21) (20) Need pointer to the
Outpatient Encounter (if
it exists) to see if visit
was related to claimed
exposures\n
For the DISPOSITION LOG-IN DATE/TIME (#1000) field
(sub-file #2.101) of the PATIENT (#2) file:\n
Zeroth node (^DPT(DFN,"DIS",Inv Log-In Date/Time,0)):\n
Field Name/#/Piece on node Reason Needed
============================ =============
STATUS (#1) (2) Make sure registration is
not Application w/o Exam
OUTPATIENT ENCOUNTER (#18) (18) Need pointer to the
Outpatient Encounter (if
it exists) to see if visit
was related to claimed
exposures", "", "", ""], ["838", "DBIA325-D", "File", "SCHEDULING", "1993/12/23", "", "Retired", "Private", "409.5", "\n
For SCHEDULING VISITS (#409.5) file:\n
"ADT" cross reference (^SDV("ADT",DFN,Visit Date)=ptr):\n
This cross-reference is used to find all of a patient's stops
on a specific date.\n
CLINIC STOP CODE (#10) field (sub-file #409.51):
Zeroth node (^SDV(ptr,"CS",ien,0)):\n
Field Name/#/Piece on node Reason Needed
============================ =============
ASSOCIATED CLINIC (#3) (3) Need clinic to see of it
is non-count
APPOINTMENT TYPE (#5) (5) Need to see if Appointment
Type is billable
OUTPATIENT ENCOUNTER (#8) (8) Need pointer to the
Outpatient Encounter (if
it exists) to see if visit
was related to claimed
exposures", "", "", ""], ["839", "DBIA325-E", "File", "SCHEDULING", "1993/12/23", "APPROVED", "Active", "Private", "209.42", "\n
For the OUTPATIENT CLASSIFICATION (#409.42) file:\n
Zeroth node (^SDD(409.42,ien,0)):\n
Field Name/#/Piece on node Reason Needed
============================ =============
TYPE (#.01) (1) Determine whether question
relates to AO, SC, IR, or
EC
VALUE (#.03) (3) Determine whether care was
related to the claimed
exposure.\n
"OE" cross reference (^SDD(409.42,"OE",ptr to #409.68,ien)):\n
This cross-reference is used to find all classification answers
for a specific outpatient encounter.\n\n
Please note that all of these references may be found in the
routine IVMUFNC2.", "", "", ""], ["840", "DBIA329-B", "Routine", "1", "1994/01/12", "APPROVED", "Active", "Private", "", "", "", "DII", ""], ["841", "DBIA329-C", "File", "1", "1994/01/12", "", "Retired", "Private", "", "
DICRW+5^ESPFM, the reference to ^DIC(+Y,0,"GL")", "", "", ""], ["842", "DBIA329-D", "File", "1", "1994/01/12", "APPROVED", "Active", "Private", "", "
1. Read only: ^DD(910.2,.01,0) - ESP POLICE
REGISTRATION LOG File - Displays an identifier.\n
2. Read only: ^DD(910.7,IEN,0,U,R) - ESP SELECTABLES file - Displays the
color field as an identifier.\n
3. ^DD(912,.01,1,2,1.4) - ESP OFFENSE REPORT file - Executes a trigger to
stuff institution information.\n
4. Read only: ^DD(914,.03,0) - ESP VIOLATIONS file - Displays if courtesy or
violation identifier.\n
5. ^DD("SITE" - IEN - INSTITIUTION file read only.\n
6. Read only: ^DD(915,.01,0) ESP OFFENSE CODES file - Displays Offense Code
as an identifier.", "", "", ""], ["843", "DBIA333-B", "File", "LAB SERVICE", "1994/01/14", "", "Retired", "Private", "61", "
Outpatient Pharmacy is granted a temporary integration
agreement with Laboratory to obtain results for a given lab test specimen type
within a date range. This data may be used many different ways. Current uses
are clozapine monitoring, printing on action profile, and drug usage
evaluation.\n\n
GLOBAL MAP DATA DICTIONARY #61 -- TOPOGRAPHY FIELD FILE STORED IN ^LAB(61,
SITE: BIRMINGHAM ISC
--------------------------------------------------------------------------
^LAB(61,D0,0)= (#.01) NAME [1F] ^", "", "", ""], ["844", "DBIA333-C", "File", "LAB SERVICE", "1994/01/14", "APPROVED", "Active", "Private", "63", "
Outpatient Pharmacy is granted a temporary integration
agreement with Laboratory to obtain results for a given lab test specimen type
within a date range. This data may be used many different ways. Current uses
are clozapine monitoring, printing on action profile, and drug usage
evaluation.\n
GLOBAL MAP DATA DICTIONARY #63 -- LAB DATA FILE STORED IN ^LR(
SITE: BIRMINGHAM ISC
--------------------------------------------------------------------------
^LR(D0,"CH",D1,0)= (#.01) DATE/TIME SPECIMEN TAKEN [1D] ^^ (#.03) DATE
REPORT COMPLETED [3D] ^^ (#.05) SPECIMEN TYPE [5P] ^
^LR(D0,"CH",D1,data name#)= (data name#) results ^\n", "", "", ""], ["845", "DBIA335-B", "File", "SCHEDULING", "1994/01/18", "APPROVED", "Active", "Private", "2", "
Pharmacy Prescription Practices Prototype is granted
this DBIA with Scheduling to make the following calls:\n
C. ^DPT(DFN,"S",DATE,0) -> Used to verify that a clinic
appointment has not been canceled.\n", "", "", ""], ["846", "DBIA344-B", "Other", "ORDER ENTRY/RESULTS REPORTING", "1994/01/31", "APPROVED", "Active", "Private", "", "
The Unwinder was originally written as part of OE/RR in
the namespace OR. When the Unwinder functionality was separated into the XQOR
routines, all the links to OE/RR were isolated into the routine, XQORO. This
routine uses OE/RR variables, and calls into OE/RR entry points. The
following integration agreements are needed to support this routine (XQORO).\n
OE/RR Variables: The XQORO routine makes sure OE/RR variables are set to the
proper values between each protocol that is executed. The following variables
are killed between each protocol to protect the OE/RR environment -\n
ORIFN,ORCOST,ORIT,ORSTRT,ORSTOP,ORTO,ORPURG,ORTX,ORSTS,ORPK,ORLOG,
ORPCL,OR,ORZ,ORNS\n
The following variables are reset between each protocol -\n
ORVP,ORPV,ORL,ORTS,ORDUZ,ORNP,OROLOC,ORGY,ORACTION,OROLD,ORNS,
ORTX,ORUP\n
ORPRFRM is used in conjunction with response time monitoring.", "", "", ""], ["847", "DBIA344-C", "File", "ORDER ENTRY/RESULTS REPORTING", "1994/01/31", "APPROVED", "Active", "Private", "100.99", "
Read Access to File 100.99: The OE/RR Parameters file
(100.99) is accessed in setting up some of the OE/RR variables and in
determining if OE/RR is running.", "", "", ""], ["848", "DBIA344-D", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/01/31", "APPROVED", "Active", "Private", "", "", "", "OR1", ""], ["849", "DBIA344-E", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/01/31", "APPROVED", "Active", "Private", "", "", "", "ORX2", ""], ["850", "DBIA344-F", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/01/31", "APPROVED", "Active", "Private", "", "", "", "ORUTL", ""], ["851", "DBIA344-G", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/01/31", "APPROVED", "Active", "Private", "", "", "", "ORGKEY", ""], ["852", "DBIA344-H", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/01/31", "APPROVED", "Active", "Private", "", "", "", "ORUHDR", ""], ["853", "DBIA345-B", "File", "1", "1994/02/02", "", "Retired", "Private", "", "\n
Read only access for ^DIC(FN,0,"GL"), where FN is a file number, to
verify the the value of DIC prior to initiating the look-up (GMPTA4).", "", "", ""], ["854", "DBIA346-B", "File", "TOOLKIT", "1994/02/04", "APPROVED", "Active", "Private", "8984.2", "\n
Read only access to ^XT(8984.2,"B" and the associated data node
^XT(8984.2,DA,0)\n
If the user input is found in the "B" cross-reference, and it is
a valid "Short Cut" for the Clinical Lexicon - ^XT(8984.2,DA,0)[GMP(757.01 -
then the preprocessing of the input string is disabled and the Multi-Term
Look-Up Utility (MTLU) is called directly (GMPTA2).\n
Read only access to ^XT(8984.* globals for $D checks in the Environment
Check routine prior to installing the Clinical Lexicon (GMPTIENV).\n
i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not
found" K DIFQ Q\n
Read/Write access to ^XT(8984.* global in Post-Init routines to setup
the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST).\n
i.e.,\n
a. Seeding the Local Look-Up file #8984.4 with the Clinical
Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT
display routine.\n
b. Seeding the Synonym file #8984.3 with Cancer as a sample
synonym for Carcinoma\n
c. Seeding the Short Cut file #8984.2 with DM II as a sample
short cut for Diabetes Mellitus, Non-Insulin Dependent", "", "", ""], ["855", "DBIA346-C", "File", "TOOLKIT", "1994/02/04", "APPROVED", "Active", "Private", "8984.3", "\n
Read only access to ^XT(8984.* globals for $D checks in the Environment
Check routine prior to installing the Clinical Lexicon (GMPTIENV).\n
i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not
found" K DIFQ Q\n
Read/Write access to ^XT(8984.* global in Post-Init routines to setup
the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST).\n
i.e.,\n
a. Seeding the Local Look-Up file #8984.4 with the Clinical
Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT
display routine.\n
b. Seeding the Synonym file #8984.3 with Cancer as a sample
synonym for Carcinoma\n
c. Seeding the Short Cut file #8984.2 with DM II as a sample
short cut for Diabetes Mellitus, Non-Insulin Dependent", "", "", ""], ["856", "DBIA346-D", "File", "TOOLKIT", "1994/02/04", "APPROVED", "Active", "Private", "8984.4", "\n
Read only access to ^XT(8984.* globals for $D checks in the Environment
Check routine prior to installing the Clinical Lexicon (GMPTIENV).\n
i.e. I '$D(^XT(8984.1)) W !,"Multi-Term Look-Up Untility not
found" K DIFQ Q\n
Read/Write access to ^XT(8984.* global in Post-Init routines to setup
the Multi-Term Look-Up Utility for the Clinical Lexicon (GMPTIPST).\n
i.e.,\n
a. Seeding the Local Look-Up file #8984.4 with the Clinical
Lexicon Expression file #757.01, the "AWRD" index and the XTLK^GMPTPRNT
display routine.\n
b. Seeding the Synonym file #8984.3 with Cancer as a sample
synonym for Carcinoma\n
c. Seeding the Short Cut file #8984.2 with DM II as a sample
short cut for Diabetes Mellitus, Non-Insulin Dependent", "", "", ""], ["857", "DBIA346-E", "Other", "TOOLKIT", "1994/02/04", "", "Retired", "Private", "", "\n
Agreement is to add XTLK name-spaced Option XTLKUSER2 to the GMPT
CLINICAL LEXICON MGT MENU so managers can add keywords, short-cuts and
synonyms to the ^XT(8984.* files without leaving the Clinical Lexicon Manager
menu.", "", "", ""], ["858", "DBIA351-B", "File", "KERNEL", "1994/02/28", "", "Retired", "Private", "", "
Use of ^XUTL: The XQOR routines use ^XUTL("XQORM") and
^XUTL("XQORW") to store compiled protocol menus. An agreement to allow use of
these global nodes would partially replace DBIA #4 (which erroneously
identifies the node used as ^XUTL("ORUM")). The portion of DBIA #4 which
allows OE/RR to use ^XUTL("OR",$J,package namespace) would need to remain as
is.", "", "", ""], ["859", "DBIA351-C", "File", "1", "1994/02/28", "", "Retired", "Controlled Subscription", "", "", "", "", ""], ["860", "DBIA351-D", "Routine", "KERNEL", "1994/02/28", "", "Retired", "Private", "", "
Call to ABT^XQ12: The Unwinder calls ABT^XQ12. I
believe this is part of the response time monitoring. The local variable,
XQXFLG, is also checked when making this call. Agreement is made to call
ABT^XQ12 and check the XQXFLG variable or this needs to be placed on the list
of supported references.\n", "", "XQ12", ""], ["861", "OR", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "OR", ""], ["862", "ORUHDR", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORUHDR", ""], ["863", "ORUPREF2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2004/09/07", "", "Retired", "Controlled Subscription", "", "", "", "ORUPREF2", ""], ["864", "ORUTL", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORUTL", ""], ["865", "ORVOM", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORVOM", ""], ["866", "ORX", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORX", ""], ["867", "ORX2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/06/29", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORX2", ""], ["868", "ORX3", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORX3", ""], ["869", "ORX5", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORX5", ""], ["870", "ORX7", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORX7", ""], ["871", "ORX8", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1994/04/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORX8", "2009/03/03"], ["872", "File 101", "File", "KERNEL", "1994/04/28", "APPROVED", "Active", "Controlled Subscription", "101", "
This file may be referenced by packages to maintain
protocols within their namespace. This file may also be pointed to.", "", "", ""], ["873", "File 100.98", "File", "ORDER ENTRY/RESULTS REPORTING", "1994/04/28", "APPROVED", "Active", "Controlled Subscription", "100.98", "
This file may be referenced to determine an appropriate
Display Group for an order in the manner:
S ORTO=$O(^ORD(100.98,'B','OTHER HOSPITAL SERVICES',0))", "", "", ""], ["874", "File 100.99", "File", "ORDER ENTRY/RESULTS REPORTING", "1994/04/28", "APPROVED", "Active", "Controlled Subscription", "100.99", "
This file may be referenced by packages interfacing
with OE/RR to see if OE/RR has been installed in the manner:
I $D(^ORD(100.99)) ...\n
Packages may also setup entries in the Package Parameters portion of this
file.", "", "", ""], ["875", "File 100.01", "File", "ORDER ENTRY/RESULTS REPORTING", "1994/04/28", "APPROVED", "Active", "Controlled Subscription", "100.01", "
This file may be pointed to.", "", "", ""], ["885", "DBIA885", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "52", "
This agreement will be retired on 12/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSO*7*213. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["886", "DBIA886", "File", "PHARMACY DATA MANAGEMENT", "1994/11/17", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
As described in DBIA885, External Peer Review needs to identify patients
receiving prescriptions in certain VA classes.", "", "", ""], ["887", "MTLU setup", "File", "TOOLKIT", "1994/05/16", "APPROVED", "Active", "Controlled Subscription", "8984.4", "
The Clinical Lexicon Utility needs to write to the
Kernel Toolkit Multi-Term Look-up Utility's (MTLU) files/DDs during the
Post-Init.", "", "", ""], ["888", "MTLU setup", "File", "1", "1994/05/16", "APPROVED", "Active", "Private", "8984.1", "
The Clinical Lexicon Utility needs to write to the DD
of the Kernel Toolkit Multi-Term Look-up Utility (MTLU) during the Post-Init.", "", "", ""], ["889", "MTLU setup", "File", "1", "1994/05/16", "APPROVED", "Active", "Private", "8984.2", "
The Clinical Lexicon Utility needs to write to the DD
of Kernel Toolkit Multi-Term Look-up Utility (MTLU) during the Post-Init.", "", "", ""], ["890", "MTLU setup", "File", "TOOLKIT", "1994/05/16", "APPROVED", "Active", "Controlled Subscription", "8984.2", "
The Clinical Lexicon Utility needs to write to the
Kernel Toolkit Multi-Term Look-up Utillity's (MTLU) files/DDs during the
Post-Init.", "", "", ""], ["891", "MTLU setup", "File", "TOOLKIT", "1994/05/16", "APPROVED", "Active", "Controlled Subscription", "8984.3", "
The Clinical Lexicon Utility needs to write to the
Kernel Toolkit Multi-Term Look-up Utility's (MTLU) files/DDs during the
Post-Init.", "", "", ""], ["892", "GMTSLRCE", "Routine", "HEALTH SUMMARY", "1996/02/15", "APPROVED", "Active", "Controlled Subscription", "", "
The Adverse Reaction Tracking (ART) package uses a call
to XTRCT^GMTSLRCE to extract lab results. A check is made for the existence of
the routine i.e., $T(GMTSLRCE^GMTSLRCE).", "", "GMTSLRCE", ""], ["893", "SURGERY Data Interface for LABORATORY SERVICE", "Routine", "SURGERY", "2000/12/07", "APPROVED", "Active", "Private", "", "
SROSPLG was written as an interface to provide SURGERY
data for LABORATORY SERVICE Surgical Pathology reports created during Anatomic
Pathology Log-In. Entry point SROSPLG allows the LABORATORY SERVICE user to
select from a list of surgeries performed in the last seven days for the given
patient. Entry point DISP extracts the chosen surgery data and copies it into
the corresponding Surgical Pathology report.", "", "SROSPLG", ""], ["894", "DBIA894", "File", "LAB SERVICE", "1994/05/18", "APPROVED", "Active", "Private", "63", "
The Surgery package has written routines to be used
with the Surgical Pathology (SP) portion of the Laboratory package. When an
SP specimen is accessioned, the Laboratory package will call the above
mentioned Surgery routines. The Surgery routines will allow the accessioning
person to associate the specimen with a surgical case and transfer certain
information from the SURGERY file (#130) to the LAB DATA file (#63). The
information (Brief Clinical History, Preoperative Diagnosis, Operative
Findings and Postoperative Diagnosis) will be written to File 63. This
agreement gives permission to Surgery to write this information to File 63 if
the matching field in File 63 does not already contain data. Also, this
agreement allows Surgery to read the PARENT FILE field (.02) and the NAME
field (.03) of File 63 to establish the patient identity.", "", "", ""], ["895", "PSSGIU", "Routine", "PHARMACY DATA MANAGEMENT", "1994/06/24", "APPROVED", "Active", "Controlled Subscription", "", "
Gives the ability to mark entries in the Drug file (50)
for use with various packages.", "", "PSSGIU", ""], ["896", "DBIA896", "File", "INDIAN HEALTH SERVICE", "1994/09/06", "APPROVED", "Active", "Private", "9000001", "
** A DBIA agreement is being requested by the
Patient/IHS Subset package
(PXPT) with the Indian Health Service. This agreement would document
the changes in the use of the Patient/IHS file in the VA. **\n
This description includes a comparison of the VA's Patient/IHS File (9000001)
as distributed in the PXPT package and the IHS's Patient/IHS File (9000001).\n
NOTE: Per discussions previously with IHS developers, George Huggins has
agreed to have the file named "Patient" file (9000001) in IHS changed to
the name "Patient/IHS" file.\n
VA Patient/IHS File:
====================
The VA version of 9000001 has a subset of fields defined in the IHS version.
The main consideration for determining what should be distributed in the VA
was: "What is the minimal set of data required to have the Patient/IHS file
defined and be useable by IHS tools, such as QMAN". Sending out the
minimum set limits the confusion of sending out Patient/IHS fields and
pointed to files that could cause confusion in the VA.\n
Summary of differences in File and fields:
File SPECIAL LOOKUP ROUTINE is sent out as DPTLK
File POST SELECTION ACTION is sent out as D ^AUPNPAT
The only fields destributed in VA nationally are NAME,
LOCATION OF HOME,
and HEALTH RECORD NO. multiple.
The Health Record No. multiple has had a few changes.
The .01 field is based on the Default institution in the
Kernel Site Parameter file because the DUZ(2) upon
adding a patient may not reflect the institution the patient
should be related to. (e.g., Regional Office adding Patients)\n
The .02 field has been changed to be a freetext field long
enough for a SSN or pseudo-SSN or DOD PID with dependent
counters.\n
The following is the Standard List of Attributes for the VA version:\n
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n
STANDARD DATA DICTIONARY #9000001 -- PATIENT/IHS FILE 05/26/94 PAGE 1
STORED IN ^AUPNPAT( (406 ENTRIES) SITE: SLC UCI: DVA,DEV\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
-------------------------------------------------------------------------
This file is IHS's primary patient data file. The NAME (.01) field of this
file is a pointer to the VA's patient file (#2). Fields in common between the
two dictionaries actually exist only in the VA patient file and are referenced
by the IHS patient file as computed fields. All other files containing
patient data have backward pointers linking them to this file. The linkage is
by patient name and the internal FileMan gener- ated number of the ancillary
file is the same number used in this file.\n
All applications developed for the RPMS which require patient data will point
to this file.\n
FILE SCREEN (SCR-node) : X "I '$P(^DPT(Y,0),U,19)" W $E(^AUPNPAT(Y,0),0)
SPECIAL LOOKUP ROUTINE : DPTLK POST-SELECTION ACTION : D ^AUPNPAT
DD ACCESS: @
DEL ACCESS: @\n
POINTED TO BY: PATIENT field (#.02) of the TIU DOCUMENT File (#8925)
PATIENT NAME field (#.05) of the VISIT File (#9000010)
PATIENT NAME field (#.02) of the V MEASUREMENT File
(#9000010.01)
PATIENT NAME field (#.02) of the V PROVIDER File
(#9000010.06)
PATIENT NAME field (#.02) of the V POV File (#9000010.07)
PATIENT NAME field (#.02) of the V LAB File (#9000010.09)
PATIENT NAME field (#.02) of the V IMMUNIZATION File
(#9000010.11)
PATIENT NAME field (#.02) of the V SKIN TEST File
(#9000010.12)
PATIENT NAME field (#.02) of the V EXAM File (#9000010.13)
PATIENT NAME field (#.02) of the V MEDICATION File
(#9000010.14)
PATIENT NAME field (#.02) of the V TREATMENT File
(#9000010.15)
PATIENT NAME field (#.02) of the V PATIENT ED File
(#9000010.16)
PATIENT NAME field (#.02) of the V CPT File (#9000010.18)
PATIENT NAME field (#.02) of the V HEALTH FACTORS File
(#9000010.23)
PATIENT NAME field (#.02) of the PROBLEM File (#9000011)\n
CROSS REFERENCED BY: NAME(B), HEALTH RECORD NO.(D)\n
9000001,.01 NAME 0;1 POINTER TO PATIENT FILE (#2)
(Required)\n
INPUT TRANSFORM: S:$D(X) DINUM=X
LAST EDITED: SEP 29, 1990
DESCRIPTION: This field points to the Patient file
(#2) and has the same internal number as
that file. Thus, the patient's name is
the Patient file (#2) name.\n
TECHNICAL DESCR: This field is populated in the VA when a
new patient is added to the ^DPT file by
the PX09 cross-reference on the Social
Security Number (.09) field of ^DPT.\n
Any merging of patients in ^DPT by a VAMC
should include this PATIENT/IHS file in
its merging process.\n
SOURCE OF DATA: 011/PINAME
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMME R\n
CROSS-REFERENCE: 9000001^B
1)= S ^AUPNPAT("B",$E(X,1,30),DA)=""
2)= K ^AUPNPAT("B",$E(X,1,30),DA)\n
9000001,1201 LOCATION OF HOME 12;0 WORD-PROCESSING #9000001.12\n
DESCRIPTION: This is the directions to get to the
patients home.\n
9000001,4101 HEALTH RECORD NO. 41;0 POINTER Multiple #9000001.41
(Add New Entry without Asking)\n
DESCRIPTION: This multiple contains the different
health record identifiers by facility.
IHS uses a 6 character identifier. The
VA uses the social security number which
may be up to 10 characters.\n
TECHNICAL DESCR: This multiple is used for Multi-Facility
Integration (MFI) processing at IHS
facilities.\n
IDENTIFIED BY: HEALTH RECORD NO.(#.02),\n
9000001.41,.01 HEALTH RECORD FAC 0;1 POINTER TO LOCATION FILE (#999
9999.06)\n
INPUT TRANSFORM: S DINUM=X
LAST EDITED: MAR 7, 1991
HELP-PROMPT: ENTER NAME OF FACILITY ASSOCIATED WITH
THE HEALTH RECORD NUMBER YOU WISH TO
ENTER.
DESCRIPTION: This field is a pointer to the LOCATION
file. The internal pointer is forced
into the third subscript for the
9000001.41 subfile. This allows easy
lookup by health record number for the
logged on location (facility).\n
The complete subscript for 9000001.41
will be (DFN,41,facility pointer,0).\n
TECHNICAL DESCR: In the VA, the Kernel Site Parameters
DEFAULT INSTITUTION field is used to
populate this field. This was used
instead of the users institution
because of regional users ability to
add patients to the VA.\n
SOURCE OF DATA: 015/HRSUBR
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAM MER\n
9000001.41,.02 HEALTH RECORD NO. 0;2 FREE TEXT (Required)\n
INPUT TRANSFORM: I $G(DUZ("AG"))="I" K:(X'?1.6N&(X'?1"T"
5N))!(X?1.6N&(X'=+X)) X
LAST EDITED: MAY 24, 1988
HELP-PROMPT: ENTER TEXT FROM 1 TO 10 CHARACTERS.
DESCRIPTION: This field is used to represent the
health record number related to a
facility.\n
IHS uses a 6 character whole number.\n
VA uses the patient SSN from the
Patient File (2).\n
TECHNICAL DESCR: In the VA, this field is populated by
the PX09 cross-reference on the SSN
(.09) field of the Patient File (2).\n
SOURCE OF DATA: 015/HRNUMB
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAM MER\n
CROSS-REFERENCE: 9000001^D
1)= S ^AUPNPAT("D",$E(X,1,30),DA(1),DA)
=""\n
2)= K ^AUPNPAT("D",$E(X,1,30),DA(1),DA)\n
9000001.41,.03 DATE INACTIVATED/DELETED 0;3 DATE\n
INPUT TRANSFORM: S %DT="EX" D ^%DT S X=Y K:Y<1 X
DESCRIPTION: This is date that the patients entry
was inactivated.\n
TECHNICAL DESCR: This is primarily used by IHS
facilities for tracking patients. The
VA currently is not maintaining this
field.\n
9000001.41,.05 RECORD STATUS 0;5 SET\n
'D' FOR DELETED;
'I' FOR INACTIVATED;
'M' FOR MERGED;
LAST EDITED: APR 19, 1990
HELP-PROMPT: Enter "D" if the record has been
deleted.
DESCRIPTION: This field is used by the IHS
Multi-Facility Integration (MFI)
package to determine whether to stop
integrating data at a facility for a
particular patient and location
facility.\n
9000001.41,.06 STOP INTEGRATION 0;6 SET
'0' FOR NO;
'1' FOR YES;
LAST EDITED: AUG 17, 1988
DESCRIPTION: This field is used by the Mult-Facility
Integration (MFI) package, created by
IHS, to indicate this patients data
should no longer be integrated by MFI.\n
FILES POINTED TO FIELDS\n
LOCATION (#9999999.06) HEALTH RECORD NO.:HEALTH RECORD FAC (#.01)
PATIENT (#2) NAME (#.01)\n
===========================================================================
The following are two captures, one of the global map of the Patient File
BEFORE VA changes, and the second is the Standard attribute list for the
Health Record multiple.\n
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GLOBAL MAP DATA DICTIONARY #9000001 -- PATIENT FILE 05/26/94 PAGE 1
STORED IN ^AUPNPAT( (1 ENTRY) SITE: SALT LAKE CITY UCI: PCC,PCC
-------------------------------------------------------------------------
This file is the primary patient data file. The NAME (.01) field of this file
is a backward pointer to the VA's patient file (#2). Fields in common between
the two dictionaries actually exist only in the VA patient file and are
referenced by the IHS patient file as computed fields. All other files
containing patient data have backward pointers linking them to this file. The
linkage is by patient name and the internal FileMan gener- ated number of the
ancillary file is the same number used in this file.\n
All applications developed for the RPMS which require patient data will point
to this file.\n
CROSS REFERENCED BY: CURRENT COMMUNITY(AC), CLASSIFICATION/BENEFICIARY(AD),
DATE ESTABLISHED(ADTE), TRIBE OF MEMBERSHIP(AE),
EMPLOYER NAME(AF), SPOUSE'S EMPLOYER NAME(AG),
TRIBE QUANTUM(AZ1), INDIAN BLOOD QUANTUM(AZ2),
PCIS ID NO.(AZZ), NAME(B), HEALTH RECORD NO.(D) ^AUPNPAT(D0,0)=
(#.01) NAME [1P] ^ (#.02) DATE ESTABLISHED [2D] ^
==>(#.03) DATE OF LAST REG. UPDATE [3D] ^ (#.04) OUTPT
==>MED/RR RELEASE DATE [4D] ^ (#.05) MED/RR RELEASE
==>REVOKED DATE [5D] ^ (#.06) PCIS ID NO. [6F] ^ (#.07)
==>TRIBAL ENROLLMENT NO. [7F] ^ (#.08) MFI MEDICAL [8S] ^
==>(#.09) CHS TRIBAL AFFILIATION [9P] ^ ^ (#.11)
==>ESTABLISHING USER [11P] ^ (#.12) USER-LAST UPDATE [12P]
==>^ (#.13) BLOOD TYPE [13S] ^ (#.14) PRIMARY PROVIDER
==>[14P] ^ (#.15) CHS TX DATE [15D] ^ (#.16) DATE OF LAST
==>UPDATE [16D] ^ (#.17) ASSIGN BENEFITS OBTAINED DATE
==>[17D] ^ (#.18) ASSIGN BENEFITS EXPIRED DATE [18D] ^
==>(#.19) EMPLOYER NAME [19P] ^ ^ (#.21) EMPLOYMENT
==>STATUS [21S] ^ (#.22) SPOUSE'S EMPLOYER NAME [22P] ^
==>(#.23) SSN VERIFICATION STATUS [23P] ^ (#.24) REASON
==>FOR NO SSN [24S] ^ ^AUPNPAT(D0,3)= (#.31) PRINTABLE NAME [1F]
^ ^AUPNPAT(D0,11)= ^ ^ ^ ^ (#1105) BIRTH CERTIFICATE NO. [5F] ^ ^ ^
==>(#1108) TRIBE OF MEMBERSHIP [8P] ^ (#1109) TRIBE
==>QUANTUM [9F] ^ (#1110) INDIAN BLOOD QUANTUM [10F] ^
==>(#1111) CLASSIFICATION/BENEFICIARY [11P] ^ (#1112)
==>ELIGIBILITY STATUS [12S] ^ ^ (#1114) UNDERLYING CAUSE
==>OF DEATH [14P] ^ (#1115) STATE OF DEATH [15P] ^
==>(#1116) DEATH CERTIFICATE NO. [16F] ^ ^ (#1118)
==>CURRENT COMMUNITY [18F] ^ (#1119) TRIBE MEMBERSHIP
==>VERIFIED FLAG [19S] ^ ^ (#1121) RESIDENCE VERIFIED
==>FLAG [21S] ^ (#1122) PREV HSDA RES (VER) FLAG [22S] ^
==>(#1123) DATE ELIGIBILITY DETERMINED [23D] ^ (#1124)
==>BIC ELIGIBILITY STATUS [24P] ^ (#1125) ELIGIBILE MINOR
==>CHILD [25S] ^ (#1126) BIC PRINTED FLAG [26S] ^ (#1127)
==>PRE-BIC TRIBE [27P] ^ ^AUPNPAT(D0,12,0)=^9000001.12^^
(#1201) LOCATION OF HOME ^AUPNPAT(D0,12,D1,0)= (#.01) LOCATION OF HOME [1W] ^
^AUPNPAT(D0,13,0)=^9000001.13^^ (#1301) ADDITIONAL REGISTRATION INFO
^AUPNPAT(D0,13,D1,0)= (#.01) ADDITIONAL REGISTRATION INFO [1W] ^
^AUPNPAT(D0,14,0)=^9000001.14^^ (#1401) REMARKS ^AUPNPAT(D0,14,D1,0)= (#.01)
REMARKS [1W] ^ ^AUPNPAT(D0,15,0)=^9000001.15^^ (#1501) ALERTS
^AUPNPAT(D0,15,D1,0)= (#.01) ALERTS [1W] ^ ^AUPNPAT(D0,26)= ^ (#2602)
FATHER'S CITY OF BIRTH [2F] ^ (#2603)
==>FATHER'S STATE OF BIRTH [3P] ^ ^ (#2605) MOTHER'S
==>CITY OF BIRTH [5F] ^ (#2606) MOTHER'S STATE OF BIRTH
==>[6P] ^ ^AUPNPAT(D0,28)= ^ (#2802) NOK RELATIONSHIP [2P] ^
^AUPNPAT(D0,31)= ^ (#3102) EC RELATIONSHIP [2P] ^
^AUPNPAT(D0,41,0)=^9000001.41IP^^ (#4101) HEALTH RECORD NO.
^AUPNPAT(D0,41,D1,0)= (#.01) HEALTH RECORD FAC [1P] ^ (#.02) HEALTH
==>RECORD NO. [2F] ^ (#.03) DATE INACTIVATED/DELETED
==>[3D] ^ (#.04) RECORD DISPOSITION [4P] ^ (#.05)
==>RECORD STATUS [5S] ^ (#.06) STOP INTEGRATION [6S]
==>^
^AUPNPAT(D0,43,0)=^9000001.43P^^ (#4301) OTHER TRIBE ^AUPNPAT(D0,43,D1,0)=
(#.01) OTHER TRIBE [1P] ^ (#.02) QUANTUM [2F] ^
^AUPNPAT(D0,51,0)=^9000001.51D^^ (#5101) PREVIOUS COMMUNITY
^AUPNPAT(D0,51,D1,0)= (#.01) DATE MOVED [1D] ^ (#.02) DATE ADDED TO
==>FILE [2D] ^ (#.03) COMMUNITY OF RESIDENCE [3P] ^
^AUPNPAT(D0,61,0)=^9000001.61P^^ (#6101) MFI SITE ^AUPNPAT(D0,61,D1,0)=
(#.01) MFI SITE [1P] ^\n
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n
The following is a standard list file attributes for the Health Record
multiple BEFORE VA changes:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _\n
STANDARD DATA DICTIONARY #9000001.41 -- HEALTH RECORD NO. SUB-FILE 05/26 /94
PAGE 1 STORED IN ^AUPNPAT( (1 ENTRY) SITE: SALT LAKE CITY UCI: PCC,PCC\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
-------------------------------------------------------------------------
IDENTIFIED BY: HEALTH RECORD NO. (#.02)\n
9000001.41,.01HEALTH RECORD FAC 0;1 POINTER TO LOCATION FILE (#99999
99.06)\n
INPUT TRANSFORM: S DINUM=X
LAST EDITED: MAR 7, 1991
HELP-PROMPT: ENTER NAME OF FACILITY ASSOCIATED WITH
THE HEALTH RECORD NUMBER YOU WISH TO
ENTER.
DESCRIPTION: This field is a pointer to the FACILITY
file. The internal pointer is forced
into the third subscript for the
9000001.41 subfile. This allows easy
lookup by health record number for the
logged on facility.\n
The complete subscript for 9000001.41
will be (DFN,41,facility pointer,0).\n
SOURCE OF DATA: 015/HRSUBR
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMME\n
9000001.41,.02HEALTH RECORD NO. 0;2 FREE TEXT (Required)\n
INPUT TRANSFORM: K:(X'?1.9N&(X'?1"T"5N))!(X?1.9N&(X'=+X))
X
LAST EDITED: APR 6, 1994
HELP-PROMPT: ENTER A WHOLE NUMBER BETWEEN 1 AND 999999
SOURCE OF DATA: 015/HRNUMB
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMME\n
CROSS-REFERENCE: 9000001^D
1)= S ^AUPNPAT("D",$E(X,1,30),DA(1),DA)="
"\n
2)= K ^AUPNPAT("D",$E(X,1,30),DA(1),DA)\n
9000001.41,.0299TERMINAL DIGITS ; COMPUTED\n
MUMPS CODE: X ^DD(9000001.41,.0299,9.4) S X=$E(Y(9000
001.41,.0299,5),Y(9000001.41,.0299,6),X)
S Y=+X,X=Y(9000001.41,.0299,4),X=X_Y
9.2 = S Y(9000001.41,.0299,1)=$S($D(^AUPN
PAT(D0,41,D1,0)):^(0),1:"") S X=$P(Y(9000
001.41,.0299,1),U,2)+1000000,Y(9000001.41
,.0299,2)=X S X=6
9.3 = X ^DD(9000001.41,.0299,9.2) S Y(900
0001.41,.0299,3)=X S X=7,X=$E(Y(9000001.4
1,.0299,2),Y(9000001.41,.0299,3),X)_"-",Y
(9000001.41,.0299,4)=X
9.4 = X ^DD(9000001.41,.0299,9.3) S X=$P(
Y(9000001.41,.0299,1),U,2)+1000000,Y(9000
001.41,.0299,5)=X S X=2,Y(9000001.41,.029
9,6)=X S X=7
9.5 = X ^DD(9000001.41,.0299,9.4) S Y(900
0001.41,.0299,7)=X S X=$P(Y(9000001.41,.0
299,3),U,2)+1000000,Y(9000001.41,.0299,8)
=X S X=2,Y(9000001.41,.0299,9)=X S X=5
ALGORITHM: $E(#.02+1000000,6,7)_"-"_+$E(#.02+1000000
,2,7)
LAST EDITED: JUN 23, 1986\n
9000001.41,.03DATE INACTIVATED/DELETED 0;3 DATE\n
INPUT TRANSFORM: S %DT="EX" D ^%DT S X=Y K:Y<1 X\n
9000001.41,.04RECORD DISPOSITION 0;4 POINTER TO PATIENT RECORD DISPOS
ITION FILE (#9999999.02)\n
LAST EDITED: DEC 10, 1985\n
9000001.41,.05RECORD STATUS 0;5 SET\n
'D' FOR DELETED;
'I' FOR INACTIVATED;
'M' FOR MERGED;
LAST EDITED: APR 19, 1990
HELP-PROMPT: Enter "D" if the record has been deleted.\n
9000001.41,.06STOP INTEGRATION 0;6 SET\n
'0' FOR NO;
'1' FOR YES;
LAST EDITED: AUG 17, 1988\n
FILES POINTED TO FIELDS\n
LOCATION (#9999999.06) HEALTH RECORD FAC (#.01)\n
PATIENT RECORD DISPOSITION
(#9999999.02) RECORD DISPOSITION (#.04)\n\n", "", "", ""], ["897", "DBIA897", "File", "INDIAN HEALTH SERVICE", "1994/09/06", "", "Retired", "Private", "9001000", "
The PCE Patient/IHS Subset package (PXPT) requests a
DBIA with Indian Health Service to distribute the PCC MASTER CONTROL FILE
(9001000).\n
The UNCODED ICD DIAGNOSIS CODE and UNCODED ICD PROCEDURE CODE fields were
added by IHS to support differences in the codes the VA and IHS can use when
an ICD9 code could not be found for a provider narrative. These fields are
only used by PCC logic at this time. The Clinical Lexicon is currently coded
to use a VA default ICD9 code only, and does not make use of these fields.\n
The PXPT developers added a file description and added an 800 node to the
Package multiple for Historical load Control and Last Patient Loaded.\n
The DEFAULT HEALTH SUMMARY TYPE field is used by PCC logic at the Tucson VAMC.
This field is currently only used by PCC logic.\n
The following is the Data Dictionary definition being distributed by PXPT:
-------------------------------------------------------------------------
STANDARD DATA DICTIONARY #9001000 -- PCC MASTER CONTROL FILE 09/6/94
PAGE 1 STORED IN ^APCCCTRL( (1 ENTRY) SITE: SLC UCI: DVA,DEV\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
---------------------------------------------------------------------------
This file is used by both IHS PCC and VA PCE to control interactions between
DHCP packages and their links to populate visit related files.\n\n
DD ACCESS: @
DEL ACCESS: @
AUDIT ACCESS: @\n\n
CROSS REFERENCED BY: SITE(B)\n\n
9001000,.01 SITE 0;1 POINTER TO LOCATION FILE (#9999999
.06) (Required)\n
INPUT TRANSFORM: S:$D(X) DINUM=X
DESCRIPTION: This is the facility's site name. This is
a pointer to the SITE file.\n
Enter the name of the site used for this
facility.\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER\n
CROSS-REFERENCE: 9001000^B
1)= S ^APCCCTRL("B",$E(X,1,30),DA)=""
2)= K ^APCCCTRL("B",$E(X,1,30),DA)\n\n
9001000,.02 TYPE OF LINK 0;2 SET (Required)\n
'0' FOR DATE ONLY REQUIRED;
'1' FOR TIME REQUIRED;
LAST EDITED: APR 2, 1990
DESCRIPTION: This flag is set in order to allow some
flexibility in how visits are created. Some
sites might be such that they only want to
use the date were other sites require that
a time is used in the visit.\n
Enter a code which represents which type of
visit is allowed. enter a "0" for date only
or a "1" for date and time being required.\n\n
9001000,.03 DEFAULT HEALTH SUMMARY TYPE 0;3 POINTER TO HEALTH SUMMARY TYP
E FILE (#142)\n
LAST EDITED: MAY 7, 1992
HELP-PROMPT: Select a summary type from the VA Health
Summary Type file to be used as a default
when generating a health summary.
DESCRIPTION: This is the default Health Summary type
that will be used for this site. It is
chosen from the list of Health Summaries in
the "Health Summary Type" file.\n
Select a summary type that you wish to be
the default for this site.\n\n
9001000,.04 TYPE OF VISIT 0;4 SET\n
TYPE OF VISIT FOR STATISTICAL PURPOSES
'I' FOR IHS;
'C' FOR CONTRACT;
'O' FOR OTHER;
'T' FOR TRIBAL;
'6' FOR 638 PROGRAM;
'V' FOR VA;
LAST EDITED: MAY 31, 1990
DESCRIPTION: This is the type of visit that is made at
this site. It is generally used for
statistical purposes.\n
Enter the code that best describes the
visits made at this site.\n\n
9001000,.05 UNCODED ICD DIAGNOSIS CODE 0;5 POINTER TO ICD DIAGNOSIS FILE
(#80)\n
LAST EDITED: MAR 29, 1993
HELP-PROMPT: Select an ICD DIAGNOSIS code to represent
"uncodable" diagnoses.\n
9001000,.06 UNCODED ICD PROCEDURE CODE 0;6 POINTER TO ICD OPERATION/PROCE
DURE FILE (#80.1)\n
LAST EDITED: MAR 29, 1993
HELP-PROMPT: Select an ICD OPERATION/PROCEDURE code to
represent "uncodable" procedures.\n
9001000,1101 PACKAGE 11;0 POINTER Multiple #9001000.011
(Add New Entry without Asking)\n
DESCRIPTION: This is the ancillary package that has
links to the v files.\n
Enter the name of a package.\n\n
9001000.011,.01 PACKAGE 0;1 POINTER TO PACKAGE FILE (#9.4)
(Required) (Multiply asked)\n
INPUT TRANSFORM: S:$D(X) DINUM=X
DESCRIPTION: This is the ancillary package that has
links to the v-file.\n
Enter the name of an ancillary package.\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAM MER\n\n
9001000.011,.02 PASS DATA TO PCC ? 0;2 SET (Required)\n
'0' FOR NO;
'1' FOR YES;
HELP-PROMPT: If you want data to be passed from this
package to the v-files you must answer 1
(YES).
DESCRIPTION: This is the on and off flag that allows
data to be passed from an ancillary
package to the v-files.\n
Enter a "0" to turn off the link or a "1"
to turn on the link.\n\n
9001000.011,.03 PACKAGE FLAG 0;3 FREE TEXT\n
INPUT TRANSFORM: K:$L(X)>10!($L(X)<1) X
LAST EDITED: JUN 5, 1990
HELP-PROMPT: Answer must be 1-10 characters in length.
DESCRIPTION: This flag is for internal use by the
package.\n\n
9001000.011,800.01HISTORICAL LOAD CONTROL 800;1 SET\n
'0' FOR NO;
'1' FOR YES;
LAST EDITED: NOV 16, 1993
This field is currently not inuse.\n\n
9001000.011,800.02LAST PATIENT LOADED 800;2 FREE TEXT\n
INPUT TRANSFORM: K:$L(X)>30!($L(X)<1) X
LAST EDITED: FEB 2, 1994 T: Answer must be 1-30
characters in length.
DESCRIPTION: This is a field that allows a process to
keep track of the last patient that was
processed. In case of failure that
process can find out where it last
completed a process and where to restart
at.\n
Enter the number or name of the last
patient processed.\n\n\n\n\n
FILES POINTED TO FIELDS\n
HEALTH SUMMARY TYPE (#142) DEFAULT HEALTH SUMMARY TYPE (#.03)\n
ICD DIAGNOSIS (#80) UNCODED ICD DIAGNOSIS CODE (#.05)\n
ICD OPERATION/PROCEDURE (#80.1) UNCODED ICD PROCEDURE CODE (#.06)\n
LOCATION (#9999999.06) SITE (#.01)\n
PACKAGE (#9.4) PACKAGE:PACKAGE (#.01)\n\n
INPUT TEMPLATE(S):\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):\n
The PXPT Post Installation routine creates a PCC Master Control File entry if
it does not exist for the facility. The DEFAULT INSTITUTION field in the
Kernel Site Parameters File is used as the facility.\n", "", "", ""], ["898", "DBIA898", "Routine", "INDIAN HEALTH SERVICE", "1994/09/24", "APPROVED", "Active", "Private", "", "
The PCE Patient/IHS Subset package (namespaced PXPT)
requests a DBIA with the Indian Health Service to distribute the AUPNPAT
routine with the PXPT package. The PXPT package will distribute it as
PXPTNPAT and use ZOSF to load and save the routine as AUPNPAT.\n
There have been no coding changes to the AUPNPAT code by the VA. This is the
same version that is at Tucson VAMC running as of September 4, 1994.\n
This routine is defined in the POST-SELECTION ACTION field of the PATIENT/IHS
file distributed with the PXPT package.\n
AUPNPAT ; IHS/OHPRD/EDE - POST SELECTION SETS FOR PATIENT LOOKUP ;
24-MAY-1993
;;93.2;IHS PATIENT DICTIONARIES.;;JUL 01, 1993
;
; This routine sets standard patient variables
;
START ;
S:$D(X) AUPNPATX=X
S AUPNPAT=+Y
S AUPNSEX=$P(^DPT(AUPNPAT,0),U,2),AUPNDOB=$P(^(0),U,3),AUPNDOD=""
S:$D(^(.35)) AUPNDOD=$P(^(.35),U,1)
S X2=AUPNDOB,X1=$S('AUPNDOD:DT,AUPNDOD:AUPNDOD,1:DT) D ^%DTC S
AUPNDAYS=X K X,X1,X2
S:$D(AUPNPATX) X=AUPNPATX
K %T,%Y,AUPNPATX
Q
;
KILL ; KILL VARIABLES SET BY THIS ROUTINE
K AUPNPAT,AUPNSEX,AUPNDOB,AUPNDOD,AUPNDAYS
Q\n\n
The following routine (PXPTNPAT) is a PXPT version of AUPNPAT that is being
distributed to the field. When the ZOSF("SAVE") is completed, the AUPNPAT
routine will appear as displayed above.\n\n
PXPTNPAT ; SLC/DLT - Post selection sets for Patient Lookup EXPORT
;1/22/ 94 21:03
;;1.0V1;PCE PATIENT/IHS SUBSET (PXPT);;Sept 7, 1994 AUPNPAT ;
IHS/OHPRD/EDE - POST SELECTION SETS FOR PATIENT LOOKUP ;
24-MAY-1993
;;93.2;IHS PATIENT DICTIONARIES.;;JUL 01, 1993
;
; This routine sets standard patient variables
;
START ;
S:$D(X) AUPNPATX=X
S AUPNPAT=+Y
S AUPNSEX=$P(^DPT(AUPNPAT,0),U,2),AUPNDOB=$P(^(0),U,3),AUPNDOD=""
S:$D(^(.35)) AUPNDOD=$P(^(.35),U,1)
S X2=AUPNDOB,X1=$S('AUPNDOD:DT,AUPNDOD:AUPNDOD,1:DT) D ^%DTC S
AUPNDAYS=X K X,X1,X2
S:$D(AUPNPATX) X=AUPNPATX
K %T,%Y,AUPNPATX
Q
;
KILL ; KILL VARIABLES SET BY THIS ROUTINE
K AUPNPAT,AUPNSEX,AUPNDOB,AUPNDOD,AUPNDAYS
Q\n", "", "AUPNPAT", ""], ["899", "DBIA899", "File", "ORDER ENTRY/RESULTS REPORTING", "1994/06/02", "", "Retired", "Private", "101.11", "
When OE/RR handles the prompting for generic orders,
prompts that require word processing answers store the entered text
temporarily in file 101.11 (XQOR WORD PROCESSING). The lifespan of an entry
in this file is several minutes. The Unwinder uses this file when handling
the order prompting for OE/RR. Since this file is an OE/RR file, the Unwinder
needs an integration agreement for both read and write access to this file.\n
It would be possible to move this file into the Unwinder package. However,
this portion of the Unwinder is currently used exclusively by OE/RR. Since
the portion of OE/RR that handles order dialogs is being rewritten (so OE/RR
can handle the front door), I would prefer to wait until version 3 of OE/RR
before shifting around the custody of files too much.", "", "", ""], ["900", "PSIVACT", "Routine", "INPATIENT MEDICATIONS", "1994/06/24", "APPROVED", "Active", "Controlled Subscription", "", "
Provides the subscribing package the ability to
discontinue all of a patient's IV orders.", "", "PSIVACT", ""], ["901", "PSSJEEU", "Routine", "PHARMACY DATA MANAGEMENT", "1994/06/24", "APPROVED", "Active", "Controlled Subscription", "", "
This is a set of utilities that can be used to create,
validate and process order timing schedules.", "", "PSSJEEU", ""], ["902", "PSJSV0", "Routine", "INPATIENT MEDICATIONS", "1994/06/24", "APPROVED", "Active", "Controlled Subscription", "", "
This displays help text for use when validating a
schedule. This may be used as the executable help for a field.", "", "PSJSV0", ""], ["903", "DBIA903", "File", "1", "2003/07/08", "", "Retired", "Private", "", "
Inpatient Medications version 5.0 accesses the zero
node of fields in ^DD(42, ^DD(50, ^DD(50.3, ^DD(52.6, ^DD(53.1, ^DD(55,
^DD(59, and ^DD(101,", "", "", ""], ["905", "DBIA905", "File", "ADVERSE REACTION TRACKING", "1994/07/07", "APPROVED", "Active", "Controlled Subscription", "120.8", "
This DBIA grants access to specific fields in the
PATIENT ALLERGIES FILE (120.8).", "", "?\"", ""], ["906", "DBIA906", "File", "PROGRESS NOTES", "1994/07/07", "", "Retired", "Private", "121.2", "
Health Summary is accessing file GMR(121.2, to get the
title of a progress note for displaying in the Progress Notes components.", "", "", ""], ["907", "AUPNVSIT", "Routine", "PCE PATIENT CARE ENCOUNTER", "1994/07/13", "APPROVED", "Active", "Controlled Subscription", "", "\n
Update dependent entry counter
------------------------------\n
Note: These calls are customarily done via a MUMPS cross reference on the
pointer field.", "", "AUPNVSIT", ""], ["908", "DBIA908", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "44", "
Read only access for the ^SC global.\n
Read ^SC(n,0) to obtain Hospital Location name, abbreviation and
Division.\n
Read ^SC(n,42) to obtain ward location file pointer to obtain field
#.017 Specialty in the Ward Location file #42.\n
Read ^SC("B", and ^SC("C", cross references to get patient location
internal entry #: $O(^SC("B",X,0)) and $O(^SC("C",X,0)).\n
Read access to the ^SC(D0,"I") node to obtain inactivate date
(field # 2505) and re-activate date (field # 2506).\n
Read only access to ^SC(D0,"S",D1,1,D2,0) to access patients by
clinic location and clinic date to print lab report.\n
Read only access to ^SC(D0,"S",DATE) used to check if a clinic
meets on a specified date.", "", "", ""], ["909", "DBIA909-A", "File", "REGISTRATION", "1994/07/14", "APPROVED", "Active", "Private", "45.7", "\n
The laboratory LMIP reports require that workload data be collected based on
Facility Treating Specialty #45.7 and Specialty #42.4. We determine this
information by looking at the ordering location.
We are asking permission to read the these files to obtain .01 field and the
field #6 CDR ACCOUNT field for certain reports.\n
The logic uses the ^SC(X,42) to determine if the location is a ward. If it is
the n use the Facility Treating specialty pointers to navigate to the data.
See DBIA909-B & DBIA909-C", "", "", ""], ["910", "DBIA910", "Other", "MAILMAN", "1994/07/20", "", "Retired", "Private", "", "\n\n
Lab is requesting a new domain for the purpose of uploading a monthly
laboratory workload reports to Austin. The increase in traffic should be less
than 30K per institution once per month. Typically a message is about 200
lines.\n
NAME: REDACTED FLAGS: S
RELAY DOMAIN: REDACTED DHCP ROUTING INDICATOR:LAB
PHYSICAL LINK DEVICE: MINIOUT TRANSMISSION SCRIPT: SCRIPT TEXT:", "", "", ""], ["912", "DBIA912", "File", "1", "1994/07/21", "", "Retired", "Private", "", "
^DIC("AC" - Screen lookup on files for the Lab
application group. ^DIC("AC","LR"", "", "", ""], ["913", "DBIA913", "File", "REGISTRATION", "1994/07/22", "APPROVED", "Active", "Controlled Subscription", "21", "", "", "", ""], ["915", "DBIA915", "Routine", "SOCIAL WORK", "1994/08/11", "APPROVED", "Active", "Private", "", "\n
Health Summary requests the ability to execute the ^SOWKHSUM routine.
Health Summary will have a patient DFN defined as the variable DFN upon
calling ^SOWKHSUM. ^SOWKHSUM will output the ^TMP("SOWK",$J,line number) array
which will include the Source of Referral, Source of Information, the
Social/Family Relationship segment, The Current Substance Problems segment and
the Psycho-Social Assessment segment. These segments will be formated like
their display in the Social Work Service Reports with the exception that they
will not be prefaced with a Roman Numeral.
Health Summary will export this routine in the GMTS name space and if it
doesn't exist when Health Summary is installed, the routine will be renamed to
the SOWK name space.", "", "SOWKHSUM", ""], ["916", "DBIA916", "File", "1", "1994/07/25", "APPROVED", "Active", "Controlled Subscription", "", "
The current packages subscribing to this IA are
expected to migrate to use DID calls. NO NEW FUTURE SUBSCRIBERS WILL BE
ADDED.", "", "", ""], ["917", "DBIA917", "File", "1", "1994/07/26", "", "Retired", "Private", "", "
NOTE: This DBIA has been combined into DBIA #510 and
has been retired.\n
Laboratory V 5.2 uses ^DISV(DUZ,"LRACC") and ^DISV(DUZ,"LRAN") to store items.\n
An example is in routine LRACC at line LRACC+4:\n
S:$L(X)>2 ^DISV(DUZ,"LRACC")=X S:X=" " X=$S($D(^DISV(DUZ,"LRACC")):
^("LRACC"),1:"?")\n
Lab needs an agreement for read/write access to ^DISV(DUZ,"LRACC") and
^DISV(DUZ,"LRAN")", "", "", ""], ["918", "DBIA918", "File", "REGISTRATION", "1994/07/26", "APPROVED", "Active", "Private", "2", "
Read only access for the ^DPT( global to obtain Period
of Service and POW information.\n
Read ^DPT(dfn,.52) to obtain POW information.\n
Read ^DPT(dfn,.32) to obtain Period of Service information.", "", "", ""], ["920", "DBIA920", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
Read only access for the ^PSRX(x,0) node.\n
In routines LRBLPE1 and LRBLPH:\n
...I $D(^PSRX(Y,0)) S ^TMP($J,+$P(^(0),"^",6))=O\n
We are $O(^PS(55,DFN,"P",X)) to build the ^TMP( array. We then use that array
for possible data.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["921", "DBIA921", "File", "PHARMACY DATA MANAGEMENT", "1994/07/27", "APPROVED", "Active", "Private", "52.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
Read only access for the ^PS(52.6,X,0) node.\n
In routines LRBLPE1 and LRBLPH:\n
...I $D(^PS(52.6,X,0)...W !,"IV DRUG: ",$P(^(0),"^")", "", "", ""], ["922", "DBIA922", "File", "PHARMACY DATA MANAGEMENT", "1994/07/27", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006\n
Read only access to the following nodes in the Pharmacy Patient file #55.\n
All these references are found in routines LRBLPE1 and LRBLPH.\n
^PS(55,DFN,"IV",X,"AD",Y,0)\n
K ^TMP($J) F X=0:0 S X=$O(^PS(55,DFN,"IV",X)) Q:'X!(R[U) F Y=0:0
S Y=$O(^PS(55,DFN,"IV",X,"AD",Y)) Q:'Y!(R[U) S ^TMP($J,+^(Y,0))=""\n
^PS(55,DFN,5,X,1,Y,0)\n
K ^TMP($J) F X=0:0 S X=$O(^PS(55,DFN,5,X)) Q:'X!(R[U) F Y=0:0
S Y=$O(^PS(55,DFN,X,1,Y)) Q:'Y!(R[U) S ^TMP($J,+^(Y,0)=""\n
NOTE: Inpatient Medication allows direct access to the Inpatient Medication
data, with the understanding that this structure may change in Inpatient Meds
version 5.0. If a change is necessary, Lab will need to supply a patch to call
an Inpatient utility to provide this data rather than directly accessing the
global.", "", "", ""], ["923", "DBIA923", "File", "SCHEDULING", "1994/07/28", "APPROVED", "Active", "Private", "40.7", "
The following fields are accessed in a read-only
manner:\n
^DIC( 40.7 STOP CODE file
1 AMIS REPORTING STOP CODE\n
In routines LRCAPPH line LRCAPPH+8\n
SDC S SDC=$S($P(^("NITE"),U,3):$G(^DIC(40.7,+$P(^LAB(69.9,1,"NITE"),
U,3),0)),1:"") S LRSDC=$S($P(SDC,U,2):+$P(SDC,U,2),1:108)\n
LRSTOPC line LRSTOPC+3\n
S LRSDC=$S(+$P($G(^DIC(40.7,+$P($G(^LAB(69.9,1,"NITE")),U,3),0)),U,2):
$P(^(0),U,2),1:108),CNT=0,LREND=0\n
Routine LRSTOPC manually records clinic stop codes for Lab. Routine LRCAPPH
automatically records clinic stop codes for Lab.", "", "", ""], ["924", "DBIA924", "File", "REGISTRATION", "1994/07/28", "APPROVED", "Active", "Private", "11", "
Read only access for the ^DIC(11, global.\n
In routine LRMIHDR line LRMIHDR+22:\n
I LRMARST S LRMARST=$S($D(^DIC(11,LRMARST,0)):$P(^(0),U),1:"")\n
LAB SERVICE will also use MARITAL STATUS fields in Fileman sort and print
templates.", "", "", "2010/09/01"], ["925", "DBIA925", "File", "REGISTRATION", "1994/07/28", "APPROVED", "Active", "Private", "10", "
Read only access to the ^DIC(10, global.\n
In routine LRMIHDR line LRMIHDR+21:\n
I LRRACE S LRRACE=$S($D(^DIC(10,LRRACE,0)):$P(^(0),U),1:"")\n
LAB SERVICE will use the NAME (#.01), HL7 VALUE (#3) and INACTIVE (#200)
fields in sort and print templates.", "", "", "2010/09/02"], ["927", "LIST SURGICAL OPERATIONS SCHEDULED", "File", "SURGERY", "1994/08/01", "APPROVED", "Active", "Private", "130", "
Read only access for the ^SRF global.\n\n
Routine LRBLPCSS, blood bank routine, pre-op component selection, checks for
pending operations by looping through the "ADT" Date of Operation cross
reference then lists operations scheduled. The date, operation procedure, and
planned principal procedure code is listed.", "", "", "1994/08/01"], ["928", "DBIA928", "Routine", "PROBLEM LIST", "1994/08/02", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement is to post the routine GMPLUTL as a
supported reference by controlled subscription. There are 3 entry points to
return currently active problems, add a new problem, or update an existing
problem.", "", "GMPLUTL", "2015/08/18"], ["930", "DBIA930", "File", "KERNEL", "1994/09/20", "APPROVED", "Active", "Private", "9.4", "\n\n
The Laboratory package requests agreement from the VA FileMan package to edit
the Package file (9.4) during the init process for Laboratory Version 5.2.\n
There are two sets of inits distributed with Lab V 5.2. The LR inits are the
primary inits for the release. The LA inits are for the Automated Instruments
part of the release. The LA inits are only run when the site is installing
this version in a virgin account. There are directions in the installation
guide telling the site NOT to run the inits if they overlaying version 5.2
over version 5.1. The Package file entry for Automated Instruments needs to
be updated to version 5.2, but because the inits are not run, the Package file
will not get updated.\n
We request permission to use ^DIE and ^DICN to update the following fields in
the AUTOMATED LAB INSTRUMENTS entry in the PACKAGE file.\n
VERSION (field #22, add a multiple entry)
VERSION (field #.01, sub field of #22)
DATE DISTRIBUTED (field #1, sub field of #22)
DATE INSTALLED AT THIS SITE (field #2, sub field of #22)\n
CURRENT VERSION (field #13)\n
This is a one-time request for this release of Laboratory Version 5.2.\n", "", "", ""], ["931", "DBIA931", "File", "CPT/HCPCS CODES", "1994/08/03", "", "Retired", "Private", "81", "
Direct read access to the ^ICPT( global, CPT file #81.\n
In routine LRBLPCSS, Blood Bank Pre-op Component selection,
read node ^ICPT(x,"D",z,0) to print description field.\n
In routine LRBLPOST, Blood Bank Post-init, read node ^ICPT(x,"LR"). This will
move all 66 fields to our own field in ^LAB(66.5, . This is one time for V.
5.2 installation only.", "", "", ""], ["932", "DBIA932", "File", "KERNEL", "1994/08/04", "APPROVED", "Active", "Private", "3.2", "
Permission to define a field in one of our files as a
pointer to the Terminal File.", "", "", ""], ["933", "DBIA933", "Routine", "KERNEL", "1994/08/04", "APPROVED", "Active", "Private", "", "", "", "%ZISS1", ""], ["934", "DBIA934", "Routine", "PHARMACY DATA MANAGEMENT", "1994/08/05", "APPROVED", "Active", "Private", "", "
This is for Pharmacy 6.0 and greater.", "", "PSOP", ""], ["935", "DBIA935", "File", "REGISTRATION", "1994/08/09", "APPROVED", "Active", "Private", "22", "
In Lab V 5.2 patient POW information is being obtained
from inquiries to global locations. Routines LRAPPOW and LRAPDPT reference
the global ^DIC(22, .", "", "", ""], ["936", "XUSESIG", "Routine", "KERNEL", "1994/08/11", "APPROVED", "Active", "Controlled Subscription", "", "
This routine, when called from the top, allows the user
to setup a personal electronic signature code. It is used within application
code to allow the user immediate 'on-the-fly' access to setup the electronic
signature, rather than force the user to leave the application and enter a
different option to do the same.", "", "XUSESIG", ""], ["937", "SEARCH TEMPLATE RESULTS", "File", "1", "1994/08/12", "APPROVED", "Active", "Supported", "", "\n\n
^DIBT(SORT_TEMPLATE#,1,IEN)=""\n
The 1 node indicates that the IEN list was created one of two ways:
1) The user was in FileMan INQUIRE mode, selected a number of records, and
saved the list in a template.
2) The user ran the FileMan SEARCH, either through the interactive FileMan
menu, or through the programmer entry point EN^DIS. In this case, the IEN
list is the record numbers that met the search criteria.\n
IEN - is the internal entry number of a record in the file indicated by the
4th piece of the 0 node of the template, ^DIBT(SORT_TEMPLATE#,0).\n
Read, Write, Delete access allowed.", "", "", ""], ["938", "DBIA938", "Routine", "HEALTH SUMMARY", "1994/08/16", "APPROVED", "Active", "Controlled Subscription", "", "
Entry points to use the Health Summary routine GMTSDVR
to allow users to print a Health Summary.", "", "GMTSDVR", ""], ["939", "DBIA939", "File", "HEALTH SUMMARY", "1994/08/16", "APPROVED", "Active", "Private", "142", "
Used to do a look-up to the Health Summary Type (#142)
to select a template. This agreement is tied to DBIA938.", "", "", ""], ["940", "DBIA940", "File", "HEALTH LEVEL SEVEN", "1994/08/19", "APPROVED", "Active", "Private", "772", "
The IVM package requests permission to use the HL7
TRANSMISSION (#772) file to find the mailman message number associated with an
outgoing HL7 transmission. The purpose of this reference is to use that
number to determine if the message is Awaiting Transmission.", "", "", ""], ["941", "DBIA941", "File", "HEALTH LEVEL SEVEN", "1994/08/19", "APPROVED", "Active", "Private", "771.3", "
The IVM package requests permission to store the
pointer to an entry in the HL7 SEGMENT NAME (#771.3) file in an IVM file.
Both the pointer and segment name will be stored, in the INCOMING SEGMENT
(#.01) and SEGMENT NAME (#.02) fields of the QUERY TRANSMISSION DATE/TIME
(#.05) multiple of the IVM PATIENT (#301.5) file, respectively. The pointer
to the segment name will be determined using a DIC look-up call. The segment
name will be extracted from an HL7 message segment.", "", "", ""], ["942", "DBIA942", "Other", "HEALTH LEVEL SEVEN", "1994/08/19", "APPROVED", "Active", "Private", "", "
The IVM requests permission to perform the following
actions during the initialization process of IVM v2.0:\n
1. Add the following two new segments to the HL7 SEGMENT NAME
(#771.3) file:\n
A. ABBREVIATED NAME: ZIR
FULL NAME: VA Specific Income Information VERSION: 2.1\n
B. ABBREVIATED NAME: ZIO
FULL NAME: VA Spec. Patient Information VERSION: 2.1\n
2. Update the 'IVM' entry in the HL7 DHCP APPLICATION PARAMETER
(#771) file with:\n
A. New entries in the HL7 MESSAGE (#6) multiple
B. New entries in the HL7 SEGMENT (#5) multiple", "", "", ""], ["943", "DBIA943", "Routine", "INCOME VERIFICATION MATCH", "1994/08/19", "APPROVED", "Active", "Private", "", "
IB requests an integration agreement with the IVM
package to pass billing and collections information to the IVM package.", "", "IVMUFNC3", ""], ["944", "DBIA944", "Routine", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Private", "", "
IVM files patient insurance information into DHCP which
has been received from the IVM Center. This call is used to identify a group
plan for the policy when the policy is being filed.", "", "IBCNSU", ""], ["945", "DBIA945", "Routine", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Private", "", "
IVM files patient insurance information into DHCP which
has been received from the IVM Center. This call is used to reconcile the
field COVERED BY HEALTH INSURANCE? in the PATIENT (#2) file with the
information stored in the INSURANCE TYPE multiple after the new policy
received from the IVM Center has been filed.", "", "IBCNSM31", ""], ["946", "DBIA946", "Routine", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Private", "", "
IVM files patient insurance information into DHCP which
has been received from the IVM Center. This routine is used to invoke the IB
Insurance Event Driver after a new patient policy which has been received from
the IVM Center is filed.", "", "IBCNSEVT", ""], ["947", "DBIA947", "Routine", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Private", "", "
These routine calls are used by the IVM package to
retrieve IVM-related billing and collections information from IB to transmit
to the IVM Center.", "", "IBAMTV4", ""], ["948", "DBIA948", "Other", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Private", "", "
This agreement is to request approval to perform the
following activities when installing IVM v2.0:\n
1. Export the PATIENT (#.02) and STATUS (#.05) fields of the
INTEGRATED BILLING ACTION (#350) file with the release.\n
2. Export the options IB MT ON HOLD MENU and IB MT REV PEND CHARGES
with the release.\n
3. Export the List Templates (in file #409.61) IB MT REVIEW INDIV CHARGES
and IB MT REVIEW PATIENT with the release.\n
4. Export the following IB protocols with this release:\n
- IBAMTV REV PASS CHARGE
- IBAMTV REV CANC CHARGE
- IBAMTV REV IND CHARGES
- IBAMTV SEL PATIENT
- IBAMTV REV PATIENT\n
5. Attach the IVM protocol IVM INSURANCE EVENT to the IB protocol
IBCN NEW INSURANCE EVENTS.\n
6. Add the new entry HOLD - REVIEW to the IB ACTION STATUS (#350.21)
file.", "", "", ""], ["949", "DBIA949", "File", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Private", "36", "
IVM files patient insurance information into DHCP which
has been received from the IVM Center. To file a complete policy, it may be
necessary to add entries to the INSURANCE COMPANY (#36) file.", "", "", ""], ["950", "DBIA950", "File", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Controlled Subscription", "2", "
IVM files patient insurance information into DHCP which
has been received from the IVM Center. The patient policy is filed in the
PATIENT (#2) file.\n
Update: IB*2*497 increased the length of the SUBSCRIBER ID field and the NAME
OF INSURED field to support the EDI New Standards and Operating Rules for VHA
providers. This required length increase made it necessary to move the
location of these 2 fields to new Data Dictionary nodes in the INSURANCE TYPE
sub-file. To support this implementation, all subscribers to this ICR will
need to make the necessary changes in their applications to reference the new
fields and remove the references to the old fields. When all subscribers have
implemented the use of the new fields, the old fields will be deleted with a
IB*2*518. Old and new fields are noted in the field list detail of this ICR.", "", "", "2014/02/21"], ["951", "DBIA951", "File", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Controlled Subscription", "355.1", "
IVM files patient insurance information into DHCP which
has been received from the IVM Center. The type of plan is received from the
IVM Center with the policy. This value points to the TYPE OF PLAN (#355.1)
file and must be filed in the GROUP INSURANCE PLAN (#355.3) file.", "", "", ""], ["952", "DBIA952", "File", "INTEGRATED BILLING", "1994/08/19", "APPROVED", "Active", "Private", "355.3", "
IVM files patient insurance information into DHCP which
has been received from the IVM Center. This involves potentially filing a new
entry in the GROUP INSURANCE PLAN (#355.3) file.", "", "", ""], ["954", "DBIA954", "Routine", "IFCAP", "1994/08/19", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PRCSREC2", ""], ["955", "DBIA955", "Other", "REGISTRATION", "1994/08/21", "APPROVED", "Active", "Private", "", "
The IVM package requests permission to perform the
following actions during the initialization of IVM v2.0:\n
1. Export the following fields/files:\n
a. The SOCIAL SECURITY NUMBER (#.09) field of the INCOME PERSON
(#408.13) file.\n
b. The following fields in the ANNUAL MEANS TEST (#408.31) file:
DATE/TIME COMPLETED (#.07)
DATE VETERAN SIGNED TEST (#.24)
HARDSHIP? (#.2)
PRIMARY INCOME TEST FOR YEAR? (#2)
SOURCE OF INCOME TEST (#.23)
DATE IVM VERIFIED MT COMPLETED (#.25)
REFUSED TO SIGN (#.26)\n
c. The SOURCE OF INCOME TEST (#408.34) file, with data.\n
d. The following fields of the MEANS TEST CHANGES (#408.41)
file:
OLD SOURCE OF INCOME TEST (#.08)
NEW SOURCE OF INCOME TEST (#.09)\n
2. Export the input template DGMT UPDATE AUDIT.\n
3. Export the following PIMS routines:
DGMTA DGMTAUD DGMTAUD1 DGMTCOU1 DGMTDD DGMTDD2 DGMTDEL DGMTE
DGMTEO DGMTO1 DGMTOFA1 DGMTOPYT DGMTOREQ DGMTP4 DGMTSCC DGMTU
DGMTU11 DGMTU2 DGMTU21 DGMTU22 DGMTU23 DGMTU3 DGMTUB DGMTV
DGPTUTL1 DGRPU VAFHLFNC VAFHLZDP VAFHLZGD VAFHLZIR VAFHLZMT\n
4. Add the new entries 'MEANS TEST UPLOAD' and 'UPLOADED MEANS TEST
DELETION' to the MEANS TEST CHANGES TYPE (#408.42) file.\n
5. Update the field SOURCE OF INCOME TEST (#.23) to 'VAMC' and the
field PRIMARY INCOME TEST FOR YEAR? (#2) to 'YES' for every
entry in the ANNUAL MEANS TEST (#408.31) file.", "", "", ""], ["956", "DBIA956", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Under Revision", "Private", "", "
The IVM package requests use of the function
$$EN^VAFHLZIR to extract veteran income relation data to transmit to the IVM
Center.\n
The Ambulatory Care Database Project requests use of the function
$$EN^VAFHLZIR to extract veteran income relation data to transmit to NPCDB.", "", "VAFHLZIR", ""], ["957", "DBIA957", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "", "
The IVM package files new entries in the ANNUAL MEANS
TEST (#408.31) file. This call is used to create a stub entry in that file.", "", "DGMTA", ""], ["958", "DBIA958", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "", "
After IVM adds a new Means Test to the PIMS database,
the Means Test Event Driver must be invoked. These calls to DGMTEVT are used
to invoke that event driver.", "", "DGMTEVT", ""], ["959", "DBIA959", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "", "
The IVM package adds new Means Tests into the PIMS
Means Test module. In order to calculate the correct category for these
tests, a call to PAR^DGMTSCU is made to retrieve the Means Test threshold
figures for the correct year.", "", "DGMTSCU", ""], ["960", "DBIA960", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "", "
The IVM package adds Means Tests to the PIMS Means Test
module. This call is used to calculate the Means Test category once a
veteran's Means Test, income, and income relations information is filed.", "", "DGMTSCU2", ""], ["961", "DBIA961", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "", "
The IVM package needs to extract Social Security
numbers for a veteran's spouse. The function call $$DEM^DGMTU1 is used to
retrieve the zeroth node of the PATIENT (#2) or INCOME PERSON (#408.13) for
the spouse.", "", "DGMTU1", ""], ["962", "DBIA962", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Other", "Private", "", "
The IVM package files new Means Tests into the PIMS
Means Test module. The routine DGMTU11 is used to retrieve active dependent
information and update the veteran's income relation record with that data.", "", "DGMTU11", ""], ["963", "DBIA963", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "", "
The IVM package files new Means Tests into the PIMS
Means Test module. As such, income and income relations records must be filed
in files #408.21 and #408.22, respectively. Two function calls to routine
DGMTU2 are made to add stub entries to these files.", "", "DGMTU2", ""], ["964", "DBIA964", "File", "SCHEDULING", "2004/10/26", "APPROVED", "Active", "Private", "44", "
The IVM package requests direct access to the field
NON-COUNT CLINIC? (#2502) in the HOSPITAL LOCATION (#44) file. The field is
used to determine whether an outpatient encounter in a specific clinic is
potentially billable for Means Test billing.", "", "", ""], ["965", "DBIA965", "Routine", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "", "
The IVM packages files new Means Tests in the PIMS
Means Test module. Part of that process is to find income records for
specific patient relations. The call to DGMTU3 is used to find the veteran's
own income record.", "", "DGMTU3", ""], ["966", "DBIA966", "File", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Controlled Subscription", "405", "
The IVM package needs to determine the last date that a
veteran was treated at a specific facility. The "ATID3" cross-reference in
the PATIENT MOVEMENT (#405) file is used to determine the patient's last
discharge date.", "", "", ""], ["967", "DBIA967", "File", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "2", "
The IVM package requests permission to directly access
and file various fields in the PATIENT (#2) file.", "", "", ""], ["968", "DBIA968", "File", "REGISTRATION", "1994/08/22", "APPROVED", "Active", "Private", "408.31", "
The IVM package files new Means Tests in the PIMS Means
Test module. IVM requests permission to add new entries into the ANNUAL MEANS
TEST (#408.31) file, and to update several fields in that file. Additionally,
permission is requested to delete entries from that file (if the IVM Center
mistakenly sends a Means Test to a facility).", "", "", ""], ["969", "DBIA969", "File", "REGISTRATION", "1994/08/22", "APPROVED", "Other", "Private", "408.12", "
The IVM package files new Means Tests in the PIMS Means
Test module. IVM requests permission to add and update entries in the PATIENT
RELATION (#408.12) file, as part of adding a new Means Test. Additionally,
permission is requested to delete entries from that file (if the IVM Center
mistakenly sends a Means Test to a facility).", "", "", ""], ["970", "DBIA970", "File", "REGISTRATION", "1994/08/22", "APPROVED", "Other", "Private", "408.13", "
The IVM package files new Means Tests in the PIMS Means
Test module. IVM requests permission to add and update entries in the INCOME
PERSON (#408.13) file, as part of adding a new Means Test. Additionally,
permisssion is requested to delete entries from that file (if the IVM Center
mistakenly sends a Means Test to a facility).", "", "", ""], ["971", "DBIA971", "File", "REGISTRATION", "1994/08/22", "", "Pending", "Private", "408.21", "
The IVM package files new Means Tests in the PIMS Means
Test module. IVM requests permission to add and update entries in the
INDIVIDUAL ANNUAL INCOME (#408.21) file, as part of adding a new Means Test.
Additionally, permission is requested to delete entries from that file (if the
IVM Center mistakenly sends a Means Test to a facility).", "", "", ""], ["972", "DBIA972", "File", "REGISTRATION", "1994/08/22", "APPROVED", "Other", "Private", "408.22", "
The IVM package files new Means Tests in the PIMS Means
Test module. IVM requests permission to add and update entries in the INCOME
RELATION (#408.22) file, as part of adding a new Means Test. Additionally,
permission is requested to delete entries from that file (if the IVM Center
mistakenly sends a Means Test to a facility).", "", "", ""], ["973", "DBIA973", "File", "KERNEL", "1994/09/23", "APPROVED", "Active", "Private", "200", "
Used to screen out inactive providers.\n
Below is a listing of files and fields that will be referencing the inactive
provider field in 200, indirectly. Routine DGPMDD references the data. The
fields contain an extrensic function for screening,
$$SCREEN^DGPMDD(ien,da,date) and a call to HELP^DGPMDD(da,date) for executable
help.
=====================================================================\n\n
File 405 - Patient Movement
*Field .08 - PRIMARY CARE PHYSICIAN
*Field .19 - ATTENDING PHYSICIAN
File 2 - Patient
Field .104 - PROVIDER
Field .1041 - ATTENDING PHYSICIAN
File 41.1 - Scheduled Admission
Field 5 - PROVIDER
File 45 - PTF (Subfile 45.02, 50)
Field 24 - PROVIDER
File 45.7 - FACILITY TREATING SPECIALTY (Subfile 45.701, 10)
Field .01 - PROVIDERS", "", "", ""], ["974", "DBIA974", "Routine", "REGISTRATION", "1994/08/23", "APPROVED", "Active", "Controlled Subscription", "", "
IVM requests permission to make the function call
$$MTS^DGMTU in order to determine the Means Test status, given a pointer to
the status in the MEANS TEST STATUS (#408.32) file.", "", "DGMTU", ""], ["975", "DBIA975", "File", "1", "1994/08/29", "APPROVED", "Active", "Private", "1.5", "
This integration agreement permits LetterMan to install
and reference the WORD LIST file #1.5 stored in global ^DIW(1.5,. The WORD
LIST file is used by the LetterMan spell checker.", "", "", ""], ["976", "DBIA976", "File", "KERNEL", "1994/08/29", "APPROVED", "Active", "Private", "200", "
This integration agreement permits LetterMan to
distribute and add/edit data in the fields in the range of 8983 to 8984 in the
NEW PERSON FILE #200.\n
The following is a standard data dictionary listing of the fields:\n\n
200,8983.11 DISPLAY HELP AT ENTRY TO LM LM;1 SET
'y' FOR YES;
'n' FOR NO;
LAST EDITED: JAN 26, 1990
HELP-PROMPT: Enter yes to display the help text before
entering the editor.
DESCRIPTION: If set to yes, a help text will be displayed
before entering the editor. This is used
primarily for new users.\n\n
200,8983.12 ASK TERMINAL TYPE AT LM ENTRY LM;2 SET
'y' FOR YES;
'n' FOR NO;
HELP-PROMPT: Enter yes to ask the terminal type upon entry
to the editor.
DESCRIPTION: If set to yes, the terminal type will be asked
upon entry to the editor.\n\n
200,8983.13 DEFAULT TERMINAL TYPE FOR LM LM;3 POINTER TO TERMINAL TYPE FILE
(
#3.2)
LAST EDITED: JAN 26, 1990
DESCRIPTION: This field stores the default terminal type
for
a user.\n\n
200,8983.14 DISPLAY LM COMMANDS LM;4 SET
'y' FOR YES;
'n' FOR NO;
LAST EDITED: JAN 26, 1990
HELP-PROMPT: Enter yes to display the list of commands when
entering the command mode.
DESCRIPTION: If set to yes, the list of commands will be
displayed at the bottom of the screen when
entering the command mode.\n\n
200,8983.15 BRIGHT CHARS AT EXIT FROM LM LM;5 SET
'y' FOR YES;
'n' FOR NO;
LAST EDITED: JAN 26, 1990
HELP-PROMPT: Enter yes to leave the terminal in high
intensity after exiting LetterMan.
DESCRIPTION: If set to yes, the terminal will be left in
high intensity after exiting.\n\n
200,8983.16 DATE LAST ACCESSED LM WP LM;6 DATE
INPUT TRANSFORM: S %DT="ETR" D ^%DT S X=Y K:Y<1 X
LAST EDITED: JAN 28, 1990
DESCRIPTION: The date and time a user last accessed the
LetterMan word processor document editor.\n\n
200,8983.17 TOTAL MINUTES USING LM WP LM;7 NUMBER
INPUT TRANSFORM: K:+X'=X!(X>999999999)!(X<0)!(X?.E1"."1N.N) X
LAST EDITED: JAN 28, 1990
HELP-PROMPT: Enter the total minutes spent using the
LetterMan Word Processor (Editor), from 0 to
999999999.
DESCRIPTION: The total minutes a user has used the
LetterMan
word processor document editor.\n\n
200,8983.18 KEYSTROKES FROM LM WP LM;8 NUMBER
INPUT TRANSFORM: K:+X'=X!(X>999999999)!(X<0)!(X?.E1"."1N.N) X
LAST EDITED: JAN 28, 1990
HELP-PROMPT: Enter the total number of keystrokes a user
has
typed from the word processor document editor,
from 0 to 999999999.
DESCRIPTION: This field stores the total number of
keystrokes a user has typed from the word
processor document editor.\n\n
200,8983.5 SPELLING EXCEPTION DICTIONARY LM1;0 Multiple #200.0089831
DESCRIPTION: This field stores the exception spelling
dictionary for the user.\n\n
200.0089831,.01 WORD 0;1 FREE TEXT (Multiply asked)
INPUT TRANSFORM: K:$L(X)>30!($L(X)<1) X I $D(X),X'?.L,X'["-"
K
X
LAST EDITED: JAN 26, 1990
HELP-PROMPT: Enter the WORD which should be checked by
the
spelling checker, from 1 to 30 lower case
characters including '-'.
DESCRIPTION: This field stores words which will be
checked
when spell checking a document.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 200.0089831^B
1)= S
^VA(200,DA(1),"LM1","B",$E(X,1,30),DA)=
""
2)= K ^VA(200,DA(1),"LM1","B",$E(X,1,30),DA)\n\n
200.0089831,1 ITS A WORD ? 0;2 SET
'y' FOR YES;
LAST EDITED: MAY 4, 1992
CROSS-REFERENCE: 200.0089831^AW^MUMPS
1)= S
^VA(200,DA(1),"LM1","AW",$P(^VA(200,DA(
1),"LM1",DA,0),"^"),DA)=""
2)= K
^VA(200,DA(1),"LM1","AW",$P(^VA(200,DA(
1),"LM1",DA,0),"^"),DA)
This cross reference is used to identify the
entry in the exception dictionary as a
word.\n\n
200.0089831,2 ITS NOT A WORD ? 0;3 SET
'y' FOR YES;
LAST EDITED: MAY 4, 1992
CROSS-REFERENCE: 200.0089831^AN^MUMPS
1)= S
^VA(200,DA(1),"LM1","AN",$P(^VA(200,DA(
1),"LM1",DA,0),"^"),DA)=""
2)= K
^VA(200,DA(1),"LM1","AN",$P(^VA(200,DA(
1),"LM1",DA,0),"^"),DA)
This cross reference is used to identify the
entry in the exception dictionary as a
non-word.\n\n
200,8983.51 DEFINED FORMATS FOR LM LM2;0 Multiple #200.0089832
DESCRIPTION: This field is used to store predefined format
lines which a user can select from during
editing.\n\n
200.0089832,.01 NUMBER 0;1 NUMBER (Multiply asked)
INPUT TRANSFORM: K:+X'=X!(X>9999999)!(X<1)!(X?.E1"."1N.N) X
LAST EDITED: JAN 26, 1990
HELP-PROMPT: Enter the number of the predefined format
line, from 1 to 9999999.
DESCRIPTION: This is the reference number to the
predefined format line.
CROSS-REFERENCE: 200.0089832^B
1)= S
^VA(200,DA(1),"LM2","B",$E(X,1,30),DA)=
""
2)= K ^VA(200,DA(1),"LM2","B",$E(X,1,30),DA)\n\n
200.0089832,1 DEFAULT 0;2 SET
'y' FOR YES;
'n' FOR NO;
LAST EDITED: JAN 26, 1990
HELP-PROMPT: Enter yes to use this format line when you
enter the screen editor.
DESCRIPTION: If set to yes, this format line will be used
as the default format line when using the
screen editor. If a document already has a
format line defined, then the document
format
will be used.
CROSS-REFERENCE: 200.0089832^AC
1)= S
^VA(200,DA(1),"LM2","AC",$E(X,1,30),DA)
=""
2)= K
^VA(200,DA(1),"LM2","AC",$E(X,1,30),DA)\n\n
200.0089832,2 FORMAT LINE 0;3 FREE TEXT
INPUT TRANSFORM: K:$L(X)>79!($L(X)<1) X I $D(X) S
%=X,X="WPSEF
ORM" X ^%ZOSF("TEST") K X I $T S X=% D
CHECK^
WPSEFORM
LAST EDITED: MAR 23, 1992
HELP-PROMPT: The format line should contain dots '.'
representing spaces or 'T' representing tab
or indent markers followed by a '<'
indicating the end of the right margin.
DESCRIPTION: This field stores the predefined format
lines
of the user.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER\n\n
200,8983.52 DEFINED PHRASES FOR LM LM3;0 Multiple #200.0089833
DESCRIPTION: This field stores predefined phrases which can
be inserted into the document during editing.\n\n
200.0089833,.01 KEYWORD 0;1 FREE TEXT (Multiply asked)
INPUT TRANSFORM: K:$L(X)>50!($L(X)<1) X
LAST EDITED: JAN 26, 1990
HELP-PROMPT: Enter the keyword used to select this
phrase,
from 1 to 50 characters.
DESCRIPTION: The predefined phrase 'keyword' used to
select the phrase.
CROSS-REFERENCE: 200.0089833^B
1)= S
^VA(200,DA(1),"LM3","B",$E(X,1,30),DA)=
""
2)= K ^VA(200,DA(1),"LM3","B",$E(X,1,30),DA)\n\n
200.0089833,1 PHRASE 1;0 WORD-PROCESSING #200.00898331 (NO
WRAP)
DESCRIPTION: The phrase to be inserted into the document.\n\n
200,8983.6 LM LIMIT WP FIELDS TO EDIT LM4;0 Multiple #200.0089834
DESCRIPTION: This field is used by the user to limit which
word processing fields should be edited by
LetterMan.\n\n
200.0089834,.01 LM LIMIT WP FIELDS TO EDIT 0;1 FREE TEXT (Multiply asked)
Limited Word-Processing Fields to Edit
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X)
K:$L(X)>150!($L
(X)<4) X I $D(X) S %=X,X="WPSEFM" X
^%ZOSF("T
EST") K X I $T S X=% D SCREEN^WPSEFM
LAST EDITED: DEC 12, 1990
HELP-PROMPT: Answer must be 4-150 characters in length.
EXECUTABLE HELP: S X="WPSEHELP" X ^%ZOSF("TEST") I $T D
FMHELP
^WPSEHELP
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 200.0089834^B
1)= S
^VA(200,DA(1),"LM4","B",$E(X,1,30),DA)=
""
2)= K ^VA(200,DA(1),"LM4","B",$E(X,1,30),DA)", "", "", ""], ["977", "DBIA977", "File", "KERNEL", "1994/08/29", "", "Pending", "Private", "19", "
This integration agreement permits IFCAP to remove
entries from the OPTION file (#19) until the release and availability of KIDS.\n", "", "", ""], ["978", "DBIA978", "File", "KERNEL", "1994/08/30", "APPROVED", "Active", "Private", "3.2", "
This integration agreement allows IFCAP to lookup data
in the TERMINAL TYPE File #3.5. The lookups are direct global references
(^%ZIS(2,IOST(0),node)).\n
The agreement is established since the routine %ZISS does not return the
values for the fields above. In a future version of %ZISS, the fields 60 and
61 could be included since the bar code fields can be turned on/off by writing
the value of the field (i.e. W ^%ZIS(2,IOST(0),"BAR1")).\n
The routine %ZISS could also return the field values for opening and closing
the printer port providing the field value returned is in its executable form
(i.e. X ^%ZIS(2,IOST(0),10)).", "", "", ""], ["979", "DBIA979", "File", "KERNEL", "1994/08/30", "APPROVED", "Active", "Private", "3.5", "
This integration agreement allows LetterMan to lookup
terminal type attributes from the TERMINAL TYPE File #3.5 using direct global
references. One option in LetterMan will automatically set up the terminal
type to be used with LetterMan.\n
In the next version of LetterMan, it will migrate to using the %ZISS routine
to return the attributes. There are approximately 15 attributes used by
LetterMan. Half of the attributes will be converted from executable code to
writeable attributes (as returned by %ZISS).", "", "", ""], ["980", "PSODISP", "Routine", "OUTPATIENT PHARMACY", "1994/08/30", "APPROVED", "Active", "Private", "", "
To display help at the prescription selection prompt.", "", "PSODISP", ""], ["981", "PSOFUNC", "Routine", "OUTPATIENT PHARMACY", "1994/08/30", "APPROVED", "Active", "Private", "", "
To determine the status of a prescription", "", "PSOFUNC", ""], ["982", "PSOLSET", "Routine", "OUTPATIENT PHARMACY", "1994/08/30", "APPROVED", "Active", "Private", "", "
To kill Outpatient variables.", "", "PSOLSET", ""], ["983", "PSOCSRL", "Routine", "OUTPATIENT PHARMACY", "1994/08/30", "APPROVED", "Active", "Private", "", "
To release prescriptions from a vault.", "", "PSOCSRL", ""], ["984", "MED ROUTES", "File", "PHARMACY DATA MANAGEMENT", "1994/08/30", "", "Pending", "Controlled Subscription", "51.2", "", "", "", ""], ["985", "RX PATIENT STATUS", "File", "OUTPATIENT PHARMACY", "1994/08/30", "", "Pending", "Controlled Subscription", "53", "", "", "", ""], ["986", "DBIA986", "File", "OUTPATIENT PHARMACY", "1994/08/30", "APPROVED", "Active", "Private", "52", "
For the Controlled Substances/Outpatient interface,
read access is required for several fields in the PRESCRIPTION file.", "", "", ""], ["987", "DBIA987", "File", "1", "1994/09/26", "APPROVED", "Active", "Private", "", "
The Laboratory package Version 5.2 requests agreement
from the VA FileMan package to modify the B cross-references in the LABORATORY
TEST FILE #60
and the WKLD CODE FILE #64 to be greater than 30 characters. The first 30
characters are quite frequently the same for more than one test or workload
code.\n
^DD(60,.01,1,1,1)=S ^LAB(60,"B",$E(X,1,40),DA)=""\n
^DD(64,.01,1,1,1)=S ^LAM("B",$E(X,1,60),DA)=""\n
^DD(64.061,.01,1,1,1)=^LAB(64.061,"B",$E(X,1,50),DA)", "", "", ""], ["988", "LIBRARY USE OF VENDOR FILE", "File", "IFCAP", "1994/09/26", "APPROVED", "Retired", "Private", "440", "\n
************************************************************************
The Library package was decommissioned with LBR*2.5*15. This ICR was retired
with the release of the Library patch.
************************************************************************", "", "", ""], ["990", "DBIA990-A", "File", "SURGERY", "1994/09/30", "APPROVED", "Active", "Controlled Subscription", "130", "", "", "", ""], ["991", "DBIA990-B", "File", "SURGERY", "1994/09/30", "APPROVED", "Active", "Controlled Subscription", "137.45", "", "", "", ""], ["992", "DBIA990-C", "Routine", "SURGERY", "1994/09/30", "APPROVED", "Active", "Controlled Subscription", "", "
Routine: PRCPCSOR:
1. Call the routine ^SROPS to lookup the
patient and scheduled operation.", "", "SROPS", ""], ["993", "DBIA993-A", "File", "REGISTRATION", "1994/09/30", "", "Retired", "Private", "45", "", "", "", ""], ["994", "DBIA993-B", "File", "REGISTRATION", "1994/09/30", "APPROVED", "Active", "Controlled Subscription", "45.84", "\n\n
Used to check and make sure the PTF record has not been closed out.", "", "", ""], ["995", "DBIA995", "File", "PHARMACY DATA MANAGEMENT", "1994/08/31", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
Read only access to the following nodes in the Pharmacy Patient file #55.\n
This reference is found in routines LRBLPE1 and LRBLPH.\n
^PS(55,DFN,"P",X,0)\n
F X=0:0 S X=$O(^PS(55,DFN,"P",X)) Q:'X I $D(^(X,0)) S Y=+^(0)
I $D(^PSRX(Y,0))...", "", "", ""], ["996", "DBIA118-D", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1994/08/31", "APPROVED", "Active", "Controlled Subscription", "72", "
These look fine for the current field version (4.0) of
Radiology. There are a few cautions for you when we release Radiology/Nuclear
Medicine Version 4.5. These things may have no affect on you whatsoever, but
you need to know so you can make your own judgement:
a) Currently the exam statuses (file 72) each can be used for any
exam regardless of imaging type. In Version 4.5, exam statuses
will be specific to imaging type. We are adding the basic statuses
(WAITING FOR EXAM, CALLED FOR EXAM, EXAMINED, CANCELLED, COMPLETE)
to this file for each of the 8 imaging types. (i.e. there will be an
EXAMINED status for General Radiology, an EXAMINED status for
Nuclear Med, an EXAMINED status for Ultrasound , etc.. so that
each imaging department can set up their exam status parameters
differently.)
b) Because of item a above, the 'B' cross-reference on file 72
becomes much less meaningful - there will now be 8 instances of
each of the basis exam statuses. This may affect the proposed DBIA.
Since the sites can add their own site-specific statuses, it's
possible to have many instances of any status. So, the 'B' x-ref no
longer represents a unique status name.", "", "", ""], ["997", "DBIA997", "File", "REGISTRATION", "1994/08/31", "APPROVED", "Active", "Controlled Subscription", "42.4", "", "", "", ""], ["998", "DBIA998", "File", "REGISTRATION", "1994/08/31", "APPROVED", "Active", "Controlled Subscription", "2", "", "", "", ""], ["999", "DBIA999", "File", "1", "1994/09/02", "APPROVED", "Active", "Controlled Subscription", "", "
Read only access for the ^DD( Global.\n
$O(^DD(FN,"GL",subscript,piece,0)) to get the field #.\n
Read ^DD(FN,FLD,0), Custodial files only, where FN is a file #
and FLD is a field #, to obtain the field name, the set of codes,
or the input transform.", "", "", ""], ["1002", "DBIA1002", "File", "SURGERY", "2005/06/20", "", "Retired", "Private", "137.45", "
The following reference will be made from the QIP3SR*
routines which, while belonging to the QIP namespace, will be maintained by
the Surgery developers. Coordination of release and patches will be through
the QIP custodial ISC.", "", "", ""], ["1003", "Scheduled Admission DBIA", "File", "REGISTRATION", "1994/09/13", "APPROVED", "Active", "Private", "41.1", "
The health summary package needs to set up a DBIA to
access Registration data in the Scheduled Admission File. We need to have read
only access on the cross reference ^DGS(41.1,"B",Patient DFN,Internal Entry #
in File 41.1) to check if any scheduled admissions exist for a given patient
and to find the record number in file 41.1. A call will then be issued to
EN^DIQ1 after setting DA=Internal entry in file 41.1, DIC=41.1, and
DR="2:6;8:10;13;17". We need read only data on the following fields in file
41.1:\n
2 - Reservation Date/Time
3 - Length of Stay Expected
4 - Admitting Diagnosis
5 - Provider
6 - Surgery
8 - Ward
9 - Treating Specialty
10 - Ward or Treating Specialty
13 - Date/Time Cancelled
17 - Admitted", "", "", ""], ["1004", "DBIA1004", "File", "INDIAN HEALTH SERVICE", "1994/09/24", "APPROVED", "Active", "Private", "9999999.06", "
The PCE Patient/IHS Subset Package (PXPT) requests a
file DBIA to distribute a partial definition of the Indian Health Services
Location File (9999999.06) in the VA.\n
The PXPT Post Installation routine will populate this Location File with
dinumed entries from the Institution File (4).\n
The description for this file is very specific about going through the IHS DBA
for any changes. The IHS DBA proposed that the VA should use the dinumed
Institution entries, and not distribute required IHS fields.\n
The following data dictionary definition represents the subset of the Location
File to be distributed by PXPT:\n
STANDARD DATA DICTIONARY #9999999.06 -- LOCATION FILE 09/6/94 PAGE 1
STORED IN ^AUTTLOC( (251 ENTRIES) SITE: SLC UCI: DVA,DEV\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
---------------------------------------------------------------------------
This file contains the IHS Standard Facilities and their Associated codes, CHS
Vendors, pointers to their respective service units and areas, a 2-4 character
abbreviation, and the highest medical record number assigned by that facility.\n
Changes to this data dictionary should be coordinated thru the IHS DBA.\n
This file reflects entries in the IHS Standard Code Book, section VIII-C Area
- Service Unit - Facility. Local additions or modifications should not be
made. Monthly updates (if required) are provided by the IHS DBA thru the
patch module.\n\n
DD ACCESS: @
DEL ACCESS: @
AUDIT ACCESS: @\n
IDENTIFIED BY:\n
POINTED TO BY: DEFAULT INSTITUTION field (#.04) of the VISIT TRACKING
PARAMETERS File (#150.9)
HEALTH RECORD FAC field (#.01) of the HEALTH RECORD NO.
sub-field (#9000001.41) of the PATIENT/IHS File
(#9000001)
LOC. OF ENCOUNTER field (#.06) of the VISIT File (#9000010)
FACILITY field (#.06) of the PROBLEM File (#9000011)
NOTE FACILITY field (#.01) of the NOTE FACILITY sub-field
(#9000011.11) of the PROBLEM File (#9000011)
SITE field (#.01) of the PCC MASTER CONTROL File (#9001000)
LOCATION field (#.03) of the TAXONOMY File (#9002226)
LOCATION OF ENCOUNTER field (#.18) of the TAXONOMY File
(#9002226)\n\n
CROSS REFERENCED BY: NAME(B)\n\n
9999999.06,.01NAME 0;1 POINTER TO INSTITUTION FILE (#4)
(Required)\n
INPUT TRANSFORM: S:$D(X) DINUM=X
LAST EDITED: APR 2, 1986
DESCRIPTION: This field points to the Institution file
(#4) and has the same internal number as
that file. Thus, the location has the same
name as the Institution file (#4). The
location is also referred to as the
Facility.\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER\n
CROSS-REFERENCE: 9999999.06^B
1)= S ^AUTTLOC("B",$E(X,1,30),DA)=""
2)= K ^AUTTLOC("B",$E(X,1,30),DA)\n\n\n
FILES POINTED TO FIELDS\n
INSTITUTION (#4) NAME (#.01)\n\n
INPUT TEMPLATE(S):\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):\n", "", "", ""], ["1005", "DBIA1005", "File", "INDIAN HEALTH SERVICE", "1994/09/24", "APPROVED", "Active", "Private", "9999999.27", "
The PCE Patient/IHS Subset package (PXPT) requests a
DBIA to distribute the Indian Health Services Provider Narrative File
(9999999.27) in the VA.\n
There have been two new fields added by the VA on the 757 node. These two
fields are used for 1)documenting the clinical lexicon which could be used to
represent the provider narrative, and 2) determining the context of the
narrative when it was entered into the Provider Narrative File. The
originating file will be populated by the VA Problem List and PCE. The
clinical lexicon field will be populated in the future as provider narratives
get mapped to clinical lexicon expressions.\n
STANDARD DATA DICTIONARY #9999999.27 -- PROVIDER NARRATIVE FILE 09/14/94
PAGE 1 STORED IN ^AUTNPOV( (275 ENTRIES) SITE: SLC UCI: DVA,DEV (VERSION
93.2)\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
--------------------------------------------------------------------------
This file contains each unique POV NARRATIVE QUALIFIER.\n\n
DD ACCESS: @
DEL ACCESS: @
AUDIT ACCESS: @\n\n
POINTED TO BY: PROVIDER NARRATIVE field (#.04) of the V POV File
(#9000010.07)
PROVIDER NARRATIVE CATEGORY field (#80201) of the V POV
File (#9000010.07)
PROVIDER NARRATIVE field (#.04) of the V PROCEDURE File
(#9000010.08)
PROVIDER NARRATIVE field (#.06) of the V TREATMENT File
(#9000010.15)
PROVIDER NARRATIVE CATEGORY field (#80201) of the V
TREATMENT File (#9000010.15)
PROVIDER NARRATIVE field (#.04) of the V CPT File
(#9000010.18)
PROVIDER NARRATIVE CATEGORY field (#80201) of the V CPT
File (#9000010.18)
PROVIDER NARRATIVE field (#.05) of the PROBLEM File
(#9000011)
PROVIDER NARRATIVE field (#.04) of the PERSONAL HISTORY
File (#9000013)
PROVIDER NARRATIVE field (#.04) of the FAMILY HISTORY File
(#9000014)\n\n
CROSS REFERENCED BY: NARRATIVE(B), MNEMONIC(B)\n\n
9999999.27,.01NARRATIVE 0;1 FREE TEXT (Required)\n
INPUT TRANSFORM: K:$L(X)>80!($L(X)<2)!'(X'?1P.E)!(X'?.ANP)
X
LAST EDITED: JUL 20, 1987
HELP-PROMPT: ANSWER MUST BE 2-80 CHARACTERS IN LENGTH
DESCRIPTION: This is the Narrative that the provider
has written out that is his description of
what he treated the patient for.\n
Enter a 2 to 80 character description.
CROSS-REFERENCE: 9999999.27^B
1)= S ^AUTNPOV("B",$E(X,1,30),DA)=""
2)= K ^AUTNPOV("B",$E(X,1,30),DA)\n\n
9999999.27,8801MNEMONIC 88;1 FREE TEXT\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>2!($
LAST EDITED: DEC 16, 1985
HELP-PROMPT: ANSWER MUST BE 1-2 CHARACTERS IN LENGTH
DESCRIPTION: This is a mnemonic that stands for this
provider narrative.\n
Enter a 1-2 character mnemonic. Enter a
1-2 character mnemonic.\n
CROSS-REFERENCE: 9999999.27^B^MNEMONIC
1)= S ^AUTNPOV("B",$E(X,1,30),DA)=1
2)= K ^AUTNPOV("B",$E(X,1,30),DA)\n\n
9999999.27,75701CLINICAL LEXICON 757;1 POINTER TO
EXPRESSIONS FILE (#757.01)\n
LAST EDITED: MAY 25, 1994
DESCRIPTION: This is the clinical expression related to
the provider narrative.\n
TECHNICAL DESCR: This field will be primarily populated by
the Problem List package.\n\n
9999999.27,75702ORIGINATING FILE 757;2 FREE TEXT\n
INPUT TRANSFORM: K:$L(X)>15!($L(X)<1) X
LAST EDITED: MAY 25, 1994
DESCRIPTION: This field is used in the VA to identify
what file pointing to the provider
narrative file created the entry in the
Provider Narrative File. This may be
useful as more packages create pointers to
the Provider Narrative File to store the
local capture of provider terminology.\n
The Problem List package puts its free
text file number in this field when it
adds provider narratives to the Provider
Narrative File.\n
HELP FRAME:\n
INPUT TEMPLATE(S):\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):\n", "", "", ""], ["1006", "DBIA1006", "Routine", "INDIAN HEALTH SERVICE", "1994/09/24", "APPROVED", "Active", "Private", "", "
The PCE Patient/IHS Subset package (namespaced PXPT)
requests a DBIA with the Indian Health Service to distribute the AUTNPOV
routine with the PXPT package. The PXPT package will distribute it as
PXPTNPOV and use ZOSF to load and save the routine as AUTNPOV.\n
There have been no coding changes to the AUTNPOV code by the VA. This is the
same version that is at Tucson VAMC running as of September 4, 1994.\n
This routine is called by the .01 Narrative field input transform on any
lookup of the Provider Narrative File (9999999.27). The Provider Narrative
File is distributed with the PXPT package and has a File type DBIA for
distribution of the Provider Narrative File in the VA. The Provider Narrative
file is used by the VA's Problem List Package and by the PCE package.\n
AUTNPOV ; PROVIDER NARRATIVE TRUE INPUT TRANSFORM
;;92.1;IHS STANDARD DICTIONARIES;;NOV 13, 1991
;
START ;
Q:'$D(APCDOVRR)
I X="=",$D(APCDTNQP) S X=APCDTNQP
Q:X?.E1C.E
I $L(X)>30,$D(^AUTNPOV("B",X)) S X="`"_$O(^(X,0)) Q
S AUTNPOVX=$E(X,1,30)
F AUTNPOVY=0:0 S AUTNPOVY=$O(^AUTNPOV("B",AUTNPOVX, AUTNPOVY))
Q:'AUTNPOVY Q:$P(^AUTNPOV(AUTNPOVY,0),U,1)=X
S X=$S(AUTNPOVY:"`"_AUTNPOVY,$E(X)="`":X,$E(X)="""":X,1:"""" _X_"""")
K AUTNPOVX,AUTNPOVY
Q\n\n
The following routine (PXPTNPOV) is a PXPT version of AUTNPOV that is being
distributed to the field. When the ZOSF("SAVE") is completed, the AUTNPOV
routine will appear as displayed above.\n
PXPTNPOV ; SLC/DLT - Provider Narrative True Input Transform for Export
;1/22/94 14:48
;;1.0V1;PCE PATIENT/IHS SUBSET (PXPT);;Sept 7, 1994 AUTNPOV ; IHS/LB -
PROVIDER NARRATIVE TRUE INPUT TRANSFORM
;;92.1;IHS STANDARD DICTIONARIES;;NOV 13, 1991
;
START ;
Q:'$D(APCDOVRR)
I X="=",$D(APCDTNQP) S X=APCDTNQP
Q:X?.E1C.E
I $L(X)>30,$D(^AUTNPOV("B",X)) S X="`"_$O(^(X,0)) Q
S AUTNPOVX=$E(X,1,30)
F AUTNPOVY=0:0 S AUTNPOVY=$O(^AUTNPOV("B",AUTNPOVX, AUTNPOVY))
Q:'AUTNPOVY Q:$P(^AUTNPOV(AUTNPOVY,0),U,1)=X
S X=$S(AUTNPOVY:"`"_AUTNPOVY,$E(X)="`":X,$E(X)="""":X,1:"""" _X_"""")
K AUTNPOVX,AUTNPOVY
Q\n", "", "AUTNPOV", ""], ["1007", "DBIA106-E", "File", "NATIONAL DRUG FILE", "2005/06/20", "", "Retired", "Private", "50.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
The following references will be made from the QIP3POL* and QIP3NUR* routines
which, while belonging to the QIP namespace, will be maintained by the
Pharmacy developers. Coordination of release and patches will be through the
QIP custodial ISC.", "", "", ""], ["1008", "DBIA104-D", "File", "REGISTRATION", "2005/06/20", "", "Retired", "Private", "43", "
The following reference will be made from the ^QIP1NS
routine which, while belonging to the QIP namespace, will be maintained by the
PIMS developers. Coordination of release and patches will be through the QIP
custodial ISC.", "", "", ""], ["1009", "DBIA110-C", "File", "SCHEDULING", "1994/09/27", "", "Retired", "Private", "409.5", "
The following references will be made from the ^QIP1*
routines which, while belonging to the QIP namespace, will be maintained by
the PIMS developers. Coordination of release and patches will be through the
QIP custodial ISC.", "", "", ""], ["1010", "DBIA1010", "File", "REGISTRATION", "1994/09/30", "", "Retired", "Private", "45.83", "
This is associated with 993 and 994", "", "", ""], ["1011", "DBIA1011", "Routine", "REGISTRATION", "1994/09/30", "", "Pending", "Private", "", "
Fee will look into changing to the mailman mailgroup
functionality in a future version.", "", "VATRAN", ""], ["1012", "DBIA110-D", "File", "SCHEDULING", "2005/06/20", "", "Retired", "Private", "2", "
Routine QIP1NS will use the following field to
determine to percentage of no-show visits versus the total number of visits:", "", "", ""], ["1013", "DOLRO LINE TAG IN ROUTINE %ZOSV", "Routine", "KERNEL", "1994/10/05", "APPROVED", "Active", "Private", "", "
In the FileMan MUMPS OS file, we use code that does
routine DOLRO^%ZOSV to save the local symbol table. This entry point is not
documented.", "", "%ZOSV", ""], ["1014", "SET PIECE OF %ZOSF GLOBAL", "File", "KERNEL", "1994/10/05", "APPROVED", "Active", "Private", "", "
FileMan sets the second piece of ^%ZOSF("OS") equal to
the record number selected from the FileMan MUMPS OS file during DINIT. This
second piece acts like a pointer to the MUMPS OS file.", "", "", ""], ["1015", "DBIA1015", "Routine", "SCHEDULING", "2003/04/03", "APPROVED", "Active", "Private", "", "
Integrated Billing requests use of the function
$$EXOE^SDCOU2. The purpose of the function is to determine whether the
classification questions should be asked for a specific outpatient encounter.
IB needs to know whether the classification questions were not asked of
patients who have claimed exposures, so that a message may be sent to the
Category C Billing mailgroup to alert MCCR personnel to manually review
whether that particular encounter was actually related to the veteran's
claimed exposures.", "", "SDCOU2", "2007/03/15"], ["1016", "FIELD EDITOR - EN~DIR0()", "Routine", "1", "1994/10/17", "APPROVED", "Active", "Private", "", "
Kernel needs to use the screen-oriented field editor
for the character based GUI emulation module.", "", "DIR0", ""], ["1017", "CALLS TO FILEMAN FOR KIDS", "Routine", "1", "1994/10/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call the FileMan DIFROMSU Server routine. This call is used during the build
and installation of a package.", "", "DIFROMSU", ""], ["1018", "UPDATE FILE 101 & 100.99", "File", "ORDER ENTRY/RESULTS REPORTING", "2003/06/10", "", "Retired", "Private", "101", "
Kernel Installation and Distributions System needs to
update the Protocol file, 101, and the Package Parameter multiple in the Order
Parameter file, 100.99. KIDS needs to extract data from these files during
Package transportations. KIDS also needs to update these files during package
installation.", "", "", ""], ["1019", "BULLETIN FILE", "File", "MAILMAN", "1994/10/07", "APPROVED", "Active", "Private", "3.6", "
Kernel Installation and Distributions System needs to
update the Bulletin file, 3.6. KIDS needs to extract data from this file
during Package transportations. KIDS also needs to update this file during
Package installation.", "", "", ""], ["1020", "PBM", "File", "IFCAP", "1998/10/23", "APPROVED", "Active", "Private", "442", "
All the fields are read from the file using Fileman
calls, except the P.O. DATE. The P.O. DATE's "AB" cross reference is used for
sorting purposes.", "", "", ""], ["1021", "D&PPM", "File", "IFCAP", "1998/06/01", "APPROVED", "Active", "Private", "445", "", "", "", ""], ["1022", "D&PPM", "File", "IFCAP", "1994/10/12", "APPROVED", "Active", "Private", "420.5", "", "", "", ""], ["1023", "HS Components-PDX Segments", "Routine", "PATIENT DATA EXCHANGE", "1994/10/13", "APPROVED", "Active", "Private", "", "\n
As the Health Summary package adds new components to the HEALTH SUMMARY
COMPONENT file (#142.1), it will also add those components to PDX's
VAQ - DATA SEGMENT file (#394.71).\n
At this time, Health Summary will only add those components that do not
have selection items.\n
Health Summary will use the entry point $$ADDSEG^VAQUTL50() to add its
components to the VAQ - DATA SEGMENT file and will use the entry point
$$UPDSEG^VAQUTL50() to update the VAQ - DATA SEGMENT file entries when
the corresponding component is modified. Health Summary will also use
the entry point $$FIRSTUP^VAQUTL50() to check that the component name is
in the uppercase/lowercase naming convention used by PDX.\n
As new components are made available to the PDX users, those components
will be added to DBIA297-E (816).\n
Revision History:
06/01/2023 - Effective with VAQ*1.5*46 and GMTS*2.7*144:
Added new component $$UPDSEG
Corrected component $$ADDSEG to reflect how released code
works", "", "VAQUTL50", "2023/06/09"], ["1024", "Health Summary to File 40.7", "File", "SCHEDULING", "1994/10/17", "APPROVED", "Active", "Controlled Subscription", "40.7", "
Health Summary accesses file ^DIC(40.7, to display the
Name of the Clinic Stop in one of its components.", "", "", ""], ["1025", "Health Summary access to 409.5", "File", "SCHEDULING", "1994/10/17", "", "Retired", "Controlled Subscription", "409.5", "
Health Summary accesses file 409.5, Scheduling Visits
file to display the Associated Clinic and Appointment Type in one of its
components, Clinic Past Visits (CVP).", "", "", ""], ["1026", "Health Summary access to file 409.1", "File", "SCHEDULING", "1994/10/17", "", "Retired", "Controlled Subscription", "409.1", "
Health Summary accesses file 409.1, Appointment Type
File, to display the name of the Appointment Type in one of its components,
Clinic Past Visits (CVP).", "", "", ""], ["1027", "DBIA1027", "Other", "PATIENT DATA EXCHANGE", "1994/11/02", "APPROVED", "Active", "Private", "", "
Health Summary will distribute the routine, VAQUTL50,
under the routine GMTSPDXA. If the routine, VAQUTL50, is not on the system
where the components are being loaded, Health Summary will load it's routine,
GMTSPDXA and rename it to VAQUTL50.", "", "", ""], ["1030", "DBIA1030-A", "Routine", "OUTPATIENT PHARMACY", "1994/11/09", "APPROVED", "Active", "Controlled Subscription", "", "
These entry points can be used to batch process
prescriptions received via telecommunications.", "", "PSOBBC", ""], ["1031", "DBIA1031", "Routine", "REGISTRATION", "1994/10/20", "APPROVED", "Active", "Private", "", "\n\n\n
The PDX application is granted permission to use the function call
$$LOADXMY^DGSEC() in order to place the mail group contained in the
SENSITIVE REC ACCESSED GROUP field (#509) of the MAS PARAMETER
file (#43) into the array XMY.\n
Input:
None\n
Output:
0 = Successfully created XMY("G.MailGroup")="" where MailGroup is
text value of mail group pointed to by field #509 of file #43
-1^ErrorText = Error", "", "DGSEC", ""], ["1032", "DBIA1032", "Routine", "REGISTRATION", "1994/10/21", "APPROVED", "Active", "Private", "", "
The PXPT - PCE Patient/IHS subset package requests
persmission to include the routine DPTLK as the LOOK-UP PROGRAM for the
Patient/IHS file that is being distributed in the VA for use by PCE.", "", "DPTLK", ""], ["1033", "DBIA1033", "File", "INDIAN HEALTH SERVICE", "1994/10/18", "APPROVED", "Active", "Private", "9000010", "\n
Requesting permission to export the Visit File
with the release of Visit Tracking V2.0.\n
File Global Number
----- ------ --------
VISIT AUPNVSIT( 9000010", "", "", ""], ["1034", "FILEGRAMS use of MESSAGE file", "File", "MAILMAN", "1994/10/18", "APPROVED", "Active", "Private", "3.9", "
VA FileMan looks directly at the MESSAGE file in
processing FILEGRAMS.\n
FM is requesting the DBIA for FM Version 21. We will include the migration of
the Filegram processor to use the SERVER protocol to our V22 to-do-list; it
will then be prioritized along w/ the n number of things already planned for
V22.", "", "", ""], ["1035", "TRANSFER TEXT FROM MAIL MESSAGE", "File", "MAILMAN", "1994/10/18", "", "Retired", "Private", "3.9", "
VA FileMan looks directly at the MESSAGE file to
transfer text from one mail message to another, using the UTILITY, TRANSFER
TEXT option in the line editor.\n
FM is requesting the DBIA until mailman provides the interface for
transferring message text.", "", "", ""], ["1036", "DBIA1036", "File", "DRUG ACCOUNTABILITY", "1994/11/17", "APPROVED", "Active", "Private", "58.8", "
Instead of collecting dispensing by looping through the
"AL", "AJ", "AM", and "AN" x-refs in the outpatient ^PSRX( global, the
dispensing data will be stored on a daily basis in ^XTMP("PSA",. If the Drug
Acct. background job is not scheduled, the Outpatient routine will not update
^XTMP("PSA",. If it is scheduled and a Drug Acct. Location for that
Outpatient Division is tracking the drug being released or returned to stock,
a cumulative total will be updated in ^XTMP("PSA",DIVISION,DRUG,DT). The Drug
Acct. background job is intended to be run nightly and will loop thru
^XTMP("PSA", updating Drug Acct. files and then killing off that node in
^XTMP("PSA",. When the job completes, ^XTMP("PSA",0) is updated. This file
agreement supports Outpatient direct global reads to ^PSD(58.8, and direct
writes to ^XTMP("PSA", in routines PSODISP* and PSORESK*.", "", "", ""], ["1037", "DBIA1037", "File", "REGISTRATION", "1994/10/24", "APPROVED", "Active", "Private", "2", "
The PCE Patient/IHS Subset (PXPT) package request
permission to directly access the zeroth node of the ^DPT global for the
PATIENT MERGED TO field. This field is checked in screening logic on the
PATIENT/IHS file. This field is used by IHS in their PATIENT MERGE
application. By documenting this dependency on the PATIENT MERGE TO field by
IHS, this agreement serves to show a current dependency based on Joint Sharing
of the Patient File (2) and the Patient/IHS file (9000001). The Patient/IHS
file is distributed in the VA by the PCE Patient/IHS Subset (PXPT) package.\n
When the VA determines how it will use the PATIENT MERGE TO field, a
modification to this agreement may be needed.", "", "", ""], ["1038", "DBIA1038-A", "File", "CONTROLLED SUBSTANCES", "1994/10/27", "APPROVED", "Active", "Private", "59.4", "
Controlled Substances Version 2.0 exports field #31
from INPATIENT SITE file #59.4.\n
Inpatient Medications will remain custodian of the file and will provide clean
up of fields * for deletion in Version 5.0. At that time, Controlled
Substances will become custodian of this File 59.4.", "", "", ""], ["1039", "DBIA1039", "File", "KERNEL", "1994/10/24", "APPROVED", "Active", "Private", "4", "
The PCE Patient/IHS Subset (PXPT) package requests
permission to directly access the Institution file. This direct access is
needed to setup the IHS Location file (9999999.06), which is DINUMed to the
Institution File. The Location file is distributed by the PXPT package to
support the Visit file and Problem List files which are jointly shared files
between the VA and IHS.\n
The direct access is referencing the internal entry number, without actually
looking at any fields in the Institution file.", "", "", ""], ["1040", "LIST INDEX OF MESSAGE RESPONSES", "Routine", "MAILMAN", "1994/10/24", "APPROVED", "Active", "Supported", "", "
This API may be called in a roll and scroll mode to
list the responses of a message.", "", "XMAH", ""], ["1041", "DBIA1041", "Routine", "HEALTH SUMMARY", "1994/10/25", "", "Pending", "Private", "", "
Progress Notes rtn ^GMRPNR5 (exported w/GMRP*2.5*31) is
using Health Summary rtn ^GMTSLTR to delimit locations selected using the
GMRPN PRINT BATCH option.", "", "GMTSLTR", ""], ["1042", "USE OF XMSUB IN FM SCREEN EDITOR", "Other", "MAILMAN", "1994/10/25", "", "Retired", "Private", "", "
The Screen Editor in VA FileMan checks for the
existence of the variable XMSUB. If XMSUB exists, the Screen Editor displays
the first 30 characters of that variable between "greater than" and "less
than" symbols (< and >) on the top ruler line of the screen. When an original
MailMan message is edited, XMSUB contains the subject of the message; when a
response is edited, XMSUB contains an "R" concatenated with the number of the
original message.", "", "", ""], ["1043", "DBIA1038-B", "File", "CONTROLLED SUBSTANCES", "1994/10/27", "APPROVED", "Active", "Private", "59.4", "
Controlled Substances Version 2.0 utilizes INPATIENT
SITE file #59.4 to distinguish which sites are flagged for CS use.\n
Inpatient Medications will remain custodian of the file and will provide clean
up of fields * for deletion in Version 5.0. At that time, Controlled
Substances will become custodian of this File 59.4.", "", "", ""], ["1044", "DBIA1044", "Routine", "INDIAN HEALTH SERVICE", "1994/10/27", "APPROVED", "Active", "Private", "", "\n
Visit Tracking V2.0 request permission to export the AUPNVSIT
routine.", "", "AUPNVSIT", ""], ["1045", "DBIA1045", "File", "INTEGRATED BILLING", "1994/10/28", "APPROVED", "Active", "Private", "355.1", "
IVM Center software utilizes the Type of Plan File
(#355.1) to correctly categorize insurance policies identified through the IVM
verification process. The type of plan (derived from file 355.1) is
transmitted from the IVM Center database via HL7 IN1 (Insurance) Segment to
DHCP facilities for insurance policies identified for veterans.\n
The Type of Plan file is pointed to by an IVM specific file (IVM Verified
Insurance - #300.122) -- local entries are not added (file 355.1 is utilized
for reference purposes only).\n", "", "", ""], ["1046", "DBIA1046", "Routine", "INTEGRATED BILLING", "1994/10/28", "APPROVED", "Active", "Controlled Subscription", "", "
This function returns the value of various VA pension
rates. These values are date sensitive and vary depending upon the number of
dependents that a veteran has. These pension values are compared with the
veteran's income to determine the veteran's eligibility for the medication
copayment.\n
This function is used primarily as an internal utility for Integrated Billing
during the process of determining a veteran's medication copayment exemption
status, but is also accessible to a limited number of applications for the
purpose of accessing and displaying these values as they would apply to a
specific veteran.", "", "IBARXEU1", ""], ["1047", "MENTAL HEALTH - PROGRESS NOTE #1047", "File", "PROGRESS NOTES", "1994/10/28", "", "Retired", "Private", "121", "
Mental Health V. 5.01 requests to convert data stored
in the Generic Progress Notes file (#121), in the field DXLS (#30). Only data
stored in this field that points to the DSM-III-R (#627.5) file will be
modified to point to the new DSM (#627.7) file.", "", "", ""], ["1048", "MAILMAN: Initialize Mailman Environment", "Routine", "MAILMAN", "1994/11/01", "", "Retired", "Supported", "", "
NOTICE! NOTICE! NOTICE!\n
XMGAPI1 is being RETIRED as a supported reference. Use INIT^XMVVITAE instead.\n
This routine contains two application programmer entry points:\n
$$EN^XMGAPI1(DUZ,.HEADERS) which initializes mailman to access DUZ's mail
and is the preferred technique for programs to use. OPTIONS should continue
to invoke EN^XM.\n
$$READ^XMGAPI1() which returns the "next" line in the body of a message
-- typically for a server", "", "XMGAPI1", ""], ["1049", "PNs use of Security Key file (19.1)", "File", "KERNEL", "1994/11/04", "APPROVED", "Active", "Private", "19.1", "
Progress Notes is adding field #.05 SECURITY KEY to the
GENERIC PROGRESS NOTE TITLE file (121.2).\n
This field will point to the SECURITY KEY file (19.1)\n
This is being done to implement functionality requested in E3R 4858 and will
be exported in patch GMRP*2.5*29.\n
Many services use the Progress Notes package. Sites will now have the option
to restrict entering of new Progress Notes to users that hold the key
associated with a particular title. This is accomplished using DIC("S") when
creating a new progress note. If a TITLE does not have a security key
associated with it, no restriction will apply.\n
This will be particularly useful for sites wanting to control access to the
CWAD titles; Crisis Note, Clinical Warning, and Advance Directive.\n
Any existing security key may be used to lock any title. It is entirely at
the sites' discretion. This will not in any way impact the display or
printing of any notes.\n
The SECURITY KEY field (#.05) entry in GENERIC PROGRESS NOTE TITLE file
(121.2) may be edited at any time. This can be accomplished by using the
'GMRPN TITLE MGMT MENU' option.\n
The next version of Progress Notes will utilize the TIU (Text Integration
Utility) which will inlude the ASU (Authorization/Subcription Utility). The
use of the SECURITY FIELD will no longer be necessary at this time.", "", "", ""], ["1050", "DBIA909-B", "File", "REGISTRATION", "1994/07/14", "APPROVED", "Active", "Private", "42.4", "\n
The laboratory LMIP reports require that workload data be collected based on
Facility Treating Specialty #45.7 and Specialty #42.4. We determine this
information by looking at the ordering location.
We are asking permission to read the these files to obtain .01 field and the
field #6 CDR ACCOUNT field for certain reports.\n
The logic uses the ^SC(X,42) to determine if the location is a ward. If it is
the n use the Facility Treating specialty pointers to navigate to the data.
See DBIA909-A & DBIA909-C.\n
The laboratory package also needs to access the ACTIVE status of the entries
in the SPECIALTY file (#42.4). This will be done using direct access via the
"ADATE" cross reference of the EFFECTIVE DATE multiple field and extracting
the data from the 0-node of the EFFECTIVE DATE multiple. The call will be to
ACTV^LRJSDX with the ien of the entry in file 42.4 and optionally an 'as of'
date passed into it.", "", "", "2010/09/09"], ["1051", "DBIA909-C", "File", "REGISTRATION", "1994/07/14", "APPROVED", "Active", "Private", "42", "\n
The laboratory LMIP reports require that workload data be collected based on
Facility Treating Specialty #45.7 and Specialty #42.4. We determine this
information by looking at the ordering location.
We are asking permission to read the these files to obtain .01 field and the
field #6 CDR ACCOUNT field for certain reports.\n
The logic uses the ^SC(X,42) to determine if the location is a ward. If it is
the n use the Facility Treating specialty pointers to navigate to the data.
See DBIA909-A & DBIA909-B.", "", "", ""], ["1052", "DBIA1052-A", "Routine", "1", "1994/11/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call the FileMan DIFROM Server routines and Compiler routines. These calls
are used to update the Data Dictionaries, Templates, Forms, and Functions at a
site during the installation of a package.", "", "DIFROMS", ""], ["1053", "DBIA1052-B", "Routine", "1", "1994/11/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call the FileMan DIFROM Server routines and Compiler routines. These calls
are used to update the Data Dictionaries, Templates, Forms, and Functions at a
site during the installation of a package.", "", "DIFROMSO", ""], ["1054", "DBIA1052-C", "Routine", "1", "1994/11/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call the FileMan DIFROM Server routines and Compiler routines. These calls
are used to update the Data Dictionaries, Templates, Forms, and Functions at a
site during the installation of a package.", "", "DIFROMSI", ""], ["1055", "DBIA1052-D", "Routine", "1", "1994/11/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call the FileMan DIFROM Server routines and Compiler routines. These calls
are used to update the Data Dictionaries, Templates, Forms, and Functions at a
site during the installation of a package. The DIEZ routine is used to
recompile input templates in non-interactive mode.", "", "DIEZ", ""], ["1056", "DBIA1052-E", "Routine", "1", "1994/11/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call the FileMan DIFROM Server routines and Compiler routines. These calls
are used to update the Data Dictionaries, Templates, Forms, and Functions at a
site during the installation of a package. The DIKZ routine is used to
recompile a file's cross-references in non-interactive mode.", "", "DIKZ", ""], ["1057", "DBIA1052-F", "Routine", "1", "1994/11/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call the FileMan DIFROM Server routines and Compiler routines. These calls
are used to update the Data Dictionaries, Templates, Forms, and Functions at a
site during the installation of a package. The DIPZ routine is used to
recompile print templates in non-interactive mode.", "", "DIPZ", ""], ["1058", "DBIA1052-G", "Routine", "1", "1994/11/07", "APPROVED", "Active", "Private", "", "
Kernel Installation and Distribution System needs to
call two undocumented ScreenMan entry points from the 7.5 node of .01 fields
of multiples in the Build file. These entry points are used to inform
ScreenMan of subrecords that have been added or deleted during the execution
of the 7.5 node.", "", "DDSUTL", ""], ["1059", "FILE SECURITY CODE ACCESS", "File", "1", "1994/11/08", "APPROVED", "Active", "Private", "1", "
This integration agreement will allow the MAS package
to release a patch to allow sites to review and update file security codes
without having to install inits of all files. Due to problems reported in
several recent NOIS mesages, we've had cause to review and update our
recommended levels of access. We feel this is the best way to get the sites
up-to-date. An informal message and a draft copy of the routines has already
been submitted to FileMan development for review and concurrence. Our
instructions will be that this is a one time only run. No options will be
created for this patch. The patch is DG*5.3*49 and is currently under
development.\n
We are requesting the ability to view and edit the following nodes in the DIC
global:\n
^DIC(filenum,0,"WR") file write access
^DIC(filenum,0,"DD") file DD access
^DIC(filenum,0,"RD") file read access
^DIC(filenum,0,"DEL") file delete access
^DIC(filenum,0,"LAYGO") file LAYGO access", "", "", ""], ["1060", "DBIA1030-B", "Routine", "OUTPATIENT PHARMACY", "1994/11/09", "", "Retired", "Controlled Subscription", "", "
This entry point can be used to get the site number of
the site running the Outpatient Pharmacy package.", "", "PSOLSET", ""], ["1061", "PATIENT LOOK-UP CALL TO MPR", "Routine", "Missing Patient Register", "1994/11/10", "APPROVED", "Active", "Private", "", "
At the request of the MPR (Missing Patient Register)
developer, we have added a call to MPRCHK from the security routine Q+2^DGSEC.\n", "", "MPRCHK", ""], ["1062", "1062", "Other", "1", "1995/01/12", "APPROVED", "Active", "Private", "", "
Kernel Toolkit needs this agreement with Fileman to be
able to use the variable D0 in DD definitions. Here are some examples of the
use of variable D0.\n
15,99991 LOOKUP1 ; COMPUTED\n
MUMPS CODE: S X="`"_+^VA(15,D0,0)
ALGORITHM: S X="`"_+^VA(15,D0,0)
DESCRIPTION: This field is used to navigate to the file
pointed to by RECORD1.\n
TECHNICAL DESCR: This field is used to navigate to the file
pointed to by RECORD1.\n\n
15,99992 LOOKUP2 ; COMPUTED\n
MUMPS CODE: S X="`"_+$P(^VA(15,D0,0),U,2)
ALGORITHM: S X="`"_+$P(^VA(15,D0,0),U,2)
DESCRIPTION: This field is used to navigate to the file
pointed to by RECORD2.\n
TECHNICAL DESCR: This field is used to navigate to the file
pointed to by RECORD2.\n\n
15,99993 LOOKUP3 ; COMPUTED\n
MUMPS CODE: S X="`"_D0
ALGORITHM: S X="`"_D0
LAST EDITED: AUG 08, 1989
DESCRIPTION: This computed field provides navigational
capability to any file that points to this
file and has a DINUM relationship.\n
TECHNICAL DESCR: This computed field provides navigational
capability to any file that points to this
file and has a DINUM relationship.", "", "", ""], ["1063", "DBIA1063-A", "File", "KERNEL", "1994/11/16", "", "Retired", "Private", "19", "\n
The Outpatient routines PSODISP and PSORESK need to make sure that the
Drug Acct. background job, PSA IV ALL LOCATIONS is scheduled to run before
updating ^XTMP("PSA". This agreement supports the look-up to the OPTION file
for a Kernel version 7.1 environment.", "", "", ""], ["1064", "DBIA1063-B", "File", "KERNEL", "1994/11/16", "APPROVED", "Active", "Controlled Subscription", "19.2", "
The Drug Acct. background job, PSA IV ALL LOCATIONS is
scheduled to run before updating ^XTMP("PSA".", "", "", ""], ["1065", "D&PPM", "File", "DRUG ACCOUNTABILITY", "1994/11/17", "", "Retired", "Private", "58.8", "
The Pharmacy Benefits Management package will extract
data on a monthly basis from the "Drug Accountability Stats" file number 58.8.\n", "", "", ""], ["1066", "D&PPM", "File", "DRUG ACCOUNTABILITY", "1994/11/17", "", "Retired", "Private", "58.81", "
The Drug & Pharmeacuticl Product Management (D&PPM)
package will extract data on a monthly basis from the "Drug Accountability
Transactions file" number 58.81. The primary sorting process through this
file is on the "AF" cross- reference of the DATE/TIME field.", "", "", ""], ["1067", "Pharmacy Benefits Management", "File", "CMOP", "1994/11/17", "APPROVED", "Active", "Private", "552.5", "
The Pharmacy Benefits Management package will extract
statistical data on a monthly basis from "HOST" CMOP facilities' file", "", "", ""], ["1068", "DBIA1068", "File", "MENTAL HEALTH", "1994/11/21", "APPROVED", "Retired", "Private", "627.7", "
Progress Notes has a variable pointer, DXLS, file 121,
field 30 that is as follows:
FILE ORDER PREFIX LAYGO MESSAGE
80 1 I n ICD9 Code
627.5 2 D n DSM-III-R Code This is for use with
Mental Health v4.18 and Mental Health v5.0.\n
With the release of Mental Heath v5.01 this will be changed to:
FILE ORDER PREFIX LAYGO MESSAGE
80 1 I n ICD9 Code
627.7 2 D n DSM-IV\n
PNs should have had an agreement to use this file. Prior to the release of
Progress Notes v2.5 this data was a part of the Mental Health progress notes
global 606. The agreement was somehow overlooked when the data was converted
to ^GMR(121.\n
GMRP*2.5*26 will make Progress Notes fully compatible with versions 4.18, 5.0
and 5.01 of Mental Health.\n
Progress Notes rtns ^GMRPNP3 and ^GMRPNP4 have been modified to check for the
existence of all 3 possible globals and accomplish the prting accordingly.", "", "", ""], ["1069", "DS needs WARD AT DISCHARGE", "File", "REGISTRATION", "1994/12/05", "APPROVED", "Active", "Private", "405", "
Discharge Summary is using the computed field WARD AT
DISCHARGE from the PATIENT MOVEMENT FILE in lieu of the location returned in
VAIP(17,4) from ^VADPT.\n
DS was having a problem with the value that is returned from VADPT being
accurate when the pt was ASIH. The use of this field is being implemented in
GMRD*1*2 in rtns GMRDLIBA and GMRDLIBF.", "", "", ""], ["1070", "DBIA1070", "Routine", "REGISTRATION", "1995/03/30", "APPROVED", "Active", "Private", "", "
The IVM package files new Means Tests into the PIMS
Means Test module. This routine contains utilities for Means Test processing.\n", "", "DGMTSCU3", ""], ["1071", "DGPMSTAT", "Routine", "REGISTRATION", "1994/12/09", "", "Pending", "Supported", "", "
Obtain Inpatient Status.", "", "DGPMSTAT", ""], ["1072", "VACPT", "Routine", "VETERANS ADMINISTRATION", "1994/12/09", "", "Pending", "Supported", "", "
Display CPT Copyright Information.", "", "VACPT", ""], ["1073", "VADATE", "Routine", "REGISTRATION", "1994/12/09", "", "Pending", "Supported", "", "
Generic Date Routine. This was designed many years ago
(1988-1989) for use with the MAS package. Since this time, the ToolKit
package has released function calls in XLFDT. It is our feeling at this point
that those tools should be used for new code. This integration agreement is
entered for legacy code only.", "", "VADATE", ""], ["1074", "VATRAN", "Routine", "VETERANS ADMINISTRATION", "1994/12/09", "", "Pending", "Supported", "", "
Establish VADATS Transmission Variables", "", "VATRAN", ""], ["1075", "VATREDIT", "Routine", "REGISTRATION", "1994/12/09", "", "Pending", "Supported", "", "
Enter/Edit Transmission Routers File.", "", "VATREDIT", ""], ["1076", "VAUQWK", "Routine", "REGISTRATION", "1994/12/09", "APPROVED", "Active", "Private", "", "
Quick Lookup for Patient Data.", "", "VAUQWK", "1994/12/10"], ["1077", "VAUTOMA", "Routine", "VETERANS ADMINISTRATION", "1994/12/09", "", "Pending", "Supported", "", "
Generic One, Many, All Routine.", "", "VAUTOMA", ""], ["1078", "DBIA1078", "File", "PROGRESS NOTES", "1994/12/09", "APPROVED", "Active", "Controlled Subscription", "121", "
Mental Health V. 5.01 requests to change Generic
Progress Notes file (#121) field DXLS (#30) variable pointer value to point to
the new DSM file (#627.7), instead of the DSM-III-R file (#627.5).", "", "", ""], ["1079", "DBIA1079-A", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "", "
Direct read access to PS global. Used to extract
pharmacy outpatient RX data.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["1080", "DBIA1079-B", "File", "PHARMACY DATA MANAGEMENT", "1994/12/13", "APPROVED", "Active", "Private", "55", "", "", "", ""], ["1081", "DBIA1079-C", "Routine", "OUTPATIENT PHARMACY", "1994/12/13", "", "Retired", "Private", "", "
This routine needs to maintain the calls to Pharmacy
Prescription Practices (PPP).", "", "PSOBBC", ""], ["1082", "DBIA1079-D", "Routine", "OUTPATIENT PHARMACY", "1994/12/13", "", "Retired", "Private", "", "
This routine needs to maintain the calls to Pharmacy
Prescription Practices (PPP).", "", "PSONUM", ""], ["1083", "DBIA1079-E", "Routine", "PHARMACY PRESCRIPTION PRACTICE", "1994/12/13", "APPROVED", "Retired", "Private", "", "
This routine needs to maintain the calls to Pharmacy
Prescription Practices (PPP).", "", "PPPGET7", ""], ["1084", "DBIA1079-F", "Routine", "OUTPATIENT PHARMACY", "1994/12/13", "", "Retired", "Private", "", "
This routine needs to maintain the calls to Pharmacy
Prescription Practices (PPP).", "", "PSORX", ""], ["1085", "DBIA1079-G", "Routine", "PHARMACY PRESCRIPTION PRACTICE", "1994/12/13", "APPROVED", "Retired", "Private", "", "
This routine needs to maintain the calls to Pharmacy
Prescription Practices (PPP).", "", "PPPPRT9", ""], ["1086", "DBIA1079-H", "Other", "OUTPATIENT PHARMACY", "1994/12/13", "", "Retired", "Private", "", "
The following PSO routines will be distributed as part
of the PPP v1.0 release. The routines will be sent in the PPP namespace and
then translated back to their PSO namespace as part of the PPP post init. At
that point PSO becomes custodian of the routines and will be responsible for
any reported problems. PSO will be responsible for entering an informational
patch describing the destribution of the PSO routines by PPP. The routines
are:\n
1. PSOBBC PPPSE01
2. PSONUM PPPSE02
3. PSOPRF PPPSE03
4. PSORX PPPSE04
5. PSOSD PPPSE05\n\n
The patch number is PSO*6*105", "", "PSOSD", ""], ["1087", "DBIA1087", "File", "KERNEL", "1994/12/13", "APPROVED", "Active", "Private", "200", "
Agreement for the Notifications component of OE/RR 2.5
to directly access the global ^VA(200. This includes Read/Delete access to
the global.", "", "", ""], ["1088", "DBIA1088", "Routine", "CMOP", "1995/04/04", "APPROVED", "Active", "Private", "", "
When running CMOP and NDF software, NDF has a hook into
CMOP in the Rematch/Match Single Drug option. If a drug has been marked to
transmit to CMOP through the CMOP package and an individual wants to rematch
it, the software will display a message telling the user that it is matched
and marked for CMOP. If the user chooses to rematch, the software will kill
off the match, unmark it to transmit CMOP. The entry point is REMTCH^PSNHELP.
This entry point sets the variable +Y equal to the variable DA. It then calls
the CMOP routine PSXREF. This routine sets the proper information into a CMOP
activity log multiple in file 50 (subfile 50.0214). In addition, when the
software marks or unmarks a drug, it sets field 213 "CMOP DISPENSE" in 50 to a
"1" for mark and a "0" for unmark. This field also belongs to CMOP. File 50 is
a shared pharmacy file. Each module owns different fields and nodes in this
file.", "", "PSXREF", ""], ["1089", "Supported Option File Routines", "Routine", "GENERIC CODE SHEET", "1995/01/09", "APPROVED", "Active", "Supported", "", "
This integration agreement contains the entry points
supported by the Generic Code Sheet package. For more information on using
the supported references, please refer to the Generic Code Sheet Technical
Manual.", "", "GECSCALL", ""], ["1090", "DBIA1090", "Other", "CONSULT/REQUEST TRACKING", "1994/12/14", "APPROVED", "Active", "Private", "", "
The Medicine developers and the Consult/Request
Tracking developers have agreed to remove the GMRCACT NEW PATIENT protocol
(child) as an item from the GMRCACTM MEDICINE PKG MENU protocol (parent) in
the Consult/ Request Tracking package. The functionality provided in the
GMRCACT NEW PATIENT protocol as an item in the GMRCACTM MED PKG MENU is not
appropriate within the defined context of the Medicine package and removing
this item will ensure that users are not prompted twice for selecting a
patient.\n
The routine MCFIXOEP, has been developed and will be included in the
pre-installation process for Medicine V2.2 which will remove the protocol
item. The Consult/Request Tracking developers will remove the GMRCACT NEW
PATIENT protocol item from future versions of Consults.", "", "", ""], ["1091", "DBIA316-C", "Other", "1", "1995/01/05", "APPROVED", "Active", "Private", "", "
Multi Term Lookup (a component of TOOLKIT) requests the
ability to read the "GL" node of ^DIC in order to retrieve a global root. This
reference can be found in the routines XTLKEFOP, XTLKKWL, XTLKMGR, XTLKPRT and
in the MUMPS X-REF of file 8984.3:\n
CROSS-REFERENCE: 8984.3^AC^MUMPS
1)= I $D(^XT(8984.3,DA,0)),$P(^(0),U,2)'="" S
J\n
L=$P(^(0),U,2),JL=$P(^DIC(JL,0,"GL"),U,2),^XT(8
984.3,"AC",JL,$E(X,1,30),DA)="" K JL\n
2)= I $D(^XT(8984.3,DA,0)),$P(^(0),U,2)'="" S
J
L=$P(^(0),U,2),JL=$P(^DIC(JL,0,"GL"),U,2) K
^XT
(8984.3,"AC",JL,$E(X,1,30),DA),JL
Associates the synonym with the global root
of the lookup file.\n
***** Amendment 1/23/95 *****\n
The above request should be modified to include both Multi-Term Lookup and the
Duplicate Resolution modules of Toolkit. The 'GL' node is referenced for the
same purpose in file 15.1, field .01, "AGL" x-reference.", "", "", ""], ["1092", "Use of Spooler by Health Summary", "Routine", "KERNEL", "1994/12/20", "APPROVED", "Active", "Controlled Subscription", "", "
The API for PDX to request Health Summary data
functions by Spooling Health Summary output into a SPOOL DOCUMENT and
transfering the resulting data from ^XMBS(3.519, into an array (usually ^TMP)
named by the calling application. This was necessary, given the current
design of Health Summary, and the absence of HFS space on the 486 systems. To
be portable, the most practical means of generating ASCII output to a MUMPS
global was to use the Spooler.\n
To that end, Health Summary requests permission to make direct reference to
the SPOOL DOCUMENT (^XMB(3.51,) and SPOOL DATA (^XMBS(3.519,) files to
evaluate the status of the Spool Document, and to transfer the resulting text
to the target array respectively. We also call the entry points DSD^ZISPL and
DSDOC^ZISPL to delete the SPOOL DATA and SPOOL DOCUMENT records once the
transfer is successfully completed until otherwise specified.", "", "ZISPL", ""], ["1093", "DBIA1093-A", "Routine", "GENERIC CODE SHEET", "1994/12/22", "APPROVED", "Active", "Private", "", "
This is a request for an integration agreement between
GECS and PIMS. With the changes made in GECS V2.0, the calls made from PIMS
no longer were available. The call to GETMAP^GECSXMAP( ) will return variable
GECSMAP( ) containing the fields in the GENERIC CODE SHEET file (#2100) that
are associated with the code sheet selected.", "", "GECSXMAP", ""], ["1094", "DBIA1093-B", "File", "GENERIC CODE SHEET", "1994/12/22", "APPROVED", "Active", "Private", "2100", "
This is a request for an integration agreement between
GECS and PIMS. PIMS will be making references to files in GECS and a print
template. This integration agreement will formalize references that have been
included in PIMS in the past, and modified to incorporate the changes in GECS
V2.0.", "", "", ""], ["1095", "DBIA1095", "Other", "INPATIENT MEDICATIONS", "1994/12/29", "APPROVED", "Active", "Private", "", "\n\n
Controlled Substances Version 2.0 utilizes three security keys exported by the
Inpatient Medications software. The keys are used, within Inpatient Meds, to
identify the user of the package. The same use is requested by Controlled
Substances.\n
The PSJ RPHARM key identifies a pharmacist, the PSJ RNURSE key identifies a
nurse, and the PSJ PHARM TECH key identifies a pharmacy technician. These
same identifications are used in the Controlled Substances package.", "", "", ""], ["1096", "PATIENT MOVEMENT file cross reference", "File", "REGISTRATION", "1995/01/03", "APPROVED", "Active", "Controlled Subscription", "405", "
Patient Movement file (#405)
- The "ATID1" xref.of the Patient Movement file. This is to order through
admissions in inverse date order.", "", "", ""], ["1097", "Lookup on Facility Movement file", "File", "REGISTRATION", "1995/01/03", "APPROVED", "Active", "Private", "405.1", "\n
- A lookup on the FACILITY MOVEMENT TYPE file (#405.1) for discharge types
with a screen that utilizes the "AM" Xref of the FACILITY MOVEMENT TYPE file
(#405.1) and the fourth piece, the 'ACTIVE' field, on the zero node. The 'AM'
cross reference will be $O through to search for active facility movement
types.\n
- Global read access to the FACILITY MOVEMENT TYPE file (#405.1) the second
piece of the zero node the TRANSACTION TYPE field to identify discharge types.\n", "", "", ""], ["1098", "GENERAL LOOKUP", "File", "REGISTRATION", "1995/01/03", "APPROVED", "Active", "Private", "405.2", "
The AMIE software will perform a FM lookup on the MAS
MOVEMENT file (#405.2) in order to create and display a list of movement
types. No pointer values will be stored as part of the AMIE database.", "", "", ""], ["1099", "LOOKUP on MAS MOVEMENT TRANSACTION TYPE file", "File", "REGISTRATION", "1995/01/03", "APPROVED", "Active", "Private", "405.3", "
The AMIE software will perform a FM lookup on the MAS
MOVEMENT TRANSACTION TYPE file (#405.3) in oder to check for a specific
transaction type and gather its internal file number. This value will be used
for comparison during the processing of records. This value will not be
stored as part of the AMIE database.", "", "", ""], ["1100", "DISPOSITION NODE", "File", "REGISTRATION", "1995/01/03", "APPROVED", "Active", "Private", "2", "
Global read access to the "DIS" node of the PATIENT
file, to look at the STATUS field.", "", "", ""], ["1101", "Patient File Scheduling Node", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "\n\n
AMIE references the described fields on the 'S' Node of the Patient file to
implement C&P appointment linking for release with V2.7.\n", "", "", ""], ["1102", "Hospital Location File Scheduling Node", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "\n\n
AMIE references the described fields on the 'S' Node of the Hospital Location
file to implement C&P appointment linking for release with V2.7.\n", "", "", ""], ["1103", "AMIE use of SDAM1", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "\n\n
AMIE calls $$STATUS^SDAM1 to retrieve for output the status of a given
appointment.\n", "", "SDAM1", ""], ["1105", "DBIA1105", "File", "ACCOUNTS RECEIVABLE", "1995/01/06", "", "Withdrawn", "Private", "423.5", "
This file contains a listing of the transactions that
can be handled by the PRCOISM IFCAP server. This file also contains the
mailgroup that will receive any transaction processing error message and the
entry point (TAG^ROUTINE) for each different transaction processing. It
contains only four fields: TRANSACTION CODE, MAILGROUP, TAG and ROUTINE.", "", "", ""], ["1106", "EEO/PAID - QAQ ADHOC REPORT", "Routine", "QUALITY ASSURANCE INTEGRATION", "1995/01/09", "APPROVED", "Active", "Controlled Subscription", "", "
Equal Employment Opportunity Complaint Tracking version
2.0 (EEO) will be referencing the routine ^QAQAHOC0 from within the routine
^EEOEAHOC. The neccessary QAQ* variables will be set for this call after
establishing the existance of the routine ^QAQAHOC0. This reference will
provide the EEO user with flexible report generation capabilities.\n
PAID version 4.0 will be referencing the routine ^QAQAHOC0 from within
routines PRSDAH1, PRSDAH2, PRSDAH3 and PRSDAH4. The neccessary QAQ* variables
will be set for this call after establishing the existance of the routine
^QAQAHOC0. This reference will provide the PAID user with flexible report
generation capabilities.", "", "QAQAHOC0", ""], ["1107", "GECSENTR reference", "Routine", "GENERIC CODE SHEET", "1995/01/10", "APPROVED", "Active", "Supported", "", "
This integration agreement contains the GECSENTR
reference supported by the Generic Code Sheet package. For more information
on using the supported reference, please refer to the Generic Code Sheet
Technical Manual.", "", "GECSENTR", ""], ["1108", "FMS code sheets", "Routine", "GENERIC CODE SHEET", "1995/01/11", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement contains the routine used by
IFCAP/AR and ENGINEERING to build and transmit the Financial Management System
(FMS) code sheets. For more information regarding the use of this routine,
please refer to the Generic Code Sheet Technical Manual.", "", "GECSUFMS", ""], ["1109", "Use of Cross References", "File", "SCHEDULING", "1995/01/26", "", "Retired", "Private", "409.5", "
Read access to the following cross references is being
requested. These cross references will be used to count the clininc stops and
the stop codes for a particular patient. The AMIE code will $O through these
structures.
^SDV("ADT"
^SDV("C"", "", "", ""], ["1110", "1110", "File", "1", "2003/06/10", "", "Retired", "Private", "15", "
Kernel Toolkit needs this agreement with FileMan to be
able to clean up some "IX" nodes in the data dictionary of the DUPLICATE
RECORD (#15) file. The "IX" nodes which are killed during the post-init
contain the names of the X-refs. which do not exist.", "", "", ""], ["1111", "1111", "File", "1", "1995/01/10", "APPROVED", "Active", "Private", "", "
Kernel Toolkit files have a number of fields whose
screens, input transforms, and executable helps contain code that directly
references ^DD.", "", "", ""], ["1112", "PATIENT TYPE", "File", "REGISTRATION", "1995/01/26", "APPROVED", "Active", "Controlled Subscription", "391", "
Read access to the following global and cross reference
is being requested. The file in question is Type of Patient (391) the zero
node first piece, as well as the "B" cross reference. The AMIE package needs
this information when transferring 2507 requests. Internal entry numbers are
not used during the transfer, only external values.", "", "", ""], ["1113", "1113", "File", "KERNEL", "1995/01/10", "APPROVED", "Active", "Private", "9.4", "
Kernel Toolkit needs this agreement with Kernel to
reference ^DIC(9.4", "", "", ""], ["1114", "FMS code sheets", "Routine", "GENERIC CODE SHEET", "1995/01/11", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement contains the routine used by
IFCAP/AR and Engineering to build and transmit the Financial Management System
(FMS) code sheets. For more information regarding the use of this routine,
please refer to the Generic Code Sheet Technical Manual.", "", "GECSUFM1", ""], ["1115", "FMS code sheets", "Routine", "GENERIC CODE SHEET", "1995/01/11", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement contains the routine used by
IFCAP/AR and Engineering to build and transmit the Financial Management System
(FMS) code sheets. For more information regarding the use of this routine,
please refer to the Generic Code Sheet Technical Manual.", "", "GECSSTAA", ""], ["1116", "FMS code sheets", "Routine", "GENERIC CODE SHEET", "1995/01/11", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement contains the routine used by
IFCAP/AR to build and transmit the Financial Management System (FMS) code
sheets. For more information regarding the use of this routine, please refer
to the Generic Code Sheet Technical Manual.\n", "", "GECSSDCT", ""], ["1117", "FMS code sheets", "Routine", "GENERIC CODE SHEET", "1995/01/11", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement contains the routine used by
IFCAP/AR and Engineering to build and transmit the Financial Management System
(FMS) code sheets. For more information regarding the use of this routine,
please refer to the Generic Code Sheet Technical Manual.", "", "GECSSGET", ""], ["1118", "ICD Codes update in PTF", "File", "REGISTRATION", "1995/01/11", "APPROVED", "Active", "Private", "45.89", "
This is to enable the annual DRG Grouper ICD release to
include updates to the PTF Expanded Code file (#45.89). New entries are
added, updating fields .01, CATEGORY; and .02, DIAGNOSIS/PROCEDURE CODE.
Several codes are inactivated, adding entries to their .03, INACTIVE DATE
field.", "", "", ""], ["1119", "Contrast Medium Allergy Field Access", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1995/01/11", "", "Retired", "Private", "70", "", "", "", ""], ["1120", "GMRVUTL", "Routine", "GEN. MED. REC. - VITALS", "1995/01/18", "APPROVED", "Active", "Supported", "", "\n
User can extract the latest record for a desired vital type from the
Vital/Measurement database for a particular patient by calling EN6^GMRVUTL.\n
Input Variables:\n
DFN = The internal entry number in the Patient file (#2) for the
patient data that is to be retrieved.\n
GMRVSTR = The abbreviation of the vital/measurement desired from the
Vital Type file (#120.51). For example:\n
S GMRVSTR="T",DFN=5 D EN6^GMRVUTL\n
"T" is the abbreviation of temperature. GMRVSTR will be killed.\n
Output Variable:\n
X is set to the entire zeroth node for the entry in question in the
Vital/Measurement file (#120.5), for example, ^GMR(120.5,IEN,0),
where IEN is the subscript in the file that contains the data. The
following shows the format of value containd in X.\n
X=2920728.06^5^2^2920728.13482^42^2098^6^101.1", "", "GMRVUTL", ""], ["1121", "DBIA1121", "File", "PAID", "1995/01/19", "", "Pending", "Private", "450", "
Prosthetics is accessing PRSPC( to obtain hourly rate
information in order to accurately compute labor costs.", "", "", ""], ["1122", "STOP CODES", "File", "SCHEDULING", "1995/01/27", "", "Retired", "Private", "409.5", "
Read access is being requested to loop through the 'CS'
node of the Scheduling Visits file. The AMIE software will $O through this
node collecting the stop codes. The stop codes or any pointers will not be
stored in the AMIE database. The 'CS' node is the subfile that contains the
list of stop codes. The node looks like ^SDV(DATE,"CS",..", "", "", ""], ["1123", "Contrast Media Allergy", "Routine", "ADVERSE REACTION TRACKING", "1995/01/31", "APPROVED", "Active", "Private", "", "
The Allergy package is providing extrinsic functions to
support adding and entering in error Radiological contrast media allergy data
for Radiology/Nuclear Medicine patients.\n", "", "GMRARAD", ""], ["1124", "References to Package File (9.4)", "File", "KERNEL", "1995/02/01", "APPROVED", "Active", "Private", "9.4", "
^XTSUMBLD, %INDEX, and the XINDEX routines need to look
at the Package file to find out what files are part of the package. For
example,\n\n
>>>>>XTSUMBLD+14 (FIELD: PREFIX)
S X=$P(^DIC(9.4,+$P(Y(0),U,2),0),U,2) D NAME(X) G EXIT:'$D(XTRNAME)\n
>>>>>XINDX10+11 (FIELD: FILE) F J=0:0 S J=$O(^DIC(9.4,DA,4,J)) Q:J'>0 I
$D(^(J,0)) SINDFN=+^(0),INDRN="|dd" _INDFN,(INDF,INDL)=0 D INSERT\n
>>>>>XINDX11+22 (FIELD: PREFIX) NAMSP S
INDXN=$P(^DIC(9.4,DA,0),"^",2),C9=0,INDXN(C9)="," F A=0:0 S A=$O(^DIC(9.
4,DA,"EX",A)) Q:A'>0 I $D(^(A,0))#2 S C9=C9+1,INDXN(C9)=$P(^(0),"^")\n\n
>>>>>ZINDX10+4 (FIELD: FILE)
F J=0:0 S J=$O(^DIC(9.4,DA,4,J)) Q:J'>0 I $D(^(J,0)) S INDFN=+^(0),INDRN="
|dd" _INDFN,(INDF,INDL)=0 D INSERT\n
>>>>>ZINDX11+5 (FIELD: PREFIX) NAMSP S
INDXN=$P(^DIC(9.4,DA,0),"^",2),C9=0,INDXN(C9)="," F A=0:0 S A=$O(^DIC(9.
4,DA,"EX",A)) Q:A'>0 I $D(^(A,0))#2 S C9=C9+1,INDXN(C9)=$P(^(0),"^")", "", "", ""], ["1125", "Index and BUILD file", "File", "KERNEL", "1995/02/01", "APPROVED", "Active", "Private", "9.6", "
Index reads the file list, option list, Function list,
routine list to get the components of a build. The references are in XINDX10,
XINDX11, XINDX51.", "", "", ""], ["1126", "Index and the DD global.", "File", "1", "1995/02/01", "APPROVED", "Active", "Private", "", "", "", "", ""], ["1127", "Lookup on B x-ref in globals DIE, DIBT, DIPT", "File", "1", "1995/02/03", "", "Retired", "Controlled Subscription", "", "", "", "", ""], ["1128", "Killing global DOPT", "Other", "1", "1995/02/03", "APPROVED", "Active", "Private", "", "
This integration agreement allows the LetterMan
pre-init to remove the old version namespace entries in the global ^DOPT. The
globals killed are:
^DOPT("WPSE")
^DOPT("WPSE1")
^DOPT("WPSE2")
^DOPT("WPSE3")
^DOPT("WPSE4")\n", "", "", ""], ["1129", "DBIA1129-A", "File", "KERNEL", "1995/02/06", "APPROVED", "Active", "Private", "", "
Reference to ^ZZSLOT. Toolkit requests read access to
this node to maintain the number of active slots in it's performance database.\n
.S XUCMSLOT=+$G(^ZZSLOT(XUCMND,"ACTIVE"))", "", "", ""], ["1130", "DBIA1129-B", "Routine", "KERNEL", "1995/02/06", "APPROVED", "Active", "Private", "", "
References to ^%ZOSV*", "", "%ZOSV2", ""], ["1131", "XMB('NETNAME')", "File", "MAILMAN", "1995/02/09", "APPROVED", "Active", "Supported", "", "
^XMB("NETNAME") contains the human-readable form of the
name of the local domain. It is a copy of the .01 field of the record in the
DOMAIN file 4.2 pointed to by the .01 field of the only record in the MAILMAN
SITE PARAMETERS file 4.3.\n
You may reference this global in any routine.", "", "", ""], ["1132", "TEST FORWARDING ADDRESS", "Routine", "MAILMAN", "1995/02/21", "APPROVED", "Active", "Supported", "", "
This API sends a test message from the Postmaster to
the forwarding address of a user. If the MAILMAN SITE PARAMETER field 7.01,
FWD TEST MESSAGE TO POSTMASTER, is not set, the Postmaster is a recipient.
The message will either be successful or a message will be returned to the
Postmaster from the remote system identified in the forwarding address
explaining that the message could not be delivered.\n
This entry point is not normally used by application programmers.\n
Usage: D ^XMUT7(Y), where Y is the DUZ of the user whose forwarding address is
to be tested.", "", "XMUT7", ""], ["1135", "GMRAMCU0", "Routine", "ADVERSE REACTION TRACKING", "1995/02/17", "APPROVED", "Active", "Supported", "", "
The Patient Wristband software calls
IDBAND^GMRAMCU0(DFN,DATE,USR) to update the ID BAND MARKED field in file 120.8
(PATIENT ALLERGIES).", "", "GMRAMCU0", ""], ["1136", "ENCODE/DECODE CARETS AND CTRL CHARS", "Routine", "MAILMAN", "1995/02/21", "APPROVED", "Active", "Supported", "", "
This API contains the following functions:\n
$$ENCODEUP^XMCU1(STRING) - convert all "^" to "~U~"
$$DECODEUP^XMCU1(STRING) - convert all "~U~" to "^"\n
$$STRAN^XMCU1(STRING) - convert all control characters to printables
$$RTRAN^XMCU1(STRING) - undo the conversion by $$STRAN^XMCU1", "", "XMCU1", ""], ["1137", "DBIA1137", "Routine", "INTEGRATED BILLING", "1995/09/19", "APPROVED", "Active", "Private", "", "
IBQ Package requests use of the routines to derive date
ranges.", "", "IBOUTL", ""], ["1138", "DBIA1138", "Routine", "AUTOMATED MED INFO EXCHANGE", "1995/02/17", "APPROVED", "Active", "Private", "", "\n
The health summary package needs to be able to retrieve Compensation and
Pension data for a health summary C & P component.", "", "DVBCHS0", "2010/10/13"], ["1139", "Add HFS device for OE/RR", "File", "KERNEL", "1997/10/12", "APPROVED", "Active", "Controlled Subscription", "3.5", "", "", "", ""], ["1140", "MAILMAN: (old) Message Forwarding (Extr.Fun.)", "Routine", "MAILMAN", "1995/02/19", "", "Retired", "Supported", "", "
NOTICE! NOTICE! NOTICE!\n
XMDF is being RETIRED as a supported reference. Use ENT1^XMD instead.\n
$$ENT^XMD is an interface in the same routine as the other interfaces for
forwarding messages. It has identical parameters and results and calls this
one -- which will remain supported since documented first.\n
$$ENT^XMDF is a newly created extrinsic function to forward a message for
immediate delivery TO LOCAL RECIPIENTS ONLY. This is processed while the user
waits. It is not passed on to background filer(s) as with most mail messages.\n\n
Usage: S X=$$ENT^XMDF(RECIPIENT,TOBASKET,MESSAGE,FORWARDER)\n
Where:
RECIPIENT = Recipient DUZ (Pointer to the New Person file)
TO_BASKET = Number of Basket (to recipient; typically null; if
less than 1, set to 1 (IN))
MESSAGE = IEN of message in the Message file (XMZ)
FORWARDER = DUZ of person who forwarded message\n\n
Output: If successful, +X>0.(1 or 10) ...or
If unsuccessful, X=Human readable error (+X<1); for example:
"-0: Already a recipient"\n\n
Example: S X=$$ENT^XMDF(.5,"",XMZ,DUZ) I X<1 W *7,!,"**** Message NOT
forwarded: ",X", "", "XMDF", ""], ["1141", "MAILMAN: Ext. Fun. to view/edit Info. Only Flag", "Routine", "MAILMAN", "1995/02/20", "", "Withdrawn", "Supported", "", "
$$INFO^XMA11\n
This extrinsic function allows the user to view and, potentially, change the
type of a message to "Information Only".\n
Usage: S X=$$INFO^XMA11(XMZ)\n
Where: XMZ = Message Number (IEN in file 3.9)\n\n
Always returns a "0" (zero) and whatever would be returned by a DIE call.\n
Invokes DIE call in interactive mode.\n\n
Example:\n
S X=$$INFO(XMZ)\n
INFORMATION ONLY?: ?
If "YES", the message will be considered "INFORMATION ONLY" for all
recipients.
Choose from:
y YES
n NO INFORMATION ONLY?: ??
This field, if set to "YES", will cause all recipients to be considered
"INFORMATION ONLY", which disables responses to the message.\n
If a sender wishes to individually restrict responses, "INFO:" before
the recipient's names will restrict their responses.\n
Messages which are broadcast (by naming a recipient "*"), are
automatically
set to INFORMATION ONLY.
Choose from:
y YES
n NO INFORMATION ONLY?:", "", "", ""], ["1142", "MESSAGE SUBJECT API", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
This API contains the following functions:\n
$$SUBCHK^XMGAPI0 - validate a proposed message subject
$$SUBGET^XMGAPI0 - retrieve the subject of a message", "", "XMGAPI0", ""], ["1143", "MESSAGE HEADER API", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
This API contains the following function:\n
$$NET^XMRENT - Get message header information", "", "XMRENT", ""], ["1144", "MESSAGE INFO API", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
This API contains the following function:\n
$$HDR^XMGAPI2 - retrieve information about a message.", "", "XMGAPI2", ""], ["1145", "REPLY TO / ANSWER A MESSAGE API", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
The APIs (functions) in this DBIA send non-interactive
replies and answers.\n
$$ENT^XMA2R - Send a reply to a message. Add a response to the response chain
of original message.\n
$$ENTA^XMA2R - Send an answer to a message. Create a new message (rather than
adding a response to the response chain of original message).", "", "XMA2R", ""], ["1146", "MAIL GROUP API", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
This mail group API contains the following entry
points:\n
$$DM^XMBGRP Delete local members from a mail group.
$$MG^XMBGRP Create a new mail group or add local members to an existing mail
group.", "", "XMBGRP", ""], ["1147", "LOOKUP / CREATE BASKET", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
This function looks up a mail basket name and returns
its IEN. If the basket doesn't exist, the basket will be created and the IEN
of the newly created basket will be returned.", "", "XMAD2", ""], ["1148", "MAILMAN: Interactive control of a port", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
Device and Line Checking\n
GO^XMCTLK\n
This routine allows one to interactively use a device and displays keyboard
entry and data coming down the line.\n
Usage: D GO^XMCTLK\n
Note: DHCP programming environment is assumed (initialized through the
execution of D ^XUP or sign-on through ^XUS). All I/O from the keyboard and
device chosen are echoed on screen. It is good for testing devices, Network
outgoing points, etc. What is displayed on the screen may be captured into a
mail message. Type an "A" to communicate with TalkMan.", "", "XMCTLK", ""], ["1149", "MAILMAN: User Question & Answer Driver and Validator", "Routine", "MAILMAN", "1995/02/20", "", "Retired", "Supported", "", "
NOTICE! NOTICE! NOTICE!\n
XMAREAD supported calls are being RETIRED. Use FileMan's ^DIR instead.\n
^XMAREAD contains the following application programmer functions:\n
$$READ^XMAREAD(prompt,question_type,default,anti-illegals_flag,.help_array) is
a question and answer driver that will allow the caller to specify a question
type, a prompt and a default.\n
$$CHECK^XMAREAD(question_type,string-to-be-tested) is a silent form of
$$READ^XMAREAD, e.g. it does not ask questions.\n\n\n\n
$$READ^XMAREAD(prompt,question_type,default,anti-illegals_flag,.help_array)\n
This function is a question and answer driver that will allow the caller to
specify a question type, a prompt and a default. The senders' exact input or
the default (except in the case where a "Yes" or "No" question is answered) is
returned to the caller. All basic input checking is completed without
changing or setting any variables.\n
Suggestions for Improvement to this interface are welcomed.\n\n
The way the function is used is as follows:\n
Usage: S X=$$READ^XMAREAD(A,B,C,D,.E)\n
Where: A (prompt) is a string that will be used as a prompt
B (question_type) is a question type C (default) is the default
answer to the questions
D (no_illegals_flag) If non-zero, do not store illegal characters
E (.help_array) is the array of help text (leading period is
required!)\n\n
There are four different types of questions (second parameter):\n
U Abort (This question type will always append the message
"Enter <RET> to continue, "^" to abort")
F Free Text
N Number
Y Yes or No\n\n
Illegal characters are control characters and any of these:
@^!()#~_-=%$|[]\\""><\n\n
The value returnable for each type is:\n
Type Handling\n
U Whatever the user types -- the caller must interpret it.\n
F A string of 3-30 characters which does not contain any control
characters or @, ^, !, (, ), #, -, _, =, %, $, |, [, ], \\,", <, >. If the
third parameter is non-zero and not null or the variable XMREADNO exists,
special characters are allowed. Otherwise only numbers, spaces and letters
are accepted.\n
N Only integers are acceptable inputs.\n
Y Any leading substrings of "Yes" or "No" are acceptable. In either
case, "1" is returned for Yes, "0" for No.\n\n\n
$$CHECK^XMAREAD(Y,Z)\n
This function is the same as $$READ^XMAREAD, except it does not ask questions.
It merely puts any answers through a validity check.\n
Usage: S X=$$CHECK^XMAREAD(Y,Z)\n
Where: Y = The Type (U,N,F, or Y)
Z = The input to be validated\n
If the input is valid, the null string is returned. If the input is NOT
valid, a text string which documents why the string is not valid is returned.", "", "XMAREAD", ""], ["1150", "RESEQUENCE MESSAGES API", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
This API resequences the messages in your basket.", "", "XMA03", ""], ["1151", "MAILMAN: Server API", "Routine", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "", "
^XMS1 contains the following application programmer
functions:\n
$$STATUS^XMS1(MSGIEN,RDUZ) which extracts the status from network messages
only.\n
$$SRVTIME(MSGIEN,RDUZ,Status) which sets status of recipients in a message.\n\n\n\n\n
Appendix 1 -- Message Server Protocol\n\n
Overview\n
A server is an option which is invoked when a mail message that has been
addressed to it has been delivered. As an option, many of the parameters
associated with the servers are embedded in the definition of the option.
Therefore, in order to understand servers completely, you should refer to the
server documentation in Kernel 7.0 manuals. Options are listed in the Menu
Management documentation.\n
Servers may or may not receive data. The received data usually comes in the
form of the text of the message being delivered to it, but the data may also
be pointed to by the message, and exist in the system either because it was
there in the beginning, or because it arrived independently.\n
Servers may be addressed from a remote site. A server on DNS may receive a
message addressed to it from DNS. In fact, this is very common. There are
security features as parameters of the option that has been designated as a
server because of the fact. Please be aware of these security parameters.
Messages addressed to servers will not be scheduled if security is not passed.
Filegrams work through use of a server. Data is loaded into a mail message,
addressed and when delivered, processed by the filegram server into the
receiving database.\n
Servers are always invoked through tasks that are set up when the message is
delivered into the system locally or over the network. One of the options is
to "Run Immediately". Then the task is scheduled to run "NOW".\n
However, tasks may not need to be scheduled at all because the system manager
has stated so in the entry for the server in the Option file or because of a
problem. See the Menu Management documentation in the MailMan Technical
Manual and Systems Management Guide for more information concerning this.
Server Statuses\n
Server recipients are recorded in the recipient chain of a message and appear
similarly to other users. MailMan enters statuses on its own as stages in the
server process are reached. First, the message is marked as "Awaiting
Server". This indicates that the message has been received and the option is
a valid one. At this point, a task has been created to actually invoke
MenuMan to schedule or perform the service (option) required.\n
The last status which MailMan sets is "Served", which means that MenuMan has
been called successfully and MenuMan has either performed the task in the case
of a server that runs immediately, or that some other action has been done.\n
At this point, a task could be scheduled to invoke the server or simply a
message could be sent to indicate that the task exists and needs to be
scheduled, or some other action that was required was performed. MenuMan has
its own statuses which will be used.\n\n
$$SRVTIME^XMS1\n
This extrinsic function sets status of recipients in a message.\n
Usage: S X=$$SRVTIME^XMS1(A,B,C)\n
Where: A = XMZ (message number)
B = A string representing the recipient name
C = Status is free-text (String less than nine (9)
characters in length)\n
If successful, X = 0
...or If unsuccessful, X will be a number followed by a human
readable error\n
Addressing a Server\n
To address a server, precede the recipient name with "S." (e.g., S.XMECHO).
This example sends a message to the Mail Man Echo Tester server. "S." must be
followed by an option name from the Option file in the Target Domain. If not,
a "Recipient not Found" error will occur.\n
A "Recipient Ambiguous" error will occur, if there is more than one option
whose name partially matches the name addressed.\n
The District Registry server for admitting a new patient could be addressed as
follows:\n
S.DGDISTADMIT@DNS\n
The message is destined for the DGDISTADMIT option at San Francisco. Replies
to this message would be from this same name.\n\n
Writing a Server Program\n
The server communicates with mail messages in specific ways. Code is used to
interface the server to the message system. The code below returns the
original message to the sender:\n
ECHO ;
K XMY
S XMSUB=$E("Server echo of'"_XMBSUB_"`",1,65)
S XMY(XMFROM)="",XMTXT="^XMB(3.9,"_XMZ_",2,"
D ^XMD
Q\n
In this example, the variable XMFROM contains the sender address and is
supplied to the server when invoked. Other variables also exist upon
invocation of the server.\n
The XMF.1 example server program is supplied with MailMan. XMF1 uses some of
the other variables supplied to the server.\n
Execute variable XMREC to read a line of the message. XMER and XMRG are
returned.
XMER This variable returns the execution status of XMREC. XMER<0, if there
is no more message text to read. The value of XMER will be zero (0), if XMRG
is being returned as non-null. XMRG, in that case, will have as its value the
text of the next line of the message.\n
XMRG The value of XMRG will be the next line of message text. XMRG will
always be defined, though it will be null when XMER<0.\n
XMPOS This variable contains the current position of the text returned in the
variable XMGR. It is initialized if it is undefined, but should be killed by
the server when it is finished "Reading" the message.\n
Here's another example of code, this time from XMF1:\n
S XMA=0
A ;
X XMREC ; Receive a line
I $D(XMER) G Q;XMER<0 ; Check for end of message
S XMA=XMA+1 ; Increment local line count
S XMTEXT(XMA)=XMRG ; Set local array
G A ; Go back for another line\n
Double Serving Messages\n
On occasion, the transmission/receive process is interrupted by a system
back-up. It appears to result in the same message being served twice. The
Audit Log for the Options file shows two messages with the same message number
and subject, but with different Date/Times and Job Numbers.\n\n
To avoid this, application servers should be written such that they check for
and avoid processing of the same message being delivered to any particular
server. MailMan transparently checks this and does not deliver twice to mail
boxes. However, devices and servers do not have mail boxes to check against.
Servers can have some understanding of special mail baskets in the
Postmaster's mail box and can be written to check for duplicate deliveries
(See reference XMAIC entry points in the Callable Routines section of the
Technical Manual and System Manager's Guide).", "", "XMS1", ""], ["1152", "VAM", "Routine", "MINIMAL PATIENT DATASET", "1995/02/23", "APPROVED", "Active", "Private", "", "", "", "VAMPAPI0", ""], ["1153", "PACKAGE FILE REFERENCES CLEANUP", "File", "KERNEL", "1995/02/24", "APPROVED", "Active", "Controlled Subscription", "9.4", "
Loop through the "C" cross-reference on the PACKAGE
file and delete any extra entries with the subscribing package namespace.
Where necessary, the name of a package may be changed to make it unique.", "", "", ""], ["1154", "DIC(45.7,", "File", "REGISTRATION", "1995/03/02", "APPROVED", "Active", "Supported", "45.7", "
The integration agreement allows reading (with FileMan
only) the SPECIALTY field (#1) of the FACILITY TREATING SPECIALTY file
(#45.7).", "", "", ""], ["1155", "DBIA1155", "File", "ORDER ENTRY/RESULTS REPORTING", "1995/03/08", "APPROVED", "Active", "Controlled Subscription", "100.9", "
This DBIA allows references to the OE/RR Notifications
(#100.9) file.", "", "", ""], ["1156", "DBIA1156", "Routine", "HEALTH SUMMARY", "1995/03/08", "APPROVED", "Active", "Private", "", "
Progress Notes rtn ^GMRPNCW is checking
$L($T(CS^GMTSCW)) to ascertain if the 'Advance Directive' component exported
with GMTS*2.5*15 has been installed before proceeding with the enhanced CWAD
display.", "", "GMTSCW", ""], ["1157", "XPDMENU", "Routine", "KERNEL", "1995/03/08", "APPROVED", "Active", "Supported", "", "
Extrinsic functions and API calls that can be used to
manage Options in the Options file. The LKOPT function is used to lookup all
options. The ADD and DELETE functions are used to add/delete menu items. The
OUT, RENAME, LOCK, and RLOCK are APIs used to populate certain fields for a
given option.", "", "XPDMENU", "2018/05/16"], ["1159", "DBIA1159", "Routine", "REGISTRATION", "1995/03/30", "APPROVED", "Active", "Private", "", "
The IVM package files new Means Tests into PIMS Means
Test module. This routine contains utilities for audit changes to Means
Tests.", "", "DGMTAUD", ""], ["1160", "ONCOLOGY FILE NAME CLEAN-UP", "File", "1", "1995/03/14", "APPROVED", "Active", "Private", "1", "
Clean-up of old file names.", "", "", ""], ["1161", "DBIA1161-A", "File", "DRG GROUPER", "1995/03/14", "", "Retired", "Private", "", "
Converts IDC9 codes to there text equivalents", "", "", ""], ["1162", "DBIA1161-B", "File", "REGISTRATION", "1995/03/14", "APPROVED", "Active", "Controlled Subscription", "43.4", "
Convert speciality code to its text equivalent", "", "", ""], ["1163", "DBIA1161-C", "File", "SCHEDULING", "1995/03/14", "APPROVED", "Active", "Private", "40.7", "
Convert Speciality code to its text equivalent", "", "", ""], ["1164", "DBIA1161-D", "File", "REGISTRATION", "1995/03/14", "APPROVED", "Active", "Private", "42.4", "
Convert speciality code to text equivalent", "", "", ""], ["1165", "DBAI1165", "File", "MAILMAN", "1995/03/14", "", "Withdrawn", "Private", "4.2", "
Used to build PPP DOMAIN XREF file (#1020.8). This is
a file of station numbers and domains.", "", "", ""], ["1166", "DBIA1166", "File", "PATIENT DATA EXCHANGE", "1995/03/16", "APPROVED", "Retired", "Private", "394.61", "
Used to verify and extract PDX transaction information", "", "", ""], ["1167", "DBIA1167", "Other", "1", "1995/04/14", "APPROVED", "Active", "Private", "", "
When sites run Mental Health V. 5.01 inits and they
have the DSM3 ^DIC(627, file that has the 2nd and 3rd pieces flipped the
install gracefully aborts and tells the user that the DSM3 file is missing
conversion node(s)!! The DSM conversion cannot continue and the correct
versions of this file should have been installed during the Mental Health V.
5.01 initialization process.\n
Permission from the FILEMAN community to do the following:
1. Hard KILL the node ^DIC(627,310.1) at END+1^YSD4PRE.
2. Reverse the values of the 2nd and third pieces on line
Q+36^YSINI035.\n
All routine changes will be sent out in patch YS*5.01*6.", "", "YSINI02Q", ""], ["1168", "FILE 124.2 B CROSS-REFERENCE CHANGE", "File", "1", "1995/03/21", "APPROVED", "Active", "Private", "0", "
Since the .01 field of the TG Term (124.6) file is 2-60
characters in length, and there is no need to add a second regular
cross-reference, the Text Generator would request an exemption to modify the
"B" cross- reference so that it uses 60 characters instead of 30.", "", "", ""], ["1169", "DBIA1169-A", "File", "HEALTH LEVEL SEVEN", "1995/03/21", "APPROVED", "Active", "Controlled Subscription", "771.5", "
Check for existance of version 2.2 in 771.5. If
missing add via Fileman", "", "", ""], ["1170", "DBIA1169-B", "File", "HEALTH LEVEL SEVEN", "1997/07/29", "APPROVED", "Active", "Controlled Subscription", "771.2", "
Checks and adds "ADR" message type if it does not exist
in HL7 MESSAGE TYPE file (#771.2).\n
This DBIA is being revised for version 1.6 of HL7.\n
Applications wishing to export interfaces may have the need to update specific
HL7 reference files with entries relevant to the current HL7 standard or
VA-specific 'Z' segments.\n
Applications may read/update the following files using KIDS or documented VA
Fileman calls following written notification and approval of an appropriate
official in Technical Integration.\n
771.2 HL7 MESSAGE TYPE 771.1 HL7 FIELD 771.3 HL7 SEGMENT 771.5 HL7 VERSION
779.001 HL7 EVENT TYPE CODE", "", "", ""], ["1171", "DBIA1171", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1995/03/21", "", "Under Revision", "Private", "74", "
The Radiology Package will reserve field 2005 of file
#74 to be used as a multiple for pointers to file #2005. This field will
first be supported in Radiology/Nuclear Medicine Version 4.5. Imaging will
write pointers to field 2005 of file #74.\n
In addition, Imaging reads the 'NO PURGE' node to determine if images should
be purged. If this node is set the Image Purge routine will not delete images
associated to the case study (radiology case number). Direct global read is
required due to the massive amount of image transactions acquired at sites.\n
As of 12/05/2019 (MAG*3.0*231) radiology allows Imaging to read the zero
^RARPT(DA,0) global directly and with VA FileMan.", "", "", ""], ["1172", "DBIA1172", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "APPROVED", "Active", "Controlled Subscription", "70", "
As of 12/05/2019 VistA Radiology gives Imaging
permission to read file #70 ^RADPT(DA,0) directly and with VA FileMan.\n
VistA Radiology grants permission to VistA Imaging (VI) to read cross-
reference ^RADPT('AO'.", "", "", "2023/01/10"], ["1174", "DBIA1174", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "", "Under Revision", "Private", "71", "
VistA Radiology gives permission to Imaging (VI) to
read the entire zero node of the RAD/NUC MED PROCEDURES (#71) file directly
and with VA FileMan.\n
VistA Radiology gives permission to Imaging (VI) to read the MODALITY field
(#.01) of the MODALITY sub-file (71.0731) directly and with VA FileMan.", "", "", ""], ["1175", "DBIA1175", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2003/08/12", "APPROVED", "Active", "Controlled Subscription", "72", "
Radiology gives permission to Imaging to read file #72
(^RA).", "", "", ""], ["1176", "DBIA1176", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "", "Retired", "Private", "74", "
Radiology gives permission to Imaging to read file #74
(^RARPT).\n", "", "", ""], ["1177", "DBIA1177", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "APPROVED", "Active", "Private", "", "
Radiology gives permission to Imaging to call ^RARTR to
display a radiology report. This will be called with RARPT set to the
internal entry number for the report to be displayed.\n\n", "", "RARTR", ""], ["1178", "DBIA1178", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "APPROVED", "Active", "Controlled Subscription", "", "
Radiology gives permission to Imaging to call
CREATE^RARIC to write data to the ^RARPT global. This will be called after RA
variables are set as done by RAPTLU (for example, RADTE, RACN, RADFN, RADTI,
RACNI, etc).\n
A report created through this call by the Imaging Package is a skeletal report
that is there solely for the purpose of providing a place to store the Imaging
pointer in Field 2005. This is necessary because images are very often
captured prior to the report transcription.\n", "", "RARIC", "2009/08/05"], ["1179", "DBIA1179", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "APPROVED", "Active", "Private", "", "
Radiology gives permission to Imaging to call PTR^RARIC
to write data to the ^RARPT global. This is called with RARPT set to the
internal entry number of the radiology report file and MAGGP set to the
internal entry number for the image/object in File 2005. MAGGP will be set
into file 74 as the pointer to the image/object.\n", "", "RARIC", "2009/08/05"], ["1180", "DBIA1180", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "APPROVED", "Active", "Private", "", "
Radiology gives Imaging permission to call UP1^RAUTL1
when updating the Interpreting Radiologist (Primary Interpreting Resident, or
Primary Interpreting Staff) from the Imaging VistARad Workstation software.", "", "RAUTL1", ""], ["1181", "DGPM MOVEMENT EVENT", "Other", "REGISTRATION", "1995/03/23", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by the registration,
discharge, or transfer of a patient. Actions from any application area that
are dependent on this event may be added to this event upon approval of the
DBIC.\n
The variable DGQUIET -MUST- be checked before doing writes to the screen.
E.g., W:'$G(DGQUIET) !!,"Updating appointment status..."\n
Please note: If a package has an installation which affects one of the
protocols on DGPM MOVEMENT EVENTS, we strongly urge you to disable the
following options during installation:\n
Admit a Patient DG ADMIT PATIENT
Transfer a Patient DG TRANSFER PATIENT
Treating Specialty Transfer DG TREATING TRANSFER
Check-in Lodger DGPM CHECK-IN
Lodger Check-out DGPM CHECK-OUT
Discharge a Patient DG DISCHARGE PATIENT
Disposition and Application DG DISPOSITION APPLICATION
Extended Bed Control DG BED CONTROL EXTENDED
Load/Edit PTF Data DG PTF SCREEN
Quick Load/Edit PTF Data DG PTF QUICK LOAD
Enter/Edit an IRT DGJ IRT ENTER/EDIT", "", "", ""], ["1182", "NATIONAL DATA BASE CALL TO IB", "Routine", "INTEGRATED BILLING", "1995/03/24", "", "Withdrawn", "Private", "", "
National Data Base Routine (RCNR4) calls $$CRIT^IBRFN2
to get insurance information.", "", "IBRFN2", ""], ["1183", "Health Summary extract routine for Problem List", "Routine", "PROBLEM LIST", "1995/03/28", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMPLHS", "2015/08/12"], ["1184", "GMTSLTR", "Routine", "HEALTH SUMMARY", "1995/03/29", "APPROVED", "Active", "Private", "", "
Progress Notes uses the Health Summary package to print
large letters between locations when batch prting PNs.\n
I $L($T(^GMTSLTR)) S GMTSLTR=$P(^SC(GMRPCO,0),U,2) D ^GMTSLTR", "", "GMTSLTR", ""], ["1185", "DELETE OPTION QUEUING INFORMATION", "File", "KERNEL", "1995/03/30", "APPROVED", "Active", "Private", "19", "
We have been tasked with turning off the ODS software.
As part of that, we would like to unschedule the nightly background job. The
following code will be used in a one time clean-up routine:\n
S DGVER=$$VERSION^XPDUTL("XU")
S DIC="^DIC(19,",DIC(0)="QMZ",X="A1B2 BACKGROUND JOB" D ^DIC S (DGIEN,DA)=+Y
I DA'>0 G ENQ ; background job not in option file
I DGVER<8 S DR="200///@;201///@;202///@;203///@",DIE=DIC D ^DIE
I DGVER'<8 S DIK="^DIC(19.2," F DA=0:0 S DA=$O(^DIC(19.2,"B",DGIEN,DA)) Q:'DA
D ^DIK", "", "DGYMODS", ""], ["1186", "OPTION SCHEDULING FILE ACCESS", "File", "KERNEL", "1995/03/30", "APPROVED", "Active", "Private", "19.2", "
If a site is running KERNEL 8 or higher, we'd like to
delete all entries in the SCHEDULED OPTIONS file for the ODS BACKGROUND JOB.
Code is as follows:\n
S DGVER=$$VERSION^XPDUTL("XU")
S DIC="^DIC(19,",DIC(0)="QMZ",X="A1B2 BACKGROUND JOB" D ^DIC S
(DGIEN,DA)=+Y
I DA'>0 G ENQ ; background job not in option file
I DGVER<8 S DR="200///@;201///@;202///@;203///@",DIE=DIC D ^DIE
I DGVER'<8 S DIK="^DIC(19.2," F DA=0:0 S DA=$O(^DIC(19.2,"B",DGIEN,DA)) Q:'DA
D ^DIK", "", "", ""], ["1187", "DBIA1187", "File", "REGISTRATION", "1995/03/30", "APPROVED", "Active", "Private", "408.34", "
The IVM package files new Means Tests in the PIMS Means
Test module. IVM requests permission to read from the SOURCE OF INCOME TEST
file.", "", "", ""], ["1188", "DBIA1188", "File", "REGISTRATION", "1995/03/30", "APPROVED", "Active", "Private", "408.41", "
The IVM package files new Means Tests in the PIMS Means
Test module. IVM requests permission to read from the Means Test CHANGES
file.", "", "", ""], ["1189", "DBIA1189-A", "File", "CLINICAL PROCEDURES", "1995/04/03", "APPROVED", "Active", "Private", "", "
The purpose of this agreement is to provide access to
the Medicine package (custodian) by the Imaging package (subscriber) for the
purpose of creating a new Medicine package entry (stub:Pt ID, Date/time) as a
holder of an Imaging pointer or set of Imaging pointers. The Imaging pointers
are set in the field 2005, as descendants of the 0 subscript of node 2005 in
each of the following files: Echo(691), Cardiac Cath(691.1), EKG(691.5),
Hematology(694), Endoscopy(699), Generalized Procedure(699.5), and
Rheumatology(701).\n
In addition, the MEDICAL PATIENT field (location 0;2) is also permitted for
Direct Global Read.\n
The Imaging routines which perform this function are as follows: MAGMCPT* and
MAGUFILR", "", "", ""], ["1190", "DBIA1189-B", "File", "CLINICAL PROCEDURES", "1995/04/03", "APPROVED", "Active", "Private", "", "
The purpose of this agreement is to provide access to
the Medicine package (custodian) by the Imaging package (subscriber) for the
purpose of editing (including deletion of) Medicine package Image entries.
The Imaging pointers are set in the field 2005, as descendants of the 0
subscript of node 2005 on each of the following files: Echo(691), Cardiac
Cath(691.1), EKG(691.5), Hematology(694), Endoscopy(699), Generalized
Procedure(699.5), and Rheumatology(701).\n
The Imaging routines which perform this function are as follows: MAGMCPT*,
MAGUDEL* and MAGUFILR.", "", "", ""], ["1191", "DBIA1189-C", "File", "CLINICAL PROCEDURES", "2003/10/20", "", "Retired", "Private", "", "
The purpose of this agreement is to provide access to
the Medicine package (custodian) by the Imaging package (subscriber) for the
purpose of displaying Medicine package Summary fields associated with Images.\n
The Imaging functions require direct global read access to the
Procedure/Subspecialty file (697.2), the Image multiple of each of the
Medicine Procedure files listed below, and the Summary field each of the Files
Listed below.\n
Medicine Procedure Files: Echo(691), Cardiac Cath(691.1), EKG(691.5),
Hematology(694), Endoscopy(699), Generalized Procedure(699.5), and
Rheumatology(701).\n
The Imaging routines which perform this function are as follows: MAGDISP,
MAGMIM, MAGSUM, and MAGABLP.", "", "", ""], ["1193", "DBIA1193", "Routine", "CLINICAL PROCEDURES", "1995/04/06", "APPROVED", "Active", "Private", "", "
This privately supported entry point allows the display
the full Medicine report associated with the Imaging Workstation Display. The
routine MCMAGDSP has an entry point of REPRT which, when passed the IEN and
the Medicine package file number, will display the full report to the
Workstation (only). This routine (MCMAGDSP) will be bundled in a patch to
Medicine 2.2. It contains display functionality for the following types of
Medicine procedures: Electrocardiograms (ECG), Echocardiography (ECHO),
Cardiac Catheterization, Hematology (Bone Marrow biopsies and aspirates),
Pulmonary Endoscopies, Gastrointestinal Endoscopies, Medicine Consults,
Generic Procedures, and Rheumatology. This is the current extent of Medicine
procedures that have Imaging pointer fields. This reporting functionality
uses the Procedure/Subspecialty file in tandem with the result files to
determine the type of procedure. This is necessary as many of the results
files share a common structure to house data of different procedure types (as
in different CPTs). The MCMAGDSP routine uses the same compiled print
templates that Medicine uses and there are also calls to utilities of the
common Medicine print driver.", "", "MCMAGDSP", ""], ["1194", "DBIA1194", "Routine", "INTEGRATED BILLING", "1995/04/06", "", "Retired", "Private", "", "", "", "IBARXEU", ""], ["1195", "INPATIENT MEDICATIONS XREF CLEAN UP", "File", "1", "2003/06/10", "", "Retired", "Private", "55", "
Inpatient Medications 4.5 exported the AUDS cross
reference on the START DATE/TIME(#10) field of the UNIT DOSE(#55.06) multiple
of the PHARMACY PATIENT(#55) file. This cross reference is not referenced by
the Inpatient Medications software, and since this field is "hard set", the
cross reference is never set. This causes problems with locally created sort
templates on this field when running VA FILEMAN V21.\n
To elminate this problem, a routine will be exported in PSJ*4.5*12 that will
identify and delete this cross reference from the Data Dictionary.\n
The routine to be used for this is listed below:\n
PSJUTL2 ;B'ham ISC/MLM - REMOVE AUDS XREF FROM 55.06,10 ; 14 Apr 95 / 9:59AM
;;4.5; Inpatient Medications ;**12**;7 Oct 94
;
EN ; Entry point from programmer mode to delete the AUDS xref.
;
W "This routine was exported as part of PSJ*4.5*12 to delete the
AUDS",!
W "cross reference from the PHARMACY PATIENT(#55) file.",!!
N X,DIR
S DIR(0)="Y",DIR("B")="NO",DIR("A")="Delete this cross reference?"
S DIR("?")="Enter ""YES"" to continue with this process or ""NO"" to
abort."
D ^DIR Q:$D(DIRUT)
F X=0:0 S X=$O(^DD(55.06,10,1,X)) Q:'X D
.K:$G(^DD(55.06,10,1,X,0))="55^AUDS" ^DD(55.06,10,1,X)
K ^DD(55,0,"IX","AUDS",55.06,10)
W !!,"Done."
Q\n\n
Inpatient Medications requests a PRIVATE DBIA with VA FILEMAN to directly K
^DD(55.06,10,1,X), where X is the IEN of the AUDS cross reference.", "", "", ""], ["1196", "IMAGING/SURGERY MAGSRIC", "Routine", "IMAGING", "1995/04/13", "APPROVED", "Active", "Private", "", "
The Surgery Package is given permission to call
IM^MAGSRIC to provide image capture capability to users of the operations
options", "", "MAGSRIC", ""], ["1197", "IFCAP FUND CONTROL POINT INFORMATION", "Routine", "GENERIC CODE SHEET", "1995/04/17", "APPROVED", "Active", "Private", "", "
This integration agreement allows Generic Code Sheets
(version 2.0) to call IFCAP routines from within distributed input templates.
The calls will return fund control points and information pertaining to the
fund control point which is used to build the FMS code sheets.", "", "PRCSUTCP", ""], ["1198", "IFCAP FUND CONTROL POINT INFORMATION", "Routine", "IFCAP", "1995/04/17", "APPROVED", "Active", "Private", "", "
This integration agreement allows Generic Code Sheets
(version 2.0) to call IFCAP routines from within distributed input templates.
The calls will return fund control points and information pertaining to the
fund control point which is used to build the FMS code sheets.\n", "", "PRCSUT", ""], ["1199", "IFCAP FUND CONTROL POINT INFORMATION", "Routine", "GENERIC CODE SHEET", "1995/04/17", "APPROVED", "Active", "Private", "", "
This integration agreement allows Generic Code Sheets
(version 2.0) to call IFCAP routines from within distributed input templates.
The calls will return fund control points and information pertaining to the
fund control point which is used to build the FMS code sheets.\n", "", "PRC0C", ""], ["1200", "INPATIENT MEDICATIONS XREF CLEAN UP", "File", "1", "2003/06/10", "", "Retired", "Private", "55", "
Inpatient Medications 4.5 exported the AUDS cross
reference on the START DATE/TIME(#10) field of the UNIT DOSE(#55.06) multiple
of the PHARMACY PATIENT(#55) file. This cross reference is not referenced by
the Inpatient\n
Medications software, and since this field is "hard set", the cross reference
is never set. This causes problems with locally created sort templates on this
field when running VA FILEMAN V21.\n
To elminate this problem, a routine will be exported in PSJ*4.5*12 that will
identify and delete this cross reference from the Data Dictionary.\n
The routine to be used for this is listed below:\n
PSJUTL2 ;B'ham ISC/MLM - REMOVE AUDS XREF FROM 55.06,10 ; 14 Apr 95 / 9:59AM
;;4.5; Inpatient Medications ;**12**;7 Oct 94
;
EN ; Entry point from programmer mode to delete the AUDS xref.
;
W "This routine was exported as part of PSJ*4.5*12 to delete the
AUDS",!
W "cross reference from the PHARMACY PATIENT(#55) file.",!!
N X,DIR
S DIR(0)="Y",DIR("B")="NO",DIR("A")="Delete this cross reference?"\n
S DIR("?")="Enter ""YES"" to continue with this process or ""NO"" to
abort."
D ^DIR Q:$D(DIRUT)
F X=0:0 S X=$O(^DD(55.06,10,1,X)) Q:'X D
.K:$G(^DD(55.06,10,1,X,0))="55^AUDS" ^DD(55.06,10,1,X)
K ^DD(55,0,"IX","AUDS",55.06,10)
W !!,"Done."
Q\n
Inpatient Medications requests a PRIVATE DBIA with VA FILEMAN to directly K
^DD(55.06,0,"IX","AUDS",55.06,10).", "", "", ""], ["1201", "KERNEL transport MM routine", "Routine", "MAILMAN", "1995/04/20", "APPROVED", "Active", "Private", "", "
Kernel needs to transport MailMan routine XMGAPI4 to
sites untill MailMan 7.2 is installed. KIDS will check and only install the
routine if it doesn't already exist.", "", "XMGAPI4", ""], ["1202", "MAGING/SURGERY CLEANUP", "Routine", "IMAGING", "1995/04/21", "APPROVED", "Active", "Private", "", "
The Surgery Package is given permission to call
CLEAN^MAGSRIC to kill MAG namespaced local variables on exit from routine(s)
using IM^MAGSRIC for image capture.", "", "MAGSRIC", ""], ["1203", "SURGERY/IMAGING REPORT DISPLAY", "Routine", "SURGERY", "1995/04/21", "APPROVED", "Active", "Controlled Subscription", "", "
The Imaging Package is given permission to call SROPRPT
to display surgery operation reports.", "", "SROPRPT", ""], ["1204", "SURGERY/IMAGING FIELD 2005", "File", "SURGERY", "1995/04/21", "APPROVED", "Active", "Private", "130", "
The Surgery Package will reserve field 2005 of File 130
for an IMAGE multiple pointing to File 2005. (The Surgery Package will be
adding this field to its package as soon as feasible.) Imaging Package is
given permission to set and delete pointers from Field 2005 of File 130.", "", "", ""], ["1205", "KERNEL 8 transport of ORBUTL", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1995/04/21", "APPROVED", "Active", "Private", "", "
Kernel 8.0 needs to transport the routine ORBUTL. This
routine was modified in order to work with Kernel 8.0. The changes are not
compatible with Kernel 7.1. This is a one time release.", "", "ORBUTL", ""], ["1206", "DBIA1206", "File", "1", "1995/04/28", "APPROVED", "Active", "Private", "", "
During the installation of IFCAP v. 5.0 (namespace PRC)
and IFCAP's Generic Inventory Package v. 5.0 (namespace PRCP), direct MUMPS
kills of erroneous ^DD nodes need to be done in the Pre-Init After User Commit
and the Post-Init routines. The specific nodes are listed below:
1. IFCAP (namespace PRC):
a. Field descriptions (node 21) for files and sub-files in
the range from 410 to 443.99. The kills are done in the
DESCRIP^PRC5INS1 module, which is called from PRC5A, the Pre-Init
After User Commit routine. The clean up is necessary as the new
description may have fewer lines than the previous description,
and, with double question mark help, the left-over lines
may appear.
b. Erroneous Computed Field nodes for fields currently defined as
Free-Text:
^DD(420.01,2,9.01), ^DD(420.01,2,9.1), ^DD(420.01,2,9.2)
^DD(420.01,3,9.01), ^DD(420.01,3,9.1), ^DD(420.01,3,9.2)
The kills are done in routine PRC5A, the Pre-Init After User Commit
routine.
c. Erroneous "IX" node:
^DD(442.8,0,"IX","AE",442.8,.01)
The kill is done in routine PRC5A.
d. Erroneous "NM" node:
^DD(420.11,0,"NM","SUBACCOUNT")
The kill is done in routine PRC5A.
2. Generic Inventory Package of IFCAP (namespace PRCP):
a. Field descriptions (node 21) from files and sub-files in the
range from 445 to 447. The kills are done in the DESCRIP^PRC5INS1
module, which is called from PRCP5PRE, the Pre-Init After User
Commit routine.
b. Erroneous "ID" node:
^DD(445.121,0,"ID","WRITE")
The kill is done in routine PRCP5POS, the Post-Init routine.
c. Erroneous "NM" node:
^DD(445.121,0,"NM","MEMBER OF SET/PACK")
The kill is done in routine PRCP5POS.", "", "", ""], ["1207", "DBIA1207", "Routine", "CLINICAL PROCEDURES", "1995/05/04", "APPROVED", "Active", "Supported", "", "
1) Decision Support System (DSS) interface\n
Functional description:
This process provides a reporting mechanism to the DSS package. The
subscriber passes a Starting date and ending date to the MCARDSS routine and
the TMP global will store the result records in an arbitrary order. The
results include the following required fields: Date and Time the record is
released, Provider signing or signed for, CPT code, Patient identification\n
Software components: Routines -- ^MCARDSS, ^MCBLD, ^MCPTF File(s) --
Procedure Term File: ^MCAR(694.8 Menu Options: None\n
Technical overview: The DSS application makes a parameterized call to
^MCARDSS(Start_date,End_date) with dates in regular Fileman date/time format.
Only results which have a valid signature, CPT code, date signed, and valid
patient ID will be returned in the ^TMP($J,count) scratch global. The result
is stored as follows: Provider ID(DUZ)^Patient ID(DFN)^Date/time signed(FM
DATE/TIME)^CPT code for example --
^TMP(1231231,3)=194^2323^295101010.1232^93005", "", "MCARDSS", ""], ["1208", "DBIA1208", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "APPROVED", "Active", "Private", "", "
Radiology gives permission to Imaging to call
SET^RAPSET1. The purpose of this call is to set up some variables needed to
do exam look-ups, etc.", "", "RAPSET1", ""], ["1209", "DBIA1209", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1995/05/05", "APPROVED", "Active", "Private", "", "
Radiology gives permission to Imaging to call ^RACNLU
look up a patient by radiology case number. SET^RAPSET1 must be called first
to set variables. This is an interactive routine, so other input is provided
by the user.\n", "", "RACNLU", ""], ["1210", "PRINT 1010F WITH ENCOUNTER FORMS", "Routine", "REGISTRATION", "1997/04/10", "APPROVED", "Active", "Private", "", "
Allow AICS to print 1010F's for patients who require a
means test or thier means test will expire within a specified number of days.", "", "DGMTP", ""], ["1218", "ENGINEERING/IMAGING", "File", "ENGINEERING", "1995/05/05", "", "Retired", "Private", "6914", "
Imaging Package is given permission to point to File
6914.", "", "", ""], ["1219", "ENNGINEERING/IMAGING SPACE", "File", "ENGINEERING", "1995/05/05", "", "Retired", "Private", "6928", "
The Imaging Package is given permission to point to
File 6928.", "", "", ""], ["1220", "DBIA1220-A", "File", "NATIONAL DRUG FILE", "1995/05/09", "APPROVED", "Active", "Private", "50.6", "
The Consolidated Mail Outpatient Pharmacy package will
extract informational data on a daily basis.", "", "", ""], ["1221", "DBIA1220-B", "File", "OUTPATIENT PHARMACY", "1998/07/31", "", "Retired", "Private", "52", "
The Consolidated Mail Outpatient Pharmacy package will
extract data on a daily basis. Fields noted with write access will be updated
on a daily basis. The extensive overhead associated with building transmission
data prevents the CMOP software from utilizing the supported reference for
Outpatient Pharmacy Version 7.0 as described in DBIA 1878. This agreement is
PRIVATE and designed for use ONLY by the CMOP software.", "", "", ""], ["1222", "DBIA1220-C", "File", "OUTPATIENT PHARMACY", "1995/05/09", "", "Retired", "Private", "52.5", "
The Consolidated Mail Outpatient Pharmacy package will
extract data from this file on a daily basis. The CMOP INDICATOR field (#3) is
created by the CMOP software and is used to manage the prescription data for
CMOP transmission.", "", "", ""], ["1223", "DBIA1220-D", "File", "PHARMACY DATA MANAGEMENT", "1995/05/09", "APPROVED", "Active", "Private", "54", "
The Consolidated Mail Outpatient Pharmacy package
modified the input transform for the .01 to prevent the editing of the first
21 entries after the CMOP installation. This will provide consistency in the
drug warnings transmitted with drugs to be dispensed by the CMOP.", "", "", ""], ["1224", "DBIA1220-E", "File", "PHARMACY DATA MANAGEMENT", "1995/05/08", "", "Retired", "Private", "50", "
The CONSOLIDATED MAIL OUTPATIENT PHARMACY package
creates and maintains data in these fields.", "", "", ""], ["1227", "TREATING SPECIALTY INACTIVATION", "Routine", "REGISTRATION", "1995/09/28", "", "Withdrawn", "Supported", "", "
This is a supported reference to screen on active
Facility Treating Specialties or Specialties.", "", "DGACT", ""], ["1230", "PRINT A MESSAGE API", "Routine", "MAILMAN", "1995/05/17", "APPROVED", "Active", "Supported", "", "
The entry points in this API print messages:
- PR2^XMA0 print a message with a header
- HDR^XMA0 print a message without a header
- ENTPRT^XMA0 interactive print a message", "", "XMA0", ""], ["1231", "DBIA1231", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Controlled Subscription", "52.6", "
This file was previously in Inpatient Meds versions up
to 5.0. Now it has moved to Pharmacy Data Management 1.0. It is used
extensively throughout our routines. With this move, we are requesting read
and write access to the entire file and cross-references via FileMan utilities
and direct writes/reads.", "", "", ""], ["1232", "INTERACTIVE REPLY TO A MESSAGE API", "Routine", "MAILMAN", "1999/06/23", "APPROVED", "Active", "Supported", "", "
This API lets the user interactively reply to a message
in his mailbox. There are two ways to invoke it: D ^XMAH1 or D ENTA^XMAH1.", "", "XMAH1", ""], ["1233", "INTERACTIVE ANSWER OR SEND A MESSAGE API", "Routine", "MAILMAN", "1995/05/24", "APPROVED", "Active", "Supported", "", "
This API lets the user answer a message or send a
message.\n
When you send an answer to a message, the original message is copied into the
answer, the user edits the answer, the user's network signature is appended to
the end of the answer, and the whole thing is automatically addressed to the
sender of the original message.", "", "XMA11A", ""], ["1234", "DBIA1234", "File", "KERNEL", "1995/05/25", "APPROVED", "Active", "Controlled Subscription", "3.1", "", "", "", ""], ["1235", "DBIA1235", "File", "PROSTHETICS", "1995/05/26", "APPROVED", "Active", "Private", "662", "
ROES V2.0 references the Pros Disability Code File to
print and display a patient's rated disabilities. Access is read only for the
ARABIC DISABILITY NAME (.01) field and the "B" cross-reference of the .01
field.", "", "", ""], ["1236", "DBIA1236", "Routine", "CLINICAL PROCEDURES", "1995/06/16", "APPROVED", "Active", "Private", "", "
To support Medicine 2.2 with 4 new components the
$$HL7^MCORMN(MESSNUM) entry point needs to be called. This interface will
allow Health Summary to get patient data for a breif summary, a brief summary
for only abnormal values, a full summary and a full captioned summary. It will
also support the existing one line medicine summary. This interface is setup
in an HL7 compliant manner. HS will need to have the Pateint DFN, Beginning
Date, Ending Date, # of occurrences, and Type of Date (Full or Brief) set into
a message via the ^XMD call. The $$HL7^MCORMN(MESSNUM) call will retrieve the
available data based on the above specifications and using the message number
returned from the ^XMD call. Data that will be returned via the message is
DATE/TIME, PROCEDURE, SUMMARY, PROCEDURE SUMMARY, and the PROCEDURE REPORT.", "", "MCORMN", ""], ["1237", "DBIA1237", "File", "1", "1995/05/31", "APPROVED", "Active", "Private", "", "
The pre-init routines for ROES V2.0 change several file
names, clean up leftover DD nodes, and an obsolete cross-reference. These
changes were suggested by the verifier to maintain consistency throughout the
system.\n
|NOWRAP| 1. The screen on the 'BATTERY TYPE FURNISHED' field is deleted with
a Kill command.\n
GLOBAL REFERENCE:
^DD(791810.0101,.02,12)
^DD(791810.0101,.02,12.1)\n
2. The old name of field 791810.0101 is cleaned up in ORDER^RMPFPOST.
FileMan creates a duplicate NM node when a subfile name changes.\n
GLOBAL REFERENCE:
^DD(791810.0101,0,"NM","TRANSACTION")\n
3. The 'AD' cross-reference on the .01 field of file number 791810 is killed
with a direct kill in EXIT^RMPFPRE routines. The following is a capture of
the code:\n
EXIT F X=0:0 S X=$O(^DD(791810,.01,1,X)) Q:'X D
.K:$G(^DD(791810,.01,1,X,0))="791810^AD^MUMPS" ^DD(791810,.01,1,X)
K ^DD(791810,0,"IX","AD",791810,.01)\n
GLOBAL REFERENCE:
^DD(791810,.01,X,0)
^DD(791810,0,"IX","AD",791810,.01)\n
4. The file names of files 791810, 791810.1, 791810.2, 791812 are changed
using DIE like the following:\n
S DIE=1,DA=701810,DR=".01////STATION ORDER" D ^DIE", "", "", ""], ["1238", "DBIA1238", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/25", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point
VISIT^PXRHS01 to retrieve Visit, ICD-9, CPT, and Provider data. Input data
will be done via parameter passing and output data will be placed in the ^TMP
global in the specified format that is described in this agreement.\n
Entry point: VISIT(DFN,ENDDT,BEGDT,OCCLIM,CATCODE,EXTRCODE,TIMEORD)\n
INPUT : DFN - Pointer to PATIENT file (#2)
ENDDT - Ending date/time in internal FileMan format
- Defaults to today's date at 11:59 pm
BEGDT - Beginning date/time in internal FileMan format
- Defaults to one year prior to today's date
OCCLIM - Maximum number of visits returned
CATCODE - Pattern Match which controls visit data that is
returned (Can include multiple codes)
A = AMBULATORY
H = HOSPITALIZATION
I = IN HOSPITAL
C = CHART REVIEW
T = TELECOMMUNICATIONS
N = NOT FOUND
S = DAY SURGERY
O = OBSERVATION
E = EVENT (HISTORICAL)
R = NURSING HOME
D = DAILY HOSPITALIZATION DATA
X = ANCILLARY PACKAGE DAILY DATA
EXTRCODE - Pattern Match indicating which optional
data is returned (Can be multiple)
P = return PROVIDER data
C = return CPT (procedure) data
D = return ICD-9 (diagnosis) data
TIMEORD - Order visits on same day are indexed
Default is inverse cronological order
1 = Time order in regular cronological order\n
OUTPUT :
Data from VISIT (9000010) file except for hosp. loc. abbr.
^TMP("PXHSV",$J,InvExDt,COUNT,0) = VISIT/ADMIT DATE&TIME [I;.01]
^ TYPE [E;.03] ^ LOC. OF ENCOUNTER [E;.06]
^ SERVICE CATEGORY [E;.07] ^ CHECK OUT DATE&TIME [I;.18]
^ HOSPITAL LOCATION [E;.22] ^ HOSP. LOC. ABBREVIATION [E;44;1]
^ OUTSIDE LOCATION [E;2101] ^ CLINIC [E;.08]
^ WALK IN/APPT [E;.16] ^ LEVEL OF SERVICE [E;.17]
^ ELIGIBILITY [E;.21]
Data from V CPT (9000010.18) file
^TMP("PXHSV",$J,InvExDt,COUNT,"C",X) = CPT [I;.01]
^ PROVIDER NARRATIVE [E;.04]
^TMP("PXHSV",$J,InvExDt,COUNT,"C",X, MODIFIER [E;1/.01]) = ""
Data from V POV (9000010.07) file
^TMP("PXHSV",$J,InvExDt,COUNT,"D",X) = POV [I;.01]
^ MODIFIER [E;.06] ^ CAUSE OF DX [E;.07]
^ PLACE OF ACCIDENT [E;.11] ^ PRIMARY/SECONDARY [E;.12]
^TMP("PXHSV",$J,InvExDt,COUNT,"D",X,"N") = PROVIDER NARRATIVE [E;.04]
Data from V PROVIDER (9000010.06) file
^TMP("PXHSV",$J,InvExDt,COUNT,"P",X) = PROVIDER [E;.01]
^ PRIMARY/SECONDARY [E;.04]
Data from V HOSPITALIZATION (9000010.02) file (If Service Category is for
hospitalization)
^TMP("PXHSV",$J,InvExDt,COUNT,"H",X) = DATE OF DISCHARGE [I;.01]
^ ADMITTING DX [E;.12]\n
[] = [I(nternal)/E(xternal); Optional file #; Record #]
Subscripts:
InvExDt - Inverse FileMan date of DATE OF visit [.01]
Count - # of entry", "", "PXRHS01", ""], ["1239", "IMMUNIZATION EXTRACT", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to retrieve immunization data. Subscribers can retrieve data on
administrations, contraindications, and refusals.", "", "PXRHS03", "2023/10/10"], ["1240", "DBIA1240", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Private", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point
SKIN^PXRHS04 to retrieve skin test data. Input data will be done via parameter
passing and output data will be placed in the ^TMP global in the specified
format that is described in this agreement.\n
Entry point: SKIN(DFN)\n
INPUT : DFN - Pointer to PATIENT file (#2)\n
OUTPUT : Data from V SKIN TEST (9000010.12) file
^TMP("PXS,$J,SKIN,InvDt,IFN,0) = SKIN TEST [E;.01]
^ EVENT DATE/TIME or VISIT/ADMIT DATE&TIME [I;1201 or .03]
^ RESULTS CODE [I;.04] ^ RESULTS [E;.04] ^ READING [E;.05]
^ DATE READ [I;.06] ^ ORDERING PROVIDER [E;1202]
^ CLINIC [3;1203] ^ ENCOUNTER PROVIDER [E;1204]
^TMP("PXS",$J,SKIN,InvDt,IFN,1) = ^ HOSPITAL LOCATION [E;1205]
^ HOSP. LOC. ABBREVIATION [ E;44;1]
^ LOC OF ENCOUNTER [E;9000010;.06] ^ OUTSIDE LOC [E;9000010;2101]
^TMP("PXS",$J,SKIN,InvDt,IFN,"S") = DATA SOURCE [E;80102]\n
[] = [I(nternal)/E(xternal); Optional file #; Record #]
Subscripts:
SKIN - Skin Test name
InvDt - Inverse FileMan date of DATE OF event or visit
IFN - Internal Record #
******", "", "PXRHS04", ""], ["1241", "DBIA1241", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point
EXAM^PXRHS05 to retrieve Exam data.Input data will be done via parameter
passing and output data will be placed in the ^TMP global in the specified
format that is described in this agreement.\n
Entry point: EXAM(DFN,ENDDT,BEGDT,OCCLIM)\n
INPUT : DFN - Pointer to PATIENT file (#2)
ENDDT - Ending date/time in internal FileMan format
- Defaults to today's date at 11:59 pm
BEGDT - Beginning date/time in internal FileMan format
- Defaults to one year prior to today's date
OCCLIM - Maximum # of each type of exam returned OUTPUT :
Data from V EXAM (9000010.13) file
^TMP("PXE,$J,EXAM,InvDt,IFN,0) = EXAM [E;.01]
^ EVENT DATE/TIME or VISIT/ADMIT DATE&TIME [I;1201 or .03]
^ RESULTS CODE [I;.04] ^ RESULTS [E;.04]
^ ORDERING PROVIDER [E;1202] ^ CLINIC [3;1203]
^ ENCOUNTER PROVIDER [E;1204] ^
^TMP("PXE",$J,EXAM,InvDt,IFN,1) = HOSPITAL LOCATION [E;1205]
^ HOSP. LOC. ABBREVIATION [E;44;1]
^ LOC OF ENCOUNTER [E;9000010;.06] ^ OUTSIDE LOC [E;9000010;2101]
^TMP("PXE",$J,EXAM,InvDt,IFN,"S") = DATA SOURCE [E;80102]\n
[] = [I(nternal)/E(xternal); Optional file #; Record #]
Subscripts:
EXAM - EXAM name
InvDt - Inverse FileMan date of DATE OF event or visit
IFN - Internal Record #", "", "PXRHS05", ""], ["1242", "DBIA1242", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Private", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point
TREAT^PXRHS06 to retrieve Treatment data. Input data will be done via
parameter passing and output data will be placed in the ^TMP global in the
specified format that is described in this agreement.\n
Entry point: TREAT(DFN,ENDDT,BEGDT,OCCLIM,CATCODE)\n
INPUT : DFN - Pointer to PATIENT file (#2)
ENDDT - Ending date/time in internal FileMan format
- Defaults to today's date at 11:59 pm
BEGDT - Beginning date/time in internal FileMan format
- Defaults to one year prior to today's date
OCCLIM - Maximum number of days for which data is returned
(If multiple visits on a given day, all data for
these visit will be returned) or an "R" for
only the most recent occurrence of each topic
Note: If event date is used, it may appear that too
many occurrences are retrieved but it is
based on visit date not event date.
returned (Can include multiple codes)
CATCODE - Pattern Match which controls visit data that is
A = AMBULATORY
H = HOSPITALIZATION
I = IN HOSPITAL
C = CHART REVIEW
T = TELECOMMUNICATIONS
N = NOT FOUND
S = DAY SURGERY
O = OBSERVATION
E = EVENT (HISTORICAL)
R = NURSING HOME
D = DAILY HOSPITALIZATION DATA
X = ANCILLARY PACKAGE DAILY DATA\n
OUTPUT :
Data from V TREATMENT (9000010.15) file
^TMP("PXT,$J,InvDt,TREAT,IFN,0) = TREATMENT [E;.01]
^ EVENT DATE/TIME or VISIT/ADMIT DATE&TIME [I;1201 or .03]
^ HOW MANY [I;.04] ^ ORDERING PROVIDER [E;1202]
^ CLINIC [3;1203] ^ ENCOUNTER PROVIDER [E;1204]
^TMP("PXT",$J,InvDt,TREAT,IFN,1) = HOSPITAL LOCATION [E;1205]
^ HOSP. LOC. ABBREVIATION [E;44;1]
^ LOC OF ENCOUNTER [E;9000010;.06] ^ OUTSIDE LOC [E;9000010;2101]
^TMP("PXT",$J,InvDt,TREAT,IFN,"S") = DATA SOURCE [E;80102]
^TMP("PXT",$J,InvDt,TREAT,IFN,"P") = PROVIDER NARRATIVE [E;.06]
^TMP("PXT",$J,InvDt,TREAT,IFN,"PNC") = PROVIDER NARR. CATEGORY [E;80201]\n
[] = [I(nternal)/E(xternal); Optional file # ; Record #]
Subscripts:
InvDt - Inverse FileMan date of DATE OF event or visit minus time
TREAT - TREATMENT PROVIDED
IFN - Internal Record #", "", "PXRHS06", ""], ["1243", "DBIA1243", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Private", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point HF^PXRHS07
to retrieve Health Factor data. Input data will be done via parameter passing
and output data will be placed in the ^TMP global in the specified format that
is described in this agreement.\n
Entry point: HF(DFN,ENDDT,BEGDT,OCCLIM,ITEMS)\n
INPUT : DFN - Pointer to PATIENT file (#2)
ENDDT - Ending date/time in internal FileMan format
- Defaults to today's date at 11:59 pm
BEGDT - Beginning date/time in internal FileMan format
- Defaults to one year prior to today's date
OCCLIM - Maximum number of days for which data is returned
for each Health Factors item.
If multiple visits on a given day, all data for
these visit will be returned.
Note: If event date is used, it may appear that too
many occurrences are retrieved but it is
it is based on visit date not event date.
ITEMS - Optional array containing a selected list of HF
Categories. If not used will get all catergories of
health factors. OUTPUT :
Data from V HEALTH FACTORS (9000010.23) file
^TMP("PXF,$J,HFC,HF,InvDt,IFN,0) = Health Factor [E;.01]
^ EVENT DATE/TIME or VISIT/ADMIT DATE&TIME [I;1201 or .03]
^ SHORT NAME [E;9999999.64;.04] ^ LEVEL/SEVERITY [E;.04]
^ ORDERING PROVIDER [E;1202] ^ CLINIC [3;1203]
^ ENCOUNTER PROVIDER [E;1204]
^TMP("PXF",$J,HFC,HF,InvDt,IFN,1) = HOSPITAL LOCATION [E;1205]
^ HOSP. LOC. ABBREVIATION [E;44;1]
^ LOC OF ENCOUNTER [E;9000010;.06] ^ OUTSIDE LOC [E;9000010;2101]
^TMP("PXF",$J,HFC,HF,InvDt,IFN,"S") = DATA SOURCE [E;80102]\n
[] = [I(nternal)/E(xternal); Optional file #; Record #]
Subscripts:
HFC - Health Factor Category name
HF - Health Factor name
InvDt - Inverse FileMan date of DATE OF event or visit
IFN - Internal Record #", "", "PXRHS07", ""], ["1244", "DBIA1244", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Private", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point
MEAS^PXRHS09 to retrieve Measurement data. Input data will be done via
parameter passing and output data will be placed in the ^TMP global in the
specified format that is described in this agreement.\n
Entry point: MEAS(DFN,ENDDT,BEGDT,OCCLIM)\n
INPUT : DFN - Pointer to PATIENT file (#2)
ENDDT - Ending date/time in internal FileMan format
- Defaults to today's date at 11:59 pm
BEGDT - Beginning date/time in internal FileMan format
- Defaults to one year prior to today's date
OCCLIM - Maximum number of days for which data is returned
(If multiple visits on a given day, all data for
these visit will be returned)
Note: If event date is used, it may appear that too
many occurrences are retrieved but it is
based on visit date not event date. OUTPUT : Data
from V MEASUREMENT (9000010.01) file
^TMP("PXM",$J,TYPE,InvDt,IFN,0) = TYPE [E;.01]
^ MEASUREMENT TYPE DESCRIPTION [E;9999999;.02]
^ EVENT DATE/TIME or VISIT/ADMIT DATE&TIME [I;1201 or .03]
^ VALUE [E;.04] ^ ORDERING PROVIDER [E;1202]
^ CLINIC [3;1203] ^ ENCOUNTER PROVIDER [E;1204]
^TMP("PXM",$J,TYPE,InvDt,IFN,1) = HOSPITAL LOCATION [E;1205]
^ HOSP. LOC. ABBREVIATION [E;44;1]
^ LOC OF ENCOUNTER [E;9000010;.06] ^ OUTSIDE LOC [E;9000010;2101]
^TMP("PXM",$J,TYPE,InvDt,IFN,"S") = DATA SOURCE [E;80102]\n
[] = [I(nternal)/E(xternal); Optional file #; Record #]
Subscripts:
TYPE - Measurement Type
InvDt - Inverse FileMan date of DATE OF event or visit
IFN - Internal Record #", "", "PXRHS09", ""], ["1245", "ENGINEERING XREF CLEAN UP", "File", "1", "1995/07/20", "APPROVED", "Active", "Private", "6914", "
Engineering exported a series of cross references in
the Equipment Inv (#6914) file to support the upload of equipment data to the
ISMS system. These mumps cross references were never activated because the
ISMS system was not brought on line. These cross references are now obsolete
and should be removed from the Equipment Inv file.\n
The following cross references will be deleted with patch EN*7*25 using code
in a PRE-INIT AFTER USER COMMIT routine.\n
CROSS-REFERENCE FIELD # FIELD NAME
--------------- ------- ----------------------
AI1 1 MANUFACTURER
AI2 2 PARENT SYSTEM
AI27 4 MODEL
AI3 5 SERIAL #
AI0 7 TYPE OF ENTRY
AI5 10 VENDOR POINTER
AI6 11 PURCHASE ORDER #
AI7 12 ACQUISITION VALUE
AI8 12.5 LEASE COST
AI9 13 ACQUISITION DATE
AI10 13.5 ACQUISITION SOURCE
AI11 15 LIFE EXPECTANCY
AI12 16 REPLACEMENT DATE
AI13 18 CATEGORY STOCK NUMBER
AI26 19 CMR
AI14 20 USE STATUS
AI15 20.1 OWNERSHIP
AI16 20.5 TURN-IN DATE
AI17 22 DISPOSITION DATE
AI18 23 PHYSICAL INVENTORY DATE
AI19 31 DISPOSITION METHOD
AI20 32 DISPOSITION VALUE
AI21 33 CONTROLLED ITEM?
AI22 34 CAPITALIZED?
AI23 36 COST CENTER
AI24 38 GENERAL LEDGER ACCOUNT
AI25 39 YALD CODE
AI28 51 REPLACING (ENTRY NUMBER)\n\n
Code similar to the following will be used in the pre-init to delete the cross
references from the data dictionary.\n
ENXGIPR ;WIRMFO/SAB-PRE INIT ;7/21/95
;;7.0;ENGINEERING;**25**;Aug 17, 1993
N ENFX
Q:'$D(DIFROM)
W !,"Performing Pre-Init...",!
XREF ; delete any obsolete ISMS cross references
W !,"Deleting obsolete xrefs from Equipment Inv (#6914) file..."
F ENFX="1^AI1","2^AI2","4^AI27","5^AI3","7^AI0","10^AI5",
"11^AI6","12^AI 7","12.5^AI8","13^AI9","13.5^AI10" D DELXREF
($P(ENFX,U),$P(ENFX,U,2))
F ENFX="15^AI11","16^AI12","18^AI13","19^AI26","20^AI14"
,"20.1^AI15","20.5^AI16","22^AI17" D DELXREF($P(ENFX,U),$P(ENFX,U,2))
F ENFX="23^AI18","31^AI19","32^AI20","33^AI21","34^AI22",
"36^AI23","38^AI24","39^AI25","51^AI28" D DELXREF($P(ENFX,U),$P(ENFX,U,2))
XREFEND ; end of delete obsolete ISMS cross references
EXIT ;
W !,"Completed Pre-Init",!
Q
DELXREF(ENF,ENX) ; for field number ENF delete xref ENX
N ENI
Q:'$D(^DD(6914,0,"IX",ENX,6914,ENF)) ; already deleted
S ENI=0 F S ENI=$O(^DD(6914,ENF,1,ENI)) Q:'ENI D
.K:$G(^DD(6914,ENF,1,ENI,0))=("6914^"_ENX_"^MUMPS")
^DD(6914,ENF,1,ENI)
K ^DD(6914,0,"IX",ENX,6914,ENF)
K:'$O(^DD(6914,ENF,1,0)) ^DD(6914,"IX",ENF) ; no xrefs left on field
W !," ",ENX," xref deleted from field ",ENF
Q\n
The following DD nodes may be deleted\n
^DD(6914,field number,1,ien for xref)\n
^DD(6914,0,"IX",xref,6914,field number)\n
^DD(6914,"IX",field number) This will only be done if there are no cross
references left on the field. (i.e. '$O(^DD(6914,field number,1,0)) is true).", "", "", ""], ["1246", "DGPMDDCF CALLS", "Routine", "REGISTRATION", "1995/07/20", "APPROVED", "Active", "Supported", "", "
This agreement allows other packages to call the
following tags in the routine DGPMDDCF: WIN, RIN, BOS, AUTH, and OPER. These
calls return info on whether wards and beds are in service and the number of
beds in service, authorized, and operating for a given ward.", "", "DGPMDDCF", ""], ["1247", "DBIA1247", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Private", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point
VISIT^PXRHS12 to retrieve Hospitalization Visit, ICD-9, CPT, and Provider
data. Input data will be done via parameter passing and output data will be
placed in the ^TMP global in the specified format that is described in this
agreement.\n
Entry point: VISIT(DFN,ENDDT,BEGDT,OCCLIM)\n
INPUT : DFN - Pointer to PATIENT file (#2)
ENDDT - Ending date/time in internal FileMan format
- Defaults to today's date at 11:59 pm
BEGDT - Beginning date/time in internal FileMan format
- Defaults to one year prior to today's date
OCCLIM - Maximum number of visits returned OUTPUT :
Data from VISIT (9000010) file except for hosp. loc. abbr.
^TMP("PXHSV",$J,InvExDt,COUNT,0) = VISIT/ADMIT DATE&TIME [I;.01]
^ TYPE [E;.03] ^ LOC. OF ENCOUNTER [E;.06]
^ SERVICE CATEGORY [E;.07] ^ CHECK OUT DATE&TIME [I;.18]
^ HOSPITAL LOCATION [E;.22] ^ HOSP. LOC. ABBREVIATION [E;44;1]
^ OUTSIDE LOCATION [E;2101] ^ CLINIC [E;.08]
^ WALK IN/APPT [E;.16] ^ LEVEL OF SERVICE [E;.17]
^ ELIGIBILITY [E;.21]
Data from V CPT (9000010.18) file
^TMP("PXHSV",$J,InvExDt,COUNT,"C",X) = CPT [I;.01]
^ PROVIDER NARRATIVE [E;.04]
^TMP("PXHSV",$J,InvExDt,COUNT,"C",X,MODIFIER [E;1/.01]) = ""
Data from V POV (9000010.07) file
^TMP("PXHSV",$J,InvExDt,COUNT,"D",X) = POV [I;.01]
^ MODIFIER [E;.06] ^ CAUSE OF DX [E;.07]
^ PLACE OF ACCIDENT [E;.11] ^ PRIMARY/SECONDARY [E;.12]
^TMP("PXHSV",$J,InvExDt,COUNT,"D",X,"N") = PROVIDER NARRATIVE [E;.04]
Data from V PROVIDER (9000010.06) file
^TMP("PXHSV",$J,InvExDt,COUNT,"P",X) = PROVIDER [E;.01]
^ PRIMARY/SECONDARY [E;.04]
Data from V HOSPITALIZATION (9000010.02) file (If Service Category
is for hospitalization)
^TMP("PXHSV",$J,InvExDt,COUNT,"H",X) = DATE OF DISCHARGE [I;.01]
^ ADMITTING DX [E;.12]\n
[] = [I(nternal)/E(xternal); Optional file #; Record #]
Subscripts:
InvExDt - Inverse FileMan date of DATE OF visit [.01]
Count - # of entry", "", "PXRHS12", ""], ["1248", "DBIA1248", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/26", "APPROVED", "Active", "Private", "", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to call the entry point
MEAS^PXRHS20 to retrieve Measurement data. Input data will be done via
parameter passing and output data will be placed in the ^TMP global in the
specified format that is described in this agreement.\n
Entry point: MEAS(DFN,PATDOB,SEX,ENDDT,BEGDT,OCCLIM,MSRPANEL) INPUT: DFN
- Pointer to PATIENT file (#2)
PATDOB - Patient's Date of Birth in MM/DD/YY Format
SEX - Patient's Sex ("M" for Male and "F" for Female)
OCCLIM - Maximum number of days for which data is returned
(If multiple visits on a given day, all data for
these visit will be returned)
Note: If event date is used, it may appear that too
many occurrences are retrieved but it is
based on visit date not event date.
MSRPANEL - Pointer to Health Summary Meas Panel (9001017) file
OUTPUT:
Data from V MEASUREMENT (9000010.01) file
^TMP("PXM",$J,InvDt,ORDER,IFN) = VALUE [E;.04]
^ Optional error note for BMI and RW values
If a transform exists in file 9001017 for this panel item, it will
be applied to VALUE.
Data from HEALTH SUMMARY MEAS PANEL (9001017) file
^TMP("PXF",$J,PNAME,ORDER)= PANEL COMPONENT [E;9001017.01;1]
^ FIELD WIDTH [E;9001017.01;2] ^ LABEL [E;9001017.01;3]
^ NOTE TO DISPLAY [E;9001017.01;5]\n
[] = [I(nternal)/E(xternal); Optional file #; Record #]
Subscripts:
InvDt - Inverse FileMan date of DATE OF event or visitr visit
TYPE - Measurement Type
IFN - Internal Record #
ORDER - Order in Panel
PNAME - Measurement Panel Name", "", "PXRHS20", ""], ["1249", "DIC(10,", "File", "REGISTRATION", "1995/05/30", "APPROVED", "Active", "Private", "10", "
The integration agreement allows reading (with FileMan
only) the ABBREVIATION field (#2) of the RACE file (#10).", "", "", ""], ["1251", "DBIA 1251", "File", "PCE PATIENT CARE ENCOUNTER", "1995/08/03", "APPROVED", "Active", "Private", "150.9", "
PCE debugging utility calls Fileman to display the
entry number 1 to the user so that they can review it.", "", "", ""], ["1252", "PRIMARY CARE INPUT AND OUTPUT API CALLS", "Routine", "SCHEDULING", "1995/06/20", "APPROVED", "Active", "Supported", "", "
SDUTL3 contains 2 input APIs and 3 output APIs which
allow enter of/return of the CURRENT PC PRACTITIONER and CURRENT PC TEAM. The
three output APIs will continue to be supported. The two input APIs will be
supported as long as the two fields exist in the patient file. The approximate
time for deletion of these fields is March 1 2000.", "", "SDUTL3", ""], ["1253", "DBIA1253", "File", "PROBLEM LIST", "1995/05/30", "APPROVED", "Active", "Controlled Subscription", "9000011", "
The Health Summary Package desires to set up an
integration agreement with the Problem List Package to access the Problem
(#900011) file. Health Summary needs to check if the Problem List file
contains a specific ICD9 code (diagnosis) for a given patient. The "AC" cross
reference is checked to get problem entries for a patient. DFN is the internal
patient record number. The Diagnosis pointer (1st piece of the 0 node) and
Date Entered (8th piece of the 0 node) are retrieved for each record found.\n
This is done in the following manner: S GMTSHRFE="" F S
GMTSHRFE=$O(^AUPNPROB("AC",DFN,GMTSHRFE)) Q:'GMTSHRFE S
Y=$P(^AUPNPROB(GMTSHRFE,0),U),GMTSHRID=$P(^(0),U,8),
GMTSHRIC=$P(^ICD9(Y,0),U)_" "", "", "", ""], ["1254", "DBIA1254", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/05/30", "APPROVED", "Active", "Private", "9000001", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to access the ^PXRHS13 routine to
get a patient's location of home.", "", "PXRHS13", ""], ["1255", "DBIA1255", "Routine", "REGISTRATION", "1995/08/08", "APPROVED", "Active", "Private", "", "
The IVM package files new Means Tests into the PIMS
Means Test module. This routine contains utilities for Means Test processing.\n", "", "DGMTSCU2", ""], ["1256", "DBIA1256", "File", "CLINICAL REMINDERS", "1995/08/03", "APPROVED", "Active", "Controlled Subscription", "811.9", "
This IA is for packages needing to point to the
Reminder Definition (#811.9) file. The Selection Item (.01) field in the
Structure Multiple (field 1) of the Health Summary Type (#142) file points to
the file #811.9. The Selection File (.01) field in the Selection File Multiple
(Field 7) of the Health Summary Component (#142.1) file points to the file
#811.9. Health Summary also requires the ability to add the application group
"GMTS" ^DIC(811.9) when the Reminder Definition file exists. This is done with
a VA Fileman call in the Health Summary Preinit Routine.", "", "", ""], ["1257", "DBIA1257", "Routine", "REGISTRATION", "1995/08/08", "APPROVED", "Active", "Private", "", "
This routine contains utilities for Means Tests/Copay
processing.", "", "DGMTCOU1", "2013/02/15"], ["1258", "VARIABLES IN PROGRAMMER HOOKS", "File", "1", "1995/08/08", "", "Withdrawn", "Supported", "", "
The following DBIA describes the variables that are
available and what values these variables are set to within programmer hooks.
(define programmer hook here)", "", "", ""], ["1259", "DBIA1259", "File", "PCE PATIENT CARE ENCOUNTER", "1995/05/30", "APPROVED", "Active", "Private", "9001017", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to point to the Health Summary MEAS
Panel (#9001017) file. The Selection Item (.01) field in the Structure
Multiple (field 1) of the Health Summary Type (#142) file points to this file.
The Selection File (.01) field in the Selection File multiple (field 7) of the
Health Summary Component (#142.1) file points to this file. Health Summary
also requries the ability to add the application group "GMTS" to ^DIC(9001017)
when the Health Summary MEAS Panel file exists. This is done with a fileman
call.", "", "", ""], ["1261", "DBIA1261", "File", "PROBLEM LIST", "1995/08/09", "APPROVED", "Active", "Controlled Subscription", "9000011", "\n
The Patient Care Encounter Package would like to do a direct global read on a
Problem List node.", "", "", ""], ["1262", "DBIA1262", "File", "KERNEL", "1995/08/09", "", "Pending", "Supported", "200", "
The PAID 4.0 development team is requesting permission
to add a new field to the NEW PERSON file and a new cross-reference to the NEW
PERSON SSN field.\n
The new field will be PAID EMPLOYEE (#450) and will be a pointer to the PAID
EMPLOYEE (#450) file. This field will be uneditable.\n
The new MUMPS cross-reference will be the AJ cross-reference on the SSN (#9)
field. This cross-reference will set or kill the NEW PERSON pointer in the
PAID EMPLOYEE file and the PAID EMPLOYEE pointer in the NEW PERSON file
whenever the SSN value is changed or deleted.", "", "", ""], ["1264", "DBIA1264", "File", "CPT/HCPCS CODES", "1995/08/09", "", "Retired", "Controlled Subscription", "81", "\n
This is an agreement to look at several fields in the CPT FILE #81 using
Fileman.", "", "", ""], ["1265", "OE/RR conversion needs sched admissions", "File", "REGISTRATION", "1997/10/20", "APPROVED", "Active", "Private", "41.1", "
The OE/RR version 3 conversion would like permission to
loop through the "C" index of the scheduled admission file. It will then
access the 0 node to get the PATIENT pointer.", "", "", ""], ["1267", "DBIA1265-C IMMUNIZATION", "File", "INDIAN HEALTH SERVICE", "1995/08/11", "", "Pending", "Private", "9999999.14", "
The PCE Patient Care Encounter Package requests a DBIA
to distribute the Indian Health Services IMMUNIZATION file (9999999.14)\n
STANDARD DATA DICTIONARY #9999999.14 -- IMMUNIZATION FILE 08/11/95 PAGE 1
STORED IN ^AUTTIMM( (38 ENTRIES) SITE: ISCSLC UCI: DVA,DEV\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
------------------------------------------------------------------
This file is a list of Immunizations and associated codes developed
specifically for use in the IHS. This file contains a full descriptive name
for each Immunization, plus a shortened name of Ten Characters which is used
on the Health Summary and on reports where space is limited, plus a Two Digit
Code for each Immunization.\n\n\n
IDENTIFIED BY: SHORT NAME (#.02)\n
POINTED TO BY: SELECTION ITEM field (#4) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#142.944) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
FILE ENTRY field (#.01) of the PCE CODE MAPPING
File (#811.1)
RELATED SUPPORTING FILE ENTRY field (#.02) of the
PCE CODE MAPPING File (#811.1)
MULTIPLE VALUES field (#3101) of the PCE TAXOTIPLE VALUES field
(#.01) of the MULTIPLE VALUES
sub-field (#811.23101) of the PCE TAXONOMY File
(#811.2)
SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#811.944) of the FILE SELECTION
CRITERIA sub-field (#811.94) of the PCE
REMINDER/MAINTENANCE ITEM File (#811.9)
IMMUNIZATION field (#.01) of the V IMMUNIZATION
File (#9000010.11)
IMMUNIZATION field (#.04) of the IMMUNIZATION LOT
File (#9999999.41)\n\n
CROSS REFERENCED BY: NAME(B), MNEMONIC(B), CODE(C), SHORT NAME(D)\n\n
9999999.14,.01NAME 0;1 FREE TEXT (Required)\n
INPUT TRANSFORM: K:$L(X)>45!($L(X)<3)!'(X'?1P.E)!(X
'?.ANP) X
LAST EDITED: APR 11, 1988
HELP-PROMPT: ANSWER WITH IMMUNIZATION (3-45
CHARACTERS)
DESCRIPTION: This is the name of the
Immunization (e.g. Tetanus
Toxoid).\n
Enter the Name of the Immunization
using 3 to 45 characters.\n
CROSS-REFERENCE: 9999999.14^B
1)= S ^AUTTIMM("B",$E(X,1,30),DA)=""
2)= K ^AUTTIMM("B",$E(X,1,30),DA)\n\n
9999999.14,.02SHORT NAME 0;2 FREE TEXT (Required)\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>10!($L(X)<2) X
LAST EDITED: OCT 08, 1986
HELP-PROMPT: ANSWER WITH A SHORT NAME (2-10
CHARACTERS)
DESCRIPTION: This is the "Short" name for this
immunization such as an acronym,
Nick name, or other name by which
it might be called (e.g. Tet Tox).\n\n
Enter the short name using 2 to 10
characters (e.g. Tet Tox).\n
CROSS-REFERENCE: 9999999.14^D
1)= S ^AUTTIMM("D",$E(X,1,30),DA)=
""\n
2)= K ^AUTTIMM("D",$E(X,1,30),DA)\n\n
9999999.14,.03CODE 0;3 FREE TEXT (Required)\n\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>2!($L(X)<2)!'(X?2N) X I $D(X),
$D(^AUTTIMM("C",X)),'$D(^AUTTIMM("
C",X,DA)) K X W " Already used!
"
LAST EDITED: JAN 25, 1994
HELP-PROMPT: ANSWER MUST BE 2 CHARACTERS IN
LENGTH
DESCRIPTION: This is a 2 digit code that
represents the immunization.\n
Enter a 2 digit code that
represents the immunization code.\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PR OGRAMMER\n
CROSS-REFERENCE: 9999999.10),DA)=""\n\n
2)= K ^AUTTIMM("C",$E(X,1,30),DA)\n\n
9999999.14,.05MAX # IN SERIES 0;5 SET\n
'0' FOR NON-SERIES;
'1' FOR 1;
'2' FOR 2;
'3' FOR 3;
'4' FOR 4;
'5' FOR 5;
'6' FOR 6;
'7' FOR 7;
'8' FOR 8;
LAST EDITED: DEC 09, 1987
DESCRIPTION: (Optional) This is the maximum
number of vaccinations that can be
given for this immunization.\n
Enter the number between 0 and 8
that represents the maximum
allowable vaccinations that can be
given for this immunization.\n\n
9999999.14,.06CHILDHOOD IMMUNIZATION 0;6 SET (Required)\n
'0' FOR NO;
'1' FOR YES;
LAST EDITED: AUG 29, 1988
DESCRIPTION: This is a yes(1)/no(2) answer to
the question "Was this
immunization given during
childhood?"\n
Enter a 0 for no or a 1 for yes.\n\n
9999999.14,8801MNEMONIC 88;1 FREE TEXT\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>3!($L(X)<1) X
LAST EDITED: NOV 04, 1987
HELP-PROMPT: ANSWER MUST BE 1-3 CHARACTERS IN
LENGTH
DESCRIPTION: This is the mnemonic for this
Immunization.\n
Enter a 1 to 3 character mnemonic.\n\n
CROSS-REFERENCE: 9999999.14^B^MNEMONIC
1)= S ^AUTTIMM("B",$E(X,1,30),DA)=
1\n
2)= K ^AUTTIMM("B",$E(X,1,30),DA)\n\n
INPUT TEMPLATE(S):\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):\n
FORM(S)/BLOCK(S):\n", "", "", ""], ["1268", "DBIA1268", "File", "PCE PATIENT CARE ENCOUNTER", "1995/05/31", "APPROVED", "Active", "Private", "9999999.64", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to point to the Health Factors
(#9999999.64) file. The Selection Item (.01) field in the Structure Multiple
(field 1) of the Health Summary Type (#142) file points to the Health Factors
file. The Selection File (.01) field in the Selection File multiple (field 7)
of the Health Summary Component (#142.1) file points to the Health Factors
file. Health Summary also requires the ability to add the application group
"GMTS" ^DIC(9999999.64) when the Health Factors files exists. This is done
with a Fileman Call.", "", "", ""], ["1269", "DBIA1265-D EXAM", "File", "INDIAN HEALTH SERVICE", "1995/08/11", "", "Pending", "Private", "9999999.15", "
The PCE Patient Care Encounter Package requests a DBIA
to distribute the Indian Health Services EXAM file (9999999.15) in the VA\n\n
STANDARD DATA DICTIONARY #9999999.15 -- EXAM FILE 08/11/95 PAGE 1 STORED IN
^AUTTEXAM( (29 ENTRIES) SITE: ISCSLC UCI: DVA,DEV ( VERSION 1T)\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
-----------------------------------------------------------------
This file is a list of Physical Exams and associated codes developed
specifically for use in the IHS for entering Examinations performed on an
Outpatient or Inpatient Encounter. Some of the Exams are used in\n\n\n\n
POINTED TO BY: SELECTION ITEM field (#4) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#142.944) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
MULTIPLE VALUES field (#3101) of the PCE TAXONOMY
File (#811.2)
MULTIPLE VALUES field (#.01) of the MULTIPLE
VALUES sub-field (#811.23101) of the PCE
TAXONOMY File (#811.2)
SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#811.944) of the FILE SELECTION
CRITERIA sub-field (#811.94) of the PCE
REMINDER/MAINTENANCE ITEM File (#811.9)
EXAM field (#.01) of the V EXAM File (#9000010.13)
MEMBERS field (#.01) of the MEMBERS sub-field
(#9001020.15) of the STRUCTURE sub-field
(#9001020.01) of the HEALTH SUMMARY FLOWSHEET
File (#9001020)\n\n
CROSS REFERENCED BY: NAME(B), MNEMONIC(B), CODE(C)\n\n
9999999.15,.01NAME 0;1 FREE TEXT (Required)\n
INPUT TRANSFORM: K:$L(X)>30!($L(X)<3)!'(X'?1P.E)!(
X'?.ANP) X
HELP-PROMPT: ANSWER WITH THE NAME OF THE EXAM
(3-3ON: This is the name of the
examination being given to a
patient.\n
Enter the name of the exam using
3 to 30 characters.\n\n
CROSS-REFERENCE: 9999999.15^B
1)= S ^AUTTEXAM("B",$E(X,1,30),DA
)=""\n
2)= K ^AUTTEXAM("B",$E(X,1,30),DA
)\n\n
9999999.15,.02CODE 0;2 FREE TEXT (Required)\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$
L(X)>2!($L(X)<2)!'(X?2N) X I $D(X
),$D(^AUTTEXAM("C",X)),'$D(^AUTTE
XAM("C",X,DA)) K X W " Already
used! "
LAST EDITED: DEC 22, 1989
HELP-PROMPT: ANSWER MUST BE 2 CHARACTERS IN
LENGTH
DESCRIPTION: This is a 2-digit code associated
with the exam given.\n
Enter a two digit number.\n\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY P ROGRAMMER\n
CROSS-REFERENCE: 9999999.15^C
1)= S ^AUTTEXAM("C",$E(X,1,30),DA
)=""\n
2)= K ^AUTTEXAM("C",$E(X,1,30),DA
)\n\n
9999999.15,.03SEX SPECIFIC 0;3 SET\n
'M' FOR MALE;
'F' FOR FEMALE;
LAST EDITED: FEB 09, 1989
HELP-PROMPT: ENTER M OR F IF THIS EXAM IS SEX
SPECIFIC
DESCRIPTION: (Optional) This is the indicator
for psecifying the sex for which
the exam is given.\n
Enter an "M" for male or an "F"
for Female.\n\n
9999999.15,8801MNEMONIC 88;1 FREE TEXT\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$
L(X)>2!($L(X)<1) X
LAST EDITED: DEC 16, 1985
HELP-PROMPT: ANSWER MUST BE 1-2 CHARACTERS IN
LENGTH
DESCRIPTION: This is a 1 - 2 character
mnemonic for this exam.\n
Enter a 1monic.\n\n
CROSS-REFERENCE: 9999999.15^B^MNEMONIC
1)= S ^AUTTEXAM("B",$E(X,1,30),DA
)=1\n
2)= K ^AUTTEXAM("B",$E(X,1,30),DA
)\n\n
INPUT TEMPLATE(S):\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):\n
FORM(S)/BLOCK(S):\n", "", "", ""], ["1270", "DBIA1265-E TREATMENT", "File", "INDIAN HEALTH SERVICE", "1995/08/11", "", "Pending", "Private", "9999999.17", "
The PCE Patient Care Encounter Package requests a DBIA
to distribute the Indian Health Services TREATMENT file (9999999.17) in the
VA.\n
STANDARD DATA DICTIONARY #9999999.17 -- TREATMENT FILE 08/11/95 PAGE 1
STORED IN ^AUTTTRT( (293 ENTRIES) SITE: ISCSLC UCI: DVA,DEV (V ERSION 1T)\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
------------------------------------------------------------------
This file is a table developed by the IHS for recording Patient Treatments
which are not covered in the ICD-9-CM Procedures. These are primarily Nursing
Activities perfomed during a Patient Visit, such as Ear Irriga- tion, or
Instructions or Counseling given to a patient for a Medical Problem.\n\n\n\n
POINTED TO BY: TREATMENT field (#.01) of the V TREATMENT File
(#9000010.15)\n\n
CROSS REFERENCED BY: NAME(B), MNEMONIC(B), CODE(C)\n\n
9999999.17,.01NAME 0;1 FREE TEXT (Required)\n
INPUT TRANSFORM: K:$L(X)>30!($L(X)<3)!'(X'?1P.E)!(X
'?.ANP) X
HELP-PROMPT: ANSWER WITH TREATMENT NAME (3-30
CHARACTERS)
DESCRIPTION: The name of the treatment that is
being administered.\n
Enter the ntheme of a treatment
using 3 to 30 characters.\n
CROSS-REFERENCE: 9999999.17^B
1)= S ^AUTTTRT("B",$E(X,1,30),DA)=
""\n
2)= K ^AUTTTRT("B",$E(X,1,30),DA)\n\n
9999999.17,.02CODE 0;2 FREE TEXT (Required)\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>6!($L(X)<6)!'(X?6N) X I $D(X),
$D(^AUTTTRT("C",X)),'$D(^AUTTTRT("
C",X,DA)) K X W " Already used!
"
LAST EDITED: DEC 22, 1989
HELP-PROMPT: ANSWER MUSNGTH
DESCRIPTION: This is an IHS code which
represents the treatment being
rendered.\n
Enter a 6 digit code.\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PR OGRAMMER\n
CROSS-REFERENCE: 9999999.17^C
1)= S ^AUTTTRT("C",$E(X,1,30),DA)=
""\n
2)= K ^AUTTTRT("C",$E(X,1,30),DA)\n\n
9999999.17,.03SUMMARY FLAG 0;3 FREE TEXT (Required)\n
INPUT TRANSFORM: K:$L(X)>1!($L(X)<1)!'((X="0")!(X="
1")) X
HELP-PROMPT: ANSWER MUST BE 1 CHARACTER IN
LENGTH\n
9999999.17,8801MNEMONIC 88;1 FREE TEXT\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>6!($L(X)<1) X
LAST EDITED: MAR 16, 1987
HELP-PROMPT: ANSWER MUST BE 1-6 CHARACTERS IN
LENGTH
DESCRIPTION: (Optional) This is a mnemonic for
this treatment.\n\n
CROSS-REFERENCE: 9999999.17^B^MNEMONIC
1)= S ^AUTTTRT("B",$E(X,1,30),DA)=
1\n
2)= K ^AUTTTRT("B",$E(X,1,30),DA)\n\n
INPUT TEMPLATE(S):\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):\n
FORM(S)/BLOCK(S):\n", "", "", ""], ["1271", "DBIA1265-F SKIN TEST", "File", "INDIAN HEALTH SERVICE", "1995/08/11", "", "Pending", "Private", "9999999.28", "
The PCE Patient Care Encounter Package requests a DBIA
to distribute the Indian Health Services SKIN TEST file (9999999.28) in the
VA.\n
STANDARD DATA DICTIONARY #9999999.28 -- SKIN TEST FILE 08/11/95 PAGE 1
STORED IN ^AUTTSK( (9 ENTRIES) SITE: ISCSLC UCI: DVA,DEV (VERS ION 1T)\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
------------------------------------------------------------------
This file contains Skin Tests and their associated codes developed by the IHS.
It consists of a full descriptive name, a Ten Character Abbreviated Name for
the Health Summary and other reports where spaces are limited, plus a Two
Digit Code.\n\n\n\n
POINTED TO BY: SELECTION ITEM field (#4) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#142.944) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
FILE ENTRY field (#.01) of the PCE CODE MAPPING
File (#811.1)
RELATED SUPPORTING FILE ENTRY field (#.02) of the
PCE CODE MAPPING File (#811.1)
MULTIPLE VALUES field (#3101) of the PCE TAXONOMY
File (#811.2)
MULTIPLE VALUES field (#.01) of the MULTIPLE VALUES
sub-field (#811.23101) of the PCE TAXONOMY File
(#811.2)
SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#811.944) of the FILE SELECTION
CRITERIA sub-field (#811.94) of the PCE
REMINDER/MAINTENANCE ITEM File (#811.9)
SKIN TEST field (#.01) of the V SKIN TEST File
(#9000010.12)\n\n
CROSS REFERENCED BY: NAME(B), MNEMONIC(B), CODE(C)\n\n
9999999.28,.01NAME 0;1 FREE TEXT (Required)\n
INPUT TRANSFORM: K:$L(X)>10!($L(X)<3)!'(X'?1P.E)!(X
'?.ANP) X
LAST EDITED: DEC 16, 1985
HELP-PROMPT: ANSWER WITH SKIN TEST NAME (3-10
CHARACTERS)
DESCRIPTION: This is the name of the skin test
(e.g Cocci,PPD).\n
Enter a name using 3 to 10
characters.\n
CROSS-REFERENCE: 9999999.28^B
1)= S ^AUTTSK("B",$E(X,1,30),DA)="
"\n
2)= K ^AUTTSK("B",$E(X,1,30),DA)\n\n
9999999.28,.02CODE 0;2 FREE TEXT (Required)\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>2!($L(X)<2)!'(X?2N) X I $D(X),
$D(^AUTTSK("C",X)),'$D(^AUTTSK("C"
,X,DA)) K X W " Already used! "
LAST EDITED: DEC 22, 1989
HELP-PROMPT: ANSWER MUST BE 2 CHARACTERS IN
LENGTH
DESCRIPTION: This is a 2 character IHS code for
the skin test.\n
Enter a 2 character code.\n\n
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PR OGRAMMER\n
CROSS-REFERENCE: 9999999.28^C
1)= S ^AUTTSK("C",$E(X,1,30),DA)="
"\n
2)= K ^AUTTSK("C",$E(X,1,30),DA)\n\n
9999999.28,8801MNEMONIC 88;1 FREE TEXT\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>2!($L(X)<1) X
LAST EDITED: DEC 16, 1985
HELP-PROMPT: ANSWER MUST BE 1-2 CHARACTERS IN
LENGTH
DESCRIPTION: (Optional) This is a 1-2 character
mnemonic for the skin test.\n
Enter a 1-2 character mnemonic.\n
CROSS-REFERENCE: 9999999.28^B^MNEMONIC
1)= S ^AUTTSK("B",$E(X,1,30),DA)=1
2)= K ^AUTTSK("B",$E(X,1,30),DA)\n\n
INPUT TEMPLATE(S):\n
PRINT TEMPLATE(S):\n
SORT TEMPLATE(S):\n
FORM(S)/BLOCK(S):\n", "", "", ""], ["1273", "DBIA1273", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/08/03", "APPROVED", "Active", "Private", "9000010", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to access the described API to the
Visit (#900010) file.\n
VISIT^PXRHS14(DFN,FROM,RECNO,OCCLIM,CATCODE,PSTAT)\n
INPUT: DFN - Pointer to PATIENT file (#2).
FROM - Index entry from which to begin the list.
Passed by reference.
RECNO - Record number. Passed by reference.
OCCLIM - Maximum number of visits to return.
CATCODE - Pattern Match which controls visit data that is
returned (Can include multiple codes).
A = AMBULATORY
H = HOSPITALIZATION
I = IN HOSPITAL
C = CHART REVIEW
T = TELECOMMUNICATIONS
N = NOT FOUGERY
O = OBSERVATION
E = EVENT (HISTORICAL)
R = NURSING HOME
D = DAILY HOSPITALIZATION DATA
X = ANCILLARY PACKAGE DAILY DATA
PSTAT - Patient Status.
1 = Inpatient
0 or NULL = Outpatient\n
OUTPUT:
Data fro0) file except for hosp. loc. abbr.
^TMP("PXV",$J,InvExDt,RecNo,0) = VISIT/ADMIT DATE&TIME [I;.01]
^ LOC. OF ENCOUNTER [E;.06] ^ SERVICE CATEGORY [E;.07]
^ CLINIC [E;.08] ^ WALK IN/APPT [E;.16]
^ EVALUATION AND MANAGEMENT CODE [E;.17]
^ HOSPITAL LOCATION [E;.22]\n
[] = [I(nternal)/E(xternal); Field #]
Subscripts:
InvExDt - Inverted Visit Date from "AA" x-ref
RecNo - Record Number\n
NOTE: Calling routine is required to delete ^TMP("PXV",$J). It can be deleted
between multiple calls to this entry point or after the calling routine makes
the last call depending on how the data needs to be accumulated.", "", "PXRHS14", ""], ["1274", "DBIA1274", "File", "CPT/HCPCS CODES", "1995/06/01", "", "Retired", "Private", "81", "
The Health Summary Package desires to set up an
integration agreement with the CPT/AMB Procedures Update Package to access the
CPT (#81) file.", "", "", ""], ["1275", "DBIA1275", "File", "DRG GROUPER", "1995/06/01", "", "Retired", "Private", "80", "
The Health Summary Package desires to see up an
integration agreement with the DRG Grouper Package to access the ICD Diagnosis
(#80) file.", "", "", ""], ["1276", "DBIA1276", "File", "DRG GROUPER", "1995/06/01", "", "Retired", "Private", "80.1", "
The Health Summary Package desires to set up an
integration agreement with the DRG Grouper Package to access the ICD
Operation/Procedure (#80.1) file.", "", "", ""], ["1277", "DBIA1277", "Routine", "ACCOUNTS RECEIVABLE", "1995/06/01", "APPROVED", "Active", "Private", "", "
These routine calls are used by Integrated Billing to
determine
(1) How a user may be allowed to delete an Insurance Company
from the INSURANCE COMPANY (#36) file, and
(2) To cause the Accounts Receivable module to re-point the
debtor (which corresponds to the Insurance Company being
deleted) of all applicable AR records to a new debtor.", "", "RCAMINS", ""], ["1278", "DBIA1278", "Routine", "INTEGRATED BILLING", "1995/06/01", "APPROVED", "Active", "Private", "", "\n
The ACCOUNTS RECEIVABLE package will call the entry point BILL in the
routine IBCNSCD1 to allow the IB package to merge or delete the Primary
Insurance Carrier on corresponding bills in IB.", "", "IBCNSCD1", ""], ["1279", "DBIA1279", "Other", "KERNEL", "1995/06/05", "APPROVED", "Active", "Private", "", "
Integrated Billing plans to release the enhancement
patch IB*2*28 within 4-6 weeks. We need to update the zeroth node of an entry
in the ITEM (#10) multiple in one of our menu protocol (file #101) entries.
The easiest way we have found to effect that change is to delete the item from
the menu protocol, and have the onits re-add the item, with the new zero node
in the multiple, back into the menu protocol.\n
We are formally requesting permission to delete the item which points to the
protocol IBCNS QUIT from the menu protocol IBCNSC INSURANCE CO in the
post-init of patch IB*2*28. The item would immediately be re-added by
invoking the onit right after the deletion.", "", "", ""], ["1280", "DBIA1280", "File", "MENTAL HEALTH", "1995/06/06", "APPROVED", "Retired", "Controlled Subscription", "90", "
The Health Summary Package requests of the Mental
Health Package permission to access the Medical Record (#90) file in order to
display/print Mental Health Physical Exam data.\n
This DBIA will be effective until the next version of either Health Summary or
Mental Health at which time a Mental Health API will need to be set up.", "", "", ""], ["1281", "DBIA183 - A", "Routine", "OUTPATIENT PHARMACY", "1995/06/06", "APPROVED", "Active", "Controlled Subscription", "", "\n\n", "", "PSOSD1", ""], ["1282", "OPTION FILE ENTRY/EXIT FIELDS", "File", "KERNEL", "1995/06/26", "APPROVED", "Active", "Private", "19", "
This integration agreement allows the Generic Code
Sheet package version 2.0 to update the OPTION file's (#19) ENTRY and EXIT
ACTION fields (#20 and #15) in the routine GECXPOST. The routine GECXPOST is
distributed with patch GEC*2*2.\n
The routine GECXPOST will change the ENTRY ACTION field from calling an
unsupported Generic Code Sheet entry point to a supported entry point (as
defined in integration agreement #1089). It will also change the EXIT ACTION
field from null to 'K GECSSYS' where GECSSYS is a supported Generic Code Sheet
variable.\n
The options defined as '<NMSP> GECS*' will have the ENTRY and EXIT ACTION
changed. <NMSP> is defined as the namespace as follows:\n
ABSV BLD CHAP DENT DG ESP
FB FH GMRC LBRC LR MC
NURS PLAY PRCC PRSP PRSP PS
RA RMPR SR SOWK VOLU YS\n", "", "", ""], ["1283", "MAILMAN - Access 'as if' a server", "Routine", "MAILMAN", "1995/06/28", "APPROVED", "Active", "Supported", "", "
Invoking GET^XML with XMCHAN="SERVER" (or any other
appropriate channel) sets up the variables available to servers (that channel)
invoked during normal delivery.\n
Note that before XMREC is executed, XMZ must be defined; XMER and XMRG are
defined by executing XMREC. XMPOS can be changed by the user if appropriate.\n
==========================================================================\n\n
Execute variable XMREC to read a line of the message. XMER and XMRG are
returned.\n
XMER This variable returns the execution status of XMREC. XMER<0, if there
is no more message text to read. The value of XMER will be zero (0), if XMRG
is being returned. XMRG, in that case, will have as its value the text of the
next line of the message. (Note: which may be null, i.e. a blank line; you
cannot test it for being done!)\n
XMRG The value of XMRG will be the next line of message text. XMRG will
always be defined, though it will be null when XMER<0.\n
XMPOS This variable contains the current position of the text returned in the
variable XMGR. It is initialized if it is undefined and should be killed by
the server when it is finished "Reading" the message.\n\n
Prototype Message Body Reader\n
S XMCHAN="SERVER" GET^XML
N A,TEXT ; N MIRROR
S A=0
A ;
X XMREC ; Receive a line
I $D(XMER) G Q:XMER<0 ; Check for end of message
S A=A+1 ; Increment local line count
S TEXT(A)=XMRG ; Set local array
; S MIRROR(XMPOS)=XMRG ; MIRROR will have the same subscripts
; as the original message
G A ; Go back for another line\n\n\n
VARIABLES: XMZ Input The internal number of the message to
be processed.\n
XMPOS Input The number of the last line read (or
null).
XMPOS Output The number of the "next" line in the
message; if no further lines, XMPOS=""\n
XMER Output 0 unless no lines greater than XMPOS,
then -1
XMRG Output line XMPOS of message XMZ", "", "XML", ""], ["1284", "INTERACTIVE READ/MANAGE MESSAGES OPTION", "Routine", "MAILMAN", "1995/07/05", "APPROVED", "Active", "Supported", "", "
This API lets the user read and manage the messages in
his mailbox.", "", "XMA", ""], ["1293", "DBIA1265-G HEALTH FACTORS", "File", "INDIAN HEALTH SERVICE", "1995/08/11", "", "Pending", "Private", "9999999.64", "\n\n
The PCE Patient Care Encounter Package requests a DBIA to distribute the
Indian Health Services HEALTH FACTORS file (9999999.64) in the VA.\n\n
STANDARD DATA DICTIONARY #9999999.64 -- HEALTH FACTORS FILE 08/11 /95 PAGE
1 STORED IN ^AUTTHF( (15 ENTRIES) SITE: ISCSLC UCI: DVA,DEV (VER SION 1T)\n
DATA NAME GLOBAL DATA ELEMENT TITLE
LOCATION TYPE
------------------------------------------------------------------
Changes to this data dictionary should be coordinated thru the IHS DBA.\n\n\n
IDENTIFIED BY: ENTRY TYPE (#.1)\n
POINTED TO BY: SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#142.14) of the STRUCTURE sub-field
(#142.01) of the HEALTH SUMMARY TYPE File
(#142)
SELECTION ITEM field (#4) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
SELECTION ITEM field (#.01) of the SELECTION ITEM
sub-field (#142.944) of the FILE SELECTION
CRITERIA sub-field (#142.94) of the HEALTH
SUMMARY MAINT ITEM File (#142.9)
HEALTH FACTOR field (#.01) of the V HEALTH
FACTORS File (#9000010.23)
HEALTH FACTOR field (#.01) of the HEALTH STATUS
File (#9000019)
HEALTH FACTOR TYPE field (#1) of the HEALTH FACTORS
PANEL sub-field (#9001015.08) of the HEALTH
SUMMARY TYPE File (#9001015)
CATEGORY field (#.03) of the HEALTH FACTORS File
(#9999999.64)
NOT USED WITH field (#.01) of the NOT USED WITH
sub-field (#9999999.641101) of the HEALTH
FACTORS File (#9999999.64)\n\n
SUMMARY TYPE File (#9001015)
CATEGORY field (#.03) of the HEALTH FACTORS File
(#9999999.64)
NOT USED WITH field (#.01) of the NOT USED WITH
sub-field (#9999999.641101) of the HEALTH
FACTORS File (#9999999.64)\n\n
CROSS REFERENCED BY: CATEGORY(AC), ENTRY TYPE(AD), FACTOR(B),
CODE(C), SYNONYM(D)\n\n
9999999.64,.01FACTOR 0;1 FREE TEXT (Required)\n
INPUT TRANSFORM: K:$L(X)>30!($L(X)<3)!'(X'?1P.E) X
LAST EDITED: JUL 01, 1991
HELP-PROMPT: ANSWER WITH HEALTH FACTOR NAME
(3-30 CHARACTERS)
DESCRIPTION: This is the name of the Health
Factor (e.g., Current Smoker,
Non-Tobacco User)\n
CROSS-REFERENCE: 9999999.64^B
1)= S ^AUTTHF("B",$E(X,1,30),DA)="
"\n
2)= K ^AUTTHF("B",$E(X,1,30),DA)\n\n
9999999.64,.02CODE 0;2 FREE TEXT\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>4!($L(X)<4)!'(X?4N) X
LAST EDITED: JUL 01, 1991
HELP-PROMPT: Answer must be 4 characters in
length.
DESCRIPTION: (Optional) This is a short IHS 4
digit numeric code for this health
factor.\n
Enter a 4 digit number.\n
CROSS-REFERENCE: 9999999.64^C
1)= S ^AUTTHF("C",$E(X,1,30),DA)="
"\n
2)= K ^AUTTHF("C",$E(X,1,30),DA)\n\n
9999999.64,.03CATEGORY 0;3 POINTER TO HEALTH FACTORS
FILE (#9999999.64) (Required)\n
INPUT TRANSFORM: S DIC("S")="I $P(^(0),U,10)'=""F""
" D ^DIC K DIC S DIC=DIE,X=+Y K:Y<
0 X
LAST EDITED: OCT 15, 1991
HELP-PROMPT: Select the category to which this
factor belongs.
DESCRIPTION: This is the Health Factor that
categorizes several factors into
one group. For instance, Non
smoker and Frequent Smoker would
have the category of Tobacco.\n
Enter the name of the Health
Factor Category.\n
SCREEN: S DIC("S")="I $P(^(0),U,10)'=""F""
"
EXPLANATION: Screening to prevent pointing to a
non category type factor.
CROSS-REFERENCE: 9999999.64^AC
1)= S ^AUTTHF("AC",$E(X,1,30),DA)=
""\n
2)= K ^AUTTHF("AC",$E(X,.04SHORT NAME
0;4 FREE TEXT\n
INPUT TRANSFORM: K:$L(X)>10!($L(X)<2) X
LAST EDITED: JUL 01, 1991
HELP-PROMPT: Answer must be 2-10 characters in
length.
DESCRIPTION: (Optional) This is a 'short name'
for this health factor. If
defined, it will be used on the
Health Factors Component of the
Health Summary\n
Enter a 2-5 character short name
for this health factor.\n\n
9999999.64,.05USE ONLY WITH SEX 0;5 SET\n
'F' FOR FEMALE;
'M' FOR MALE;
LAST EDITED: JUL 01, 1991
DESCRIPTION: (Optional) This is the sex that
this health factor is used for.\n
Enter an "F" for female or an "M"
for male.\n\n
9999999.64,.06LOWER AGE 0;6 NUMBER\n
INPUT TRANSFORM: K:+X'=X!(X>99999)!(X<0)!(X?.E1"."1
N.N) X
LAST EDITED: JUL 01, 1991
HELP-PROMPT: Type a Number between 0 and 99999,
0 Decimal Digits
DESCRIPTION: (Optional) Tmit that might apply to this
health factor.\n
Enter an age between 0 and 99999.\n\n
9999999.64,.07UPPER AGE 0;7 NUMBER\n
INPUT TRANSFORM: K:+X'=X!(X>99999)!(X<0)!(X?.E1"."1
N.N) X
LAST EDITED: JUL 01, 1991
HELP-PROMPT: Type a Number between 0 and 99999,
0 Decimal Digits
DESCRIPTION: (Optional) This is the upper age
limit that applies to this health
factor.\n
Enter a number between 0 and
99999.\n\n
9999999.64,.08DISPLAY ON HEALTH SUMMARY 0;8 SET\n
'Y' FOR YES;
'N' FOR NO;
LAST EDITED: JUL 01, 1991
DESCRIPTION: (Optional) This allows the health
factor to be displayed on Health
Summaries.\n
Enter a yes to display or a no to
not display.\n\n
9999999.64,.09SYNONYM 0;9 FREE TEXT\n
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L
(X)>30!($L(X)<2) X
LAST EDITED: JUL 01, 1991
HELP-PROMPT: Answer must be 2-30 characters in
length.
DESCRIPTION: (Optional) This this the synonym
for this health factor.\n
Enter a 3 to 30 character synonym
for this health factor.\n
CROSS-REFERENCE: 9999999.64^D
1)= S ^AUTTHF("D",$E(X,1,30),DA)="
"\n
2)= K ^AUTTHF("D",$E(X,1,30),DA)\n\n
9999999.64,.1 ENTRY TYPE 0;10 SET (Required)\n
'C' FOR CATEGORY;
'F' FOR FACTOR;
LAST EDITED: OCT 15, 1991
HELP-PROMPT: SMOKER or NON-SMOKER would be
FACTORS. TOBACCO would be the
Category that SMOKER and
NON-SMOKER would belong to. Are
you entering a FACTOR or a
CATEGORY ?
DESCRIPTION: This is the type of health factor,
(e.g.,"F" for factor or "C" for
category).\n
Enter an "F" for factor or a "C"
for category.\n
CROSS-REFERENCE: 9999999.64^AD
1)= S ^AUTTHF("AD",$E(X,1,30),DA)=
""\n
2)= K ^AUTTHF("AD",$E(X,1,30),DA)\n\n
9999999.64,1101NOT USED WITH 11;0 POINTER Multiple #999999
9.641101\n
DESCRIPTION: Some health factors are not used
with others. This is the group of
health factors that this factor is
not used with.\n\n
9999999.641101,.01NOT USED WITH 0;1 POINTER TO HEALTH FACTO
RS FILE (#9999999.64)
(Multiply asked)\n
LAST EDITED: JUL 01, 1991
DESCRIPTION: This is the health factor that
the health factor is not used
with.\n
Enter the name of a health
factor that is laready in this
file.\n
CROSS-REFERENCE: 9999999.641101^B
1)= S ^AUTTHF(DA(1),11,"B",$E(X,
1,30),DA)=""\n
2)= K ^AUTTHF(DA(1),11,"B",$E(X,
1,30),DA)\n\n\n\n\n
FILES POINTED TO FIELDS\n
HEALTH FACTORS (#9999999.64) CATEGORY (#.03)
NOT USED WITH:NOT USED WITH (#.01
)\n\n
INPUT TEMPLATE(S): PX EDIT HEALTH FACTORS JUL 20, 1995@10:26 USER
#1217\n
PRINT TEMPLATE(S): CAPTIONED USER #0\n
SORT TEMPLATE(S):\n
FORM(S)/BLOCK(S):\n\n", "", "", ""], ["1294", "DBIA 1294 ICD DIAGNOSIS", "File", "DRG GROUPER", "1995/08/15", "", "Retired", "Controlled Subscription", "80", "
The PCE package is requesting to look at and extract
from several fields in the ICD DIAGNOSIS FILE (#80).", "", "", ""], ["1295", "DBIA 1295 HOSPITAL LOCATION", "File", "SCHEDULING", "2003/04/03", "APPROVED", "Active", "Private", "44", "
The PCE package is requesting to look at and extract
data from the HOSPITAL LOCATION file (# 44).", "", "", "2024/12/20"], ["1296", "DBIA 1296 GETLST~IBDF18A", "Routine", "AUTOMATED INFO COLLECTION SYS", "1995/08/15", "", "Under Revision", "Controlled Subscription", "", "
The PCE team requests an agreement to call the
following API.", "", "IBDF18A", "2012/04/12"], ["1297", "OE/RR conversion needs wait list file", "File", "REGISTRATION", "1997/10/20", "APPROVED", "Active", "Private", "42.5", "
The OE/RR version 3.0 orders conversion would like
permission to loop through the WAIT LIST file to get current/pending waiting
list entries. We use this to determine records to convert early in the
process.", "", "", ""], ["1298", "PXK VISIT DATA EVENT", "Other", "PCE PATIENT CARE ENCOUNTER", "1995/08/16", "APPROVED", "Active", "Controlled Subscription", "", "
The Scheduling Developers are requesting permission to
hook the protocol named SDAM PCE EVENT to the ITEM multiple of the protocol
named PXK VISIT DATA EVENT.\n
This protocol event point was developed to publish data collected by PCE
during an encounter via manual data entry or scanned encounter forms. The
data represents elements that are stored in the Visit file (9000010) and other
PCE V-Files.\n
The data is stored in a ^TMP global array with subscripts denoting the
category of published data. An AFTER and BEFORE subscript are included to
distinguish changes made to data elements during the encounter session. The
data published in the ^TMP global represents data from one encounter. The
structure of the ^TMP global that is published is:\n
^TMP("PXKCO",$J,VISIT,"V FILE STRING",V FILE RECORD,DD SUBSCRIPT,
"AFTER/BEFORE")=DATA\n
In cases where there is a CPT modifier, the following structure will be used,
this will capture multiple entries for the sub-file.
^TMP("PXKCO",$J,VISIT,"V FILE STRING",V FILE RECORD,DD SUBSCRIPT,
"AFTER/BEFORE",DATA)=""\n
In cases where there is an Immunization VIS, Other Diagnosis, or Remarks, the
following structure will be used, this will capture multiple entries for the
sub-file.
^TMP("PXKCO",$J,VISIT,"V FILE STRING",V FILE RECORD,DD SUBSCRIPT,
"AFTER/BEFORE",V SUBFILE RECORD)=DATA\n
Temporary global file root: ^TMP\n
Subscript Piece: 1 Description: String notation representing Package
Contents: "PXKCO"\n
Subscript Piece: 2 Description: Job Number Contents: $J\n
Subscript Piece: 3 Description: Internal Entry Number of the Visit (IEN)
Contents: Number\n
Subscript Piece: 4 Description: String representing the Visit or V file data
category. The
"SOR" string refers to the PCE Data Source file (839.7) which is not a
V-File. Contents:
"CPT" = V CPT (procedure)
9000010.18
"HF" = V Health Factors
9000010.23
"ICR" = V Imm Contra/Refusal Events
9000010.707
"IMM" = V Immunization
9000010.11
"PED" = V Patient Ed
9000010.16
"POV" = V POV (diagnosis)
9000010.07
"PRV" = V Provider
9000010.06
"SK" = V Skin Test
9000010.12
"SOR" = PCE Data Source
839.7
"TRT" = V Treatment
9000010.15
"VST" = Visit file
9000010
"XAM" = V Exam
9000010.13
"CSTP" = Visit file
9000010\n
This subscript contains child visits used to store additional Stop
Codes.\n
Subscript Piece: 5 Description: Internal entry number of the entry in the
file represented
in subscript #4 Contents: Number\n
Subscript Piece: 6 Description: Subscript or DD node on which the data is
stored. Every DD
node is published whether or not there is any data for that node. The
exception to this is when an entry is deleted from the file, only the 0
node is posted.\n
"ELAP" is the exception. There is no DD subscript in the Visit file
that corresponds to this string. "ELAP" represents the patient's
eligibility and appointment type for the encounter and has the following
structure: ^TMP("PXKCO",$J,VISIT,"VST",VISIT,"ELAP","BEFORE") or
^TMP("PXKCO",$J,VISIT,"VST",VISIT,"ELAP","AFTER") Contents: 0 800 811 or
"ELAP"\n
Subscript Piece: 7 Description: String designating whether or not the data
is an "AFTER" or
"BEFORE" reflection of the data.\n
* If all the "BEFORE"s are blank, then the data represents a new entry.
* If a node was edited, the "BEFORE" is the value before it was edited,
and the "AFTER" is the value after is was edited.
* If the file entry was deleted, only the 0 node is returned; the
"AFTER" is blank, and the "BEFORE" is the 0 node as it appeared before
it was deleted. Contents: "AFTER" "BEFORE"\n
Subscript Piece: 8 Description: For Immunizations that contain VIS, Other
Diagnosis, or
Remarks, this subscript will contain the Internal Entry Number (IEN) of
the multiple for this sub-file entry.\n\n\n
DATA:\n
The DATA that exists to the right of the global node is a reflection of data
as it appears in the global node of the IEN of the file (noted in subscript
#5) and the NODE of that IEN (described in subscript #6). Refer to the Data
Dictionary for the Visit and V-Files for the format of the data.\n
The data stored on the "ELAP" node is the only exception to this. "ELAP" does
not represent a Data Dictionary node and does not have a corresponding DD
definition. The data stored on this node has the following structure:\n
ELIG PTR^ELIG TEXT^APPT PTR^APPT TEXT", "", "", "2016/09/19"], ["1299", "DBIA1299", "File", "PHARMACY DATA MANAGEMENT", "1997/05/15", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
A direct reference to the Drug file is requested for the Price Per Dispense
Unit field so the VA Cost of a drug can be calculated and billed.", "", "", ""], ["1300", "DBIA1300-A SDCO21", "Routine", "SCHEDULING", "2004/07/19", "APPROVED", "Active", "Private", "", "
The Patient Care Encounter Developers would like to
request private permission to call the following entry points in routine
SDCO21 with the purpose of obtaining outpatient classification requirements.
IA #1301 is also associated with this request.", "", "SDCO21", ""], ["1301", "DBIA1300-B PATIENT", "File", "SCHEDULING", "1995/08/17", "APPROVED", "Active", "Controlled Subscription", "2", "
Patient Care Encounter would like to request to
directly read the following fields in the PATIENT file (# 2). Our goal is to
reach the pointer value of the OUTPATIENT ENCOUNTER file (# 409.68)", "", "", ""], ["1302", "OE/RR conversion needs discharges", "File", "REGISTRATION", "1997/10/20", "APPROVED", "Active", "Private", "405", "
OE/RR version 3.0 orders conversion would like
permission to loop through discharges within 30 days of the OE/RR version 3.0
installation date. This is done to ensure that orders for recently discharged
patients are converted early in the process.", "", "", ""], ["1303", "PAID - QAQ AD HOC REPORTS", "Routine", "QUALITY ASSURANCE", "1995/08/18", "", "Withdrawn", "Private", "", "", "", "QAQAHOC*", ""], ["1304", "SDAM", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The PCE developers request the following DBIA with the
Scheduling developers. We are aware that these are not publicly supported
calls and request only PRIVATE USE BY PCE.\n
LIST^SDAM\n
All calls assume you are in a List Manager(LM) environment, so appropriate LM
variables have been initialized.", "", "SDAM", ""], ["1305", "SDAMBAE6", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The Patient Care Encounter Developers request an IA to
call the following API.\n
FREE^SDAMBAE6\n
This API is called from an action protocol in the PCE's user interface which
allows a user to create a stand alone stop code whithout lieaving PCE's
Interface. This is so the user can get their workload credit and enter
billable data. If they were to enter this data into PCE, the data would not
get to the Scheduling package if the visit cannot be associated with the
appointment.", "", "SDAMBAE6", ""], ["1306", "V PROVIDER FILE", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.06", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.", "", "", ""], ["1307", "V POV FILE", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.07", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.", "", "", ""], ["1308", "V IMMUNIZATION FILE", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.11", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.", "", "", ""], ["1309", "V SKIN TEST", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.12", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.", "", "", ""], ["1310", "V EXAM", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.13", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.", "", "", ""], ["1311", "V TREATMENT", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.15", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.\n", "", "", ""], ["1312", "V PATIENT EDUCATION", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.16", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.\n", "", "", ""], ["1313", "V CPT", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.18", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.\n", "", "", ""], ["1314", "V HEALTH FACTORS", "File", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "9000010.23", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.\n", "", "", ""], ["1315", "IHS FILES", "Other", "INDIAN HEALTH SERVICE", "1995/08/21", "APPROVED", "Active", "Private", "", "\n
The Patient Care Encounter Package requests a DBIA
to distribute the following Indian Health Service
files in the VA.\n
---Visit Related Files--
V PROVIDER 9000010.06 AUPNVPRV(
V POV 9000010.07 AUPNVPOV(
V IMMUNIZATION 9000010.11 AUPNVIMM(
V SKIN TEST 9000010.12 AUPNVSK(
V EXAM 9000010.13 AUPNVXAM(
V TREATMENT 9000010.15 AUPNVTRT(
V PATIENT EDUCATION 9000010.16 AUPNVPED(
V CPT 9000010.18 AUPNVCPT(
V HEALTH FACTORS 9000010.23 AUPNVHF(\n
---Supporting files\n
EDUCATION TOPIC 9999999.09 AUTTEDT(
IMMUNIZATION 9999999.14 AUTTIMM(
EXAM 9999999.15 AUTTXAM(
TREATMENT 9999999.17 AUTTTRT(
SKIN TEST 9999999.28 AUTTSK(
HEALTH FACTORS 9999999.64 AUTTHF(", "", "", ""], ["1316", "V MEASUREMENT FILE", "Other", "INDIAN HEALTH SERVICE", "1995/08/21", "", "Retired", "Private", "", "
The Patient Care Encounter Package requests permission
to READ,WRITE,EDIT and DELETE data to and from this file DIRECTLY and with VA
FILEMAN.\n", "", "", ""], ["1317", "SDAM1", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The PCE developers request the following DBIA with the
Scheduling developers. We are aware that these are not publicly supported
calls and request only PRIVATE USE BY PCE.\n
BLD^SDAM1\n
This call assumes you are in a List Manager(LM) environment, so appropriate LM
variables have been initialized.\n\n", "", "SDAM1", ""], ["1318", "SDAM3", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The PCE developers request the following DBIA with the
Scheduling developers. We are aware that these are not publicly supported
calls and request only PRIVATE USE BY PCE.\n
BLD^SDAM3", "", "SDAM3", ""], ["1319", "SDAMEP", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The PCE developers request the following DBIA with the
Scheduling developers. We are aware that these are not publicly supported
calls and request only PRIVATE USE BY PCE.\n
EN^SDAMEP\n\n", "", "SDAMEP", ""], ["1320", "SDAM APPOINTMENT EVENTS", "Other", "SCHEDULING", "2004/01/08", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event that is invoked when an action is
taken upon an appointment, such as check in.\n
^TMP("SDEVT",$J,SDHDL,SDPROC,"SDOE",SDOE,0,"AFTER") = Zero node of encounter
after change\n
SDHDL = Handle (can get more than one at a time)
SDPROC = Originating process
1 = Appointment
2 = Add/Edit
3 = Disposition
4 = Credit Stop (ignore these)
SDOE = Pointer to encounter", "", "", ""], ["1321", "SCCV ENCOUNTER CONVERSION EVENTS", "Other", "SCHEDULING", "2003/04/03", "", "Withdrawn", "Controlled Subscription", "", "
This is the event that is invoked when an encounter is
converted as part of the Scheduling redesign.", "", "", ""], ["1322", "DBIA1322", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
References to the Provider multiple of the Hospital
Location file (44).
- returns list of providers for a clinic for printing on an
encounter form. References ^SC(clinic,"PR", and
^SC("ADPR",clinic,\n", "", "", ""], ["1323", "Clinical Reminder/Maintenance API", "Routine", "PCE PATIENT CARE ENCOUNTER", "1995/08/24", "", "Retired", "Private", "", "
Request permission to call the
MAIN^PXRHM(DFN,AGE,SEX,PXRITEM,PXRHM) entry point to retrieve Clinical
Reminder/Maintenance data generated by the PCE PACKAGE. Listed below is the
details on accessing this entry point and the data that should be returned.\n
MAIN(DFN,AGE,SEX,PXRITEM,PXRHM)\n
INPUT: DFN - Pointer to Patient File (#2)
AGE - Age of patient
SEX - Sex of patient
PXRITEM - Internal entry of PCE Reminder/Maintenance Item
PXRHM - Flag to indicate level of information needed
1 - Health Maintenance
0 - Reminders DUE NOW only OUTPUT: Data found related
to the PCE Reminder/Maintenance Item (811.9) file\n
^TMP("PXRHM",$J,PXRITEM,"Reminder Item Text"="DUE NOW" or null
^ date due (Internal FM Date) ^ Last activity date (Internal FM date)\n
Note: The following items are only returned if PXRHM = 1.\n
If activity was found in files related to the reminder/maintenance item:
^TMP("PXRHM",$J,PXRITEM,"Reminder Item Text",inverted FM date of activity)=
Type of data^Internal FM date of activity^Name of activity\n
If there is text to describe the reminder/maintenance criteria:
^TMP("PXRHM",$J,PXRITEM,"Reminder Item Text","TXT",1 to N)=
Text about rule and patient findings", "", "PXRHM", ""], ["1324", "DBIA1324-A", "File", "IMAGING", "1995/08/25", "APPROVED", "Active", "Private", "2005", "
This DBIA documents Radiology/Nuclear Medicine's use of
a global node belonging to the Imaging package to determine whether the
Imaging package has been installed at a given facility.", "", "", ""], ["1325", "DBIA1324-B", "File", "IMAGING", "1995/08/25", "APPROVED", "Active", "Private", "2005", "
This DBIA documents Radiology/Nuclear Medicine's use of
a global node owned by the Imaging package to determine if images are scanned
in before a reports are entered.", "", "", ""], ["1326", "DBIA1324-C", "Routine", "IMAGING", "1995/08/25", "APPROVED", "Active", "Private", "", "
This DBIA documents a line label reference within the
Radiology/Nuclear Medicine package to a routine in the Imaging package.", "", "MAGSET3", ""], ["1327", "DBIA1327", "Routine", "INTEGRATED BILLING", "1995/09/19", "APPROVED", "Active", "Private", "", "
The IBQ Package requests use of the function
$$VNDT^IBTRV to extract Review date.", "", "IBTRV", ""], ["1328", "DBIA1324-E", "Routine", "IMAGING", "1995/08/25", "APPROVED", "Active", "Private", "", "
This DBIA documents a Radiology/Nuclear Medicine
package reference to a line label within the Imaging package.", "", "MAGRIC", ""], ["1329", "DBIA1329", "Other", "INTEGRATED BILLING", "1995/09/19", "APPROVED", "Active", "Private", "", "
The IBQ package requests permission to perform the
following actions during the initialization of IBQ 1.0.\n
1. Export the following fields/files:\n
a. Claims Tracking File (#356) - add new field (#1.09) ACUTE CARE
DISCHARGE DATE and add new cross-reference 'ADIS'.\n
b. Hospital Review File (#356.1) - add trigger to existing field
(#1.17) ACUTE CARE DISCHARGE DATE to update field (#1.09) ACUTE CARE
DISCHARGE DATE of File (#356).\n
2. Post init call ENALL^DIK to index existing entries of field (#1.17)
ACUTE CARE DISCHARGE DATE of File (#356.1).", "", "", ""], ["1332", "Rad/Nuc Med flds in File 200", "File", "KERNEL", "1995/08/31", "APPROVED", "Active", "Private", "200", "
This DBIA documents the fields in File 200 that are
created by the Radiology/Nuclear Medicine package developers, and are used
specifically by the Radiology/Nuclear Medicine package. These fields are to
be distributed in a patch by the Kernel developers. The patch will be
prepared by the Radiology/Nuclear Medicine developers and will contain an
environment check to make sure Version 4.5 of Radiology/Nuclear Medicine is
installed before installing these fields on file 200. These fields will also
be distributed along with Radiology/Nuclear Medicine 4.5.", "", "", ""], ["1333", "DBIA1333", "Other", "ADVERSE REACTION TRACKING", "1995/09/07", "APPROVED", "Active", "Private", "", "
Dietetics V5.0 will include Allergy Tracking Systems
option Enter/Edit Patient Reaction Data on Diet Order Management menu.", "", "", ""], ["1334", "CPT CODE/MODIFIERS", "Routine", "CPT/HCPCS CODES", "1995/09/11", "", "Withdrawn", "Supported", "", "
This a function which will return a 1/0 value,
indicating either the modifier can be used with the CPT code or not. If a
modifier is not passed in the 1/0 value will relate to whether the code passed
is a valid CPT code. There are two functions within the routine.\n
MODE(CODE,MOD) ; Returns 1/0 if modifier can be used with code
;
; Input: CODE = CPT code (external format)
; MOD = CPT modifier [Optional] (external format)
; Output: 0/1 = 0 cannot be used with code
; 0 not a valid CPT code if modifier not passed in
; 1 can be used with code
; 1 a valid CPT code if modifier not passed in
MODI(CODE,MOD) ; Returns 1/0 if modifier can be used with code
;
; Input: CODE = CPT code (internal format)
; MOD = CPT modifier [Optional] (internal format)
; Output: 0/1 = 0 cannot be used with code
; 0 not valid CPT code if modifier not passed in
; 1 can be used with code
; 1 valid CPT code if modifier not passed in", "", "DGYACPT", ""], ["1335", "DBIA1335", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
This DBIA documents references made by the
Radiology/Nuclear Medicine package to fields in the Hospital Location file
#44. The references are global reads.", "", "", ""], ["1336", "DBIA1030-C", "Routine", "OUTPATIENT PHARMACY", "1995/09/12", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point is used to build an Outpatient
prescription profile for a patient. This profile is in the form of an array,
names PSOSD.", "", "PSORX", ""], ["1337", "DBIA1337", "File", "REGISTRATION", "1995/09/12", "APPROVED", "Active", "Controlled Subscription", "42.4", "
This DBIA documents Radiology/Nuclear Medicine package
references to the Specialty file #42.4. Rad/Nuc Med contains a field that
points to file 42.4, and there are global reads on the zeroeth node. Direct
read of the 'B' Cross Reference is also permitted.", "", "", ""], ["1338", "DBIA1338", "Other", "IMAGING", "1995/09/12", "APPROVED", "Active", "Private", "", "
This DBIA documents that Radiology/Nuclear Medicine
kills two ^TMP( nodes for the Imaging package. The global nodes are:
^TMP("MAG",$J,"ROW")
^TMP("MAG",$J,"COL") This is necessary to reset the abstract display screen
so the next abstract display will begin in the upper left hand corner of the
screen. Only the Radiology/Nuclear Medicine package knows when the current
case processing is finished, which is the point where these nodes must be
killed.", "", "", ""], ["1339", "DBIA1339", "File", "HEALTH LEVEL SEVEN", "1995/09/13", "APPROVED", "Active", "Private", "772", "
This DBIA documents a Radiology/Nuclear Medicine
package reference to the HL7 package file #772. This is only applicable when
Health Level Seven Version 1.5 is the version currently installed at a site.", "", "", ""], ["1340", "DBIA1340", "File", "KERNEL", "1995/09/14", "APPROVED", "Active", "Supported", "19.1", "
The Security Key file (#19.1) Name field (.01) can be
pointed to. Standard utilities should be used for look-up.", "", "", ""], ["1341", "DBIA1341-A", "Routine", "ENGINEERING", "1995/09/19", "APPROVED", "Active", "Private", "", "
Version 1.0 of the Non-Expendable Equipment/Turn-In
Request Module will call the Engineering Work Order Module in order to create
a work order for equipment that must be disconnected before final turn-in can
occur.", "", "ENWONEW2", ""], ["1342", "DBIA1341-B", "File", "ENGINEERING", "1995/09/19", "APPROVED", "Active", "Private", "6914", "
The Non-expendable Equipment/Turn-In Request Module
requests permission to point to file 6914.", "", "", ""], ["1343", "DBIA1341-C", "File", "ENGINEERING", "1995/09/19", "APPROVED", "Active", "Private", "6914.1", "
The Non-expendable Equipment/Turn-in Request Module
requests permission to point the CMR file, 6914.1.", "", "", ""], ["1344", "DBIA1341-D", "File", "ENGINEERING", "1996/03/21", "APPROVED", "Active", "Private", "6920", "
This reference is to the WORK ORDER # file in
Engineering for items which must have a work order created in order to remove
or disconnect the item by the Engineering department.", "", "", ""], ["1345", "DBIA1341-E", "File", "ENGINEERING", "1995/09/21", "APPROVED", "Active", "Private", "6910", "
The ENG INIT PARAMETERS file is checked for the entry
of the EQUIPMENT TURN-IN SECTION field.", "", "", ""], ["1346", "DBIA1341-F", "Routine", "ENGINEERING", "1996/03/21", "APPROVED", "Active", "Private", "", "
FMS requires FA code sheets on capitalized equipment
and FD code sheets when dispositioned. Turn-In items must be sure that the
appropriate FA and FD code sheets have been done before finalizing the
turn-in.", "", "ENFAUTL", ""], ["1347", "CONTRACT NURSING HOME", "File", "FEE BASIS", "1996/04/25", "", "Withdrawn", "Private", "", "", "", "", ""], ["1348", "DBIA1341-H", "File", "ENGINEERING", "1996/04/04", "APPROVED", "Active", "Private", "6925", "
The Equipment/Turn-In module asks permission to display
projects, their description and to pull the Chief Engineer Name if exists for
inclusion in Equipment Request if necessary.", "", "", ""], ["1349", "DBIA1341-I", "File", "ENGINEERING", "1996/04/04", "APPROVED", "Active", "Private", "6928", "
Equipment/Turn-In module asks permission to access the
Location file (#6928) to identify where new equipment may be located and where
equipment will need to be picked up from when being turned in.", "", "", ""], ["1350", "DBIA1350", "File", "INTEGRATED BILLING", "1995/09/21", "", "Withdrawn", "Private", "356", "
The IBQ package needs to retrieve information from the
Claims Tracking File (#356) for rollup to the National Database. The "ADIS"
x-ref is used to gather discharged patients from the Claims Tracking File
(#356) for use in IBQ.", "", "", ""], ["1351", "DBIA1351", "File", "INTEGRATED BILLING", "1995/09/21", "APPROVED", "Active", "Private", "356.1", "
The IBQ package needs to retrieve Hospital Review
information out of the HOSPITAL REVIEW File (#356.1) for use in the rollup to
the National Database. The 'C' x-ref is used for the gathering of review
information, given the Claims Tracking entry number from the Claims Tracking
File (#356). Refer to IA-1350 for the Claims Tracking IEN that is retrieved
from the 'ADIS' x-ref.", "", "", ""], ["1352", "DBIA1352", "File", "INTEGRATED BILLING", "1995/09/21", "", "Withdrawn", "Private", "356.94", "
The IBQ package needs to retrieve the providers from
the INPATIENT PROVIDER File (#356.94) that correspond to the patient's Claims
Tracking information. The 'C' x-ref is used to retrieve the patient's
providers, given the PATIENT MOVEMENT number. PATIENT MOVEMENT is retrieved
in IA 1350 using the ADMISSION field from File (#356).", "", "", ""], ["1353", "DBIA1353", "File", "1", "1995/09/21", "APPROVED", "Active", "Private", ".402", "
This DBIA documents a Radiology/Nuclear Medicine
package look-up on FileMan's Edit template file. The look-up is done within
an IRM option so that IRM can select one, many, or all Radiology/ Nuclear Med
compiled templates for re-compiling. The look-up must be done through a
Radiology program which calls DIC in order to provide the "one-many-all"
look-up functionality.", "", "", ""], ["1354", "DBIA1354", "File", "INTEGRATED BILLING", "1995/09/21", "APPROVED", "Active", "Private", "356.9", "
The IBQ package needs to retrieve diagnosis data
related to the patient's admission. The 'ADG' x-ref in the INPATIENT
DIAGNOSIS File (#356.9) is used to return the patient's diagnosis, given the
PATIENT MOVEMENT number. The PATINT MOVEMENT number retrieved in IA-1350 from
ADMISSION in the Claims Tracking File (#356).", "", "", ""], ["1355", "DBIA1355", "File", "1", "1995/09/21", "APPROVED", "Active", "Private", ".4", "
This DBIA documents a Radiology/Nuclear Medicine
package look-up on FileMan's Print template file. The look-up is done within
an IRM option so that IRM can select one, many, or all Radiology/Nuclear Med
compiled tempaltes for re-compiling. the look-up must be done through a
Radiology program which calls DIC in order to provide the "one-many-all"
look-up functionality.", "", "", ""], ["1356", "DBIA1356", "File", "INTEGRATED BILLING", "1995/09/21", "", "Withdrawn", "Private", "356.4", "
The IBQ package needs to retrieve the external codes in
the CLAIMS TRACKING NON-ACUTE CLASSIFICATION File (#356.4). Internal entry
numbers of codes to convert come from the REASON fields in the Hospital Review
File (#356.1). Refer to IA-1351 for use of the REASON fields in the IBQ
package.", "", "", ""], ["1357", "DBIA1357", "File", "INTEGRATED BILLING", "1995/09/21", "", "Withdrawn", "Private", "356.3", "
The IBQ package needs to retrieve the external codes
found in the CLAIMS TRACKING SI/IS CATEGORIES File (#356.3). Internal entry
number of codes to convert come from the SI and IS fields in the HOSPITAL
REVIEW File (#356.1). Refer to IA-1351 for use of the SI and IS fields in the
IBQ package.", "", "", ""], ["1358", "DBIA1358", "File", "REGISTRATION", "1995/09/21", "APPROVED", "Active", "Private", "405", "
The IBQ package requests permission to directly access
the MOVEMENT DATE/TIME field in the PATIENT MOVEMENT File (#405) for use in
the IBQ package. Reference to the PATIENT MOVEMENT File is by the ADMISSION
filed in the CLAIMS TRACKING File (#356). Refer to IA-1350 for use of the
ADMISSION field in the IBQ package.", "", "", ""], ["1359", "DBIA1359", "File", "REGISTRATION", "1995/09/21", "APPROVED", "Active", "Controlled Subscription", "45.7", "
The IBQ package requests permission to directly access
the FACILITY TREATING SPECILTY File (#45.7) in order to retrieve the NAME
Field. The SPECIALTY FOR REVIEW Field from the HOSPITAL REVIEW File (#356.1)
will be used as the IEN to the FACILITY TREATING SPECIALTY File. Refer to
IA-1351 for use of the SPECIALTY FOR REVIEW field in the IBQ package.", "", "", ""], ["1360", "DBIA1360", "File", "REGISTRATION", "1995/09/21", "APPROVED", "Active", "Private", "42.4", "
The IBQ package requests permission to directly access
the SPECILTY File (#42.4) to retrieve the SERVICE field (#.03).", "", "", ""], ["1361", "DBIA1361-A", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1995/09/22", "APPROVED", "Active", "Private", "", "
This DBIA documents a Radiology/Nuclear Medicine call
to an OE/RR routine for the purpose of first-time population of the OE/RR v.3
orderable items file. This DBIA shall take effect with Version 3 of OE/RR.", "", "ORMFN", ""], ["1362", "DBIA1361-B", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1995/09/22", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents a call to EN^ORB3 which handles
processing of notifications via CPRS. This call is made by packages which
must generate CPRS alerts through their own package code.", "", "ORB3", ""], ["1363", "KERNEL 8 transport of ORBSTAT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1995/09/22", "APPROVED", "Active", "Private", "", "
Kernel 8.0 needs to transport the routine ORBSTAT.
This routine was modified in order to work with Kernel 8.0. The changes are
not compatible with Kernel 7.1. This is a one time release.", "", "ORBSTAT", ""], ["1364", "KERNEL 8 transport of ORF2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1995/09/22", "APPROVED", "Active", "Private", "", "
Kernel 8.0 needs to transport the routine ORF2. This
routine was modified in order to work with Kernel 8.0. The changes are not
compatible with Kernel 7.1. This is a one time release.", "", "ORF2", ""], ["1365", "DBIA1365", "Routine", "PROBLEM LIST", "1995/09/25", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMPLENFM", ""], ["1366", "DBIA1366", "File", "KERNEL", "1995/09/26", "APPROVED", "Active", "Private", "200", "
Version 1.6 of the HL7 package includes support for
sending security codes (access and signature) in an HL7 message. As a result
the HL7 package needs to directly access the new person file to validate the
security codes.", "", "", ""], ["1367", "XPDKEY", "Routine", "KERNEL", "1995/09/26", "APPROVED", "Active", "Supported", "", "
APIs and extrinsic functions that can be used to
control the Security Key File.", "", "XPDKEY", "2008/03/12"], ["1368", "OE/RR conversion needs recent/future appts", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
We would like permission for the OE/RR version 3.0
orders conversion to loop through appointments in the HOSPITAL LOCATION file.
It will loop through appointments within 30 days of the conversion run date
(+/-).", "", "", ""], ["1369", "Get Clinic Appointments", "File", "SCHEDULING", "1995/10/02", "APPROVED", "Active", "Controlled Subscription", "2", "\n
^DPT(DFN,"DE" for current clinics", "", "", ""], ["1370", "DDBRZIS/DDBDMSG", "Other", "1", "1995/10/03", "APPROVED", "Active", "Controlled Subscription", "", "
Progress Notes will check $G(DDBRZIS). If so, the
variable DDBDMSG will be set equal to "Progress Notes". This will enable
"Progress Notes" to display as the title if the BROWSER device has been
selected.", "", "", ""], ["1371", "DBIA1371", "File", "GENERIC CODE SHEET", "1995/10/04", "APPROVED", "Active", "Private", "2101.2", "
This is a request for an integration agreement between
GECS and PIMS. PIMS will be making reference to file ^GECS(2101.2, GENERIC
CODE SHEET TRANSACTION TYPE/SEGMENT file, the zero node, 5th piece, to look at
the ACTIVE CODE SHEET (#1) field.", "", "", ""], ["1372", "PTF file access", "File", "REGISTRATION", "1995/10/06", "", "Under Revision", "Controlled Subscription", "45", "
The health summary packages needs the ability to access
PTF data to display in several of the health summary components.\n
NOTE: Existing subscribers to this ICR are grandfathered in for accessing PTF
(#45) Diagnosis, Procedure code, and Surgical code data fields. However,
current subscribers are encouraged to use ICR 6130 in the future. ICR 6130
supports the use of PTF Utility API's to access PTF (#45) Diagnosis, Present
on Admission (POA) indicators, Procedure code, and Surgical code fields,
instead of accessing fields directly or using Fileman. New subscribers should
not be added to this ICR if PTF (#45) file data fields may be obtained using
the PTF Utility API's supported by ICR 6130.\n
Revision History:
- 8/21/24: Added 79.33 field to GLOBAL REFERENCE ^DGPT(D0,70) effective with
PX*1.0*241", "", "", "2015/09/18"], ["1373", "DBIA1373", "File", "KERNEL", "1995/10/12", "APPROVED", "Active", "Controlled Subscription", "101", "
Version 1.6 of the HL7 package uses the Protocol file
(#101) to store event related information concerning HL7 messages being
exchanged by applications. As a result, it was necessary to add values to the
Type field (#4) and to add a number of messaging specific fields and cross
references to the file.\n
The following Input Template was added to the Protocol file (#101):\n
'HL MESSAGING PROTOCOL EDIT'\n
This template allow for editing of the fields described in this Integration
Agreement.\n", "", "", ""], ["1374", "DBIA1030-D", "Routine", "PHARMACY PRESCRIPTION PRACTICE", "1995/10/18", "APPROVED", "Retired", "Controlled Subscription", "", "
This function determines if the patient has been to
other hospitals and whether there is any prescription information in the PDX
data file for the patient. If there is data, the user is given the option to
view it. Prescrition Practices is not required. A check is done for the
existance of the routine PPPPDA1.", "", "PPPPDA1", ""], ["1375", "DGACT", "Routine", "REGISTRATION", "1995/11/07", "", "Withdrawn", "Supported", "", "
This function will determine if a treating specialty
entry is active or inactive in either the SPECIALTY (#42.4) file or the
FACILITY TREATING SPECIALTY (#45.7) file. The function will return a 1 if the
treating specialty is active or 0 otherwise.", "", "DGACT", ""], ["1376", "NEW PERSON", "File", "KERNEL", "1995/11/07", "APPROVED", "Active", "Private", "200", "
Nursing can access the New Person file as described in
this DBIA.", "", "", ""], ["1377", "WARD LOCATION", "File", "REGISTRATION", "1995/11/07", "APPROVED", "Active", "Controlled Subscription", "42", "
Controlled access to the Ward Location (42) file
fields/cross-references as described in this DBIA.", "", "", "2009/07/10"], ["1378", "DGPM", "File", "REGISTRATION", "1995/11/07", "APPROVED", "Active", "Controlled Subscription", "405", "
Nursing directly references the ^DGPM global. We would
like permissionto reference the following fields/cross-references using direct
global reads:\n
.01 DATE/TIME
.02 TRANSACTION
.03 PATIENT
.06 WARD LOCATION
.14 ADMISSION/CHECK-IN MOVEMENT
"AMV3" cross-reference
"APMV" cross-reference
"ATID1" cross-reference
"ATID2" cross-reference
"ATID3" cross-reference
"CN" cross reference", "", "", ""], ["1379", "OPTION FILE", "File", "KERNEL", "1995/11/07", "", "Retired", "Private", "19", "
This integration agreement is only for Nursing V3.0,
Vitals/Measurements 3.0 and Intake/Output 3.0.\n
Permission to access the "B" xref on the option file.\n
Persmission to set the OUT OF ORDER field in file 19 using ^DIE.", "", "", ""], ["1380", "ROOM-BED", "File", "REGISTRATION", "1995/11/07", "APPROVED", "Active", "Controlled Subscription", "405.4", "
Nursing, Vitals/Measurements and Intake/Output have
permission to access the following elements in the Room-Bed (405.4) file.\n
^DG(405.4,0) to test for existence of file.
"W" cross-reference
Direct global read of the NAME (.01) field.", "", "", ""], ["1381", "GMRV VITAL MEASUREMENT", "File", "GEN. MED. REC. - VITALS", "1995/11/07", "APPROVED", "Active", "Controlled Subscription", "120.5", "
This DBIA authorizes access to the following fields in
the GMRV Vital Measurement (120.5) file.", "", "", ""], ["1382", "GMRV VITAL TYPE", "File", "GEN. MED. REC. - VITALS", "1995/11/07", "APPROVED", "Active", "Controlled Subscription", "120.51", "
Nursing has permission to access the GMRV Vital Type
(120.51) file.", "", "", ""], ["1383", "GMRV VITAL SITE", "File", "GEN. MED. REC. - VITALS", "1995/11/07", "", "Retired", "Private", "120.52", "
Nursing has permission to access the following fields
in the GMRV Vital Site (120.52) file.", "", "", ""], ["1384", "GMRV VITAL SITE", "File", "GEN. MED. REC. - VITALS", "1995/11/07", "", "Retired", "Private", "120.53", "
Nursing has permission to access the following fields
in the GMRV Vital Site (120.53) file.", "", "", ""], ["1385", "BRANCH OF SERVICE", "File", "REGISTRATION", "1995/11/07", "APPROVED", "Active", "Controlled Subscription", "23", "
Nursing has permission to access the Branch of Service
(23) file as described in this DBIA.", "", "", ""], ["1386", "GMRG PARAMETERS", "File", "GEN. MED. REC. - GENERATOR", "1995/11/07", "APPROVED", "Active", "Private", "124.1", "
Nursing has permission to access the GMRG Parameters
(124.1) file fields described in this DBIA.", "", "", ""], ["1387", "AGGREGATE TERM", "File", "GEN. MED. REC. - GENERATOR", "1995/11/07", "APPROVED", "Active", "Private", "124.2", "
Nursing has permission to access the Aggregate Term
(124.2) file fields described in this DBIA.", "", "", ""], ["1388", "TERM CLASSIFICATION", "File", "GEN. MED. REC. - GENERATOR", "1995/11/07", "APPROVED", "Active", "Private", "124.25", "
Nursing has permission to access the Term
Classification (124.25) file fields described in this DBIA.", "", "", ""], ["1389", "GMR TEXT", "File", "GEN. MED. REC. - GENERATOR", "1995/11/07", "APPROVED", "Active", "Private", "124.3", "
Nursing has permission to access the GMR Text (124.3)
file fields described in this DBIA.", "", "", ""], ["1390", "GMRY PATIENT I/O FILE", "File", "GEN. MED. REC. - I/O", "1995/11/07", "APPROVED", "Active", "Private", "126", "
Nursing has permission to access the GMRY Patient I/O
File (126) file fields described in this DBIA.", "", "", ""], ["1391", "GMRY NUR SHIFT/OTHER", "File", "GEN. MED. REC. - I/O", "1995/11/07", "APPROVED", "Active", "Private", "126.95", "
Nursing and Vitals/Measurements have permission to
access the GMRY NUR Shift/Other file fields described in this DBIA.", "", "", ""], ["1392", "GMRY INPUT TYPE", "File", "GEN. MED. REC. - I/O", "1995/11/07", "APPROVED", "Active", "Private", "126.56", "
Vitals/Measurments has permission to access the GMRY
Input Type file as described in this DBIA.", "", "", ""], ["1393", "GMRY OUTPUT TYPE", "File", "GEN. MED. REC. - I/O", "1995/11/07", "APPROVED", "Active", "Private", "126.58", "
Vitals/Measurements has permission to access the GMRY
Output Type (126.58) file as described in this DBIA.", "", "", ""], ["1394", "GMRGED0", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/07", "APPROVED", "Active", "Private", "", "
Nursing has permission to access the GMRGED0 routines
as described in this DBIA.", "", "GMRGED0", ""], ["1395", "GMRYED1", "Routine", "GEN. MED. REC. - I/O", "1995/11/07", "APPROVED", "Active", "Private", "", "
Nursing has permission to access the entry points
described in this DBIA for the GMRYED1 routine.", "", "GMRYED1", ""], ["1396", "GMRYRP0", "Routine", "GEN. MED. REC. - I/O", "1995/11/07", "APPROVED", "Active", "Private", "", "
Nursing has permission to access the following entry
points in the GMRYRP0 routine.", "", "GMRYRP0", ""], ["1397", "GMRYED3", "Routine", "GEN. MED. REC. - I/O", "1995/11/07", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry points described
in this DBIA for the GMRYED3 routine.", "", "GMRYED3", ""], ["1398", "PRSE STUDENT EDUCATION TRACKING", "File", "EDUCATION TRACKING", "1997/04/21", "APPROVED", "Other", "Private", "452", "
Nursing has permission to access the PRSE Student
Education Tracking (452) fields as described in this DBIA.", "", "", ""], ["1399", "PRSE PROGRAM/CLASS", "File", "EDUCATION TRACKING", "1997/02/14", "APPROVED", "Other", "Private", "452.1", "
Nursing has permission to access the PRSE Program/Class
fields specified in this DBIA.", "", "", ""], ["1400", "PRSE MANDATORY TRAINING (MI) CLASS GROUP", "File", "EDUCATION TRACKING", "1997/02/14", "APPROVED", "Other", "Private", "452.3", "
Nursing has permission to access the PRSE Mandatory
Training (MI) Class Group file fields described in this DBIA.", "", "", ""], ["1401", "PRSE PARAMETERS", "File", "EDUCATION TRACKING", "1995/11/07", "APPROVED", "Active", "Private", "452.7", "
Nursing has permission to access the PRSE Parameters
(452.7) file fields as described in this DBIA.", "", "", ""], ["1402", "PAID EMPLOYEE", "File", "PAID", "1997/02/14", "APPROVED", "Other", "Private", "450", "
Nursing has permission to access the PAID Employee file
fields as described in this DBIA.", "", "", ""], ["1403", "PAID CODE FILES", "File", "PAID", "1995/11/07", "APPROVED", "Active", "Private", "454", "
Nursing has permission to access the PAID Code Files
file fields as described in this DBIA.", "", "", ""], ["1404", "PAID COST CENTER/ORGANIZATION", "File", "PAID", "1995/11/07", "APPROVED", "Active", "Private", "454.1", "
Nursing has permission to access the "B"
cross-reference of the PAID Cost Center/Organization (454.1) file using direct
global reads.", "", "", ""], ["1405", "ORDER", "File", "ORDER ENTRY/RESULTS REPORTING", "1995/11/08", "", "Retired", "Private", "100", "
Vitals/Measurements has permission to access the Order
(100) file as described in this DBIA. This agreement shall be only valid for
V2.5 of the Order Entry package.", "", "", ""], ["1406", "BULLETIN", "File", "MAILMAN", "1995/11/08", "", "Retired", "Private", "3.6", "
Nursing has permission to access the Bulletin (3.6)
file as described in this DBIA.", "", "", ""], ["1407", "FHWHEA", "Routine", "DIETETICS", "1995/11/08", "APPROVED", "Active", "Controlled Subscription", "", "
Nursing has permission to call the ^FHWHEA routine as
described in this DBIA.", "", "FHWHEA", ""], ["1408", "PRSEUTL5", "Routine", "EDUCATION TRACKING", "1997/02/19", "APPROVED", "Other", "Private", "", "
Nursing can use the PRSEUTL5 utility as described in
this DBIA.", "", "PRSEUTL5", ""], ["1409", "NURS LOCATION", "File", "NURSING SERVICE", "1995/11/08", "APPROVED", "Active", "Private", "211.4", "
Intake/Output can access the Nurs Location (211.4) file
entry as described in this DBIA.\n
Direct read of the 'B' Cross Reference in the NURS LOCATION file (#211.4) is
also permitted.\n
Direct global read of the "C" cross-reference of the NURS LOCATION file
(#211.4) is also permitted.", "", "", ""], ["1410", "NURS POSITION CONTROL", "File", "NURSING SERVICE", "1995/11/08", "APPROVED", "Active", "Private", "211.8", "
Intake/Output has permission to access the NURS
Position Control (211.8) file as indicated in this DBIA.", "", "", ""], ["1411", "NURS PATIENT", "File", "NURSING SERVICE", "1995/11/08", "APPROVED", "Active", "Private", "214", "
Intake/Output can access the NURS Patient (214) file as
described in this DBIA.", "", "", ""], ["1412", "DD GLOBAL", "File", "1", "1997/03/05", "APPROVED", "Active", "Controlled Subscription", "0", "
The Nursing, Vitals/Measurements, and Text Generator
packages have been granted permission to access the DD global as defined in
this DBIA.", "", "", ""], ["1413", "MARITAL STATUS", "File", "REGISTRATION", "1995/11/08", "APPROVED", "Active", "Controlled Subscription", "11", "
Nursing has permission to access the Marital Status
(11) file as described in this DBIA.", "", "", ""], ["1414", "RELIGION", "File", "REGISTRATION", "1995/11/08", "APPROVED", "Active", "Private", "13", "
Nursing has permission to access the Religion (13) file
as described in this DBIA.\n
LAB SERVICE will use the NAME (#.01) and CODE (#3) fields in sort and print
templates.", "", "", "2010/09/01"], ["1415", "GMRYFLW0", "Routine", "GEN. MED. REC. - I/O", "1995/11/08", "APPROVED", "Active", "Private", "", "
Nursing has permission to access the following entry
point in the GMRYFLW0 routine.", "", "GMRYFLW0", ""], ["1416", "HOSPITAL LOCATION", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
Nursing can access the Hospital Location (44) file as
described in this DBIA.", "", "", ""], ["1417", "LOCATION TYPE", "File", "SCHEDULING", "2004/06/24", "APPROVED", "Active", "Private", "40.9", "
Nursing can access the Location Type (40.9) file as
described in this DBIA.", "", "", ""], ["1418", "GMRGED1", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can reference the GMRGED1 routine as described
in this DBIA.", "", "GMRGED1", ""], ["1419", "GMRGED2", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can access the GMRGED2 routine as described in
this DBIA.", "", "GMRGED2", ""], ["1420", "GMRGEDB", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can access the GMRGEDB routine as described in
this DBIA.", "", "GMRGEDB", ""], ["1421", "GMRGPNBL", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can access the GMRGPNBL routine as described in
this DBIA.", "", "GMRGPNBL", ""], ["1422", "GMRGRUT0", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can use the GMRGRUT0 routine as described in
this DBIA.", "", "GMRGRUT0", ""], ["1423", "GMRGRUT1", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing has permission to use the GMRGRUT1 routine as
described in this DBIA.", "", "GMRGRUT1", ""], ["1424", "GMRGRUT2", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can access the GMRGRUT2 routine as described in
this DBIA.", "", "GMRGRUT2", ""], ["1425", "GMRGRUT3", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can access the GMRGRUT3 routine as indicated in
this DBIA.", "", "GMRGRUT3", ""], ["1426", "GMRGTGIF", "Routine", "GEN. MED. REC. - GENERATOR", "1995/11/13", "APPROVED", "Active", "Private", "", "
Nursing can access the GMRGTGIF routine as described in
this DBIA.", "", "GMRGTGIF", ""], ["1427", "PHARMACY SYSTEM", "File", "PHARMACY DATA MANAGEMENT", "1995/11/20", "", "Retired", "Private", "59.7", "
This agreement will be retired on 12/31/2006. Please do
not add any
additional code that utilizes this Integration Agreement. APIs have been
created that can be used in place of any code needing to make use of this
agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code
that currently utilizes this Integration Agreement must be converted to
use the new API's. If any part of this Integration Agreement cannot be
satisfied with the APIs, please contact the PRE development team mail
group at EMAIL GROUP DEV using Microsoft Outlook.\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy
packages are still allowed to utilize this agreement past the expiration
date of December 31, 2006. Vitals/Measurements can access the Pharmacy
Sytsem (59.7) file as described in this DBIA.", "", "", ""], ["1428", "IV SOLUTIONS", "File", "INPATIENT MEDICATIONS", "1995/11/20", "", "Retired", "Private", "52.7", "
Patient Intake/Output V3.0 can access the IV Solutions
(52.7) file as described in this DBIA.", "", "", ""], ["1429", "PHARMACY PATIENT", "File", "INPATIENT MEDICATIONS", "1995/11/20", "", "Retired", "Private", "55", "
Intake/Output V3.0 can access the Pharmacy Patient (55)
file as described in this DBIA.", "", "", ""], ["1430", "GMRYRP1", "Routine", "GEN. MED. REC. - I/O", "1995/11/20", "APPROVED", "Active", "Private", "", "
Nursing has permission to access the NEXT entry point
for the GMRYRP1 routine. Vitals/Measurements is allowed to use the entry
STARTD for the GMRYRP1 routine.", "", "GMRYRP1", ""], ["1431", "GMRVDS0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/20", "APPROVED", "Active", "Private", "", "
Nursing can access the GMRVDS0 routine as described in
this DBIA.", "", "GMRVDS0", ""], ["1432", "GMRYUT0", "Routine", "GEN. MED. REC. - I/O", "1995/11/20", "APPROVED", "Active", "Private", "", "
Vitals/Measurements can access the GMTRYUT0 routine as
described in this DBIA.", "", "GMRYUT0", ""], ["1433", "GMRYUT2", "Routine", "GEN. MED. REC. - I/O", "1995/11/20", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point in the
GMRYUT2 routine.", "", "GMRYUT2", ""], ["1434", "GMRYUT9", "Routine", "GEN. MED. REC. - I/O", "1995/11/20", "APPROVED", "Active", "Private", "", "
Vitals/Measurements can access the GMRYUT9 routine as
described in this DBIA.", "", "GMRYUT9", ""], ["1435", "GMRYRP2", "Routine", "GEN. MED. REC. - I/O", "1995/11/20", "APPROVED", "Active", "Private", "", "
Nursing and Vitals/Measurements can access the
following entry points in the GMRYRP2 routine.", "", "GMRYRP2", ""], ["1436", "GMRYRP3", "Routine", "GEN. MED. REC. - I/O", "1995/11/20", "APPROVED", "Active", "Private", "", "
Nursing and Vitals/Measurements can access the
following entry point in the routine GMRYRP3.", "", "GMRYRP3", ""], ["1437", "GMRYSE0", "Routine", "GEN. MED. REC. - I/O", "1995/11/21", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point in the
GMRYSE0 routine.", "", "GMRYSE0", ""], ["1438", "GMRYSE3", "Routine", "GEN. MED. REC. - I/O", "1995/11/21", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point in the
GMRYSE3 routine.", "", "GMRYSE3", ""], ["1439", "GMRVDS1", "Routine", "GEN. MED. REC. - VITALS", "1995/11/21", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point in the
GMRVDS1 routine as described in this DBIA.", "", "GMRVDS1", ""], ["1440", "GMRVED0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry points described
in this DBIA for the GMRVED0 routine.", "", "GMRVED0", ""], ["1441", "GMRVEE0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point described
in this DBIA for the GMRVEE0 routine.", "", "GMRVEE0", ""], ["1442", "GMRVER0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point described
in this DBIA for the GMRVER0 routine.", "", "GMRVER0", ""], ["1443", "GMRVSAS0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point described
in this DBIA for the GMRVSAS0 routine.", "", "GMRVSAS0", ""], ["1444", "GMRVSC0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry points described
in this DBIA for the GMRVSC0 routine.\n
12/17/2003: Modified this IA to add the EN3 entry point.", "", "GMRVSC0", ""], ["1445", "GMRVSR0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry points described
in this DBIA for the GMRVSR0 routine.", "", "GMRVSR0", ""], ["1446", "GMRVUT0", "Routine", "GEN. MED. REC. - VITALS", "2006/11/28", "APPROVED", "Active", "Controlled Subscription", "", "
This routine will return vital/measurement for a
patient over a given date/time range.", "", "GMRVUT0", ""], ["1447", "GMRVUT2", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point described
in this DBIA for the GMRVUT2 routine.", "", "GMRVUT2", ""], ["1448", "GMRVVS0", "Routine", "GEN. MED. REC. - VITALS", "1995/11/22", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry points described
in this DBIA for the GMRVVS0 routine.", "", "GMRVVS0", ""], ["1449", "CHANGE PACKAGE FILE ENTRY", "Other", "KERNEL", "1995/12/07", "APPROVED", "Active", "Private", "", "
The Allergy Tracking System package is changing its
name to Adverse Reaction Tracking when the next version (4.0) is released. The
Expert Panel feels this is a more accurate name for what the package does.
When Version 4.0 is installed, the environmental check routine will do a
look-up (using a DBS call) on the 'C' cross-reference of the PACKAGE file
(#9.4) to find the appropriate entry and change the .01 field value to
'ADVERSE REACTION TRACKING'. The package's namespace is GMRA.\n
Also, the PACKAGE file entry contains the old name and version number as data
in the SHORT DESCRIPTION (#2) and DESCRIPTION (#3) fields. Leaving that data
in the File 9.4 entry would confuse IRM support personnel. We request
permission to edit these two fields, via FileMan, in the environment check
routine at the time of installation.", "", "", ""], ["1450", "DELETE X-REF ON .01 FIELD OF FILE 120.8", "File", "1", "1995/12/13", "APPROVED", "Active", "Private", "0", "
With the release of Adverse Reaction Tracking v4.0, we
would like to directly kill the "ANKA01" cross-reference on the .01 field of
File 120.8. In our installation process, we will do the following:", "", "", ""], ["1451", "DBIA1451", "Routine", "ACCOUNTS RECEIVABLE", "1996/01/03", "APPROVED", "Active", "Private", "", "
The following calls are made to routine RCJIBFN1 and
are used to display bill transaction information. Each call returns data on a
specific entry in the AR TRANSACTION FILE (#433). All data is returned in
internal/unformated form unless otherwise stated.", "", "RCJIBFN1", ""], ["1452", "DBIA1452", "Routine", "ACCOUNTS RECEIVABLE", "1996/01/04", "APPROVED", "Active", "Private", "", "
The following calls are made to routine RCJIBFN2. The
AR specific information returned for a bill/claim is displayed in Third Party
Joint Inquiry.", "", "RCJIBFN2", ""], ["1453", "DBIA1453", "Routine", "ACCOUNTS RECEIVABLE", "1996/01/04", "APPROVED", "Active", "Private", "", "\n\n
This call is used by the Third Party Joint Inquiry to allow the person viewing
a bill to add a comment transaction to the AR bill record.", "", "RCJIBFN3", ""], ["1454", "XPDMENU TO GET OPTION IEN", "Routine", "KERNEL", "1996/01/11", "", "Withdrawn", "Private", "", "
This IA will allow the registration package to call
LKOPT^XPDMENU to acquire the IEN of a menu option when passed the option name.\n", "", "XPDMENU", ""], ["1455", "XUTMOPT used to reschedule task", "Routine", "KERNEL", "1996/01/11", "", "Withdrawn", "Private", "", "
This IA will allow the registration package to
reschedule a task if it is not already scheduled in the future.", "", "XUTMOPT", ""], ["1456", "DIC(19.2 usage", "File", "KERNEL", "1996/01/11", "", "Withdrawn", "Private", "19.2", "
Allows use of the "B" cross-reference of the OPTION
SCHEDULING file (#19.2) to loop though queued times for a given option. Also
allows access of the QUEUED TO RUN AT WHAT TIME (#2) field which is the 2nd
piece of the 0 node of the file.", "", "", ""], ["1457", "DBIA1457", "Other", "INTEGRATED BILLING", "1996/01/12", "APPROVED", "Active", "Private", "", "
Third Party Joint Inquiry Menu [IBJ THIRD PARTY JOINT
INQUIRY] will be added to the Agent Cashier [PRCAY MASTER] and Clerk's AR Menu
[PRCA CLERK MENU]. This will be done by running the PRYQINIT init routine in
patch PRCA*4.5*15.", "", "", ""], ["1458", "GMRY IV DC'ED REASON", "File", "GEN. MED. REC. - I/O", "1996/01/17", "APPROVED", "Active", "Private", "126.76", "
Nursing has permission to access the following field in
the GMRY IV DC'ed Reason (126.76) file.", "", "", ""], ["1459", "GMRY OUTPUT SUBTYPE", "File", "GEN. MED. REC. - I/O", "1996/01/17", "APPROVED", "Active", "Private", "126.6", "
Nursing has permission to access the following fields
in the GMRY Output Subtype (126.6) file.", "", "", ""], ["1460", "GMRY INTAKE ITEMS", "File", "GEN. MED. REC. - I/O", "1996/01/17", "APPROVED", "Active", "Private", "126.8", "
Nursing has permission to access the following fields
in the GMRY Intake Items (126.8) file.", "", "", ""], ["1461", "GMRY IV SITE", "File", "GEN. MED. REC. - I/O", "1996/01/17", "APPROVED", "Active", "Private", "126.7", "
Nursing has permission to access the following field in
the GMRY IV Site (126.7) file.", "", "", ""], ["1462", "GMRY NUR IV SOLUTION", "File", "GEN. MED. REC. - I/O", "1996/01/18", "APPROVED", "Active", "Private", "126.9", "
Nursing has permission to access the following fields
in the GMRY NUR IV Solution (126.9) file.", "", "", ""], ["1463", "GMRY INPUT TYPE", "File", "GEN. MED. REC. - I/O", "1996/01/18", "APPROVED", "Active", "Private", "126.56", "
Nursing has permission to access the following fields
in the GMRY Input Type (126.56) file.", "", "", ""], ["1464", "GMRY IV SITE DESCRIPTION", "File", "GEN. MED. REC. - I/O", "1996/01/18", "APPROVED", "Active", "Private", "126.72", "
Nursing has permission to access the following field in
the GMRY IV Site Description (126.72) file.", "", "", ""], ["1465", "GMRY IV CATHETER", "File", "GEN. MED. REC. - I/O", "1996/01/18", "APPROVED", "Active", "Private", "126.74", "
Nursing has permission to access the following field in
the GMRY IV Catheter (126.74) file.", "", "", ""], ["1466", "GMRY OUTPUT TYPE", "File", "GEN. MED. REC. - I/O", "1996/01/18", "APPROVED", "Active", "Private", "126.58", "
Nursing has permission to access the following fields
in the GMRY Output Type (126.58) file.", "", "", ""], ["1467", "GMRA ENTERED IN ERROR PROTOCOL", "Other", "ADVERSE REACTION TRACKING", "1996/01/19", "APPROVED", "Active", "Controlled Subscription", "", "
This extended action protocol is created with v4.0 and
is invoked whenever an allergy/adverse reaction for a patient is marked as
'entered-in-error'. Action protocols from other applications may be added to
this event upon approval of the DBIC.\n
Listed below are the variables that will be defined for that reaction.\n
Variables:
GMRAPA = The Internal Entry Number of the reaction in
File 120.8 (PATIENT ALLERGIES)
GMRAPA(0) = The zero node of the entry in File 120.8.
Below is a description of the data for that node.\n
$P Field name Field type
-----------------------------------------------------------
1 PATIENT Pointer to File 2 (PATIENT)
2 REACTANT Free Text of Reaction
3 GMR ALLERGY Variable Pointer *
4 ORIGINATION DATE/TIME Date/Time (FM format)
5 ORIGINATOR Pointer to File 200 (NEW
PERSON)
6 OBSERVED/HISTORICAL Set of Codes
(o=Observed,h=Historical)
12 ORIGINATOR SIGN OFF Set of Codes
(1=Signed,(Zero or
Null)=Unsigned)
14 MECHANISM Set of Codes (U=Unknown,
P=Pharmacologic,A=Allergy)
16 VERIFIED Set of Codes
(1=Verified,(0 or Null)=Not
Verified)
17 VERIFICATION DATE/TIME Date/Time (FM format)
18 VERIFIER Pointer to File 200
20 ALLERGY TYPE Free Text/Set of Codes
1 to 3 characters long
(Where "D" = Drug,
"F" = Food,
"O" = Other)\n\n
*The GMR ALLERGY field is a variable pointer which points to one of five
possible files. They are:\n
File Name File Reference
--------- --------------
GMR ALLERGIES GMR(120.8, (e.g., 212;GMR(120.8,)
NATIONAL DRUG PSNDF(
DRUG PSDRUG(
DRUG INGREDIENTS PS(50.416,
VA DRUG CLASS PS(50.605,", "", "", "2014/09/30"], ["1468", "GMRA MEDWATCH DATA COMPLETE PROTOCOL", "Other", "ADVERSE REACTION TRACKING", "1996/01/19", "", "Withdrawn", "Controlled Subscription", "", "
This extended action protocol is created with v4.0 and
is invoked whenever the Pharmacy and Therapeutics Committee completes a
MedWatch form on a patient's adverse reaction. Action protocols from other
applications may be added upon approval of the DBIC.\n
Listed below are the variables that will be defined for that reaction.\n
Variables:
GMRAPA = The Internal Entry Number of the reaction in
File 120.8 (PATIENT ALLERGIES)
GMRAPA(0) = The zero node of the entry in File 120.8.
Below is a description of the data for that node.\n
$P Field name Field type
-----------------------------------------------------------
1 PATIENT Pointer to File 2 (PATIENT)
2 REACTANT Free Text of Reaction
3 GMR ALLERGY Variable Pointer *
4 ORIGINATION DATE/TIME Date/Time (FM format)
5 ORIGINATOR Pointer to File 200 (NEW
PERSON)
6 OBSERVED/HISTORICAL Set of Codes
(o=Observed,h=Historical)
12 ORIGINATOR SIGN OFF Set of Codes
(1=Signed,(Zero or Null)
=Unsigned)
14 MECHANISM Set of Codes (U=Unknown,
P=Pharmacologic,A=Allergy)
16 VERIFIED Set of Codes
(1=Verified,(0 or Null)=Not
Verified)
17 VERIFICATION DATE/TIME Date/Time (FM format)
18 VERIFIER Pointer to File 200
20 ALLERGY TYPE Free Text/Set of Codes
1 to 3 characters long
(Where "D" = Drug,
"F" = Food,
"O" = Other)\n
GMRAPA1 = The Internal Entry Number of the reaction in
File 120.85 (ADVERSE REACTION REPORTING)
GMRAPA1(0) = The zero node of the entry in File 120.85.
Below is a description of the data for that node.\n
$P Field name Field type
-----------------------------------------------------------
1 DATE/TIME OF EVENT Date/Time (FM format)
2 PATIENT Pointer to File 2 (PATIENT)
3 QUESTION #1 Set of Codes (y=YES,n=NO)
4 QUESTION #2 Set of Codes (y=YES,n=NO)
5 QUESTION #3 Set of Codes (y=YES,n=NO)
6 QUESTION #4 Set of Codes (y=YES,n=NO)
7 QUESTION #5 Set of Codes (y=YES,n=NO)
8 NO. DAY HOSPITALIZED Numeric
9 QUESTION #6 Set of Codes (y=YES,n=NO)
10 QUESTION #7 Set of Codes (y=YES,n=NO)
11 QUESTION #8 Set of Codes (y=YES,n=NO)
12 DATE MD NOTIFIED Date/Time (FM format)
13 OBSERVER Pointer to File 200 (NEW
PERSON)
14 SEVERITY Set of Codes
(1=Mild,
2=Moderate,
3=Severe)
15 RELATED REACTION Pointer to File 120.8 (PATIENT
ALLERGIES)
16 QUESTION #9 Set of Codes (y=YES,n=NO)
17 QUESTION #10 Set of Codes (y=YES,n=NO)\n\n\n
*The GMR ALLERGY field is a variable pointer which points to one of five
possible files. They are:\n
File Name File Reference
--------- --------------
GMR ALLERGIES GMR(120.8, (e.g., 212;GMR(120.8,)
NATIONAL DRUG PSNDF(
DRUG PSDRUG(
DRUG INGREDIENTS PS(50.416,
VA DRUG CLASS PS(50.605,", "", "", ""], ["1469", "GMRA SIGN-OFF ON DATA PROTOCOL", "Other", "ADVERSE REACTION TRACKING", "1996/01/19", "APPROVED", "Active", "Controlled Subscription", "", "
This extended action protocol is created with v4.0 and
is invoked whenever an allergy/adverse reaction tracking incident is
signed-off on a patient. Action protocols from other applications may be
added to this event upon approval of the DBIC.\n
Listed below are the variables that will be defined for that reaction.\n
Variables:
GMRAPA = The Internal Entry Number of the reaction in
File 120.8 (PATIENT ALLERGIES)
GMRAPA(0) = The zero node of the entry in File 120.8.
Below is a description of the data for that node.\n
$P Field name Field type
-----------------------------------------------------------
1 PATIENT Pointer to File 2 (PATIENT)
2 REACTANT Free Text of Reaction
3 GMR ALLERGY Variable Pointer *
4 ORIGINATION DATE/TIME Date/Time
5 ORIGINATOR Pointer to File 200 (NEW
PERSON)
6 OBSERVED/HISTORICAL Set of Codes
(o=Observed,h=Historical)
12 ORIGINATOR SIGN OFF Set of Codes
(1=Signed,(Zero or Null)=
Unsigned)
14 MECHANISM Set of Codes (U=Unknown,
P=Pharmacologic,A=Allergy)
16 VERIFIED Set of Codes
(1=Verified,(0 or Null)=Not
Verified)
17 VERIFICATION DATE/TIME Date/Time
18 VERIFIER Pointer to File 200
20 ALLERGY TYPE Free Text/Set of Codes
1 to 3 characters long
(Where "D" = Drug,
"F" = Food,
"O" = Other)\n\n
*The GMR ALLERGY field is a variable pointer which points to one of five
possible files. They are:\n
File Name File Reference
--------- --------------
GMR ALLERGIES GMR(120.8, (e.g., 212;GMR(120.8,)
NATIONAL DRUG PSNDF(
DRUG PSDRUG(
DRUG INGREDIENTS PS(50.416,
VA DRUG CLASS PS(50.605,", "", "", "2014/09/30"], ["1470", "GMRA VERIFY DATA PROTOCOL", "Other", "ADVERSE REACTION TRACKING", "2020/03/09", "APPROVED", "Active", "Controlled Subscription", "", "
This extended action protocol is created with v4.0 and
is invoked whenever an allergy/adverse reaction tracking incident is verified
on a patient. Action protocols from other applications may be added to this
event upon approval.\n
Listed below are the variables that will be defined for that reaction.\n
Variables:
GMRAPA = The Internal Entry Number of the reaction in
File 120.8 (PATIENT ALLERGIES)
GMRAPA(0) = The zero node of the entry in file 120.8.
Below is a description of the data for that node.\n
$P Field name Field type
-----------------------------------------------------------
1 PATIENT Pointer to File 2 (PATIENT)
2 REACTANT Free Text of Reaction
3 GMR ALLERGY Variable Pointer *
4 ORIGINATION DATE/TIME Date/Time (FM format)
5 ORIGINATOR Pointer to File 200 (NEW
PERSON)
6 OBSERVED/HISTORICAL Set of Codes
(o=Observed,h=Historical)
12 ORIGINATOR SIGN OFF Set of Codes
(1=Signed,(Zero or Null)=
Unsigned)
14 MECHANISM Set of Codes (U=Unknown,
P=Pharmacologic,A=Allergy)
16 VERIFIED Set of Codes
(1=Verified,(0 or Null)=Not
Verified)
17 VERIFICATION DATE/TIME Date/Time (FM format)
18 VERIFIER Pointer to File 200
20 ALLERGY TYPE Free Text/Set of Codes
1 to 3 characters long
(Where "D" = Drug,
"F" = Food,
"O" = Other)\n\n
*The GMR ALLERGY field is a variable pointer which points to one of five
possible files. They are:\n
File Name File Reference
--------- --------------
GMR ALLERGIES GMR(120.8, (e.g., 212;GMR(120.8,)
NATIONAL DRUG PSNDF(
DRUG PSDRUG(
DRUG INGREDIENTS PS(50.416,
VA DRUG CLASS PS(50.605,", "", "", "2020/03/09"], ["1471", "RAUTL3", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1996/01/23", "", "Retired", "Private", "", "
The Adverse Reaction Tracking (ART) package requests
permission to call the ALLERGY^RAUTL3 entry point in the Rad/Nuc Med package
if the version of the Rad/Nuc Med package is 4.0 or 4.5. In version 4.0 of the
Rad/Nuc Med package this entry point updated the Contrast Medium Allergy field
(.05) in the Rad/Nuc Med Patient file (70). That data is now stored in the ART
package. With the recent release of Rad/Nuc Med v4.5 this entry point is
merely a Quit command. It exists to provide ART with backward compatibility.
We ask that the Rad/Nuc Med package keep this entry point through its version
4.5 after which Rad/Nuc Med can delete the entry point and ART will modify its
code to no longer reference this routine entry point.", "", "RAUTL3", ""], ["1472", "XUTMOPT Option scheduling interface", "Routine", "KERNEL", "1996/01/23", "APPROVED", "Active", "Supported", "", "
This routine holds several supported calls for access
to the option scheduling file.", "", "XUTMOPT", ""], ["1473", "DBIA1473", "Routine", "AUTOMATED MED INFO EXCHANGE", "1996/02/09", "APPROVED", "Active", "Private", "", "
Quality: Audiology and Speech Pathology Audit and
Review (QUASAR), will make calls to AMIE routines EN1^DVBCTRN and EN2^DVBCTRN.\n
This is done to acquire the soft link information, verify the availability of
the soft link's request, and to download information to AMIE for the purpose
of transmitting audiology C&P exam data.", "", "DVBCTRN", ""], ["1474", "DBIA1474", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
Quality: Audiology and Speech Pathology Audit and
Review (QUASAR), will place the PIMS option [SDCLINIC WORKLOAD] on the QUASAR
Reports menu tree during the post-init process. This will provide Audiology
and Speech Pathology workload data to A&SP users.", "", "", ""], ["1475", "Global Read of S node in File 2", "File", "SCHEDULING", "1996/02/09", "APPROVED", "Active", "Private", "2", "
The Adverse Reaction Tracking package requests
permission to do a direct global read of the "S" nodes in the Patient file in
order to get the STATUS field (#3) value for an APPOINTMENT (#1900) entry.", "", "", ""], ["1476", "DBIA1476", "File", "REGISTRATION", "1996/02/09", "APPROVED", "Active", "Controlled Subscription", "2", "
Quality: Audiology and Speech Pathology Audit and
Review (QUASAR) will reference the following fields from the PATIENT file.
From node .372 of the PATIENT file (#2), fields .01, RATED DISABILITIES (VA),
2 DISABILITY %, and 3 SERVICE CONNECTED. From node .36 of the PATIENT file
(#2), field .361 PRIMARY ELIGIBILITY CODE.", "", "", ""], ["1477", "Global Read of S node of File 44", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "44", "
The Adverse Reaction Tracking package requests
permission to do a direct global read of the "S" nodes of the Hospital
Location file (#44) in order to get the PATIENT (#2) field value of the
APPOINTMENT multiple (#1900).", "", "", ""], ["1478", "Global Read zero and CS nodes of File 409.5", "File", "SCHEDULING", "1996/02/09", "", "Retired", "Private", "409.5", "
The Adverse Reaction Tracking package requests
permission to do a direct global read of the "CS" nodes in the Scheduling
Visits file (#409.5) in order to get the ASSOCIATED CLINIC field (#3) value of
the CLINIC STOP CODE (#10) multiple. Also, we wish to do a direct global read
of the zero node in order to get to the PATIENT (#2) field value.", "", "", ""], ["1479", "Delete PACKAGE file entry", "Other", "KERNEL", "1996/03/01", "APPROVED", "Active", "Private", "", "
The Allergy package is changing its name to ADVERSE
REACTION TRACKING with version 4. The package's namespace is GMRA. Some sites
have two entries in their PACKAGE file that have GMRA as the namespace. They
are ALLERGY TRACKING SYSTEM and GEN. MED. REC. - ALLERGIES. The former is
version 2.2 and the latter is version 3. Both are previous versions of the
ADVERSE REACTION TRACKING package. The GEN. MED. REC. - ALLERGIES entry will
be changed to ADVERSE REACTION TRACKING in the PACKAGE file (DBIA #1449).
This DBIA allows the version 4 environment check routine to delete any other
PACKAGE file entries that have the GMRA namespace.\n
When the unwanted entry has a lower internal entry number in the PACKAGE file
it confuses the $$VERSION^XPDUTL utility which looks at the namespace
cross-reference.\n
For example: W $$VERSION^XPDUTL("GMRA") can return the value 2.2 when it
should return 4.", "", "", ""], ["1480", "Global Read of zero node and AMV1 nodes in File 405", "File", "REGISTRATION", "1996/02/09", "", "Other", "Controlled Subscription", "405", "
The Adverse Reaction Tracking package requests
permission to do a direct global read of the zero node of the PATIENT MOVEMENT
file (#405) in order to read the DATE/TIME (#.01), WARD LOCATION (#.06) and
DISCHARGE/CHECK-OUT MOVEMENT (#.17) fields. Also, we request permission to do
a direct global read of the "AMV1' cross-reference nodes.", "", "", ""], ["1481", "Check Out-Of-Service nodes on File 42", "File", "REGISTRATION", "1996/02/09", "APPROVED", "Active", "Private", "42", "
The Adverse Reaction Tracking package requests
permission to do a direct global read of the "OOS" nodes (OUT-OF-SERVICE DATE)
in the WARD LOCATION file (#42) in order to determine if a ward is
out-of-service during a particular date/time range.", "", "", ""], ["1482", "DBIA1482", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "44", "
Quality: Audiology and Speech Pathology Audit and
Review (QUASAR) will reference the zero node of the HOSPITAL LOCATION file,
fields .01 NAME and field 8 STOP CODE NUMBER.\n
Quality: Audiology and Speech Pathology Audit and Review (QUASAR) Package,
A&SP CLINIC VISIT File (#509850.6), CLINIC LOCATION Field (#2.6) points to
the HOSPITAL LOCATION File (#44) to accommodate recording, tracking and
reporting workload by clinic.\n
Quality: Audiology and Speech Pathology Audit and Review (QUASAR) Package,
A&SP SITE PARAMETER File (#508950.8), CLINIC Multiple (#1), CLINIC LOCATION
(# .01) points to the HOSPITAL LOCATION File (#44) to accommodate recording,
tracking and reporting workload by clinic.\n
Quality: Audiology and Speech Pathology Audit and Review (QUASAR) Package,
A&SP DELETE VISIT File (#509850.9), CLINIC Field (#20) points to the HOSPITAL
LOCATION File (#44) to accommodate recording, tracking and reporting workload
by clinic.", "", "", ""], ["1483", "DBIA1483", "File", "IFCAP", "1996/02/26", "APPROVED", "Active", "Private", "420.8", "
Engineering Package is given permission to point to
File #420.8 SOURCE CODE.", "", "", ""], ["1484", "DBIA1484", "File", "IFCAP", "1996/02/26", "APPROVED", "Active", "Private", "420.1", "
The Engineering Package is given permission to point to
File 420.1. (COST CENTER).", "", "", ""], ["1485", "DBIA1485", "File", "IFCAP", "1996/02/26", "APPROVED", "Active", "Private", "441.2", "
The Engineering Package is given permission to point to
File 441.2. (FEDERAL SUPPLY CLASSIFICATION)", "", "", ""], ["1486", "Global Read of I nodes in File 44", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "44", "
The Adverse Reaction Tracking package requests
permission to do a direct global read of the "I" nodes in the HOSPITAL
LOCATION file (#44) in order to get the INACTIVATE DATE (#2505) and the
REACTIVATE DATE (#2506) field values.", "", "", ""], ["1487", "DBIA1487", "File", "DRG GROUPER", "1996/02/13", "", "Retired", "Private", "80", "
Quality: Audiology and Speech Pathology Audit and
Review (QUASAR) will reference the following fields from the ICD DIAGNOSIS
file to convert ICD9 codes to their text equivalents. Specifically, fields
.01 CODE NUMBER and field 3 DIAGNOSIS. Additionally for QUASAR reports, we
will reference the "BA" cross-reference.", "", "", ""], ["1488", "DBIA1488", "File", "CPT/HCPCS CODES", "1996/02/13", "", "Retired", "Controlled Subscription", "81", "
Quality: Audiology and Speech Pathology Audit and
Review (QUASAR) will reference the following fields from the CPT file to
convert CPT codes to their text equivalents. Specifically, field .01 CPT CODE
, field 2 SHORT NAME, and field 5 INACTIVE FLAG. Additionally for QUASAR
reports, we will reference the "B" cross-reference.", "", "", ""], ["1489", "Look at File 100.21", "File", "ORDER ENTRY/RESULTS REPORTING", "1996/02/14", "APPROVED", "Active", "Controlled Subscription", "100.21", "
The Adverse Reaction Tracking (ART) package requests
permission to do direct global reads in the OE/RR TEAM FILE (#100.21) through
version 2.5 of CPRS (OE/RR). The ART package sends bulletins to the team
members associated with a patient.", "", "", ""], ["1490", "DEMOGRAPHIC REFERENCE FILE", "File", "SURVEY GENERATOR", "1996/02/22", "APPROVED", "Active", "Private", "748.2", "
Nursing has permission to access the following field in
the Demographic Reference File (748.2).", "", "", ""], ["1491", "SURVEY", "File", "SURVEY GENERATOR", "1996/02/16", "APPROVED", "Active", "Private", "748", "
Nursing has permission to access the following fields
in the Survey (748) file.", "", "", ""], ["1492", "SURVEY QUESTIONS", "File", "SURVEY GENERATOR", "1996/02/16", "APPROVED", "Active", "Private", "748.25", "
Nursing has permission to access the following fields
in the Survey Questions (748.25) file.", "", "", ""], ["1493", "SURVEY RESPONSE DATA", "File", "SURVEY GENERATOR", "1996/02/16", "APPROVED", "Active", "Private", "748.3", "
Nursing has permission to access the following fields
in the Survey Response Data (748.3) file.", "", "", ""], ["1494", "SENSITIVE PATIENT BULLETIN NAME", "File", "REGISTRATION", "1996/02/21", "APPROVED", "Active", "Controlled Subscription", "43", "
NETWORK HEALTH EXCHANGE (NHE) is requesting permission
to access the following element in the MAS PARAMETERS file (^DG(43,). A
direct global read will collect the pointer value for the mail group specified
to receive sensitive patient accessed bulletins at the site and then look up
the mail group name in ^XMB(3.8) in order to trigger a bulletin at the target
site when patient data is requested from another NHE site for a Sensitive
patient.", "", "", ""], ["1495", "DBIA1495-A", "File", "HEALTH LEVEL SEVEN", "1996/02/22", "APPROVED", "Active", "Controlled Subscription", "869.2", "
Controlled Substances Version 3.0 needs write access to
the HL LOWER LEVEL PROTOCOL PARAMETER file to allow a post-init to populate
necessary parameters for an interface to narcotic dispensing equipment
systems.", "", "", ""], ["1496", "DBIA1495-B", "File", "HEALTH LEVEL SEVEN", "1996/02/22", "APPROVED", "Active", "Controlled Subscription", "870", "
Write access permitted to the HL LOGICAL LINK file to
allow installation to populate necessary fields to support interfaces.", "", "", ""], ["1497", "DBIA1497", "File", "IFCAP", "1996/02/26", "APPROVED", "Active", "Private", "420.2", "
The Engineering Package is given permission to point to
File 420.2. (BUDGET OBJECT CODE).", "", "", ""], ["1498", "DBIA1498", "File", "IFCAP", "1996/02/26", "APPROVED", "Active", "Private", "440", "
The Engineering Package is given permission to point to
File 440 (Vendor).", "", "", ""], ["1499", "DBIA1499", "File", "IFCAP", "1996/02/26", "APPROVED", "Active", "Private", "442", "
The Engineering package is given permission to read
data from the following fields in file #442 (PROCUREMENT AND ACCOUNTING
TRANSACTIONS) using FileMan utilities and to loop through the global nodes of
the ITEM and BOC multiples to obtain the internal entry number of the multiple
for use in FileMan calls.", "", "", ""], ["1500", "Returns Accounting Data", "Routine", "IFCAP", "1996/02/26", "APPROVED", "Active", "Private", "", "
The Engineering Package is given permission to call
$$ACC^PRC0C.", "", "PRC0C", ""], ["1501", "Info for Network Health Exchange (NHE)", "Routine", "INPATIENT MEDICATIONS", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange (NHE) would like to call
ENIV^PSJAC in order to obtain Inpatient Medications information.", "", "PSJAC", ""], ["1502", "Info for Network Health Exchange (NHE)", "Routine", "DISCHARGE SUMMARY", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange (NHE) would like to call:
$$STATUS^GMRDLIBC in order to obtain informations on report status.", "", "GMRDLIBC", ""], ["1503", "Info for Network Health Exchange (NHE)", "Routine", "DISCHARGE SUMMARY", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange (NHE) would like to call
$$CANSEE^GMRDLIBP to determine if a clinician may view a report on-screen.", "", "GMRDLIBP", ""], ["1504", "Info for Network Health Exchange (NHE)", "Routine", "DISCHARGE SUMMARY", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange (NHE) would like to call
$$DATE^GMRDLIBS and $$NAME^GMRDLIBS to get information on Discharge
Summarys.", "", "GMRDLIBS", ""], ["1505", "Info for Network Health Exchange (NHE)", "Routine", "HEALTH SUMMARY", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange would like to call
FMHL7DTM^GMTSU in order to obtain information.", "", "GMTSU", ""], ["1506", "Info for Network Health Exchange (NHE)", "Routine", "LAB SERVICE", "2005/07/15", "", "Retired", "Private", "", "
Network Health Exchange (NHE) would like to call ^LROC1
in order to obtain valid lab order information.", "", "LROC1", ""], ["1507", "Info for Network Health Exchange (NHE)", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange (NHE) would like to call
SAVE^OR1 to gather information.", "", "OR1", ""], ["1508", "Info for Network Health Exchange (NHE)", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange would like to call AFT^OR4 to
obtain information to be included in the NHE reports (Health Summary clones).", "", "OR4", ""], ["1509", "Info for Network Health Exchange (NHE)", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange (NHE) would like to call
$$TX^ORREV3 and
TXOLD^ORREV3 to obtain information for the NHE reports (Health Summary
clones).", "", "ORREV3", ""], ["1510", "Info for Network Health Exchange (NHE)", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1996/03/01", "", "Withdrawn", "Private", "", "
Network Health Exchange (NHE) would like to call
END^ORUDPA to collect information for NHE reports (Health Summary clones).", "", "ORUDPA", ""], ["1511", "USE OF ICDONE", "Routine", "LEXICON UTILITY", "1996/03/08", "APPROVED", "Active", "Private", "", "
The Automated Information Collection System has the
ability to print lists of terms based on the Clinical Lexicon on Encounter
Forms. When the forms are scanned and data is passed the PCE, the ICD9
diagnosis code associated with the term is required to populate the Purpose of
Visit. This agreement is to allow AICS to use the call ICDONE^GMPTU (and its
successor) ICDONE^LEXU to determine the correct, or best ICD9 Diagnosis code
associated with the selected term. Input variable is the pointer to the
clinical lexicon entry in file 757.01. Output is the ICD9 code, or null if
none is found. This will be coded in such a way as when Clinical Lexicon
converts to the LEX namespace that no changes will be required.\n", "", "GMPTU", ""], ["1512", "USE OF ICDONE", "Routine", "LEXICON UTILITY", "1996/03/08", "", "Retired", "Private", "", "
The Automated Information Collection System has the
ability to print lists of terms based on the Clinical Lexicon on Encounter
Forms. When the forms are scanned and data is passed the PCE, the ICD9
diagnosis code associated with the term is required to populate the Purpose of
Visit. This agreement is to allow AICS to use the call ICDONE^LEXU when
released to determine the correct, or best ICD9 Diagnosis code associated with
the selected term. Input variable is the pointer to the clinical lexicon entry
in file 757.01. Output is the ICD9 code, or null if none is found. This will
be coded in such a way as when Clinical Lexicon converts to the LEX namespace
that no changes will be required.", "", "LEXU", ""], ["1513", "DBIA1513", "Routine", "KERNEL", "1996/03/11", "", "Pending", "Controlled Subscription", "", "
This is a new supported reference in the routine
XUVERIFY.", "", "XUVERIFY", ""], ["1514", "ORF4 ENTRY POINT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1996/03/12", "", "Retired", "Private", "", "
Request permission to call ^ORF4 routine to get order
data.\n
Input variables:
ORUPKG=ptr to package file, ORUSTS=status0^status1^status2...
ORUVP=variable pointer of patient "dfn;DPT("
ORUPRES=pre-defined context 1>All 2>Current 3>DC'ed 4>Expd
5>Exp 6>New 7>Pend 8>Act (OPTIONAL) 9>Expanded
ORDR=1 will put data into ^TMP("OR",$J,"OUT",9999999-ORSTRT,ORIFN)
(OPTIONAL)
ORUSTART=date/time to start looking in FM format (OPTIONAL)
ORUEND=date/time to stop looking in FM format (OPTIONAL)\n
Output Variables from Order (#100) file:
^TMP("ORR",$J,ORLIST,i)=ORIFN_^_STATUS\n
or optionally\n
^TMP("OR",$J,"OUT",Inverse Start Date,IFN,"ORNP") = (field 1)
Internal Current Agent/Provider ^ External Current Agent/Provider
^TMP("OR",$J,"OUT",Inverse Start Date,IFN,"ORSTOP")= (field 22)
Stop Date
^TMP("OR",$J,"OUT",Inverse Start Date,IFN,"ORSTS")= (field 5)
Internal Status ^ External Status
^TMP("OR",$J,"OUT",Inverse Start Date,IFN,"ORSTRT")= (field 21.1)
Current Start Date
^TMP("OR",$J,"OUT",Inverse Start Date,IFN,"ORTX",Line cnt)= (field .11)
Order Text", "", "ORF4", ""], ["1515", "Set File Security for ART files", "File", "1", "1996/03/12", "APPROVED", "Active", "Private", "", "
The Adverse Reaction Tracking (ART) package uses the
KIDS utility to export the package software. ART exports the file level
security codes for its data dictionaries. Currently, KIDS will not change the
file level security codes on the target system if they already exist. This
DBIA allows ART to check the file level security nodes on the package's data
dictionaries and change the target system's file level security to match the
ones being exported. They are:\n
^DIC(120.8,0,"AUDIT") = @
^DIC(120.8,0,"DD") = @
^DIC(120.8,0,"DEL") = @
^DIC(120.8,0,"LAYGO") = @
^DIC(120.8,0,"WR") = @\n
^DIC(120.82,0,"AUDIT") = @
^DIC(120.82,0,"DD") = @
^DIC(120.82,0,"DEL") = @\n
^DIC(120.83,0,"AUDIT") = @
^DIC(120.83,0,"DD") = @
^DIC(120.83,0,"DEL") = @\n
^DIC(120.84,0,"AUDIT") = @
^DIC(120.84,0,"DD") = @
^DIC(120.84,0,"DEL") = @
^DIC(120.84,0,"LAYGO") = @
^DIC(120.84,0,"RD") = @
^DIC(120.84,0,"WR") = @\n
^DIC(120.85,0,"AUDIT") = @
^DIC(120.85,0,"DD") = @
^DIC(120.85,0,"DEL") = @
^DIC(120.85,0,"LAYGO") = @
^DIC(120.85,0,"WR") = @\n
^DIC(120.86,0,"AUDIT") = @
^DIC(120.86,0,"DD") = @
^DIC(120.86,0,"DEL") = @
^DIC(120.86,0,"LAYGO") = @
^DIC(120.86,0,"RD") = @
^DIC(120.86,0,"WR") = @\n
^DIC(120.87,0,"AUDIT") = @
^DIC(120.87,0,"DD") = @
^DIC(120.87,0,"DEL") = @
^DIC(120.87,0,"LAYGO") = @
^DIC(120.87,0,"WR") = @", "", "", ""], ["1516", "Add SCD component", "Routine", "HEALTH SUMMARY", "1996/03/19", "APPROVED", "Active", "Private", "", "
Spinal Cord Dysfunction requests permission to add a
new SCD component to the Health Summary Component (#142.1) file which presents
SCD information while respecting Time and Occurrence limits. This component
will be added by the SCD post-init as record number 74. The post-init also
adds this component to the GMTS HS ADHOC OPTION Health Summary Type by calling
the subroutine ENPOST^GMTSLOAD, installs the routine SPNHS1 as GMTSSCD (This
is the driver/print routine for the component), and will installs SCD into PDX
data segment file (refer to DBIA #1023).", "", "GMTSLOAD", ""], ["1517", "SCD API", "Routine", "SPINAL CORD DYSFUNCTION", "1996/03/19", "APPROVED", "Active", "Supported", "", "
Permission to call the routine
EN^SPNHS0(SPNDFN,SPNBEG,SPNEND,SPNMAX) to get Spinal Cord Dysfunction data.
Parameter passing is being used for Input variables and data will be returned
in ^TMP array.", "", "SPNHS0", ""], ["1518", "DEFAULT INSTITUTION", "File", "KERNEL", "1996/03/22", "", "Withdrawn", "Controlled Subscription", "8989.3", "
Record Tracking needs to find the institution
associated with a borrower when the borrower is an entry in the NEW PERSON
file. We plan to first look at the division multiple of the NEW PERSON file.
If there are no entries in that multiple, we would like to use the DEFAULT
INSTITUTION field (#217) of the KERNEL SITE PARAMETERS file (#8989.3). This
same logic is used in routines such as XUP and XUS1.", "", "", ""], ["1519", "XUTMDEVQ", "Routine", "KERNEL", "1996/03/29", "APPROVED", "Active", "Supported", "", "
These APIs allow you to run jobs directly or queue
them, whether printing to a device or not, and enable varying degrees of user
interaction. See the TaskMan: Developer Tools section of the Kernel
Developer's Guide for further information.\n
EN^XUTMDEVQ: Use this to allow the user to decide whether to run the job
directly or queue it. The user may select the device and the start time.\n
If a task is long-running, and has an output device, it will tie up the output
device for the whole time. That's not desirable. We've created a way for you
to split the job into two tasks: gather and print. The user may select the
device and the start time.
$$QQ^XUTMDEVQ(): Double Queue- This API creates the Gather and Print tasks.
The gather task is scheduled to run, while the print task is not scheduled.
The gather task collects data and stores it, perhaps in ^XTMP. When the
gather task is finished, the gather task can schedule the print task.
$$REQQ^XUTMDEVQ(): Schedule the Print task that was created by $$QQ^XUTMDEVQ.\n
The print task prints the data that was stored by the gather task. This API
should be invoked at the end of the Gather task to print the results.\n
$$DEV^XUTMDEVQ(): Use this to force the user to queue a job. The user may
select the device and start time.\n
$$NODEV^XUTMDEVQ(): Use this to force the user to queue a job which doesn't
need any device. The user may select the start time.\n", "", "XUTMDEVQ", "2012/06/20"], ["1520", "DBIA1520-A", "Routine", "IFCAP", "1996/04/04", "APPROVED", "Active", "Private", "", "
The NX Module (Equipment/Turn-In) requests permission
to use IFCAP program PRCFSITE to set special IFCAP variables used in the
package.", "", "PRCFSITE", ""], ["1521", "DBIA1520-B", "Routine", "IFCAP", "1996/04/04", "APPROVED", "Active", "Private", "", "
The NX module (Equipment/Turn-In) requests permission
to reference program PRCSEB when creating 2237s.", "", "PRCSEB", ""], ["1522", "DBIA1520-C", "Routine", "IFCAP", "1996/04/04", "APPROVED", "Active", "Private", "", "
This agreement will allow the NX (Equipment/Turn-In)
module to call IFCAP routines from within a distributed input template, used
to create 2237s. The calls will return fund control points and information
pertaining to the fund control point used to create the 2237.", "", "PRCSUT", ""], ["1523", "DBIA1520-D", "Routine", "IFCAP", "1996/04/04", "APPROVED", "Active", "Private", "", "
This agreement will allow the NX (Equipment/Turn-In)
module to call the IFCAP transaction utility program when creating 2237s which
will create the record in file 410 and process all checks on creating a 2237.", "", "PRCSUT3", ""], ["1524", "DBIA1520-E", "File", "IFCAP", "1996/04/04", "APPROVED", "Active", "Private", "410", "
The NX (Equipment/Turn-In) module requests permission
to reference file 410 to create/edit 2237s which are the end product of this
module. Includes addition of two templates to file 410, PRCN2237 and
PRCN2237E.", "", "", ""], ["1525", "DBIA1520-F", "File", "IFCAP", "1996/04/04", "APPROVED", "Active", "Private", "440", "
This agreement requests permission for the NX
(Equipment/Turn-In) module to point, with read access only, to the Vendor file
(440).", "", "", ""], ["1526", "DBIA1526", "Routine", "IFCAP", "1996/04/04", "", "Pending", "Private", "", "
The NX module requests permission to use checks
currently in use when creating a 2237.", "", "PRCSCK", ""], ["1527", "DBIA1527", "Other", "OUTPATIENT PHARMACY", "1996/04/05", "APPROVED", "Active", "Private", "", "
Inpatient Medications would like to include the PSO
INTERVENTION MENU andrelated options as a component. This would allow
pharmacists to have thesame functionality for interventions in Inpatient
Medications that existsin Outpatient Pharmacy.\n
The options included on this menu are:\n
PSO INTERVENTION NEW ENTRY PSO INTERVENTION EDIT PSO INTERVENTION PRINTOUT PSO
INTERVENTION DELETE PSO INTERVENTION VIEW", "", "", ""], ["1528", "Homeless Indicator", "Routine", "SOCIAL WORK", "1996/04/05", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement is in reference to an API to
return homeless information on a patient.", "", "SOWKHIRM", ""], ["1529", "DBIA1529", "File", "NURSING SERVICE", "1996/04/26", "APPROVED", "Active", "Private", "211.4", "
This agreement will allow Controlled Substances Version
3.0 to use VA Fileman read access to the NURS LOCATION FILE (#211.4).", "", "", ""], ["1530", "VENDOR SCREEN CNH", "File", "FEE BASIS", "1996/04/29", "APPROVED", "Active", "Private", "161.2", "
PIMS would like to have a variable pointer to the FEE
BASIS VENDOR file (#161.2) and a screen (DIC("S")) that will make only
contract nursing home vendors a valid choice. Revisions are being made to the
RUG-II software that will allow the entry of CNH patient assessments.\n
Looking at the 9th piece of the zero node and the first piece of the "ADEL"
node, would allow us to see if the vendor is a CNH and still active in Austin.
The 9th piece of the zero node in the PART CODE (field #7). When this field
equals 5, the vendor is a contract nursing home. The 1st piece of the "ADEL"
node is AUSTIN DELETED. When this field is defined, set to yes, the vendor is
no longer active in the eyes of Austin.", "", "", ""], ["1531", "DBIA1531", "File", "DSS - DECISION SUPPORT SYSTEM EXTRACTS", "1996/05/01", "APPROVED", "Active", "Private", "727.815", "
Event Capture will export the EVENT CAPTURE LOCAL
EXTRACT file (#727.815). The global root of this file is ^ECX(727.815,. Event
Capture will not populate this file but the procedure data format will change
with the release of Version 2.0. The DSS Extracts software routine ^ECXEC
populates this file.", "", "", ""], ["1532", "DBIA1532", "File", "CPT/HCPCS CODES", "1996/05/06", "", "Retired", "Private", "81", "
Store a variable pointer in the Event Capture files
that has a primary lookup to CPT file (#81). This is read only. The second
lookup is contained locally in the Event Capture file range.\n
Global read access to the CPT file (#81) to display the CPT CODE field (.01)
and SHORT NAME field (2) on input screens and reports within the Event Capture
software.", "", "", ""], ["1533", "DBIA1533", "File", "1", "1996/05/07", "APPROVED", "Active", "Private", "725", "
Event Capture requests to modify the "B" cross
reference for the EC NATIONAL PROCEDURE file (#725) to be 63 characters rather
than the standard 30 characters.\n
As part of this agreement Event Capture will provide the following:
1. Add a description to the "B" cross reference indicating that it was
modified and that ^DIC lookups into this file with DIC(0)["X" will not find
exact matches greater than 30 characters in length.\n
2. Create a post-install routine that kills the "B" index of the file and
then calls ENALL^DIK with DIK(1)=".01^B" to rebuild it.", "", "", ""], ["1534", "NURS CARE PLAN", "File", "NURSING SERVICE", "1996/05/14", "APPROVED", "Active", "Private", "216.8", "
The Text Generator V3 has permission to delete entries
in the NURS Care Plan (216.8) file.", "", "", ""], ["1535", "'DEL' node modification", "File", "1", "1996/05/17", "APPROVED", "Active", "Private", "0", "
The health summary package needs permission to change
the "DEL" node in the DD structure for file 142.1. This will be done with the
SET command and will be done with patch 7.\n
Here is the code to reset the "DEL" node:\n
S ^DD(142.1,.01,"DEL",1,0)="I $S(+$G(DUZ(2))'>0:1,DUZ(2)=5000:0,(DA'<100
001)&(DA'>9999999):0,1:1) N GMZ S GMZ=$S(+$G(DUZ(2)):""ONLY Components Created
a t your site can be deleted"",1:""DUZ(2) MUST equal your DIVISION"") D
EN^DDIOL(GMZ)"\n
S ^DD(142.1,.01,"DEL",2,0)="I '$D(GMCMP) D EN^DDIOL(""You may only delet e
COMPONENTS using the GMTS IRM/ADPAC COMP EDIT option."","""",""!!"")"", "", "", ""], ["1536", "Deleting Options", "Other", "GEN. MED. REC. - VITALS", "1996/05/29", "", "Retired", "Private", "", "
The Nursing package can delete the following
Vitals/Measurements options using the appropriate KIDS supported method to do
this:\n
GMRV CUSTOM V/M, GMRV PULSE RADIAL, GMRVOR DGADM, GMRVOR DGDIS, GMRVOR
DGPM, GMRVOR DGXFR, GMRVORADMIT V/M, GMRVORB/P, GMRVORHT, GMRVORMENU,
GMRVORP CUM REPORT, GMRVORP DISP VITALS, GMRVORP SF511, GMRVORPULSE,
GMRVORRESP, GMRVORTEMP, GMRVORTPR, GMRVORTPR B/P, GMRVORWT", "", "", ""], ["1537", "Deleting Options", "Other", "GEN. MED. REC. - I/O", "1996/05/29", "", "Retired", "Private", "", "
The Nursing package can delete the following
Intake/Output options using the appropriate KIDS supported method to do this:
GMRY IV SHIFT AND EVENT.", "", "", ""], ["1539", "DBIA1539", "Routine", "INTEGRATED BILLING", "1996/06/12", "", "Withdrawn", "Private", "", "
IB routine IBRFN3\n
This routine collects billing information from the Bill/Claims file (#399)
which is used by the Regional Counsel interface of the Accounts Receivable
package for the purpose of sending via E-mail to a site's Regional Counsel
office.", "", "IBRFN3", ""], ["1540", "Setting ID entries", "File", "1", "1996/06/13", "APPROVED", "Active", "Private", "0", "
Since KIDS cannot presently support changing the ID
entries for a file without also shipping all fields in the file, IFCAP wants
to send a post-INIT to remove the old ID nodes and set a new ID node. This
will change the ID display to alow 5 different entries (vendors) to be seen on
a 24 line display without any entries scrolling off the top.\n
This change will be used in patch PRC*5*69 only.", "", "", ""], ["1541", "DBIA1541", "Routine", "PCE PATIENT CARE ENCOUNTER", "1998/02/23", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement permits read access to
procedure, diagnosis and provider information associated with a visit using
API tags in routine PXAPIOE.\n
Using appropriate API tags, this DBIA also allows the following:
1) Setting of the PERSON CLASS (#.06) field of the V PROVIDER
(#9000010.06) file
2) Setting the PRIMARY/SECONDARY (#.12) field in the V POV
(#9000010.07) file to 'primary'", "", "PXAPIOE", ""], ["1542", "BUILD File Read", "File", "KERNEL", "1996/06/18", "", "Withdrawn", "Private", "9.6", "
For PCMM (SD*5.3*41), as part of the installation
environment checker, SCMCENV, we check for the existence of the following
global using $DATA:
^XPD(9.6,"B",SCPATCH)
This is NAME cross-reference of the BUILD File (#9.6)\n
Due to the concurrent development of PCMM and the RPC BROKER software, it was
necessary to check for the existence of the specific BUILD NAME. If the BUILD
file check fails, we use $$VERSION^XPDUTL as a check for the existence of the
appropriate RPC BROKER version. If both checks fail, we abort the install of
PCMM.", "", "", ""], ["1543", "CHECK FOR DI*21*17", "Routine", "1", "1996/06/18", "APPROVED", "Active", "Private", "", "
The Scheduling Developers would like the following
one-time integration agreement with the FileMan Developers:\n
For PCMM (SD*5.3*41), as part of the installation environment checker,
SCMCENV, we check the second line of the following routine using $TEXT:
^DICA
This is the part of VA FileMan's Updater engine. Patch #17 of Version
21.0 was specifically listed as necessary for proper functioning of the RPC
Broker (which PCMM depends on). As such, we require that either:
o The package version is 22 or higher
o The package version is 21 and DICA has patch #17 indicated in its
second line.", "", "DICA", ""], ["1544", "USRLM CALLS", "Routine", "AUTHORIZATION/SUBSCRIPTION", "1996/06/18", "APPROVED", "Active", "Controlled Subscription", "", "
The Scheduling Developers would like the following
on-going integration agreement with the Authorization/Subscription Developers:\n
Use of the following USRLM calls:
$$ISA(USER,CLASS,ERR) - Boolean - Is USER a Member of CLASS?
$$SUBCLASS(DA,CLASS) - Evaluate whether a given USER CLASS is a
DESCENDENT of another class
$$CLNAME(CLASS) - Given a class, return the Display Name
$$WHOIS2(MEMBER,CLASS)- Given a Class, return list of CURRENT members\n
Parameters:
USER - Pointer to File #200
CLASS - Pointer to File #8930
DA - Pointer to File #8930
ERR - [Optional] Error Variable to contain error message
MEMBER is name of array (local or global) in which members are
returned in alphabetical order by name - indexed by number
i.e. @MEMBER@(1 ...n)
@member@(0) = ien of8930^usr class name^count of members
@member@(1..n)=
1 2 3 4 5 6 7 8
p200^p8930.3^classname^effectdate^inactdate^username^title^mailcode
Note: For pieces 2,4 & 5 - Only one of potentially many is returned\n
These calls are part of the User Class Membership functions that PCMM uses for
sites that choose to use the user class functionality.", "", "USRLM", ""], ["1545", "GLOBAL READ OF USR & USR(8930", "File", "AUTHORIZATION/SUBSCRIPTION", "1996/06/18", "", "Withdrawn", "Private", "8930", "
The Scheduling Developers would like the following
on-going integration agreement with the Authorization/Subscription Developers:\n
Read access to the following global:\n
^USR(8930 (The USR CLASS File (#8930)\n
We do the following operations:
o Read of ^USR(8930,ien,0)
o $DATA check of ^USR(8930)
o $DATA check of ^USR(
o $ORDER read of ^USR(8930,"B",SCX)
o $ORDER read of ^USR(8930,"B",SCX,SCI)
o Look-up, using ^DIC
o RPC Broker Lister lookup of File #8930
o The USER CLASSIFICATION Field (#.02) of the STANDARD POSITION File
(#403.46) points to File #8930.
o The USER CLASS Field (#.13) of the TEAM POSITION File (#404.57)
points to File #8930.
o The USE USR CLASS FUNCTIONALITY Field (#801) of the SCHEDULING
PARAMETERS File (#404.91) does a $DATA check in its input transform
for the existence of the ^USR global - requiring this global for the
value 'YES' to be set.", "", "", ""], ["1546", "READ OF USR(8930.3", "File", "AUTHORIZATION/SUBSCRIPTION", "1996/06/18", "APPROVED", "Active", "Private", "8930.3", "
The Scheduling Developers would like the following
on-going integration agreement with the Authorization/Subscription Developers:\n
Read access to the following global:\n
^USR(8930.3 (The USR CLASS MEMBERSHIP File (#8930.3)\n
We do the following operations:
o $DATA check of ^USR(8930.3,"B",Y) as a screen for the PRACTITIONER
Field (#.03) of the POSITION ASSIGNMENT HISTORY File (#404.52).
o $DATA check of ^USR(8930.3) as part of our post-init routine,
SCMCPST, which sets the USE USER CLASS FUNCTIONALITY Field (#801) to
'YES', if this global exists (and other conditions are true).", "", "", ""], ["1547", "DD GLOBAL READ", "File", "1", "1996/06/18", "", "Withdrawn", "Private", "", "
The Scheduling Developers would like the following
integration agreement with the FileMan Developers:\n
Read access to the DD global in the following fashion:
IF $P($G(^DD(SCFILE,SCFLD,0)),U,4)[";0"\n
SCFILE = Filenumber of concern
SCFLD = Fieldnumber of concern\n
This code is used to determine if the field is a word-processing field. When
the PCMM software is updated to use VA FileMan's components, this DBIA will no
longer be needed. Per previous discussions with FileMan Component developers,
this DBIA is needed because of the poor response time that resulted from use
of supported calls.", "", "", ""], ["1548", "DBIA1548-A", "File", "KERNEL", "1996/06/19", "", "Retired", "Private", "3.1", "
IA combined with IA 1234.", "", "", ""], ["1549", "DBIA1548-B", "File", "IFCAP", "1996/06/19", "APPROVED", "Active", "Private", "411", "
The Equipment/Turn-In Request package would like access
to IFCAP's file ADMIN. ACITIVITY SITE PARAMETER (#411) to identify a station
for requests and 2237s.", "", "", ""], ["1550", "DBIA1548-C", "File", "IFCAP", "1996/06/19", "APPROVED", "Active", "Private", "410.2", "
A CLASSIFICATION OF REQUEST may be assigned to a 2237.
The Equipment/Turn-In Request package would like to be able to assign this
field early in the request package and transfer it to the 2237.", "", "", ""], ["1551", "DBIA1548-D", "File", "IFCAP", "1996/06/19", "APPROVED", "Active", "Private", "410.7", "
The SORT GROUP file (#410.7) is used as a sorting
mechanism of requests to categorize their particular cost distribution for
2237s. The Equipment/Turn-In Request package would like to prompt for this
information early in the request and then pass it on to the 2237.", "", "", ""], ["1552", "DBIA1548-E", "Routine", "IFCAP", "1996/06/19", "APPROVED", "Active", "Private", "", "
The Equipment/Turn-In Request package would like
permission to use PRCUSESIG to check for the electronic signature code.", "", "PRCUESIG", ""], ["1553", "DBIA1553", "Other", "1", "1996/06/24", "APPROVED", "Active", "Private", "", "
This request is to allow Integrated Billing to hard-set
an identifier node in the Procedures (#304) sub-file of the Bill/Claims (#399)
file. File #399 is a very large file which we would prefer not to distribute
just to update the modifier of one of its sub-files.\n
The post-init to patch IB*2*62 will set this identifier. The following code
will be executed:\n
S ^DD(399.0304,0,"ID","WRITE")="D DISPID^IBCSC4D"", "", "", ""], ["1554", "DBIA1554", "Routine", "PCE PATIENT CARE ENCOUNTER", "1996/06/26", "APPROVED", "Active", "Controlled Subscription", "", "
A call is made to POV^PXAPIIB to retrieve all diagnosis
(Purpose of Visit) for a visit so they can be added to a claim.", "", "PXAPIIB", ""], ["1555", "PCMM Needs DBIA For .01 Field Pointing to File #200", "File", "KERNEL", "1996/06/26", "APPROVED", "Active", "Private", "200", "
The SCHEDULING USER PREFERENCE File (#403.35) has a .01
field (SCHEDULING USER) that points to and is DINUMed to the NEW PERSON File
(#200). .01 fields are specifically excluded from the normal permission for
fields to point to File #200.", "", "", ""], ["1556", "SCHEDULING REPORTS Field Points to File #1", "File", "1", "1996/07/01", "APPROVED", "Active", "Private", "1", "
The Scheduling Developers would like the following
integration agreement with the FileMan Developers:\n
With PCMM (SD*5.3*41), in the SCHEDULING REPORT File (#404.92), in the FILES
multiple (#40), there is a FILE field (#.01) which points to the FILE file.\n
This field contains the name of the file from which selections are made.", "", "", ""], ["1557", "E-SIG API'S", "Routine", "KERNEL", "1996/07/03", "APPROVED", "Active", "Supported", "", "
This is the list of supported references to the E-SIG
facility.", "", "XUSESIG1", "2008/03/24"], ["1558", "A&SP Clinic Visit File", "File", "QUASAR", "1996/07/17", "APPROVED", "Active", "Controlled Subscription", "509850.6", "
DSS Extracts will reference QUASAR data from the A&SP
CLINIC VISIT file (#509850.6).", "", "", ""], ["1559", "DBIA1559", "File", "QUASAR", "1996/07/17", "APPROVED", "Active", "Private", "509850.8", "
DSS Extracts will reference QUASAR data from the A&SP
SITE PARAMETER file (#509850.8).", "", "", ""], ["1560", "DBIA1560", "File", "QUASAR", "1996/07/17", "APPROVED", "Active", "Private", "509850.4", "
DSS Extracts will reference QUASAR data from the A&SP
PROCEDURE CODE file (#509850.4).", "", "", ""], ["1561", "DSS UNIT file 724", "File", "EVENT CAPTURE", "1996/07/18", "APPROVED", "Active", "Private", "724", "
DSS Extracts and QUASAR will reference Event Capture
data from the DSS UNIT file (#724).", "", "", ""], ["1562", "MEDICAL SPECIALTY file 723", "File", "EVENT CAPTURE", "1996/07/18", "", "Retired", "Private", "723", "
DSS Extracts will reference Event Capture data from the
MEDICAL SPECIALTY file (#723).", "", "", ""], ["1563", "DBIA1563", "File", "MAILMAN", "1996/07/19", "APPROVED", "Active", "Private", "3.8", "\n
As part of the installation process, the Ambulatory Care
Reporting Project is granted permission to add
'XXX@Q-ACD.DNS' to the REMOTE MEMBER multiple (#12)
of the 'SCDX AMBCARE TO NPCDB' entry in the MAIL GROUP
file (#3.8).", "", "", ""], ["1564", "DBIA1564", "File", "MAILMAN", "1996/07/19", "APPROVED", "Active", "Private", "3.6", "\n
As part of the installation process, the Ambulatory Care
Reporting Project is granted permission to add the mail
group contained in the OPC GENERATE MAIL GROUP field (#216)
of the MAS PARAMETER file (#43) to the MAIL GROUP multiple
(#4) of the 'SCDX AMBCARE TO NPCDB SUMMARY' entry in the
BULLETIN file (#3.6).", "", "", ""], ["1565", "DBIA1565", "File", "HEALTH LEVEL SEVEN", "1996/07/19", "APPROVED", "Active", "Private", "779.001", "\n
As part of the installation process, the Ambulatory Care
Reporting Project is granted permission to create the following
entry in the HL7 EVENT TYPE CODE file (#779.001)\n
CODE (#.01): Z00
DESCRIPTION (#2): Ambulatory Care transmission to/from NPCDB
VERSION (#100): 2.2", "", "", ""], ["1566", "DBIA1566", "File", "HEALTH LEVEL SEVEN", "1996/07/19", "APPROVED", "Active", "Private", "869.2", "\n
As part of the installation process, the Ambulatory Care
Reporting Project is granted permission to create the following
entry in the HL LOWER LEVEL PROTOCOL PARAMETER file (#869.2)\n
NAME (#.01): AMB-CARE
LLP TYPE (#.02): MAILMAN
MAIL GROUP (#100): SCDX AMBCARE TO NPCDB", "", "", ""], ["1567", "DBIA1567", "File", "HEALTH LEVEL SEVEN", "1996/07/19", "", "Retired", "Private", "870", "\n
As part of the installation process, the Ambulatory Care
Reporting Project is granted permission to create the
following entry in the HL LOGICAL LINK file (#870)\n
NAME (#.01): AMB-CARE
LLP PARAMETERS (#2): AMB-CARE", "", "", ""], ["1568", "Set File Security for Medicine Files", "File", "1", "1996/07/30", "APPROVED", "Active", "Private", "1", "
The Medicine package uses the KIDS utility to export
the package software. Medicine exports file level security codes for its data
dictionaries. Currently, KIDS will not change the file level security codes
on the target system if they already exist. This DBIA allows Medicine to
check the file level security nodes on the package's data dictionaries and
change the target system's file level security to match the ones being
exported.\n
The nodes changed are:\n
^DIC(File,0,"DD")="@" and ^DIC(File,0,"AUDIT")="@"\n
Where 'File' has the following values:\n
690 690.1 690.2 690.5 690.97
690.99 691 691.1 691.5 691.6
691.7 691.8 691.9 692 693
693.2 693.3 693.5 693.6 694
694.1 694.5 694.8 695 695.1
695.3 695.4 695.5 695.6 695.8
695.9 696 696.1 696.2 696.3
696.4 696.5 696.7 696.9 697
697.1 697.2 697.3 697.5 698
698.1 698.2 698.3 698.4 698.6
698.9 699 699.48 699.5 699.55
699.57 699.6 699.7 699.81 699.82
699.83 699.84 699.85 699.86 699.88
700 700.1 700.2 700.5 701", "", "", ""], ["1569", "TEXT INTEGRATION UTILITIES", "Routine", "LIST MANAGER", "1996/08/01", "APPROVED", "Active", "Private", "", "
TIU is using List Manager. For one of our LM displays,
we need to display at the beginning of the screen a 60 character name, then 4
or 5 short fields, then a different 60 character name. Sites don't want
either 60 character name truncated. Since the screen is only 80 characters
wide, we need to set one scroll lock long enough to display a meaningful part
of the name and still show our short fields, and then to set a second, very
short scroll lock so we can display the whole second 60 character name with
enough scroll locked to identify the entry.\n
I have found that if I set VALM("FIXED") and VALMLFT, I can essentially set
two different scroll locks, enabling me to display both 60 character names
meaningfully.\n
This also enables me to code a PRINT LIST Action which prints columns beyond
page width on a separate page rather than wrapping them. Since we are using
many columns beyond 80 characters, this is important to our users.\n
For the sake of clarity, this was NOT a simple matter of setting those two
variables: I also had to rewrite for TIU the Scroll Right/Left actions and
the Print List Action rather than use the actions LM exports.\n
TIU requests a private Integration Agreement with List Manager to read and set
the variables VALMLFT and VALM("FIXED").\n
We understand that if/when LM adds functionality affecting these variables, we
would need to rewrite portions of our code.", "", "VALM", ""], ["1571", "LEXICON UTILITY EXPRESSIONS", "File", "LEXICON UTILITY", "1996/08/07", "APPROVED", "Active", "Supported", "757.01", "
The Lexicon Utility (version 2.0 and greater) will
maintain static internal entry numbers (IENs) for the Expression file
(#757.01). As a result, this file may be pointed to to retrieve the Display
Text (.01) for both current Expressions and deactivated Expressions
(Deactivation Flag 757.01;9 1;5 set to 1). This agreement is a follow-on to
DBIA 457 (version 1.0) and is re-issued to include the package name, namespace
and global root changes occurring in version 2.0. This is not an amendment to
457.\n
Version 1.0 Version 2.0\n
Package name Clinical Lexicon Utility Lexicon Utility
Namespace GMPT LEX Expression File
Global Root ^GMP(757.01, ^LEX(757.01,", "", "", ""], ["1573", "LEXU", "Routine", "LEXICON UTILITY", "1996/08/07", "APPROVED", "Active", "Supported", "", "
LEXU is a utility routine for the Lexicon Utility which
contains functions useful in retrieving classification code(s) for a term.
This agreement is a follow-on to DBIA 10148 (version 1.0) and is re-issued to
include the package name, namespace, routine name and global root changes
occurring in version 2.0. This is not an amendment to 10148.", "", "LEXU", ""], ["1574", "DBIA1574", "File", "REGISTRATION", "1996/08/07", "APPROVED", "Active", "Controlled Subscription", "43", "
AICS is requesting direct global access to the
following fields within file 43 (MAS Parameters):\n
48 DEFAULT EF PRINTER 0;48 <-- Read
11 MULTIDIVISION MEDICAL CENTER "GL";2 <-- Read\n
During the Registration process, an Encounter Form may be printed. It is
necessary to determine if the site has defined a default EF printer to print
the EF on. Access to piece 48 of the 0th node would allow this.\n
Additionally, throughout the AICS package, it is necessary to determine if the
facility is Multidivisional. Access to the 2nd piece of the GL node would
provide us with this information.", "", "", ""], ["1575", "AMBCARE DATE CALLS", "Routine", "SCHEDULING", "1996/08/07", "APPROVED", "Active", "Private", "", "
The calls in this agreement are to be used in
conjunction with the installation and running of the Ambulatory Care Report
Project Patch SD*53*44.", "", "SCDXUTL", ""], ["1576", "DIVISION FILE LOOKUP", "File", "REGISTRATION", "1996/08/08", "", "Withdrawn", "Controlled Subscription", "40.8", "
AICS allows printing of Encounter Forms and various
package reports to be sorted by Division. It is necessary to access the .01
field in file 40.8 (Medical Center Division) to resolve the data that is
returned in calls made to VAUTOMA. This request is for direct global read
access to the .01 field in file 40.8.", "", "", ""], ["1577", "CLINICAL LEXICON REFERENCES", "Routine", "LEXICON UTILITY", "1996/08/08", "", "Retired", "Controlled Subscription", "", "
The purpose of this IA is to access line tag CONFIG in
routine ^LEXSET.", "", "LEXSET", ""], ["1578", "CLINICAL LEXICON UTILITY", "Routine", "LEXICON UTILITY", "1996/08/08", "", "Withdrawn", "Controlled Subscription", "", "
AICS would like to request access to call linetag
CONFIG^GMPTSET until the new version of the Clinical Lexicon Utility is
released. At that point, we will reference routine ^LEXSET.", "", "GMPTSET", ""], ["1579", "SCHEDULING CLASSIFICATION", "Routine", "SCHEDULING", "2003/06/30", "APPROVED", "Active", "Controlled Subscription", "", "
This IA is for the purpose of calling into routine
^SDCO22 to ask the classification questions such as Service Connected, Agent
Orange, Ionizing Radiation and Environmental Contaminants.", "", "SDCO22", ""], ["1580", "SDAMU", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "
Request ability to call into two linetags within
routine SDAMU.", "", "SDAMU", ""], ["1581", "CHECK OUT", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "
This IA is for the purpose of determining if the
checkout is complete.", "", "SDCOU", ""], ["1582", "INPATIENT APPT", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "
This IA is for the purpose of calling into routine
^SDAM2 to determine if an appointment is for an inpatient.", "", "SDAM2", ""], ["1583", "CHECKOUT REQUIRED?", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "
The purpose of this IA is to call in to REQ^SDM1A to
determine if checkout is required.", "", "SDM1A", ""], ["1584", "SDM", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "
The purpose of this IA is to call into routine ^SDM
from the top with the patient defined, so that a follow up appointment can be
made for the patient.", "", "SDM", ""], ["1585", "PRINT MGR CLINIC SETUP", "File", "SCHEDULING", "1996/08/08", "APPROVED", "Active", "Controlled Subscription", "409.95", "
The purpose of this IA is to retrieve the current print
manager clinic setup.", "", "", ""], ["1586", "DBIA1586", "File", "DRG GROUPER", "1996/08/08", "APPROVED", "Retired", "Controlled Subscription", "80.3", "
This will enable reads both directly and through
FileMan the code name in the MAJOR DIAGNOSTIC CATEGORY file (#80.3)\n", "", "", ""], ["1587", "CPT CATEGORY file 81.1", "File", "CPT/HCPCS CODES", "1996/08/08", "APPROVED", "Active", "Supported", "81.1", "
This will enable the display of the CPT Category. Both
a direct global read and a FileMan read are acceptable.", "", "", "2015/01/12"], ["1588", "SC GLOBAL REFERENCES", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "44", "
The purpose of this IA is to determine if flag is set
to default to PC practitioner.", "", "", ""], ["1589", "GMRVPCE0", "Routine", "GEN. MED. REC. - VITALS", "1996/08/08", "APPROVED", "Active", "Controlled Subscription", "", "
The GMRVPCE0 routine can be used to enter data into the
Vitals/Measurements package (using PCE Device Interface Specification),
validate measurement data (which uses PCE Device Interface Specification),
print help for a particular measurement, or validate a particular measurement.\n", "", "GMRVPCE0", ""], ["1590", "PC PRACTITIONER", "Routine", "SCHEDULING", "1996/08/09", "APPROVED", "Active", "Controlled Subscription", "", "
This IA is for the purpose of determining the ien and
name of the practitioner filling the PC position.", "", "SCAPMCU2", ""], ["1591", "SCHEDULED APPOINTMENTS", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "44", "
This IA is for the purpose of finding all patients with
an appointment for a clinic on a given day.", "", "", ""], ["1592", "PATIENT CARE ENCOUNTER", "File", "PROBLEM LIST", "1996/08/09", "APPROVED", "Active", "Controlled Subscription", "9000011", "
The purpose of this IA is to allow access to the
^AUPNPROB( global for purposes of gathering information specific to a problem.\n", "", "", ""], ["1593", "PATIENT CARE ENCOUNTER", "File", "PCE PATIENT CARE ENCOUNTER", "1996/08/09", "APPROVED", "Active", "Controlled Subscription", "9999999.27", "
The purpose of this IA is to allow access to the
^AUTNPOV( global for purposes of gathering information specific to a problem.", "", "", ""], ["1594", "APPOINTMENT MULTIPLE", "File", "REGISTRATION", "1996/08/12", "APPROVED", "Active", "Controlled Subscription", "2", "
The purpose of this IA is to allow direct reference to
the Appointment multiple of the patient file to access a number of fields.
This IA will allow reference to the entire ^DPT(D0,'S',D1,0) node. This will
prevent multiple global hits to gather data from the fields referenced in this
IA.", "", "", ""], ["1595", "FILE SECURITY", "File", "1", "1996/08/15", "APPROVED", "Active", "Private", "1", "
Intake/Output V3 is asking for a one-time exemption to
be able to read/write to the ^DIC(file,0,access) global where 126 <= file <=
126.95 and access=(DD,RD,WR,LAYGO,DEL).", "", "", ""], ["1597", "LEXICON EXPRESSION INFORMATION", "Routine", "LEXICON UTILITY", "1996/08/18", "APPROVED", "Active", "Supported", "", "
LEXA is used by the Lexicon Utility to perform a silent
look-up and return an array of the expression found.", "", "LEXA", ""], ["1599", "LEXICON USER DEFAULTS - FILTER", "Routine", "LEXICON UTILITY", "1996/08/19", "APPROVED", "Active", "Private", "", "
The entry point EN1^LEXDFL will be used to setup user
default filter for conducting searches in the Lexicon Utility. This entry
point, along with EN1^LEXDCC, EN1^LEXDVO, EN1^LEXDCX and EN1^LEXDDS replaces
^GMPTDUSR used in verion 1.0 of the Clinical Lexicon Utility (see DBIA 339).", "", "LEXDFL", ""], ["1601", "LEXICON USER DEFAULTS - DISPLAY", "Routine", "LEXICON UTILITY", "1996/08/19", "APPROVED", "Active", "Private", "", "
The entry point EN1^LEXDCC(LEXAP) will be used to setup
user default display (classification codes) for conducting searches in the
Lexicon Utility. This entry point along with EN1^LEXDFL, EN1^LEXDVO,
EN1^LEXDCX and EN1^LEXDDS replaces ^GMPTDUSR used in verion 1.0 of the
Clinical Lexicon Utility (see DBIA 339).", "", "LEXDCC", ""], ["1603", "LEXICON USER DEFAULTS - VOCABULARY", "Routine", "LEXICON UTILITY", "1996/08/19", "APPROVED", "Active", "Private", "", "
The entry point EN1^LEXDVO will be used to setup user
default vocabulary for conducting searches in the Lexicon Utility. This entry
point, along with EN1^LEXDFL, EN1^LEXDCC, EN1^LEXDCX and EN1^LEXDDS replaces
^GMPTDUSR used in version 1.0 of the Clinical Lexicon Utility (see DBIA 339).", "", "LEXDVO", ""], ["1605", "LEXICON USER DEFAULTS - SHORTCUTS", "Routine", "LEXICON UTILITY", "1996/08/19", "APPROVED", "Active", "Private", "", "
The entry point EN1^LEXDCX will be used to setup user
default shortcuts by context for conducting searches in the Lexicon Utility.
This entry point along with EN1^LEXDFL, EN1^LEXDCC, EN1^LEXDVO and EN1^LEXDDS
replaces ^GMPTDUSR used in version 1.0 of the Clinical Lexicon Utility (see
DBIA 339).", "", "LEXDCX", ""], ["1607", "LEXICON USER DEFAULTS - LIST", "Routine", "LEXICON UTILITY", "1996/08/19", "APPROVED", "Active", "Private", "", "
The entry point EN1^LEXDDS will be used to list user
defaults for searching the Lexicon to a device (terminal or printer). This
entry point along with EN1^LEXDFL, EN1^LEXDCC, EN1^LEXDVO and EN1^LEXDCX
replaces ^GMPTDUSR used in version 1.0 of the Clinical Lexicon Utility (see
DBIA 339).", "", "LEXDDS", ""], ["1609", "LEXICON SETUP SEARCH PARAMETERS", "Routine", "LEXICON UTILITY", "1996/08/19", "APPROVED", "Active", "Supported", "", "
The Lexicon Utility uses LEXSET to setup search
parameters based on applications definitions, subset definitions and user
defaults stored in the Subsets Definition file (#757.2). These search
parameters are stored in the global array ^TMP("LEXSCH",$J).", "", "LEXSET", ""], ["1611", "PROBLEM FILE UPDATE BY LEXICON", "File", "PROBLEM LIST", "1996/08/20", "APPROVED", "Active", "Private", "9000011", "
This gives the Lexicon Utility the ability to update
the ICD codes and the Lexicon pointer (Problem) in the Problem List
application with each new release of the Lexicon.", "", "", ""], ["1612", "DSM FILE", "File", "MENTAL HEALTH", "1996/08/20", "APPROVED", "Active", "Supported", "627.7", "
This will enable access to the DSM Code, DSM version
and the Disorder Name.", "", "", ""], ["1614", "LEXICON EXPRESSIONS FROM CODES", "Routine", "LEXICON UTILITY", "1996/08/20", "APPROVED", "Active", "Supported", "", "
The Lexicon Utility uses the LEXCODE routine to extract
expressions (terms) in the form of Fileman's output variable "Y" based on a
classification code.", "", "LEXCODE", ""], ["1615", "ENCOUNTER FORM DATA ENTRY", "Routine", "AUTOMATED INFO COLLECTION SYS", "1996/08/27", "APPROVED", "Active", "Supported", "", "
This is a supported reference to process encounter form
data. Packages that know patient, visit date/time, and clinic can call this
API to use the AICS data entry system to prompt users for encounter data and
subsequently store this data using the PCE device interface (this is done
automatically using the AICS parameters).", "", "IBDFDEA", ""], ["1616", "PNs TITLE file conv to TIU", "Other", "TEXT INTEGRATION UTILITIES", "1996/08/27", "APPROVED", "Active", "Private", "", "
Progress Notes patch GMRP*2.5*44 will be exporting a
series of options to facilitate the clean-up of the PNs package in preparation
for the conversion to TIU. Once clean-up is complete the final step is to run
the conversion of the Progress Notes Title file (#121.2) to the TIU Document
Definition file (#8925.1).", "", "", ""], ["1617", "Scheduling Reads DD(2,0,'ID',...", "File", "1", "1996/08/29", "", "Withdrawn", "Private", "0", "", "", "", ""], ["1618", "DIV", "Routine", "1", "1996/09/13", "APPROVED", "Active", "Private", "", "
Lab is requesting a database agreement to call the DIV
routine at line tag VER for the workload data Lab archiving verify option.
The option is Verify Files for Archiving. This option allows the user to
select either the WKLD DATA (64.1) or LAB MONTHLY WORKLOADS (67.9) file and
choose to verify data in either the whole file or entries selected by the
Select Entries for Archiving option.\n\n
Routine name:LRARVER\n
line: ALL D VER^DIV(LRART) where LRART = file # 64.1 or 67.9\n
line: VWD+1 D VER^DIV(64.11,.LRWIN) where LRWIN is an array of records to
verify\n
line: VLMW+1 D VER^DIV(67.911,.LRWIN) where LRWIN is an array of records to
verify", "", "DIV", ""], ["1619", "Set ID nodes in post-install patch routine", "File", "1", "1996/09/24", "APPROVED", "Active", "Private", "357", "
KIDS cannot support adding new Identifiers with a
partial DD update, AICS wants to send a post-install routine to add a new
Identifier and update existing data-file entries for the ENCOUNTER FORM file
(357).\n
The following ^DD and ^IBE(357 nodes will be set in a post-install routine:\n
^DD(357.02,0,"ID",.02)=W " ",@("$P($P($C(59)_$S($D(^DD(357.02,.02,0)):
$P(^(0),U,3),1:0)_$E("_DIC_"Y,0),0),$C(59)_$P(^(0),U,2)_"":"",2), $C(59),1)")\n
$P(^DD(357,2,0),"^",2)="357.02I"\n
$P(^IBE(357,D0,2,0),"^",2)="357.02I"\n", "", "", ""], ["1621", "%ZTER (ERROR RECORDING)", "Routine", "KERNEL", "1996/10/04", "APPROVED", "Active", "Supported", "", "
This IA is to document the supported calls into the
%ZTER routine in support of standard error trapping.", "", "%ZTER", "2009/08/12"], ["1622", "DBIA1622", "File", "1", "1996/10/18", "APPROVED", "Active", "Private", "3.8", "
Request DBIA to allow MailMan to\n
K ^DD(3.8,0,"ID",5.1)\n
as a post-install routine on a patch. There currently is no other way to
remove a field as an identifier.", "", "", ""], ["1623", "SCDXUAPI - OCCASION OF SERVICE ENTRY", "Routine", "SCHEDULING", "1996/10/22", "APPROVED", "Active", "Controlled Subscription", "", "
The SCDXUAPI is used to add locations to the HOSPITAL
LOCATION file which are deemed occasions of service. This routine has some
supported references, but they should only be used after being discussed with
the scheduling developers. The subscription to these APIs will be controlled.\n
There are 4 supported calls in this routine. Line tags not specifically
mentioned in this DBIA are NOT supported. Detailed documentation on these
calls is provided within the routine.\n
The supported calls are: RAD - this tag is specifically written for the
radiology package. It
allows them to pass in an IEN and convert the entry in file 44 to be
an occasion of service location.\n
LOC - main entry point to add occasion of service locations. This may
also be used to edit or inactivate a location.\n
SCREEN - provides a screen (S DIC("S")="SCREEN^SCDXUAPI(pkg)" to allow
selection of only occasion of service locations which were added by
the package passed in.\n
EXEMPT - provides a screen (S DIC("S")="EXEMPT^SCDXUAPI()") which will
allow selection of only stop codes which are deemed occasion of
service stop codes.", "", "SCDXUAPI", ""], ["1624", "Cross Reference on Date of Death Field", "File", "REGISTRATION", "1996/10/24", "APPROVED", "Active", "Private", "2", "
A APSOD xref on the Date of Death field in file #2.
This Xref will be used to discontinue all active outpatient medication
whenever a date of death is entered for a patient.\n
This IA applicable only for Outpatient Pharmacy version 7.0.", "", "", ""], ["1625", "PERSON CLASS API'S", "Routine", "KERNEL", "1996/11/07", "APPROVED", "Active", "Supported", "", "
Based on a multiple in the NEW PERSON file (#200) which
contains entries that reflect the assignement of HCFA taxonomy to providers,
these APIs provide data for a given NEW PERSON file entry on HCFA code,
profession, specialty, and subspecialty.", "", "XUA4A72", ""], ["1626", "XWB FILE LIST", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Supported", "", "", "XWB FILE LIST", "", ""], ["1627", "XWB FILENAME CHECK", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Supported", "", "", "XWB FILENAME CHECK", "", ""], ["1628", "XWB API LIST", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Private", "", "", "XWB API LIST", "", ""], ["1629", "XWB GET VARIABLE VALUE", "Remote Procedure", "RPC BROKER", "2006/11/28", "APPROVED", "Active", "Controlled Subscription", "", "
One can call the XWB GET VARIABLE VALUE RPC
(distributed with the RPC Broker) to retrieve the value of any M variable in
the server environment. Pass the variable name in Param[0].Value, and the
type (reference) in Param[0].PType. Also, the current context of the user
must give them permission to execute the XWB GET VARIABLE VALUE RPC (it must
be included in the RPC multiple of the "B"-type option registered with the
CreateContext function).", "XWB GET VARIABLE VALUE", "", ""], ["1630", "XUS AV CODE", "Remote Procedure", "KERNEL", "1999/06/29", "", "Active", "Private", "", "
Broker Signon RPC'S. This DBIA covers the following
RPC's
XUS AV CODE
XUS VA HELP
XUS CVC
XUS SIGNON SETUP That are all private to Broker.", "XUS AV CODE", "", ""], ["1631", "XUS INTRO MSG", "Remote Procedure", "KERNEL", "1999/06/29", "APPROVED", "Active", "Controlled Subscription", "", "
RPC to return the INTRO TEXT from the KSP file.", "XUS INTRO MSG", "", ""], ["1632", "XUS SIGNON SETUP", "Remote Procedure", "KERNEL", "1999/06/29", "APPROVED", "Active", "Supported", "", "", "XUS SIGNON SETUP", "", ""], ["1633", "XUS SEND KEYS", "Remote Procedure", "KERNEL", "1999/06/29", "APPROVED", "Active", "Private", "", "
This is a two part RPC for a Broker Signon component.
XUS DIVISION GET
XUS DIVISION SET\n
The rpc XUS DIVISION GET gets a list of the institutions that this user may
signon as belonging to.\n
The rpc XUS DIVISION SET sets the Kernel variable DUZ(2) to the selected
Division/institution.", "XUS SEND KEYS", "", ""], ["1634", "TIU NOTES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/30", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU NOTES", "", ""], ["1635", "TIU GET RECORD TEXT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET RECORD TEXT", "", ""], ["1636", "ORQPT VAMC PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT VAMC PATIENTS", "", ""], ["1637", "ORQPT DEMOG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT DEMOG", "", ""], ["1638", "ORQPT ADDR", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT ADDR", "", ""], ["1639", "ORQQAL LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQAL LIST", "", ""], ["1640", "ORQQAL RXN", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQAL RXN", "", ""], ["1641", "ORQQAL DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQAL DETAIL", "", ""], ["1642", "ORQQPL LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQPL LIST", "", ""], ["1643", "ORQQPL DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQPL DETAIL", "", ""], ["1644", "ORQQXQA PATIENT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQXQA PATIENT", "", ""], ["1645", "ORQQXQA USER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQXQA USER", "", ""], ["1646", "ORQPT NAME", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT NAME", "", ""], ["1647", "ORQQVI VITALS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Private", "", "
The array returned will be in the format:
Vitals IEN
Vital Type Short Label - ie 'T' for Temperature
Metric measurement (if available), including units. If no metric value
is available, the imperial measurement is returned here.
Date/time Vital measurement taken
Imperial measurement, including units", "ORQQVI VITALS", "", "2020/08/19"], ["1648", "ORQPT DEFAULT PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT DEFAULT PATIENTS", "", ""], ["1649", "ORQPT DEFAULT PATIENT LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT DEFAULT PATIENT LIST", "", ""], ["1650", "ORQPT PROVIDERS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT PROVIDERS", "", ""], ["1651", "ORQPT PROVIDER PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT PROVIDER PATIENTS", "", ""], ["1652", "ORQPT CLINIC PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT CLINIC PATIENTS", "", ""], ["1653", "ORQPT SPECIALTIES", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT SPECIALTIES", "", ""], ["1654", "ORQPT SPECIALTY PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT SPECIALTY PATIENTS", "", ""], ["1655", "ORQPT TEAMS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2004/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT TEAMS", "", ""], ["1656", "ORQPT TEAM PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2004/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT TEAM PATIENTS", "", ""], ["1657", "ORQPT WARD PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT WARD PATIENTS", "", ""], ["1658", "ORQPT CLINICS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT CLINICS", "", ""], ["1659", "ORQQPS LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
The following is a capture of the Remote Procedure
ORQQPS LIST:\n
NAME: ORQQPS LIST TAG: LIST
ROUTINE: ORQQPS RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION DESCRIPTION:
Function returns a list of a patient's medications.\n
INPUT PARAMETER: PATIENT ID PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 16 REQUIRED: YES DESCRIPTION:
Patient id (DFN) from Patient File (#2).\n
INPUT PARAMETER: START DATE/TIME PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 16 REQUIRED: NO DESCRIPTION:
Start date/time in FileMan format indicating what date/time to begin listing
medications.\n
INPUT PARAMETER: STOP DATE/TIME PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 16 REQUIRED: NO DESCRIPTION:
Stop date/time in FileMan format indicating what date/time to end listing
medications.\n
RETURN PARAMETER DESCRIPTION:
Array medications in the format: medication id^nameform (orderable item)^
stop date/time^route^schedule/iv rate^refills remaining\n\n
REMOTE PROCEDURE: ORQQPS LIST
Function returns a list of a patient's medications.\n
TAG^ROUTINE: LIST^ORQQPS
KEYWORDS:", "ORQQPS LIST", "", ""], ["1660", "ORB LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORB LIST", "", ""], ["1661", "ORB LIST ON/OFF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORB LIST ON/OFF", "", ""], ["1662", "ORQPT PROVIDER TEAM PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT PROVIDER TEAM PATIENTS", "", ""], ["1663", "ORQPT PROVIDER TEAMS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT PROVIDER TEAMS", "", ""], ["1664", "ORQQRA DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQRA DETAIL", "", ""], ["1665", "ORQQRA LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQRA LIST", "", ""], ["1666", "ORQQRA SEVEN LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQRA SEVEN LIST", "", ""], ["1667", "ORQQLR LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQLR LIST", "", ""], ["1668", "ORQQLR HX", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQLR HX", "", ""], ["1669", "ORQQLR ORDER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQLR ORDER", "", ""], ["1670", "TIU SUMMARIES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU SUMMARIES", "", ""], ["1671", "ORQQCN LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
Parameters: Patien DFN, Start Date, End Date, Service, Status\n
Patient DFN - DFN of patient from VistA system.\n
Start Date - Date to begin searching for consult records. If blank, ALL
records for the patient will be returned.\n
End Date - Date to stop searching for consult records. If Start Date is
blank, End Date will be ignored.\n
Service - Consult service (File 123.5 entry) to return records for. If Service
is blank, records will be returned for All Services.\n
Status - An order status (File 100.01) to search for. May be a single or
multiple comma separated statuses. If blank, all statuses will be returned.", "ORQQCN LIST", "", "2011/04/21"], ["1672", "ORQQCN DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQCN DETAIL", "", ""], ["1673", "ORK TRIGGER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORK TRIGGER", "", ""], ["1674", "ORB FOLLOW-UP STRING", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORB FOLLOW-UP STRING", "", ""], ["1675", "ORB DELETE ALERT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORB DELETE ALERT", "", ""], ["1676", "ORQPT WARDS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/02/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT WARDS", "", ""], ["1677", "ORB FOLLOW-UP TYPE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORB FOLLOW-UP TYPE", "", ""], ["1678", "ORB FOLLOW-UP ARRAY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORB FOLLOW-UP ARRAY", "", ""], ["1679", "ORB FOLLOW-UP WP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORB FOLLOW-UP WP", "", ""], ["1680", "ORQOR DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQOR DETAIL", "", "2017/08/22"], ["1681", "ORQPT DEFAULT LIST SOURCE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT DEFAULT LIST SOURCE", "", ""], ["1682", "ORQPT VAMC PATIENTS LONG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT VAMC PATIENTS LONG", "", ""], ["1683", "ORQPT DEFAULT CLINIC DATE RANG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT DEFAULT CLINIC DATE RANG", "", ""], ["1684", "ORWPT ID INFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
NOTE: (Added 3/12/25)
New subscribers should be aware that this Remote Procedure is often
updated due to Congressional Mandates. Developers should ensure they have
the most recent release of the Remote Procedure in their development
accounts.", "ORWPT ID INFO", "", ""], ["1685", "ORWPT LIST ALL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT LIST ALL", "", ""], ["1686", "ORWUH POPUP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORWUH POPUP", "", ""], ["1687", "ORWLR CUMULATIVE REPORT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWLR CUMULATIVE REPORT", "", ""], ["1688", "ORQPT PATIENT APPTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT PATIENT APPTS", "", ""], ["1689", "ORWPT LOOKUP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT LOOKUP", "", ""], ["1690", "ORQQVS LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQVS LIST", "", ""], ["1691", "ORQQVS VISITS/APPTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQVS VISITS/APPTS", "", ""], ["1692", "ORQQPP LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQPP LIST", "", ""], ["1693", "ORQPT WARDRMBED", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQPT WARDRMBED", "", "2014/03/06"], ["1694", "ORQQPX IMMUN LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQPX IMMUN LIST", "", ""], ["1695", "ORR ORDERS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Pending", "Supported", "", "", "ORR ORDERS", "", ""], ["1697", "ORWOR CURRENT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORWOR CURRENT", "", ""], ["1698", "ORWOR CATEGORY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORWOR CATEGORY", "", ""], ["1699", "ORQQLR DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQLR DETAIL", "", ""], ["1700", "ORQQVS DETAIL NOTES", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQVS DETAIL NOTES", "", ""], ["1701", "ORQQVS DETAIL SUMMARY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQVS DETAIL SUMMARY", "", ""], ["1702", "ORQQPS DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQQPS DETAIL", "", ""], ["1703", "ORQQXQA ALLPAT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQXQA ALLPAT", "", ""], ["1704", "ORQOR STATI", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQOR STATI", "", ""], ["1705", "TIU NOTES BY VISIT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/30", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU NOTES BY VISIT", "", ""], ["1706", "TIU SUMMARIES BY VISIT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/30", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU SUMMARIES BY VISIT", "", ""], ["1707", "ORB SORT METHOD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORB SORT METHOD", "", ""], ["1708", "ORWDPSO LOAD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORWDPSO LOAD", "", ""], ["1709", "ORQQXMB MAIL GROUPS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORQQXMB MAIL GROUPS", "", ""], ["1710", "ORQPT ATTENDING/PRIMARY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT ATTENDING/PRIMARY", "", ""], ["1711", "ORWD DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Private", "", "", "ORWD DEF", "", ""], ["1712", "ORQ NULL LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQ NULL LIST", "", ""], ["1713", "SC LISTER", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC LISTER", "", ""], ["1714", "SC FILER", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILER", "", ""], ["1715", "SC DELETE ENTRY", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC DELETE ENTRY", "", ""], ["1716", "SC FIND", "Remote Procedure", "SCHEDULING", "2006/11/17", "", "Under Revision", "Supported", "", "", "SC FIND", "", ""], ["1717", "SC FILE NUMBER", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILE NUMBER", "", ""], ["1718", "SC GLOBAL NODE", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC GLOBAL NODE", "", ""], ["1719", "SC GETS ENTRY DATA", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC GETS ENTRY DATA", "", ""], ["1720", "SC LOCK/UNLOCK NODE", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC LOCK/UNLOCK NODE", "", ""], ["1721", "SC VALIDATOR", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC VALIDATOR", "", ""], ["1722", "SC GLOBAL NODE COUNT", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC GLOBAL NODE COUNT", "", ""], ["1723", "SC PRTP", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC PRTP", "", ""], ["1724", "SC MAILMAN", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC MAILMAN", "", ""], ["1725", "SC NEW HISTORY OK", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC NEW HISTORY OK", "", ""], ["1726", "SC CHANGE HISTORY OK", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC CHANGE HISTORY OK", "", ""], ["1727", "SC INACTIVATE ENTRY", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC INACTIVATE ENTRY", "", ""], ["1728", "SC DELETE HISTORY", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC DELETE HISTORY", "", ""], ["1729", "SC HISTORY STATUS OK", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC HISTORY STATUS OK", "", ""], ["1730", "SC MEAN TEST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC MEAN TEST", "", ""], ["1731", "SC TEAM LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC TEAM LIST", "", ""], ["1732", "SC PATIENT LOOKUP", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC PATIENT LOOKUP", "", ""], ["1733", "SC POSITION MEMBERS", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC POSITION MEMBERS", "", ""], ["1734", "SC FILE SINGLE VALUE", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILE SINGLE VALUE", "", ""], ["1735", "SCTM AUTOLINK GETRECORD", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCTM AUTOLINK GETRECORD", "", ""], ["1736", "SC KEY CHECK", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC KEY CHECK", "", ""], ["1737", "SCTM AUTOLINK SETRECORD", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCTM AUTOLINK SETRECORD", "", ""], ["1738", "SCTM AUTOLINK GETLINK", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCTM AUTOLINK GETLINK", "", ""], ["1739", "SCRP DEFINITION GETRECORD", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP DEFINITION GETRECORD", "", ""], ["1740", "SCUT GET USER RECORD", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCUT GET USER RECORD", "", ""], ["1741", "SCRP QUERY GETRECORD", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP QUERY GETRECORD", "", ""], ["1742", "ORQPT PROVIDER PERSONAL LISTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT PROVIDER PERSONAL LISTS", "", ""], ["1743", "ORQQLR SEARCH RANGE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQLR SEARCH RANGE", "", ""], ["1744", "ORQQAL LIST REPORT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/11/17", "", "Withdrawn", "Controlled Subscription", "", "", "ORQQAL LIST REPORT", "", ""], ["1745", "XWB EGCHO STRING", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Supported", "", "", "XWB EGCHO STRING", "", ""], ["1746", "XWB EGCHO LIST", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Private", "", "", "XWB EGCHO LIST", "", ""], ["1747", "XWB EGCHO BIG LIST", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Private", "", "", "XWB EGCHO BIG LIST", "", ""], ["1748", "XWB EGCHO SORT LIST", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Supported", "", "", "XWB EGCHO SORT LIST", "", ""], ["1749", "XWB EGCHO MEMO", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Supported", "", "", "XWB EGCHO MEMO", "", ""], ["1750", "XWB RPC LIST", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Retired", "Supported", "", "", "XWB RPC LIST", "", ""], ["1751", "XWB CREATE CONTEXT", "Remote Procedure", "RPC BROKER", "2006/11/17", "", "Active", "Private", "", "", "XWB CREATE CONTEXT", "", "2014/04/09"], ["1752", "SCRP SELECTION SOURCE", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP SELECTION SOURCE", "", ""], ["1753", "SCRP FILE ENTRY GETSELECTION", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP FILE ENTRY GETSELECTION", "", ""], ["1754", "SCRP QUERY SAVE", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP QUERY SAVE", "", ""], ["1755", "SCRP QUERY VALIDATE", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP QUERY VALIDATE", "", ""], ["1756", "SCRP QUERY DELETE", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP QUERY DELETE", "", ""], ["1757", "SCRP QUERY CHECK NAME", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP QUERY CHECK NAME", "", ""], ["1758", "SCUT SET USER QUERY DEFAULT", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCUT SET USER QUERY DEFAULT", "", ""], ["1759", "SCRP REPORT PRINT", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SCRP REPORT PRINT", "", ""], ["1760", "SC STAFF LOOKUP", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC STAFF LOOKUP", "", ""], ["1761", "SC USER CLASS STATUS", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC USER CLASS STATUS", "", ""], ["1762", "SC PRIMARY CARE TEAM", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC PRIMARY CARE TEAM", "", ""], ["1763", "SC BUILD PAT CLN LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SC BUILD PAT CLN LIST", "", ""], ["1764", "SC GET PAT BUILD", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Private", "", "", "SC GET PAT BUILD", "", ""], ["1765", "SC ASSIGN PATIENT LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC ASSIGN PATIENT LIST", "", ""], ["1766", "SC FILE PATIENT LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILE PATIENT LIST", "", ""], ["1767", "SC BUILD PAT TM LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC BUILD PAT TM LIST", "", ""], ["1768", "SC GET PAT TM LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC GET PAT TM LIST", "", ""], ["1769", "SC GET PAT BLOCK", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC GET PAT BLOCK", "", ""], ["1770", "SC BLD PAT LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC BLD PAT LIST", "", ""], ["1771", "SC FILE PAT TM ASGN", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILE PAT TM ASGN", "", ""], ["1772", "SC BLD PAT CLN LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC BLD PAT CLN LIST", "", ""], ["1773", "SC FILE PAT POS ASGN", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILE PAT POS ASGN", "", ""], ["1774", "SC BLD PAT SCDE LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC BLD PAT SCDE LIST", "", ""], ["1775", "SC BLD PAT TM LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC BLD PAT TM LIST", "", ""], ["1776", "SC BLD PAT POS LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC BLD PAT POS LIST", "", ""], ["1777", "SC PAT ENROLL CLN", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC PAT ENROLL CLN", "", ""], ["1778", "SC CHECK FOR PC POS", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC CHECK FOR PC POS", "", ""], ["1779", "SC FILE ALL PAT TM ASGN", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILE ALL PAT TM ASGN", "", ""], ["1780", "SC BLD PAT APT LIST", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC BLD PAT APT LIST", "", ""], ["1781", "SC FILE ALL PAT POS ASGN", "Remote Procedure", "SCHEDULING", "2006/11/17", "APPROVED", "Active", "Supported", "", "", "SC FILE ALL PAT POS ASGN", "", ""], ["1782", "TIU GET PN TITLES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2006/11/28", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET PN TITLES", "", ""], ["1783", "TIU GET DS TITLES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/29", "APPROVED", "Active", "Private", "", "", "TIU GET DS TITLES", "", ""], ["1784", "TIU LOAD BOILERPLATE TEXT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU LOAD BOILERPLATE TEXT", "", ""], ["1785", "ORWD ODEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD ODEF", "", ""], ["1786", "ORQPT PRIMARY TEAM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT PRIMARY TEAM", "", ""], ["1787", "ORQPT TEAM PROVIDERS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT TEAM PROVIDERS", "", ""], ["1788", "ORWORDG GRPSEQB", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWORDG GRPSEQB", "", ""], ["1789", "ORWORR GET", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWORR GET", "", ""], ["1790", "TIU SIGN RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU SIGN RECORD", "", ""], ["1791", "ORWU USERINFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWU USERINFO", "", ""], ["1792", "ORWD SAVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD SAVE", "", ""], ["1793", "ORWD SIGN", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD SIGN", "", ""], ["1794", "ORWD SIGNOK", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD SIGNOK", "", ""], ["1795", "ORWD OI", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD OI", "", ""], ["1796", "TIU GET PERSONAL PREFERENCES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/30", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET PERSONAL PREFERENCES", "", ""], ["1797", "SC BLD NOPC TM LIST", "Remote Procedure", "SCHEDULING", "", "APPROVED", "Active", "Supported", "", "", "SC BLD NOPC TM LIST", "", ""], ["1798", "SC PAT ASGN MAILMAN", "Remote Procedure", "SCHEDULING", "", "APPROVED", "Active", "Supported", "", "", "SC PAT ASGN MAILMAN", "", ""], ["1799", "TIU UPDATE RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU UPDATE RECORD", "", ""], ["1800", "TIU REQUIRES COSIGNATURE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU REQUIRES COSIGNATURE", "", ""], ["1801", "TIU LOAD RECORD FOR EDIT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU LOAD RECORD FOR EDIT", "", ""], ["1802", "TIU DETAILED DISPLAY", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/30", "APPROVED", "Active", "Private", "", "", "TIU DETAILED DISPLAY", "", ""], ["1803", "ORWDLR DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDLR DEF", "", ""], ["1804", "ORWDLR LOAD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDLR LOAD", "", ""], ["1805", "TIU CREATE ADDENDUM RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU CREATE ADDENDUM RECORD", "", ""], ["1806", "TIU CREATE RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/29", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU CREATE RECORD", "", ""], ["1807", "ORQPT PATIENT TEAM PROVIDERS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Controlled Subscription", "", "", "ORQPT PATIENT TEAM PROVIDERS", "", ""], ["1808", "ORWDLR ABBSPEC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDLR ABBSPEC", "", ""], ["1809", "ORWDLR ALLSAMP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDLR ALLSAMP", "", ""], ["1810", "ORWDLR OIPARAM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDLR OIPARAM", "", ""], ["1811", "TIU DELETE RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "
1) A document in the CONSULTS class/DC can not be
written unless it is
linked to a Consult request\n
2) A document outside of the CONSULTS class/DC can not be associated
with a consult\n
3) An addendum can not be linked to a consult request directly", "TIU DELETE RECORD", "", ""], ["1812", "ORWPT DEMOG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT DEMOG", "", ""], ["1813", "ORWPT GETVSIT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT GETVSIT", "", ""], ["1814", "ORWU VALIDSIG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWU VALIDSIG", "", ""], ["1815", "ORWPT APPTLST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT APPTLST", "", ""], ["1816", "ORWU HOSPLOC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/03/24", "APPROVED", "Active", "Private", "", "
.Y=returned list, FROM=text to $O from, DIR=$O
direction\n
Sample return data: Y(1)="153^AAC-PROS" Y(2)="274^ALB-PRRTP"
Y(3)="115^ALCOHOL" Y(4)="64^AUDIOLOGY" Y(6)="11^BCMA" Y(9)="143^BON-HBHC
SOCIAL WORK"", "ORWU HOSPLOC", "", "2011/04/21"], ["1817", "ORWPT ADMITLST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "
Returns a list of admissions for a patient (for visit
selection).\n
Input:
DFN [required] = IEN from the Patient file #2\n
Output:
LST(n)=DATA delimited by "^" where n=1,2,3,4,. . .\n
Return Parameter Description\n
If successful: LST(n)=p1^p2^p3^p4^p5^p6\n
Where: p1 := MOVEMENT DATE/TIME p2 := IEN from Hospital Location file#44 p3 :=
Location name-the external value from file #44,.01 p4 := Type name -the
external value from the Facility Movement Type file #405.1,.01 p5 := IEN from
Patient Movement file #45 p6 := IEN from TIU DOCUMENT file #8925,otherwise 0
if no discharge summary p7 := 1 if there is discharge summary, otherwise 0", "ORWPT ADMITLST", "", ""], ["1818", "ORWU VALDT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWU VALDT", "", ""], ["1819", "ORWPT PSCNVT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT PSCNVT", "", ""], ["1820", "ORWD FORMID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD FORMID", "", ""], ["1821", "ORWD GET4EDIT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD GET4EDIT", "", ""], ["1822", "ORWD VALIDACT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD VALIDACT", "", ""], ["1823", "ORWD SAVEACT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD SAVEACT", "", ""], ["1824", "ORWD DT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Private", "", "", "ORWD DT", "", ""], ["1825", "ORWDCSLT LOOK200", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDCSLT LOOK200", "", ""], ["1826", "ORWDCSLT DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDCSLT DEF", "", ""], ["1827", "ORWD PROVKEY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWD PROVKEY", "", ""], ["1828", "ORWDGX LOAD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDGX LOAD", "", ""], ["1829", "ORWDPS LOAD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDPS LOAD", "", ""], ["1830", "ORWDRA DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDRA DEF", "", ""], ["1831", "ORWDGX VMDEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDGX VMDEF", "", ""], ["1832", "ORWDPS DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDPS DEF", "", ""], ["1833", "ORWDLR STOP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWDLR STOP", "", ""], ["1834", "TIU PRINT RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU PRINT RECORD", "", ""], ["1835", "TIU GET DOCUMENT PARAMETERS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/29", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET DOCUMENT PARAMETERS", "", ""], ["1836", "ORWU NEWPERS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2023/10/13", "APPROVED", "Active", "Controlled Subscription", "", "
When CPRS v33MOE releases, this RPC call will be
replaced in the CPRS GUI application. The new RPC call is ORNEWPERS NEWPERSON.
The plan is to remain backward compatibility with ORWU NEWPERS while allowing
expansion capabilities with ORNEWPERSON NEWPERSON.\n
For anyone updating ORNEWPERSON NEWPERSON, remember that you must ensure that
ORWU NEWPERS still functions correctly.", "ORWU NEWPERS", "", "2023/10/16"], ["1837", "ORWU DEVICE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Private", "", "", "ORWU DEVICE", "", ""], ["1838", "ORWRA IMAGING EXAMS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWRA IMAGING EXAMS", "", ""], ["1839", "ORWRA REPORT TEXT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWRA REPORT TEXT", "", ""], ["1840", "ORWRP REPORT LISTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWRP REPORT LISTS", "", ""], ["1841", "ORWRP REPORT TEXT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2009/12/18", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWRP REPORT TEXT", "", "2009/12/20"], ["1842", "ORWRP PRINT REPORT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Controlled Subscription", "", "", "ORWRP PRINT REPORT", "", ""], ["1843", "ORWLR REPORT LISTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Controlled Subscription", "", "", "ORWLR REPORT LISTS", "", ""], ["1844", "ORWLR CUMULATIVE SECTION", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Controlled Subscription", "", "", "ORWLR CUMULATIVE SECTION", "", ""], ["1845", "ORWU URGENCY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "", "Withdrawn", "Private", "", "", "ORWU URGENCY", "", ""], ["1846", "DBIA1846", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "44", "
In addition to fields which are supported by DBIA
10040, DSS Extracts will reference the following data from the HOSPITAL
LOCATION file (#44).\n
Numerous DSS extract files contain a field (e.g., WARD, CLINIC NAME, LOSING
WARD, OR ROOM NUMBER, LOCATION (WARD OR CLINIC)) which is a pointer to the
HOSPITAL LOCATION file (#44).", "", "", ""], ["1847", "DBIA1847", "File", "REGISTRATION", "1996/11/21", "APPROVED", "Active", "Private", "21", "
DSS Extracts will reference the following data from the
PERIOD OF SERVICE file (#21).", "", "", ""], ["1848", "DBIA1848", "File", "REGISTRATION", "1996/11/26", "APPROVED", "Active", "Controlled Subscription", "42", "
In addition to fields which are supported by DBIA
10039, DSS Extracts will reference the following data from the WARD LOCATION
file (#42).\n
The DSS Extracts UNIT DOSE EXTRACT DATA file (#728.904) contains a field,
WARD, which is a pointer to the WARD LOCATION file (#42).\n
DSS uses the "AINV" cross reference on the OUT-OF-SERVICE DATE(S) field.
Global: ^DIC(42,D0,"OOS","AINV",INVERSE_DATE,DA)\n", "", "", ""], ["1849", "DBIA1849", "File", "REGISTRATION", "1996/11/26", "", "Under Revision", "Private", "40.8", "
DSS Extracts will point to the MEDICAL CENTER DIVISION
file (#40.8). Most of the DSS extract files include a free text FACILITY field
which contains a pointer to this file.\n
Direct read of the 'B' Cross Reference is permitted.", "", "", ""], ["1850", "DBIA1850", "File", "REGISTRATION", "1996/11/26", "APPROVED", "Active", "Controlled Subscription", "2", "
In addition to fields which are supported by DBIA
10035, DSS Extracts references the following data from the PATIENT file (#2).\n
Most of the DSS Extracts files contain a field, PATIENT NO. - DFN, which is a
pointer to the PATIENT file (#2).\n
This agreement now includes only the PREFERRED FACILITY field (#27.02). All
other PATIENT file data is obtained by use of supported functionality in
^VADPT.\n", "", "", ""], ["1851", "DBIA1851", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1996/12/03", "APPROVED", "Active", "Private", "78.3", "
The DSS Extracts RADIOLOGY EXTRACT file (#727.814)
contains a field, DIAGNOSTIC CODE, which is a pointer to the DIAGNOSTIC CODES
file (#78.3).", "", "", ""], ["1852", "DBIA1852", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1996/12/03", "APPROVED", "Active", "Private", "79.2", "
DSS Extracts references the following data from the
IMAGING TYPE file(#79.2).\n
The DSS Extracts RADIOLOGY EXTRACT file (#727.814) contains a field, IMAGING
TYPE, which is a pointer to the IMAGING TYPE file (#79.2).", "", "", ""], ["1853", "DBIA1853", "File", "SURGERY", "1996/12/03", "APPROVED", "Active", "Private", "131.7", "
DSS Extracts references the following data from the
OPERATING ROOM file (#131.7).", "", "", ""], ["1854", "DBIA1854", "File", "SURGERY", "1996/12/03", "APPROVED", "Active", "Private", "134", "
The DSS Extracts SURGERY EXTRACT file (#727.811)
contains a field, OR TYPE, which is a pointer to the OPERATING ROOM TYPE file
(#134).", "", "", ""], ["1855", "DBIA1855", "File", "SURGERY", "1996/12/03", "APPROVED", "Active", "Private", "137.45", "
DSS Extracts references the following data from the
LOCAL SURGICAL SPECIALTY file (#137.45).", "", "", ""], ["1856", "DBIA1856", "File", "REGISTRATION", "1996/12/03", "APPROVED", "Active", "Private", "45", "
DSS Extracts references the following data from the PTF
file (#45).\n
From the 501 multiple (45.02):", "", "", ""], ["1857", "DBIA1857", "File", "REGISTRATION", "1996/12/04", "APPROVED", "Active", "Private", "45.9", "
DSS Extracts references the following data from the PAF
file (#45.9).\n
DSS uses the "AA" cross reference on the ASSESSMENT DATE field.
Global: ^DG(45.9,"AA",DATE,D0)", "", "", ""], ["1858", "DBIA1858", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1996/12/04", "APPROVED", "Active", "Private", "72", "
DSS Extracts references the following data from the
EXAMINATION STATUS file (#72).", "", "", ""], ["1859", "DBIA1859", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1996/12/04", "APPROVED", "Active", "Private", "79", "
DSS Extracts references the following data from the
RAD/NUC MED DIVISION file (#79).\n
Direct global read of the 'B' cross reference is also permitted in file #79.\n
Revision History:\n
11/05/2024 Added IMAGING LOCATION field for use by MEDICOM.\n
Radiology Custodian Noted that both 79'& 79.1's top-level .01's are pointers
themselves to the INSTITUTION & HOSPITAL LOCATION files.", "", "", ""], ["1860", "DBIA1860", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1996/12/04", "APPROVED", "Active", "Controlled Subscription", "79.1", "
The DSS Extracts RADIOLOGY EXTRACT file (#727.814)
contains a field, IMAGING LOCATION, which is a pointer to the RADIOLOGY
LOCATIONS file (#79.1).", "", "", ""], ["1861", "DBIA1861", "File", "REGISTRATION", "1996/12/04", "APPROVED", "Active", "Controlled Subscription", "10", "
DSS Extracts references the following data from the
RACE file (#10).", "", "", ""], ["1862", "DBIA1862", "File", "DENTAL", "1996/12/04", "", "Retired", "Private", "220.2", "
The DSS Extracts DENTAL EXTRACT file (#727.806)
contains a field, PATIENT CATEGORY, which is a pointer to the DENTAL
CLASSIFICATION file (#220.2).", "", "", ""], ["1863", "DBIA1863", "File", "DENTAL", "1996/12/04", "APPROVED", "Active", "Private", "220.5", "
DSS Extracts references the following data from the
DENTAL PROVIDER file (#220.5).", "", "", ""], ["1864", "DBIA1864", "File", "DENTAL", "1996/12/04", "APPROVED", "Active", "Private", "225", "
DSS Extracts references the following data from the
DENTAL SITE PARAMETERS file (#225). (Included in these references is a Direct
Global Read of the 'B' Cross Reference.)", "", "", ""], ["1865", "DBIA1865", "File", "REGISTRATION", "1996/12/05", "APPROVED", "Active", "Controlled Subscription", "405", "
DSS Extracts points to and references the following
data from the PATIENT MOVEMENT file (#405).\n
Most of the DSS extract files include a MOVEMENT FILE # field which is a
pointer to the PATIENT MOVEMENT file (#405).\n
For the extract date range, DSS uses the following cross references:
"ATID1" cross reference ^DGPM("ATID1",DFN,INVERSE_DATE,D0
"ATID2" cross reference ^DGPM("ATID2",DFN,INVERSE_DATE,D0
"ATID6" cross reference ^DGPM("ATID6",DFN,INVERSE_DATE,D0
"ATT1" cross reference ^DGPM("ATT1",DATE,D0
"ATT2" cross reference ^DGPM("ATT2",DATE,D0
"ATT3" cross reference ^DGPM("ATT3",DATE,D0
"ATT6" cross reference ^DGPM("ATT6",DATE,D0
"APCA" cross reference ^DGPM("APCA",DFN,CORRES_ADM,DATE,D0
"APMV" cross reference ^DGPM("APMV",DFN,CORRES_ADM,INVERSE_DATE,D0
"ATS" cross reference ^DGPM("ATS",DFN,CORRES_ADM,INVERSE_DATE,
TREATING_SPECIALTY,D0\n", "", "", "2018/10/26"], ["1866", "DBIA1866", "File", "REGISTRATION", "1996/12/05", "", "Retired", "Private", "408.32", "
DSS Extracts references the following data from the
MEANS TEST STATUS file (#408.32).\n
The use of utilities to extract this information will be investigated prior to
the release of a verified version of DSS Extracts (e.g., $$LST^DGMTU).\n", "", "", ""], ["1867", "DBIA1867", "File", "KERNEL", "1996/12/05", "APPROVED", "Active", "Private", "200", "
This IA adds two fields to file 200 -- COMMERCIAL PHONE
(# .135) and SUPPLY EMPLOYEE (# 400). These fields should be sent out any
time file 200 is sent out as a full DD. No data should go with these fields.
Any data at the sites in those fields should remain.", "", "", ""], ["1868", "DBIA1868", "File", "SCHEDULING", "1996/12/05", "", "Retired", "Private", "409.5", "
DSS Extracts references the following data from the
SCHEDULING VISITS file (#409.5).\n
As of 12/5/96, it is understood that this file may soon become obsolete as
part of the ambulatory care development.\n", "", "", ""], ["1869", "DBIA1869", "File", "EVENT CAPTURE", "1996/12/05", "APPROVED", "Active", "Private", "720", "
DSS Extracts references the following data from the
EVENT CAPTURE PROCEDURE file (#720).\n", "", "", ""], ["1870", "DBIA1870", "File", "EVENT CAPTURE", "1996/12/05", "APPROVED", "Active", "Private", "720.1", "
DSS Extracts references the following data from the
EVENT CAPTURE LOG file (#720.1).\n", "", "", ""], ["1871", "DBIA1871", "File", "EVENT CAPTURE", "1996/12/05", "", "Retired", "Private", "720.2", "
DSS Extracts references the following data from the
EVENT CODE SCREENING file (#720.2).\n", "", "", ""], ["1872", "DBIA1872", "File", "EVENT CAPTURE", "1996/12/05", "APPROVED", "Active", "Private", "720.3", "
DSS Extracts references the following data from the EC
EVENT CODE SCREENS file (#720.3).\n
In order to pass the correct version number to the Austin Automation Center,
DSS Extracts examines the Event Capture DD as follows:
I $D(^DD(720.3)) S ECVER=<current version number>\n", "", "", ""], ["1873", "DBIA1873 READ ACCESS TO FILE #721", "File", "EVENT CAPTURE", "1996/12/05", "", "Active", "Controlled Subscription", "721", "
DSS Extracts references the following data from the
EVENT CAPTURE PATIENT file (#721).\n
DSS checks for the existence of the EVENT CAPTURE PATIENT file (#721) to
determine if Event Capture is in use prior to performing the extract (i.e.,
global ^ECH).\n
DSS uses the "AC1" cross reference on the DATE/TIME OF PROCEDURE field.
Global: ^ECH("AC1",LOCATION,DATE,DA)\n
The Re-Engineered SPINAL CORD DYSFUNCTION application needs to acces the EVENT
CAPTURE PATIENT file (#721) for reporting purposes. Spinal Cord needs the
ability to look at a patient's CPT and ICD code history.\n
MHV uses the "APAT" cross reference on the Procedure IEN, Date/Time of
Procedure fields to get the IEN of Workload, ^ECH("APAT",Procedure
IEN,Date/Time of Procedure fields,Workload IEN).\n
Read-only access is granted for:-\n
EVENT CAPTURE PATIENT file (# 721)
^ECH(D0,0)
2 DATE/TIME OF PROCEDURE 0;3
^ECH(D0,"DX",D1,0)
.01 SECONDARY ICD-9 CODE 0;1
^ECH(D0,"P")
19 PCE CPT CODE P;1
20 PRIMARY ICD-9 CODE P;2
^ECH("APAT")", "", "", "2007/01/23"], ["1874", "DBIA1874", "File", "EVENT CAPTURE", "1996/12/05", "APPROVED", "Active", "Controlled Subscription", "725", "
MHV Secure Messaging - Workload Credit HL7 Interface
references NAME, NATIONAL NUMBER fields from the EC NATIONAL PROCEDURE file
(#725).\n
DSS Extracts references the following data from the EC NATIONAL PROCEDURE file
(#725).\n
The 'E' cross reference will also be referenced with a Direct global read.
^EC(725,"E",National Number, DA).", "", "", ""], ["1875", "DBIA1875", "File", "EVENT CAPTURE", "1996/12/05", "APPROVED", "Active", "Private", "726", "
DSS Extracts points to and references the following
data from the EVENT CAPTURE CATEGORY file (#726).\n
The DSS Extracts EVENT CAPTURE LOCAL EXTRACT file (#727.815) contains a field,
CATEGORY, which is a pointer to the EVENT CAPTURE CATEGORY file (#726).\n", "", "", ""], ["1876", "DBIA1876", "File", "OUTPATIENT PHARMACY", "1996/12/06", "APPROVED", "Active", "Controlled Subscription", "59", "
The DSS PRESCRIPTION EXTRACT file (#727.81) contains
the DIVISION field (9) which is a pointer to the OUTPATIENT SITE file (#59).\n
Direct global read of the 'B' Cross Reference is permitted into this file.\n", "", "", ""], ["1877", "DBIA1877", "File", "NURSING SERVICE", "1996/12/10", "APPROVED", "Active", "Private", "213.3", "
The DSS Extracts NURSING EXTRACT file (#727.805)
contains a field, NURSING BEDSECTION, which is a pointer to the NURS AMIS WARD
file (#213.3).\n", "", "", ""], ["1878", "DBIA1878", "Routine", "OUTPATIENT PHARMACY", "1996/12/11", "APPROVED", "Active", "Supported", "", "
Open subscription for Outpatient Pharmacy prescription
data.", "", "PSOORDER", ""], ["1879", "DBIA1879", "File", "INPATIENT MEDICATIONS", "1996/12/11", "", "Retired", "Private", "50.8", "
DSS Extracts references the following data from the IV
STATS file (#50.8).\n
DSS uses the "AC" cross reference on the IV DRUG field. Global:
^PS(50.8,IV_ROOM,2,DATE,2,"AC",FILE_52_.6 or .7,IEN_addtv_or_soln,IV_DRUG#)
Example: ^PS(50.8,2,2,2910513,2,"AC",52.6,24,2) =
^PS(50.8,2,2,2910513,2,"AC",52.7,7,3) =\n
References to the IV STATS file (#50.8), occur ONLY for the small number of
sites who are still running a version of Inpatient Meds prior to version 4.5.
For version 4.5 (or greater), this information comes from the IV EXTRACT DATA
holding file (#728.113) which is populated by PSIVSTAT.\n", "", "", ""], ["1880", "DBIA1880", "File", "PHARMACY DATA MANAGEMENT", "1996/12/12", "APPROVED", "Active", "Private", "52.6", "
DSS Extracts references the following data from the IV
ADDITIVES file (#52.6).\n
This reference is used ONLY for the small number of sites who are still
running a version of Inpatient Meds prior to version 4.5. For version 4.5 (or
greater), this information comes from the IV EXTRACT DATA holding file
(#728.113) which is populated by PSIVSTAT.\n", "", "", ""], ["1881", "DBIA1881", "File", "PHARMACY DATA MANAGEMENT", "1996/12/12", "", "Retired", "Private", "52.7", "
DSS Extracts references the following data from the IV
SOLUTIONS file (#52.7).\n
This reference is used ONLY for the small number of sites who are still
running a version of Inpatient Meds prior to version 4.5. For version 4.5 (or
greater), this information comes from the IV EXTRACT DATA holding file
(#728.113) which is populated by PSIVSTAT.\n", "", "", ""], ["1882", "ACCESS TO ECXPIV1", "Routine", "DSS - DECISION SUPPORT SYSTEM EXTRACTS", "1996/12/12", "APPROVED", "Active", "Private", "", "
DSS Extracts needs data from the Inpatient Medications
package which cannot be extracted from any file. The IV team has modified
routine PSIVSTAT to call, after executing %ZOSF("TEST"), routine ECXPIV1 to
move data into a DSS file for future extract by DSS.\n
The requested data is placed in the ECUD variable, which the ECXPIV1 routine
uses to store the data in the IV EXTRACT DATA file (#728.113).", "", "ECXPIV1", ""], ["1883", "DBIA1883", "File", "PHARMACY DATA MANAGEMENT", "1996/12/13", "", "Retired", "Private", "55", "
DSS Extracts references the following data from the
PHARMACY PATIENT file (#55).\n
This integration agreement is for version 4.5 (or less) of Inpatient
Medications. When version 5.0 of Inpatient Medications is released, this
reference must be replaced. At that time, the information will be returned as
part of the data stream that is passed in PSIVSTAT.\n", "", "", ""], ["1884", "DBIA1884", "File", "INPATIENT MEDICATIONS", "1996/12/13", "APPROVED", "Active", "Controlled Subscription", "59.5", "
DSS Extracts references the following data from the IV
ROOM file (#59.5).\n
This agreement will be restricted to only Pharmacy packages after 12/31/2006.
Please do not add any additional code that utilizes this Integration
Agreement. An API has been created that can be used in place of any code
needing to make use of this agreement. This API was released with patch
PSJ*5*163. Documentation information can be found in the patch description. In
addition, any code that currently utilizes this Integration Agreement must be
converted to use the new API's. If any part of this Integration Agreement
cannot be satisfied with this API, please contact the PRE development team
mail group at EMAIL GROUP DEV using Microsoft Outlook.", "", "", ""], ["1885", "IFCAP Vendor Display Format $P(.VA(200,,400),U,2)", "File", "KERNEL", "1996/12/19", "", "Pending", "Supported", "200", "\n\n
This field stores the user's desired format for displaying a list of vendors.
Terminal users have requested a minimum number of lines per vendor so that
vendors won't scroll of the top of the screen. The Horizontal (2 line) format
and a Vertical 4-6 line format are illustrated below. Entry of VS or HS will
make that choice automatically throughout this session, i.e. until you log in
again. Entry of VA or HA will mean you won't be prompted for a choice again.\n\n
Normal Usage\n
Select VENDOR NAME: ??\n
Choose from:
1 AOBC SEE WHAT SHOWS UP FOR LONG NAME How should Vendor
Addresses be displayed? : (HR/VR/HS/VS/HA/VA): VR// ?\n
'Session' means until you log in again. 'Always' means never seeing this
again.\n
Select one of the following:\n
HR Horizontal (minimum # of lines) -- Reask every selection
VR Vertical (Postal Format) -- Reask ''
HS Horizontal -- every time this Session
VS Vertical -- ''
HA Always Horizontal -- never Ask again
VA Always Vertical -- ''\n\n\n
Field can also be set explicitly via the
Enter/Edit Vendor Display Format option\n\n\n\n
200,402 Vendor Display Format 400;2 SET\n
VENDOR DISPLAY FORMAT
'HR' FOR Horizontal (minimum # of lines) -
Reask every list;
'VR' FOR Vertical (Postal Format) - '';
'HS' FOR Horizontal -- rest of Session;
5 CENTRAL BUSINESS SERVICES
AND SUPP EDI VENDOR 202 491- 0231 NO.
5\n
FMS VENDOR CODE:NAME: 37844821002: SPECIAL
FACTORS: VENDOR MUST BE CALLED PRIOR TO
MAILING
PO ORDERING ADDRESS: 4000 RESERVOIR ROAD
WASHINGTON, DC 20008
6 **MILAN >> INACTIVE No
substitute defined
7 SAM'S 512-876-4433
NO.
7 FMS VENDOR CODE:NAME: MISC1234501: SPECIAL
FACTORS: ORDERING ADDRESS: 4 HIGH ST
AUSTIN, TX 75434
8 GENERIC GENERAL STORE
301-427-3700 NO. 8 FMS VENDOR CODE:NAME:
123456798: SPECIAL FACTORS: ORDERING ADDRESS:
111 MAIN STREET
SILVER SPRING, MD 20910\n\n
Horizontal Format Example:\n
4 DAN'S DOG FOOD SUPPLY `14
123-4567
Order From: 1234 STATE STREET; ; ; ; ZW
DQ, MD 20708
5 CENTRAL BUSINESS SERVICES
AND SUPP `5 202 491-0231
FMS #-NAME: 37844821002-
Note: VENDOR MUST BE CALLED PRIOR
TO MAILING PO
EDI Fax: 301 427-3700 Order From:
4000 RESERVOIR ROAD; SUITE 200; ;
WASHINGTON, DC 20008
6 **MILAN >> INACTIVE No
substitute defined\n
7 SAM'S `7 512-876-4433
FMS
#-NAME: MISC1234501-
Order From: 4 HIGH ST; CHECK THIS OUT;
;
; AUSTIN, TX 75434\n\n
DESCRIPTION
This field stores the user's desired format
for
displaying a list of vendors. Terminal users
have requested a minimum number of lines per
vendor so that vendors won't scroll of the top
of the screen. The Horizontal (2 line) format
and a Vertical 4-6 line format are illustrated
below. Entry of VS or HS will make that
choice
automatically throughout this session, i.e.
until you log in again. Entry of VA or HA
will
mean you won't be prompted for a choice again.\n\n
SCREEN: S DIC("S")="I Y'=""B""!(DUZ(0)=""@"")"
EXPLANATION: Programmers have an additional option.
SOURCE OF DATA: User decision
DATA DESTINATION: PRCH69", "", "", ""], ["1886", "DBIA1886-A", "File", "HOME BASED PRIMARY CARE", "1997/01/16", "APPROVED", "Active", "Private", "631", "
The "AC" cross-reference will be used to find HBHC
patients discharged within a date range.", "", "", ""], ["1887", "DBIA1886-B", "File", "HOME BASED PRIMARY CARE", "1997/01/17", "APPROVED", "Active", "Private", "631.4", "", "", "", ""], ["1888", "DBIA1888", "File", "REGISTRATION", "1997/01/23", "APPROVED", "Active", "Private", "45", "\n
The Lab Emerging Pathogen Initiative is requesting a integration
agreement to reference to two fields in the PTF file (#45)\n
PTF file (#45)\n
^DGPT(D0,300) = (#300.03) LEGIONNAIRE'S DISEASE\n
^DGPT(D0,"M",D1,300) = (#300.03) LEGIONNAIRE'S DISEASE\n\n\n", "", "", ""], ["1889", "ADD/EDIT/DELETE PCE DATA SILENTLY", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "\n
PURPOSE: Provide a utility for ancillary packages such as Laboratory,
Surgery, Medicine, Radiology, Text Integration Utility (TIU)
and Computerized Patient Record System (CPRS) to non-
interactively (silently) add/edit/delete data, including
encounter, provider, diagnosis and procedure information.\n
Dr. Kizer's 10/1/96 mandate which requires a provider, a procedure and a
diagnosis to positively document the occurrence of an encounter, and the
resulting change to use this data rather than stop codes to document
workload and initiate third party billing, necessitated the development of
an application programmer interface (API) which would support the mandated
requirements. PCE was tasked with developing the API. $$DATA2PCE^PXAPI
was developed to enable the adding, editing and deletion of encounter,
provider, diagnosis and procedure data. Data will be stored in the Visit
and V files and will be posted on the PXK VISIT DATA EVENT for use by
subscribing packages such as Scheduling.\n
This document includes:
1. Definitions and Conventions used to describe the API.
2. Description of $$DATA2PCE^PXAPI, its parameter definitions, and the
returned values.
3. A table which describes the subscripts used for passing data to
PCE.
4. An example array for passing data to PCE.\n
DEFINITIONS AND CONVENTIONS:\n
Listed below are definitions and conventions used to describe this API.\n
1. Valid data values: [ 1 | 0 | null ]
`1' Denotes TRUE or YES
`0' Denotes FALSE or NO
null Denotes VALUE NOT KNOWN
2. Counter "i" is used as a subscript. It denotes a sequence number,
i.e., 1, 2,
3. To denote deletion of a data ITEM, pass the "@" symbol as the data
value in the node for the item being deleted. You may not delete
required data items.
4. To denote deletion of an ENTRY, pass "1" as the data value in the
"DELETE" node of the identified entry.\n\n
$$DATA2PCE^PXAPI(INPUT_ROOT,PKG,SOURCE,.VISIT,USER,ERRDISP,.ERRARRAY,PPEDIT,
.ERRPROB,.ACCOUNT)\n
This is a function which will return a value identifying the status of the
call. Data that is processed by PCE will be posted on the PXK VISIT DATA
EVENT protocol.\n
Parameter Description:\n
1. INPUT_ROOT: (required) Where INPUT_ROOT is a unique variable
name, either local array or global array, which identifies the
defined data elements for the encounter. An example of an
INPUT_ROOT is ^TMP("LRPXAPI",$J) or ^TMP("RAPXAPI",$J). The gross
structure of the array includes four additional subscripts
(ENCOUNTER, PROVIDER, DX/PL, PROCEDURE and STOP) for defining the
data passed. A detailed description of this array and its
structure are included below in a table format.\n
2. PKG: (required) Where PKG is a pointer to the Package File (9.4).\n
3. SOURCE: (required) Where SOURCE is a string of text (3-30
character) identifying the source of the data. The text is the
SOURCE NAME field (.01) of the PCE Data Source file (839.7). If
the SOURCE currently does not exist in the file, it will be added.
Examples of SOURCE are: "LAB DATA" or "RADIOLOGY DATA" or "PXCE
DATA ENTRY" or "AICS ENCOUNTER FORM."\n
4. VISIT: (optional) Where VISIT is a pointer to the Visit
file (9000010) which identifies the encounter which this data
must be associated with. If the pointer to the Visit file does not
match
data passed in INPUT_ROOT then this DBIA will return negative value
'-3', see the Returned Value description below.
If the pointer value to the Visit is
saved, it is necessary to also subscribe to IA 1902.\n
5. USER: (optional) User who is responsible for add/edit/delete
action on the encounter. Pointer to the New Person file (200).
If USER is not defined, DUZ will be used.\n
6. ERRDISP: (optional) To display errors during development,
this variable may be set to "1". If it is defined the errors will
be displayed on screen when the error occurs. If ERRDISP is
not defined, errors will be posted on the defined INPUT_ROOT
subscripted by "DIERR". BLD^DIALOG is used to manage errors.
Review BLD^DIALOG and MSG^DIALOG descriptions included in the
FileMan v. 22.0 Programmer Manual on pages 2-33 to 2-38.\n
7. ERRARRAY: (optional) A dotted variable name. When errors and
warnings occur, the array will contain the PXKERROR array elements
to the caller.\n
8. PPEDIT: (optional) Set to 1 if you want to edit the
Primary Provider. Only use for the moment that editing is
being done.\n
8. ERRPROB: (optional) A dotted variable name. When errors and
warnings occur, they will be passed back in the form of an array
with the general description of the problem.\n
8. ACCOUNT: (optional) A dotted variable name. Where ACCOUNT is the
PFSS Account Reference associated with the data being by the calling
application. Each PFSS Account represents an internal entry number
in the PFSS ACCOUNT file (#375).\n
Returned Value:\n
1 If no errors occurred and data was processed.
-1 An error occurred. Data may or may not have been processed.
If ERR_DISPLAY is undefined, errors will be posted on the
INPUT_ROOT subscripted by "DIERR".
-2 Unable to identify a valid VISIT. No data was processed.
-3 API was called incorrectly. No data was processed.\n
It is advisable to verify a Return Value for confirmation if the
passed data was processed or not, also if this DBIA is called in
background.\n
ENCOUNTER: All data must be associated with an entry in the VISIT file
(#9000010). Only one "ENCOUNTER" node may be passed with each call to
$$DATA2PCE^PXAPI. The "ENCOUNTER" node documents encounter specific
information and must be passed:
1. To create an entry in the VISIT file (9000010). All provider,
diagnosis and procedure data is related to an entry in the
VISIT file.
2. To enable adding, editing or deleting "ENCOUNTER" node data
elements. When encounter data elements are not added, edited or
deleted, the VISIT parameter may be passed in lieu of defining an
"ENCOUNTER" node.\n
SUBSCRIPT DESCRIPTION:\n
"ENCOUNTER",1,"ENC D/T") Required
This is the encounter date/ time for primary encounters or the date
for occasions of service. If the encounter is related to an
appointment, this is the appointment date/time. If this is an
occasion of service created by an ancillary package, this is
the date/time of the instance of care.
Imprecise dates are allowed for historical encounters.
Encounter date/time may be added, but not edited.
*Deletions of encounters can occur only when nothing is pointing
to the encounter.
*"ENC D/T" is not required for existing visits where the visit
number is included in the parameter list but if it is passed
then it will be checked against the VISIT/ADMIT DATE&TIME field
(#.01)
in the Visit file of the vistit IEN passed as the VISIT
parameter.
Only matching values will be accepted and if on match occurs
then '-3' will be retured, see the Returned Value above.
Format: FileMan Internal Format for date/time
"ENCOUNTER",1,"PATIENT") Required
This is the patient DFN. This cannot be edited or deleted.
*"PATIENT" is not required for existing visits where the visit
number is included in the parameter list but if it is passed then
it will be
checked against the PATIEN NAME field (# .05) in the Visit file of the\n
visit IEN passed as the VISIT parameter. Only matching values
will be accepted and if on match occurs then -3 will be
returned, see
the Returned Value above.
Format: Pointer to IHS Patient file (9000001)
This file is Dinumed to the Patient file (2)
"ENCOUNTER",1,"HOS LOC") Required
This is the hospital location where the encounter took place for
primary encounters, or this is the ordering location for
ancillary encounters.
*"HOS LOC" is not required for existing visits where the visit
number is included in the parameter list but if it is passed
then it will be checked against the HOSPITAL LOCATION filed
(#.22)
in the Visit file of the visit IEN passed as the VISIT parameter.\n
Only matching values will be accepted and if no match occurs
then '-3' will be returned, see the Returned Value above.
Format: Pointer to Hospital Location file (44)
"ENCOUNTER",1,"OUTSIDE LOCATION") Optional
This is an outside location of an encounter, not included in the
INSTITUTION file. The OUTSIDE LOCATION should exclude the
INSTITUTION: "ENCOUNTER",1,"INSTITUTION") and
the INSTITUTION should exclude the OUTSIDE LOCATION.
Format: Free text (2-245 characters)
"ENCOUNTER",1,"INSTITUTION") Optional
This is the Institution where the encounter took place. If it is
not defined, the division defined for the Hospital Location is
used. If that is not defined, $$SITE^VASITE is used.
Format: Pointer to IHS Location file (9999999.06).
This file is dinumed to the Institution file (4).
"ENCOUNTER",1,"SC") Optional
This encounter is related to a service connected condition.
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"CV") Optional
This encounter is related to Combat Veteran
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"AO") Optional
This encounter is related to Agent Orange exposure.
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"IR") Optional
This encounter is related to Ionizing Radiation exposure.
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"EC") Optional
This encounter is related to Environmental Contaminant exposure.
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"SHAD") Optional
This encounter is related to Project 112/SHAD
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"MST") Optional
This encounter is related to Military Sexual Trauma.
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"HNC") Optional
This encounter is related to Head & Neck Cancer.
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"CLV") Optional
This encounter is related to Camp Lejeune.
Format: [ 1 | 0 | null ]
"ENCOUNTER",1,"CHECKOUT D/T") Optional
This is the date/time when the encounter was checked out.
Format: FileMan Internal Format for date/time
"ENCOUNTER",1,"ELIGIBILITY") Optional
This is the eligibility of the patient for this encounter.
Format: Pointer to Eligibility Code file (8)
"ENCOUNTER",1,"APPT") Optional
This is the appointment type of the encounter.
Format: Pointer to Appointment Type file (409.1)
"ENCOUNTER",1,"SERVICE CATEGORY") Required
This denotes the type of encounter.
Format: Set of Codes.
A::=Ambulatory
Should be used for clinic encounters. "A" s are changed
to "I" s by Visit Tracking if patient is an inpatient at
the time of the encounter.
H::=Hospitalization
Should be used for an admission.
I::=In Hospital
C::=Chart Review
T::=Telecommunications
N::=Not Found
S::=Day Surgery
E::=Event (Historical)
Documents encounters that occur outside of this facility.
Not used for workload credit or 3rd party billing.
R::=Nursing Home
D::=Daily Hospitalization Data
X::=Ancillary Package Daily Data.
"X" s are changed to "D" s by Visit Tracking if patient is
an inpatient at the time of the encounter.
"ENCOUNTER",1,"DSS ID") Optional
This is required for ancillary occasions of service such as
laboratory and radiology or telephone encounters
Format: Pointer to Clinic Stop file (40.7)
"ENCOUNTER",1,"ENCOUNTER TYPE") Required
This identifies the type of encounter, e.g., primary encounter,
ancillary encounter, etc. A "Primary" designation indicates
that the encounter is associated with an appointment or is a
standalone. Examples of ancillary encounters include
Laboratory and Radiology instances of care.
Format: Set of Codes.
P::=Primary
O::=Occasion of Service
S::=Stop Code
A::=Ancillary
Ancillary packages such as Laboratory and Radiology
Should pass an "A"
C::=Credit Stop
If the visit number is included in passed parameters then
the passed code will be checked against the ENCOUNTER TYPE field
(#15003)
in the Visit file of the visit IEN passed as VISIT parameter.
Only matching values will be accepted and if no match occurs
then '-3' will be returned, see the Returned Value above.
"ENCOUNTER",1,"PARENT") Optional
This is the parent encounter for which the ENCOUNTER is a
supporting encounter. For example, this would be the primary
encounter for which this occasion of service supports and
should be associated.
Format: Pointer to Visit file (9000010).
"ENCOUNTER",1,"COMMENT") Optional
Comment
Format: Free Text (1-245 characters) "ENCOUNTER",1,"DELETE")
Optional
This is a flag that denotes deletion of the encounter entry.
Encounter will not be deleted if other data is pointing to it.
Format: [ 1 | null ]|\n\n
PROVIDER: The "PROVIDER" node may have multiple entries (i) and documents
the provider, indicates whether he/she is the primary provider, and
indicates whether the provider is the attending provider. Comments may
also be passed. To delete the entire "PROVIDER" entry, set the "DELETE"
node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"PROVIDER",i,"NAME") Required
Provider's IEN.
Format: Pointer to NEW PERSON file (200)
"PROVIDER",i,"PRIMARY") Optional
Indicator that denotes this provider as the "primary" provider.
Format: [ 1 | 0 | null ]
"PROVIDER",i,"ATTENDING") Optional
Indicator that denotes this provider as the attending provider.
Format: [ 1 | 0 | null ]
"PROVIDER",i,"COMMENT") Optional
Comment
Format: Free text (1 - 245 characters)
"PROVIDER",i,"DELETE") Optional
This is a flag that denotes deletion of the Provider entry.
Format: [ 1 | null ]|\n\n
DX/PL: The "DX/PL" node may have multiple entries (i) and documents
diagnoses and/or problems. Only active ICD-9-CM codes will be accepted.
The "DX/PL" node adds diagnoses to the PCE database as well as adding an
active or inactive diagnosis or problem to the Problem List. If a
diagnosis or problem already exists on the Problem List, this node may be
used to inactivate it. To delete the entire "DX/PL" entry from PCE (not
Problem List), set the "DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"DX/PL",i,"DIAGNOSIS") Required for PCE Optional for PL
Diagnosis code
Format: Pointer to ICD9 Diagnosis file (80)
"DX/PL",i,"PRIMARY") Optional for PCE N/A for PL
Code that specifies that the diagnosis is the "primary" diagnosis
for this encounter. Only one "primary" diagnosis is recorded
for each encounter.
Format: "P"::=Primary
"1"::=Primary
"S"::=Secondary
"0"::=Secondary
"DX/PL",i,"ORD/RES") Optional for PCE N/A for PL
Code that specifies that the diagnosis is either an "ordering
diagnosis or is a "resulting diagnosis or "both for this
encounter.
Format: "O ::=Ordering
"R ::=Resulting
"OR ::=Both Ordering and Resulting "DX/PL",i,"LEXICON TERM")
Optional for PCE Optional for PL
This is a term that is contained in the Clinical Lexicon.
Format: Pointer to the Expressions file (757.01)
"DX/PL",i,"PL IEN") Optional for PCE *Optional for PL
This is the problem IEN that is being acted upon. *This node is
required to edit an existing problem on the Problem List.
Format: Pointer to Problem List file (9000011)
"DX/PL",i,"PL ADD") N/A for PCE *Optional for PL
*This is required to Add a diagnosis/problem to the Problem List.
"1" indicates that the entry should be added to the Problem
List.
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL ACTIVE") N/A for PCE Optional for PL
This documents whether a problem is active or inactive. The
Default is Active if not specified.
Format: Set of Codes.
A::=Active
I::=Inactive
"DX/PL",i,"PL ONSET DATE") N/A for PCE Optional for PL
The date that the problem began.
Format: FileMan Internal Format for date.
"DX/PL",i,"PL RESOLVED DATE") N/A for PCE Optional for PL
The date that the problem was resolved.
Format: FileMan Internal Format for date.
"DX/PL",i,"PL SC") Required for PCE Optional for PL
This problem is related to a service connected condition.
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL CV") Required for PCE Optional for PL
This problem is related to Combat Veteran
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL AO") Required for PCE Optional for PL
This problem is related to Agent Orange exposure.
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL IR") Required for PCE Optional for PL
This problem is related to Ionizing Radiation exposure.
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL SHAD") Required for PCE Optional for PL
This problem is related to Project 112/SHAD
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL EC") Required for PCE Optional for PL
This problem is related to Environmental Contaminant exposure.
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL MST") Required for PCE Optional for PL
This problem is related to Military Sexual Trauma.
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL HNC") Required for PCE Optional for PL
This problem is related to Head and/or Neck Cancer
Format: [ 1 | 0 | null ]
"DX/PL",i,"PL CLV") Required for PCE Optional for PL
This problem is related to Camp Lejeune.
Format: [ 1 | 0 | null ]
"DX/PL",i,"NARRATIVE") *Optional for PCE *Optional for PL
The provider's description of the diagnosis/problem. *If NARRATIVE
is not passed for a diagnosis/problem, the Description from
the ICD Diagnosis file (80) will be used as the default.
Format: Free text (2-245 characters)
"DX/PL",i,"CATEGORY") Optional for PCE N/A for PL
A term that denotes a grouping or category for a set of related
diagnosis/problem.
Format: Free text (2-245 characters)
"DX/PL",i,"ENC PROVIDER") Optional for PCE *Optional for PL
Provider who documented the diagnosis/problem.
*This is required to Add a diagnosis/problem to the Problem List.
Format: Pointer to New Person file (200)
"DX/PL",i,"EVENT D/T") Optional for PCE N/A for PL
Date/Time Diagnosis was documented.
Format: FileMan Internal Format for date/time
"DX/PL",i,"COMMENT") Optional for PCE *Optional for PL
Comment
Format: PCE Free Text (1-245 char)
PL Free Text (3-60 char)
"DX/PL",i,"DELETE") Optional for PCE N/A for PL
This is a delete flag used to denote deletion of the diagnosis
entry.
Format: [ 1 | null ]|\n\n
PROCEDURE: The "PROCEDURE" node may have multiple entries (i). Only
active CPT/HCPCS codes will be accepted. The "PROCEDURE" node documents
the procedure(s), the number of times the procedure was performed, the
diagnosis the procedure is associated with and the narrative that
describes the procedure. It also enables documentation of the provider
who performed the procedure, the date/time the procedure was performed and
any comments that are associated with the procedure. To delete the entire
"PROCEDURE" entry, set the "DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"PROCEDURE",i,"PROCEDURE") Required
Procedure code
Format: Pointer to CPT file (81)
"PROCEDURE",i,"MODIFIERS",MODIFIER)="" Optional
CPT Modifier(s)
Format: external form. Any number of modifiers may be listed.
"PROCEDURE",i,"QTY") Required
Number of times the procedure was performed.
Format: Whole number > 0
"PROCEDURE",i,"DIAGNOSIS") Optional
The first diagnosis that is associated with the identified
procedure and is the primary diagnosis associated with
this procedure.
Format: Pointer to ICD Diagnosis file (80)
"PROCEDURE",i,"DIAGNOSIS 2") Optional
The second diagnosis that is associated with the identified
procedure.
"PROCEDURE",i,"DIAGNOSIS 3") Optional
The third diagnosis that is associated with the identified
procedure.
"PROCEDURE",i,"DIAGNOSIS 4") Optional
The fourth diagnosis that is associated with the identified
procedure.
"PROCEDURE",i,"DIAGNOSIS 5") Optional
The fifth diagnosis that is associated with the identified
procedure.
"PROCEDURE",i,"DIAGNOSIS 6") Optional
The sixth diagnosis that is associated with the identified
procedure.
"PROCEDURE",i,"DIAGNOSIS 7") Optional
The seventh diagnosis that is associated with the identified
procedure.
"PROCEDURE",i,"DIAGNOSIS 8") Optional
The eighth diagnosis that is associated with the identified
procedure.
Format: Pointer to ICD Diagnosis file (80)
"PROCEDURE",i,"NARRATIVE") *Optional
The provider's description of the procedure performed. *If
NARRATIVE is not passed for a procedure, the Short Name from
the CPT file (81) will be used as the default.
Format: Free text (2-245 characters)
"PROCEDURE",i,"CATEGORY") Optional
A term that denotes a grouping or category for a set of related
procedures.
Format: Free text (2-245 characters)
"PROCEDURE",i,"ENC PROVIDER") Optional
Provider who performed the procedure.
Format: Pointer to New Person file (200)
"PROCEDURE",i,"ORD PROVIDER") Optional
Provider who ordered the procedure.
Format: Pointer to New Person file (200)
"PROCEDURE",i,"ORD REFERENCE") Optional
Order reference for the ordered procedure.
Format: Pointer to the Order file (100)
"PROCEDURE",i,"EVENT D/T") Optional
Date/Time procedure was done.
Format: FileMan Internal Format for date/time
"PROCEDURE",i,"DEPARTMENT") Optional
A 3-digit code that defines the service area. Missing Department
Codes will be assigned a Department Code. The Department Code will
be the Stop Code associated (in the HOSPITAL LOCATION file, #44)
with the Hospital Location of the patient visit. If no Department
Code can be established, a 999 will be passed to the PFSS Cache.
Format: Set of Codes.
1::=Poor
2::=Fair
3::=Good
4::=Group--No Assessment
5::=Refused
108::=Laboratory
160::=Pharmacy
419::=Anesthesiology
423::=Prosthetics
180::=Oral Surgery
401::=General Surgery
402::=Cardiac Surgery
403::=Otorhinolaryngology (ENT)
404::=Gynecology
406::=Neurosurgery
407::=Ophthalmology
409::=Orthopedics
410::=Plastic Surgery (inc. H&N)
411::=Podiatry
412::=Proctology
413::=Thoracic Surgery
415::=Peripheral Vascular
457::=Transplantation
105::=General Radiology
109::=Nuclear Medicine
109::=Cardiology Studies (Nuclear Med)
115::=Ultrasound
703::=Mammography
150::=CT Scan
151::=Magnetic Resonance Imaging
152::=Angio-Neuro-Interventional
421::=Vascular Lab
"PROCEDURE",i,"COMMENT") Optional
Comment
Free Text (1-245 characters)
"PROCEDURE",i,"DELETE") Optional
This is a flag that denotes deletion of the Procedure entry.
Format: [ 1 | null ]|\n\n
PATIENT ED: The "PATIENT ED" node may have multiple entries (i). To
delete the entire "PATIENT ED" entry, set the "DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"PATIENT ED",i,"TOPIC") Required
Education Topic that patient received education.
Format: Pointer to Education Topics file (9999999.09)
"PATIENT ED",i,"UNDERSTANDING") Optional
The patients level of understanding of the education.
Format: Set of Codes.
1::=Poor
2::=Fair
3::=Good
4::=Group--No Assessment
5::=Refused
"PATIENT ED",i,"ENC PROVIDER") Optional
Provider who was the educator.
Format: Pointer to New Person file (200)
"PATIENT ED",i,"EVENT D/T") Optional
Date/Time of Event
Format: FileMan Internal Format for date/time
"PATIENT ED",i,"COMMENT") Optional
Comment
Format: Free Text field (1-245 characters)
"PATIENT ED",i,"DELETE") Optional
This is a flag that denotes deletion of the Provider entry.
Format: [ 1 | null ]|
"PATIENT ED",i,"DELETE") Optional
This is a flag that denotes deletion of the Patient Ed entry.
Format: [ 1 | null ]|\n\n
HEALTH FACTOR: The "HEALTH FACTOR" node may have multiple entries (i). To
delete the entire "HEALTH FACTOR" entry, set the "DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"HEALTH FACTOR",i,"HEALTH FACTOR") Required
Health Factor that contributes to a patient's state of health.
Format: Pointer to Health Factors file (9999999.64)
"HEALTH FACTOR",i,"LEVEL/SEVERITY") Optional
Level/Severity of health factor related to the patient's state of
health.
Format: Set of Codes.
M::=Minimal
MO:=Moderate
H:=Heavy/Severe
"HEALTH FACTOR",i,"ENC PROVIDER") Optional
Provider who documented the health factor.
Format: Pointer to New Person file (200)
"HEALTH FACTOR",i,"EVENT D/T") Optional
Date/Time of Event
Format: FileMan Internal Format for date/time
"HEALTH FACTOR",i,"COMMENT") Optional
Comment
Format: Free Text field (1-245 characters)
"HEALTH FACTOR",i,"DELETE") Optional
This is a flag that denotes deletion of the Health Factor entry.
Format: [ 1 | null ]|\n\n
EXAM: The "EXAM" node may have multiple entries (i). To delete the entire
"EXAM" entry, set the "DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"EXAM",i,"EXAM") Required
Exam that was performed.
Format: Pointer to Exam file (9999999.15)
"EXAM",i,"RESULT") Optional
Result of Exam
Format: Set of Codes.
A::=Abnormal
N::=Normal
"EXAM",i,"ENC PROVIDER") Optional
Provider who performed the exam..
Format: Pointer to New Person file (200)
"EXAM",i,"EVENT D/T") Optional
Date/Time of Exam
Format: FileMan Internal Format for date/time
"EXAM",i,"COMMENT") Optional
Comment
Format: Free Text field (1-245 characters)
"EXAM",i,"DELETE") Optional
This is a flag that denotes deletion of the Exam entry.
Format: [ 1 | null ]|\n\n
SKIN TEST: The "SKIN TEST" node may have multiple entries (i). To delete
the entire "SKIN TEST" entry, set the "DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"SKIN TEST",i,"TEST") Required
Skin Test that was performed
Format: Pointer to Skin Test file (9999999.28)
"SKIN TEST",i,"READING") Optional
Numeric measurement of the surface area tested (in millimeters).
Format: Whole number between 0 and 40 inclusive.
"SKIN TEST",i,"RESULT") Optional
Results of the Skin Test
Format: Set of Codes.
P::=Positive
D::=Doubtful
N::=Negative
O::=No Take
"SKIN TEST",i,"D/T READ") Optional
Date/time skin test was read
Format: FileMan Internal Format for date/time
"SKIN TEST",i,"DIAGNOSIS") Optional
The first diagnosis that is associated with the identified
skin test and is the primary diagnosis associated with
this skin test.
Format: Pointer to ICD Diagnosis file (80)
"SKIN TEST",i,"DIAGNOSIS 2") Optional
The second diagnosis that is associated with the identified
skin test.
"SKIN TEST",i,"DIAGNOSIS 3") Optional
The third diagnosis that is associated with the identified
skin test.
"SKIN TEST",i,"DIAGNOSIS 4") Optional
The fourth diagnosis that is associated with the identified
skin test.
"SKIN TEST",i,"DIAGNOSIS 5") Optional
The fifth diagnosis that is associated with the identified
skin test.
"SKIN TEST",i,"DIAGNOSIS 6") Optional
The sixth diagnosis that is associated with the identified
skin test.
"SKIN TEST",i,"DIAGNOSIS 7") Optional
The seventh diagnosis that is associated with the identified
skin test.
"SKIN TEST",i,"DIAGNOSIS 8") Optional
The eighth diagnosis that is associated with the identified
skin test.
Format: Pointer to ICD Diagnosis file (80)
"SKIN TEST",i,"ENC PROVIDER") Optional
Provider who read the skin test.
Format: Pointer to New Person file (200)
"SKIN TEST",i,"EVENT D/T") Optional
Date/Time test was administered.
Format: FileMan Internal Format for date/time
"SKIN TEST",i,"COMMENT") Optional
Comment
Format: Free Text field (1-245 characters)
"SKIN TEST",i,"READER") Optional
The person who read the skin test.
Format: Pointer to New Person file (200)
"SKIN TEST",i,"ORD PROVIDER") Optional
The provider who ordered this skin test.
Format: Pointer to New Person file (200)
"SKIN TEST",i,"D/T PLACEMENT RECORDED") Optional
The date and time of documentation of the placement
of the skin test.
Format: FileMan Internal Format for date/time
"SKIN TEST",i,"ANATOMIC LOC") Optional
The anatomic location of skin test placement.
Format: Pointer to Imm Administration Site (Body)
file (920.3)
"SKIN TEST",i,"D/T READING RECORDED") Optional
The date and time of documentation of the reading
of the skin test.
Format: FileMan Internal Format for date/time
"SKIN TEST",i,"READING COMMENT") Optional
Comment related to the reading of the patient's
skin test.
Format: Free Text field (1-245 characters)
"SKIN TEST",i,"DELETE") Optional
This is a flag that denotes deletion of the Skin Test entry.
Format: [ 1 | null ]|\n\n
IMMUNIZATION: The "IMMUNIZATION" node may have multiple entries (i). To
delete the entire "IMMUNIZATION" entry, set the "DELETE" node to 1.\n
Effective with PX*1*209, the "IMMUNIZATION" node contains modifications
to include additional fields: Event Info Source, Dosage, Route, Admin
Site, Lot #. These new fields are optional, and therefore backward
compatible.\n
SUBSCRIPT DESCRIPTION:\n
"IMMUNIZATION",i,"IMMUN") Required
Immunization that was performed.
Format: Pointer to Immunization file (9999999.14)
"IMMUNIZATION",i,"SERIES") Optional
Series specifies the sequence of the series for the immunization
that was administered.
Format: Set of Codes.
P::=Partially complete
C::=Complete
B::=Booster
1::=Series1 thru 8::=Series8
"IMMUNIZATION",i,"REACTION") Optional
The observed reaction to the immunization.
Format: Set of Codes.
0::=None
1::=Fever
2::=Irritability
3::=Local Reaction or Swelling
4::=Vomiting
5::=Rash or Itching
6::=Lethargy
7::=Convulsions
8::=Arthritis or Arthralgias
9::=Anaphylaxis or Collapse
10::=Respiratory Distress
11::=Other
"IMMUNIZATION",i,"CONTRAINDICATED") Optional
This field may be used to indicate that this immunization should
not be administered again. "1" indicates that the immunization
should not be given to the patient in the future.
Format: [ 1 | 0 | null ]
"IMMUNIZATION",i,"DIAGNOSIS") Optional
The first diagnosis that is associated with the identified
immunization and is the primary diagnosis associated with
this immunization.
Format: Pointer to ICD Diagnosis file (80)
"IMMUNIZATION",i,"DIAGNOSIS 2") Optional
The second diagnosis that is associated with the identified
immunization.
"IMMUNIZATION",i,"DIAGNOSIS 3") Optional
The third diagnosis that is associated with the identified
immunization.
"IMMUNIZATION",i,"DIAGNOSIS 4") Optional
The fourth diagnosis that is associated with the identified
immunization.
"IMMUNIZATION",i,"DIAGNOSIS 5") Optional
The fifth diagnosis that is associated with the identified
immunization.
"IMMUNIZATION",i,"DIAGNOSIS 6") Optional
The sixth diagnosis that is associated with the identified
immunization.
"IMMUNIZATION",i,"DIAGNOSIS 7") Optional
The seventh diagnosis that is associated with the identified
immunization.
"IMMUNIZATION",i,"DIAGNOSIS 8") Optional
The eighth diagnosis that is associated with the identified
immunization.
Format: Pointer to ICD Diagnosis file (80)
"IMMUNIZATION",i,"ENC PROVIDER") Optional
Provider who performed the immunization.
Format: Pointer to New Person file (200)
"IMMUNIZATION",i,"EVENT D/T") Optional
Date/Time immunization was administered.
Format: FileMan Internal Format for date/time
"IMMUNIZATION",i,"COMMENT") Optional
Comment
Format: Free Text (1-245 characters)
"IMMUNIZATION",i,"LOT NUM") Optional
The lot number of the Immunization entered for this event.
Format: Pointer to Immunization Lot file (9999999.41)
"IMMUNIZATION",i,"INFO SOURCE") Optional
The source of the information obtained for this immunization
event.
Format: Pointer to Immunization Info Source file (920.1)
"IMMUNIZATION",i,"ADMIN ROUTE") Optional
The method this vaccine was administered.
Format: Pointer to Imm Administration Route file (920.2)
"IMMUNIZATION",i,"ANATOMIC LOC") Optional
The area of the patient's body through which the vaccine was
administered.
Format: Pointer to Imm Administration Site (Body) file (920.3)
"IMMUNIZATION",i,"DOSE") Optional
The amount of vaccine product administered for this
immunization.
Format: Numeric (between 0 and 999, 2 fractional digits)
"IMMUNIZATION",i,"DOSE UNITS") Optional
The units that reflect the actual quantity of the
vaccine product administered.
Format: Pointer to the UCUM Codes file (#757.5)
"IMMUNIZATION",i,"VIS",SEQ #,0)=VISIEN^DATE Optional
The Vaccine Information Statement (VIS) offered to or
given to the patient before administration of the
immunization, and the date it was offered or given.
Format: "VISIEN" is a pointer to the Vaccine Information
Statement file (#920). "DATE" is a date (without time) in
FileManager internal format.
NOTE: If the caller is updating a previously recorded
immunization:
1) If the caller passes in VIS data in the "VIS"
subscript, the system will purge the previously filed
VIS data before filing the updates.
2) If the caller does not pass in any VIS data, the
previously filed VIS data persists.
3) If the caller wants to delete the previously filed VIS
without replacing it with anything else, that is done
explicitly by setting the "VIS" subscript as follows:
"IMMUNIZATION",i,"VIS")="@"
"IMMUNIZATION",i,"REMARKS",SEQ #,0) Optional
Comments related to the immunization encounter with
the patient.
Format: Free-text in the format of a FileManager
word-processing field.
NOTE: If the caller is updating a previously recorded
immunization:
1) If the caller passes in remarks in the "REMARKS"
subscript, the system will purge the previously filed
remarks before filing the updates.
2) If the caller does not pass in any remarks, the
previously filed remarks persist.
3) If the caller wants to delete the previously filed
remarks without replacing it with anything else,
that is done explicitly by setting the "REMARKS"
subscript as follows: "IMMUNIZATION",i,"REMARKS")="@"
"IMMUNIZATION",i,"ORD PROVIDER") Optional
The provider who ordered the immunization.
Format: Pointer to New Person file (#200).
"IMMUNIZATION",i,"WARNING ACK") Optional
This field indicates acknowledgement of a
contraindication/refusal event warning for this
immunization with the decision to proceed with
administration.
Format: [ 1 | 0 | null ]
"IMMUNIZATION",i,"OVERRIDE REASON" Optional
This is the reason for overriding the warning of
existing contraindication and/or refusal reasons.
Format: Free Text (3-245 characters).
"IMMUNIZATION",i,"DELETE") Optional
This is a flag that denotes deletion of the Immunization entry.
Format: [ 1 | null ]|\n\n
TREATMENT: The "TREATMENT" node may have multiple entries (i). To delete
the entire "TREATMENT" entry, set the "DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"TREATMENT",i,"TREATMENT") Required
Name of Treatment
Format: Pointer to Treatment file (9999999.17)
"TREATMENT",i,"QTY") Optional
Number of times the treatment was performed.
Format: Whole number > 0
"TREATMENT",i,"NARRATIVE") *Optional
The provider's description of the treatment performed. *If
NARRATIVE is not passed for a treatment, the Treatment Name
from the Treatment file (9999999.17) will be used as the
default.
Format: Free text (2-245 characters)
"TREATMENT",i,"CATEGORY") Optional
A term that denotes a grouping or category for a set of related
treatments.
Format: Free text (2-245 characters)
"TREATMENT",i,"ENC PROVIDER") Optional
Provider who performed the treatment.
Format: Pointer to New Person file (200)
"TREATMENT",i,"EVENT D/T") Optional
Date/Time treatment was done.
Format: FileMan Internal Format for date/time
"TREATMENT",i,"COMMENT") Optional
Comment
Format: Free Text (1-245 characters)
"TREATMENT",i,"DELETE") Optional
This is a flag that denotes deletion of the Treatment entry.
Format: [ 1 | null ]|\n\n
IMM CONTRA/REFUSAL: The "IMM CONTRA/REFUSAL" node may have multiple
entries (i). To delete the entire "IMM CONTRA/REFUSAL" entry, set the
"DELETE" node to 1.\n
SUBSCRIPT DESCRIPTION:\n
"IMM CONTRA/REFUSAL",i,"CONTRA/REFUSAL") Required
The Contraindication or Refusal Reason.
Format: Variable Pointer to: IMM Contraindication
Reasons file (920.4) or IMM Refusal Reasons file (920.5).
"IMM CONTRA/REFUSAL",i,"IMMUN") Required
The immunization contraindicated or refused.
Format: Pointer to Immunization file (9999999.14)
"IMM CONTRA/REFUSAL",i,"WARN UNTIL DATE") Optional
The date until which a warning should be given for this
contraindication/refusal.
Format: FileManager Internal Format for date.
"IMM CONTRA/REFUSAL",i,"EVENT D/T") Optional
The date/time of this contraindication/refusal event.
Format: FileManager Internal Format for date/time.
"IMM CONTRA/REFUSAL",i,"ENC PROVIDER") Optional
This is the provider who recorded the
contraindication/refusal event.
Format: Pointer to New Person file (#200).
"IMM CONTRA/REFUSAL",i,"COMMENT") Optional
Comment.
Format: Free Text (1-245 characters).
"IMM CONTRA/REFUSAL",i,"DELETE") Optional
This is a flag that denotes deletion of the IMM
Contra/Refusal entry.
Format: [ 1 | null ]\n\n
EXAMPLE OF DATA PASSED TO $$DATA2PCE^PXAPI\n
Provided below is an example of data passed to $$DATA2PCE^PXAPI where
Laboratory is the ancillary package reporting the data.\n
$$DATA2PCE^PXAPI("LRPXAPI",$J,182,"LAB DATA")\n
This is an example where Laboratory passes two laboratory tests (Glucose
and CPK) which were resulted on 4/20/96 at 9:30 a.m. This occasion of
service is defined as an Ancillary Package Daily Data (X).\n
^TMP("LRPXAPI",543173595,"ENCOUNTER",1,"CREDIT STOP") = 59
^TMP("LRPXAPI",543173595,"ENCOUNTER",1,"ENC D/T") = 2960420.093
^TMP("LRPXAPI",543173595,"ENCOUNTER",1,"HOS LOC") = 59
^TMP("LRPXAPI",543173595,"ENCOUNTER",1,"PATIENT") = 1030
^TMP("LRPXAPI",543173595,"ENCOUNTER",1,"SERVICE CATEGORY") = X
^TMP("LRPXAPI",543173595,"PROCEDURE",1,"ENC PROVIDER") = 58
^TMP("LRPXAPI",543173595,"PROCEDURE",1,"EVENT D/T") = 2960420.093
^TMP("LRPXAPI",543173595,"PROCEDURE",1,"PROCEDURE") = 82950
^TMP("LRPXAPI",543173595,"PROCEDURE",1,"QTY") = 1
^TMP("LRPXAPI",543173595,"PROCEDURE",2,"ENC PROVIDER") = 58
^TMP("LRPXAPI",543173595,"PROCEDURE",2,"EVENT D/T") = 2960420.093
^TMP("LRPXAPI",543173595,"PROCEDURE",2,"PROCEDURE") = 82552
^TMP("LRPXAPI",543173595,"PROCEDURE",2,"QTY") = 1
^TMP("LRPXAPI",543173595,"PROVIDER",1,"NAME") = 58
^TMP("LRPXAPI",543173595,"PROVIDER",1,"PRIMARY") = 1
^TMP("LRPXAPI",543173595,"PROCEDURE",1,"PROCEDURE") =
^TMP("LRPXAPI",543173595,"PROCEDURE",1,"MODIFIERS",57) = ""
^TMP("LRPXAPI",543173595,"PROCEDURE",1,"QUANTITY") = 1", "", "PXAPI", "2017/01/10"], ["1890", "DBIA1889-B", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
$$DELVFILE^PXAPI(WHICH,VISIT,PKG,SOURCE,ASK,ECHO,USER)\n
This function may be used to delete data from the Visit file (9000010) and V
files, including V CPT (9000010.18), V EXAM (9000010.13), V HEALTH FACTORS
(9000010.11), V PATIENT ED (9000010.16), V POV (9000010.07), V PROVIDER
(9000010.06), V SKIN TEST (9000010.12) and V TREATMENT (9000010.15).\n
Parameter Description:\n
1. WHICH: (required) An ^ delimited string where two or three
characters separated by an ^ designate the V file from
which data should be deleted, e.g., "PRV^POV^CPT^HF".
"ALL" may be used to delete data from all V files. VISIT
is the string which will delete the administrative data
and STOP is the string which will delete the additional
stop codes. An example of a function call which will
delete data typically deleted through Delete Check Out is:
$$DELVFILE^PXAPI("ALL",VISIT,,,1,1)\n
Possible individual strings which may be included in WHICH
include:\n
ALL To delete all items
CPT To delete procedures
HF To delete health factors
IMM To delete immunizations
PEP To delete patient education
POV To delete problem of visit (diagnoses)
PRV To delete provider
SK To delete skin tests
STOP To delete additional stop codes. The primary
clinic stop will not be deleted.
TRT To delete treatments
VISIT To delete Service Connected, Classification
question data, check out date.
XAM To delete examinations\n
2. VISIT: (required) A number which is a pointer to the VISIT file
(9000010). This is the visit for which related data will
be deleted.\n
3. PKG: (optional) The internal entry number of the package in the
Package file (9.4) or the namespace for the package. If
passed, only items created by this package will be
deleted.\n
4. SOURCE: (optional) A string denoting the source of the data. This
is an entry in the Data Source file (839.7). If passed,
only items created by this source will be deleted.\n
5. ASK: (optional) If ASK is passed and it does not equal 0 or
"", then PCE will prompt the user to verify that they
want to delete the data before proceeding with the
deletions. PCE recommends setting ASK to 1 to indicate
that the user should be asked to confirm that the data
should be deleted.\n
6. ECHO: (optional) If ECHO is passed and it does not equal 0 or
"", then PCE will display to the user what is being
deleted. PCE recommends setting ECHO to 1 to indicate
that the data deletions should be displayed to the user,
e.g. Deleting Procedures....
Deleting Providers....
Deleting Diagnoses....
The message will be displayed only if data has been
deleted.\n
7. USER: (optional) Set USER to the user's DUZ to restrict deletion
of data to those entries created by the user. If USER is
not passed, is equal to 0 or "", PCE will not apply
deletion restriction based on the user.\n
Returned Value:
1 If no errors occurred and deletion processed completely.
0 If errors occurred but deletion processed completely as
possible.
-1 User indicated that the data should not be deleted, or User
up-arrowed out, or errors occurred. In any case, nothing
was deleted.
-2 If unable to identify a valid VISIT.
-3 If API was called incorrectly.
-4 If dependent entry count is still greater than zero.", "", "PXAPI", ""], ["1891", "DBIA1889-C", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "\n
$$INTV^PXAPI(WHAT,PKG,SOURCE,.VISIT,.HL,.DFN,APPT,LIMITDT,ALLHLOC)\n
This API should be used by subscribing packages to prompt for Visit and
related V-file data. The parameters passed by the subscribing packages
determine which prompts will be displayed. If VISIT, HL or DFN are passed by
reference (.), a value will be returned for those variables.\n
Parameter Description:\n
1. WHAT: Required parameter that defines the series of prompts
that will be displayed.\n
ADDEDIT When not an appointment.\n
INTV Includes all prompts for the checkout interview:
1. Patient (if not defined)
2. Hospital Location (if not defined)
3. Appointment/Eligibility (Call to Scheduling API if the
encounter is not associated with an appointment and is a
new encounter.)
4. Check Out Date/Time
5. Service Connected/Classification Questions
Service Connected
Agent Orange Exposure
Ionizing Radiation Exposure
Environmental Contaminants Exposure
Military Sexual Trauma
Head and/or Neck Cancer
Combat Vet
Project 112/SHAD Exposure
Camp Lejeune
6. Provider (multiple)
Provider
Primary/Secondary Designation
7. Procedures (multiple)
CPT code
Modifiers (multiple)
Quantity
8. Diagnosis (multiple)
ICD9 code
Primary/Secondary Designation
9. Stop Code (multiple) Discontinued after 10/1/96
Stop code\n
PRV Includes all prompts for provider information (multiple):
1. Provider
2. Primary/Secondary Designation\n
POV Includes all prompts for diagnosis information (multiple):
1. ICD9 code
2. Primary/Secondary Designation\n
CPT Includes prompts for procedure information and allows
association of data with a provider (multiple):
1. Provider
2. Primary/Secondary Provider Designation
3. CPT code
4. CPT Modifiers (multiple)
5. Quantity\n
SCC Includes prompts for service connected conditions and
classification questions:
1. Service Connected
2. Combat Vet
3. Agent Orange Exposure
4. Ionizing Radiation Exposure
5. Environmental Contaminants Exposure
6. Project 112/SHAD Exposure
7. Military Sexual Trauma
8. Head and/or Neck Cancer
9. Camp Lejeune\n
CODT Includes prompt for check-out date/time:
1. Date/time Checked Out\n
ADQ Includes all administrative prompts related to the
interview:
1. Patient (if not defined)\n
3. Appointment/Eligibility (API called if encounter is not
associated with an appointment)
4. Check Out Date/Time
5. Service Connected
6. Combat Vet
7. Agent Orange Exposure
8. Ionizing Radiation Exposure
9. Environmental Contaminants Exposure
10. Project 112/SHAD Exposure
11. Military Sexual Trauma
12. Head and/or Neck Cancer
13. Camp Lejeune\n
STP Includes prompt for a stop code (multiple):
1. Stop Code (only for encounters before 10/1/96)\n
2. PKG: Required parameter that is the designated namespace for
the package as defined in the Package file or is a
pointer to the Package file (9.4).\n
3. SOURCE: Required parameter that is used for auditing purposes and
defines the data collection source. This parameter could
be the calling routine or a description of the caller,
e.g., PIMS CHECKOUT, PXCE DATA ENTRY, PANDAS, TELEFORM.
It will be added to the PCE Data Source file (839.7).\n
4. VISIT: Required parameter except when "INTV" and "ADQ" are
called. This parameter defines the encounter and is a
pointer to the Visit file (9000010).\n
5. HL: Optional parameter (passed if known) that defines the
hospital location for the encounter and points to the
Hospital Location file (44). If the subscribing package
knows the hospital location, it should be passed to avoid
unnecessary prompting.\n
6. DFN: Required parameter if there is no known visit (VISIT) and
there is an appointment (APPT); otherwise, it is an
optional parameter (passed if known) that defines the
patient and points to the Patient/IHS file (9000001). If
the subscribing package knows the patient, it should be
passed to avoid unnecessary prompting.\n
7. APPT: Optional parameter that points to the Appointment subfile
(2.98) of the Patient file (2). This parameter defines
the appointment date/time.\n
8. LIMITDT: Optional parameter that restricts creation of new visits
to the date passed or after the date passed. The format
of the parameter is internal fileman date.\n
9. ALLHLOC: Optional parameter if is not passed, 0, or null then only
clinics can be entered for hospital locations otherwise
any non disposition hospital location can be entered.\n
Returned Variables:\n
If VISIT, HL or DFN are passed by reference (.), a value will be returned for
those variables.\n
1 When the call to the API is successful; no errors were
encountered.
0 When user up-arrows out. Minimally, a visit exists. Other
processing may have occurred.
-1 When user up-arrows out or errors out and nothing has been
processed.
-2 When no visit was created and no subsequent processing
occurred.
-3 When the API was incorrectly called.\n", "", "PXAPI", "2017/01/10"], ["1892", "DBIA1889-D", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "\n
$$ENCEDIT^PXAPI(WHAT,PKG,SOURCE,DFN,BEGDT,ENDT,HLOC,SCREEN,APPT,PRMPT)\n
This is an interactive API that may be called to display a list of encounters
for selection. It allows adding a new encounter, or selecting an encounter to
edit or delete. If the user indicates that an encounter should be added, an
entry will be created in the Visit file (9000010), and the user will be
prompted based on the WHAT parameter. If an encounter is selected to edit,
the user will be prompted based on the WHAT parameter. If an encounter is
selected for deletion, all data associated with the encounter will be deleted,
and the entry in the Visit file will be assessed for deletion and deleted if
possible.\n
Parameter Description:\n
1. WHAT: (required) This parameter is string text that identifies
the set of prompts.\n
INTV Includes all prompts for the checkout interview:\n
1. Patient (if not defined)
2. Hospital Location (if not defined)
Appointment/Eligibility (Call to Scheduling API if the
encounter is not associated with an appointment and is a
new encounter.)
3. Check Out Date/Time
4. Service Connected/Classification Questions
Service Connected
Agent Orange Exposure
Ionizing Radiation Exposure
Environmental Contaminants Exposure
Military Sexual Trauma
Head and/or Neck Cancer
Combat Vet
Project 112/SHAD Exposure
Camp Lejeune
5. Provider (multiple)
Provider
Primary/Secondary Designation
6. Procedures (multiple)
CPT code
Modifiers (multiple)
Quantity
7. Diagnosis (multiple)
ICD9 code
Primary/Secondary Designation
8. Stop Code (multiple) Discontinued after 10/1/96
Stop code\n
ADQ Includes all administrative prompts related to the
interview:\n
1. Patient (if not defined)
2. Hospital Location (if not defined)
3. Appointment/Eligibility (API called if encounter is not
associated with an appointment)
4. Check Out Date/Time
5. Service Connected
6. Combat Vet
7. Agent Orange Exposure
8. Ionizing Radiation Exposure
9. Environmental Contaminants Exposure
10. Project 112/SHAD Exposure
11. Military Sexual Trauma
12. Head and/or Neck Cancer
13. Camp Lejeune\n
2. PKG: (required) This parameter is the assigned package Name
space as designated in the Package file (9.4) or is a
pointer to the Package file (9.4).\n
3. SOURCE: (required) This parameter is used for auditing purposes
and defines the data collection source. This parameter
could be the calling routine or a description of the
caller, e.g., PIMS CHECKOUT, PXCE DATA ENTRY, PANDAS,
TELEFORM. It will be added to the PCE Data Source file
(839.7).\n
4. DFN: (required) This parameter represents the patient and is
the internal entry number of the Patient's entry in the
Patient/IHS file (9000001) which is dinumed to the Patient
file (2).\n
5. BEGDT: (optional) This is the beginning date, in an INTERNAL
FORMAT, of the date range. If no date range is passed,
all entries in the Visit file (9000010) for the identified
patient will be returned.\n
6. ENDT: (optional) This is the ending date, in an INTERNAL FORMAT,
of the date range. If no date range is passed, all
entries in the Visit file (9000010) for the identified
patient will be returned.\n
7. HLOC: (optional) This is the Hospital Location. It is a pointer
to the Hospital Location file (44). This restricts
display of encounters to those associated with this
hospital location. If HLOC is not passed, all encounters
for the identified patient, irrespective of the hospital
location, will be returned.\n
8. SCREEN: (optional) This is a screen based on the Primary field
(15003) and Service Category field (.07) of the Visit file
(9000010). It is a set of codes that represents an
encounter type, e.g., primary, occasion of service, stop
code. More than one code may be used, e.g., PO. If
SCREEN is not passed, all encounters, except those that
represent historical encounters, will be included in the
list. If the screen includes E, only historical
encounters will be displayed. If the screen does not
include E, only non-historical encounters will be
displayed.\n
A Occasions of service that are passed to PCE by ancillary
packages using DATA2PCE^PXAPI.
P Primary visits are encounters created for appointments and
standalone's either through manual data entry or via
DATA2PCE^PXAPI.
O Occasions of Service are encounters that are created when
data for an ancillary package such as Radiology or
Laboratory is manually entered through Scheduling or PCE.
Assignment of this code is determined based on a managed set
of stop codes provided by ancillary packages.
S Stop Codes are child encounters that are created to store
additional stop codes for a parent encounter. This will be
discontinued after 10/1/96.
E Historical Encounters are encounters that document clinical
activities. They are not associated with an appointment and
are not used for billing or workload purposes. Use "XE"
to display all historical encounters.
X All encounters, excluding historical encounters. "X" is
the default when no SCREEN is defined.\n
9. APPT: (optional) This parameter determines the contents of the
encounter list--whether the encounter include appointments
and standalones, just appointments or just standalones. If
APPT is not passed, no appointment/encounter relationship
will be assessed.\n
1 Display only encounters related to an appointment.
0 Don't screen on encounter/appointment relationship.
-1 Display only encounters not related to an appointment
(standalones).\n
10. PRMPT:(optional) This determines the prompt used by the API. If
PRMPT is not passed or null, only selection of an item
from the list will be enabled.\n
A Includes ADD in the prompt.
D Includes DELETE in the prompt.\n
Returned Value:\n
>0 Internal entry number of the selected encounter, IEN in
the Visit file (9000010).
D^Visit IEN User selected an encounter to DELETE.
-1 No visit selected, user up-arrowed out, nothing done.
-2^Text Error encountered. Text string documents error.
-3^Text Deletion Errors. If deletion occurred, it was
incomplete.\n
======================================================================\n
$$LOPENCED^PXAPI(WHAT,PKG,SOURCE,DFN,BEGDT,ENDT,HLOC,SCREEN,APPT,PRMPT)\n
This is an interactive API that may be called to display a list of encounters
for selection. It allows adding a new encounter, or selecting an encounter to
edit or delete. If the user indicates that an encounter should be added, an
entry will be created in the Visit file (9000010), and the user will be
prompted based on the WHAT parameter. If an encounter is selected to edit,
the user will be prompted based on the WHAT parameter. If an encounter is
selected for deletion, all data associated with the encounter will be deleted,
and the entry in the Visit file will be assessed for deletion and deleted if
possible.\n
This API should be used to allow continuous looping through encounter edit
until the user exits the functionality. This API loops calling ENCEDIT^PXAPI
to collect encounter data repeatedly.\n
Parameter Description:\n
1. WHAT: (required) This parameter is string text that identifies
the set of prompts.\n
INTV Includes all prompts for the checkout interview:\n
1. Patient (if not defined)
2. Hospital Location (if not defined)
Appointment/Eligibility (Call to Scheduling API if the
encounter is not associated with an appointment and is a
new encounter.)
3. Check Out Date/Time
4. Service Connected/Classification Questions
Service Connected
Agent Orange Exposure
Ionizing Radiation Exposure
Environmental Contaminants Exposure
Military Sexual Trauma
Head and/or Neck Cancer
Combat Vet
Project 112/SHAD Exposure
Camp Lejeune
5. Provider (multiple)
Provider
Primary/Secondary Designation
6. Procedures (multiple)
CPT code
Modifiers (multiple)
Quantity
7. Diagnosis (multiple)
ICD9 code
Primary/Secondary Designation
8. Stop Code (multiple) Discontinued after 10/1/96
Stop code\n
ADQ Includes all administrative prompts related to the
interview:\n
1. Patient (if not defined)
2. Hospital Location (if not defined)
3. Appointment/Eligibility (API called if encounter is not
associated with an appointment)
4. Check Out Date/Time
5. Service Connected
6. Combat Vet
7. Agent Orange Exposure
8. Ionizing Radiation Exposure
9. Environmental Contaminants Exposure
10. Project 112/SHAD Exposure
11. Military Sexual Trauma
12. Head and/or Neck Cancer
13. Camp Lejeune\n
2. PKG: (required) This parameter is the assigned package
Namesapce as designated in the Package file (9.4) or is a
pointer to the Package file (9.4).\n
3. SOURCE: (required) This parameter is used for auditing purposes
and defines the data collection source. This parameter
could be the calling routine or a description of the
caller, e.g., PIMS CHECKOUT, PXCE DATA ENTRY, PANDAS,
TELEFORM. It will be added to the PCE Data Source file
(839.7).\n
4. DFN: (required) This parameter represents the patient and is
the internal entry number of the Patient's entry in the
Patient/IHS file (9000001) which is dinumed to the Patient
file (2).\n
5. BEGDT: (optional) This is the beginning date, in an INTERNAL
FORMAT, of the date range. If no date range is passed,
all entries in the Visit file (9000010) for the identified
patient will be returned.\n
6. ENDT: (optional) This is the ending date, in an INTERNAL
FORMAT, of the date range. If no date range is passed,
all entries in the Visit file (9000010) for the identified
patient will be returned.\n
7. HLOC: (optional) This is the Hospital Location. It is a
pointer to the Hospital Location file (44). This
restricts display of encounters to those associated with
this hospital location. If HLOC is not passed, all
encounters for the identified patient, irrespective of the
hospital location, will be returned.\n
8. SCREEN: (optional) This is a screen based on the Primary field
(15003) and Service Category field (.07) of the Visit file
(9000010). It is a set of codes that represents an
encounter type, e.g., primary, occasion of service, stop
code. More than one code may be used, e.g., PO. If
SCREEN is not passed, all encounters, except those that
represent historical encounters, will be included in the
list. If the screen includes E, only historical
encounters will be displayed. If the screen does not
include E, only non-historical encounters will be
displayed.\n
A Occasions of service that are passed to PCE by ancillary
packages using DATA2PCE^PXAPI.
P Primary visits are encounters created for appointments and
standalone's either through manual data entry or via
DATA2PCE^PXAPI.
O Occasions of Service are encounters that are created when
data for an ancillary package such as Radiology or
Laboratory is manually entered through Scheduling or PCE.
Assignment of this code is determined based on a managed set
of stop codes provided by ancillary packages.
S Stop Codes are child encounters that are created to store
additional stop codes for a parent encounter. This will be
discontinued after 10/1/96.
E Historical Encounters are encounters that document clinical
activities. They are are not associated with an appointment
and are not used for billing or workload purposes. Use
"XE" to display all historical encounters.
X All encounters, excluding historical encounters. "X" is
the default when no SCREEN is defined.\n
9. APPT: (optional) This parameter determines the contents of the
encounter list--whether the encounter include appointments
and standalones, just appointments or just standalones. If
APPT is not passed, no appointment/encounter relationship
will be assessed.\n
1 Display only encounters related to an appointment.
0 Don't screen on encounter/appointment relationship.
-1 Display only encounters not related to an appointment
(standalones).\n
10. PRMPT: (optional) This determines the prompt used by the API.
If PRMPT is not passed or null, only selection of an item
from the list will be enabled.\n
A Includes ADD in the prompt.
D Includes DELETE in the prompt.\n
Returned Value:\n
>0 Internal entry number of the selected encounter, IEN in
the Visit file (9000010).
D^Visit IEN User selected an encounter to DELETE.
-1 No visit selected, user up-arrowed out, nothing done.
-2^Text Error encountered. Text string documents error.
-3^Text Deletion Errors. If deletion occurred, it was
incomplete.", "", "PXAPI", ""], ["1893", "DBIA1889-E", "Routine", "PCE PATIENT CARE ENCOUNTER", "2004/03/08", "APPROVED", "Active", "Controlled Subscription", "", "\n
$$VISITLST^PXAPI(DFN,BEGINDT,ENDDT,HLOC,SCREEN,APPT,PRMPT)\n
Use this API to display a list of encounters. This is an interactive API that
allows the user to enter "A" to ADD a new encounter or to select an encounter
to edit or delete. If no date range is passed, all entries in the Visit file
(9000010 ) for the identified patient will be included in the list. If the
HLOC is not passed, all entries in the Visit file (9000010) for the identified
patient will be included in the list. If SCREEN is not passed, all
encounters, except those that represent historical encounters, will be
included in the list. If APPT is not passed, no appointment/encounter
relationship will be assessed. If PRMPT is not passed or is null, only
selection of an item from the list will be enabled.\n
Parameter Description:\n
1. DFN: (required) This number represents the patient and is
the internal entry number of the Patient's entry in the
Patient/IHS file (9000001) which is dinumed to the
Patient file (2).\n
2. BEGINDT: (optional) This is the beginning date, in an INTERNAL
FORMAT, of the date range. If no date range is passed,
all entries in the Visit file (9000010 ) for the
identified patient will be included in the list.\n
3. ENDDT: (optional) This is the ending date, in an INTERNAL
FORMAT, of the date range. If no date range is passed,
all entries in the Visit file (9000010 ) for the
identified patient will be included in the list.\n
4. HLOC: (optional) This is the Hospital Location. It is a
pointer to the Hospital Location file (44). This
restricts display of encounters to those associated
with this hospital location. If the HLOC is not passed,
all entries in the Visit file (9000010) for the
identified patient will be included in the list.\n
5. SCREEN: (optional) This is a screen based on the Primary field
(15003) and Service Category field (.07) of the Visit
file (9000010). It is a set of codes that represents
an encounter type, e.g., primary, occasion of service,
stop code. More than one code may be used, e.g., PO.
If SCREEN is not passed, all encounters, except those
that represent historical encounters, will be included
in the list. If the screen includes E, only historical
encounters will be displayed. If the screen does not
include E, only non-historical encounters will be
displayed.\n
A Occasions of service that are passed to PCE by ancillary
packages using DATA2PCE^PXAPI.
P Primary visits are encounters created for appointments and
standalone's either through manual data entry or via
DATA2PCE^PXAPI.
O Occasions of Service are encounters that are created when
data for an ancillary package such as Radiology or
Laboratory is manually entered through Scheduling or PCE.
Assignment of this code is determined based on a managed set
of stop codes provided by ancillary packages.
S Stop Codes are child encounters that are created to store
additional stop codes for a parent encounter. This will be
discontinued after 10/1/96.
E Historical Encounters are encounters that document clinical
activities. They are not associated with an appointment and
are not used for billing or workload purposes. Use "XE"
to display all historical encounters. This screen must be
used in combination with one of the other codes.
X All encounters, excluding historical encounters. "X" is
the default when no SCREEN is defined.\n
6. APPT: (optional) This determines the contents of the
encounter list--whether the encounters include
appointments and standalones, just appointments or just
standalones. If APPT is not passed, no
appointment/encounter relationship will be assessed.\n
1 Display only encounters related to an appointment.
0 Don't screen on encounter/appointment relationship.
-1 Display only encounters not related to an appointment
(standalones).\n
7. PRMPT: (optional) This determines the prompt used by the API.
If PRMPT is not passed or null, only selection of an
item from the list will be enabled.\n
A Includes ADD in the prompt.
D Includes DELETE in the prompt.\n
Returned Value:\n
>0 Internal entry number of the selected encounter, IEN in
the Visit file (9000010)
A User indicated to ADD an encounter.
D^IEN User selected an encounter to DELETE.
-1 No visit selected
-2^Text Error encountered. Text documents error.", "", "PXAPI", ""], ["1894", "DBIA1889-F", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
ENCEVENT^PXKENC(VISITIEN,DONTKILL)\n
This API was developed to extract all encounter data for a single encounter.
The data represents elements that are stored in the Visit file (9000010) and
other PCE files.\n
Parameter Description:\n
1. VISITIEN (required) This is a pointer to the Visit file
(9000010).\n
2. DONTKILL (optional) This determines whether or not the ^TMP
array will be killed. Enter 0 or "" (null) to kill
the array, and 1 to retain the array.\n
Returned:\n
The data is stored in a ^TMP global array with subscripts denoting the
category of returned data. The data returned in the ^TMP global represents
data from one encounter. The structure of the returned ^TMP global is:\n
^TMP("PXKENC",$J,VISIT,V FILE STRING,V FILE RECORD,DD SUBSCRIPT)
=DATA\n
Where:\n
Global Root Temporary global file root: ^TMP
Subscript 1 String notation representing Package: "PXKENC"
Subscript 2 Job Number: $J
Subscript 3 Internal Entry Number of the Visit (IEN).
Subscript 4 String representing the Visit or V file data category:
"CPT" = V CPT (procedure) #9000010.18
"HF" = V Health Factors #9000010.23
"ICR" = V Imm Contra/Refusal #9000010.707
Events
"IMM" = V Immunization #9000010.11
"PED" = V Patient Ed #9000010.16
"POV" = V POV (diagnosis) #9000010.07
"PRV" = V Provider #9000010.06
"SK" = V Skin Test #9000010.12
"TRT" = V Treatment #9000010.15
"VST" = Visit file #9000010
"XAM" = V Exam #9000010.13
"CSTP" = Visit file #9000010
This subscript contains child visits
used to store additional Stop Codes.\n
Subscript 5 Internal entry number of the entry in the file
represented in subscript #4\n
Subscript 6 Subscript or DD node on which the data is stored.
Every DD node is published whether or not there is any
data for that node. e.g. 0, 12, and 811\n
Data:\n
The DATA that exists to the right of the global node is a reflection of data
as it appears in the global node of the IEN of the file (noted in subscript
#5) and the NODE of that IEN (described in subscript #6).\n
Data Capture of Example output:\n
Included below is a capture of the ^TMP("PXKENC" global.\n
^TMP("PXKENC",549479964,78,"CPT",135,0) = 34510^1030^78^176^^^^^^^^^^^^1
^TMP("PXKENC",549479964,78,"CPT",135,1,0) = ^^1^1
^TMP("PXKENC",549479964,78,"CPT",135,1,1,0) = 16
^TMP("PXKENC",549479964,78,"CPT",135,12) = ^^^108
^TMP("PXKENC",549479964,78,"CPT",135,802) =
^TMP("PXKENC",549479964,78,"CPT",135,811) =
^TMP("PXKENC",549479964,78,"POV",96,0) = 9054^1030^78^177^^^^^^^^S
^TMP("PXKENC",549479964,78,"POV",96,12) = ^^^108
^TMP("PXKENC",549479964,78,"POV",96,800) = 0
^TMP("PXKENC",549479964,78,"POV",96,802) = 168
^TMP("PXKENC",549479964,78,"POV",96,811) =
^TMP("PXKENC",549479964,78,"POV",104,0) = 2569^1030^78^178^^^^^^^^P
^TMP("PXKENC",549479964,78,"POV",104,12) =
^TMP("PXKENC",549479964,78,"POV",104,800) =
^TMP("PXKENC",549479964,78,"POV",104,802) =
^TMP("PXKENC",549479964,78,"POV",104,811) = this is a comment
^TMP("PXKENC",549479964,78,"PRV",94,0) = 58^1030^78^S^A
^TMP("PXKENC",549479964,78,"PRV",94,12) =
^TMP("PXKENC",549479964,78,"PRV",94,811) =
^TMP("PXKENC",549479964,78,"PRV",114,0) = 108^1030^78^S
^TMP("PXKENC",549479964,78,"PRV",114,12) =
^TMP("PXKENC",549479964,78,"PRV",114,811) =
^TMP("PXKENC",549479964,78,"SK",3,0) = 1^1030^78^D^3^2960328.182336
^TMP("PXKENC",549479964,78,"SK",3,12) = ^58^^108
^TMP("PXKENC",549479964,78,"SK",3,811) =
^TMP("PXKENC",549479964,78,"TRT",2,0) = 162^1030^78^3^^175
^TMP("PXKENC",549479964,78,"TRT",2,12) = ^108^^58
^TMP("PXKENC",549479964,78,"TRT",2,802) =
^TMP("PXKENC",549479964,78,"TRT",2,811) =
^TMP("PXKENC",549479964,78,"VST",78,0) = 2960321.1^2960326^V^^1030^660
^A^143^23^^^^2960326^^^^^^^
^11^39^31^13560
^TMP("PXKENC",549479964,78,"VST",78,11) =
^TMP("PXKENC",549479964,78,"VST",78,21) =
^TMP("PXKENC",549479964,78,"VST",78,150) = 1^^P
^TMP("PXKENC",549479964,78,"VST",78,800) = 0
^TMP("PXKENC",549479964,78,"VST",78,811) =\n
====================================================================\n
$$GETENC^PXAPI(DFN,ENCDT,HLOC)\n
This API was developed to extract all encounter data for all encounters that
match the passed parameters. The data represents elements that are stored in
the Visit file (9000010) and other PCE files.\n
Parameter Description:\n
1. DFN: (required) Pointer to IHS/PATIENT file (9000001)\n
2. ENCDT: (required) Date/Time of encounter in Fileman format\n
3. HLOC: (required) Pointer to Hospital Location file (44)\n
Returned Value:\n
-2 If Called incorrectly
-1 If no encounter is found
>0 Visit file ien(s) separated by ^\n
The data is stored in a ^TMP global array with subscripts denoting the
category of returned data. The data returned in the ^TMP global represents
data from one encounter. The structure of the returned ^TMP global is:\n
^TMP("PXKENC",$J,VISIT,V FILE STRING,V FILE RECORD,DD SUBSCRIPT)
=DATA\n
Where:\n
Global Root Temporary global file root: ^TMP
Subscript 1 String notation representing Package: "PXKENC"
Subscript 2 Job Number: $J
Subscript 3 Internal Entry Number of the Visit (IEN).
Subscript 4 String representing the Visit or V file data category:
"CPT" = V CPT (procedure) #9000010.18
"HF" = V Health Factors #9000010.23
"ICR" = V Imm Contra/Refusal #9000010.707
Events
"IMM" = V Immunization #9000010.11
"PED" = V Patient Ed #9000010.16
"POV" = V POV (diagnosis) #9000010.07
"PRV" = V Provider #9000010.06
"SK" = V Skin Test #9000010.12
"TRT" = V Treatment #9000010.15
"VST" = Visit file #9000010
"XAM" = V Exam #9000010.13
"CSTP" = Visit file #9000010
This subscript contains child visits
used to store additional Stop Codes.\n
Subscript 5 Internal entry number of the entry in the file
represented in subscript #4
Subscript 6 Subscript or DD node on which the data is stored.
Every DD node is published whether or not there is any
data for that node. e.g. 0, 12, and 811\n
Data:\n
The DATA that exists to the right of the global node is a reflection of data
as it appears in the global node of the IEN of the file (noted in subscript
#5) and the NODE of that IEN (described in subscript #6).\n
Data Capture of Example output:\n
Included below is a capture of ^TMP("PXKENC".\n
^TMP("PXKENC",549479964,78,"CPT",135,0) = 34510^1030^78^176^^^^^^^^^^^^1
^TMP("PXKENC",549479964,78,"CPT",135,1,0) = ^^1^1
^TMP("PXKENC",549479964,78,"CPT",135,1,1,0) = 16
^TMP("PXKENC",549479964,78,"CPT",135,12) = ^^^108
^TMP("PXKENC",549479964,78,"CPT",135,802) =
^TMP("PXKENC",549479964,78,"CPT",135,811) =
^TMP("PXKENC",549479964,78,"POV",96,0) = 9054^1030^78^177^^^^^^^^S
^TMP("PXKENC",549479964,78,"POV",96,12) = ^^^108
^TMP("PXKENC",549479964,78,"POV",96,800) = 0
^TMP("PXKENC",549479964,78,"POV",96,802) = 168
^TMP("PXKENC",549479964,78,"POV",96,811) =
^TMP("PXKENC",549479964,78,"POV",104,0) = 2569^1030^78^178^^^^^^^^P
^TMP("PXKENC",549479964,78,"POV",104,12) =
^TMP("PXKENC",549479964,78,"POV",104,800) =
^TMP("PXKENC",549479964,78,"POV",104,802) =
^TMP("PXKENC",549479964,78,"POV",104,811) = this is a comment
^TMP("PXKENC",549479964,78,"PRV",94,0) = 58^1030^78^S^A
^TMP("PXKENC",549479964,78,"PRV",94,12) =
^TMP("PXKENC",549479964,78,"PRV",94,811) =
^TMP("PXKENC",549479964,78,"PRV",114,0) = 108^1030^78^S
^TMP("PXKENC",549479964,78,"PRV",114,12) =
^TMP("PXKENC",549479964,78,"PRV",114,811) =
^TMP("PXKENC",549479964,78,"SK",3,0) = 1^1030^78^D^3^2960328.182336
^TMP("PXKENC",549479964,78,"SK",3,12) = ^58^^108
^TMP("PXKENC",549479964,78,"SK",3,811) =
^TMP("PXKENC",549479964,78,"TRT",2,0) = 162^1030^78^3^^175
^TMP("PXKENC",549479964,78,"TRT",2,12) = ^108^^58
^TMP("PXKENC",549479964,78,"TRT",2,802) =
^TMP("PXKENC",549479964,78,"TRT",2,811) =
^TMP("PXKENC",549479964,78,"VST",78,0) = 2960321.1^2960326^V^^1030^660
^A^143^23^^^^2960326^^^^^^^
^11^39^31^13560
^TMP("PXKENC",549479964,78,"VST",78,11) =
^TMP("PXKENC",549479964,78,"VST",78,21) =
^TMP("PXKENC",549479964,78,"VST",78,150) = 1^^P
^TMP("PXKENC",549479964,78,"VST",78,800) = 0
^TMP("PXKENC",549479964,78,"VST",78,811) =\n
The ^TMP("PXKENC",$J) global may be killed before and/or after the call.", "", "PXAPI", "2016/09/19"], ["1895", "DBIA1889-G", "Routine", "PCE PATIENT CARE ENCOUNTER", "2004/03/02", "APPROVED", "Active", "Controlled Subscription", "", "
$$VST2APPT^PXAPI(VISIT)\n
This function tells if Visit is related to an appointment. Or if it is a
standalone visit (i.e. is not related to an appointment).\n
Parameter:
VISIT ien to a Visit file (#9000010) entry\n
Returned value:
1 if the visit is related to an appointment.
0 if the visit is NOT related to an appointment.
-1 if the visit is not a valued pointer.\n
=======================================================================\n
$$APPT2VST^PXAPI(PATIENT,DATETIME,HOSPLOC)\n
The function returns the visit that is related to an appointment. Must be
able to resolve the Patient, Date/Time and Clinic to an appointment entry in
the Patient file.\n
Parameters:
PATIENT DFN of a patient in the Patient file (#2) and the
Patient/IHS file (#9000001)
DATETIME The date and time of the appointment
HOSPLOC The Clinic of the appointment, pointer to Hospital
Location file (#44)\n
Returned value:
>0 ien of visit that relates to the apppointment
0 if there is no appointment or the appointment does
not point to a visit.", "", "PXAPI", ""], ["1896", "DBIA1889-H", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
$$SOURCE^PXAPI(NAME)\n
This API returns a pointer to the PCE Data Source file (#839.7) for the text
name of the Data Source. If the Data Source is not in the file it will be
added and the pointer to the new entry returned.\n
Parameter Description:\n
NAME Text name for the source of data to PCE.\n
Returned Value:\n
-1 Error in processing.
>0 IEN of the NAME in the PCE Data Source file.", "", "PXAPI", ""], ["1897", "DBIA1889-I", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Private", "", "
$$SWITCHD^PXAPI\n
This call may be used to return the switch over date defined in the SD/PCE
Switch Over Date field (.02) of the PCE Parameters file (815). This is the
date which Scheduling stopped asking for the clinical data and PCE started
asking for it instead.\n
Parameter Definition: None\n
Returned Value:\n
Date Internal FileMan format for date.
Null If date is undefined.\n\n
=====================================================================\n
$$SWITCHCK^PXAPI(DATE)\n
The call may be used to compare a date to the switch over date defined in the
SD/PCE Switch Over Date field (.02) of the PCE Parameters file (815).\n
Parameter Definition:\n
DATE Internal FileMan date.\n
Returned Value:\n
1 If the date passed is greater than or equal to the
switch over date.
0 If the date passed is less than the switch over date
or the switch over date is undefined.", "", "PXAPI", ""], ["1898", "DBIA1889-J", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Private", "", "
$$STOPCODE^PXAPI(STOPCODE,PATIENT,DATE)\n
This function call returns the quantity of a particular Stop Code for a
patient on one day. This is used by Scheduling.\n
Parameter Definition:\n
STOPCODE (required) pointer to #40.7
PATIENT (required) pointer to #2
DATE (required) the date in Fileman format
(time is ignored if passed) Returned Value:\n
the count of how many of that stop code are stored for
that one day\n
======================================================================\n
$$CPT^PXAPI(CPT,PATIENT,DATE,HLOC)\n
This is the function call to return the quantity of a particular CPT for a
patient on one day and for one hospital location if passed. This is used by
Scheduling to make sure that it has the CPT code the same number of times as
PCE does.\n
Parameter Description:\n
CPT (required) pointer to #81
PATIENT (required) pointer to #2
DATE (required) the date in Fileman format
(time is ignored if passed)
HLOC (optional) pointer to Hospital Location file (#44)\n
Returned Value:\n
The count of how many (total quinity) of that cpt code are stored
for that one day for that one patient in that one Hospital
Location.", "", "PXAPI", ""], ["1899", "DBIA1889-A", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "\n
PCE Device Interface module local array structures exported with PCE.\n
Conventions\n
An Error Suspension file records data that fails the verification process
or if there are errors in storing.\n
1. In listings of valid values [1 | 0 | null]
1 denotes TRUE or YES
0 denotes FALSE or NO
null denotes VALUE NOT SUPPLIED BY DATA CAPTURE APPLICATION\n
2. The PCE Device Interface uses a locally name-spaced array (called
LOCAL in this document ) with the following gross structure to
receive data from an external device. Developers should use an
array in their namespace to represent the LOCAL array. It is
possible that data from multiple providers was captured for the
encounter. The ENCOUNTER node records information about the
"main" provider. It is mandatory that this person be identified
in the ENCOUNTER node. Data will NOT be moved to VISTA if such a
provider is not identified on the ENCOUNTER node. The remaining
nodes in the LOCAL( array [VITALS, DIAGNOSIS, PROCEDURE,
PROBLEM... ] are specific to the particular PROVIDER associated
with the data on that node. If the provider is unknown, (for
example, the identity of the nurse who took the vitals was not
captured on a scanned encounter form) the provider subscript
<PROVIDER IEN> may be set to zero except provider is required for
PROBLEM. This is a concession to reality, and should not be
encouraged. If a provider CAN be identified, they SHOULD be
identified.\n
Locally name-spaced array:
LOCAL("DIAGNOSIS/PROBLEM",<PROVIDER IEN>)
LOCAL("PROBLEM",<PROVIDER IEN>)
LOCAL("SOURCE")
LOCAL("ENCOUNTER")
LOCAL("DIAGNOSIS",<PROVIDER IEN>)
LOCAL("PROCEDURE",<PROVIDER IEN>)
LOCAL("PROVIDER",<PROVIDER IEN>)
LOCAL("IMMUNIZATION",<PROVIDER IEN>)
LOCAL("SKIN TEST",<PROVIDER IEN>)
LOCAL("EXAM",<PROVIDER IEN>)
LOCAL("PATIENT ED",<PROVIDER IEN>)
LOCAL("HEALTH FACTORS",<PROVIDER IEN>)
LOCAL("VITALS",<PROVIDER IEN>)
Vitals are not processed by PCE but are passed to the
Vitals/Measurement package.
LOCAL("LOCAL",
This data doesn PCE and will not be
processed by PCE, but it may be used to pass local data
to a local process (see protocol for local data
processing).\n
3. The Encounter and Source nodes are required; the rest are
optional.\n
4. All entries in the local array are resolved to internal values as
defined below.\n
5. By convention; use a DUZ = .5 (the POSTMASTER) as a default when\n
one cannot be determined. This is only for tasked jobs on some
systems.\n
6. The data in the ENCOUNTER, PROCEDURE, and DIAGNOSIS/ PROBLEM or
DIAGNOSIS nodes are the minimal set for capturing workload
starting 10/1/96. The data in the rest of the nodes with the
associated providers build on the clinically relevant data set
and are not used for workload\n
7. While ENCOUNTER, PROCEDURE, and DIAGNOSIS/PROBLEM or DIAGNOSIS
values are required to capture workload and generate a bill, they
may not be present in every data set passed through this event
point. For example, data on Vitals may be collected by a Nurse
and passed through the event point for storage independent of
other data associated with the encounter. Because of this, these
are NOT required values in this version.\n
8. If there is a different (ancillary) hospital location for this
patient encounter, you have to do a separate encounter. Separate
calls for each hospital location are required.\n\n
Required Input\n
LOCAL( LOCAL( is a local array as defined in the remainder
of this document. Developers should use an array in
their namespace to represent the LOCAL array; e.g.,
IBDFPCE.\n
Result returned\n
PXCASTAT 1 = event processing occurred and the data was
passed to DHCP.
0 = event processing could not occur. There is data
in LOCAL("ERROR" explaining why.\n
LOCAL("ERROR" as described below. Denotes Errors. Data associated
with the error was not filed. The node does not
exist if errors do not occur.
LOCAL("ERROR",<NODE>,<PROVIDER
IEN>,<i>,<PIECE>)="Free text message^REJECTED VALUE"
Where <NODE> ::= "ENCOUNTER" | "VITALS" |
"DIAGNOSIS" | "PROCEDURE" |
"PROBLEM" | rest of list|
<PROVIDER IEN> ::= internal entry number of
provider. Is 0 (ZERO) for ENCOUNTER
and SOURCE
<i> ::= sub-entry 'i' for that provider
Is 0 (ZERO) for ENCOUNTER, SOURCE
and PROVIDER
<PIECE> ::= $P( selector in
LOCAL(<NODE>,<PROVIDER IEN>,<i>)
that failed.
The value of <PIECE> may be 0
(ZERO) if a problem is found that
does not relate to a single
specific piece.\n
LOCAL("WARNING" as described below. Denotes problems with the
data that did not prevent processing. Processing
continued after the warnable condition was detected.
The node does not exist if warning, conditions do
not occur. Warnings do NOT affect the value of
PXCASTAT.\n
LOCAL("WARNING",<NODE>,<PROVIDER IEN>,<i>,<PIECE>)
="Free text message^QUESTIONABLE VALUE"
Where <NODE> ::= "ENCOUNTER" | "VITALS" |
"DIAGNOSIS" | "PROCEDURE" |
"PROBLEM"
<PROVIDER IEN> ::= internal entry number of
provider. Is 0 (ZERO) for ENCOUNTER
and SOURCE
<i> ::= sub-entry 'i' for that provider
Is 0 (ZERO) for ENCOUNTER, SOURCE,
and PROVIDER
<PIECE> ::= $P( selector in
LOCAL(<NODE>,<PROVIDER IEN>,<i>) in
question.
The value of <PIECE> may be 0
(ZERO) if a problem is found that
does not relate to a single
specific piece.\n\n
Entry Point for processing the data in the foreground\n
FOREGND^PXCA(.LOCAL,.PXCASTAT) All data for the event driver is to
be stored in the local array, LOCAL(, in the
proper format by the source prior to calling
this entry point. This entry point validates and
verifies the data and then if there are no
validation errors, the data is processed in the
foreground. Computation by the source will not
continue until all processing is completed by
any and all 'down-stream' protocol event points.\n
Entry Point for processing the data in the background on the Host\n
BACKGND^PXCA(.LOCAL,.PXCASTAT) All data for the event driver is to
be stored in the local array, LOCAL(, in the
proper format by the source prior to calling
this entry point. This entry point validates and
verifies the data and then if there are no
validation errors, the data is processed in the
background via TASKMAN. Computation by the
source may continue.\n
Entry Point for data validation\n
VALIDATE^PXCA(.LOCAL) The data in the local array, LOCAL(, is
validated and verified, but is not processed.
Use of this entry point by your application will
result in the data being validated twice, since
it is validated prior to processing by the
FOREGND^PXCAEP and BACKGND^PXCAEP entry points.
If a piece of data cannot be validated, an entry
is placed in the LOCAL("ERROR" node as described
above\n
Protocol for local data processing\n
PXCA DATA EVENT Other developers who wish to use any of the data
in the local array, including local additions,
can attach a protocol that calls their routines
to the item multiple of this protocol. This
protocol is activated if there are no errors in
the data validation and after PCE has processed
the data.\n\n
For data unique to the encounter\n
SOURCE data LOCAL("SOURCE") = 1^2^3^4^5, where:\n
Piece 1
Data Source
Required for PCE
Required for SD
Format: DATA SOURCES file (#839.7)
Piece 2
DUZ
Required for PCE
Required for Scheduling\n
Piece 3
Form numbers
Not stored by PCE Piece 4
Batch ID
Not stored by PCE Piece 5
Record ID
Not stored by PCE\n
Encounter data LOCAL("ENCOUNTER") =
1^2^3^4^5^6^7^8^9^10^11^12^13^14^15^16^17^18, where:
LOCAL("ENCOUNTER",modifier[E;1/.01]) = ""\n
Piece 1
Appointment Date/Time
Required for PCE
Required for Scheduling
Format: Fileman Date/Time
Piece 2
Patient DFN
Required for PCE
Required for Scheduling
Format: Pointer to IHS PATIENT file (#9000001)
Piece 3
Hospital Location IEN
Each hospital location is a separate encounter P,S
Format: Pointer to HOSPITAL LOCATION file (#44)
Piece 4
Provider IEN
This is the person that saw the Patient at the scheduled date and
time.
Required for PCE
Format: Pointer to NEW PERSON file (#200)
Piece 5
Visit CPT code IEN
Format: Pointer to TYPE OF VISIT (#357.69)
Piece 6
SC Condition
Format: [1 | 0 | null]
Piece 7
AO Condition
Format: [1 | 0 | null]
Piece 8
IR Condition
Format: [1 | 0 | null]
Piece 9
EC Condition
Format: [1 | 0 | null]
Piece 10
MST Condition
Format: [1 | 0 | null]
Piece 13
Eligibility Code IEN
Format: Pointer to ELIGIBILITY CODE file (#8)
Piece 14
Check-out date and time
Format: Fileman Date/Time
Piece 15
Provider indicator (relates to 4)
Required for PCE
Format: Set of Codes
P ::= Primary
S ::= Secondary
Piece 16
Attending Physician IEN
(May or may not be the same as 4)
Format: Pointer to NEW PERSON file (#200)
Piece 17
HNC Condition
Format: [ 1 | 0 | null ]
Piece 18
CV Condition
Format: [ 1 | 0 | null ]\n\n
All of the remaining entries in the LOCAL( array are specific to a
particular Provider associated with the data on that node. If the
provider is unknown, (for example, the identity of the nurse who
took the vitals isn t recorded on a scanned encounter form), the
provider subscript <PROVIDER IEN> may be set to zero.\n\n
Diagnosis and/or Problems, specific to one provider\n
We recommend that you use these nodes instead of the separate Diagnosis
and Problem nodes.\n
If no Diagnosis and/or Problems, $D(LOCAL("DIAGNOSIS/PROBLEM")) is true.
LOCAL("DIAGNOSIS/PROBLEM",<PROVIDER IEN>, i) = 1^2^3^4,...17^18 where:\n
Piece 1
Diagnosis Code IEN
Required for PCE
Required for Scheduling
Format: Pointer to ICD9 DIAGNOSIS file (#80)
Piece 2
Diagnosis Specification Code
Required for PCE
N/A for Problem List
Format: Set of Codes
P ::= Primary
S ::= Secondary
Piece 3
Clinical Lexicon Term IEN
Format: Pointer to EXPRESSIONS file (#757.01)
Piece 4
Problem IEN
Required by Problem List for existing
Format: Pointer to PROBLEM LIST file (#9000011)
Piece 5
Add to Problem List
N/A for PCE
Required by Problem List for new problem
Format: [1 | 0 | null]
Piece 6
Problem Active?
Default is Active if not specified
N/A for PCE
Format: Set of Codes
A ::= Active
I ::= Inactive
Piece 7
Problem Onset Date
N/A for PCE
Format: Fileman Date/Time
Piece 8
Problem Resolved Date
N/A for PCE
Format: Fileman Date/Time
Piece 9
SC Condition
Format: [1 | 0 | null]
Piece 10
AO Condition
Format: [1 | 0 | null]
Piece 11
IR Condition
Format: [1 | 0 | null]
Piece 12
EC Condition
Format: [1 | 0 | null]
Piece 13
Provider Narrative
Required for PCE
Required by Problem List for new problem
Format: free text, 2-80 Characters
Piece 14
Category Header for Provider Narrative
N/A for Problem List
Format: free text, 2-80 Characters
Piece 15
MST Condition
Format: [ 1 | 0 | null ]
Piece 16
HNC Condition
Format: [ 1 | 0 | null ]
Piece 17
CV Condition
Format: [ 1 | 0 | null ]
Piece 18
Order/Resulting
Format: Set of Codes
O ::= Ordering
R ::= Resulting
B ::= Both Ordering and Resulting\n
LOCAL("DIAGNOSIS/PROBLEM",<PROVIDER IEN>,i,"NOTE") = 1, where:\n
Piece 1
Provider N/A for PCE
Format: free text, 3-60 Characters\n
NOTE: If the NOTE node is not needed, it does not have to exist.\n
NOTE: Information is passed to Problem List if there is data for any of
the positions 5-8 on the "DIAGNOSIS/PROBLEM" node or if there is "NOTE"
node.\n
NOTE: A provider is required to add a new problem to the Problem List.\n\n
Diagnosis data list, specific to one provider, for Problems being treated
at this encounter:\n
If no Diagnoses, then '$D(LOCAL("DIAGNOSIS",<PROVIDER IEN>))is true.
LOCAL("DIAGNOSIS",<PROVIDER IEN>,i) = 1^2^3^4^...^13^14 where:\n
Piece 1
Diagnosis code IEN
Required for PCE
Required for Scheduling
Format: Pointer to ICD9 DIAGNOSIS File (#80)
Piece 2
Diagnosis specification code
Will default to "S" if blank
Format: Set of Codes.
P ::= Primary
S ::= Secondary
Piece 3
SC Condition
Format: [1 | 0 | null]
Piece 4
AO Condition
Format: [1 | 0 | null]
Piece 5
IR Condition
Format: [1 | 0 | null]
Piece 6
EC Condition
Format: [1 | 0 | null]
Piece 7
Associated Problem IEN
Format: Pointer to PROBLEM LIST file 9000011
Piece 8
Physician's term for Diagnosis
Required for PCE
Format: free text, 2-80 Characters
Piece 9
Physician's term for Category Header
May have been used as a grouping for a set of related Diagnosis
which the provider selected from
Format: free text, 2-80 Characters
Piece 10
Lexicon IEN
Format: Pointer to EXPRESSIONS File (#757.01)
Piece 11
MST Condition
Format: [ 1 | 0 | null ]
Piece 12
HNC Condition
Format: [ 1 | 0 | null ]
Piece 13
CV Condition
Format: [ 1 | 0 | null ]
Piece 14
Order/Resulting
Format: Set of Codes
O ::= Ordering
R ::= Resulting
B ::= Both Ordering and Resulting\n
NOTE: PCE recommends using the DIAGNOSIS/PROBLEM node so that the
diagnosis can point to the problem that it relates to.\n\n
Procedures data list, specific to one provider\n
If no Procedures, then '$D(LOCAL("PROCEDURE",<PROVIDER IEN>)) is true.
LOCAL("PROCEDURE",<PROVIDER IEN>,i) = 1^2^3^4^5^6^7^8^9^10^
11^12^13^14,(pieces defined below)
LOCAL("PROCEDURE",<PROVIDER IEN>,i,modifier[E;1/.01]) = ""\n
Piece 1
CPT4 Procedure code\n
Required by PCE for V CPT file (Procedures)
if this field is blank then will be stored in V TREATMENT file
Required for Scheduling
Format: Pointer to CPT file (#81)
Piece 2
Quantity Performed
Required for PCE
Required for Scheduling
Format: number > 0
Piece 3
Procedure specification code
For CPT only.
Format: Set of Codes
P ::= Primary
S ::= Secondary
Piece 4
Date/Time Procedure performed
Format: Fileman Date/Time
Piece 5
Primary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 6
Physician's term for Procedure
Required for PCE
Format: free text, 2-80 Characters
Piece 7
Physician's term for Category Header
May have been used as a grouping for a set of related Procedures
which the provider selected from
Format: free text, 2-80 Characters
Piece 8
1st Secondary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 9
2nd Secondary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 10
3rd Secondary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 11
4th Secondary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 12
5th Secondary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 13
6th Secondary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 14
7th Secondary Associated Diagnosis IEN For this CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)\n\n
NOTE: If a Procedure doesn t have a
CPT code, it can be passed without one and will be stored in the
V Treatment file but will not be used for workload or billing.\n\n
Problem data list, specific to one provider\n
If no Problems, then '$D(LOCAL("PROBLEM",<PROVIDER IEN>)) is true.
LOCAL("PROBLEM",<PROVIDER IEN>,i) = 1^2^3^4^5^...^15 where:\n
Piece 1
Problem Name
Required for new Problem List, i.e. if Pos. 10 is null
Format: free text
Piece 2
Problem Onset Date
Format: Fileman Date/Time
Piece 3
Problem Active?
Default is ACTIVE if not specified
Format: [1 | 0 | null]
Piece 4
Problem Date Resolved
Format: Fileman Date/Time
Piece 5
SC Condition
Format: [1 | 0 | null]
Piece 6
AO Condition
Format: [1 | 0 | null]
Piece 7
IR Condition
Format: [1 | 0 | null]
Piece 8
EC Condition
Format: [1 | 0 | null]
Piece 9
ICD 9 Code value {optional}
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 10
Problem IEN
Must be null if new problem
Required for editing existing Problem
Format: Pointer to PROBLEM LIST file 9000011
Piece 11
Physician's term for Problem
Null if new problem
Format: free text, 60 Characters Max
Piece 12
Lexicon IEN
Format: Pointer to EXPRESSIONS File (#757.01)
Piece 13
MST Condition
Format: [ 1 | 0 | null ]
Piece 14
HNC Condition
Format: [ 1 | 0 | null ]
Piece 15
CV Condition
Format: [ 1 | 0 | null ]\n
NOTE: The data in this node is passed to Problem List. A Provider is
required to add a new problem to the Problem List. When a new problem is
added to the Problem List, the problem IEN is not required. If data is
passed to edit existing data, the problem IEN must be passed.\n
NOTE: It is better to use the DIAGNOSIS/PROBLEM node so that the diagnosis
can point to the problem that it relates to.\n\n
Provider data list, specific to one provider\n
Use this node to pass of additional providers which do not have data
associated with them.\n
If no additional Providers, then '$D(LOCAL("PROVIDER",< PROVIDER IEN>))
is true.\n
LOCAL ("PROVIDER",<PROVIDER IEN>= 1^2 where:\n
Piece 1
Provider indicator
Required for PCE
Format: Set of Codes.
P: = Primary
S: = Secondary
Piece 2
Attending
Format: [1|0| null]\n
NOTE: If a provider is on the Encounter node and also on this node
then the data on this node will be used for Primary/Secondary indicator.\n\n
Immunization data list, specific to one provider\n
If no immunization entries, then '$D(LOCAL("IMMUNIZATION",<PROVIDER IEN>))
is true.\n
LOCAL ("IMMUNIZATION",<PROVIDER IEN>,i)=1^2^3^4^5^6^7^8^9^10^11^12^13^14^15\n
Piece 1
Immunization
Required for PCE
Format: Pointer to IMMUNIZATION File (9999999.14)
Piece 2
Series
Format: Set of Codes.
P::=Partially complete
C::=Complete
B::=Booster
1::=Series1
...
8::=Series8
Piece 4
Reaction
REACTION Field (9000010.11,.06) SET
Format: Set of Codes.
'0' FOR NONE
'1' FOR FEVER;
'2' FOR IRRITABILITY;
'3' FOR LOCAL REACTION OR SWELLING;
'4' FOR VOMITING;
'5' FOR RASH OR ITCHING;
'6' FOR LETHARGY;
'7' FOR CONVULSIONS;
'8' FOR ARTHRITIS OR ARTHRALGIAS;
'9' FOR ANAPHYLAXIS OR COLLAPSE;
'10' FOR RESPIRATORY DISTRESS;
'11' FOR OTHER;
Piece 5
Contraindicated
Format: [1|0|null]
Piece 6
Event D/T
Format: Fileman Date/Time
Piece 7
Remarks
Format: Comment
Piece 8
Primary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80
Piece 9
1st Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 10
2nd Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 11
3rd Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 12
4th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 13
5th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 14
6th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 15
7th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)\n\n\n
Skin Test data list, specific to one provider\n
If no skin test entries, then '$D(LOCAL("SKIN TEST",<PROVIDER IEN>)) is
true. LOCAL ("SKIN TEST",<PROVIDER IEN>,i)=1^2^3^4^5^6^7^8^9^10^11^12^13\n
Piece 1
SKIN TEST
Required for PCE
Format: Pointer to SKIN TEST File (9999999.28)
Piece 2\n
READING
Format: Whole number between 0 and 40 inclusive
Piece 3
RESULT
Format: Set of Codes.
P::=Positive
N::=Negative
D::=Doubtful
0::=No Take
Piece 4
Date Read
Format: Fileman Date/Time
Piece 5
Date of Injection
Format: Fileman Date/Time
Piece 6
Primary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80
Piece 7
1st Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 8
2nd Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 9
3rd Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 10
4th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 11
5th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 12
6th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)
Piece 13
7th Secondary Associated Diagnosis IEN For this mapped CPT only.
Format: Pointer to ICD DIAGNOSIS File (#80)\n\n\n
Examination data list, specific to one provider\n
If no examination entries, then '$D(LOCAL("EXAM",<PROVIDER IEN>)) is true.
LOCAL ("EXAM",<PROVIDER.IEN>")=1^2\n
Piece 1
EXAM
Required for PCE
Format: Pointer to EXAM File (9999999.15)
Piece 2
RESULT
Format: Set of Codes.
A::=Abnormal
N::=Normal\n\n
Patient Education data list, specific to one provider\n
If no Patient Education entries, then '$D(LOCAL("PATIENT ED",<PROVIDER
IEN>)) is true. LOCAL ("PATIENT ED",<PROVIDER IEN>,i)=1^2\n
Piece 1
Topic
Required for PCE
Format: Pointer to EDUCATION TOPICS File (9999999.09)
Piece 2
Level of Understanding
Format: Set of Codes.
1::=Poor
2::=Fair
3::=Good
4::=Group - No Assessment
5::=Refused\n\n
Health Factors data list, specific to one provider\n
If no Health Factors entries, then
'$D(LOCAL("HEALTH FACTORS",<PROVIDER IEN>)) is true. LOCAL ("HEALTH
FACTORS",<PROVIDER IEN>,i)=1^2\n
Piece 1
Health Factor
Required for PCE
Format: Pointer to HEALTH FACTORS File (9999999.64)
Piece 2
Level/Severity
Format: Set of Codes.
M::=Minimal
MO::=Moderate
H::=Heavy/Severe\n\n
Vitals data list, specific to one provider\n
If no Vitals, then '$D(LOCAL("VITALS",<PROVIDER IEN>)) is true.
LOCAL("VITALS",<PROVIDER IEN>,i) = 1^2^3^4, where:\n
Piece 1
Type
Required for PCE
Format: Set of Codes.
AG::= ABDOMINAL GIRTH
AUD::= AUDIOMETREY
BP::= BLOOD PRESSURE
FH::= FUNDAL HEIGHT
FT::= FETAL HEART TONES
HC::= HEAD CIRCUMFERENCE
HE::= HEARING
HT::= HEIGHT
PU::= PULSE
RS::= RESPIRATIONS
TMP::=TEMPERATURE
TON::=TONOMETRY
VC::= VISION CORRECTED
VU::= VISION UNCORRECTED
WT::= WEIGHT
Piece 2
Value
Required for PCE
Format: Numeric
Piece 3
Units
Not stored; used for conversions
Format: Set of Codes.
C::=Centigrade (degrees)
CM::=Centimeter
F::= Fahrenheit (degrees)
IN::=Inches
KG::=Kilograms
LB::=Pounds
Piece 4
Date/Time Measurement taken
Format: Fileman Date/Time\n
If the TYPE is HT: If the UNIT is CM it is converted to IN so that it
can be stored. If the UNIT is "" it is assumed to be
IN. If the TYPE is WT If the UNIT is KG it is
converted to LB so that it
can be stored. If the UNIT is "" it is assumed to be
LB. If the TYPE is TMP If the UNIT is C it is
converted to F so that it can
be stored. If the UNIT is "" it is assumed to be F.\n
NOTE: This data is passed to the Vitals/Measurement package for validation
and storage.\n\n
Local data list, specific to one provider\n
If no local entries, then '$D(LOCAL("LOCAL",<PROVIDER IEN>)) is true.
LOCAL("LOCAL",<PROVIDER IEN>,i) = Site Specific data encoding\n
Pieces All
Site Specific data encoding
Not stored in PCE
Format: Site Specific\n
NOTE: LOCAL("LOCAL" where "LOCAL" is replaced by locally namespaced
string.", "", "PXCA", ""], ["1900", "DBIA1900-A", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Private", "", "\n
Visit Tracking is a utility that can be used by a variety of VISTA modules
(usually via PCE), with potential benefits for clinical, administrative,
and fiscal applications. Visit Tracking will allow VISTA packages to link
an event to a patient visit entry, thereby linking that event to any
number of events occurring throughout the hospital during the patient's
outpatient and/or inpatient episode.\n
Visit Tracking is not a stand-alone application. Other packages will
normally call PCE, which will handle the calls to Visit Tracking.\n\n
The key to the creation of visits will be to ensure the clinical
meaningfulness of visits. The creation of visits is facilitated by the
Visit Tracking module. In order to ensure a consistent implementation of
visit creation across packages, each package needs to have an agreement
with the Visit Administrator to create visits.\n\n
This section describes the guidelines which should be used for VA
developers populating visits in the Visit file. These guidelines are based
on a combination of the experience of Albuquerque's joint venture sharing,
IHS' PCC pilot test at Tucson VAMC, MCCR data capture pilots, HSR&D
workload reporting studies at Hines VAMC, and DMMS/DSS event data capture.\n
The purpose of the VISIT file in the VA:\n
The VISIT file has multiple purposes. The primary role is to record when
and where clinical encounters related to a patient have occurred. Visits
will be recorded for both Outpatient and Inpatient encounters.\n
Outpatient encounters include scheduled appointments and walk-in
unscheduled visits.\n
Inpatient encounters include the admission of a patient to a VAMC and
any clinically significant change related to treatment of that
patient. For example, a treating specialty change is clinically
significant, whereas a bed switch is not. The clinically significant
visits created throughout the inpatient stay are related to the
inpatient admission visit.\n
If the patient is seen in a clinic while an Inpatient, a separate
visit will be created representing the appointment visit?this visit
is related to the Admission visit.\n
A clinician's telephone communications with a patient may be
represented by a separate visit.\n
The clinical visits can be viewed from two approaches: 1) a team of
providers can be associated with a primary clinical visit (this is
the traditional view taken by IHS); or 2) a primary clinic visit can
represent the primary provider's care, and a separate visit can be
created to reflect the secondary provider's care.\n
Additionally, the VISIT file can provide a breakdown of other
ancillary services provided during the clinically significant visit.
Laboratory or Radiology services are other examples of services
provided that could have a separate visit reflecting the service
involvement related to a clinic appointment on the same day.\n
Create and/or Match Visit Using Input Criteria\n
^VSIT\n
INPUT:
VSIT <visit date [and time] in FM format>
VSIT("VDT") may be used instead of VSIT.
(time will default to 12 noon if not
specified)\n
DFN <patient file pointer>
VSIT("PAT") may be used instead of DFN.\n
[VSIT(0)] <a string of characters that defines how
the visit processor will function, see
package-wide variables>\n
[VSIT("<xxx>")] <array with mnemonic subscript>
(used in match logic if VSIT(0)["M")
(for SVC, TYP, INS, CLN, ELG, LOC)
Note: For multiple field values use
[<field value>[^...]]
i.e., VSIT("SVC")="H^D" (will find both)\n
VSITPKG <package name space>
VSIT("PKG") may be used instead of
VSITPKG.\n
OUTPUT:
VSIT(<ien>) N^S[^1]
where:
N = <internal entry number of visit>
or -1 if could not get a visit
or -2 if calling package is not
active in Visit Package Parameters
S = <value of .01 field of visit>
1 = <indicates that a new visit was added\n
VSIT(<xxx>) array passed in with all the entries
defined and the defaulted values added\n
VSIT(<ien>,<xxx>) returns the data that is stored in the
Visit file in the same format as
VSIT(<xxx>)\n
Variable descriptions:\n
VSIT(<xxx>) Variable Names for VISIT file fields,
Where <xxx> is a general reference to the field
mnemonic.
file: 9000010, global: ^AUPNVSIT(\n
Key Indicates\n
r indicated a required field m
matching/screening logic can/does apply s system
generated e strongly encouraged\n
Key Field Variable Description\n
.001 VSIT("IEN") NUMBER (visit internal entry number) rm
.01 VSIT("VDT") VISIT/ADMIT DATE&TIME (date) s .02
VSIT("CDT") DATE VISIT CREATED (date) m .03 VSIT("TYP")
TYPE (set) rm .05 VSIT("PAT") PATIENT NAME (pointer PATIENT
file
#9000001) (IHS file DINUMed to PATIENT
file #2) m .06 VSIT("INS")
LOC. OF ENCOUNTER (pointer LOCATION
file #9999999.06) (IHS file DINUMed to
INSTITUTION file #4)
.07 VSIT("SVC") SERVICE CATEGORY (set) ms .08
VSIT("DSS") DSS ID (pointer to CLINIC STOP file)
.09 VSIT("CTR") DEPENDENT ENTRY COUNTER (number)
.11 VSIT("DEL") DELETE FLAG (set)
.12 VSIT("LNK") PARENT VISIT LINK (pointer VISIT file
#9000010) s .13 VSIT("MDT")
DATE LAST MODIFIED (date)
.18 VSIT("COD") CHECK OUT DATE&TIME (date)
.21 VSIT("ELG") ELIGIBILITY (pointer ELIGIBILITY CODE
file #8) rm .22 VSIT("LOC")
HOSPITAL LOCATION (pointer HOSPITAL
LOCATION file #44)
.23 VSIT("USR") CREATED BY USER (pointer NEW PERSON
file #200)
.24 VSIT("OPT") OPTION USED TO CREATE (pointer
OPTION file #19)
.25 VSIT("PRO") PROTOCOL (pointer PROTOCOL file #101)
.26 VSIT("ACT") PFSS ACCOUNT REFERENCE (pointer
PFSS ACCOUNT file #375)
2101 VSIT("OUT") OUTSIDE LOCATION (free text)
80001 VSIT("SC") SERVICE CONNECTED (set)
80002 VSIT("AO" AGENT ORANGE EXPOSURE (set)
80003 VSIT("IR") IONIZING RADIATION EXPOSURE (set)
80004 VSIT("EC") PERSIAN GULF EXPOSURE (set)
80005 VSIT("MST") MILITARY SEXUAL TRAUMA (set)
15001 VSIT("VID") VISIT ID (free text)
15002 VSIT("IO") PATIENT STATUS IN/OUT (set)
15003 VSIT("PRI") ENCOUNTER TYPE (set)
81101 VSIT("COM") COMMENTS r 81202 VSIT("PKG")
PACKAGE (pointer PACKAGE file #9.4)
81203 VSIT("SOR") DATA SOURCE (pointer PCE DATA SOURCE file
#839.7)\n
r VSIT(0) A string of characters that defines how
the visit processor will function.
F Force adding a new entry.
I Interactive mode
E Use patient's primary eligibility if not
defined on call with VSIT("ELG").
N Allow creation of new visit.
D Look back "n" number of days for match,
defaults to one (1). D[<number of days>]
i.e., VSIT(0)="D7" e.g., VSIT(0)="D5"
(visit date to visit date - 4) use "D0"
to require exact match on visit date and
time.
M Impose criteria on matching/screening of
visits. Uses the VSIT(<xxx>) array:
Matching elements must equal their
corresponding field.\n
mr DFN Internal entry number of the patient file.
If not defined the VSIT("PAT") will be
used.\n
mr VSIT The date (and time) of the visit.
If not defined then VSIT("VDT") will be
used.\n
r VSITPKG Package Name Space.
If not defined then VSIT("PKG") will be
used.\n
VSIT(<ien>) N^S[^1]
where:
N = <internal entry number of visit>
S = <value of .01 field of visit>
1 = <indicates that a new visit was
added>", "", "VSIT", "2017/01/10"], ["1901", "VISIT FILE DATE LAST MODIFIED", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Private", "", "
MODIFIED^VSIT(IEN)\n
Sets the Date Last Modified (.13) field to NOW. This is used by PCE so that
the Date Last Modified refers to any modification to the Visit or any V-File.\n
Parameter Description:\n
IEN Pointer to the Visit file (#9000010)\n
Returned Value:\n
none\n
==========================================================================\n
UPD^VSIT\n
This will update any fields in the Visit file (#9000010) that can be edited.
Look up a visit and return all of its information\n
Where VSIT("HNC") has been identified as the reason for the visit, It will
also update the NOSE AND THROAT RADIUM HISTORY file (#28.11) to validate the
patient has been treated for Head and Neck Cancer, if no previous validation
has taken place.\n
Parameter Description:\n
VSIT("IEN") Pointer to the Visit file (#9000010)\n
Any of the following variables that are going to be updated:\n
Field # Variable Description
.03 VSIT("TYP") TYPE (set)
.06 VSIT("INS") LOC. OF ENCOUNTER (pointer LOCATION file
#9999999.06) (IHS file DINUMed to INSTITUTION
file #4)
.07 VSIT("SVC") SERVICE CATEGORY (set)
.08 VSIT("DSS") DSS ID (pointer to CLINIC STOP file)
.12 VSIT("LNK") PARENT VISIT LINK (pointer VISIT file #9000010)
.13 VSIT("MDT") DATE LAST MODIFIED (date)
This will be set to "NOW" by Visit Tracking.
.18 VSIT("COD") CHECK OUT DATE&TIME (date)
.21 VSIT("ELG") ELIGIBILITY (pointer ELIGIBILITY CODE file #8)
.22 VSIT("LOC") HOSPITAL LOCATION (pointer HOSPITAL LOCATION
file #44)
.23 VSIT("USR") CREATED BY USER (pointer NEW PERSON file #200)
.24 VSIT("OPT") OPTION USED TO CREATE (pointer OPTION file #19)
.25 VSIT("PRO") PROTOCOL (pointer PROTOCOL file #101)
2101 VSIT("OUT") OUTSIDE LOCATION (free text)
80001 VSIT("SC") SERVICE CONNECTED (set)
80002 VSIT("AO") AGENT ORANGE EXPOSURE (set)
80003 VSIT("IR") IONIZING RADIATION EXPOSURE (set)
80004 VSIT("EC") PERSIAN GULF EXPOSURE (set)
80005 VSIT("MST") MILITARY SEXUAL TRAUMA (set)
80006 VSIT("HNC") HEAD AND NECK CANCER (set)
80007 VSIT("CV") COMBAT VETERAN (set)
80008 VSIT("SHAD") PROJECT 112/SHAD (set)
80009 VSIT("CLV") CAMP LEJEUNE EXPOSURE (set)
15001 VSIT("VID") VISIT ID (free text)
15002 VSIT("IO") PATIENT STATUS IN/OUT (set)
15003 VSIT("PRI") ENCOUNTER TYPE (set)
81101 VSIT("COM") COMMENTS
81202 VSIT("PKG") PACKAGE (pointer PACKAGE file #9.4)
81203 VSIT("SOR") DATA SOURCE (pointer PCE DATA\n
Returned Value:\n
none", "", "VSIT", "2016/03/29"], ["1902", "DBIA1900-C", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
Ever field that points to the Visit file (#9000010)
needs to have two cross references. One is a regular Fileman cross reference.
If the field is in a multiple then this cross reference must be a whole file
cross reference. This cross reference is used to make sure that a Visit file
entry is not delete as long as there is a user of the entry.\n
The second cross reference calls ADD for the set logic and SUB for the kill
logic. This cross reference tells Visit Tracking how many file entries are
using (pointing to) a Visit file entry. Below is an example of this cross
reference\n
CROSS-REFERENCE: file number^Asomething^MUMPS
1)= D ADD^AUPNVSIT
2)= D SUB^AUPNVSIT\n
This cross-reference adds and subtracts from
the dependent entry count in the VISIT file.\n\n
ADD^VSIT or the more effect version: ADD^AUPNVSIT\n
Increase the dependent entry count for the Visit file entry by one.\n
INPUT X Visit IEN\n
SUB^VSIT or the more effect version: SUB^AUPNVSIT\n
Decrease the dependent entry count for the Visit file entry by one.\n
INPUT X Visit IEN\n
NOTE: These calls are customarily done through a MUMPS cross reference on the
field pointing to a Visit file entry. The input parameter X is set by Fileman.\n", "", "VSIT", ""], ["1903", "DBIA1900-D", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
$$IEN2VID^VSIT(VISIT)\n
This function returns the Visit ID for the Visit IEN passed in.\n
Parameter:
VISIT IEN to a Visit file (#9000010) entry\n
Returned value:
Visit ID if value Visit IEN
-1 if the Visit IEN is not a valued pointer\n
=======================================================================\n
$$VID2IEN^VSIT(VID)\n
This function returns the Visit IEN for the Visit ID passed in.\n
Parameter:
VID Visit ID\n
Returned value:
>0 IEN to a Visit file (#9000010) entry
-1 if there is no Visit file (#9000010) entry for the Visit ID", "", "VSIT", ""], ["1904", "DBIA1900-E", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
$$PKG2IEN^VSIT(PKG)\n
Returns a pointer to the Package file when you pass in the package name space
or name. The pointer to the package is required for some calls to PCE. This
function is provided so that the calling packages all do not have to do this
lookup themselves.\n
Parameter Description:\n
PKG Package name space or name\n
Returned Value:\n
>0 Pointer to the package in the Package file #9.4
-1 If called without PKG or if could not find the
package in the Package file.\n\n
$$PKGON^VSIT(PKG)\n
Returns the active flag for the package. A package that is active can create
Visits. PCE will be creating the Visits for most packages so they will not
need to be active. Only PCE will need to be active to create the visit for
them.\n
Parameter Description:\n
PKG Package name space or name\n
Returned Value:\n
1 The package can create visits (active)
0 The package cannot create visits (not active)
-1 Called wrong or could not find package in
Visit Tracking Parameters file # 150.9", "", "VSIT", ""], ["1905", "RETURN SELECTED VISITS FROM VSIT", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "\n
SELECTED^VSIT(DFN,SDT,EDT,HOSLOC,ENCTYPE,NENCTYPE,SERVCAT,NSERVCAT,LASTN)\n
Returns selected visits depending on screens passed in.\n\n
Parameter Description:\n
Only the DFN is required.\n
DFN Pointer to the Patient file (#2)
SDT Start Date
EDT End Date
HOSLOC Pointer to the Hospital Location file (#44)
ENCTYPE Encounter types is a string of all the Encounter Types
(field #15003) wanted.
e.g. "OA" for only Ancillary and Occasion of service
NENCTYPE Not Encounter types is a string of all the Encounter Types
(field #15003) not wanted.
e.g. "T" for do not include Telephone
SERVCAT Service Categories is a string of all the Service Categories
(field #.07) to include. If non is passed all is assumed.
e.g. "H" for just historical.
"T" for just Telephone.
"AIT" for ambulatory (in and out patient) and
Telephone.
NSERVCAT Not Service categories is a string of all the Service
Categories (field #.07) to not include.
LASTN How many to return starting with the End Date an going
backwards\n
Returned Array: (may be killed before and after use)\n
^TMP("VSIT",$J,vsit ien,#)
vsit ien Pointer to the Visit file (#9000010)
# Is a sequence number i.e. 1,2,3, ...\n
Where the values stored in the array are of the form:
Piece 1: Date and Time from the Vsit File Entry
Piece 2: If Service Category '= "H" then
Hospital Location (pointer to file#44) ";" External Value
If Service Category = "H" then
Location of Encounter (Pointer to file #9999999.06) ";"
External Value
Piece 3: Service Category (Value of field .07 set of codes)
Piece 4: Service Connected (Value of field 80001 External Value)
Piece 5: Patient Status in/out (Value of field 15002 set of codes)
Piece 6: Clinic Stop ien (Pointer to file # 40.7 ";" External value)", "", "VSIT", ""], ["1906", "DBIA1900-G", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
$$LOOKUP^VSIT(IEN,FMT,WITHIEN)\n
Look up a visit and return all of its information.\n
Parameter Description:\n
IEN Visit IEN OR the Visit's ID
FORMAT Is the format that you want the output in, where:
I ::= internal format
E ::= external format
B ::= both internal and external format
B is the default if anything other than "I" or "E"
WITHIEN 0 if you do not want the ien of the vsit as the first
subscript
1 if you do.
1 is the default.\n
Returned Value:\n
>0 Pointer to the Visit file (#9000010)
-1 if IEN was not a valid IEN or Visit ID\n\n
Returned Array:\n
The array of all the fields in the visit file. If both internal and external
format are returned the format is: internal^external\n
VSIT(<ien>,<xxx>) or VSIT(<xxx>) depending on the value of WITHIEN\n
Field # Variable Description
.01 VSIT("VDT") VISIT/ADMIT DATE&TIME (date)
.02 VSIT("CDT") DATE VISIT CREATED (date)
.03 VSIT("TYP") TYPE (set)
.05 VSIT("PAT") PATIENT NAME (pointer PATIENT file #9000001) (IHS
file DINUMed to PATIENT file #2)
.06 VSIT("INS") LOC. OF ENCOUNTER (pointer LOCATION file
#9999999.06) (IHS file DINUMed to INSTITUTION
file #4)
.07 VSIT("SVC") SERVICE CATEGORY (set)
.08 VSIT("DSS") DSS ID (pointer to CLINIC STOP file)
.09 VSIT("CTR") DEPENDENT ENTRY COUNTER (number)
.11 VSIT("DEL") DELETE FLAG (set)
.12 VSIT("LNK") PARENT VISIT LINK (pointer VISIT file #9000010)
.13 VSIT("MDT") DATE LAST MODIFIED (date)
.18 VSIT("COD") CHECK OUT DATE&TIME (date)
.21 VSIT("ELG") ELIGIBILITY (pointer ELIGIBILITY CODE file #8)
.22 VSIT("LOC") HOSPITAL LOCATION (pointer HOSPITAL LOCATION
file #44)
.23 VSIT("USR") CREATED BY USER (pointer NEW PERSON file #200)
.24 VSIT("OPT") OPTION USED TO CREATE (pointer OPTION file #19)
.25 VSIT("PRO") PROTOCOL (pointer PROTOCOL file #101)
2101 VSIT("OUT") OUTSIDE LOCATION (free text)
80001 VSIT("SC") SERVICE CONNECTED (set)
80002 VSIT("AO") AGENT ORANGE EXPOSURE (set)
80003 VSIT("IR") IONIZING RADIATION EXPOSURE (set)
80004 VSIT("EC") PERSIAN GULF EXPOSURE (set)
80005 VSIT("MST") MILITARY SEXUAL TRAUMA (set)
80006 VSIT("HNC") HEAD AND NECK CANCER (set)
80007 VSIT("CV") COMBAT VETERAN (set)
80008 VSIT("SHAD") PROJECT 112/SHAD (set)
80009 VSIT("CLV") CAMP LEJEUNE EXPOSURE (set)
15001 VSIT("VID") VISIT ID (free text)
15002 VSIT("IO") PATIENT STATUS IN/OUT (set)
15003 VSIT("PRI") ENCOUNTER TYPE (set)
81101 VSIT("COM") COMMENTS
81202 VSIT("PKG") PACKAGE (pointer PACKAGE file #9.4)
81203 VSIT("SOR") DATA SOURCE (pointer PCE DATA SOURCE file
(#839.7)\n", "", "VSIT", "2017/01/10"], ["1907", "DBIA1900-H", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Private", "", "
$$HISTORIC^VSIT(IEN)\n
Returns a flag indicating whether the visit is Historical.\n
Parameter Description:\n
IEN Pointer to the Visit file (#9000010)\n
Returned Value:\n
1 If it is an Historical visit ("E" in the
Service Category field #.07)
0 If it is not an Historical visit
-1 If the IEN is bad", "", "VSIT", ""], ["1908", "DBIA1900-A", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Private", "", "
$$PKG^VSIT(PKG,VALUE)\n
This API adds the package to the Package multiple (field #3) of the Visit
Tracking Paramenters (150.9) file. It also set the sets the Active Flag in
the multiple. If the package is already in the Package multiple it just set
the Active Flag for that package.\n
Parameter Description:\n
PKG Package Name Space
VALUE Value on the ON/OFF flag under package multiple
1 for ON and 0 for OFF\n
Returned Value:\n
1^active Where active is the value stored in the active flag
-1 Error in processing", "", "VSIT", ""], ["1909", "DBIA1900-B", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/01/23", "APPROVED", "Active", "Controlled Subscription", "", "
KILL^VSITKIL(IEN)\n
Deletes the visit if there is no files pointing to it. Before deleting checks
all the backward pointers to see if the visit is being pointed to.\n
Parameter Description:\n
IEN Pointer to the Visit file (#9000010)", "", "VSITKIL", ""], ["1910", "DBIA1910", "File", "SCHEDULING", "1997/01/24", "APPROVED", "Active", "Controlled Subscription", "409.68", "
DSS Extracts references the following data from the
OUTPATIENT ENCOUNTER file (#409.68). The data is referenced in the Clinic
Visit Extract for scheduled appointments, dispositions, stand- alones, and
appended visits.\n
(1) In determining the number of scheduled appointments: For each clinic in
the HOSPITAL LOCATION file, the APPOINTMENT multiple is examined. For each
patient appointment in the date range, the APPOINTMENT multiple in the PATIENT
file is examined. We get the OUTPATIENT ENCOUNTER (p20) pointer. Using this
IEN, we get the VISIT FILE ENTRY from the OUTPATIENT ENCOUNTER file. This is
used to call a PCE API for data. (2) In determining the number of
dispositions, stand-alones, etc.: We loop through the "B" cross-reference of
the OUTPATIENT ENCOUNTER file for the extract date range and get the encounter
IEN. Since all of the data is on the zero node, we set a local variable to the
zero node and process it from there.\n
DSS uses the "B" cross reference on the DATE field. ^SCE("B",DATE,D0)\n", "", "", ""], ["1911", "DBIA1911", "Routine", "TEXT INTEGRATION UTILITIES", "1997/01/24", "APPROVED", "Active", "Controlled Subscription", "", "
This API may be called by an application on the VistA
server to create a TIU Document with the following constraints and optional
properties:\n
Return variable (must pass by reference):\n
TIUIFN (pass by ref) = New note IFN in file 8925,
= -1 or variations if error.\n
Required Input parameters:\n
DFN = Patient IFN in file #2
TIUAUTH = Author IFN in file #200
TIURDT = Date/time of note in FM format
TIUTITLE = Title IFN in file 8925.1\n
Required global "input" variable:\n
^TMP("TIUP",$J) = Array root for text in format compatible
with FM Word-processing fields. e.g.,
^TMP("TIUP",$J,0)=^^1^1^2961216^
^TMP("TIUP",$J,1,0)=Testing the TIUPNAPI.\n
Optional Input variables:\n
TIULOC = Patient Location IFN in file #44
TIUES = 1 if TIU should prompt/process E-SIG
TIUPRT = 1 if TIU should prompt user to print note
TIUESBY = Signer IFN in file #200: Calling App is
responsible for Electronic Signature
TIUASKVS = BOOLEAN flag indicating whether to ask for visit
TIUADEL = BOOLEAN flag for automatic delete instead of
leaving UNSIGNED document if TIUESBY>0 and
signature fails. See NOTE on TIUADEL, below.\n
NOTE: The following change was made in patch TIU*1*184 in response to a
patient safety issue where SIGNED notes were sometimes created without a valid
expected cosigner being specified for users requiring cosignature.\n
If the API is called non-interactively for a user requiring cosignature with
the intention that the API create a SIGNED document (TIUESBY>0), then the
signature will now FAIL. Generally signature failure leaves the document
unsigned. However, if TIUADEL=1, signature failure deletes the document.\n
** Therefore we do not recommend the use of TIUADEL in this particular
situation (non-interactive, user requires cosignature, TIUESBY>0). **", "", "TIUPNAPI", ""], ["1912", "DBIA1912", "Routine", "1", "1997/01/28", "APPROVED", "Active", "Controlled Subscription", "", "
The MAS Developers would like a one-time integration
agreement with the FileMan Developers:\n
For patch DG*5.3*111, as part of the installation environment checker,
DG53111E, we check the second line of the following routine using $TEXT:
DIFROMSS\n
The check is to ensure that the package version is 21 and DIFROMSS has patch
#15 indicated in its second line.\n
This environment checker routine is necessary because the prefix, "DI", is not
unique to the VA FILEMAN package in the PACKAGE file (#9.4). An earlier
package named FILEMAN shares the same Prefix, and as a result, the "Required
Build" function in the KIDS Build does not function properly when referencing
a FileMan patch.", "", "DIFROMSS", ""], ["1914", "GMRVALL0", "Routine", "GEN. MED. REC. - VITALS", "1997/01/29", "APPROVED", "Active", "Private", "", "
Nursing can access the following entry point described
in this DBIA for GMRVED0 routine.", "", "GMRVALL0", ""], ["1915", "DBIA1915", "File", "LAB SERVICE", "1997/01/29", "", "Pending", "Private", "63", "", "", "", ""], ["1916", "SCAPMC - SUPPORTED PCMM CALLS", "Routine", "SCHEDULING", "1997/02/05", "APPROVED", "Active", "Supported", "", "
These are supported references in the SCAPMC routine:\n
(1) $$PRTM(SCTEAM,SCDATES,SCUSRA,SCROLEA,SCLIST,SCERR) --\n
(2) $$PRCL(SC44,SCDATES,SCPOSA,SCUSRA,SCROLEA,SCLIST,SCERR) --\n
(3) $$PRPT(DFN,SCDATES,SCPOSA,SCUSRA,SCROLEA,SCPURPA,SCLIST,SCERR) --
;
(4) $$PTTM(SCTEAM,SCDATES,SCLIST,SCERR) --\n
(5) $$TMPT(DFN,SCDATES,SCPURPA,SCLIST,SCERR) --\n
(6) $$INSTPCTM(DFN,SCEFF) --\n
(7) $$PTPR(SC200,SCDATES,SCPURPA,SCROLEA,SCLIST,SCERR,SCYESCL)--", "", "SCAPMC", ""], ["1917", "PCMM CALLS FOR CPRS/OERR - SCAPMC", "Routine", "SCHEDULING", "1997/02/06", "", "Pending", "Private", "", "
These are the PCMM supported calls in the SCAPMC
routine for Team and Personal Patient lists used by CPRS/OERR which are not
supported elsewhere:\n
ACPRTP^SCAPMC ACPTTM^SCAPMC ACPTTP^SCAPMC ACTM^SCAPMC ACTMNM^SCAPMC
ACTP^SCAPMC ACTPNM^SCAPMC INPTTM^SCAPMC TMAU^SCAPMC TMINST^SCAPMC TMPR^SCAPMC
TPPR^SCAPMC TPTM^SCAPMC", "", "SCAPMC", ""], ["1918", "PCMM CALLS FOR SCAPMCU1", "Routine", "SCHEDULING", "1997/02/06", "APPROVED", "Retired", "Private", "", "
These are the PCMM supported calls in the SCAPMCU1
routine for Team and Personal Patient lists which are not supported elsewhere:\n
DATES^SCAPMCU1 RSNDICS^SCAPMCU1 TEAMCNT^SCAPMCU1\n
ICR was originally created for use by OE/RR. As of 10/11/17, no references to
routine SCAPMCU1 were found in OR* routines. Removed OE/RR as a subscriber.\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "SCAPMCU1", "2017/10/11"], ["1919", "PCMM CALLS FOR CPRS/OERR - SCAPMCU3", "Routine", "SCHEDULING", "1997/02/06", "", "Pending", "Private", "", "
These are the PCMM supported calls in the SCAPMCU3
routine for Team and Personal Patient lists used by CPRS/OERR which are not
supported elsewhere:\n
GETEAM^SCAPMCU3 GETREC^SCAPMCU3 SETREC^SCAPMCU3", "", "SCAPMCU3", ""], ["1920", "PCMM FILE USED BY CPRS/OERR - SCTM(404.51", "File", "SCHEDULING", "1997/02/06", "", "Pending", "Private", "404.51", "
The file SCTM(404.51 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1921", "PCMM FILE USED BY CPRS/OERR - SCTM(404.57", "File", "SCHEDULING", "1997/02/06", "", "Withdrawn", "Private", "404.57", "
The file SCTM(404.57 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.\n
4/24/15-Status changed from Pending to Withdrawn with concurrence from CPRS
team and PCMM representative. No references to this file found in CPRS/OR
code.", "", "", ""], ["1922", "PCMM FILE USED BY CPRS/OERR - SCPT(404.42", "File", "SCHEDULING", "1997/02/06", "", "Pending", "Supported", "404.42", "
The file SCPT(404.42 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1923", "PCMM FILE USED BY CPRS/OERR - SCTM(404.56", "File", "SCHEDULING", "1997/02/06", "", "Pending", "Private", "404.56", "
The file SCTM(404.56 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1924", "PCMM FILE USED BY CPRS/OERR - SCTM(404.52", "File", "SCHEDULING", "1997/02/06", "", "Pending", "Private", "404.52", "
The file SCTM(404.52 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1925", "PCMM FILE USED BY CPRS/OERR - SCTM(404.58", "File", "SCHEDULING", "1997/02/06", "", "Pending", "Private", "404.58", "
The file SCTM(404.58 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1926", "PCMM FILE USED BY CPRS/OERR - SCTM(404.59", "File", "SCHEDULING", "1997/02/06", "", "Pending", "Private", "404.59", "
The file SCTM(404.59 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1927", "Vitals File Access for CPRS/OERR - GMR(120.5", "File", "GEN. MED. REC. - VITALS", "1997/02/07", "", "Pending", "Private", "120.5", "
The file GMR(120.5 is supported by Vitals/Measurements
for use by CPRS/ OERR to return most recent vitals for a patient. The "AA"
x-ref and zero nodes are used.", "", "", ""], ["1928", "Vitals File Access for CPRS/OERR - GMRD(120.51", "File", "GEN. MED. REC. - VITALS", "1997/02/07", "", "Pending", "Private", "120.51", "
The file GMRD(120.51 is supported by
Vitals/Measurements for use by CPRS/ OERR to return most recent vitals for a
patient. The "B" x-ref is used.", "", "", ""], ["1929", "DBIA1929", "File", "AUTO REPLENISHMENT/WARD STOCK", "1997/02/12", "APPROVED", "Active", "Private", "58.1", "
The Controlled Substances routines PSDTRA* need read
access to #58.1 to copy data from an AREA OF USE to a NARCOTIC AREA OF USE.", "", "", ""], ["1930", "DBIA1930", "File", "PHARMACY DATA MANAGEMENT", "1997/02/13", "APPROVED", "Active", "Private", "59.7", "
Controlled Substances needs to check the DATE OP
INSTALLED field before posting outpatient prescriptions and the DATE V2 CS/DA
CONVERSION field before doing a conversion in a post-init.", "", "", ""], ["1931", "DBIA1931", "File", "PHARMACY DATA MANAGEMENT", "1997/02/13", "APPROVED", "Active", "Controlled Subscription", "51.5", "
Various pharmacy packages need read access to this
file.", "", "", ""], ["1932", "DBIA1932", "File", "INCOMPLETE RECORDS TRACKING", "1997/02/13", "APPROVED", "Active", "Controlled Subscription", "393.3", "
This will allow Text Integration Utilities (TIU) to
point to the IRT TYPE OF DEFICIENCY file #393.3.", "", "", ""], ["1933", "DBIA1933", "Other", "HINQ", "1997/02/14", "", "Pending", "Private", "", "
Distribute HINQ input template.", "", "", ""], ["1934", "DBIA1934", "Other", "AUTOMATED MED INFO EXCHANGE", "1997/02/14", "APPROVED", "Active", "Private", "", "
Distribute AMIE input template.", "", "", ""], ["1936", "DBIA1936", "Other", "INTEGRATED BILLING", "1997/02/14", "APPROVED", "Active", "Private", "", "
Distribute IB input template.", "", "", ""], ["1937", "DBIA1937 - EC HL7 INTERFACE", "File", "HEALTH LEVEL SEVEN", "1997/02/18", "APPROVED", "Active", "Private", "771", "
The Event Capture HL7 internal interface will reference
the following data from the HL7 APPLICATION PARAMETER FILE (#771). In File
771, the Event Capture HL7 internal interface will reference the current mail
group from field (#4).", "", "", ""], ["1938", "GMRVSITE", "Routine", "GEN. MED. REC. - VITALS", "1997/02/19", "APPROVED", "Active", "Private", "", "
The Nursing package can use the DEFAULT and CHAR entry
points in the GMRVSITE routine of the Vitals/Measurements package.", "", "GMRVSITE", ""], ["1939", "DBIA1938 - EC HL7 INTERFACE", "File", "HEALTH LEVEL SEVEN", "1997/02/19", "APPROVED", "Active", "Private", "772", "
The Event Capture HL7 internal interface will reference
the following data from the HL7 MESSAGE TEXT FILE (#772). In File 772, the
Event Capture HL7 internal interface will reference information related to the
MSH and MSA segments from the MESSAGE TEXT field (#200).", "", "", ""], ["1940", "GMRVCAQU", "Routine", "GEN. MED. REC. - VITALS", "1997/02/19", "APPROVED", "Active", "Private", "", "
The Nursing package can call EN1^GMRVCAQU in the
Vitals/Measurements package.", "", "GMRVCAQU", ""], ["1941", "SETTING DD NODES", "File", "1", "1997/02/21", "APPROVED", "Active", "Private", "1", "
This integration agreement is for a one time use for
AICS v3.0 to set the following three DD nodes. These nodes point to the
Expressions file (757.01) which has changed global locations in Lexicon
Utility v2.0 from ^GMP to ^LEX. Approximately half of VAMC's have installed
Lexicon Utility v2.0. The setting of these nodes will set the Data
Dictionaries to the correct global location for the version of Lexicon
Utility.\n
I $D(^LEX) D
.S ^DD(357.3,2.02,0)="CLINICAL LEXICON ENTRY^P757.01'^LEX(757.01,^2;2^Q"
.S ^DD(358.3,2.02,0)="CLINICAL LEXICON ENTRY^P757.01'^LEX(757.01,^2;2^Q"
.S ^DD(357.951,2.02,0)="CLINICAL LEXICON^P757.01'^LEX(757.01,^2;2^Q"
.D MES^XPDUTL(">>> AICS Data Dictionaries updated to use Lexicon Utility
version 2.0")
E D MES^XPDUTL(">>> AICS Data Dictionaries updated to use Clinical Lexicon
Utility version 1.0")", "", "", ""], ["1942", "REGISTRATION FILE USED BY CPRS/OERR - DG(40.8", "File", "REGISTRATION", "1997/02/27", "", "Pending", "Private", "40.8", "
CPRS/OERR extracts data from the MEDICAL CENTER
DIVISION FILE [#40.8].", "", "", ""], ["1943", "PCMM FILE USED BY CPRS/OERR - SD(403.44", "File", "SCHEDULING", "1997/02/27", "", "Pending", "Private", "403.44", "
The file SD(403.44 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1944", "PCMM FILE USED BY CPRS/OERR - SD(403.46", "File", "SCHEDULING", "1997/02/27", "", "Pending", "Private", "403.46", "
The file SD(403.46 is supported by PCMM for use by
CPRS/OERR Team and Personal Patient lists.", "", "", ""], ["1945", "DBIA1945", "File", "SCHEDULING", "1997/03/03", "APPROVED", "Active", "Private", "404.51", "
DSS Extracts references the following data from the
TEAM file (#404.51).\n
A DSS option, "Primary Care Team Print", prints an alphabetical list of all
primary care teams and the IEN for each team. The intent of the option is to
provide help for building primary care teams on the commercial DSS system.\n", "", "", ""], ["1946", "DBIA1946", "Routine", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Private", "", "
DSS Extracts uses the Lab Service LRCAPDSS routine.\n
For a date range, the LRCAPDSS routine examines the WKLD DATA file (#64.1) and
stores appropriate data into the WKLD LOG FILE file (#64.03) for use by the
DSS Laboratory Extract.\n
Variables:
LRSDT Input Start Date
LREDT Input End Date\n
Prior to running this routine, the calling routine will purge the WKLD LOG
FILE file (#64.03).", "", "LRCAPDSS", ""], ["1947", "DBIA1947", "File", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Private", "60", "
DSS Extracts references and points to the following
data from the LABORATORY TEST file (#60).\n
DSS accesses the NAME field using a direct global read for the "Print DSS Lab
Test Datasheet" option and for generating DSS lab feeder keys.\n
The DSS Extracts LABORATORY EXTRACT file (#727.813) contains a field, TEST,
and the DSS LAB TESTS file (#727.2) contains a multiple field, LOCAL LAB TEST
NAME, which point to the LABORATORY TEST file (#60).\n
The DSS Lab Results Extract references the NATIONAL VA LAB CODE field.\n", "", "", "2017/08/09"], ["1948", "DBIA1948", "File", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Controlled Subscription", "63", "
DSS Extracts references the following data from the LAB
DATA file (#63).\n
These fields are used in the DSS Lab Extract for the original/old format which
does not use LMIP codes. With the FY'98 release of DSS Extracts, this should
no longer be needed. Therefore, this IA is to be in effect for no more than 3
years, with a sunset clause of 2000.\n", "", "", ""], ["1949", "LAB DSS EXTRACT", "File", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Controlled Subscription", "64", "
DSS Extracts references the following data from the
WKLD CODE file (#64).\n", "", "", "2011/06/06"], ["1950", "DBIA1950", "File", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Private", "64.03", "
DSS Extracts references the following data from the
WKLD LOG FILE file (#64.03). This LABORATORY file has been converted for
exclusive use by DSS software to collect laboratory workload for DSS defined
products.\n
In addition to the direct global read references indicated below, DSS has
complete direct global read and write access into the entire WKLD LOG FILE
file (#64.03). The entire file is KILLed from the system prior to DSS calling
a Lab API which populates file 64.03.", "", "", ""], ["1951", "RECONSTRUCT ACCESSION NODE", "File", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Private", "68", "
DSS Extracts points to and references the following
data from the ACCESSION file (#68).\n
The DSS Extracts LABORATORY EXTRACT file (#727.813) contains a field,
ACCESSION AREA, which is a pointer to the ACCESSION file (#68).\n
Direct global read of the 'B' Cross Reference is also permited into the
ACCESSION file (#68).\n
Blood Bank Data
===============
DSS uses LAB DATA file (#63) and Blood Bank's node ^LR(D0,"BB",D1,0) to
extract blood bank records. We then use ACCESSION NUMBER field (#.06) to
identify ACCESSION file (#68) corresponding entry. This allows us to identify
provider and division associated with patient blood bank record.", "", "", "2007/01/29"], ["1952", "DBIA1952", "File", "LAB SERVICE", "1997/03/04", "", "Retired", "Private", "69", "
DSS Extracts references the following data from the LAB
ORDER ENTRY file (#69).\n
These fields are used in the DSS Lab Extract for the original/old format which
does not use LMIP codes. With the FY'98 release of DSS Extracts, this should
no longer be needed. Therefore, this IA is to be in effect for no more than 3
years, with a sunset clause of 2000.\n", "", "", ""], ["1953", "DBIA1953", "Routine", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Private", "", "
DSS Extracts uses the Lab Service LRCAPDAR routine.\n
For a date range, the LRCAPDAR routine examines the LAB DATA file (#63) and
stores appropriate data into the LAB DSS LAR EXTRACT file (#64.036) for use by
the DSS Laboratory Results Extract.\n
Variables:
LRSDT Input Start Date
LREDT Input End Date Prior to running this
routine, the calling routine will purge the LAB DSS LAR EXTRACT file
(#64.036).", "", "LRCAPDAR", ""], ["1954", "DBIA1954", "File", "LAB SERVICE", "1997/03/04", "APPROVED", "Active", "Private", "64.036", "
DSS Extracts references the following data from the LAB
DSS LAR EXTRACT file (#64.036). This LABORATORY file has been created for
exclusive use by DSS software to collect laboratory clinical data for the DSS
Lab Results Extract.\n
In addition to the direct global read references indicated below, DSS has
complete direct global read and write access into the entire LAB DSS LAR
EXTRACT file (#64.036). The entire file is KILLed from the system prior to
DSS calling a Lab API which populates file 64.036.", "", "", ""], ["1955", "DBIA1955", "File", "DSS - DECISION SUPPORT SYSTEM EXTRACTS", "1997/03/04", "APPROVED", "Active", "Private", "727.2", "
Lab Service references the following data from the DSS
LAB TESTS file (#727.2). This reference is made from the LRCAPDAR routine
written by Lab Service to provide lab clinical results data to DSS.\n", "", "", ""], ["1956", "DBIA1956", "File", "KERNEL", "1997/03/06", "APPROVED", "Active", "Private", "49", "
Supported DBIA #10093 provides FileMan read access to
all fields of the SERVICE/SECTION file (#49). The DSS Surgery Extract uses a
direct global read on the NATIONAL SERVICE field (730) for the purpose of
determining the service to which the attending surgeon is assigned.\n
The technical description follows: ATTENDING'S SERVICE is a pointer to the
NATIONAL SERVICE file (#730). Derived from the SERVICE/SECTION field (29) in
the NEW PERSON file (#200) for the ATTENDING SURGEON field (13) in the SURGERY
EXTRACT file (#727.811) which is a pointer to the SERVICE/SECTION file (#49).
The pointer value identifies the NATIONAL SERVICE field (730) in the
SERVICE/SECTION file (#49) which points to the NATIONAL SERVICE file (#730).\n
Therefore, DSS Extracts references the following data from the SERVICE/SECTION
file (#49).\n", "", "", ""], ["1957", "File Security Codes", "File", "1", "1997/03/10", "APPROVED", "Active", "Private", "1", "
The Gen. Med. Rec. - I/O (Intake and Output), Gen. Med.
Red. - Vitals (Vitals/Measurements), Nursing Service and Text Generator
packages have permission to set the security nodes (i.e., "DD", "RD", "DEL",
"LAYGO", and "WR") in FILE 1 for those files within the package's number
range. For example: S ^DIC(210,0,"DD")="@"\n
Package Number Range
------- ------------
Intake & Output 126-126.95
Vitals/Measurments 120.5-120.57
Nursing Service 210-219.7
Text Generator 124-124.3\n
With the next release of each package, the installation process will allow the
site to change its file security codes to match the codes as they appear in
the documentation. The site can answer YES to change their file security codes
to match the package documentation or NO to leave them as is.", "", "", ""], ["1958", "DBIA1958", "Routine", "LAB SERVICE", "1997/03/19", "APPROVED", "Active", "Supported", "", "
This API will get Lab results for a given patient based
on various input parameters.", "", "LR7OSUM", ""], ["1959", "DBIA1959", "Routine", "LAB SERVICE", "2005/05/24", "", "Retired", "Controlled Subscription", "", "
This agreement is to use routine LRAURPT to produce an
autopsy report for images captured under the Autopsy Lab specialty. At the
present time, there is no supported API for this functionality.\n", "", "LRAURPT", ""], ["1961", "DBIA1961", "File", "PHARMACY DATA MANAGEMENT", "1997/03/20", "", "Retired", "Private", "51.5", "
Drug Accountability v3.0 needs write access to the
ORDER UNIT (51.5) file. A new SYNONYM multiple needs to be written to.", "", "", ""], ["1962", "DBIA1962", "File", "LAB SERVICE", "1997/03/21", "APPROVED", "Active", "Controlled Subscription", "63", "
This request is for referencing/reading and writing the
Image field in the Laboratory Data file 63. Imaging saves Image pointers in
the following sub-field of the Lab Data file: For Autopsy Images:
Lab Data sub-file:
DD(63.2,0) = AUTOPSY ORGAN/TISSUE SUB-FIELD^NL^2005.1^9
sub-fields:
DD(63.2,2005,0) = IMAGE (GROSS)^63.28P^^2005;0
DD(63.2,2005.1,0) = IMAGE (MICROSCOPIC)^63.45P^^2005.1;0\n
For Surgical Pathology Images:
Lab Data sub-file:
DD(63.08,0) = SURGICAL PATHOLOGY SUB-FIELD^NL^2005^38
Sub-field:
DD(63.08,2005,0) = IMAGE^63.82005P^^2005;0\n
For Cytology Images:
Lab Data sub-file:
DD(63.09,0) = CYTOPATHOLOGY SUB-FIELD^NL^2005^34
Sub-field:
DD(63.09,2005,0) = IMAGE^63.92005P^^2005;0\n
For Electron Microcopy
DD(63.02,0) = EM SUB-FIELD^NL^2005^32
Sub-field:
DD(63.02,2005,0) = IMAGE^63.22005P^^2005;0\n
Reading of this file is required to verify the Lab file's references, saved
during image capture, needed for displaying lab reports. Write access is
needed during image capture to save the image pointer in the appropriate Lab
accession area (SP, CY, etc.).", "", "", ""], ["1963", "DBIA1963", "File", "LAB SERVICE", "1997/03/21", "APPROVED", "Active", "Controlled Subscription", "68", "
The purpose of this request is to provide the Imaging
package access to read the Laboratory Accession file for image capture. Image
capture for Radiology will require the person to provide an Accession area,
Accession year and Accession number. These entries are used to verify the
existence of the Lab entry and to display a list of specimens for the
accession number provided.", "", "", ""], ["1964", "GMRYCATH", "Routine", "GEN. MED. REC. - I/O", "1997/03/22", "", "Withdrawn", "Private", "", "
The Nursing Service package has permission to call the
GMRYCATH routine in order to display or print its End of Shift report.", "", "GMRYCATH", ""], ["1965", "GMRYMNT", "Routine", "GEN. MED. REC. - I/O", "1997/03/22", "APPROVED", "Active", "Private", "", "
The Nursing Service package has permission to call the
GMRYMNT routine in order to display or print its End of Shift report.", "", "GMRYMNT", ""], ["1966", "DBIA1966", "File", "MAILMAN", "1997/03/25", "APPROVED", "Active", "Controlled Subscription", "4.2", "", "", "", "2017/02/14"], ["1967", "DBIA1967", "File", "PHARMACY DATA MANAGEMENT", "1997/03/27", "APPROVED", "Active", "Private", "51.5", "\n\n
This data is accessed when a drug is marked for CMOP.", "", "", ""], ["1968", "DBIA1968", "Routine", "OUTPATIENT PHARMACY", "1997/03/27", "APPROVED", "Active", "Private", "", "
In the CMOP routine PSXEDIT, a call is made to
EN1^PSONEW2 to complete the editing of a prescription.", "", "PSONEW2", ""], ["1969", "DBIA1969", "Routine", "OUTPATIENT PHARMACY", "1997/03/27", "APPROVED", "Active", "Private", "", "
The CMOP package calls the Outpatient Pharmacy routine,
PSORXL in order to print prescription labels at the medical center pharmacy.", "", "PSORXL", ""], ["1970", "DBIA1970", "Routine", "OUTPATIENT PHARMACY", "1997/03/27", "APPROVED", "Active", "Private", "", "
The CMOP package makes a call to the Outpatient
Pharmacy routine, PSOSURST in order to reset and print pharmacy labels. This
call is made when the user selects the option to reset and print window
labels. There aren't any I/O variables.", "", "PSOSURST", ""], ["1971", "DBIA1971", "Routine", "OUTPATIENT PHARMACY", "1997/03/27", "APPROVED", "Active", "Private", "", "
The CMOP package makes a call to the Outpatient
Pharmacy routine, PSOSULBL. This call is made from the CMOP routine, PSXRSUS
when the user selects the option to Print Standard Suspense at the medical
center pharmacy. There aren't any I/O variables in this call.", "", "PSOSULBL", ""], ["1972", "DBIA1972", "Routine", "OUTPATIENT PHARMACY", "1997/03/27", "APPROVED", "Active", "Private", "", "
The CMOP package makes a call to the Outpatient
Pharmacy routine, PSOSUCHG. This call is made when a user is using the Change
Suspense Date option on the Suspense Menu for Outpatient Pharmacy. Any Rx that
is entered by the user is screened for CMOP. This screening process is handled
by the CMOP routine, PSXCH. Once the screening is finished PSXCH calls
PSOSUCHG to complete the processing.", "", "PSOSUCHG", ""], ["1973", "DBIA1973", "Routine", "OUTPATIENT PHARMACY", "1997/03/27", "APPROVED", "Active", "Controlled Subscription", "", "
The CMOP package makes a call to the Outpatient
Pharmacy routine, PSOLSET. This call is made to set up the required OP system
variables that are necessary for pulling Rx's from suspense during the CMOP
transmission process or when CMOP labels are printed at the medical center
pharmacy.", "", "PSOLSET", ""], ["1974", "DBIA1974", "Routine", "OUTPATIENT PHARMACY", "1997/03/27", "APPROVED", "Active", "Private", "", "
The CMOP package makes a call to the Outpatient
Pharmacy routine, PSOCP. This call is made when the CMOP process is filing
the release data that is returned by the CMOP facility. The call is made in
order to generate any copay charges for the Rx.", "", "PSOCP", ""], ["1975", "DBIA1975", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "53", "
This agreement will be retired on 12/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSO*7*213. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["1976", "DBIA1976", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "59", "
The subscribing pharmacy packages are allowed direct
global read access to all fields and cross-references of file #59.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["1977", "DBIA1977", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "52", "
The CMOP package requires direct R/W access to all
fields and cross-references in file 52.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["1978", "DBIA1978", "File", "OUTPATIENT PHARMACY", "1997/03/28", "APPROVED", "Active", "Private", "52.5", "
The CMOP package requires direct R/W access to all
fields and cross-references in file 52.5.", "", "", ""], ["1979", "DBIA1979", "File", "PHARMACY DATA MANAGEMENT", "1997/03/28", "APPROVED", "Active", "Private", "54", "
The Consolidated Mail Outpatient Pharmacy package has
modified the input transform for the .01 field in the RX CONSULT file (#54).
This modification will prevent the first 20 entries in the file from being
edited. This is necessary to provide uniformity in the drug warnings that are
transmitted to the CMOP with each prescription. The drug warnings are passed
by their record number in the RX CONSULT file from the hospital to the CMOP
facility and then on to the vendor system. These numbers must match between
all the medical centers using the CMOP software, the CMOP Facility, and the
vendor system, or the incorrect drug warning could be printed on the
prescription label.\n
The modified input transform is shown below:\n
^DD("54",".01","0")="NAME^RFX^^0;1^K:$L(X)>25!($L(X)<1)!"(X"?1P.E)!(($G(DA
)>0)&($G(DA)<21)) X"", "", "", ""], ["1980", "DBIA1980", "File", "PHARMACY DATA MANAGEMENT", "1997/03/28", "APPROVED", "Active", "Controlled Subscription", "51", "
The Consolidated Mail Outpatient Pharmacy package
accesses the 'A' cross reference in the MEDICATION INSTRUCTION file (#51).
This cross reference used to expand the SIG in order to send this data with
the prescription when it is transmitted to the CMOP facility to be filled. The
CMOP package only reads the data in this cross reference.", "", "", ""], ["1981", "DBIA1981", "File", "PHARMACY DATA MANAGEMENT", "1997/03/28", "", "Retired", "Private", "59.7", "", "", "", ""], ["1982", "DBIA1982", "File", "PHARMACY DATA MANAGEMENT", "1997/03/28", "", "Retired", "Private", "55", "", "", "", ""], ["1983", "DBIA1983", "File", "PHARMACY DATA MANAGEMENT", "1997/03/28", "APPROVED", "Active", "Private", "50", "
The CMOP package requires direct R/W access to all
fields and cross-references in file 50.", "", "", ""], ["1984", "FILE 452.6", "File", "EDUCATION TRACKING", "1997/03/29", "", "Pending", "Private", "452.6", "
The Nursing Service package has permission to do a
global read of the zero node of the PRSE SVC REASONS FOR TRAINING file
(#452.6) and to print the first piece of that node (i.e., REASON FOR EMPLOYEE
TRAINING) for its Nursing personnel education reports.", "", "", ""], ["1985", "DBIA1985", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/04/02", "APPROVED", "Active", "Controlled Subscription", "", "
This IA supports calls into the following linetags
within routine PXAPIIB:\n
$$DSPLYED^PXAPIIB <--Education
$$DSPLYEX^PXAPIIB <--Examinations
$$DSPLYHF^PXAPIIB <--Health Factors
$$DSPLYIM^PXAPIIB <--Immunizations
$$DSPLYSK^PXAPIIB <--Skin Tests
$$POV^PXAPIIB <-Purpose of Visit", "", "PXAPIIB", ""], ["1986", "EXECUTE DD NODES OF File 391.71 Cross-references", "File", "1", "1997/05/07", "APPROVED", "Active", "Controlled Subscription", "391.71", "\n
A cross-reference on a field in the Patient file #2 creates an
entry in ADT/HL7 PIVOT file #391.71 and/or sets the cross-references
in file #391 by executing the ^DD cross-reference nodes.\n\n
^DD(2,.01,1,991,0) = 2^AVAFC01^MUMPS ^DD(2,.02,1,991,0) = 2^AVAFC02^MUMPS
^DD(2,.03,1,991,0) = 2^AVAFC03^MUMPS ^DD(2,.05,1,991,0) = 2^AVAFC05^MUMPS
^DD(2,.08,1,991,0) = 2^AVAFC08^MUMPS ^DD(2,.09,1,991,0) = 2^AVAFC09^MUMPS
^DD(2,.111,1,991,0) = 2^AVAFC111^MUMPS ^DD(2,.1112,1,991,0) =
2^AVAFC1112^MUMPS ^DD(2,.112,1,991,0) = 2^AVAFC112^MUMPS ^DD(2,.113,1,991,0) =
2^AVAFC113^MUMPS ^DD(2,.114,1,991,0) = 2^AVAFC114^MUMPS ^DD(2,.115,1,991,0) =
2^AVAFC115^MUMPS ^DD(2,.117,1,991,0) = 2^AVAFC117^MUMPS ^DD(2,.131,1,991,0) =
2^AVAFC131^MUMPS ^DD(2,.132,1,991,0) = 2^AVAFC132^MUMPS ^DD(2,.211,1,991,0) =
2^AVAFC211^MUMPS ^DD(2,.219,1,991,0) = 2^AVAFC219^MUMPS ^DD(2,.2403,1,991,0) =
2^AVAFC2403^MUMPS ^DD(2,.301,1,991,0) = 2^AVAFC301^MUMPS ^DD(2,.302,1,991,0) =
2^AVAFC302^MUMPS ^DD(2,.31115,1,991,0) = 2^AVAFC31115^MUMPS
^DD(2,.323,1,991,0) = 2^AVAFC323^MUMPS ^DD(2,.351,1,991,0) = 2^AVAFC351^MUMPS
^DD(2,391,1,991,0) = 2^AVAFC391^MUMPS ^DD(2,1901,1,991,0) = 2^AVAFC1901^MUMPS
Global ^DD(2,1901,1,991
DD(2,1901,1,991 ^DD(2,1901,1,991,0) = 2^AVAFC1901^MUMPS
^DD(2,1901,1,991,1) = D:($T(AVAFC^VAFCDD01)'="") AVAFC^VAFCDD01(DA)
^DD(2,1901,1,991,2) = D:($T(AVAFC^VAFCDD01)'="") AVAFC^VAFCDD01(DA)\n\n
^DD(391.71,.06,1,1,0) = 391.71^AC^MUMPS ^DD(391.71,.08,1,1,0) =
391.71^AXMIT2^MUMPS\n\n
^DD(391.71,.06,0) = TRANSMITTED^S^1:NEED TO TRANSMIT;^0;6^Q
^DD(391.71,.06,1,0) = ^.1 ^DD(391.71,.06,1,1,0) = 391.71^AC^MUMPS
^DD(391.71,.06,1,1,1) = S:+X ^VAT(391.71,"AC",$E(X,1,30),DA)=""
^DD(391.71,.06,1,1,2) = K ^VAT(391.71,"AC",$E(X,1,30),DA)\n
^DD(391.71,.08,0) = REQUIRES TRANSMISSION^S^0:NO;1:YES;^0;8^Q
^DD(391.71,.08,.1) = Requires Transmission ^DD(391.71,.08,1,0) = ^.1
^DD(391.71,.08,1,1,0) = 391.71^AXMIT2^MUMPS ^DD(391.71,.08,1,1,1) =
Q:(($G(VAFCA08))!('X)) N A
S A=$P(^VAT(391.71,DA,0),"^",4) S:(+A) ^VAT(391.71,"AXMIT",A,DA)=""
^DD(391.71,.08,1,1,2) = N A S A=$P(^VAT(391.71,DA,0),"^",4)
K:(+A) ^VAT(391.71,"AXMIT",A,DA)\n", "", "", ""], ["1987", "DBIA1987", "File", "PCE PATIENT CARE ENCOUNTER", "1997/04/04", "APPROVED", "Active", "Controlled Subscription", "9999999.09", "
This integration agreement authorizes global reference
to the zeroith node of the following file for purposes of retrieving the name
and inactive flag:\n
^AUTTEDT(#,0) piece 1 and piece 3\n
... and to the "B" cross-reference", "", "", ""], ["1988", "DBIA1988", "File", "PCE PATIENT CARE ENCOUNTER", "1997/04/04", "APPROVED", "Active", "Controlled Subscription", "9999999.15", "
This integration agreement authorizes global reference
to the zeroith node of the following file for purposes of retrieving the name
and inactive flag:\n
^AUTTEXAM(#,0) piece 1 and piece 4\n
... and to the "B" cross-reference", "", "", ""], ["1989", "DBIA1989", "File", "PCE PATIENT CARE ENCOUNTER", "1997/04/04", "APPROVED", "Active", "Controlled Subscription", "9999999.64", "
This integration agreement authorizes global reference
to the zeroth node of the following file for purposes of retrieving the name
and inactive flag:\n
^AUTTHF(#,0) piece 1 and piece 11\n
... and to the "B" cross-reference", "", "", ""], ["1990", "DBIA1990", "File", "PCE PATIENT CARE ENCOUNTER", "1997/04/04", "APPROVED", "Active", "Controlled Subscription", "9999999.14", "
This integration agreement authorizes global reference
to the zeroith node of the following file for purposes of retrieving the name
and inactive flag:\n
^AUTTIMM(#,0) piece 1 and piece 7\n
... and to the "B" cross-reference", "", "", "2021/11/16"], ["1991", "DBIA1991", "File", "PCE PATIENT CARE ENCOUNTER", "1997/04/04", "APPROVED", "Active", "Controlled Subscription", "9999999.28", "
This integration agreement authorizes global reference
to the zeroith node of the following file for purposes of retrieving the name
and inactive flag:\n
^AUTTSK(#,0) piece 1 and piece 3\n
... and to the "B" cross-reference", "", "", ""], ["1992", "DBIA1992", "File", "INTEGRATED BILLING", "1997/04/04", "APPROVED", "Active", "Controlled Subscription", "399", "
This ingegration agreement allows access to the
following global nodes within file 399:\n
^DGCR(399,"AOPV" use of the AOPV cross-reference for look-up
^DGCR(399,#,0)
^DGCR(399,#,"S")
^DGCR(399,#,"U1")
^DGCR(399,#,"OP",0)", "", "", ""], ["1993", "DBIA1993", "Routine", "SCHEDULING", "1997/04/08", "", "Retired", "Private", "", "
This is a one-time only DBIA with Scheduling to allow
the CPT v.6.0 package update to revise routines SDAMBAE2 and SDAMBAE3 to
eliminate references to files 409.72 and 409.71, which will no longer be
maintained.\n
In addition, the EFFECTIVE DATE will now be referenced by API, and not be
hard-coded into these routines.", "", "SDAMBAE3", ""], ["1994", "DBIA1994", "Routine", "PCE PATIENT CARE ENCOUNTER", "1997/04/08", "APPROVED", "Active", "Private", "", "
This is a one-time only DBIA with PCE to allow the CPT
v.6.0 package update to revise routine PXBUTL to eliminate references to files
409.72, which will no longer be maintained. These references have been
replaced by supported calls to supported APIs.", "", "PXBUTL", ""], ["1995", "CPT Code APIs", "Routine", "CPT/HCPCS CODES", "1997/04/08", "APPROVED", "Active", "Supported", "", "
This contains the supported references to routine
ICPTCOD for the supported APIs to be released with v.6.0 of CPT.\n
These entry points will retrieve CPT/HCPCS code related data.\n
All entry points will return
-1^error description in an error condition.", "", "ICPTCOD", ""], ["1996", "CPT/HCPCS Modifier APIs", "Routine", "CPT/HCPCS CODES", "1997/04/08", "APPROVED", "Active", "Supported", "", "
This contains the supported references to routine
ICPTMOD for the supported APIs. These entry points will retrieve CPT MODIFIER
related data. All entry points will return '-1^error description' in an error
condition.", "", "ICPTMOD", "2008/09/18"], ["1997", "CPT Utility APIs", "Routine", "CPT/HCPCS CODES", "1997/04/08", "APPROVED", "Active", "Supported", "", "
Routine contains supported calls for the CPT package.
These include an extrinsic variable, which returns the Distribution Date, an
extrinsic function that returns the category name for a category ien,
functions to perform Status Checks on codes, to retrieve the Next or Previous
code, and to retrieve the History of code activation/inactivation.\n
Both entry points will return
-1^error description in an error condition.\n
Another entry point will display the CPT SIGNON COPYRIGHT MESSAGE to the
calling device.", "", "ICPTAPIU", "2008/09/18"], ["1998", "DBIA1998", "Routine", "OUTPATIENT PHARMACY", "1997/04/09", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows a call in to routine
PSODACT and line tag ENSTUFF for purposes of printing the Drug Use Evaluations
(DUE).", "", "PSODACT", ""], ["1999", "DBIA1999", "File", "CLINICAL PROCEDURES", "2003/10/20", "", "Retired", "Private", "690", "
By providing read access to file 690, the Medical
Patient file, offer the user a list of existing medicine procedures to apphend
Images to.\n
For a list of patient procedures Imaging reads:
^MCAR(690,"AC",DFN,Inverted FM Date/Time,File #)\n
This IA will be modified as Medicine APIs are released to replace its
functions. Imaging and Medicine will participate actively in the testing
process to be sure API's meet Imaging's needs. Imaging will migrate to the
use of API's as soon as possible.", "", "", ""], ["2000", "DBIA2000", "File", "CLINICAL PROCEDURES", "2003/10/20", "", "Retired", "Private", "697.2", "", "", "", ""], ["2001", "DBIA2001", "File", "CLINICAL PROCEDURES", "2003/10/20", "", "Withdrawn", "Private", "691", "
For the purpose of appending an Image to an existing
Medicine procedure or placing an Image into a new Medicine Procedure
read/write access is require for ECHOCARDIOGRAPHY. FILE^DICN is used to
create a new file 691 entry, when necessary. The IMAGE multiple, field 2005,
is processed by direct global read/writes.\n
This IA will be modified as Medicine APIs are released to replace its
functions. Imaging and Medicine will participate actively in the testing
process to be sure API's meet Imaging's needs. Imaging will migrate to the
use of API's as soon as possible.", "", "", ""], ["2002", "DBIA2002", "File", "CLINICAL PROCEDURES", "1997/04/10", "", "Withdrawn", "Private", "691.1", "
For the purpose of appending an Image to an existing
Medicine procedure or placing an Image into a new Medicine Procedure
read/write access is require for CARDIAC CATHETERIZATION. FILE^DICN is used to
create a new file 691.1 entry,when necessary. The IMAGE multiple, field 2005,
is processed by direct global read/writes.", "", "", ""], ["2003", "DBIA2003", "File", "CLINICAL PROCEDURES", "1997/04/11", "", "Withdrawn", "Private", "691.5", "
For the purpose of appending an Image to an existing
Medicine procedure or placing an Image into a new Medicine Procedure
read/write access is require for ELECTROCARDIOGRAM. FILE^DICN is used to
create a new file 691.5 entry,when necessary. The IMAGE multiple, field 2005,
is processed by direct global read/writes.", "", "", ""], ["2004", "DBIA2004", "File", "CLINICAL PROCEDURES", "1997/04/11", "", "Withdrawn", "Private", "694", "
For the purpose of appending an Image to an existing
Medicine procedure or placing an Image into a new Medicine Procedure
read/write access is require for HEMATOLOGY. FILE^DICN is used to create a new
file 694 entry, when neccessary.
The IMAGE multiple, field 2005, is processed by direct global read/writes.", "", "", ""], ["2005", "DBIA2005", "Routine", "IFCAP", "1997/04/15", "APPROVED", "Active", "Supported", "", "
Integrated Funds of Patient routines PRPFPURG and
PRPFSCV2 are invoking an IFCAP programming call ADD^PRCGPM1.", "", "PRCGPM1", ""], ["2006", "DBIA2006", "File", "CLINICAL PROCEDURES", "1997/04/11", "", "Withdrawn", "Private", "699", "
For the purpose of appending an Image to an existing
Medicine procedure or placing an Image into a new Medicine Procedure
read/write access is require for ENDOSCOPY/CONSULT. FILE^DICN is used to
create a new file 699 entry,when necessary. The IMAGE multiple, field 2005, is
processed by direct global read/writes.", "", "", ""], ["2007", "DBIA2007", "File", "CLINICAL PROCEDURES", "1997/04/11", "", "Withdrawn", "Private", "699.5", "
For the purpose of appending an Image to an existing
Medicine procedure or placing an Image into a new Medicine Procedure
read/write access is require for GENERALIZED PROCEDURE/CONSULT. FILE^DICN is
used to create a new file 699.5 entry, when nessary. The IMAGE multiple, field
2005, is processed by direct global read/writes.", "", "", ""], ["2008", "DBIA2008", "File", "CLINICAL PROCEDURES", "1997/04/11", "", "Withdrawn", "Private", "701", "
For the purpose of appending an Image to an existing
Medicine procedure or placing an Image into a new Medicine Procedure
read/write access is require for RHEUMATOLOGY. FILE^DICN is used to create a
new file 701 entry, when necessary. The IMAGE multiple, field 2005, is
processed by direct global read/writes.", "", "", ""], ["2009", "DBIA2009", "Routine", "CLINICAL PROCEDURES", "2003/10/20", "", "Retired", "Private", "", "
This supported reference allows the Imaging package
user to view a medicine package textual report which is linked to the image.", "", "MCMAGDSP", ""], ["2010", "DBIA2010", "File", "REGISTRATION", "1997/04/15", "APPROVED", "Active", "Private", "38.5", "
This agreement will be used to allow Integrated Billing
access to all recorded patient record inconsistencies which are located in the
INCONSISTENT DATA (#38.5) file.", "", "", ""], ["2011", "DBIA2011", "File", "REGISTRATION", "1997/04/15", "APPROVED", "Active", "Private", "38.6", "
This agreement will be used to allow access for
Integrated Billing to the table values in the INCONSISTENT DATA ELEMENTS
(#38.6) file for all patient record inconsistencies.", "", "", ""], ["2012", "Rad/Nuc Med non-cancelled exam list by patient", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1997/04/15", "APPROVED", "Active", "Controlled Subscription", "", "
EN2^RAO7PC1 can be used to retrieve a list, by patient,
of Radiology/Nuclear Medicine non-cancelled exams within the last seven days.", "", "RAO7PC1", ""], ["2013", "DBIA2013", "File", "KERNEL", "1997/04/16", "APPROVED", "Active", "Private", "101", "
HL7 1.6 needs permission to export new field, ROUTING
LOGIC, with Protocol File (101) as part of the CIRN patch HL*1.6*14.", "", "", ""], ["2015", "DBIA2015", "File", "PHARMACY DATA MANAGEMENT", "1997/04/29", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
The Immunology Case Registry package (ICR) extracts Outpatient Pharmacy data
to the National registry for the tracking of disease categories such as HIV
and Renal Failure. The ICR SITE PARAMETERS file (#158.9) contains two fields,
ENTRY IN DRUG FILE and NDF ENTRY, which is a pointer to the Drug file (#50)
and NATIONAL DRUG FILE ENTRY field (#20). In order to consolidate local drug
names with the National Drug File name for reporting purposes in the national
registry, the Immunology Case Registry package requests a DBIA to point to the
following file.\n\n
Global: ^PSDRUG( Drug File #50 Field
: .01 GENERIC NAME 0;1 DIRECT GLOBAL READ
20 NATIONAL DRUG FILE ENTRY ND;1 DIRECT GLOBAL READ", "", "", ""], ["2016", "DBIA2016", "File", "NATIONAL DRUG FILE", "1997/04/29", "", "Retired", "Private", "50.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
Amended october 28, 1997.\n
The Immunology Case Registry package (ICR) requests a DBIA to reference the
following data in the National Drug file (#50.6).\n
Global: ^PSNDF( National Drug file (#50.6) Field: .01 VA
GENERIC NAME DIRECT GLOBAL READ\n
Also, the NDF ENTRY field of the ICR SITE PARAMETERS file (#158.9) may point
to the National Drug file.", "", "", ""], ["2017", "DBIA2017", "Routine", "CLINICAL PROCEDURES", "1997/04/30", "", "Pending", "Private", "", "
This DBIA implements two new Medicine APIs for the
Imaging package to call.\n
The UPDATE^MCUIMAG0() API creates new entries, if needed, in the Medical
Patient file and the Medicine Procedure data files. It also allows the
Imaging package to populate the Image multiple in the Medicine Procedure data
files.\n
The KILL^MCUIMAG0() API removes entries from the Image multiples in the
Medicine Procedure data files.", "", "MCUIMAGO", ""], ["2018", "Determining RPC Broker context", "Other", "RPC BROKER", "2003/10/28", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement is temporary. The Kernel
RPC Broker is going to publish a standard method that will replace this
agreement. Subscribing packages should be prepared to use that standard
method within three months of its availability, or within a time frame
negotiated and approved by the Kernel RPC Broker.\n
This agreement allows packages to check for the existence of the variable
XWBOS to determine if the current routine execution was called from an RPC
Broker context. This is needed to control user interface actions that are
dependent on whether they are roll-and-scroll based or GUI based.", "", "", ""], ["2019", "DBIA2019", "Routine", "DIETETICS", "1997/05/13", "APPROVED", "Active", "Private", "", "
Inpatient Medications needs data from the Dietetics
System package which can not be extracted from any file. The data returns
from CUR^FHORD7 call will be used to display on the Inpatient Medications'
MAR.", "", "FHORD7", ""], ["2020", "DBIA2020", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
A direct reference to the Prescription file is
requested for the Unit Price of Drug field so the VA Cost of a prescription
fill can be calculated and billed.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2021", "FileMan Replace/With Editor Call", "Routine", "1", "1997/05/16", "APPROVED", "Active", "Private", "", "
This IA permits Capacity Management utilities to call
the FileMan Replace/With Editor entry point at RW^DIR2.", "", "DIR2", ""], ["2022", "RECOMPILATION OF INPUT TEMPLATES", "File", "1", "1997/05/19", "APPROVED", "Active", "Controlled Subscription", ".402", "
When installing a patch that includes changes to field
definitions in a data dictionary, KIDS does not recompile the compiled input
templates. This integration agreement covers recompilation of input
templates.\n
Recompilation of input templates may involve the following steps:\n
(1) Traverse the "AF" cross-reference of the ^DIE global (file
#.402) to obtain a list of compiled input templates for the
affected fields. The structure of this cross-reference is
^DIE("AF",file,field,template)=""\n
Subfields would be treated like fields of their respective
subfiles, i.e. ^DIE("AF",subfile,subfield,template)="".\n
(2) For each template that is being recompiled, access
^DIE(template,"ROU") to determine the compiled routine.\n
(3) Invoke EN^DIEZ to recompile that input template.", "", "", ""], ["2023", "DBIA2023", "Other", "1", "1997/05/19", "APPROVED", "Active", "Private", "", "
PCE Patient Care Encounter and Visit Tracking is
requesting permission to look at the following nodes of the Data Dictionary.\n
1) ^DD(FILE,0,"PT",FILE,FIELD) ;Pointer Nodes 2) ^DD(FILE,FIELD,1,SUB,0)
;Zero node of the Cross-reference Multiple 3) ^DD(FILE,FIELD,1,SUB,1) ;Set
logic of the Cross-reference\n
This will allow us to check for any FILE and FIELD that is pointing to the
VISIT file #9000010 to make sure that a BROKEN pointer will not be created if
an entry in the VISIT file is deleted by way of PCE OR VISIT TRACKING. It
will also allow us to write reports to show who is pointing to a particular
VISIT at times when it is necessary to Debug the Visit File Data Base.\n", "", "", ""], ["2024", "DBIA2024", "Routine", "ACCOUNTS RECEIVABLE", "1997/05/20", "APPROVED", "Active", "Private", "", "
We are making a call to BN1^PRCAFN to return the AR
bill number regardless of the type of bill.", "", "PRCAFN", ""], ["2025", "DBIA2025", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
This will return the External Value of the Outpatient
Classification from file 209.41", "", "SDCODD", ""], ["2026", "SDPCE", "Routine", "SCHEDULING", "2003/04/03", "APPROVED", "Active", "Private", "", "
This DBIA will permit PCE to use exiting Scheduling
function calls to get Eligibility, Appointment Type, and Status of an
encounter.\n", "", "SDPCE", "2003/04/03"], ["2027", "DBIA2027 EDUCATION TOPICS", "File", "INDIAN HEALTH SERVICE", "1997/05/28", "APPROVED", "Active", "Private", "9999999.09", "
The PCE Patient Care Encounter Package requests a DBIA
to distribute the Indian Health Services EDUCATION TOPICS file (9999999.09) in
the VA.", "", "", ""], ["2028", "READ ACCESS ONLY TO PCE VISIT FILE", "File", "PCE PATIENT CARE ENCOUNTER", "1997/05/28", "APPROVED", "Active", "Controlled Subscription", "9000010", "
Visit Tracking grants PCE Patient Care Encounter Global
and/or FileMan Read to the Visit file: all fields and all cross references.", "", "", ""], ["2029", "DBIA2029", "Routine", "OUTPATIENT PHARMACY", "1997/06/02", "APPROVED", "Active", "Private", "", "
Integrated Billing requests permission to call three
entry points in the Outpatient Pharmacy routine PSOCPTRI. This routine
contains the interface points between IB and Pharmacy which are needed to
support the real-time billing of Tricare prescriptions using a commercial
pharmacy billing software package.", "", "PSOCPTRI", ""], ["2030", "DBIA2030", "Routine", "INTEGRATED BILLING", "1997/06/03", "APPROVED", "Active", "Private", "", "
Outpatient Pharmacy requests permission to call two
entry points in the Integrated Billing routine IBACUS. This routine contains
the interface points between Outpatient Pharmacy and Integrated Billing which
are needed to support the real-time billing of Tricare prescriptions using a
commercial pharmacy billing software package.", "", "IBACUS", ""], ["2031", "DBIA2031", "Routine", "INTEGRATED BILLING", "1997/06/04", "APPROVED", "Active", "Private", "", "
This is needed to get information about the type of
charges on the receivables from integrated billing.", "", "IBRFN", "2010/12/13"], ["2032", "DELETE C XREF", "File", "1", "1997/06/10", "APPROVED", "Active", "Controlled Subscription", "3.9", "
Subj: Request for DBIA [#24183795] 09 Jun 97 11:11 10
Lines\n
For MailMan patch XM*7.1*40,\n
Request DBIA to delete "C" xref on field 1 (LAST RESPONSE READ) of RECIPIENT
multiple of MESSAGE file.\n
The following code to be included in a pre-init routine:\n
K ^DD(3.91,1,1) K ^DD(3.91,0,"IX","C") K ^DD(3.91,"IX",1)", "", "", ""], ["2033", "DBA2033", "Routine", "SURGERY", "1997/06/13", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this agreement is to provide access to
the Surgery package (custodian) by the Imaging package (subscriber) for obtain
a surgical case listing to append images to. Requesting permission to use the
Surgery API, GET^SROGTSR, for listing surgical cases.", "", "SROGTSR", ""], ["2034", "DBIA2034", "Routine", "INTEGRATED BILLING", "1997/06/16", "APPROVED", "Active", "Supported", "", "
This supported reference allows packages to retrieve
Sponsor information which is associated with a patient. The sponsors are the
people who are responsible for the patient's Tricare or CHAMPVA medical
benefits coverage.", "", "IBCNSU4", ""], ["2035", "DBIA2035", "Routine", "INTEGRATED BILLING", "1997/06/04", "APPROVED", "Active", "Private", "", "
This is needed to allow the user to be alerted that
there is another payer for a receivable for co-ordination of benefits
purposes.", "", "IBCNSBL2", ""], ["2036", "DD GLOBAL", "File", "1", "1997/06/06", "APPROVED", "Active", "Private", "0", "
The Visit Tracking package have been granted permission
to access the DD global as defined in this DBIA.", "", "", ""], ["2037", "DBIA2037", "Routine", "INTEGRATED BILLING", "2003/04/21", "APPROVED", "Active", "Private", "", "
This DBIA provides an entry point which may be invoked
by a calling application to initiate an interactive session which will allow
the user to add new sponsors or edit existing sponsors, and to relate a
sponsor to a patient.", "", "IBCNSU41", ""], ["2038", "DBIA2038", "File", "ORDER ENTRY/RESULTS REPORTING", "1997/06/17", "APPROVED", "Active", "Private", "100", "
This is a one-time request for Consults/Request
Tracking Patch GMRC*2.5*13 to correct the pointer field 'CURRENT
AGENT/PROVIDER' within the OE/RR Package file, ORDERS #100. This field was
incorrectly populated by the Consults/Request package with a Variable Pointer,
the Consults patch #13 will replace the incorrect pointer with its
Non-Variable equivalent.\n
The correction occurs at the time of the patch install and will only be
executed that one time.", "", "", ""], ["2039", "MEDICINE UPDATE API", "Routine", "CLINICAL PROCEDURES", "1997/06/24", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point creates new entries, if needed, in the
Medical Patient file (#690) and the Medicine Procedure data files (see file
list under MCD0). It also allows the Imaging package to populate the Image
multiple in the Medicine Procedure data files.", "", "MCUIMAG0", ""], ["2040", "MEDICINE KILL API", "Routine", "CLINICAL PROCEDURES", "1997/06/24", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
This entry point removes entries from the Image multiples in the Medicine
Procedure data files.", "", "MCUIMAG0", ""], ["2041", "DB2041", "Routine", "REGISTRATION", "1997/06/25", "APPROVED", "Active", "Controlled Subscription", "", "
Used to display the Patient Profile report via a
"silent call".", "", "DGRPD", ""], ["2042", "DG Patient Sensitivity", "Routine", "REGISTRATION", "1997/06/26", "", "Withdrawn", "Private", "", "
In order to provide a method of maintaining sensitive
patient protocol through a remote procedure call (RPC), Imaging has copied and
modified the code for DGSEC and placed it in MAGGTPTS.", "", "MAGGTPTS", ""], ["2043", "DBIA2043", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1997/06/27", "APPROVED", "Active", "Supported", "", "
EN1^RAO7PC1 can be used to return a list of a patient's
Rad/Nuc Med procedures and related information. Cancelled exams may be
included, depending upon the RACINC input parameter. Exam ID output can be
used as input to another API to retrieve result reports. (See DBIA #2265)
Report ien output can also be used to retrieve a report. (See DBIA #1177)", "", "RAO7PC1", ""], ["2045", "DBIA2045", "File", "SCHEDULING", "1997/06/30", "APPROVED", "Active", "Controlled Subscription", "409.68", "
This will permit the direct reads using the "AVSIT"
cross reference of the OUTPATIENT ENCOUNTER file (#409.68). This will be used
to find an encounter associated with a specific visit from the VISIT file
(#9000010), or determine that no entry exists for a visit in the OUTPATIENT
ENCOUNTER file.\n
Once the "AVSIT" cross-reference has been used to determine if an entry
exists, the entry will be viewed, using VA FileMan, to check the STATUS field
(#.12)", "", "", "2018/10/26"], ["2046", "DBIA2046", "File", "SCHEDULING", "1997/06/30", "", "Retired", "Private", "409.44", "
This will allow the user to use the "OE"
cross-reference to obtain the ifn of a record, in order to find the value of
the PROVIDER (.01) field in the OUTPATIENT PROVIDER file (#409.44).", "", "", ""], ["2047", "DBIA2047", "File", "SCHEDULING", "1997/06/30", "", "Retired", "Controlled Subscription", "409.43", "
This will allow the user to use the "OE"
cross-reference to obtain the ifn of a record, in order to find the values of
the DIAGNOSIS (.01) and the DIAGNOSIS RANKING (.03) fields in the OUTPATIENT
DIAGNOSIS file (#409.43).", "", "", ""], ["2048", "DBIA2048", "File", "PCE PATIENT CARE ENCOUNTER", "1997/06/30", "APPROVED", "Active", "Private", "9000010.18", "
This will allow the user to use the "AD"
cross-reference to obtain the ifn of a record using the VISIT number, in order
to find the value of the CPT(.01) and ENCOUNTER PROVIDER (1204) fields in the
V CPT file (#9000010.18).", "", "", ""], ["2049", "LABORATORY DPT REFERRAL POINTER", "File", "REGISTRATION", "1997/06/30", "APPROVED", "Active", "Private", "2", "
Laboratory Electronic Date Interchange (LEDI) software
is used to accept electronic orders from and send electronic results to other
Laboratory Information Systems (LIS). The LEDI specimen accessioning procedure
has been redesigned to limit or eliminate the user's clerical patient
demographic data entry. This is achieved by adding an enhancement to the
existing FileMan patient lookup.\n
All LEDI patients are accessioned into the Referral File (#67). Adding
patients to this file requires the entry of Name, DOB, PID and Sex. The
clerical step of entering patient's demographic data is done by the
accessioning software.\n
If the FileMan lookup on the ^DPT( file is successful, a pointer is to be
placed in the Patient ^DPT( file pointing to corresponding Referral entry.
This pointer servers as a positive link identifier for future reference.\n
This new pointer serves the same purpose as the existing field in the PATIENT
FILE, LABORATORY REFERENCE (#63) except the new field will point to the
Referral File (#67).\n
Patient (#2) File ^DD(2,67,0)=LAB REFERRAL REF^P67'X^LRT(67,^LRT(;1^K X
NUMBER:67 LABEL: LAB REFERRAL REF
SPECIFIER: P67'X POINTER: LRT(67,
GLOBAL SUBSCRIPT LOCATION: LRT;1 INPUT TRANSFORM: K X
DESCRIPTION: This field contains the pointer reference to the Referral file
of the Laboratory Package. This field is set by the laboratory accessioning
software and should not be edited.\n
Changing of this pointer will result in misidentification of patients that
could have dire medical repercussions.\n
This DBA is requesting the permission for establishment of this field within
the Patient File and permission to set and read this field directly.", "", "", ""], ["2050", "Database Server (DBS) API: DIALOG Utilities", "Routine", "1", "1997/07/02", "APPROVED", "Active", "Supported", "", "
DIALOG file utilities.\n
BLD: DIALOG Extractor $$EZBLD: DIALOG Extractor (Single Line) MSG: Output
Generator", "", "DIALOG", ""], ["2051", "Database Server API: Lookup Utilities", "Routine", "1", "1997/07/02", "APPROVED", "Active", "Supported", "", "
Lookup utilities.\n
FIND: Finder $$FIND1: Finder (Single Record) LIST: Lister", "", "DIC", ""], ["2052", "Database Server API: Data Dictionary Utilities", "Routine", "1", "1997/07/02", "APPROVED", "Active", "Supported", "", "
Data dictionary utilities.\n
FIELD: DD Field Retriever FIELDLST: DD Field List Retriever FILE: DD File
Retriever FILELST: DD File List Retriever $$GET1: Attribute Retriever", "", "DID", ""], ["2053", "Data Base Server API: Editing Utilities", "Routine", "1", "1997/07/02", "APPROVED", "Active", "Supported", "", "
Editing Utilities\n
CHK: Data Checker FILE: Filer HELP: Helper UPDATE: Updater VAL: Validator WP:
Word Processing Filer $$KEYVAL^DIE( ): Key Validator VALS^DIE( ): Fields
Validator", "", "DIE", ""], ["2054", "Data Base Server API: Misc. Library Functions", "Routine", "1", "1997/07/02", "APPROVED", "Active", "Supported", "", "
Various libaray functions.\n
CLEAN: Array and Variable Clean-up $$CREF: Root Converter (Open to Closed
Format) DA: DA( ) Creator DT: Date Converter FDA: FDA Loader $$IENS: IENS
Creator $$OREF: Root Converter (Closed to Open Format) $$VALUE1: FDA Value
Retriever (Single) VALUES: FDA Values Retriever", "", "DILF", ""], ["2055", "Data Base Server API: Misc. Data Libaray Functions", "Routine", "1", "1997/07/02", "APPROVED", "Active", "Supported", "", "
Data libaray functions.\n
$$EXTERNAL: Converter to External $$FLDNUM: Field Number Retriever PRD:
Package Revision Data Initializer RECALL: Recall Record Number $$ROOT: File
Root Resolver $$VFIELD: Field Verifier $$VFILE: File Verifier", "", "DILFD", ""], ["2056", "Data Base Server API: Data Retriever Utilities", "Routine", "1", "1997/07/02", "APPROVED", "Active", "Supported", "", "
Data retriever utilities.\n
$$GET1: Single Data Retriever GETS: Multiple Data Retriever", "", "DIQ", ""], ["2057", "RETRIEVE CLOSES PRINTER", "File", "DEVICE HANDLER", "1997/07/07", "", "Withdrawn", "Private", "3.5", "
The Lab package utilizes the CLOSEST PRINTER field in
the DEVICE field. Lab requests permission to directly reference
^%ZIS(1,ien,99) to retreive this information.", "", "", ""], ["2058", "PACKAGE FILE LOOKUP", "File", "KERNEL", "1997/07/07", "APPROVED", "Active", "Controlled Subscription", "9.4", "
With the addition of the new Parameter Tools
functionality, Lab has need to retrieve the package file internal entry number
and the namespace. Lab would like permission to retrieve the IEN of the
package file by referencing the B and C indexes. Additionally, a direct
access of the PREFIX field is requested.", "", "", ""], ["2059", "LAB USE OF ORD(100.99", "File", "ORDER ENTRY/RESULTS REPORTING", "1997/07/09", "", "Withdrawn", "Private", "100.99", "
Lab would like permission to reference the ELECTRONIC
RECORD field (#22) of the ORDER PARAMETERS file (#100.99). This is only
needed while OE/RR 2.5 is running at sites. Once OE/RR 3.0 is installed
everywhere, the code can be removed and the DBIA cancelled.", "", "", ""], ["2060", "LAB USE OF OR(100,", "File", "ORDER ENTRY/RESULTS REPORTING", "1997/07/09", "APPROVED", "Active", "Private", "100", "
Lab needs to access the ORDERS file (#100) as part of
its interface with the Order Entry/Results Reporting package.", "", "", "2012/04/13"], ["2061", "DBIA2061", "File", "MAILMAN", "1997/07/11", "APPROVED", "Active", "Controlled Subscription", "3.8", "
This is an agreement for FileMan read/write access to
subfile 3.812, (#12) MEMBERS - REMOTE.", "", "", ""], ["2062", "DBIA2062", "File", "HEALTH LEVEL SEVEN", "1997/07/11", "", "Pending", "Private", "771.2", "
This agreement is to add the 2.3 version to each
message.", "", "", ""], ["2063", "DBIA2063", "File", "HEALTH LEVEL SEVEN", "1997/07/11", "", "Pending", "Private", "870", "
This agreement is for FileMan read access to the HL
LOGICAL LINK (#870) file, field LLP PARAMETER (#2).", "", "", ""], ["2065", "DBIA2065", "File", "SCHEDULING", "1997/07/21", "APPROVED", "Active", "Controlled Subscription", "409.68", "
This will permit direct reads using the "ADFN" cross
reference of the OUTPATIENT ENCOUNTER file (#409.68). This will be used to
find an encounter associated with a specific patient for a specific date via
^SCE("ADFN",PATIENT,DATE,D0).\n
Once the "ADFN" cross-reference has been used to determine if an entry exists,
the entry will be viewed by a direct global read of the 0-node, and using the
following fields:\n
.03 - CLINIC STOP CODE; .04 - LOCATION; .05 - VISIT FILE ENTRY; .06 - PARENT
ENCOUNTER; and .08 - ORIGINATING PROCESS TYPE.", "", "", ""], ["2066", "DBIA2066", "Other", "KERNEL", "1997/07/21", "", "Pending", "Private", "", "
This constitutes an agreement whereby the DHCP
Engineering Package (also known as AEMS/MERS) is allowed to use Field #62
(named 'RESERVED') of the Terminal Type File (#3.2) to allow sites to
customize the way they print bar coded equipment and location labels.\n
The bar code printing routines (ENLBL4 and ENLBL7) within the Engineering
Package contain program segments that send formatting instructions and print
requests to the user-selected bar code printer. The Engineering Package
assumes that the bar code printer is an Intermec 86xx compatible device and
that the site wants standard formatting.\n
Engineering needs:\n
1) a mechanism for interfacing to bar code printers that are not
Intermec 86xx compatible, and
2) a mechanism to allow sites to tailor the formats of their bar
coded equipment and location labels to meet local needs, if they
so desire.\n
This private integration agreement gives the Engineering Package permission to
reference Field #62 of the Terminal Type File (#3.2) entry that is pointed to
by the Device File (#3.5) entry of the selected bar code printer. The syntax
of the reference will be:\n
S X=$$GET1^DIQ(3.2,ENBCIOST(0),62)\n
where ENBCIOST(0) is the internal entry number of the bar code printer within
the Terminal Type File.\n
If $P(X,":") is equal to "ENG" then the Engineering Package will know that
pieces 2 through 5 (using ":" as a delimiter) will be executable statements,
as follows:\n
$P(X,":",2) will specify equipment formatting,
$P(X,":",3) will specify equipment data,
$P(X,":",4) will specify location formatting, and
$P(X,":",5) will specify location data.\n
An example of what a representative entry may look like is:\n
ENG:D EQFOR^ENZLBL:D EQDAT^ENZLBL:D LOCFOR^ENZLBL:D LOCDAT^ENZLBL\n
In this example:\n
program segment EQFOR^ENZLBL would be executed instead of FORMAT1^ENLBL7
" " EQDAT^ENZLBL " " " " " NXPRT1^ENLBL7
" " LOCFOR^ENZLBL " " " " " FORMAT1^ENLBL7
" " LOCDAT^ENZLBL " " " " " LOCPRT^ENLBL4\n
If any of pieces 2 through 5 in a RESERVED field that begins with 'ENG:' is
null, then the corresponding code in routine ENLBL4 or ENLBL7 will be
executed.\n
Local variables in the ENBC* namespace will be passed to each of the
executable statements, as follows:\n
ENBCIO will be the IO variable of the bar code printer
ENBCIOSL " " " IOSL " " " " " "
ENBCIOF " " " IOF " " " " " "
ENBCION " " " ION " " " " " "
ENBCIOST " " " IOST " " " " " "
ENBCIOST(0) " " " IOST(0) " " " " " "\n
Local variable DA will be passed to the executable code that processes
equipment data and to the executable code that processes location data. In the
case of equipment data, DA will be the internal entry number of a record in
the Equipment File (#6914). For location data, DA will be the internal entry
number of a record in the Space File (#6928).", "", "", ""], ["2067", "UPDATE PACKAGE FILE VERSION/APPLICATION HISTORY", "Routine", "KERNEL", "1997/07/22", "APPROVED", "Active", "Supported", "", "
These functions can be used during the Pre or Post
Install routine to update the VERSION multiple and the PATCH APPLICATION
HISTORY multiple in the PACKAGE file.", "", "XPDIP", "2018/02/02"], ["2068", "AR PACKAGE FILE UPDATE", "Other", "ACCOUNTS RECEIVABLE", "1997/07/24", "APPROVED", "Active", "Private", "", "
This is a one time agreement to allow the updating of
patch information in the AR package file for a consolidated patch release.", "", "", ""], ["2069", "DBIA2069", "File", "REGISTRATION", "1997/07/24", "", "Retired", "Private", "2", "
The patient Representative package would like to
reference two fields from the patient file, and stuff the information into the
0 node of file 745.1 (CONSUMER CONTACT file).
.323 Period of Service
.32201 Persian Gulf Service", "", "", ""], ["2070", "DBIA2070", "File", "REGISTRATION", "1997/08/04", "APPROVED", "Active", "Controlled Subscription", "2", "
The Clinical Information Resource Network (CIRN) and
Master Patient Index (MPI) will use the following fields on the MPI and MPIHIS
nodes to facilitate the exchange of patient demographic and clinical data.", "", "", ""], ["2071", "CODE INDEX (FPDS)", "File", "IFCAP", "1997/08/12", "APPROVED", "Active", "Private", "420.6", "
This agreement permits FEE BASIS to point to the CODE
INDEX (#420.6) file and also to access data in the 0 node to support a screen
of choices. The CODE INDEX file contains the list of vendor FPDS
socio-econonomic groups.", "", "", ""], ["2073", "PATIENT REPRESENTATIVE", "File", "QUALITY ASSURANCE INTEGRATION", "1997/08/14", "", "Retired", "Private", "740", "\n\n
The Patient Representation package needs to become multi-divisional. There is
a QUALITY ASSURANCE SITE PARAMETER file (#740) that stores information for all
the Quality Assurance packages. This file belongs to Quality Assurance
Integration. Patient Representative would like to ask sites (in a pre-install
patch routine) if they should be multi-divisional and if so, ensure that the
hospital divisions are listed. There are existing fields to store this
information.
field #741.1 Multi-divisional Facility
field #741.11 Hospital Division (multiple)", "", "", ""], ["2074", "DBIA2074", "File", "SCHEDULING", "1997/08/18", "APPROVED", "Active", "Private", "40.7", "
Read access is requested of all fields on the Zero node
of this file. These fields will be used for reporting purposes.\n
These fields are:
Fld # Fld Name Node;Pce
.01 NAME 0;1
1 AMIS REPORTING STOP CODE 0;2
2 INACTIVE DATE 0;3
3 CONVERT TO STOP CODE 0;4
4 COST DISTRIBUTION CENTER 0;5\n\n
Read access is requested of the "C" cross reference on this file. The "C"
cross reference will be used to check the existence of a specific 'Amis
Reporting Stop Code' as defined in field number 1.\n
It is noted that Event Capture needs to reference entries in the Clinic Stop
file (40.7) via Internal Entry Numbers (pointers) to that file.", "", "", ""], ["2075", "DBIA2075", "Routine", "TOOLKIT", "1997/08/20", "APPROVED", "Active", "Supported", "", "
This agreement expands agreement 10095 for XTKERMIT.
This agreement allows access to the KERMIT HOLDING file (#8980) and the API
that adds entries to it, RFILE^XTKERM4. The "AOK" cross-reference of the
KERMIT HOLDING file (#8980) may be checked to see if the user has an entry in
the KERMIT HOLDING file (#8980). If not, RFILE^XTKERM4 may be called to add an
entry to the file.", "", "XTKERM4", ""], ["2076", "DBIA2076-A", "Routine", "REGISTRATION", "1997/08/20", "APPROVED", "Active", "Private", "", "
To support patient data review, CIRN needs to include a
Hinq inquiry.", "", "DG10", ""], ["2077", "DBIA2077", "File", "PCE PATIENT CARE ENCOUNTER", "1997/09/24", "APPROVED", "Active", "Controlled Subscription", "9999999.17", "
This integration agreement authorizes global reference
to the zeroith node of the following file for purposes of retrieving the name
and inactive flag:\n
^AUTTTRT(#,0) piece 1 and piece 4\n
... and to the "B" cross-reference", "", "", ""], ["2078", "DBIA2078", "File", "TOOLKIT", "1997/08/20", "APPROVED", "Active", "Private", "8980", "
Integration Agreement to read the "AOK" cross reference
and check for the existence of the ^DIZ(8980,"AOK",DUZ) cross-reference. If
not, data is added to the KERMIT HOLDING file (#8980) via the RFILE^XTKERM4
entry point.", "", "", ""], ["2079", "DBIA2079", "File", "NATIONAL DRUG FILE", "1997/08/22", "APPROVED", "Active", "Private", "50.6", "
Pharmacy Data Management requests an intergration
agreement to look at National Drug file 50.6.", "", "", ""], ["2080", "DBIA2080", "Routine", "NATIONAL DRUG FILE", "1997/08/22", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management requests an intergration
agreement with National Drug File package to call up line-tag REACT1^PSNOUT.
The master Drug Enter/Edit option in PDM needs the ability to match to NDF if
the user has the proper key. PDM requires at least NDF 3.15 to be in place in
order to install. A ^%ZOSF test will be executed on routine PSNOUT. The
line-tag allows the user to match, verify, and merge an entry in DRUG file 50
to NATIONAL DRUG file 50.6.", "", "PSNOUT", ""], ["2081", "DBIA2081", "Other", "1", "1997/09/30", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management requests an intergration
agreement with the VA FileMan package. PDM requests to do a one-time hard kill
of four triggers which are no longer valid in DRUG file 50. These triggers
will be killed in a post install routine in Pharmacy Data Management version
1.0. The fields affected in DRUG file 50 are: Field 12 ORDER UNIT Field 13
PRICE PER ORDER UNIT Field 15 DISPENSE UNITS PER ORDER UNIT Field 16 PRICE
PER DISPENSE UNIT In addition: Field 23 PACKAGE SIZE (input transform) Field
24 PACKAGE TYPE (input transform) Field 8 WARNING LABEL (overflow of input
transform code)\n
The KILL logic looks as follows: K
^DD(50,12,1,535000),^DD(50,203),^DD(50,13,1,535000),^DD(50,15,1,535000),
^DD(50,16,1,1),^DD(50,"TRB",16) K
^DD(50,0,"IX","AE",50,202),^DD(50,0,"IX","IV",50.03,.01) K
^DD(50,0,"IX","IV1",50,204),^DD(50,0,"IX","IV2",50,201.1),^DD(50,0,"PT",50.03,.
02)
K
^DD(50,0,"IX","AV1",50,200),^DD(50,0,"IX","AD",50,201),^DD(50,0,"IX","AF",50,20
1.3),^DD(50,0,"IX","AV2",50,201),K
^DD(50,23,2),^DD(50,23,2.1),^DD(50,24,2),^DD(50,24,2.1),^DD(50,8,9.2)", "", "", ""], ["2082", "DBIA2082", "File", "AUTOMATED INFO COLLECTION SYS", "1997/08/25", "APPROVED", "Active", "Private", "357.69", "
This DBIA is to allow PCE to read AICS' file TYPE OF
VISIT file (#357.69) for the following files.\n
^IBE(357.69,
.01 CODE [0;1] Read/Fileman
.015 SHORT NAME [computed] Read/Fileman
.02 RECOMMENDED HEADER [0;2] Read/Fileman
.03 RECOMMENDED TEXT [0;3] Read/Fileman
.04 INACTIVE FLAG [0;4] Read/Fileman
.05 NEW,ESTABLISHED,CONSULT [0;5] Read/Global", "", "", ""], ["2083", "DBIA2083", "File", "SCHEDULING", "1997/08/26", "APPROVED", "Active", "Controlled Subscription", "409.41", "\n\n
This DBIA allows PCE to Globally read Scheduling's OUTPATIENT CLASSIFICATION
TYPE file (#409.41) for the below fields. This is used in asking the user the
patient Service Connected and Classification questions. PCE is now asking
these question for Scheduling.", "", "", ""], ["2084", "DBIA2084", "File", "SCHEDULING", "1997/08/26", "APPROVED", "Active", "Private", "409.42", "\n\n
PCE request a DBIA with Scheduling to kill entries in the OUTPATIENT
CLASSIFICATION file (#409.42). This is done in the process of asking the user
for the patient's classification if the classification " is no longer
applicable...". This is needed because PCE now ask the classification
questions for Scheduling and this was done in the asking of the classification
questions.", "", "", ""], ["2085", "DBIA2085", "File", "REGISTRATION", "1997/08/26", "APPROVED", "Active", "Private", "43", "\n\n
This is needed because PCE now ask the classification questions for
Scheduling.", "", "", ""], ["2086", "DBIA2086", "File", "REGISTRATION", "1997/08/26", "APPROVED", "Active", "Private", "2", "\n\n
This is so PCE can find the Outpatient Encounter and thus the Visit for a
disposition.", "", "", ""], ["2087", "DBIA2087", "File", "GEN. MED. REC. - VITALS", "1997/08/26", "APPROVED", "Active", "Controlled Subscription", "120.5", "\n\n
This is used in the Caseload Profile report. It is looking for blood
pressures above 159/90 (either value high).", "", "", ""], ["2088", "DBIA2088", "File", "SCHEDULING", "1997/08/26", "APPROVED", "Active", "Private", "409.68", "", "", "", ""], ["2089", "DBIA2089", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
PCE has a copy of Schedulings protocol SDAM LIST MENU
called PXCE SDAM LIST MENU with a default of Total Appt Profile and different
Entry and Exit actions. This DBIA is to allow PCE to include Scheduling's
protocols listed below on PCE's protocol.\n
NAME: PXCE SDAM LIST MENU ITEM TEXT: Appointment Lists
TYPE: menu
PACKAGE: PCE PATIENT CARE ENCOUNTER
DESCRIPTION: This action allows you to change which appointments will
be displayed based on their status of the appointments. For example, you
may change the display to list cancelled, checked in, checked out, future
appointments, inpatient appointments, appointment where no action has
been taken, non count appointments, no show appointments or all
appointments.\n
COLUMN WIDTH: 40 IDENTIFIER: AL ITEM: SDAM LIST CHECKED
IN MNEMONIC: CI
SEQUENCE: 1 ITEM: SDAM LIST NO SHOWS MNEMONIC: NS
SEQUENCE: 2 ITEM: SDAM LIST ALL MNEMONIC: TA
SEQUENCE: 3 ITEM: SDAM LIST NO ACTION MNEMONIC: NA
SEQUENCE: 4 ITEM: SDAM LIST CANCELLED MNEMONIC: CA
SEQUENCE: 5 ITEM: SDAM LIST FUTURE MNEMONIC: FU
SEQUENCE: 6 ITEM: SDAM LIST INPATIENT MNEMONIC: IP
SEQUENCE: 7 ITEM: SDAM LIST NON-COUNT MNEMONIC: NC
SEQUENCE: 8 ITEM: SDAM LIST CHECKED OUT MNEMONIC: CO
SEQUENCE: 9
EXIT ACTION: S:'$D(VALMBCK) VALMBCK="" D EXIT^PXCESDAM
ENTRY ACTION: D FULL^VALM1 S XQORM(0)="1A"
HEADER: W "" MENU PROMPT: Select List:
MENU DEFAULT: Total Appt Profile TIMESTAMP: 57166,50591", "", "", ""], ["2090", "ACCESS TO PATIENT MOVEMENT DATA", "File", "REGISTRATION", "1997/08/27", "APPROVED", "Active", "Controlled Subscription", "405", "
THIS ICR ALLOWS ACCESS TO PATIENT MOVEMENT DATA.", "", "", "2012/10/12"], ["2091", "DBIA2091", "File", "KERNEL", "1997/08/27", "APPROVED", "Active", "Controlled Subscription", "8932.1", "", "", "", ""], ["2092", "2092", "File", "LAB SERVICE", "1997/08/27", "APPROVED", "Active", "Private", "60", "
This is used by the PCE Reports.", "", "", ""], ["2093", "DBIA2092-B", "File", "LAB SERVICE", "1997/08/27", "APPROVED", "Active", "Private", "63", "
This is used by the PCE Reports.", "", "", ""], ["2094", "CHECK FOR INACTIVE PROVIDER", "File", "KERNEL", "1997/08/27", "APPROVED", "Active", "Controlled Subscription", "200", "
This is used to see if a provider has been inactivated
at the time of the patient encounter.\n
Revision History:
- 2/26/25-Added OE/RR as a subscriber to document historical usage, which
resulted in adding Field 53.1", "", "", ""], ["2095", "DBIA2095", "File", "PHARMACY DATA MANAGEMENT", "1997/09/04", "APPROVED", "Active", "Private", "50", "
Drug Accountability/Inventory Interface (DA) v3.0
interfaces with the DRUG (#50) file to assist Pharmacy in maintaining a
perpetual inventory. DA contains two methods of maintaining the drug balances.
The site can either interface with the Generic Inventory Package (GIP) or with
the prime vendor's electronic invoice data. The DRUG file is used to store
matches between drugs and either an item in GIP or the NDC in the prime
vendor's invoice data. It is also used to identify matched drugs when they are
received and dispensed drugs via other VISTA Pharmacy packages. When the
fields are read, it is by a direct global read. When the fields are written
to, it is by a FileMan DIE call.\n
Read fields:
============
GLOBAL MAP DATA DICTIONARY #50 -- DRUG FILE
--------------------------------------------------------------------------
^PSDRUG(D0,0)= (#.01) GENERIC NAME [1F] ^ ^ ^ ^ ^ (#6) FSN [6F] ^ ^ ^
==>(#51) NON-FORMULARY [9S] ^ ^ ^PSDRUG(D0,1,0)=^50.1A^^ (#9)
SYNONYM ^PSDRUG(D0,1,D1,0)= (#.01) SYNONYM [1F] ^ (#2) NDC CODE [2F] ^
==>(#1) INTENDED USE [3S] ^ (#400) VSN [4F] ^ (#401)
==>ORDER UNIT [5P] ^ (#402) PRICE PER ORDER UNIT [6N] ^
==>(#403) DISPENSE UNITS PER ORDER UNIT [7N] ^ (#404)
==>PRICE PER DISPENSE UNIT [8N] ^ (#405) VENDOR [9F] ^
^PSDRUG(D0,2)= ^ ^ (#63) APPLICATION PACKAGES' USE [3F] ^ (#31) NDC [4F] ^
^PSDRUG(D0,441,0)=^50.0441P^^ (#441) IFCAP ITEM NUMBER ^PSDRUG(D0,441,D1,0)=
(#.01) ITEM NUMBER [1P] ^ ^PSDRUG(D0,660)= ^ (#12) ORDER UNIT [2P] ^ (#13)
PRICE PER ORDER UNIT [3N]
==>^ ^ (#15) DISPENSE UNITS PER ORDER UNIT [5N] ^ (#16)
==>PRICE PER DISPENSE UNIT [6N] ^ ^ (#14.5) DISPENSE UNIT
==>[8F] ^ ^PSDRUG(D0,660.1)= (#50) CURRENT INVENTORY [1N] ^
^PSDRUG(D0,I)= (#100) INACTIVE DATE [1D] ^ ^PSDRUG(D0,ND)= (#20) NATIONAL DRUG
FILE ENTRY [1P] ^ (#21) VA PRODUCT
==>NAME ENTRY [2N] ^ (#22) PSNDF VA PRODUCT NAME ENTRY [3N] ^
==>(#23) PACKAGE SIZE [4P] ^ (#24) PACKAGE TYPE [5P] ^\n
Cross-references Read:
=====================
ITEM NUMBER(AB), VSN(AVSN), SYNONYM(C), VA PRODUCT NAME(VAPN), NDC(NDC)\n
Fields Written to:
==================
GLOBAL MAP DATA DICTIONARY #50 -- DRUG FILE
--------------------------------------------------------------------------
^PSDRUG(D0,0)= (#.01) GENERIC NAME [1F] ^ ^PSDRUG(D0,1,0)=^50.1A^^ (#9)
SYNONYM ^PSDRUG(D0,1,D1,0)= (#.01) SYNONYM [1F] ^ (#2) NDC CODE [2F] ^
==>(#1) INTENDED USE [3S] ^ (#400) VSN [4F] ^ (#401)
==>ORDER UNIT [5P] ^ (#402) PRICE PER ORDER UNIT [6N] ^
==>(#403) DISPENSE UNITS PER ORDER UNIT [7N] ^ (#404)
==>PRICE PER DISPENSE UNIT [8N] ^ (#405) VENDOR [9F] ^
^PSDRUG(D0,2)= ^ ^ ^ (#31) NDC [4F] ^ ^PSDRUG(D0,441,0)=^50.0441P^^ (#441)
IFCAP ITEM NUMBER ^PSDRUG(D0,441,D1,0)= (#.01) ITEM NUMBER [1P] ^
^PSDRUG(D0,660)=^ (#12) ORDER UNIT [2P] ^ (#13) PRICE PER ORDER UNIT [3N]
==>^ ^ (#15) DISPENSE UNITS PER ORDER UNIT [5N] ^ (#16)
==>PRICE PER DISPENSE UNIT [6N] ^^ (#14.5) DISPENSE UNIT [8F]
^PSDRUG(D0,660.1)= (#50) CURRENT INVENTORY [1N] ^\n\n
Three print templates are used to print two reports. PSADRIP and PSADRIH are
used to print the DRUG file/ITEM MASTER file Comparison Report from a selected
sort range The report contains information on packaging and pricing. PSADRIH
is the header on this report. PSADRI is used to print the Inquire/Compare DRUG
file/ITEM MASTER file report that compares the packaging and pricing between
the DRUG file and the ITEM MASTER file.", "", "", ""], ["2096", "2096", "File", "SCHEDULING", "2005/12/01", "APPROVED", "Active", "Controlled Subscription", "409.63", "", "", "", ""], ["2097", "DBIA2097", "File", "1", "1997/08/29", "APPROVED", "Active", "Private", "1.1", "\n
CIRN needs to display the last date edited for a patient. CIRN
recommends that sites turn on auditing for demographic fields. To get the
last date edited, if auditing is turned on, CIRN checks the
$P(^DIA(2,0),U,3)+1 for the last entry and then $O(^DIA(2,"B",DFN,LAST
ENTRY),-1) to find the most recent edit, $P(^DIA(2,IEN,0),U,2). CIRN requests
direct read access to these nodes.", "", "", ""], ["2098", "DIQUIET TO SUPPRESS WRITES", "Other", "1", "1997/09/02", "APPROVED", "Active", "Controlled Subscription", "", "
1. DESCRIPTION OF USE OF DIQUIET IN FILEMAN\n
HISTORY OF DIQUIET: The purpose for creating DIQUIET was mostly that as we
were creating the data-base server calls, we sometimes needed to call into
Classic FileMan, and we absolutely didn't want FileMan to talk. DIQUIET was a
variable that would let us know within those classic calls that we were being
called from a DBS call, so we shouldn't talk. Therefore, at the start of
almost all the DBS calls, we set DIQUIET=1. DIQUIET was also used as a flag
in EN^DDIIOL, which is embedded in Xecutable code in the DD, to assure that
text is placed in ^TMP instead of being Written when DBS calls are involved.\n\n
SETTING DIQUIET WITHIN FILEMAN CODE: DIQUIET is set to 1 at the start of the
following published calls:\n
Finder FIND^DIC
Finder (Single Record) $$FIND1^DIC
Lister LIST^DIC
DD Field Retriever FIELD^DID
DD Field List Retriever FIELDLST^DID
DD File Retriever FILE^DID
DD File List Retriever FILELIST^DID
Attribute Retriever $$GET1^DID
Data Checker CHK^DIE
Filer FILE^DIE
Helper HELP^DIE
Updater UPDATE^DIE
Validator VAL^DIE
Word-Processing Filer WP^DIE
Single Data Retriever $$GET1^DIQ
Data Retriever GETS^DIQ\n
In addition, there are a few places that Classic FileMan sets DIQUIET for the
same reason.\n
Import Tool (DDMP, DDMPU) because the Import tool is designed to be silent
like the DBS calls.\n
DIED and DIEZ1 (classic DIE call to edit data) sets DIQUIET if the user is
stuffing data in a SET OF CODES field, because it makes a call to ^DIR and
does not want the Reader to talk.\n
DIEZ, DIKZ and DIPZ (template and x-ref compilation) appear to have silent
entry points (all labeled EN2) that set DIQUIET. I believe that these were
created by Rick, I don't think they're documented. Perhaps KIDS uses them, I
need to discuss this with him.\n
DIP (the PRINT routine) sets DIQUIET if it is not already set, and if all
the information that DIP normally prompts the user for has been sent (I.E.,
file and fields to print, sort criteria, device, etc.), or if the print job is
queued. That was to avoid some places where FileMan was writing error
messages.\n\n
HONORING DIQUIET TO SUPPRESS WRITES: Mostly we made changes to classic FileMan
as we needed to, in places where we were calling it from the new DBS calls and
wanted it to be silent. The places are:\n
DDIOL (The loader), where DIQUIET tells the routine to load the text that is
passed into an array rather than writing it. That's why we were able to tell
people that any writes that they have in their DDs should call ^DDIOL rather
than just write.\n
%DT (date validation routine) to keep the date from echoing back.\n
DT^DICRW (routine that sets up required FileMan variables). Was writing a
line-feed.\n
DIE3 (enter/edit) Does not write "Searching for a..." when doing a lookup on
a file pointed-to by a variable pointer, and does not ask OK when a pointed-to
entry is found, even if the DD has been set up that way.\n
DIP The changes to the print are described above, and were not done for the
DBS calls, as we don't call the print from within any of them.\n
DIR1 The Reader doesn't write a message when processing sets of codes if
DIQUIET is set. This was required by DIE when stuffing a SET OF CODES field,
as I described above.\n
2. REASON RPC BROKER NEEDS TO SET DIQUIET:\n
Setting of DIQUIET variable, which is used within the VA FileMan package to
suppress WRITEs from FileMan routines and DDs, to 1. Variable being set by
RPC Broker when it is certain that no direct user-interaction is appropriate
(client/server environment).\n
The only FileMan code that the Broker does directly that requires DIQUIET to
be set is DT^DICRW (a linefeed is suppressed). However, since the Broker
performs the code written in RPCs, having DIQUIET set protects the code in the
RPCs from inadvertently Writing because of a call to a FileMan routine or the
Xecution of a DD node.", "", "", ""], ["2099", "PSORPH", "Other", "OUTPATIENT PHARMACY", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to check for the PSORPH
security key.", "", "", ""], ["2100", "DBIA2100", "Other", "INPATIENT MEDICATIONS", "1997/09/16", "APPROVED", "Active", "Private", "", "
PDM requests permission to check for the following
security keys:
PSJU MGR
PSJI MGR
PSGWMGR
PSJ RPHARM
PSJ RNURSE
PSJ PHARM TECH", "", "", ""], ["2104", "DBIA2104", "Other", "DRUG ACCOUNTABILITY", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to check for the PSAMGR and PSA
ORDERS security keys.", "", "", ""], ["2105", "DBIA2105", "Other", "CONTROLLED SUBSTANCES", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to check for the PSDMGR
security key.", "", "", ""], ["2106", "DBIA2106", "Other", "NATIONAL DRUG FILE", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to check for the PSNMGR
security key.", "", "", ""], ["2107", "PSXCMOPMGR", "Other", "CMOP", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to check for the PSXCMOPMGR
security key.", "", "", ""], ["2108", "DBIA2108", "Other", "INPATIENT MEDICATIONS", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to use the PSJ OAOPT input
template to Pharmacy System file 59.7.", "", "", ""], ["2109", "DBIA2109", "File", "INPATIENT MEDICATIONS", "1997/09/16", "APPROVED", "Active", "Private", "53.45", "
PDM requests to look at INPATIENT USER PARAMETERS file
53.45. PDM requests permission to use the [PSJ IUP SUPER EDIT] and [PSJ IUP
USER EDIT] input templates for INPATIENT USER PARAMETERS file 53.45.", "", "", ""], ["2110", "DBIA2110", "File", "INPATIENT MEDICATIONS", "1997/09/16", "APPROVED", "Active", "Private", "59.6", "
PDM requests permission to look at INPATIENT WARD
PARAMETERS file 59.6. PDM requests permission to use the [PSJIWPIEDIT] input
template for INPATIENT WARD PARAMETERS file 59.6.", "", "", ""], ["2111", "DBIA2111", "File", "INPATIENT MEDICATIONS", "1997/09/16", "APPROVED", "Active", "Private", "57.7", "
PDM requests permission to look at MEDICATION
ADMINISTERING TEAM file 57.7. PDM requests permission to use the [PSJUMATE]
input template to MEDICATION ADMINISTERING TEAM file 57.7.", "", "", ""], ["2112", "DBIA2112", "File", "INPATIENT MEDICATIONS", "1997/09/16", "APPROVED", "Active", "Private", "57.5", "
PDM requests permission to look at WARD GROUP file
57.5. PDM requests permission to use the [PSJU WG] input template for WARD
GROUP file 57.5.", "", "", ""], ["2114", "DBIA2114", "File", "INPATIENT MEDICATIONS", "1997/09/16", "APPROVED", "Active", "Private", "51.15", "
PDM requests permission to look at ADMINISTRATION SHIFT
file 51.15. PDM requests permission to use the [PSJ SHIFT EDIT] input
template for ADMINISTRATION SHIFT file 51.15.", "", "", ""], ["2115", "DBIA2115", "File", "INPATIENT MEDICATIONS", "1997/09/16", "APPROVED", "Active", "Private", "53.2", "
PDM requests permission to look at ORDER SET file 53.2.\n
PDM requests permission to use the [PSJUOSE] input template for UNIT DOSE
ORDER SET file 53.2.", "", "", ""], ["2116", "DBIA2116", "Other", "INPATIENT MEDICATIONS", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to use [PSJ SCHEDULE EDIT] and
[PSJ EXT SCHEDULE EDIT] input templates to ADMINISTRATION SCHEDULE file 51.1.", "", "", ""], ["2118", "DBIA2118", "Routine", "KERNEL", "1997/09/05", "APPROVED", "Active", "Supported", "", "
This routine is part of the Kernel Device handler. It
is used for making TCP/IP connection between computers. It only deals with IP
address.", "", "%ZISTCP", ""], ["2119", "DBIA2119", "Routine", "KERNEL", "1997/09/05", "APPROVED", "Active", "Supported", "", "
Access to some device handler tools.", "", "%ZISUTL", ""], ["2120", "DBIA2120", "Routine", "KERNEL", "1997/09/05", "APPROVED", "Active", "Controlled Subscription", "", "
IA between Kernel and RPB Broker.", "", "XUSRB", ""], ["2121", "DBIA2121", "Routine", "KERNEL", "1997/09/05", "APPROVED", "Active", "Private", "", "
This is a custom call developed for the RPC Broker.", "", "XUSRB1", ""], ["2122", "DBIA2122", "Routine", "OUTPATIENT PHARMACY", "1997/09/05", "APPROVED", "Active", "Private", "", "
PDM requests permission to call PSOHELP1. This routine
is called by a compiled cross-reference routine (PSSJXR) ON PHARMACY PATIENT
file 55. PSOHELP1 sets two cross-references in file #55 ("A" and "P")
involked from VA FileMan.", "", "PSOHELP1", ""], ["2123", "DBIA2123", "File", "INPATIENT MEDICATIONS", "1997/09/05", "", "Pending", "Private", "3.081", "
Drug Accountability/Inventory Interface v3.0 is
requesting an integration agreement to read the SIGN-ON LOG FILE's (#3.081)
^XUSEC("PSJ RPHARM") node. It is used to determine if the user holds the
pharmacist key.", "", "", ""], ["2124", "DBIA2124", "Routine", "KERNEL", "1997/09/05", "APPROVED", "Active", "Private", "", "
Special call to menu system to check access to options
and RPC's.", "", "XQCS", ""], ["2125", "DBIA2125", "File", "INPATIENT MEDICATIONS", "1997/09/08", "APPROVED", "Active", "Private", "53.45", "
PDM requests permission to look at INPATIENT USE
PARAMETERS file 53.45.", "", "", ""], ["2126", "ACCESS FILE 59.6", "File", "INPATIENT MEDICATIONS", "1997/09/08", "", "Active", "Private", "59.6", "
PDM requests permission to look at INPATIENT WARD
PARAMETERS file 59.6.", "", "", "2020/09/01"], ["2127", "DBIA2127", "File", "PHARMACY DATA MANAGEMENT", "1997/09/08", "APPROVED", "Active", "Private", "50.3", "
This file was originally associated with Inpatient
Medications as the custodial package. Due to the conversion of Rational to
GitHub, this file is now assigned to the Pharmacy Data Management Package,
making this ICR no longer necessary because PDM was the only subscribing
package. Additionally the 50.3 file is no longer used, but has not gone
through a formal retirement in the ICRs.\n
Old text before 9/1/20: PDM requests permission to look at PRIMARY DRUG file
50.3.", "", "", "2020/09/01"], ["2128", "DBIA2128", "File", "INPATIENT MEDICATIONS", "1997/09/08", "", "Pending", "Private", "57.7", "
PDM requests permission to look at MEDICATION
ADMINISTERING TEAM file 57.7.", "", "", ""], ["2129", "DBIA2129", "File", "INPATIENT MEDICATIONS", "1997/09/08", "", "Pending", "Private", "57.5", "
PDM requests permission to look at WARD GROUP file
57.5.", "", "", ""], ["2130", "DBIA2130", "File", "INPATIENT MEDICATIONS", "1997/09/08", "", "Pending", "Private", "53.2", "
PDM requests permission to look at UNIT DOSE ORDER SET
file 53.2.", "", "", ""], ["2131", "DBIA2131", "File", "CONTROLLED SUBSTANCES", "1997/09/08", "APPROVED", "Active", "Private", "59.4", "
PDM requests permission to look at INPATIENT SITE file
59.4.", "", "", ""], ["2132", "DBIA2132", "File", "INPATIENT MEDICATIONS", "1997/09/08", "APPROVED", "Active", "Private", "51.15", "
PDM requests permission to look at ADMINISTRATION SHIFT
file 51.15.", "", "", ""], ["2133", "DBIA2133", "File", "NATIONAL DRUG FILE", "1997/09/08", "APPROVED", "Active", "Private", "56", "
PDM requests permission to look at DRUG INTERACTION
file 56.", "", "", ""], ["2134", "DBIA2134", "File", "INPATIENT MEDICATIONS", "1997/09/08", "", "Pending", "Private", "50.2", "
PDM requests permission to look at IV CATEGORY file
50.2.", "", "", ""], ["2135", "DBIA2135", "Routine", "IFCAP", "1997/09/08", "APPROVED", "Active", "Private", "", "
The Prosthetics package requests permission to use
IFCAP program PRCFSITE to set special IFCAP variables used in the package.", "", "PRCFSITE", ""], ["2136", "DBIA2136", "File", "NATIONAL DRUG FILE", "1997/09/09", "APPROVED", "Active", "Private", "50.608", "
PDM requests permission to look at PACKAGE TYPE file
50.608.", "", "", ""], ["2137", "DBIA2137", "File", "NATIONAL DRUG FILE", "1997/09/09", "APPROVED", "Active", "Private", "50.609", "
PDM requests permission to look at PACKAGE SIZE file
50.609.", "", "", ""], ["2138", "DBIA2138", "File", "NATIONAL DRUG FILE", "1997/09/09", "APPROVED", "Active", "Private", "50.605", "
PDM requests permission to look at VA DRUG CLASS file
50.605.", "", "", ""], ["2139", "DBIA2139", "File", "INPATIENT MEDICATIONS", "1998/11/25", "APPROVED", "Active", "Private", "57.1", "
PDM requests permission to look at PHARMACY QUICK ORDER
file 57.1.", "", "", ""], ["2140", "DBIA2140", "File", "INPATIENT MEDICATIONS", "1997/09/09", "APPROVED", "Active", "Private", "53.1", "
The Pharmacy Data Management package requests
permission to read fields from the NON-VERIFIED ORDERS file (#53.1).", "", "", "2020/01/29"], ["2141", "DBIA2141", "File", "PHARMACY DATA MANAGEMENT", "1997/09/09", "", "Pending", "Private", "51.5", "
Drug Accountability/Inventory Interface (DA) is
requesting an integration agreement with Pharmacy Data Management to create
and write to a new SYNONYM field in a new SYNONYM multiple. In the DA v3.0
prime vendor interface, the prime vendor sends an invoice data file containing
line items that were shipped. Each line item has a two-character order unit.
If their order unit is not in the ORDER UNIT FILE, the user is asked to match
it to an existing order unit. When the data is verified, the prime vendor's
two-character order unit is added to the SYNONYM field (#.01) in the SYNONYM
multiple and in a new "APV" cross-reference.\n
The next time the order unit is received the link is used to the ABBREVIATION
field (#.01). This is done by reading the "APV" cross-reference.", "", "", ""], ["2142", "INSTALL File Read", "File", "KERNEL", "1997/09/10", "APPROVED", "Retired", "Private", "9.7", "\n
************************************************************************
The Library package was decommissioned with LBR*2.5*15. This ICR was retired
with the release of the Library patch.
************************************************************************\n
Because we didn't do a package link for Library Version 2.5 Patch 1, checks
for installation of this patch will not work. Would like to use
$D(^XPD(9.7,"B","LBR*2.5*1")) in our environment check programs until next
version of the Library package comes out.", "", "", ""], ["2143", "Option Schedule Look-up", "File", "KERNEL", "1997/09/10", "APPROVED", "Retired", "Private", "19.2", "\n
************************************************************************
The Library package was decommissioned with LBR*2.5*15. This ICR was retired
with the release of the Library patch.
************************************************************************\n
Sometimes the Library package TaskMans are not restarted when the system is
shut down. This causes a problem with transaction processing back and forth
with FORUM. To help the Librarians with observation of this problem, a
program has been written that displays the option, the frequency and the next
scheduled time. We need to do a DIC lookup into file 19.2 to retrieve this
information because using XUTMOPT displays more information than the general
user needs to see and also page feeds for each option.", "", "", ""], ["2144", "DBIA2144", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "APPROVED", "Active", "Private", "", "
PDM requests permission to use the PSGAL5 Inpatient
Medications routine. PHARMACY PATIENT File (#55) belongs to PDM, however,
there are subfiles within this file which are compiled cross-references. The
PSSJXR routine serves as the driver for these cross-references in file #55.
This driver routine calls PSGAL5 routine.", "", "PSGAL5", ""], ["2145", "DBIA2145", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "APPROVED", "Active", "Private", "", "
PDM requests permission to use the PSGAMSA Inpatient
Medications routine. A ZOSF test will be done before invoking the routine.
PHARMACY PATIENT File (#55) belongs to PDM, however, there are subfiles within
this file which are compliled cross-references. The PSSJXR routine serves as
the driver for these cross-references in file #55. This driver routine calls
PSGAMSA routine.", "", "PSGAMSA", ""], ["2146", "DBIA2146", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "APPROVED", "Active", "Private", "", "
A ZOSF test will be done before invoking the routine.", "", "PSGCT", ""], ["2147", "DBIA2147", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "", "Pending", "Private", "", "
PDM requests permission to use PSGFILD1 Inpatient
Medications routine. A ZOSF test will be done before invoking the routine.
This routine is invoked by routine PSSFIl which prompts the user to be
displayed instructions for auto-discontinue set-up.", "", "PSGFILD1", ""], ["2148", "DBIA2148", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "", "Pending", "Private", "", "
PDM requests permission to use the PSGGAO Inpatient
Medications routine. A ZOSF test will be done before invoking the routine.", "", "PSGGAO", ""], ["2150", "DBIA2150", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "APPROVED", "Active", "Private", "", "
A ZOSF test will be done before invoking the routine.", "", "PSGNE3", ""], ["2152", "DBIA2152", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "", "Pending", "Private", "", "
PDM requests permission to use the PSGSET Inpatient
Medications routine. A ZOSF test will be done before invoking the routine.", "", "PSGSET", ""], ["2153", "DBIA2153", "Routine", "INPATIENT MEDICATIONS", "2000/07/07", "APPROVED", "Active", "Private", "", "
The Pharmacy Data Management V. 1.0 application
requests an integration agreement with the Inpatient Medications V. 5.O
application to make an external call to ENIVKV^PSGSETU.\n
The external call is executed from the PSSVIDRG routine within the Pharmacy
Data Management application. The PSSVIDRG routine will perform an ^%ZOSF test
before invoking the routine This external call is used to clean up or kill
existing IV variables.", "", "PSGSETU", ""], ["2154", "DBIA2154", "Routine", "INPATIENT MEDICATIONS", "1997/09/17", "APPROVED", "Active", "Private", "", "
PDM requests permission to use the PSIVWL Inpatient
Medications routine. A ZOSF test will be done before invoking the routine.", "", "PSIVWL", ""], ["2155", "DBIA2155", "Routine", "INPATIENT MEDICATIONS", "2000/07/07", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management V. 1.0 application requests an
integration agreement with the Inpatient Medications V. 5.O application to
make an external call to ENQ^PSIV.\n
The external call is executed from the PSSVIDRG routine within the Pharmacy
Data Management application. This external call is used to read a user
response.", "", "PSIV", ""], ["2156", "DBIA2156", "Routine", "INPATIENT MEDICATIONS", "2000/07/07", "APPROVED", "Active", "Private", "", "\n
Pharmacy Data Management V. 1.0 application requests an integration
agreement with the Inpatient Medications V. 5.O application to make an
external call to the PSIVHLP1 routine.\n
The external call is executed from the PSSVIDRG routine within the
Pharmacy Data Management application. This external call is used to
provide help information related to IV Additives and Solutions.", "", "PSIVHLP1", ""], ["2157", "DBIA2157", "Routine", "INPATIENT MEDICATIONS", "2000/07/07", "APPROVED", "Active", "Private", "", "
The Pharmacy Data Management V. 1.0 application
requests an integration agreement with the Inpatient Medications V. 5.O
application to make an external call to the PSIVXU routine.\n
The external call is executed from the PSSVIDRG routine within the Pharmacy
Data Management application. The PSSVIDRG routine will perform an ^%ZOSF test
before invoking the routine. This external call is used to group drug
information for reports.", "", "PSIVXU", ""], ["2159", "DBIA2159", "File", "1", "1997/09/29", "APPROVED", "Active", "Private", "", "
PDM requests permission to look at the ^DD global for
following files:\n
Global route File # File
--------------------------------------------------------------------
^DD(50 50 DRUG
File 50 DRUG MUMPS x-ref (AUDAP)
Field .01 GENERIC NAME - ^DD(50,51,0).
^DD("50",".01","1","3","0")="50^AUDAP^MUMPS" ^DD("50",".01","1","3","1")="I
'$D(PSGINITF) S ^PSDRUG("AUDAP")=$S($D(^PS(59.7,1 ,20)):$P(^(20),"^"),1:"")"
^DD("50",".01","1","3","1.1")="S X=Y(0) S Y(1)=$S($D(^PSDRUG(D0,0)):^(0),1:"")
S
X=$P(Y(1),U,1) S XMB(1)=X" ^DD("50",".01","1","3","1.2")="S X=Y(0) S
Y(2)=$C(59)_$S($D(^DD(50,51,0)):$P(^(0
),U,3),1:""),Y(1)=$S($D(^PSDRUG(D0,0)):^(0),1:"") S
X=$P($P(Y(2),$C(59)_$P(Y(1), U,9)_":",2),$C(59),1) S XMB(2)=X"
^DD("50",".01","1","3","1.3")="S X=Y(0) S Y(1)=$S($DPSDRUG(D0,0)):^(0),1:"") S
X=$S('$D(^PS(50.5,+$P(Y(1),U,2),0)):"",1:$P(^(0),U,1)) S XMB(3)=X"
^DD("50",".01","1","3","1.4")="S X=Y(0) S Y(1)=$S($D(^PSDRUG(D0,0)):^(0),1:"")
S
X1),U,10) S XMB(4)=X" ^DD("50",".01","1","3","2")="Q"
^DD("50",".01","1","3","2.2")="S X=Y(0) S
Y(2)=$C(59)_$S($D(^DD(50,51,0)):$P(^(0
),U,3),1:""),Y(1)=$S($D(^PSDRUG(D0,0)):^(0),P(Y(2),$C(59)_$P(Y(1),
U,9)_":",2),$C(59),1) S XMB(2)=X" ^DD("50",".01","1","3","2.3")="S X=Y(0) S
Y(1)=$S($D(^PSDRUG(D0,0)):^(0),1:"") S
X=$S('$D(^PS(50.5,+$P(Y(1),U,2),0)):"",(0),U,1)) S XMB(3)=X"
^DD("50",".01","1","3","2.4")="S X=Y(0) S Y(1)=$S($D(^PSDRUG(D0,0)):^(0),1:"")
S
X=$P(Y(1),U,10) S XMB(4)=X" ^DD("50",".01","1","3","3")="Used by the Unit
npatient Medications package s."\n
****************
^DD(51.1 51.1 ADMINISTRATION SCHEDULE
File 52.6 IV ADDITIVES INPUT TRANSFORM
Field 5 ADMINISTRATION TIMES - ^DD(51.1,1,0)
^DD("52.6","5","0")="ADMINISTRATION TIMES^FX^^0;6^X
$P(^DD(51.1,1,0),"^",5,999) Q" ^DD("52.6","5","3")="Answer must be 2-119
characters in length." ^DD("52.6","5","20","0")="^.3LA^1^1"
^DD("52.6","5","20","1","0")="PSJI"
^DD("52.6","5","21","0")="^^3^3^2910412^^^^" ^DD("52.6","5","21","1","0")="
Enter the admin. times that this drug is given m ost frequently. This"
^DD("52.6","5","21","2","0")="field will be shown as default for the 'ADMIN.
TIM ES: ' prompt during" ^DD("52.6","5","21","3","0")="ordry of IVPB's."
^DD("52.6","5","DT")="2910412"\n
****************
^DD(52.6 52.6 IV ADDITIVES
File 52.6 IV ADDITIVES INPUT TRANSFORM
Field 13 CONCENTRATION - ^DD(52.6,2,0)
^DD("52.6","13","0")="CONCENTRATION^FX^^0;10^K:X'=+X!(X>99999)!(X<0)!(X?.E1"."3
N
.N) X I $D(X) S PSIVX=X,Y=^DD(52.6,2,0),X=$P(^PS(52.6,D0,0),"^",3) D ENC^PSIV
D EN^DDIOL(" "_X_"/ML","","?0") S X=PSIVX_" "_X_"/ML" K PSIVX"
^DD("52.6","13","3")="Type a number between 0 and 99999 (no more than 2
decimal digits, and no trailing 0's are allowed)."\n
****************
^DD(50.4 50.4 DRUG ELECTROLYTES
File 52.6 IV ADDITIVES INPUT TRANSFORM
Subfile 52.62 Field 1 CONCENTRATION - ^DD(50.4,1,0)
^DD("52.62","1","0")="CONCENTRATION^RFX^^0;2^K:+X'=X!(X>99999)!(X<0)!(X?.E1"."5
N
.N) X I $D(X) S
PSIVX=X,Y=^DD(50.4,1,0),X=$P(^PS(50.4,+^PS(52.6,DA(1),2,DA,0),0) ,"^",2) D
ENC^PSIV S X=PSIVX_" "_X K PSIVX D STRTH^PSSDDUT2" ^DD("52.62","1","3")="Type
a number between 0 and 99999."\n
****************
^DD(59.723 59.7 PHARMACY SYSTEM
File 59.7 PHARMACY SYSTEM INPUT TRANSFORM
Subfile 59.723 Field .01 TO SERVICE - ^DD(59.723,.01,0) PSYS2 D
EN^DDIOL("(""From"" service is "_$S('$D(PS(59.7,D0,23,D1,0)):"UNKNOWN"
,$P(^(0),"^")]"":$P(^PS(";"_$P(^DD(59.723,.01,0),"^",3),";"_$P(^PS(59.7,D0,23,D
1
,0),"^")_":",2),";"),1:"UNKNOWN")_")")
Q\n
****************
^DD(55.01 55 PHARMACY PATIENT
File 52.6 IV ADDITIVES INPUT TRANSFORM
Field 4 USUAL IV SCHEDULE - ^DD(55.01,.09,0) ^DD("52.61","4","0")="USUAL IV
SCHEDULE^FX^^0;5^X $P(^DD(55.01,.09,0),"^",5,999)
"
^DD("52.61","4","3")="Answer must be 1-22 characters in length."
^DD("52.61","4","20","0")="^.3LA^1^1" ^DD("52.61","4","20","1","0")="PSJI"
^DD("52.61","4","21","0")="^^2^2^2910305^^^" ^DD("52.61","4","21","1","0")="
Enter the schedule that should be 'stuffed' int o the schedule field"
^DD("52.61","4","21","2","0")="of the IV order using this quick code."
^DD("52.61","4","DT")="2860223"\n
****************
^DD(50.4 50.4 DRUG ELECTROLYTES
File 52.7 IV SOLUTIONS INPUT TRANSFORM
Subfile 52.702 Field 1 CONCENTRATION - ^DD(50.4,1,0)
^DD("52.702","1","0")="CONCENTRATION^RFX^^0;2^K:+X'=X!(X>99999)!(X<0)!(X?.E1"."
5
N.N) X I $D(X) S
PSIVX=X,Y=^DD(50.4,1,0),X=$P(^PS(50.4,+^PS(52.7,DA(1),2,DA,0),0 ),"^",2) D
ENC^PSIV S X=PSIVX_" "_X K PSIVX D STRTH^PSSDDUT2" ^DD("52.702","1","3")="Type
a number between 0 and 99999."\n", "", "", ""], ["2160", "DBIA2160", "File", "KERNEL", "1997/09/30", "APPROVED", "Active", "Controlled Subscription", "", "
Order Entry uses ^XUTL("OR",$J,xxx where xxx is the
ancillary or support packages' namespace.", "", "", ""], ["2161", "HLFNC2", "Routine", "HEALTH LEVEL SEVEN", "1997/10/29", "APPROVED", "Active", "Supported", "", "", "", "HLFNC2", ""], ["2162", "HL7 MESSAGE TYPE", "File", "HEALTH LEVEL SEVEN", "1997/10/29", "", "Pending", "Supported", "771.2", "
The creation of new entries must be cleared through the
HL7 development team. New entries may be added with a call to FILE^DICN and a
call to IX1^DIK during the package post-installation.", "", "", ""], ["2163", "DBIA2163", "File", "QUALITY ASSURANCE INTEGRATION", "1997/12/09", "APPROVED", "Active", "Private", "740", "
Requesting permission to add two new fields in QA Site
Paramter file (#740) to store whether or not the station is multi-divisional
for the Incident Reporting package (namespace QAQ), and if yes, the names of
the Medical Centers within the NDBI Integration Group.", "", "", ""], ["2164", "HL7 MESSAGE ADMINISTRATION", "Routine", "HEALTH LEVEL SEVEN", "1997/10/30", "APPROVED", "Active", "Supported", "", "
API to generate a HL7 message.", "", "HLMA", ""], ["2165", "HL7 MESSAGE ADMINISTRATION", "Routine", "HEALTH LEVEL SEVEN", "1997/10/30", "APPROVED", "Active", "Supported", "", "
API to generate a HL7 acknowledgement message.", "", "HLMA1", ""], ["2166", "PATIENT ALLERGIES", "File", "ADVERSE REACTION TRACKING", "2006/03/10", "APPROVED", "Active", "Controlled Subscription", "120.8", "
The Baxter Sure-Med Pharmacy Interface needs to
reference a patient's allergies to transmit via HL7 segment message.", "", "", ""], ["2167", "ALLERGY SIGN/SYMPTOMS", "File", "ADVERSE REACTION TRACKING", "1997/10/30", "APPROVED", "Active", "Controlled Subscription", "120.83", "
The Baxter Sure-Med Pharmacy Interface is requesting
permission to retrieve the reaction for the HL7 AL1 segment message. It is
currently an optional field.", "", "", ""], ["2168", "HL7 DATA TYPE", "File", "HEALTH LEVEL SEVEN", "1997/10/30", "", "Pending", "Private", "771.4", "
The Baxter Sure-Med Pharmacy Interface requests an
agreement with the HL7 module to reference the HL7 Data Type file (#771.4).", "", "", ""], ["2169", "VERIFY PHARMACY ORDERS", "Routine", "INPATIENT MEDICATIONS", "1997/10/30", "", "Pending", "Private", "", "
The Baxter Sure-Med Pharmacy Interface requests
approval to copy program PSGVBW to VEFPVER and modify it to call HL7 RDE
segment API. This generates a RDE HL7 message to transmit to the Baxter
Sure-Med Dispensing Cabinet.", "", "PSGVBW", ""], ["2171", "DBIA2171", "Routine", "KERNEL", "1997/10/07", "APPROVED", "Active", "Supported", "", "
Function API's to access parts of the Institution file.\n
This DBIA documents some entry point for accessing the Institution file that
were requested by the CIRN developers or implemented by the IFR project.", "", "XUAF4", "2020/03/12"], ["2172", "DBIA2172", "Routine", "KERNEL", "1997/10/08", "APPROVED", "Active", "Supported", "", "
The routine XPDID contains calls to support the Kernel
Installation and Distribution System. All of the calls can only be used in
the context of the KIDS software.\n
INIT
This tag initializes the screen and draws the borders for the box and
draws the progress bar. It also creates a scrolling region in the box.
INPUT: none
OUTPUT: XPDIDVT=1 if output device supports graphics, =0 if not\n
TITLE(text)
This tag displays the text as a title at the top of the box.
INPUT: text
OUTPUT: none\n
EXIT(text)
This tag restore the screen to normal, cleans up all variables, and
displays the text.
INPUT: text
OUTPUT: none\n
UPDATE(current number of items)
This tag updates the progress bar to show the percentage complete of the
installation.
INPUT: current number of items
XPDIDTOT = total number of items\n
For example, if you are converting 100 records and want to update the user
every time you have completed 10% of the records you would do the following:\n
Set XPDIDTOT=100
F%=1:1:100 D CONVERT I'(%#10) D UPDATE^XPDID(%)", "", "XPDID", ""], ["2173", "DBIA2173", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Controlled Subscription", "52.7", "
This file was previously in Inpatient Meds versions up
to 5.0. Now it has moved to Pharmacy Data Management 1.0. It is used
extensively throughout our routines. With this move, we are requesting read
and write access to the entire file and cross-references via FileMan utilities
and direct writes/reads.", "", "", ""], ["2174", "DBIA2174", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Controlled Subscription", "50.606", "
Inpatient Medications request permission to look at
DOSAGE FORM file 50.606.\n
This file was previously in National Drug File. Now it has moved to Pharmacy
Data Management 1.0. It is used extensively throughout our routines. With
this move, we are requesting read and write access to the entire file and
cross-references via FileMan utilities and direct writes/reads.", "", "", ""], ["2175", "DBIA2175", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Private", "50.4", "
Inpatient Medications requests permission to look at
DRUG ELECTROLYTES file 50.4.\n
This file was previously in Inpatient Meds versions up to 5.0. Now it has
moved to Pharmacy Data Management 1.0. It is used extensively throughout our
routines. With this move, we are requesting read and write access to the
entire file and cross-references via FileMan utilities and direct
writes/reads.", "", "", ""], ["2176", "DBIA2176", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Private", "51", "
Inpatient Medications request permission to look at
MEDICATION INSTRUCTION file 51.\n
This file was previously in Inpatient Meds versions up to 5.0. Now it has
moved to Pharmacy Data Management 1.0. It is used extensively throughout our
routines. With this move, we are requesting read and write access to the
entire file and cross-references via FileMan utilities and direct
writes/reads.", "", "", ""], ["2177", "DBIA2177", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Private", "51.1", "
Inpatient Medications requests permission to look at
ADMINISTRATION SCHEDULE file 51.1.\n
This file was previously in Inpatient Meds versions up to 5.0. Now it has
moved to Pharmacy Data Management 1.0. It is used extensively throughout our
routines. With this move, we are requesting read and write access to the
entire file and cross-references via FileMan utilities and direct
writes/reads.", "", "", ""], ["2178", "DBIA2178", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Controlled Subscription", "51.2", "
Inpatient Medications request permission to look at
MEDICATION ROUTES file 51.2.\n
This file was previously in Inpatient Meds versions up to 5.0. Now it has
moved to Pharmacy Data Management 1.0. It is used extensively throughout our
routines. With this move, we are requesting read and write access to the
entire file and cross-references via FileMan utilities and direct
writes/reads.", "", "", ""], ["2179", "DBIA2179", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Private", "9009032.4", "
Inpatient Medications requests permission to look at
APSP INTERVENTION file 9009032.4.", "", "", "2025/05/28"], ["2180", "DBIA2180", "File", "PHARMACY DATA MANAGEMENT", "1997/10/14", "APPROVED", "Active", "Controlled Subscription", "50.7", "
Inpatient Medications request permission to look at
PHARMACY ORDERABLE ITEM file 50.7.\n
This is a new file with Pharmacy Data Management v1.0. It is used extensively
throughout our routines. We are requesting read and write access to the
entire file and cross-references via FileMan utilities and direct
writes/reads.", "", "", ""], ["2181", "DBIA2181", "File", "PHARMACY DATA MANAGEMENT", "1997/10/15", "APPROVED", "Active", "Private", "59.7", "
Inpatient Medications requests permission to look at
the following fields in the PHARMACY SYSTEM file 59.7.\n
Revisions: The CPRS33 project included updates to add two new fields, approved
by the DBA:
59.7,103 DURATION OVERRIDE HANDLING 62;1
59.7,104 DURATION OVERRIDE MESSAGE 62;2\n
The new fields will be used (read) by the INPATIENT MEDICATIONS application,
PSS*1*251 and PSJ*5.0*375.\n
FIELD NUMBER NAME NODE AND PIECE\n
59.7,20.01 IV STATS/200 CONVERSION STATUS 20;10
59.7,20.1 VERSION NUMBER LAST INITS RUN 20;1
59.7,20.11 NEW PERSON CONVERSION DATE 20;11
59.7,20.12 PRIMARY DRUG CONVERSION DATE 20;12
59.7,20.13 DATE V4 PRE-PACKET INSTALLED 20;13
59.7,20.14 LAST N-V ORDER CONVERTED TO V4 20;14
59.7,20.15 DATE NON-VERIFIED CONVERTED 20;15
59.7,20.16 ORDERABLE ITEM CONVERSION DATE 20;16
59.7,20.2 DATE INITS LAST RUN 20;2
59.7,20.3 USER TO LAST RUN INITS 20;3
59.7,20.4 SITE FOR BACKGROUND JOB 20;4
59.7,20.401 UD STATS/200 CONVERSION MARKER 20.4;1
59.7,20.402 IV STATS/200 CONVERSION STATUS 20.4;2
59.7,20.403 NEW PERSON CONVERSION DATE 20.4;3
59.7,20.404 LAST N-V ORDER CONVERTED TO V4 20.4;4
59.7,20.405 DATE NON-VERIFIED CONVERTED 20.4;5
59.7,20.406 LAST PAT CONVERTED FOR VER 4 20.4;6
59.7,20.407 LAST PICK LIST TO PD MARKER 20.4;7
59.7,20.408 DATE PICK LISTS CONVERT TO PD 20.4;8
59.7,20.409 ORDER SET CONVERSION MARKER 20.4;9
59.7,20.41 ORDER SET CONVERSION DATE 20.4;10
59.7,20.411 DATE UD STATS FILE CONVERTED 20.4;11
59.7,20.5 DATE ATC DATA CONVERTED 20;5
59.7,20.6 DEFAULT WARD 20;6
59.7,20.8 LAST PATIENT CONVERTED TO V4 20;8
59.7,20.9 UD STATS/200 CONVERSION STATUS 20;9
59.7,21 NON-FORMULARY MESSAGE 21;0
59.7,22 WARD ACTIONS 22;0
59.722,.01 FROM WARD 0;1
59.722,1 TO WARD 1;0
59.7221,.01 TO WARD 0;1
59.722,2 'ON PASS' ACTION 0;2
59.722,3 ACTION ON AUTHORIZED ABSENCE 0;3
59.722,4 ACTION ON UNAUTHORIZED ABSENCE 0;4
59.7,23 D/C ON SERVICE TRANSFER 23;0
59.723,.01 FROM SERVICE 0;1
59.723,1 TO SERVICE 1;0
59.7231,.01 TO SERVICE 0;1
59.7,25 INPATIENT ORDER NUMBER 25;E1,245
59.7,25.1 DATE 5.0 UD VER CONV FINISHED 20.5;1
59.7,25.2 DATE 5.0 CONVERSION COMPLETED 20.5;2
59.7,25.3 DATE 5.0 PICK LIST CONV FINISH 20.5;3
59.7,25.4 DATE 5.0 ORDER SET CONV FINISH 20.5;4
59.7,26 PRINT 6 BLOCKS FOR THE PRN MAR 26;1
59.7,26.2 ATC SORT PARAMETER 26;2
59.7,26.3 PRINT DIET ABBR LABEL ON MAR 26;3
59.7,26.4 MAR SORT 26;4
59.7,26.5 CALC UNITS NEEDED PRN ORDERS 26;5
59.7,26.6 DAYS UNTIL STOP FOR ONE-TIME 26;6
59.7,26.7 ROUND ATC PICK LIST UNITS 26;7
59.7,26.8 EFD SCHEDULE 26;8
59.7,30.1 DATE IV ORDERS CONVERTED 30;1
59.7,30.2 LAST PATIENT CONVERTED (IV) 30;2
59.7,31 DAYS TO RETAIN IV STATISTICS 31;1
59.7,32 IV IDENTIFIER 31;2
59.7,34 EXPIRED IV TIME LIMIT 31;4
59.7,60.02 LAST PAT CONVERTED FOR VER 4 60;2
59.7,61.2 DAYS NEW LABELS LAST 61;2
59.7,63.51 PICK LIST AUTO-PURGE 63.5;1
59.7,63.52 DATE/TIME AUTO-PURGE EDITED 63.5;2
59.7,63.53 USER LAST EDITING AUTO-PURGE 63.5;3
59.7,63.54 DATE PICK LIST LAST FILED AWAY 63.5;4
59.7,64 PARAM FILE CONVERSION STATUS 20.4;12
59.7,65 PICK LIST CONVERSION DATE 20.4;13
59.7,66 V4.5 PICK LIST CONVERT MARKER 20.4;14
59.7,67 V4.5 PICK LIST CONVERT STATUS 20.4;15
59.7,80 PSS VERSION 80;1
59.7,81 ORDERABLE ITEM STATUS TRACKER 80;2
59.7,103 DURATION OVERRIDE HANDLING 62;1
59.7,104 DURATION OVERRIDE MESSAGE 62;2\n
Use of input template PSJ OAOPT is also requested.\n
GLOBAL MAP DATA DICTIONARY #59.7 -- PHARMACY SYSTEM FILE 10/17/97 STORED
IN ^PS(59.7, (1 ENTRY) SITE: SALT LAKE ISC UCI: OEX,OER
--------------------------------------------------------------------------
This file contains data that pertains to the entire Pharmacy system of a
medical center, and not to any one site or division. The number ranges
for the nodes and field numbers are as follows:\n
0 - 9.99 RESERVED
10 - 19.99 National Drug File
20 - 29.99 Inpatient
30 - 39.99 IV's
40 - 49.99 Outpatient
50 - 59.99 Ward Stock/AR
60 - 69.99 Unit Dose
70 - 79.99 Drug Accountability
80 - 89.99 Pharmacy Data Management", "", "", "2023/08/17"], ["2182", "CLINICAL REMINDERS APIs", "Routine", "CLINICAL REMINDERS", "1998/01/14", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXRM", "2012/06/27"], ["2183", "DBIA2183", "File", "INPATIENT MEDICATIONS", "1997/10/15", "", "Pending", "Private", "3.081", "
Drug Accountability/Inventory Interface v3.0 is
requesting an integration agreement to read the SIGN-ON LOG FILE's (#3.081)
^XUSEC("PSJ RPHARM") node. It is used to determine if the user holds the
pharmacist key.", "", "", ""], ["2184", "DBIA2184", "Other", "DRG GROUPER", "1997/10/15", "APPROVED", "Active", "Private", "", "
Clinical Reminders use the application group PXRS for
screening taxonomy selections. The following files need to belong to this
application group: File 80 - ICD DIAGNOSIS, File 80.1 - ICD
OPERATION/PROCEDURE File 81 - CPT", "", "", ""], ["2185", "DBIA2185", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1997/10/16", "APPROVED", "Active", "Private", "", "
Inpatient Medications requests permission to call
PSJQOS^ORCONV3. This entry point passes Unit Dose Order Set information to
OERR to allow the creation of Quick orders from each Order Set. Inpatient
Meds receives no output from this call. The data passed is described below.\n
^TMP("PSJQOS",$J,"NM")=ORDER SET NAME ^TMP("PSJQOS",$J,#,1)=ORDERABLE ITEM
IEN^MED ROUTE IEN^
SCHEDULE ^DOSAGE ORDERED ^TMP("PSJQOS",$J,#,2)=SPECIAL
INSTRUCTIONS ^TMP("PSJQOS",$J,#,3)=DISPENSE DRUG IEN^UNITS PER DOSE", "", "ORCONV3", ""], ["2186", "DBIA2186", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1997/10/16", "APPROVED", "Active", "Supported", "", "
This routine has a number of supported entry points to
support package interfaces with CPRS.", "", "ORX1", ""], ["2187", "DBIA2187", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1997/10/16", "APPROVED", "Active", "Supported", "", "
This is a supported entry point for use by packages
interfacing with CPRS.", "", "ORERR", ""], ["2188", "DBIA2188", "Routine", "OUTPATIENT PHARMACY", "1997/10/16", "APPROVED", "Active", "Private", "", "
Inpatient Medications requests permission to call
(Outpatient Pharmacy) EN^PSOHLNEW. This entry point allows the order message
array from OERR to be passed to Outpatient Pharmacy for processing. All
message arrays from OERR come through the Inpatient Meds routine. The PATIENT
CLASS field comes in the array from OERR. If the value is "I", it is
processed as an Inpatient Order. If the value is "O" this call is made to
process the order as an Outpatient order. Variables are described below.\n
Input: EN^PSOHLNEW(.MSG)\n
MSG - The message array from OERR.\n
Output: none", "", "PSOHLNEW", ""], ["2189", "DBIA2189", "Routine", "OUTPATIENT PHARMACY", "1997/10/17", "APPROVED", "Active", "Private", "", "
Inpatient Medications request permission to call
(Outpatient Pharmacy) EN^PSODRDU2. If the inpatient has a drug-drug
interaction, drug class, or duplicate drug with an outpatient order with call
is made. The call displays the outpatient order's information. The call
occurs during the inpatient order entry. Variables are described below.\n
Input: EN^PSODRDU2(DFN,RXNUM)\n
DFN - Patient's internal entry number is ^DPT. RXNUM - P1_P2_;_P3
where P1= Order number
P2= Order Type, either "P" for pending or "R" for active RX
P3= Pharmacy package code, either "I" or "O"\n
Output: none", "", "PSODRDU2", ""], ["2190", "DBIA2190", "Routine", "OUTPATIENT PHARMACY", "1997/10/21", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
Inpatient Medications request permission to call (Outpatient Pharmacy)
^PSOORDRG. This call returns drug-drug order checks.", "", "PSOORDRG", ""], ["2191", "DBIA2191", "File", "PHARMACY DATA MANAGEMENT", "1997/10/21", "APPROVED", "Active", "Private", "55", "
This file is used extensively throughout our routines.
We request read and write access to the entire file and cross-references via
FileMan utilities and direct writes/reads.\n
The fields we use are listed below. The UNIT DOSE multiple and IV multiple
represent the majority of the fields in the file. Because they are so
numerous, we would like full access to the file.", "", "", ""], ["2192", "DBIA2192", "File", "PHARMACY DATA MANAGEMENT", "1997/10/21", "APPROVED", "Active", "Private", "50", "
This file was previously under Outpatient Pharmacy.
Now, Pharmacy Data Management 1.0 sends it out. This file is used extensively
throughout our routines. We use a majority of the fields in this file. We
request read and write access to the entire file, cross-references and
templates via FileMan utilities and direct writes/reads.", "", "", ""], ["2193", "DBIA2193", "Routine", "INPATIENT MEDICATIONS", "1997/10/22", "", "Pending", "Private", "", "
Drug Accountability/Inventory Interface is requesting
an integration agreement with Inpatient Medications to insert two lines of
code in routine PSGAMSA. This code is used to collect Unit Dose dispensing,
returns, extras, & pre-exchange needs.", "", "PSGAMSA", ""], ["2194", "DBIA2194", "Routine", "INPATIENT MEDICATIONS", "1997/10/22", "", "Pending", "Private", "", "
Drug Accountability/Inventory Interface is requesting
an integration agreement with Inpatient Medications to insert a line of code
in routine PSGPLF. This code is used to collect Unit Dose dispensing, returns,
extras, & pre-exchange needs.\n
Existing Code at FILE+9
-----------------------
S $P(ND,"^",2+PS)=$P(ND,"^",2+PS)+Y,$P(ND,"^",3+PS)=$P(ND,"^",3+PS)+COSD
1,1,D2,1,D3,0) G:Z OS\n
Inserted Code at FILE+9:FILE+12
------------------------------
S $P(ND,"^",2+PS)=$P(ND,"^",2+PS)+PSGY,$P(ND,"^",3+PS)=$P(ND,"^",3+PS)
+COST,^PS(57.6,D0,1,D1,1,D2,1,D3,0)=ND L -^PS(57.6,D0,1,D1,1,D2,1,D3,0)
I +$$VERSION^XPDUTL("DRUG ACCOUNTABILITY")'<3.0 D
.I $D(^%ZOSF("TEST")) S X="PSAPSI5" X ^%ZOSF("TEST") K X I S PSGRTN=
"PSGPLF" D EN^PSAPSI5 K PSGRTN
G:PSGZ OS", "", "PSGPLF", ""], ["2195", "DBIA2195", "File", "NATIONAL DRUG FILE", "1997/10/22", "APPROVED", "Active", "Controlled Subscription", "50.6", "
Inpatient Medications requests access to file 50.6
NATIONAL DRUG.", "", "", ""], ["2196", "DBIA2196", "File", "NATIONAL DRUG FILE", "1997/10/22", "APPROVED", "Active", "Controlled Subscription", "50.416", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.\n
Inpatient Medications requests access to file 50.416, DRUG INGREDIENTS.", "", "", ""], ["2197", "CPRS needs Install Start Time", "File", "KERNEL", "1997/10/25", "APPROVED", "Active", "Controlled Subscription", "9.7", "
Currently, the only way to get the start and completion
date of an install is to get the IEN of the build and reference the fields
directly.", "", "", ""], ["2198", "TEST FOR BROKER CONTEXT", "Routine", "RPC BROKER", "1997/11/19", "APPROVED", "Active", "Supported", "", "
Use this function in the M code called by an RPC to
determine if the current process is being executed by the Broker.", "", "XWBLIB", ""], ["2199", "CPRS checks for CMOP activation", "File", "CMOP", "1997/10/27", "APPROVED", "Active", "Private", "550", "
CPRS checks to see whether CMOP is activated or not to
determine whether to default meds for mail or window pick-up. The
installation of CPRS also makes a check to ensure that CMOP is inactivated
prior to installation.", "", "", ""], ["2200", "DBIA2200", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Controlled Subscription", "", "
The Outpatient Pharmacy package makes a call to the
CMOP routine, PSXOPUTL to get CMOP data from the pharmacy files. This data is
used when displaying the Rx profile to the screen.", "", "PSXOPUTL", ""], ["2201", "DBIA2201", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSOLBL, calls the CMOP
routine, PSXSRP to make the activity log entry in the Prescription file (#52)
when labels are reprinted using the Outpatient Pharmacy option Reprint Batches
from Suspense [PSO PNDRPT]. This call doesn't pass variables.", "", "PSXSRP", ""], ["2202", "DBIA2202", "Routine", "CMOP", "1997/10/28", "", "Pending", "Private", "", "
The Outpatient Pharmacy package routine, PSOORNE3,
calls the CMOP routine, PSXOPUTL to get CMOP information from the Outpatient
Pharmacy files and the CMOP files. This information is used to display
information about CMOP prescriptions.", "", "PSXOPUTL", ""], ["2203", "DBIA2203", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSOORUT1, calls the
CMOP routine, PSXOPUTL, to get CMOP data from the Outpatient Pharmacy and CMOP
files. This data is used by the OERR interface.", "", "PSXOPUTL", ""], ["2204", "DBIA2204", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSORXPR, calls the
CMOP routine, PSXVIEW, to get CMOP data from the Outpatient Pharmacy and CMOP
files. This data is displayed when viewing Rx's. The only variable passed in
this call is DA. The PSXVIEW routine displays the information on the screen.", "", "PSXVIEW", ""], ["2205", "DBIA2205", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSOSUCHG, calls the
CMOP routine, PSXCH to screen Rx's for CMOP when changing the suspense date
for Rx's. Suspense dates cannot be changed for CMOP prescriptions if the CMOP
suspense status is "TRANSMISSION COMPLETED" or "LOADING FOR TRANSMISSION".", "", "PSXCH", ""], ["2206", "DBIA2206", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSOSUCH1, calls the
CMOP routine, PSXCH, to screen Rx's when changing the suspense date.", "", "PSXCH", ""], ["2207", "DBIA2207", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSOSULB1, calls the
CMOP routine, PSXRSUS if the site is using the CMOP software. This call
displays the CMOP Print from Suspense file options.", "", "PSXRSUS", ""], ["2208", "DBIA2208", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSOSURST, calls the
CMOP routine, PSXRPPL1 if the site is using the CMOP software. This call
displays the CMOP Reprint Batches from Suspense options.", "", "PSXRPPL1", ""], ["2209", "DBIA2209", "Routine", "CMOP", "1997/10/28", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy routine, PSORXED, calls the
CMOP routine, PSXEDIT. This call will screen Rx's for CMOP when editing the
Rx.", "", "PSXEDIT", ""], ["2210", "FILE 62", "File", "LAB SERVICE", "2006/03/01", "", "Retired", "Private", "62", "", "", "", ""], ["2211", "DBIA2211", "Routine", "OUTPATIENT PHARMACY", "1997/10/29", "APPROVED", "Active", "Private", "", "
Inpatient Medications requests permission to call
(Outpatient Pharmacy) ^PSOORDA. This call builds the ^TMP("PSJAL" and
^TMP("PSJDA" globals that contain the patients Allergy/Adverse Reaction
information to display on the ListMan screen.", "", "PSOORDA", ""], ["2212", "NEW PERSON editing", "File", "KERNEL", "1997/10/29", "APPROVED", "Active", "Private", "200", "
With patch XM*7.1*50, MailMan will be dropping phone
and address fields from its MAILBOX file 3.7 and would like to let users edit,
instead, various fields in the NEW PERSON file 200.\n
The fields are:\n
31.3 preferred editor .111 street address 1 .112 street address 2 .113
street address 3 .114 city .115 state .116 zip .132 office phone .133
phone #3 .134 phone #4 .136 fax # .137 voice pager .138 digital pager\n
I intend to let the user edit the fields using a FileMan call. I intend to
retrieve the data by direct global reads. One global access will retrieve the
record with the address fields; the other, the record with the phone numbers.
I will not be retrieving the data for the preferred editor.", "", "", ""], ["2213", "XRTL SET TO FORCE RESPONSE TIME MONITORING", "Other", "TOOLKIT", "1997/10/29", "APPROVED", "Active", "Private", "", "
XRTL=1 is a flag that allows response time monitoring.
It is typically set during signon based on a flag in the Kernel Site Parameter
file.\n
Because resource utilization must be monitored closely in the new
client/server environment, the RPC Broker needs to NEW and SET the XTRL
variable in its code. This will allow for the monitoring of all RPCs. (The
README file that accompanies version 1.1 of the RPC Broker notifies IRM staff
that the monitoring is being turned on.)\n
When sufficient data has been collected the SETting of XTRL will be removed by
a patch.", "", "", ""], ["2214", "DBIA2214", "File", "ADVERSE REACTION TRACKING", "1997/10/30", "APPROVED", "Active", "Private", "120.8", "
The Outpatient Pharmacy package request permission to
look at the PATIENT ALLERGY file 120.8 for the purpose of its drug-allergy
check functionality.", "", "", ""], ["2215", "INTEGRATION BILLING ACTION FILE ACCESS", "File", "INTEGRATED BILLING", "1997/10/30", "APPROVED", "Active", "Private", "350", "
The Outpatient Pharmacy package requests permission to
look at the INTEGRATED BILLING ACTION file 350.", "", "", "2018/03/09"], ["2216", "DBIA2216", "File", "INTEGRATED BILLING", "1997/10/30", "APPROVED", "Active", "Private", "350.3", "
The Outpatient Pharmacy package requests access to the
Pharmacy Copayment charge cancellation reasons that are stored in the IB
CHARGE REMOVE REASONS (#350.3) file. Pharmacy needs to conduct two look-ups
on this file. The first look-up allows the user to select a Pharmacy
Copayment charge cancellation reason from this file. The second look-up is
conducted internally by the application to find the entry RX DELETED from this
file, when a prescription is deleted or returned to stock.", "", "", ""], ["2217", "DBIA2217", "File", "LAB SERVICE", "1997/10/30", "", "Withdrawn", "Private", "60", "
The Outpatient Pharmacy package request permission to
look at the LABORATORY TEST file 60.", "", "", ""], ["2218", "DBIA2218", "File", "LAB SERVICE", "1997/10/30", "", "Withdrawn", "Private", "63.04", "
The Outpatient Pharamcy package request permission to
look at the LAB DATA file 63.", "", "", ""], ["2219", "DBIA2219", "File", "ORDER ENTRY/RESULTS REPORTING", "1997/11/03", "APPROVED", "Active", "Controlled Subscription", "100", "
The Outpatient Pharmacy package request permission to
look at ORDER file 100.", "", "", ""], ["2220", "DBIA2220", "Routine", "SCHEDULING", "1998/04/01", "APPROVED", "Active", "Private", "", "\n
Integration agreement to use the variables SDSTPAMB, SDIEMM, VALQUIET
in the routine SCDXHLDR.\n
SDSTPAMB prevents Scheduling/Amb Care from sending an Event
Capture patient procedure to the Austin NPCD for workload credit.
However, the patient procedure is still filed in the respective
Scheduling/PCE files.\n
SDIEMM is used to prevent the validation checks from executing during
the Event Capture conversion completed as part of the install of
EC*2*7.\n
VALQUIET is used to prevent the validation dialogue from displaying to
the user during Event Capture patient record edit processing.", "", "SCDXHLDR", ""], ["2221", "DBIA2221", "File", "NATIONAL DRUG FILE", "1997/11/03", "APPROVED", "Active", "Controlled Subscription", "50.607", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.\n
The Outpatient Pharmacy package request permission to look at DRUG UNITS file
50.607.\n
We need the individual drug unit of a drug when building our segments for HL7
data transmission.", "", "", ""], ["2222", "DBIA2222", "File", "PHARMACY DATA MANAGEMENT", "1997/11/03", "", "Retired", "Private", "50.606", "
The Outpatient Pharmacy package request permission to
look at DOSAGE FORM file 50.606.\n
This file was previously in National Drug File, but now it has been moved to
Pharmacy Data Management 1.0. It is used extensively throughout our routines.
Therefore, we are requesting read/write access to the entire file and
cross-references through Fileman and direct reads/write.", "", "", ""], ["2223", "DBIA2223", "File", "PHARMACY DATA MANAGEMENT", "1997/11/03", "APPROVED", "Active", "Private", "50.7", "
The Outpatient Pharmacy package request permission to
look at PHARMACY ORDERABLE ITEM file 50.7.\n
This is a new file of Pharmacy Data Management 1.0. It is used extensively
throughout our routines. We are requesting read/write access to the entire
file and cross-references through direct reads/writes and VA Fileman
utilities.", "", "", ""], ["2224", "DBIA2224", "File", "PHARMACY DATA MANAGEMENT", "1997/11/03", "APPROVED", "Active", "Private", "51", "
The Outpatient Pharmacy package request permission to
look at MEDICATION INSTRUCTION file 51.", "", "", ""], ["2225", "DBIA2225", "File", "PHARMACY DATA MANAGEMENT", "1997/11/03", "APPROVED", "Active", "Private", "51.1", "
The Outpatient Pharmacy package request permission to
look at ADMINISTRATION SCHEDULE file 51.1.\n
We use the 'B' cross reference to $Order through the file to get the expansion
of the Administration Schedule for the prescription.", "", "", ""], ["2226", "DBIA2226", "File", "PHARMACY DATA MANAGEMENT", "1997/11/03", "APPROVED", "Active", "Private", "51.2", "
The Outpatient Pharmacy package request permission to
look at MEDICATION ROUTES file 51.2.", "", "", ""], ["2227", "DBIA2227", "File", "PHARMACY DATA MANAGEMENT", "1997/11/04", "APPROVED", "Active", "Controlled Subscription", "54", "
This Outpatient Pharmacy package request permission to
look at RX CONSULT file 54.", "", "", ""], ["2228", "DBIA2228", "File", "PHARMACY DATA MANAGEMENT", "2005/11/14", "APPROVED", "Active", "Controlled Subscription", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
The Outpatient Pharmacy and CMOP packages request full access to PHARMACY
PATIENT file 55. This file is used extensively throughout our routines.
Therefore, we request read and write access to the entire file and cross
references through Fileman utilities and direct reads/writes.", "", "", ""], ["2229", "DBIA2229", "File", "NATIONAL DRUG FILE", "1997/11/04", "APPROVED", "Active", "Private", "56", "
The Outpatient Pharmacy package request permission to
look at DRUG INTERACTION file 56.", "", "", ""], ["2230", "DBIA2230", "File", "CMOP", "1997/11/04", "APPROVED", "Active", "Private", "550", "
The Outpatient Pharmacy package request permission to
look at CMOP SYSTEM file 550.", "", "", ""], ["2231", "DBIA2231", "File", "CMOP", "1997/11/04", "APPROVED", "Active", "Controlled Subscription", "550.2", "
The Outpatient Pharmacy package request permission to
look at CMOP TRANSMISSION file 550.2.", "", "", ""], ["2232", "Resource Device", "Routine", "KERNEL", "1997/11/05", "APPROVED", "Active", "Supported", "", "
This IA describes some API's to support Resource
devices.", "", "XUDHSET", ""], ["2233", "DBIA2233", "File", "REGISTRATION", "1997/11/06", "APPROVED", "Active", "Controlled Subscription", "43", "
DSS Extracts has permission to execute a direct global
read to the MULTIDIVISIONAL MED CENTER? field (#43) (GL;2) in the MAS
PARAMETERS file (#43).", "", "", ""], ["2234", "DBIA2234", "File", "REGISTRATION", "1997/11/06", "", "Retired", "Private", "408.32", "
DSS Extracts has permission to execute a direct global
read to the CODE field (#.02) (O;2) in the MEANS TEST STATUS file (#408.32).", "", "", ""], ["2235", "DBIA2235", "File", "KERNEL", "1997/11/06", "APPROVED", "Active", "Private", "4", "
This agreement gives permission to execute a $Order
direct global read of the 'LOC' Cross Reference on the Institution file (#4).\n
In addition, editing of the CURRENT LOCATION field (#720) in the Institution
file, using supported FileMan calls, is also allowed. Edits to this field
affect the 'LOC' Cross Reference by setting or killing it as needed.", "", "", "2017/08/14"], ["2236", "DBIA2236", "Routine", "SCHEDULING", "1998/04/01", "APPROVED", "Active", "Private", "", "\n
Integration agreement to use the function $$OKTOXMIT^SCDXFU04 to
determine if Event Capture patient procedures are to be sent to the
Austin NPCD for workload credit.\n
This integration agreement is used solely by the Event Capture Patient
file (#721) clean up patch, EC*2*7.", "", "SCDXFU04", ""], ["2237", "DBIA2237", "File", "SURGERY", "1997/11/06", "APPROVED", "Active", "Controlled Subscription", "133", "
DSS Extracts has permission to execute direct global
reads of the SITE field (#.01) (0;1) and the 'B' Cross Reference on the
SURGERY SITE file (#133).", "", "", ""], ["2238", "CHANGE RPC RETURN TYPE", "Routine", "RPC BROKER", "1997/11/19", "APPROVED", "Active", "Supported", "", "
Use this function in the M code called by an RPC to
change the return value type that the RPC will return on the fly.", "", "XWBLIB", ""], ["2239", "XWBAPVER -- RPC VERSION", "Other", "RPC BROKER", "1997/11/19", "APPROVED", "Active", "Supported", "", "
XWBAPVER is a documented variable that will contain an
RPC version if one was set in the client application (using the RPCVersion
property). Otherwise XWBAPVER defaults to 0.", "", "", ""], ["2240", "ENCRYPTING -- CLIENT/SERVER", "Routine", "KERNEL", "1997/11/19", "APPROVED", "Active", "Supported", "", "
Kernel and the RPC Broker provide encryption functions
that can be used to encrypt messages sent between the client and the server.\n
This function encrypts a string before transport to a Client system, where it
will be decrypted.", "", "XUSRB1", ""], ["2241", "DECRYPTING -- CLIENT/SERVER", "Routine", "KERNEL", "1997/11/19", "APPROVED", "Active", "Supported", "", "
Kernel and the RPC Broker provide encryption functions
that can be used to encrypt messages sent between the client and the server.\n
This function decrypts a string that was encrypted on a Client system.", "", "XUSRB1", ""], ["2242", "DBIA2242", "Routine", "REGISTRATION", "1997/11/20", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will provide temporary entry points to
routine DGSEC to enable the listed packages to update the DG SECURITY LOG when
a sensitive patient has been accessed.\n
This will be in effect until supported entry points are defined.", "", "DGSEC", ""], ["2243", "Tasking KIDS Installation", "Routine", "KERNEL", "1997/12/03", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this DBIA is to document the use of a
KIDS entry point to task off a KIDS Install. This is useful if a large
conversion needs to run in background while users are back on the system. For
example, the first KIDS build can install a new version of software, then task
off a second clean-up/conversion build. This allows users back on the system
because the new version install completes and unlocks options and protocols.
Meanwhile the clean-up runs in background under KIDS and makes use of KIDS
checkpoints, restart upon failure, and message logging that can later be
accessed in the Install File Print.", "", "XPDIJ", ""], ["2244", "PATIENT REPRESENTATIVE", "File", "QUALITY ASSURANCE INTEGRATION", "1997/12/04", "", "Retired", "Private", "740", "
I am the developer for the Quality Assurrance packages.
I had previouly gotten an agreement to use two fields in the QA Site Parameter
file (#740) to keep multi-divisional information fot the Patient
Representative package. The Integration agreement is #2073. File 740 is part
of the Integration Module. Both of these packages are in the Quality
Assurrance group, the agreements are to keep a documentation trail. It turns
out that the two fields in the agreement (741.1 and 741.11) are on the "OS"
nodes, which are still being used by some stations for Occurrance Screening.
I have decided to create comparable fields on the "QAC" nodes to provide the
same functionality. The new fields are
#749 MULTI-DIVISIONAL PAT REP FACILITY
#750 PAT REP HOSPITAL DIVISION", "", "", ""], ["2245", "DBIA2245", "Routine", "INTEGRATED BILLING", "1997/12/09", "APPROVED", "Active", "Private", "", "
Outpatient Pharmacy requests permission to pass an
internal entry number from the SERVICE/SECTION File (#49) to Integrated
Billing, and have a flag returned that indicates if the service can be used
for Copay billing in Outpatient Pharmacy.", "", "IBARX1", ""], ["2246", "DBIA2246", "File", "KERNEL", "1998/01/07", "APPROVED", "Active", "Controlled Subscription", "19", "
Inpatient Medications requests permission to $O through
the OPTION file (#19), "B" cross reference. We also request Write access by
VA FileMan to the OUT OF ORDER MESSAGE field (#2). In version 5.0, this code
is used to disable options during the pre install routine and enable them in
the post install routine. The group of options that deal with Pick Lists are
inactivated during the pre install routine. The options cannot be enabled
until the end of the Pick List conversion, which is hours after the KIDS
install finishes. The last task of the Pick List conversion routine is to
enable the Pick List options again. This is needed to keep the users from
processing any Pick Lists until the conversion is completely finished. Making
the edit to the OUT OF ORDER MESSAGE FIELD seems to be the only way to
accomplish this job.", "", "", ""], ["2247", "DBIA-2247", "File", "KERNEL", "1997/12/09", "APPROVED", "Active", "Controlled Subscription", "3.2", "
Outpatient Pharmacy package request permission to look
at TERMINAL TYPE file 3.2.", "", "", ""], ["2248", "DBIA 2248", "Routine", "REGISTRATION", "1997/12/12", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement gives permission to use registration
software to determine Facility Treating Specialty file (#45.7) and Specialty
file (#42.4) properties.\n
Line tag ACTIVE^DGACT will determine if a Facility Treating Specialty or
Specialty is active on a specific date.\n
Line tag TSDATA^DGACT returns Facility Treating Specialty or Specialty;
whether the node exits, active on a specific date, associated properties.", "", "DGACT", "2010/05/20"], ["2249", "DBIA-2249", "File", "REGISTRATION", "1997/12/09", "APPROVED", "Active", "Private", "405", "
Outpatient Pharmacy package request permission to read
the 'AMV1' and 'APTT1' cross references of REGISTRATION file 405.", "", "", ""], ["2250", "DBIA2250", "File", "KERNEL", "1997/12/09", "APPROVED", "Active", "Private", "49", "
Outpatient Pharmacy requests permission to access data
in the SERVICE/SECTION (#49) file.\n
One use will be to loop through the file to retrieve internal entry numbers to
be used for a call to Integrated Billing to find the correct entry necessary
to process Co-pay prescriptions in Pharmacy.\n
Another will be to access the names of the file entries in order to provide
complete demographic information for an outpatient site through the Pharmacy
Reengineering APIs.\n", "", "", "2011/01/21"], ["2251", "DBIA-2251", "File", "KERNEL", "2003/08/25", "APPROVED", "Active", "Controlled Subscription", "4", "
Outpatient Pharmacy package request permission to look
at INSTITUTION file 4 to get the Institution name and/or station number.", "", "", ""], ["2252", "DBIA2252", "File", "KERNEL", "1997/12/16", "APPROVED", "Active", "Private", "7", "
This request is so that the Laboratory Package to be
able to read from the ^DIC(7, global. The purpose of this would be to take
the second piece of the zero node, ^DIC(7,D0,0)= (#.01) NAME [1F] ^ (#1)
ABBREV. TITLE [2F] ^ to append onto the Pathologist's Name on the various
Pathology reports.\n
This should be a temporary request and can be revisited when the Anatomic
Pathology reports incorporate electronic signature.", "", "", ""], ["2253", "DBIA2253", "File", "1", "1997/12/30", "APPROVED", "Active", "Private", "55.06", "
Inpatient Medications requests permission to call
routine ^DIC with the variable DIC defined as "^DD(55.06," and DIC(0)="QEM" or
DIC(0)="QE". This will perform a lookup on the field names of a particular
file and return the needed variables. This is used in our routines to allow a
user to up-arrow jump to another field during the editing of an order.
Example: The user is editing an order and enters "^STA". The ^DIC lookup is
performed, finds the START DATE field, and returns the field's internal entry
number. That number is then used to go to the appropriate code to edit that
field.", "", "DIC", ""], ["2254", "DBIA-2254", "File", "PHARMACY DATA MANAGEMENT", "1997/12/09", "", "Retired", "Private", "50.5", "
Outpatient Pharmacy package request permission to look
at DRUG CLASSIFICATION file 50.5 via direct global read and Fileman.", "", "", ""], ["2255", "DBIA2255", "File", "1", "1997/12/30", "APPROVED", "Active", "Private", "0", "
Inpatient Medications requests direct read access to
pharmacy files node ^DD(file #,field #,12). We are reading from this node to
return the POINTER SCREEN description.", "", "", ""], ["2256", "DBIA2256", "File", "1", "1997/12/31", "APPROVED", "Active", "Private", "53.1", "
Inpatient Medications requests permission to call
routine ^DIC with the variable DIC defined as "^DD(53.1," and DIC(0)="QEM".
This will perform a lookup on the field names of a particular file and return
the needed variables. This is used in our routines to allow a user to
up-arrow jump to another field during the editing of an order. Example: The
user is editing an order and enters "^STA". The ^DIC lookup is performed,
finds the START DATE field, and returns the field's internal entry number.
That number is then used to go to the appropriate code to edit that field.", "", "", ""], ["2257", "DBIA2257", "Routine", "OUTPATIENT PHARMACY", "1998/01/06", "APPROVED", "Active", "Private", "", "
Inpatient Medications requests permission to call
INPAT^PSOBUILD. This entry point is used to display a patient's current
Outpatient medications.\n
Input variable: PSODFN Output variable: <none>", "", "PSOBUILD", ""], ["2258", "DBIA2258", "Routine", "OUTPATIENT PHARMACY", "1998/01/06", "APPROVED", "Active", "Private", "", "
Inpatient Medications requests permission to call
^PSOVWI (Outpatient Pharmacy). This entry point is used to display a Pharmacy
intervention in a captioned format.", "", "PSOVWI", ""], ["2259", "DBIA2259", "Other", "OUTPATIENT PHARMACY", "1998/01/06", "APPROVED", "Active", "Private", "", "
Inpatient Medications requests permission to use the
following Outpatient Pharmacy templates. These templates are used by Inpatient
Medications to Enter, Edit, and Print Pharmacy interventions.\n
Input Template [PSO INTERVENTION EDIT] [PSO INTERVENTION NEW]\n
Print Template [PSO INTERVENTIONS]\n
Sort Template [PSO INTERVENTIONS]\n
These templates are used by the following Inpatient Medication protocols:\n
PSJ LM INTERVENTION EDIT PSJ LM INTERVENTION NEW ENTRY PSJ LM INTERVENTION
PRINTOUT PSJ LM INTERVENTION VIEW", "", "", ""], ["2260", "DBIA1030-D", "Routine", "OUTPATIENT PHARMACY", "1998/01/09", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point is used to build an Outpatient
prescription profile for a patient. The profile is returned in the form of an
array, named PSOSD.", "", "PSORX1", ""], ["2261", "Print Med Instruction Sheet", "Routine", "NATIONAL DRUG FILE", "1998/01/09", "APPROVED", "Active", "Private", "", "
This IA will be used in the Outpatient Pharmacy package
to print medication instruction sheets.", "", "PSNPPIP", ""], ["2263", "SUPPORTED PARAMETER TOOL ENTRY POINTS", "Routine", "TOOLKIT", "1998/01/11", "APPROVED", "Active", "Supported", "", "
Parameter Tools is a generic method of handling
parameter definition, assignment, and retrieval. A parameter may be defined
for various entities where an entity is the level at which you want to allow
the parameter defined (e.g. package level, system level, division level,
location level, user level, etc.). A developer may then determine in which
order the values assigned to given entities are interpreted. The following
are some basic definitions used by Parameter Tools:\n
Entity:
=======
An entity is a level at which you can define a parameter. The entities
allowed are stored in the Parameter Entity file (#8989.518). The list of
allowable entities at the time this utility was released were:\n
Prefix Message Points to File
------- ---------- ------------------------
PKG Package Package (9.4)
SYS System Domain (4.2)
DIV Division Institution (4)
SRV Service Service/Section (49)
LOC Location Hospital Location (44)
TEA Team Team (404.51)
CLS Class Usr Class (8930)
USR User New Person (200)
BED Room-Bed Room-Bed (405.4)
OTL Team (OE/RR) OE/RR List (101.21)\n
(Note: entries will be maintained via ToolKit patches. Entries
existing in the file at the time it is referenced are
considered supported.)\n
Parameter:
==========
A parameter is the actual name which values are stored under. The name
of the parameter must be namespaced and it must be unique. Parameters
can be defined to store the typical package parameter data (e.g. the
default add order screen in OE/RR), but they can also be used to store
GUI application screen settings a user has selected (e.g. font or window
width). When a parameter is defined, the entities which may set that
parameter are also defined. The definition of parameters is stored in
the PARAMETER DEFINITION file (#8989.51).\n
Value:
======
A value may be assigned to every parameter for the entities allowed in
the parameter definition. Values are stored in the PARAMETERS file
(#8989.5).\n
Instance:
=========
Most parameters will set instance to 1. Instances are used when more
than one value may be assigned to a given entity/parameter combination.
An example of this would be lab collection times at a division. A single
division may have multiple collection times. Each collection time would
be assigned a unique instance.\n
Parameter Template:
===================
A parameter template is similar to an input template. It contains a list
of parameters that can be entered through an input session (e.g. option).
Templates are stored in the Parameter Template file (#8989.52). Entries
in this file must also be namespaced.\n\n
This integration agreement defines the callable entry points in routine XPAR.\n", "", "XPAR", "2012/11/09"], ["2264", "DBIA2264", "File", "MAILMAN", "1998/01/12", "APPROVED", "Active", "Private", "3.7", "
Clinical Reminders (PCE) would like to use :
^XMB(3.7,"M",XMZ,XMDUZ,BASKET,NUMBER) as part of a DIC lookup screen in an
application that lets sites exchange reminder definitions via MailMan
messages. The lookup is done on ^XMB(3.9) and the screen is used to filter out
messages that have been deleted i.e., they are not in a basket.", "", "", ""], ["2265", "Rad/Nuc Med return report narrative text (exam)", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1998/01/20", "", "Under Revision", "Supported", "", "
EN3^RAO7PC1 can be used to return report narrative text
associated with a patient's exam.\n
***************************************************************************
***************** REASON FOR STUDY data will NOT be available until AFTER
***************** the release of patch RA*5.0*75 by the RADIOLOGY product.
***************************************************************************", "", "RAO7PC1", ""], ["2266", "Rad/Nuc Med return report narrative text (order)", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1998/01/20", "APPROVED", "Active", "Supported", "", "
EN30^RAO7PC1 can be used to return report narrative
text associated with a patient's order.\n
***************************************************************************
***************** REASON FOR STUDY data will NOT be available until AFTER
***************** the release of patch RA*5.0*75 by the RADIOLOGY product.
*************************************************************************", "", "RAO7PC1", ""], ["2267", "Rad/Nuc Med return imaging location information", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1998/01/20", "APPROVED", "Active", "Supported", "", "
EN4^RAO7PC1 can be used to return a list of valid,
active imaging locations within a particular imaging type.", "", "RAO7PC1", ""], ["2268", "Rad/Nuc Med exam case numbers linked to an order", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1998/01/20", "APPROVED", "Active", "Supported", "", "
CASE^RAO7PC1 is an extrinsic function that can be used
to retrieve the exam case numbers associated with an order. It returns the
case numbers, the total number of exams linked to the order, and a flag
indicating whether these exams are linked to a single report.", "", "RAO7PC1", ""], ["2269", "DBIA2269", "File", "REGISTRATION", "1998/01/23", "APPROVED", "Active", "Controlled Subscription", "40.8", "
Inpatient Medications requests permission to have a
field defined in the IV ROOM file (#59.5) that points to the MEDICAL CENTER
DIVISION file (#40.8). This field contains the division where the IV Room is
located. The Inpatient Medications field is populated by an option on the DSS
Extracts menu. It is solely for use by the DSS software and has no impact on
Pharmacy at this time. This field in Inpatient Medications supports DBIA
#1849 for the DSS Extracts package.", "", "", ""], ["2270", "Subscription Management", "Routine", "HEALTH LEVEL SEVEN", "1998/01/23", "APPROVED", "Active", "Supported", "", "
The following API's support creation, references, and
updates to HL7 subscriptions using the SUBSCRIPTION CONTROL FILE (774).\n
In addition, Vista applications may set up a pointer to file 774 if needed. An
example of this can be found in the Patient file. See the CIRN documentation
for details on how this is used.", "", "HLSUB", ""], ["2271", "DERIVE LOGICAL LINK FROM INSTITUTION", "Routine", "HEALTH LEVEL SEVEN", "1998/01/23", "APPROVED", "Active", "Supported", "", "
A new API has been created to return an array of
Logical links when only
an institution entry is known. This can be either a single institution or
a VISN. A new field has been added to the HL LOGICAL LINK file (870)
pointing to the INSTITUTION FILE.", "", "HLUTIL3", ""], ["2272", "DBIA2272", "File", "BENEFICIARY TRAVEL", "1998/02/02", "", "Pending", "Private", "392", "", "", "", ""], ["2273", "DBIA2273", "File", "FEE BASIS", "1998/02/02", "", "Pending", "Private", "161.8", "", "", "", ""], ["2274", "DBIA2274", "File", "FEE BASIS", "1998/02/02", "", "Pending", "Private", "162.1", "", "", "", ""], ["2275", "DBIA2275", "File", "FEE BASIS", "1998/02/02", "", "Pending", "Private", "162", "", "", "", ""], ["2276", "DBIA2276", "File", "FEE BASIS", "1998/02/02", "", "Pending", "Private", "162.5", "", "", "", ""], ["2277", "DBIA2277", "File", "FEE BASIS", "1998/02/02", "", "Pending", "Private", "161.2", "", "", "", ""], ["2278", "DBIA2278", "File", "IFCAP", "1998/02/02", "APPROVED", "Active", "Private", "441", "
The purpose of this agreement is to allow another
package to lookup Item Master file (#441) entries by the short description
(field #.05) using the "C" cross reference on that field or extract the value
of the short description for a item whose Item Master File (IMF) number is
known.", "", "", ""], ["2281", "DBIA2281", "File", "INTEGRATED BILLING", "1998/02/02", "", "Pending", "Private", "399", "", "", "", ""], ["2282", "DBIA2282", "File", "AUTOMATED INFO COLLECTION SYS", "1998/02/02", "", "Pending", "Private", "357.69", "", "", "", ""], ["2283", "DBIA2283", "File", "DRUG ACCOUNTABILITY", "1998/02/03", "APPROVED", "Active", "Private", "58.8", "
Inpatient Medications requests permission to reference
by a direct read cross-reference ^PSD(58.8,"D",DRUG,WARD). This is the "D"
cross-reference for field WARD (FOR DRUG) for sub-file 58.800115.\n
This cross-reference is the link between the Controlled Substances package and
the Inpatient Medications package for determining ward stocked drugs.", "", "", ""], ["2284", "DBIA2284", "File", "AUTO REPLENISHMENT/WARD STOCK", "1998/02/03", "APPROVED", "Active", "Private", "58.1", "
Inpatient Medications requests permission to reference
by a direct read cross-reference ^PSI(58.1,"D", ITEM, WARD). This is the"D"
cross-reference for field WARD (FOR ITEM) for sub-file 58.26.\n
This cross-reference is used by the Inpatient Medications package to identify
items on the Unit Dose pick list that are Ward Stock items.", "", "", ""], ["2285", "DBIA2285", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/02/03", "APPROVED", "Active", "Private", "", "
Dietetics uses the entry point FH^ORCONV3 of Order
Entry version 3 (CPRS) and pass the converted PACKAGE REFERENCE to Order Entry
for storage.", "", "ORCONV3", ""], ["2286", "DBIA2286", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/02/03", "APPROVED", "Active", "Private", "", "", "", "ORCDFH", ""], ["2287", "DBIA2287", "Routine", "DIETETICS", "1998/02/06", "APPROVED", "Active", "Private", "", "
Routine FHWOR8 will pass back an array of the Dietetics
Order parameter.", "", "FHWOR8", ""], ["2288", "LEXU", "Routine", "LEXICON UTILITY", "1998/02/03", "", "Withdrawn", "Supported", "", "
LEXU is a utility routine for the Lexicon Utility which
contains functions useful in retrieving classification codes for a term. This
agreement is an amendment to DBA #1573.", "", "LEXU", ""], ["2289", "DBIA2289", "Routine", "DIETETICS", "1998/02/06", "APPROVED", "Active", "Private", "", "
Extrinsic function call $$QUAN^FHWOR5R will return the
total quantity in cc for a tubefeeding product.", "", "FHWOR5R", ""], ["2290", "DBIA2290", "Routine", "DIETETICS", "1998/02/06", "APPROVED", "Active", "Private", "", "
Extrinsic function $$RESUME^FHWORR will return a flag
on whether to prompt the user to resume the tray service or not.", "", "FHWORR", ""], ["2291", "DBIA2291", "Routine", "DIETETICS", "1998/02/06", "APPROVED", "Active", "Private", "", "
Routine FHWOR7 will return the information on the
Dietetics Profile. DFN have to be defined before using the routine.", "", "FHWOR7", ""], ["2292", "DBIA2292", "Routine", "DIETETICS", "1998/02/06", "APPROVED", "Active", "Private", "", "
P^FHWOR71 is an extrinsic function which returns the
printable Dietetics Profile for a particular inpatient.", "", "FHWOR71", ""], ["2293", "DBIA2293", "Routine", "DIETETICS", "1998/02/06", "APPROVED", "Active", "Private", "", "
Routine FHWORA contains two extrinsic functions which
will return the Nutrient Assessment dates for a particular patient and the
printable Nutrient Assessment for an Assessment date of that patient.", "", "FHWORA", ""], ["2294", "DBIA2294", "Routine", "DIETETICS", "1998/02/06", "APPROVED", "Active", "Private", "", "
Entry Point CUR^FHORD7 will return the Current Diet of
a particular inpatient. Before executing this entry point, make sure both
variables, DFN and ADM, exists.", "", "FHORD7", ""], ["2295", "DBIA2295", "File", "REGISTRATION", "1998/02/07", "APPROVED", "Active", "Private", "40.8", "", "", "", ""], ["2296", "DBIA2296", "File", "REGISTRATION", "1998/02/07", "APPROVED", "Active", "Controlled Subscription", "43", "", "", "", ""], ["2297", "DBIA2297", "File", "REGISTRATION", "1998/02/07", "", "Pending", "Private", "405", "", "", "", ""], ["2298", "DBIA2298", "File", "1", "1998/03/05", "APPROVED", "Active", "Private", "", "
HL7 Patch 14 brings in updates to reference files for
version 2.3 of the standard. These files contain identifiers that have changed
with the latest version. KIDS does not install the new data correctly unless
these identifiers are removed before installing the patch.\n
Permission is requested to execute the following code as pre and post install
routines in patch 14.\n
HLP14PRE ;SFIRMFO/JC - HL7 PATCH 14 PRE-INIT ;03/05/98 11:44
;;1.6;HEALTH LEVEL SEVEN;**14**;Oct 13, 1995 PRE ;
K ^DD(779.001,0,"ID")
K ^DD(771.2,0,"ID")
Q POST ;
S ^DD(779.001,0,"ID",2)="W "_""""_" "_""""_",$P(^(0),U,2)"
S ^DD(771.2,0,"ID",2)="W "_""""_" "_""""_",$P(^(0),U,2)"", "", "", ""], ["2299", "DBIA2299", "File", "REGISTRATION", "1998/02/07", "", "Pending", "Private", "42.4", "", "", "", ""], ["2300", "DBIA2300", "File", "REGISTRATION", "1998/02/07", "APPROVED", "Active", "Private", "2", "", "", "", ""], ["2301", "DBIA2301", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/02/07", "", "Pending", "Private", "70", "", "", "", ""], ["2302", "DBIA2302", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/02/07", "", "Pending", "Private", "71", "", "", "", ""], ["2303", "DBIA2303", "File", "PROSTHETICS", "1998/02/07", "", "Pending", "Private", "660", "", "", "", ""], ["2304", "DBIA2304", "File", "PROSTHETICS", "1998/02/07", "", "Pending", "Private", "661", "", "", "", ""], ["2305", "DBIA2305", "File", "PROSTHETICS", "1998/02/07", "", "Pending", "Private", "667", "", "", "", ""], ["2306", "DBIA2306", "File", "PROSTHETICS", "1998/02/07", "", "Pending", "Private", "667.1", "", "", "", ""], ["2307", "DBIA2307", "File", "PROSTHETICS", "1998/02/07", "", "Pending", "Private", "667.3", "", "", "", ""], ["2308", "DBIA2308", "File", "PROBLEM LIST", "1998/02/07", "", "Pending", "Controlled Subscription", "9000011", "", "", "", ""], ["2309", "DBIA2309", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Controlled Subscription", "9000010", "", "", "", ""], ["2310", "DBIA2310", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Private", "9000010.18", "", "", "", ""], ["2311", "DBIA2311", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Private", "9000010.13", "", "", "", ""], ["2312", "DBIA2312", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Controlled Subscription", "9000010.23", "", "", "", ""], ["2313", "DBIA2313", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Controlled Subscription", "9000010.11", "", "", "", "2009/08/28"], ["2314", "DBIA2314", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Private", "9000010.16", "", "", "", ""], ["2315", "DBIA2315", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Private", "9000010.07", "", "", "", ""], ["2316", "DBIA2316", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Controlled Subscription", "9000010.06", "", "", "", ""], ["2317", "DBIA2317", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Controlled Subscription", "9000010.12", "", "", "", ""], ["2318", "DBIA2318", "File", "PCE PATIENT CARE ENCOUNTER", "1998/02/07", "APPROVED", "Active", "Private", "9000010.15", "", "", "", ""], ["2319", "DBIA2319", "File", "DIETETICS", "1998/02/09", "APPROVED", "Active", "Controlled Subscription", "119.4", "
Order Entry Version 3 (CPRS) uses the
Isolation/Precaution Type file (#119.4). The Order Dialog file (#101.41)
points to file 119.4 and displays the Isolation/Precaution types for ordering.\n", "", "", ""], ["2320", "DBIA2320", "Routine", "KERNEL", "1998/02/09", "APPROVED", "Active", "Supported", "", "
The %ZISH calls described in the KERNEL SYSTEM Manual.
This is a set of calls to work with Host files of the underlaying system.", "", "%ZISH", ""], ["2321", "DBIA2321", "File", "TEXT INTEGRATION UTILITIES", "1998/02/10", "APPROVED", "Active", "Controlled Subscription", "8925.1", "
In order for the AUTHORIZATION/SUBSCRIPTION UTILITY
(ASU) to work properly with TIU documents it needs the information contained
in the first and fourth pieces of the zero node of the TIU DOCUMENT DEFINITION
FILE, # 8925.1. It also needs to use the "AD" cross-reference to traverse the
document class hierarchy to determine if authorization is granted at a higher
level. Therefore ASU requests permission to do a direct global read of the
first and fourth pieces of the zero node of file # 8925.1 and the "AD" node.", "", "", ""], ["2322", "Calls to TIULP", "Routine", "TEXT INTEGRATION UTILITIES", "1998/02/10", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA is a controlled subscription for calls to
routine TIULP.", "", "TIULP", ""], ["2323", "Calls to routine TIULC1", "Routine", "TEXT INTEGRATION UTILITIES", "1998/02/10", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIULC1.", "", "TIULC1", ""], ["2324", "DBIA2324", "Routine", "AUTHORIZATION/SUBSCRIPTION", "1998/02/10", "", "Other", "Controlled Subscription", "", "
When checking if a user should have access to a
particular document TIU needs to determine if a user is a member of a class
that can access the document. Therefore TIU requests permission to call the
function ISA^USRLM.\n
Health Summary needs to extract user class data to build a class selection
list for Health Summary Parameters referenced by the Parameters tools in the
Parameter file. Therefore GMTS request permission to call the function
WHATIS^USRLM.\n
Health Summary needs to retrieve the name (.01) of a user class referenced by
the Parameters file. The call to CLNAME^USRLM will return the Class display
name (.04).", "", "USRLM", ""], ["2325", "DBIA2325", "Routine", "AUTHORIZATION/SUBSCRIPTION", "1998/02/10", "APPROVED", "Active", "Controlled Subscription", "", "
When checking what a user can do with a document,
(read, edit, etc.) TIU needs to evaluate the user's authorization. Therefore
TIU requests permission to call the function CANDO^USRLA.", "", "USRLA", ""], ["2326", "DBIA2326", "Routine", "DIETETICS", "1998/02/12", "APPROVED", "Active", "Private", "", "
Routine ORSETUP in patch OR*2.5*49, CPRS PRE-INSTALL,
and in Order Entry Version 3 (CPRS) calls routine FHWORI to populate the
Orderable Item file (#101.43). FHWORI sends Order Entry Health Level 7
messages of Tubefeeding products, and Diets for storage in file 101.43.", "", "FHWORI", ""], ["2327", "DBIA2327", "Routine", "INTEGRATED BILLING", "1998/02/17", "APPROVED", "Active", "Private", "", "
This is needed to determine if a bill has multiple
Insurance Carriers.", "", "IBJTU31", ""], ["2328", "DBIA2328", "Routine", "INTEGRATED BILLING", "1998/02/17", "APPROVED", "Active", "Private", "", "
This call is needed to allow Accounts Receivable to
call the Third Party Joint Inquiry List Template (Integated Billing) from an
Accounts Receivable List Template option. This is needed to prevent users
from having to exit one menu option and access another option.", "", "IBJTLA", ""], ["2329", "DBIA2329", "Routine", "AUTHORIZATION/SUBSCRIPTION", "1998/02/19", "APPROVED", "Active", "Controlled Subscription", "", "
USRLFF is a library of file functions for providing
read access to various AUTHORIZATION/SUBSCRIPTION data.", "", "USRLFF", ""], ["2331", "DBIA2331-A", "File", "LAB SERVICE", "1998/03/02", "APPROVED", "Active", "Private", "65", "
Direct global reads to "AP", "B", and "C" x-refs is
also specified.", "", "", ""], ["2332", "DBIA2331-B", "Routine", "LAB SERVICE", "1998/03/02", "APPROVED", "Active", "Private", "", "\n\n
The Surgery package requests permission to call the Blood Bank routine,
BAR^LRBLB from the Surgery routine SRBLOOD, to scan the blood product
bag, to ensure bar code readability.", "", "LRBLB", ""], ["2333", "DBIA2333", "Routine", "LAB SERVICE", "1998/03/02", "APPROVED", "Active", "Private", "", "\n
The Surgery package requests permission to call the Blood Bank routine,
LRBLBU, to scan the Blood Unit ID and return that value in the
variable "X" from the blood product bag. The Surgery routine SRBLOOD,
will use this value to check for an association with the patient in the
operating room and the scanned Blood Unit ID.", "", "LRBLBU", ""], ["2334", "DBIA2334", "Routine", "LIST MANAGER", "1998/03/04", "APPROVED", "Active", "Controlled Subscription", "", "
Inpatient Medications requests permission to call
RESET^VALM4 (List Manager). This entry point allows the use of the ListMan
standard protocol VALM TURN ON/OFF MENUS ( Auto-Display(On/Off) )to toggle
between a normal and expanded screen length. In each Inpatient Medications
Protocol HEADER field, a call is made that declares a short and long screen
length and makes the call to RESET^VALM4. Each time the user executes the VALM
TURN ON/OFF MENUS protocol, the protocol choices at the bottom of the screen
are removed or brought back and the screen length is adjusted accordingly.\n
During the Alpha testing of Inpatient Medications 5.0 and CPRS 1.0 at
Tuscaloosa AL and West Palm Beach FL, this ability to expand the ListMan
screen viewing area brought extreme positive feedback from the users.", "", "VALM4", ""], ["2335", "OE/RR CALL TO XPAR FOR BACKWARDS COMPATIBILITY", "Routine", "TOOLKIT", "1998/05/11", "APPROVED", "Active", "Private", "", "
This DBIA is a private agreement between OE/RR and the
Parameter Tools portion of Toolkit to allow a call to PUT1^XPAR. This is
needed until Radiology converts to using XPAR calls directly. Parameter Tools
functionality was originally in the ORXP namespace, but was later moved to the
XPAR namespace.", "", "XPAR", ""], ["2336", "SUPPORTED CALLS TO XPAREDIT", "Routine", "TOOLKIT", "1998/05/11", "APPROVED", "Active", "Supported", "", "
This DBIA contains a list of calls which are supported
for use. The calls are part of the Parameter Tools component of Toolkit.
Parameter Tools is a generic method of handling parameter definition,
assignment, and retrieval. See DBIA 2263 for the main entry points to this
module. This DBIA contains calls to XPAREDIT which contain some additional
utilities to for editing parameters.", "", "XPAREDIT", ""], ["2338", "DBIA2338", "Routine", "TOOLKIT", "1998/05/11", "APPROVED", "Active", "Controlled Subscription", "", "
During special processing related to the Patient Merge,
the routine IBAXDR needs to call the entry point SAVEMERG^XDRMERGB. This call
is used to save the file image of an entry involved in the merge process when
only one of the entries (the entry being merged or the entry being merged
into) is present in [FILENUM]. Normally, the merge process would handle when
it can identify a FROM or a TO entry which is not present based on the DINUMed
values. For [FILENUM], however, the internal entry numbers are determined
from the "B"-cross- reference, and missing entries need to be handled
separately.\n", "", "XDRMERGB", ""], ["2340", "DIU(0)", "Routine", "1", "1998/03/05", "APPROVED", "Active", "Controlled Subscription", "", "
Specific to preventing DIK from running
cross-references which include a test for the value of DIU(0) not being
present.", "", "DIK", ""], ["2341", "DBIA2341", "Other", "REGISTRATION", "1998/03/05", "APPROVED", "Active", "Private", "2", "
The Patient Merge application of the Kernel Toolkit
requests a private integration agreement to set the variable VAFCA08 during a
merge process.", "", "", ""], ["2342", "DBIA2342", "File", "HEALTH LEVEL SEVEN", "1998/05/27", "APPROVED", "Active", "Controlled Subscription", "771", "
The Surgery package is granted permission to do a
direct global read of the ACTIVE/INACTIVE field (#2) in the HL7 APPLICATION
PARAMETER file (#771). Reading this field will allow the Surgery package to
determine if the HL7 application associated with the Surgery HL7 interface is
active or not. If the HL7 application is not active, the call to the Surgery
HL7 interface will quit, thus avoiding needless processing.", "", "", ""], ["2343", "DBIA2343", "Routine", "KERNEL", "1998/03/10", "APPROVED", "Active", "Supported", "", "
The routine XUSER has supported entry points to lookup
a user, check to determine if a user is active, DEA# details, DETOX#,
authorized to write Controlled Substances, etc.\n\n
Amended - Added 1/30/2023 The API's are designed to be backward compatible, so
that calls to APIs that formerly returned DEA information stored in the DEA#
field (#53.2), DEA EXPIRATION DATE field (#747.44), and the SCHEDULE fields
(#55.1-55.6) will now receive the same information from new fields in the DEA
NUMBERS file (#8991.9). Pharmacy code changes that use the new APIs and new
input parameters are in the Pharmacy Operational Updates Release 3 patches
PSO*7*545, PSJ*5*372, and OR*3*499.", "", "XUSER", "2023/02/08"], ["2344", "DBIA2344", "Routine", "CMOP", "1998/03/11", "", "Withdrawn", "Private", "", "
The Outpatient Pharmacy package (V 6.0) requests an
integration agreement to call the Consolidated Mail Outpatient Pharmacy (CMOP)
package routine PSXEDUTL. This routine was designed for the exclusive use of
Outpatient Pharmacy Edit and Release functions. The IEN of an Rx# is passed to
the CMOP routine and evaluated against CMOP criteria for the associated
Outpatient Pharmacy action. The functionality contained in this routine has
been integrated into V 7.0 of Outpatient Pharmacy.", "", "PSXEDUTL", ""], ["2345", "D&PPM", "File", "IFCAP", "1998/06/01", "APPROVED", "Active", "Private", "410", "", "", "", ""], ["2346", "DBIA2346", "File", "REGISTRATION", "1998/03/24", "APPROVED", "Active", "Private", "2", "
We were tasked to make the class III VIST software a
nationally supported product. In doing so, we eliminated many of the
unsupported calls to other packages and files. The following is a list of the
remaining unsupported calls to the PATIENT file (#2). We will need a DBIA to
cover these calls.", "", "", ""], ["2347", "DBIA2347", "File", "FEE BASIS", "1998/03/24", "APPROVED", "Active", "Private", "161", "
We were tasked to make the class III VIST software a
nationally supported product. In doing so, we eliminated many of the
unsupported calls to other packages and files. The following is a list of the
remaining unsupported calls to the FEE BASIS PATIENT file (#161).\n
The VIST software contains a report titled "Fee Basis List". It includes a
sort template [ANRV FEE PT] and print template [ANRV FEE PT] with references
to NAME (.01), the AUTHORIZATION multiple subfile (#161.01), FROM DATE(.01),
TO DATE(.02), and TREATMENT TYPE CODE (.095) fields in the FEE BASIS PATIENT
File (#161). We request read access via FileMan extended syntax for the FEE
BASIS PATIENT fields NAME, AUTHORIZATION, FROM DATE, TO DATE, and TREATMENT
TYPE CODE.\n
Below is a capture of the templates in question and the report it generates.\n
Here is an example of the report output;\n
FEE PATIENT LISTING MAR 19,1998 12:40 PAGE 1
NAME SSN FROM DATE TO DATE
TREATMENT TYPE CODE
--------------------------------------------------------------------------
ANRVPATIENT,ONE 000-00-4444 FEB 17,1998 APR 18,1998
I.D. CARD STATUS
------------------------------
COUNT 1\n\n\n
This is a copy of the Sort Template;\n
WANT TO EDIT 'ANRV FEE PT' TEMPLATE? NO// y YES NAME: ANRV FEE PT// READ
ACCESS: WRITE ACCESS: SORT BY: @INTERNAL(VIST ELIGIBLE (AMIS))'="I";L1
Replace
By 'VIST ELIGIBLE ', do you mean VIST ROSTER 'VIST ELIGIBLE (AMIS)'? Yes//
(Yes)
WITHIN INTERNAL(VIST ELIGIBLE (AMIS))'="I", SORT BY: @NAME//
* Previous selection: NAME not null
START WITH NAME: FIRST//
WITHIN NAME, SORT BY: AUTHORIZATION// NAME:FEE BASIS PATIENT:
By 'FEE BASIS PATIENT', do you mean the FEE BASIS PATIENT File,
pointing via its 'NAME' Field? Yes// (Yes)
FEE BASIS PATIENT FIELD: 1// AUTHORIZATION (multiple)
AUTHORIZATION SUB-FIELD: TREATMENT TYPE CODE["CARD"&(TO DATE>T);L1
Replace
WITHIN TREATMENT TYPE CODE["CARD"&(TO DATE>T), SORT BY: STORE IN 'SORT'
TEMPLATE:\n\n\n
This is a copy of the Print template;\n
WANT TO EDIT 'ANRV FEE PT' TEMPLATE? No// Y (Yes) NAME: ANRV FEE PT// READ
ACCESS: WRITE ACCESS: FIRST PRINT FIELD: NAME;C1!// THEN PRINT FIELD:
NAME:$E(SSN,1,3)_"-"_$E(SSN,4,5)_"-"_$E(SSN,6,9);"SSN"
Replace
By 'SSN', do you mean PATIENT 'SOCIAL SECURITY NUMBER'? Yes// (Yes)
By 'SSN', do you mean PATIENT 'SOCIAL SECURITY NUMBER'? Yes// (Yes)
By 'SSN', do you mean PATIENT 'SOCIAL SECURITY NUMBER'? Yes// (Yes) THEN
PRINT FIELD: NAME:FEE BASIS PATIENT: Replace
By 'FEE BASIS PATIENT', do you mean the FEE BASIS PATIENT File,
pointing via its 'NAME' Field? Yes// (Yes)
THEN PRINT FEE BASIS PATIENT FIELD: AUTHORIZATION// (multiple)
THEN PRINT AUTHORIZATION SUB-FIELD: FROM DATE;C48//
THEN PRINT AUTHORIZATION SUB-FIELD: TO DATE//
THEN PRINT AUTHORIZATION SUB-FIELD: TREATMENT TYPE CODE//
THEN PRINT AUTHORIZATION SUB-FIELD:
THEN PRINT FEE BASIS PATIENT FIELD: THEN PRINT FIELD:\n
We will need a DBIA to cover these calls.", "", "", ""], ["2348", "SERVICE CONNECTED CONDITIONS", "Routine", "PCE PATIENT CARE ENCOUNTER", "1998/03/24", "APPROVED", "Active", "Controlled Subscription", "", "
This API returns if the Service Connected and
Conditions should/can be asked for a patient at a date/time. It also returns
the current answers if any in Scheduling for an encounter for the patient at
that date/time.", "", "PXUTLSCC", ""], ["2349", "ACTIVE PROVIDER", "Routine", "PCE PATIENT CARE ENCOUNTER", "1998/03/24", "APPROVED", "Active", "Controlled Subscription", "", "
This checks to see if a provider is active on the
system and if they have an active Person Class on a given date.", "", "PXAPI", ""], ["2350", "DBIA2350", "Other", "INPATIENT MEDICATIONS", "1998/03/26", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management requests permission to export
the Inpatient Medications menu option PSJI IVCATEGORY.", "", "", ""], ["2351", "OUTPATIENT ENCOUNTER SEARCH", "Routine", "INTEGRATED BILLING", "1998/03/26", "APPROVED", "Active", "Private", "", "
IBSDU is a routine I written for IB that provides a
generic interface to the ACRP APPLICATION INTERFACE TOOL (AIT) introduced by
Scheduling patch SD*5.3*131. The particular function that AICS needs is the
'SCAN' functionality that allows for a search for data in the encounter file
without using the now prohibited direct file access.", "", "IBSDU", ""], ["2352", "READ/WRITE DRUG FILE (#50)", "File", "PHARMACY DATA MANAGEMENT", "1999/10/15", "", "Retired", "Private", "50", "\n\n\n
National Drug File is given permission by Pharmacy Data Management to make the
following references with direct global reads and writes to the fields and
direct global references to the fields' cross-references.\n
1. (#2) VA CLASSIFICATION $P(^PSDRUG(D0,0),"^",2)\n\n
2. (#2.1) PHARMACY ORDERABLE ITEM $P(^PSDRUG(D0,1),"^",2)\n\n
3. (#213) CMOP DISPENSE $P(^PSDRUG(D0,3),"^",1)\n\n
4. (#51) LOCAL NON-FORMULARY $P(^PSDRUG(D0,0),"^",9)\n\n
5. (#52) VISN NON-FORMULARY $P(^PSDRUG(D0,0),"^",11)\n\n
6. (#37) DRUG TEXT ENTRY (multiple) $P(^PSDRUG(D0,9,D1,0),"^")\n\n
7. All fields contained on the "ND" Node\n
^PSDRUG(D0,"ND")= (#20) NATIONAL DRUG FILE ENTRY [1P] ^ (#21) VA PRODUCT
==>NAME [2F] ^ (#22) PSNDF VA PRODUCT NAME ENTRY [3N] ^ (#23)
==>PACKAGE SIZE [4P] ^ (#24) PACKAGE TYPE (#25) NATIONAL DRUG
==>CLASS [6P] ^ ^ ^ ^ (#27) CMOP ID [10F] ^ (#29) NATIONAL
==>FORMULARY INDICATOR [11S] ^\n
8. ^PSDRUG(D0,"OND") This global node was eliminated by previous
versions of the software. NDF V3.18 is the last
version that will include the cleanup routine
containing code to delete this node if it exists.\n\n
9. Hard Coded sets and kills to the following cross references;\n
^PSDRUG("AND")
^PSDRUG("APC")
^PSDRUG("AQ")
^PSDRUG ("AQ1")
^PSDRUG("NDC")
^PSDRUG("VAC")
^PSDRUG("VAPN")
^PSDRUG("APN")", "", "", ""], ["2353", "DBIA2353-A", "File", "PCE PATIENT CARE ENCOUNTER", "1998/04/03", "APPROVED", "Active", "Private", "9000010.11", "
This is to allow for the reading of the set of codes
with the Fileman call D
FIELD^DID(9000010.11,field,"","POINTER","target_root","msg_root"). This is
used by a RPC to pass the values for the field to the CPRS GUI.", "", "", ""], ["2354", "DBIA2353-B", "File", "PCE PATIENT CARE ENCOUNTER", "1998/04/03", "APPROVED", "Active", "Private", "9000010.12", "
This is to allow for the reading of the set of codes
with the Fileman call D
FIELD^DID(9000010.12,field,"","POINTER","target_root","msg_root"). This is
used by a RPC to pass the values for the field to the CPRS GUI.\n
Amendment: Added .03 and 1201 effective with OR*3*405", "", "", "2022/12/23"], ["2355", "DBIA2353-C", "File", "PCE PATIENT CARE ENCOUNTER", "1998/04/03", "APPROVED", "Active", "Private", "9000010.13", "
This is to allow for the reading of the set of codes
with the Fileman call D
FIELD^DID(9000010.13,field,"","POINTER","target_root","msg_root"). This is
used by a RPC to pass the values for the field to the CPRS GUI.", "", "", ""], ["2356", "DBIA2353-D", "File", "PCE PATIENT CARE ENCOUNTER", "1998/04/03", "APPROVED", "Active", "Private", "9000010.16", "
This is to allow for the reading of the set of codes
with the Fileman call D
FIELD^DID(9000010.16,field,"","POINTER","target_root","msg_root"). This is
used by a RPC to pass the values for the field to the CPRS GUI.", "", "", ""], ["2357", "DBIA2353-E", "File", "PCE PATIENT CARE ENCOUNTER", "1998/04/03", "APPROVED", "Active", "Private", "9000010.23", "
This is to allow for the reading of the set of codes
with the Fileman call D
FIELD^DID(9000010.23,field,"","POINTER","target_root","msg_root"). This is
used by a RPC to pass the values for the field to the CPRS GUI.", "", "", ""], ["2358", "DISCONTINUE OP MEDS ON DATE OF DEATH", "Routine", "OUTPATIENT PHARMACY", "1998/04/03", "APPROVED", "Active", "Private", "", "", "", "PSOCAN3", ""], ["2359", "DBIA2359", "Other", "KERNEL", "1998/04/07", "", "Pending", "Supported", "", "
In order to provide internal workstation identification
by way of the Kernal/Broker session, read access of the session variable
IO("CLNMN") is required for the purpose of controlling remote processes.", "", "", ""], ["2360", "DBIA2360", "File", "REGISTRATION", "1998/04/08", "APPROVED", "Active", "Private", "405", "
In order to calculate the percentage of deaths within a
Medical Center that results in Autopsy, direct global reads of ^DGPM("ATID3",
and $P(^DGPM(DO,0),U,18) are requested by the Laboratory Package.", "", "", ""], ["2361", "KILLING NODES IN DD FOR RATED DISABILITIES MULTIPLE", "Other", "1", "1998/04/16", "APPROVED", "Active", "Private", "", "
The Registration Package requests permission to kill
'extra' nodes descendant from ^DD(2.04,0,"NM") in the post-install for patch
DG*5.3*147, leaving only ^DD(2.04,0,"NM","RATED DISABILITIES (VA)").\n
Justification
=============
We are currently in testing for patch DG*5.3*147, which is National
Enrollment. In part, this software consists of the transmission of patient
data to local sites and its upload.\n
We discovered that UPDATE^DIE was failing, resulting in the loss of the
patient's rated disabilities.\n
The cause was prior corruption of the DD for the 2.04 multiple (Rated
Disabilities (VA)). There are extra nodes at the "NM" cross-reference.
Deleting the nodes solved the problem.", "", "", ""], ["2362", "DBIA2362-A", "File", "KERNEL", "1998/04/21", "APPROVED", "Active", "Private", "19.081", "\n
Surgery request read access for all fields within the AUDIT LOG FOR
OPTIONS File (#19.081), to produce a sorted audit report using the
Surgery sort template, [SR BLOOD PRODUCT VERIFICATION].\n
The Surgery sort template, [SR BLOOD PRODUCT VERIFICATION]
is coded to print the Audit Log for the Surgery option
[SR BLOOD PRODUCT VERIFICATION] only.\n
^XUSEC(19,D0,0)= (#.01) OPTION [1P] ^ (#1) USER [2P] ^ (#2) DEVICE [3F] ^
==>(#3) JOB [4N] ^ (#4) DATE/TIME OF EXIT FROM OPTION [5D] ^
==>(#5) CPU [6F] ^ ^XUSEC(19,D0,1)= (#6) MESSAGE NUMBER [1N] ^
(#7) SENDER [2F] ^ ^XUSEC(19,D0,2)= (#8) SUBJECT [E1,65F] ^ ^XUSEC(19,D0,3)=
(#9) ACTION [E1,245F] ^\n
----------------------------------------------------------------------
Example of Sort Template SR BLOOD PRODUCT VERIFICATION;\n
NAME: SR BLOOD PRODUCT VERIFICATION Replace READ ACCESS: @// WRITE ACCESS:
@// SORT BY: ]DATE/TIME// * Previous selection: DATE/TIME from Jan 1,1998
START WITH DATE/TIME: FIRST//
WITHIN DATE/TIME, SORT BY: OPTION["SR BLOOD PRODUCT VERIFICATION";L1
Replace
WITHIN OPTION["SR BLOOD PRODUCT VERIFICATION", SORT BY: STORE IN 'SORT'
TEMPLATE: FIRST PRINT FIELD:", "", "", ""], ["2363", "DBIA2362-B", "Other", "KERNEL", "1998/04/21", "APPROVED", "Active", "Private", "", "\n
The Surgery package requests permission to use the KERNEL print template,
[XUOPTLOGP]. It will be called from the Surgery option, [SR BLOOD PRODUCT
VERIFY AUDIT], to print the Audit Log for the Surgery option [SR BLOOD
PRODUCT VERIFICATION].", "", "", ""], ["2364", "ASISTS use of fields in File 450", "File", "PAID", "1998/04/21", "APPROVED", "Active", "Private", "450", "", "", "", ""], ["2365", "Merge File Entries", "Routine", "TOOLKIT", "1998/04/27", "APPROVED", "Active", "Supported", "", "\n\n
Overview\n
A file in which entries need to be merged may be entered in the DUPLICATE
RESOLUTION file (file 15.1). This requires adding the file as one which can
be selected as the variable pointer, and search criteria would usually need to
be specified to assist in identifying potential duplicate pairs (although an
option can be use by which selected pairs can be added directly to the
DUPLICATE RECORD file as verified duplicates). Verified duplicate pairs may
be approved for merging, and a merge process generated for those approved
pairs. A DUPLICATE RECORD file entry will also have handle files which are
not associated as normal pointers identified in the PACKAGE file under the
'AFFECTS RECORD MERGE' subfile with special processing routines.\n
***IF A FILE HAS RELATED FILES WHICH ARE NOT NORMAL POINTERS, THEY SHOULD BE
HANDLED ONLY AS ENTRIES IN THE DUPLICATE RECORD FILE AND THE TOOLKIT OPTIONS
USED FOR MERGES INVOLVING THE FILE.***\n
The merge utility of Kernel Toolkit as revised by patch XT*7.3*23 provides an
entry point which is available to developers for the merging of one or more
pairs of records (a FROM record and a TO record) in a specified file. The
merge process me rges the data of the FROM record into that of the TO record
and deletes the FROM record, restoring by a hard set only the zero node with
the .01 value on it until the merge process is completed (such that any
references to that location via pointers will not error out). Any files which
contain entries DINUMed with the data pairs are then also merged (and any
files which are related to them by DINUM as well). Any pointers which can be
identified rapidly by cross-references are modifie d so that references for
the FROM entry become references to the TO entry instead. Following this, any
files which contain other pointers are searched entry by entry to test for
pointers to a FROM entry, and when found are modified to reference the TO
entry. This search for pointer values is the most time consuming part of the
entire process and may take an extended period depending upon the number of
files that must be searched, the number of entries in those files, and how
many levels of subfiles pointers may be located at. Since the search through
these files will take the same period of time independent of the number of
pairs which are being merged, it is suggested that as many pairs as convient
be combined in one proc ess. At the end of the conversion of these pointers,
the zero node stubs will be removed from the primary file and all related
DINUMed files.\n
The merge process is a single job which is tracked with frequent updates on
location and status from start to finish. The job can be stopped at any time
if necessary using Task Manager utilities (or in the event of a system crash,
etc.) and restarted at the point of interruption at a later time.\n\n
The manner in which data is merged.\n
When a primary file or a DINUMed files entries are merged, any top level
(single value) fields which are present in the FROM entry which are not
present in the TO entry will be merged into the TO entries data. Any of these
fields which contain cross-references will be entered using a VA File Manager
utility (FILE^DIE) so that the cross-references will be fired. Other fields
(those without cross-references) will be directly set into the data global.\n
If a subfile entry exists in the FROM record which is not present in the TO
record (as identified by the .01 value), that entry will be created with a VA
File Manager utility (UPDATE^DIE) and the rest of the subfile merged over into
the TO record and the cross-references within the subfile and any descendent
subfiles run.\n
If a subfile entry exists in the FROM record and an identical .01 value exists
in the TO record, the subfile in the FROM record will be searched for any
descendent subfiles which are not present in the TO record subfile. If such a
subfile is found it will be merged into the subfile in the TO record and any
cross-references in the merged subfile run.\n
For fields which are simple pointers to the primary file (or any other file
DINUMed to the primary file) the reference to the FROM record will be changed
to a reference to the TO record. If the field contains a cross-reference this
editing will be performed using a VA File Manager Utility call (FILE^DIE),
otherwise it will be set directly into the global node.", "", "XDRMERG", ""], ["2367", "DBIA2367", "File", "PHARMACY DATA MANAGEMENT", "1998/04/28", "", "Retired", "Private", "50", "
Consolidated Mail Outpatient Pharmacy is given
permission by Pharmacy Data Management to make the following references to
^PSDRUG.\n
1. (#213) CMOP DISPENSE $P(^PSDRUG(D0,3),"^",1)\n
2. All fields contained on the "ND" node - Global Read Access only
^PSDRUG(D0,"ND")= (#20) NATIONAL DRUG FILE ENTRY [1P] ^ (#21) VA PRODUCT
==>NAME [2F] ^ (#22) PSNDF VA PRODUCT NAME ENTRY [3N] ^ (#23)
==>PACKAGE SIZE [4P] ^ (#24) PACKAGE TYPE (#25) NATIONAL DRUG
==>CLASS [6P] ^ ^ ^ ^ (#27) CMOP ID [10F] ^\n
3. Hard coded sets and kills to the following cross references:
^PSDRUG("AQ")
^PSDRUG("AQ1")\n
4. (#2.1) PHARMACY ORDERABLE ITEM $P(^PSDRUG(D0,1),"^",2)", "", "", ""], ["2371", "REATTACH SC TEAM AUTO-ADD PROTOCOL", "Other", "SCHEDULING", "1998/04/28", "APPROVED", "Active", "Private", "", "
CPRS did an OOPS. When we attempted to add our
protocol to theSC CLINIC ENTROLL/DISCHARGE EVENT DRIVER protocol, we ended up
removing the SC TEAM AUTO-ADD protocol which was already attached.\n
We would like permission to do the reattachment as part of OR*3*19. The patch
sends SC TEAM AUTO-ADD as ATTACH AT SITE and SC CLINIC ENROLL/DISCHARGE EVENT
DRIVER as USE AS LINK so we're not actually sending out the definitions, just
making the connection.", "", "", ""], ["2372", "SC CLINIC ENROLL/DISCHARGE EVENT DRIVER protocol", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "
The SC CLINIC ENROLL/DISCHARGE EVENT DRIVER protocol is
provided to post information whenever a patient is enrolled in or discharged
from a clinic.\n
It is exported with the SC TEAM AUTO-ADD protcol attached to it.", "", "", ""], ["2373", "DIST(1.2 REFERENCE IN OE/RR", "File", "1", "1998/04/29", "APPROVED", "Active", "Private", "1.2", "
The Order Entry/Results Reporting module would like
permission to reference the ALTERNATE EDITOR file. OE/RR uses the FM reader
almost exclusively in the order dialog process. When taking actions such as
copy and renew orders, it is necessary to allow comments (a word processing
field) to be carried over. OE/RR would like to use the ALTERNATE EDITOR file
to determine if the user is using the line editor. If not, it will display
the text in the field prior to asking them if they want to edit it.\n
Without this reference, always displaying the text in the field would cause
those with the line editor to see it 2x.", "", "", ""], ["2374", "TOOLKIT NEEDS NAME", "File", "1", "1998/04/29", "APPROVED", "Active", "Controlled Subscription", "1", "
The Parameter Tools component of Toolkit is a generic
tool to allow setting parameters at various levels (system, package, etc.).
In order to achieve this goal, it is necessary to make a direct global read to
DIC to determine file name.", "", "", ""], ["2375", "TOOLKIT NEEDS TO ACCESS VARIABLE PTR DEF", "File", "1", "1998/04/29", "APPROVED", "Active", "Private", "", "
The Parameter Tools component of Toolkit allows setting
of parameters at various levels. This necessitates a file structure with a
variable pointer definition to point to the files which are allowed to be used
through the Parameter Tools component.\n
To ensure that no other files are pointed to, a check is done on the DD's "V"
multiple, "B" cross-reference, to deterine whether an entry is in the variable
pointer definitition.", "", "", ""], ["2376", "DBIA2376", "Routine", "INPATIENT MEDICATIONS", "1998/04/30", "APPROVED", "Active", "Controlled Subscription", "", "
These entry points build drug information for patient's
orders entered in the Inpatient Medications package. The data returned is
used in order checks in Computerized Patient Record System.", "", "PSJORUT2", ""], ["2377", "DIR('V') usage in parameter tools", "Other", "1", "1998/04/30", "APPROVED", "Active", "Private", "", "
The parameter tools component of toolkit would like
permission to use DIR("V") to ensure a silent interaction with the reader when
doing data validation checks.", "", "", ""], ["2378", "TEST FOR ADVERSE REACTION TO AGENT", "Routine", "ADVERSE REACTION TRACKING", "1998/05/06", "APPROVED", "Active", "Supported", "", "
This integration agreement allows a package to
determine if a patient has an adverse reaction to an agent defined by the
parameters TYP and PTR.", "", "GMRAOR", "1998/06/01"], ["2380", "GMRD(120.82 USAGE IN OE/RR", "File", "ADVERSE REACTION TRACKING", "1998/05/06", "APPROVED", "Active", "Controlled Subscription", "120.82", "", "", "", ""], ["2381", "OE/RR REFERENCES TO PS(51.2,", "File", "PHARMACY DATA MANAGEMENT", "1998/05/06", "APPROVED", "Active", "Controlled Subscription", "51.2", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
The Order Entry/Results Reporting package requests permission to access the
NAME and ABBREVIATION fields in the MEDICATION ROUTES file (#51.2).", "", "", ""], ["2382", "OUTPATIENT PHARMACY/CIRN", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1998/05/07", "APPROVED", "Active", "Private", "", "
Outpatient Pharmacy provides the CIRN package
prescription data at various stages in the prescription life cycle. The data
is provided through the use of a single entry point EN^RGEQ("RX",RX IEN) in
the CIRN package. The following Outpatient Pharmacy routines call this entry
point from the lines indicated:\n
ROUTINE LINE\n
PSOAUTOC CAN+16
PSOBUILD GET+18
PSOCAN3 ADD+1
PSODISP BATCH+11
PSODISPS QTY+16
PSOHLD UHLD+10
UHLD+14
H+8
PSORESK BC1+21
PAR+14
PSORXED1 DIE+6", "", "RGEQ", ""], ["2383", "SEND INPT MEDS TO CPRS", "Routine", "INPATIENT MEDICATIONS", "1998/05/07", "APPROVED", "Active", "Private", "", "
This call, OCL^PSJORRE, returns the Inpatient
Medications data that is passed to Computerized Patient Record System and used
for display in the CPRS meds screen.", "", "PSJORRE", "2008/07/28"], ["2384", "DBIA2384", "Routine", "INPATIENT MEDICATIONS", "1998/05/07", "APPROVED", "Active", "Private", "", "
This call, OEL^PSJORRE1, returns the Inpatient
Medications order data that is passed to Computerized Patient Record System.
This array is used for the meds screen detailed order display.", "", "PSJORRE1", "2018/10/10"], ["2385", "DBIA2385", "Routine", "OUTPATIENT PHARMACY", "1998/05/07", "APPROVED", "Active", "Private", "", "
The Consolidated Mail Outpatient Pharmacy (CMOP)
Package requests an integration agreement with the Outpatient Pharmacy (OP) V.
7.0 package. The agreement covers a single entry point in the OP package at
EN^PSOHLSN1(IEN #52, "ZD"). These two parameters are the only ones that are
required. Others are optional. Prescription event data is passed through the
OP package to the Clinical Information Resources Network (CIRN) package in the
form of the Rx internal entry # from file 52. No data is returned to the CMOP
package from the CIRN package.\n
This agreement also covers the same entry point in the OP package at
EN^PSOHLSN1(IEN #52, "SC"). These two parameters are the only ones that are
required. Others are optional. In this case, the prescription event data is
passed to the Computerized Patient Record System (CPRS) package to update
status information for CMOP prescriptions. No data is returned to the CMOP
package.", "", "PSOHLSN1", ""], ["2386", "PARAMETER TOOLS POINTS TO FILE 1", "File", "1", "1998/05/09", "APPROVED", "Active", "Private", "1", "
The Parameter Tools portion of Toolkit requests
approval to point to the file of files (file #1). Parameter Tools uses this
pointer to determine allowable files for setting up parameters.", "", "", ""], ["2387", "LAB(60 USAGE IN OE/RR", "File", "LAB SERVICE", "1998/05/09", "APPROVED", "Active", "Controlled Subscription", "60", "
Order Entry/Results Reporting requests permission to
access the following fields and cross-references in the LABORATORY TEST file
(#60).", "", "", "2024/02/20"], ["2388", "LAB(61 USAGE IN OE/RR", "File", "LAB SERVICE", "1998/05/09", "APPROVED", "Active", "Private", "61", "
Order Entry/Results Reporting requests permission to
access the following fields and cross-references in the TOPOGRAPHY FIELD file
(#61).", "", "", "2013/02/20"], ["2389", "LAB(62 USAGE IN OE/RR", "File", "LAB SERVICE", "1998/05/09", "APPROVED", "Active", "Private", "62", "
Order Entry/Results Reporting requests permission to
access the following fields and cross-references in the COLLECTION SAMPLE file
(#62).", "", "", "2012/04/23"], ["2390", "LAB(62.05, USAGE IN OE/RR", "File", "LAB SERVICE", "1998/05/09", "APPROVED", "Active", "Private", "62.05", "
Order Entry/Results Reporting requests permission to
access the following fields in the URGENCY file (#62.05).", "", "", ""], ["2391", "LAB(62.07, USAGE IN OE/RR", "File", "LAB SERVICE", "1998/05/09", "APPROVED", "Active", "Private", "62.07", "
Order Entry/Results Reporting requests permission to
access the following field in the EXECUTE CODE file (#62.07).", "", "", ""], ["2392", "OE/RR ACCESS TO PS(51.1,", "File", "PHARMACY DATA MANAGEMENT", "1998/05/10", "APPROVED", "Active", "Private", "51.1", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
Order Entry/Results Reporting requests permission to access the following
fields and cross-reference in the Administration Schedule file (#51.1).", "", "", ""], ["2393", "OE/RR USE OF PS(50.605,", "File", "NATIONAL DRUG FILE", "1998/05/10", "", "Retired", "Private", "50.605", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
Order Entry/Results Reporting requests teh ability to use the "C" x-ref in the
VA DRUG CLASS file (#50.605) when checking whether an allergy is associated
with a class of drugs.", "", "", ""], ["2394", "OE/RR USAGE OF PSNDF", "File", "NATIONAL DRUG FILE", "1998/05/10", "", "Retired", "Private", "50.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
Order Entry/Results Reporting requests the ability to use the "B" and "T"
x-refs in the NATIONAL DRUG file (#50.6) when checking whether an allergy is
associated with a drug.", "", "", ""], ["2395", "CALL TO GMRCAFRD", "Routine", "CONSULT/REQUEST TRACKING", "1998/05/10", "APPROVED", "Active", "Private", "", "
The Order Entry/Results Reporting packages requests
approval to call FR^GMRCAFRD.", "", "GMRCAFRD", ""], ["2396", "OE/RR USAGE OF PS(55,", "File", "PHARMACY DATA MANAGEMENT", "1998/05/10", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
Order Entry/Results Reporting requests global read access to the Pharmacy
Patient file (#55) for the fields listed below.", "", "", ""], ["2397", "OE/RR CALL TO PSOHLUP", "Routine", "OUTPATIENT PHARMACY", "1998/05/10", "APPROVED", "Active", "Private", "", "
Order Entry/Results Reporting calls PSOHLUP during the
CPRS orders conversion.", "", "PSOHLUP", ""], ["2398", "OE/RR CALL TO PSORENW", "Routine", "OUTPATIENT PHARMACY", "1998/05/10", "APPROVED", "Active", "Private", "", "
The Order Entry/Results Reporting would like approval
to call the extrinsic function $$RENEW^PSORENW(ien).", "", "PSORENW", ""], ["2399", "OE/RR CALL TO PSOREF FOR REFILL CHECK", "Routine", "OUTPATIENT PHARMACY", "1998/05/10", "APPROVED", "Active", "Private", "", "
Order Entry/Results Reporting requests permission to
call REFILL^PSOREF to determine whether an order is refillable.", "", "PSOREF", ""], ["2400", "OE/RR CALLS TO PSOORRL", "Routine", "OUTPATIENT PHARMACY", "1998/05/10", "APPROVED", "Active", "Controlled Subscription", "", "
Order Entry/Results Reporting requests approval to make
the following calls to PSOORRL.\n
Patch PSO*7*622 updated OCL^PSOORRL with two new parameters to accept a second
set of date ranges for Inpatient Medications. Previously, this API only
supported one set of date ranges used for both Outpatient Medications and
Inpatient Medications. Existing callers of this API will not see any change in
behavior, as if nothing is passed into the new parameters, it will behave as
it did previously. Only if a caller wishes to use different date ranges for
Outpatient/Non-VA Medications and Inpatient Medication they need to utilize
the new parameters.", "", "PSOORRL", "2008/07/28"], ["2401", "OE/RR CONVERSION CALL TO PSJIPST3", "Routine", "INPATIENT MEDICATIONS", "1998/05/10", "APPROVED", "Active", "Private", "", "
The CPRS post-installation makes a call to
BADNAMES^PSJIPST3 so that Inpatient Meds can send a list of IV orders where
the user name could not be resolved.", "", "PSJIPST3", ""], ["2402", "INPATIENT MED CALLS FOR OE/RR", "Routine", "INPATIENT MEDICATIONS", "1998/05/10", "APPROVED", "Active", "Private", "", "
Order Entry/Results Reporting would like approval to
make the following calls to PSJORUT2.", "", "PSJORUT2", ""], ["2403", "OE/RR CALLS TO PSJORUTL", "Routine", "INPATIENT MEDICATIONS", "1998/05/10", "APPROVED", "Active", "Private", "", "
Order Entry/Results Reporting requests approval to make
the following calls to PSJORUTL.", "", "PSJORUTL", ""], ["2404", "OE/RR CALL TO PSJORMAR", "Routine", "INPATIENT MEDICATIONS", "1998/05/10", "APPROVED", "Active", "Private", "", "
Order Entry/Results Reporting seeks approval to call
MAR^PSJORMAR to print MAR label via Print Format.", "", "PSJORMAR", ""], ["2405", "OE/RR CALLS TO PSSHL1", "Routine", "PHARMACY DATA MANAGEMENT", "1998/05/10", "APPROVED", "Active", "Private", "", "
Order Entry/Results Reporting wishes to document the
call to EN1^PSSHL1 which is used to populate pharmacy orderables into the
OE/RR ORDERABLE ITEM file.", "", "PSSHL1", ""], ["2406", "OE/RR CONVERSION CALLS LR7OV2", "Routine", "LAB SERVICE", "1998/05/10", "APPROVED", "Active", "Private", "", "
This is to document OE/RR v3's call to EN^LR7OV2 as
part of the CPRS Orders conversion.", "", "LR7OV2", ""], ["2407", "OE/RR REFERENCES TO LRO(69,", "File", "LAB SERVICE", "1998/05/10", "APPROVED", "Active", "Controlled Subscription", "69", "
Order Entry/Results Reporting requests approval to make
the following refrences to the Lab Order Entry file (#69).", "", "", ""], ["2409", "2409", "File", "IFCAP", "1998/05/11", "APPROVED", "Active", "Private", "410", "", "", "", ""], ["2410", "ENTER PROGRESS NOTE", "Routine", "TEXT INTEGRATION UTILITIES", "2001/03/12", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point allows a package to invoke the TIU
note entry process.", "", "TIUEDIT", ""], ["2411", "DBIA2411", "Routine", "INPATIENT MEDICATIONS", "1998/05/14", "APPROVED", "Active", "Private", "", "
This entry point is used to backfill/convert a patients
Inpatient Medications orders after the installation of Outpatient Pharmacy
version 7.0, and Inpatient Medications version 5.0.", "", "PSJUTL1", ""], ["2412", "ON-THE-FLY ORDERS CONVERSION", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/05/14", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA is a controlled subscription for packages
needing to envoke the OE/RR version 3 Orders Conversion for a patient.", "", "OR3CONV", ""], ["2414", "ORDERS CONVERSION CHECK", "File", "ORDER ENTRY/RESULTS REPORTING", "1998/05/15", "APPROVED", "Active", "Supported", "100.99", "
This DBIA authorizes direct global read of some fields
in the ^ORD(100.99,1,"CONV") node. This node contains the fields used by the
CPRS v1 Orders Conversion. Calling packages can use this information to
determine whether the Orders Conversion is complete. It also authorizes
access to ^ORD(100.99,1,"PTCONV") which is a multiple which contains the DFNs
of patients left to convert.", "", "", ""], ["2415", "PS EVSEND OR", "Other", "PHARMACY DATA MANAGEMENT", "1998/05/15", "APPROVED", "Active", "Controlled Subscription", "", "
The PS EVSEND OR protocol is used to pass order
messages from Pharmacy packages to other packages. This protocol is exported
by the Pharmacy Data Management package, and is invoked by other Pharmacy
Packages.", "", "", ""], ["2416", "PS EVSEND OR", "Other", "PHARMACY DATA MANAGEMENT", "1998/05/15", "", "Retired", "Controlled Subscription", "", "
This agreement will allow certain packages to attach
protocols as Items under the PS EVSEND OR protocol, which is an Extended
Action protocol used to pass Pharmacy order information from Pharmacy packages
to other packages in the form of an array.", "", "", ""], ["2417", "Pharmacy Schedule and Admin Team Utilities", "Routine", "INPATIENT MEDICATIONS", "1998/05/15", "APPROVED", "Active", "Private", "", "
These entry points provide utilities to access entries
in the ADMINISTRATION SCHEDULE file (#51.1).", "", "PSJEEU", ""], ["2418", "OE/RR CALL TO PSSJORDF", "Routine", "PHARMACY DATA MANAGEMENT", "1998/05/20", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA allows use of START^PSSJORDF and
START1^PSSJORDF as documented in the OE/RR Developer Interface Specification.", "", "PSSJORDF", "2011/05/10"], ["2419", "OE/RR REFERENCES TO RAMIS(71.2", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/05/20", "APPROVED", "Active", "Private", "71.2", "
This DBIA requests direct global read access to the
fields and cross-references documented in this DBIA.", "", "", ""], ["2420", "OE/RR REFERENCE TO RAMIS(71", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/05/20", "APPROVED", "Active", "Private", "71", "
This DBIA requests direct global read access to the
RAD/NUC MED PROCEDURES file as listed in this DBIA.", "", "", ""], ["2421", "GMRADPT DATA SUBSET", "Routine", "ADVERSE REACTION TRACKING", "1998/05/20", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to retrieve a subset of the adverse reaction data returned by integration
agreement #10099 GMRADPT.", "", "GMRAOR1", "2015/01/09"], ["2422", "Detailed Adverse Reaction", "Routine", "ADVERSE REACTION TRACKING", "1998/05/21", "", "Under Revision", "Supported", "", "
This integration agreement allows a package to retrieve
detailed information for a specific adverse reaction.", "", "GMRAOR2", "2017/02/13"], ["2423", "Inpatient Medications Quick Order Conversion", "Routine", "PHARMACY DATA MANAGEMENT", "1998/05/21", "APPROVED", "Active", "Private", "", "
Used by OR*2.5*49 to convert existing Inpatient
Medication Quick Orders for use with CPRS v1.0.", "", "PSSQOC", ""], ["2424", "ROUTINE CALLS IN GMRCA1", "Routine", "CONSULT/REQUEST TRACKING", "1998/05/21", "APPROVED", "Active", "Private", "", "
This DBIA will allow calling various entry points in
GMRCA1.", "", "GMRCA1", ""], ["2425", "CALL TO GMRCACTM", "Routine", "CONSULT/REQUEST TRACKING", "1998/05/21", "APPROVED", "Active", "Private", "", "
This DBIA will alow Order Entry/Results Reporting to
call CPRS^GMRCACTM.", "", "GMRCACTM", ""], ["2426", "CALLS TO GMRCASV", "Routine", "CONSULT/REQUEST TRACKING", "1998/05/21", "APPROVED", "Active", "Private", "", "
This DBIA request permission for Order Entry/Results
Reporting to call the following entry points in GMRCASV.", "", "GMRCASV", ""], ["2427", "CALLS TO GMRCTIU", "Routine", "CONSULT/REQUEST TRACKING", "1998/05/21", "APPROVED", "Active", "Private", "", "
This DBIA will document the calls from Order
Entry/Results Reporting to GMRCTIU.", "", "GMRCTIU", "2010/05/25"], ["2428", "USE OF LR7OR3 CALLS", "Routine", "LAB SERVICE", "1998/05/21", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA formalizes the documentation for calls to
LR7OR3 as documented in the OE/RR Interface Specification document.", "", "LR7OR3", "2021/01/22"], ["2429", "USE OF LR7OV4 CALLS", "Routine", "LAB SERVICE", "1998/05/21", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA formalizes the documentation for calls to
LR7OV4 as documented in the OE/RR Interface Specification document.", "", "LR7OV4", ""], ["2430", "USE OF XUTL('XQORM',", "Other", "KERNEL", "1998/05/21", "APPROVED", "Active", "Controlled Subscription", "", "
Setting data into XUTL("XQORM" allows the protocol
unwinder to display the data as if it were a protocol. This has been used for
quite some time, but was never formally requested/documented.", "", "", ""], ["2431", "DBIA2431", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
A need exists in Integrated Billing to be able to get
the disposition node from the pointer value in the 9th piece of the encounter
file 0-node. We would like to call $$ER^SDOE to accomplish this.", "", "SDOE", ""], ["2432", "DBIA2432", "File", "SCHEDULING", "2004/06/24", "APPROVED", "Active", "Controlled Subscription", "44", "
Medicine requests a FILEMAN read to the DIVISION field
(#3.5) of the HOSPITAL LOCATION file (#44) [$P(^SC(D0,0),"^",15)] to display
what division a Ward belongs to.", "", "", ""], ["2433", "XPDGREF", "Other", "KERNEL", "1998/06/10", "APPROVED", "Active", "Supported", "", "
Developers can put information in the KIDS Transport
Global, ^XTMP. The transport global will be available during the Environment
Check, Pre-Install, and Post-Install routines. The developer can access the
information by using the variable XPDGREF to read or set the transport global.\n
example: to set the transport global
S @XPDGREF@("My subscript",1)="Information I need"
to read the transport global
S X=@XPDGREF@("My subscript",1)\n
Developers can create a routine that will always set information into the
transport global whenever a package is transported. The field,
PRE-TRANSPORTATION ROUTINE, will be run during the transport process. The
variable XPDGREF will be available to set information into the transport
global.", "", "", ""], ["2434", "DBIA2434", "Routine", "HEALTH LEVEL SEVEN", "1998/06/16", "APPROVED", "Active", "Supported", "", "
Patch HL*1.6*36 introduces 3 new entry points in
routine HLUTIL. These entry points support two new features, "Don't Purge" and
"Reprocessing" messages, which were originally requested by the CIRN project.
Patch HL*1.6*19 added a 4th API and restricted the use of all APIs to TCP/IP
connections.", "", "HLUTIL", ""], ["2435", "READ FILE 80 FILE HEADER", "File", "DRG GROUPER", "1998/06/19", "APPROVED", "Retired", "Private", "80", "
Clinical Reminders needs to be able to determine when a
new version of file 80 has been installed in order to keep its expanded
taxonomy cache current. In order to do this we would like to do a direct read
of pieces 3 and 4 of the file header, ^ICD9(0).", "", "", ""], ["2436", "READ FILE 80.1 FILE HEADER", "File", "DRG GROUPER", "1998/06/19", "APPROVED", "Retired", "Private", "80.1", "
Clinical Reminders needs to be able to determine when a
new version of file 80.1 has been installed in order to keep its expanded
taxonomy cache current. In order to do this we would like to do a direct read
of pieces 3 and 4 of the file header, ^ICD0(0).", "", "", ""], ["2437", "DBIA2437", "File", "REGISTRATION", "1998/06/21", "APPROVED", "Active", "Controlled Subscription", "405", "
References to ADT/Registration globals and routines.", "", "", ""], ["2438", "DBIA2438", "File", "REGISTRATION", "1998/06/22", "APPROVED", "Active", "Controlled Subscription", "40.8", "
Pharmacy Benefits Management (PBM) software needs to
extract the facility number from the Medical Center Division file #40.8.", "", "", ""], ["2439", "DBIA2439", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "44", "
Pharmacy Benefits Management (PBM) software needs to
access the division pointer from the Hospital Location File in order to
extract the facility number from the Medical Center Division File... Existing
DBIA #2432 would meet the need.", "", "", ""], ["2440", "DBIA2440", "File", "REGISTRATION", "1998/06/22", "APPROVED", "Active", "Controlled Subscription", "42", "
Pharmacy Benefits Managment (PBM) vs 3.0 (formerly
D&PPM) software needs to access the division pointer. This will be used to
extract the facility number from the Medical Center Division file.", "", "", ""], ["2441", "Obtain data from the Drug (50) file.", "File", "PHARMACY DATA MANAGEMENT", "1998/06/29", "APPROVED", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's.\n
Radiology/Nuclear Medicine obtains the following data from Pharmacy Data
Management's (PDM) Drug file:\n
field name field number node;piece purpose
--------------------------------------------------------------------------
Generic Name .01 0;1 display Generic Name\n
VA Classification 2 0;2 radiopharmaceutical check\n
Inactive Date 100 I;1 check if an active drug", "", "", ""], ["2442", "DBIA2442", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/06/30", "APPROVED", "Active", "Controlled Subscription", "74", "
CIRN needs read access to the ^RARPT global to
calculate the Master of Record score. Traversing the ^RARPT("C" x-ref, CIRN
uses $P(^RARPT(D0,0),U,3) to calculate the score.", "", "", ""], ["2443", "DBIA2443", "File", "SCHEDULING", "1998/06/30", "APPROVED", "Active", "Private", "409.68", "
CIRN traverses the ^SCE("C" x-ref and uses ^SCE(D0,0)
to calculate the Master of Record score.", "", "", ""], ["2444", "DBIA2444", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9000010", "
VISIT file access to zeroeth node.", "", "", ""], ["2445", "DBIA2445", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9000010.13", "
V EXAM file access.", "", "", ""], ["2446", "DBIA2446", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9000010.23", "
V HEALTH FACTORS file access.", "", "", ""], ["2447", "DBIA2447", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "900010.11", "
V IMMUNIZATION file access.", "", "", ""], ["2448", "DBIA2448", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9000010.16", "
V PATIENT ED file access.", "", "", ""], ["2449", "DBIA2449", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9000010.12", "
V SKIN TEST file access.", "", "", ""], ["2450", "DBIA2450", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Controlled Subscription", "9000010.15", "
V TREATMENT file access.", "", "", ""], ["2451", "DBIA2451", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9999999.09", "
EDUCATION TOPICS file access.", "", "", ""], ["2452", "DBIA2452", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9999999.15", "
EXAM file access.", "", "", ""], ["2453", "DBIA2453", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Controlled Subscription", "9999999.64", "
HEALTH FACTORS file access.", "", "", ""], ["2454", "DBIA2454", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Controlled Subscription", "9999999.14", "
IMMUNIZATION file access.", "", "", ""], ["2455", "DBIA2455", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Controlled Subscription", "9999999.28", "
SKIN TEST file access.", "", "", ""], ["2456", "DBIA2456", "File", "PCE PATIENT CARE ENCOUNTER", "1998/07/01", "APPROVED", "Active", "Private", "9999999.17", "
TREATMENT file access.", "", "", ""], ["2457", "DBIA2457", "File", "MENTAL HEALTH", "1998/07/01", "APPROVED", "Active", "Private", "627.8", "
DIAGNOSTIC RESULTS - MENTAL HEALTH file access.", "", "", "2012/06/04"], ["2458", "DBIA2458", "File", "AUTOMATED INFO COLLECTION SYS", "1998/07/01", "APPROVED", "Active", "Private", "357.69", "
TYPE OF VISIT file access.", "", "", ""], ["2459", "DBIA2459", "File", "FEE BASIS", "1998/07/01", "", "Retired", "Private", "161", "
FEE BASIS PATIENT file access.", "", "", ""], ["2460", "DBIA2460", "File", "REGISTRATION", "1998/07/01", "APPROVED", "Active", "Private", "2", "
PATIENT file access.", "", "", ""], ["2461", "DBIA2461", "File", "REGISTRATION", "1998/07/01", "APPROVED", "Active", "Private", "408.32", "
MEANS TEST STATUS file access.", "", "", ""], ["2462", "DBIA2462", "File", "REGISTRATION", "1998/07/01", "APPROVED", "Active", "Controlled Subscription", "27.11", "
PATIENT ENROLLMENT file access.", "", "", ""], ["2463", "DBIA2463", "Routine", "REGISTRATION", "1998/07/01", "APPROVED", "Active", "Private", "", "
Means Test utility routine.", "", "DGMTU", ""], ["2464", "DBIA2464", "Routine", "REGISTRATION", "1998/07/01", "APPROVED", "Active", "Private", "", "
Inpatient ward location utility.", "", "DGPMSTAT", ""], ["2465", "DBIA2465", "Routine", "REGISTRATION", "1998/07/01", "APPROVED", "Active", "Private", "", "
Provides ward location for a given inpatient movement.", "", "DGPMUTL", ""], ["2466", "DBIA2466", "File", "LAB SERVICE", "2005/05/25", "", "Retired", "Private", "63", "
CIRN needs read access to the ^LR( global to calculate
a Master of Record score.", "", "", ""], ["2467", "ORDERABLE ITEMS, PROMPT VALUES", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/07/06", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement will allow subscribers to
retrieve information from a specific order in the ORDER file (#100).", "", "ORX8", "2009/12/20"], ["2468", "DBIA2468", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
Integration agreement to use the call SC^SDCO23(DFN) to
display the patient's service connection percentage and rated disabilities as
part of the help text. This will display during the Event Capture Data Entry
options when a '?' is entered in response to the service connected
classification prompt.", "", "SDCO23", ""], ["2469", "LAB ACCESSING FIELD LAB LABEL PRINTER IN DEVICE FILE", "File", "KERNEL", "1998/07/07", "APPROVED", "Active", "Private", "3.5", "
Lab requests permission to access the LAB LABEL PRINTER
field (#101) in the Kernel DEVICE (#3.5) file. Field is used to determine if
user has a Lab label printer associated with the user's home device in the
DEVICE (#3.5) file. If an association exists then this device is used as the
default prompt for label printer instead of the standard LABLABEL device.\n
Code to access this field is as follows:\n
I $G(IOS) D ; Check if label device assigned to this user's HOME Device
. S X=$$GET1^DIQ(3.5,IOS_",",101,"E")
. I $L(X) S %ZIS("B")=X", "", "", ""], ["2470", "DBIA2470", "File", "PHARMACY DATA MANAGEMENT", "1998/07/07", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
This agreement will be retired on 12/31/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that can
be used in place of any code needing to make use of this agreement. These APIs
were released with patch PSS*1*101. Documentation information can be found in
the patch description. In addition, any code that currently utilizes this
Integration Agreement must be converted to use the new API's. If any part of
this Integration Agreement cannot be satisfied with the APIs, please contact
the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
CIRN needs read access to ^PS(55 to calculate the Master of Record score.", "", "", ""], ["2471", "DBIA2471", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
CIRN needs read access to ^PSRX, to calculate the
Master of Record score.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2472", "DBIA2472", "File", "NATIONAL DRUG FILE", "1998/07/09", "", "Retired", "Private", "50.605", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.", "", "", ""], ["2473", "DBIA2473", "File", "NATIONAL DRUG FILE", "1998/07/09", "", "Retired", "Controlled Subscription", "50.605", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
The FH SITE PARAMETERS (#119.9) file contains a multiple field called DRUG
CLASSIFICATIONS (#85) which points to the VA DRUG CLASS (#50.605) file. This
allows dietetics users to create a list of drug classes which are of interest
to clinicians. These drug classes will be looked for when running the Print
Nutrition Profile [FHASP1] option. Under the medications section of that
report the option will check the medications of the selected patient. If the
patient is on any medications that are defined in the DRUG CLASSIFICATIONS
multiple of the FH SITE PARAMETERS file, the option will display them in this
report.", "", "", ""], ["2474", "DBIA2474", "File", "PHARMACY DATA MANAGEMENT", "1998/07/09", "APPROVED", "Active", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.", "", "", ""], ["2475", "DBIA2475", "File", "PHARMACY DATA MANAGEMENT", "1998/07/09", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.", "", "", ""], ["2476", "PSOCMOP", "Routine", "OUTPATIENT PHARMACY", "1998/07/09", "APPROVED", "Active", "Private", "", "
This integration agreement between the Consolidated
Mail Outpatient Pharmacy (CMOP) package with the Outpatient Pharmacy V 7.0
(OP) package allows CMOP to call the routine PSOCMOP (used exclusively for
CMOP purposes) at line tag TEST from routine PSXRESUB. This call allows an Rx
fill that has been rejected by a CMOP host facility to be resubmitted to that
facility a single time.\n
Two input variables are passed to PSOCMOP: PPL = IEN of Rx in Prescription
file (#52) ZD(IEN of Rx in 52) = Current Date/Time\n
One output variable is returned: PPL = If contains a value indicates that Rx
was not eligible for CMOP
resubmission.
If null, then Rx has been placed in suspense for CMOP transmission.\n\n
CMOP Routine OP Routine Variables in Variables out\n
PSXRESUB TEST^PSOCMOP PPL PPL
ZD(IEN 52)", "", "PSOCMOP", ""], ["2477", "DBIA2477", "Routine", "OUTPATIENT PHARMACY", "1998/07/14", "APPROVED", "Active", "Private", "", "", "", "PSOLBL", ""], ["2478", "DBIA2478", "Routine", "OUTPATIENT PHARMACY", "1998/07/14", "", "Other", "Private", "", "", "", "PSOSULB1", ""], ["2479", "RAD/NUC MED REPORTS FILE (#74) ALL", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/07/14", "", "Under Revision", "Controlled Subscription", "74", "
The Women Veterans Health (WVH) package requests
permission to read with FileMan an entire RAD/NUC MED REPORTS file (#74) entry
and to display certain Radiology/Nuclear Medicine report information
concerning mammograms and breast ultrasound exams to the WVH users.\n
On August 11th 2020, Clinical Reminders (PXRM) requested subscription to this
Integration Agreement (IA) to access data in the RAD/NUC MED REPORTS file. It
was decided at this time that all current and future subscribers to this IA
would be granted full read with VA FileMan access to all fields in the RAD/NUC
MED REPORTS file.\n
Please note that as of this date (08/20/2020) the following fields are
computed and have no global location:\n
Field # Field Name
------- ----------
102 PROCEDURE
103 EXAM STATUS
104 CATEGORY OF EXAM
106 WARD
107 SERVICE
108 PRINCIPAL CLINIC
109 CONTRACT/SHARING SOURCE
109.5 RESEARCH SOURCE
112 PRIMARY INTERPRETING RESIDENT
113 PRIMARY DIAGNOSTIC CODE
114 REQUESTING PHYSICIAN
115 PRIMARY INTERPRETING STAFF
116 COMPLICATION
118 PRIMARY CAMERA/EQUIP/RM
119 BEDSECTION", "", "", ""], ["2480", "RAD/NM PATIENT FILE (#70)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/07/14", "APPROVED", "Active", "Controlled Subscription", "70", "
The Women Veterans Health (WVH) package requests
permission to view the following fields from the RAD/NUC MED PATIENT file
(#70):\n
[Modified 5/26/2009 to include Pregnancy Screen,Pregnancy Screen Comment and
Imaging Order.]\n
[Modified 08/04/2011 to include read w/FileMan access to the VISIT field
(70.03;27). The request was made by AViVA (VPR).]", "", "", "2012/05/24"], ["2481", "RAD/NUC MED PROCEDURES (#71)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/07/14", "APPROVED", "Active", "Private", "71", "
The Women Veterans Health (WVH) package requests
permission to view the CPT Code associated with a Radiology/NM procedure to
determine if the procedure is a mammogram or breast ultrasound procedure.", "", "", ""], ["2482", "PROCEDURE MODIFIERS (#71.2)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/07/14", "APPROVED", "Active", "Private", "71.2", "
The Women Veterans Health (WVH) package requests
permission to view the NAME field of the PROCEDURE MODIFIERS file (71.2) to
determine which modifiers were used for a Radiology procedure.", "", "", ""], ["2483", "FILE 2 IA for WVH", "File", "REGISTRATION", "1998/07/15", "APPROVED", "Active", "Private", "2", "
The Women Veterans Health package would like to view
the following fields in the Patient File (#2):", "", "", ""], ["2484", "DIAGNOSTIC CODES (78.3)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/07/15", "APPROVED", "Active", "Private", "78.3", "
The Women Veterans Health (WVH) package requests
permission to point to the DIAGNOSTIC CODES (78.3) file so that the WV
RESULTS/DIAGNOSIS file (790.31) file entries can be associated with the
Radiology diagnostic codes.\n
Revision:
12/8/23 - Effective with WV*1.0*32, ICR updated to allow access to read a
new field DISPLAY TEXT, #100, in file 78.3", "", "", "2023/12/19"], ["2485", "DBIA2485", "Routine", "FEE BASIS", "1998/07/17", "APPROVED", "Active", "Controlled Subscription", "", "
This API builds the ZFE HL7 segments for a specified
veteran. These segments contain FEE Authorization data.", "", "FBHLZFE", ""], ["2486", "LOGGING PATIENTS FOR THE NIGHTLY TRANSMISSION", "Routine", "INCOME VERIFICATION MATCH", "1998/07/20", "APPROVED", "Active", "Controlled Subscription", "", "", "", "IVMPLOG", ""], ["2487", "CMOP MAILGROUP ACCESS", "File", "MAILMAN", "1998/07/28", "APPROVED", "Active", "Private", "3.8", "
The Consolidated Mail Outpatient Pharmacy (CMOP)
package requires access to the "B" cross reference in the Mailgroup (3.8)
File. This access will be limited to CMOP V 2.0 software and the routine
PSXPOST.", "", "", ""], ["2488", "IA2488", "File", "HEALTH LEVEL SEVEN", "1998/08/04", "APPROVED", "Active", "Private", "772", "\n\n
The Lab requests a DBIA from HL7 for the following reference:\n
^HL(772,176674,"P") = 4^2980419.101639^EventProtocol not found^13\n
Using the code: S LRSTATUS=+$G(^HL(772,LRMID,"P"))\n
I plan to use this during the acknowledgement process of NCH messages from
Austin.\n\n
REFERENCE FORUM MESSAGE: 27535419", "", "", ""], ["2489", "FILE CORRECTIONS", "File", "KERNEL", "1998/08/05", "", "Withdrawn", "Private", "9.4", "\n
More than one Library Package entry exists from the testing and
installation of Version 2.5 and Patches 1-4. We would like permission
to update the site's Package File #4 with one active and accurate
Library entry under the name LIBRARY and namespace LBR. It will
contain a '2.5' VERSION multiple with all the patch installations. If
the '2.5V1' VERSION multiple is present (this was created from the 2.5
version installation), we would like to create a '2.5' VERSION
multiple as a copy of the '2.5V1' multiple. If the Package File entry
for Library v.1.2 is present, we would like to rename it as
LIBRARY(OLD) under the renamed namespace LBRZ. This would eliminate
the need for DBIA #2142 "INSTALL File Read". If any other entries are
located, except the LBRN and LBRT entries (apart of 2.5 installation),
we would like to delete them. We would also like to update the
CURRENT VERSION field with the latest version 2.5. This will prevent
any future NOIS logs related to this.\n
In order to complete this update, we would like to modify the Package
File entry that Patch LBR*2.5*7 linked to in the load. This
modification would use FILE^DIE to update the NAME and PREFIX to
LIBRARY and LBR, respectively. Then to continue with the update, we
would like to use FIND^DIC to locate all Package File entries having a
PREFIX beginning with "LBR". From each of these Package file entries,
we would like to use FIND^DIC to locate the '2.5V1' VERSION multiple
entry. We would then like to use the IEN from the '2.5V1' VERSION
multiple entry and GETS^DIQ to retrieve the DATE DISTRIBUTED (1), DATE
INSTALLED AT THIS SITE (2), INSTALLED BY (3), and DESCRIPTION OF
ENHANCEMENTS (41) fields to create a '2.5' VERSION multiple.\n
To rename the v.1.2 package file entry, we would like to use FILE^DIE
to change the NAME and PREFIX fields to LIBRARY(OLD) and LBRZ,
respectively. To remove all unimportant Library Package file entries,
we would like to use ^DIK.\n
In order to update the CURRENT VERSION field, we would like to use
GET1^DIQ to retrieve the present CURRENT VERSION field value and
FILE^DIE to change it to "2.5".\n", "", "", ""], ["2490", "PATCH INSTALLATION CHECK AND UPDATE", "File", "KERNEL", "1998/08/05", "", "Withdrawn", "Private", "9.7", "\n
In order to complete all corrections to the Package File #9.4
referenced in DBIA #2489, we would like to have permission to check
and update any Library Package Patch installations stored in the
Install File #9.7. To locate the Library v.2.5 patches, we would like
to use FIND^DIC and extract the entries' corresponding data in their
STATUS(.02), PACKAGE FILE LINK(1), INSTALLED BY(9), and INSTALL
COMPLETE TIME(17) fields. For each Library patch install entry, we
would also like to use GET1^DIQ to extract the internal value for the
pointer in the PACKAGE FILE LINK field. In order to update this field
with the pointer to the correct Library Package File entry, we would
like to use FILE^DIE. Error checking for each check and update will
be performed.\n", "", "", ""], ["2491", "DBIA 16B", "File", "SURGERY", "1998/08/10", "APPROVED", "Active", "Private", "130", "
This amends DBIA #16 to include file reference used for
OP and NON-OP Health Summary.", "", "", ""], ["2492", "DBIA2492", "File", "REGISTRATION", "1998/08/17", "APPROVED", "Active", "Private", "45", "
CIRN needs read access to ^DGPT to calculate the Master
of Record Score\n
Global Reference:\n
^DGPT('B',\n
The "B" cross-reference is used to find a specific PTF record for a patient.
The RGVCCMR2 routine orders through the 'B' cross-reference
$O(^DGPT("B",+DFN,NXPTF to order through the ^DGPT(NXPTF,0 for admission
dates.
It compares the admission dates to current year, and past two years to
calculate the CMOR score.\n
^DGPT(D0,'S',0\n
Direct Read orders through ^DGPT(NXPTF,"S",0 for the surgury/procedure dates.\n
^DGPT(D0,0 2 Admission Date 0;2 Direct Global Read\n
CIRN is looking for patient(s) activity over a three-year period.", "", "", ""], ["2494", "DBIA-2494 PDM-Delete bad field global", "File", "PHARMACY DATA MANAGEMENT", "1998/08/11", "APPROVED", "Active", "Supported", "50", "
To resolve NOIS # EKH-0798-41058, we are inserting a
line of code to delete the impartial field data found in File #50. We believe
that the ^DD(50,0,"ID",534016) global is a local site-specific field. We do
not have a zero node that identifies the field name. We are adding a line of
code to routine PSSPCH13 that checks for the zero node. If not there, it will
delete the data related to the field number 534016.\n
Example. I '$D(^DD(50,534016)) K ^DD(50,0,"ID",534016).\n
This change is included in patch PSS*1*13.", "", "", ""], ["2495", "DBIA2495", "File", "KERNEL", "1998/08/11", "APPROVED", "Active", "Private", "7", "
Pharmacy Benefits Management needs to extract the name
and abbrev from the Provider Class File #7. The provider pointer (#200) will
be obtained from various pharmacy files. The new person provider class field
#53.5 will be then be used to extract the name and abbrev from the Provider
Class File.", "", "", ""], ["2496", "MAILMAN SITE PARAMETERS", "File", "MAILMAN", "1998/08/11", "APPROVED", "Active", "Private", "4.3", "
Pharmacy Benefits Managment is an extract program. It
will extract Pharmacy IV, Unit dose, prescription, Controlled substance and
ward stock order information along with Procurement and a limited amount of
laboratory data. The data will be sent via MailMan message to Pharmacy
Benefits Management section at Hines and incorporated into their national
database. These messages will be very long and we wanted to make sure that the
PBM software 'honored' the sites wishes to limit their message line #. If we
do not find a number in the NETWORK -MAX LINES @ SEND TO field, the program
will limit the message to 10,000 lines.", "", "", "2012/06/26"], ["2497", "DBIA2497", "File", "PHARMACY DATA MANAGEMENT", "1998/08/12", "APPROVED", "Active", "Controlled Subscription", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
Pharmacy Benefits Management extracts data from the following Pharmacy Patient
File #55 fields.", "", "", ""], ["2498", "DBIA2498", "File", "CONTROLLED SUBSTANCES", "1998/08/12", "APPROVED", "Active", "Private", "59.4", "
Pharmacy Benefits Managment will extract the inpatient
name from the Inpatient Site file #59.4.", "", "", ""], ["2499", "DBIA2499", "File", "INPATIENT MEDICATIONS", "1998/08/12", "APPROVED", "Active", "Private", "59.5", "
Pharmacy Benefits Management extracts the following
fields from the IV Room file #59.5:\n
.02 Division .104 LVP'S GOOD FOR HOW MANY DAYS .111
HYPERAL GOOD FOR HOW MANY DAYS .112 PB'S GOOD FOR HOW MANY DAYS 17
SYRN'S GOOD FOR HOW MANY DAYS 18 CHEMO'S GOOD FOR HOW MANY DAYS", "", "", ""], ["2500", "DBIA 2500", "Routine", "KERNEL", "1998/08/12", "APPROVED", "Active", "Private", "", "
Requesting approval to use DOLRO^%ZOSV.\n
This entry is in every Kernel %ZOSV and only requires the variable X as input
as to where the user wants to store a list of the variables in the partition.\n
This functionality is desired and it is located within the Kernel for each
platform that Kernel runs on.\n
Its use is requested so that seperate hardcoded routines for each platform do
not have to be written to achieve the same functionality.\n\n
This request is made in behalf of the Pharmacy Benefits Program (PSU) and
McKinley Enterprises | WesTech Computer Group (BTW) who is coding PBM under
contract with EDS through the VA - EDS Partnership.", "", "%ZOSV", ""], ["2501", "DBIA2501", "File", "SCHEDULING", "1998/08/17", "APPROVED", "Active", "Private", "40.7", "
CIRN needs read access to ^DIC(40.7,'C' to calculate
the Master of Record Score\n", "", "", ""], ["2502", "DBIA2502", "Routine", "PCE PATIENT CARE ENCOUNTER", "1998/08/18", "APPROVED", "Active", "Private", "", "
An integration agreement is needed with the PCE package
for the Scheduling data conversion project. The PCE package's standard filer
entrypoints require that all providers added to PCE for a visit have a valid
provider class. The problem is that some of the encounters that the
Scheduling conversion can convert will consist of old provider data where the
provider class for the provider does not exist. As a result, many many
providers will not be able to be converted with their visits/encounters
because they do not have a valid provider class. Denis Eaton was consulted
about this and he concluded the only way to store these old providers in PCE
would be to pre-set the global array that PCE uses to file the data to what it
would look like after all the edit checks were done, and call the filer
directly. Since the affected provider data is old and its corresponding visit
will be flagged as historical in PCE, there should not be a data integrity
issue with storing a provider without a valid provider class. It also makes
the conversion more consistent and complete. This exemption is requested
specifically for filing the new provider data and would be a one-time
exemption to be used only when new visits are created as a result of the
conversion. All other data added to PCE via this project would flow through
the normal PCE edits. The agreement would only exist for the life of the
conversion.\n
The array definition follows:\n
^TMP("PXK",$J,"SOR") = Source ien\n
^TMP("PXK",$J,"VST",1,0,"BEFORE") = the 0-node of the visit file
^TMP("PXK",$J,"VST",1,0,"AFTER") = the same as "BEFORE"
^TMP("PXK",$J,"VST",provider counter,"IEN") = ""\n
^TMP("PXK",$J,"PRV",provider counter,0,"BEFORE") = ""
^TMP("PXK",$J,"PRV",provider counter,0,"AFTER") = Provider id^DFN^Visit
ien^P/S for primary/secondary
^TMP("PXK",$J,"PRV",provider counter,"IEN") = "" ^TMP("PXK",$J,"PRV",provider
counter,"BEFORE") = "" ^TMP("PXK",$J,"PRV",provider counter,"AFTER") =
^Package ien^Source ien\n
The entrypoint to call for the post-edit filer is EN1^PXKMAIN", "", "PXKMAIN", ""], ["2503", "USE OF LR7OR1", "Routine", "LAB SERVICE", "1998/08/18", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA formalizes the documentation for calls to
LR7OV1 as documented in the OE/RR Interface Specification document.", "", "LR7OR1", ""], ["2504", "DBIA2504", "File", "REGISTRATION", "1998/08/19", "APPROVED", "Active", "Private", "21", "
Lab is requesting a temporary aggreement to read the
following:\n
;NOW GET PERIOD OF SERVICE
K VAEL D ELIG^VADPT
S:$G(VAEL(2))'="" $P(MSG,HLFS,28)=$P($G(^DIC(21,+VAEL(2),0)),U,3)
K VAEL\n", "", "", ""], ["2505", "INPATIENT SITE", "File", "CONTROLLED SUBSTANCES", "1998/08/20", "APPROVED", "Active", "Private", "59.4", "\n
In the DRUG ACCOUNTABILITY STATS file (#58.8), there is a field called
INPATIENT SITE (#2). This field is a pointer to the NAME field (.01) of
the INPATIENT SITE file (#59.4). To obtain the external value of this
pointer, a direct global read is used.", "", "", ""], ["2506", "DBIA2506", "File", "HEALTH LEVEL SEVEN", "1998/08/20", "", "Withdrawn", "Private", "772", "
The lab package request a direct read on the "IN"
subscript of file 772 as follows: S
LRMN=$P($G(^HL(772,LRMID,"IN",1,0)),HLFS,10)\n
This will only be needed `till the next extract update.\n", "", "", ""], ["2507", "DBIA2507", "File", "HEALTH LEVEL SEVEN", "1998/08/20", "APPROVED", "Active", "Controlled Subscription", "771.6", "
Lab requests permission to read file 771.6 as follows:\n
I $G(LRSTATUS) S LRTXT(LRX)="Message: "_LRX_$P(^HL(771.6,+LRSTATUS,0),U)\n
This call will be converted in the next version of the extract.", "", "", ""], ["2508", "2508", "File", "KERNEL", "1998/08/20", "APPROVED", "Active", "Private", "4", "
The lab requests a DBIA to perform a direct read on the
following:\n
S:$D(^DIC(4,"D",SITE)) ISITE=$O(^DIC(4,"D",SITE,0)) I
+ISITE>0,$G(^DIC(4,ISITE,0))'="" S SITE=$P(^DIC(4,SITE,0),U,1)\n", "", "", ""], ["2509", "DBIA2509", "File", "KERNEL", "1998/08/24", "APPROVED", "Active", "Private", "19", "
Surgery requests permission to $O through the OPTION
file (#19) "B" cross reference to identify options in the SR namespace.
Surgery further requests READ access by VA FileMan to the ENTRY ACTION field
(#20) and WRITE access to the XQUIT EXECUTABLE field (#22). The purpose of
this request is to allow Surgery to issue a patch that will identify the
Surgery options that may potentially set the XQUIT variable and to update
these options with code to process the XQUIT.", "", "", ""], ["2510", "DBIA2510", "File", "OUTPATIENT PHARMACY", "1998/08/24", "APPROVED", "Active", "Private", "59", "
Pharmacy Benefits Management extracts data from the
division fields of the prescription file (#52) and outpatient site field of
the drug accountability stats file (#58.8). These fields point to the
Outpatient site file #59 from which the outpatient site name and number can be
extracted.", "", "", ""], ["2511", "DBIA2511", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "53", "
Pharmacy Benefits Management extracts the Rx Patient
status from the Prescription file to determine the AMIS workload category for
a prescription. THIS REQUEST IS FOR VERSION 6 OF OUTPATIENT PHARMACY ONLY.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2512", "DBIA2512", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
Pharmacy Benefits Management extracts various data
elements from the PRESCRIPTION file #52 for a selected time frame. In order to
obtain the data desired and to use the supported DBIA 1878 provided for
version 7 of Outpatient Pharmacy access is needed to the following. DBIA 1878
requires the DFN and RX IEN, i.e. D EN^PSOORDER(DFN,RX).\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2513", "DBIA2513", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
Pharmacy Benefits Management extracts data elements
from the PRESCRIPTION file (#52) for a selected time frame. This is for
version Outpatient Pharmacy V. 6.0 only.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2514", "ACCESS TO DRUG INGREDIENTS FILE (#50.606)", "File", "PHARMACY DATA MANAGEMENT", "1998/08/24", "APPROVED", "Active", "Private", "50.606", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
National Drug File has need to do a direct global read to the zero node of
file 50.606.", "", "", ""], ["2515", "DBIA2515", "File", "AUTO REPLENISHMENT/WARD STOCK", "1998/08/24", "APPROVED", "Active", "Private", "58.1", "
Pharmacy Benefits Management extracts the following
fields from File #58.1, Pharmacy AOU Stock in order to attempt to breakdown
the AR/WS statistical data by division.\n
Various portions of the program $O through ^PSI(58.1,D0,0), ^PSI(58.1,D0,2,0
and ^PSI(58.1,"ASITE",in order to use various Area of Uses (AOU) to map an
inpatient site to a specific division by using the ward/location (for
percentage) field.", "", "", ""], ["2516", "DBIA2516", "File", "REGISTRATION", "1998/08/24", "APPROVED", "Active", "Controlled Subscription", "8.1", "
^DIC(8.1,D0,0) .01 NAME 0;1 Direct Global Read 6
INACTIVE 0;7 Direct Global Read\n\n
One of the CIRN pre-implementation steps is to compare the entries in the
ELIGIBILITY CODE file (#8) and the MAS ELIGIBILITY CODE file (#8.1). This is
to insure that all the entries in File 8 link to a corresponding entry in File
8.1.\n
The CIRN ELIGIBILITY CODE REVIEW report, routine RGPRELIG, displays these
links.", "", "", ""], ["2517", "FILE405 ADFN X-REF", "File", "REGISTRATION", "1998/08/24", "APPROVED", "Active", "Private", "405", "
The Women Veterans Health (WVH) package requests
permission to loop through the ADFN cross-reference to determine if a patient
has an entry within a user selected date range. The WVH package does not want
to look at the entry itself, but is merely interested in whether the patient
has a record.", "", "", ""], ["2518", "OUTPATIENT DRUG INTERACTION", "Routine", "NATIONAL DRUG FILE", "1998/08/25", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy V 6.0 package (OP) requests the
ability to re-route the Drug-Drug interaction function to the National Drug
File's (NDF) routine PSNDINT. Upcoming new functionality by NDF will
eventually replace the OP Drug-Drug interaction functionality. During the
installation period this would allow the users a painless introduction to the
new functionality. After a period of time the OP options will be removed. OP
ROUTINE/LINETAG ADD+1^PSOHELP Add local drug interactions CRI+1^PSOHELP
Change interaction severity\n
Both call PSNDINT at the top. No variables are passed or returned.", "", "PSNDINT", ""], ["2519", "DBIA2519", "File", "DRUG ACCOUNTABILITY", "1998/08/30", "APPROVED", "Active", "Private", "58.8", "
Pharmacy Benefits Management extracts the following
fields from the Drug Accountability Stats file #58.8 on a montly basis.", "", "", ""], ["2520", "DBIA2520", "File", "DRUG ACCOUNTABILITY", "1998/08/30", "APPROVED", "Active", "Private", "58.81", "
Pharmacy Benefits Management extracts data from the
Drug Accountability Transaction file #58.81 on a monthly basis. The program
uses the ^PSD(58.81,"AF" cross reference on the date/time field to identify
certain types of controlled substance and procurement transactions.", "", "", ""], ["2521", "DBIA2521", "File", "DRUG ACCOUNTABILITY", "1998/08/30", "APPROVED", "Active", "Private", "58.811", "
Pharmacy Benefits Management extracts data from the
Drug Accountability Order file #58.811 on a monthly basis.\n
The program utilizes the ^PSD(58.811,"ADATE", cross reference to identify
prime vendor invoices for a specific time period.", "", "", ""], ["2522", "DBIA2522", "File", "LAB SERVICE", "1998/08/30", "APPROVED", "Active", "Private", "64", "
Pharmacy Benefits Management utilizes the Wkld Code
file #64 to identify national laboratory tests with a specific wkld code and
then which local laboratory tests are linked.\n\n
The ^LAM("C" cross reference will be used to identify national laboratory test
with a specific wkld code.\n
The ^LAM(D0,7,"B", cross refernce on the associated name field will be used to
identify all local laboratory tests linked to specific wkld codes.", "", "", ""], ["2523", "DBIA2523", "File", "LAB SERVICE", "1998/08/30", "APPROVED", "Active", "Private", "60", "
Pharmacy Benefits Management extracts data from the
Laboratory test file #60.\n
Only local laboratory tests with a site/specimen that contains 'plasma',
'serum' or 'blood'. The name, units and the location of the test result data
can then be extracted.", "", "", ""], ["2524", "DBIA2524", "File", "LAB SERVICE", "1998/08/30", "APPROVED", "Active", "Private", "63", "
Pharmacy Benefits Management extracts test results
(^LR(D0,CH,0)=^63.04^^ for certain laboratory tests, the hi/lo flag and the
date/time the specimen was taken. The program will go back one year and pull
the most recent result for a particular lab test.", "", "", ""], ["2525", "POINTER TO FILE 870", "File", "HEALTH LEVEL SEVEN", "1998/09/02", "", "Retired", "Private", "870", "
CIRN would like to store in the CIRN SITE PARAMETER
file (#991.8) a pointer to the HL LOGICAL LINK file (#870) for the MPI logical
link.\n
In the CIRN SITE PARAMETER file (#991.8), the MPI LINK field (#36) points to
File #870. The Master Patient Index (MPI) is used to send messages to the MPI
in Austin.\n
IA retired. See IA 3335 for current documentation.", "", "", ""], ["2526", "PRCHUTL", "Routine", "IFCAP", "1998/09/03", "APPROVED", "Active", "Private", "", "
This integration agreement will allow Accounts
Receivable to call two functions in this routine. $$VENSEL will return the
internal number of a user selected Vendor from the IFCAP Vendor file. $$VEN
will return the Vendor ID number when the internal number of a Vendor is sent
to this function.", "", "PRCHUTL", ""], ["2527", "DBIA2527", "File", "NATIONAL DRUG FILE", "1998/09/01", "APPROVED", "Active", "Controlled Subscription", "50.612", "", "", "", ""], ["2528", "DBIA2528", "File", "PROSTHETICS", "1998/09/03", "APPROVED", "Active", "Private", "660", "
DSS needs to reference the following fields to extract
Prosthetics information for the DSS Program.\n
Additionally, DSS Extracts need to $Order through the ^RMPR(660,"CT")
cross-reference to pull the Delivery date from the prosthetics entries. the
'C' cross-reference is on the Delivery Date field (#10).", "", "", ""], ["2529", "DBIA2529", "File", "PROSTHETICS", "1998/09/03", "APPROVED", "Active", "Private", "669.9", "
DSS Extracts has permission to $Order through the 'C'
Cross-Reference on the Prosthetics Site Parameters file (#669.9).
[^RMPR(669.9,"C")] The 'C' Cross-Reference is on the Station field (#1) which
points to the Institution file (#4).", "", "", ""], ["2530", "IB INSURANCE BUFFER ACCEPT/REJECT UPDATES", "Routine", "INCOME VERIFICATION MATCH", "1998/09/15", "APPROVED", "Active", "Private", "", "
Integrated Billing calls the IVM function
$UPDATE^IVMLINS4 when an IB Insurance Buffer file entry that originated in IVM
is either accepted or rejected.\n
With patch IVM*2*135, IVMREPTR and IVMSUPPR variables were added to the API.", "", "IVMLINS4", "2009/04/13"], ["2531", "Application Programmer Interfaces (APIs)", "Routine", "NATIONAL DRUG FILE", "1998/09/04", "APPROVED", "Active", "Supported", "", "
Since the National Drug File is being redesigned, these
APIs are designed to allow other applications to make a smooth transition to
the new file structure.", "", "PSNAPIS", ""], ["2532", "DBIA2532", "File", "TOOLKIT", "1998/09/04", "APPROVED", "Active", "Private", "15", "
In routine RGMTDPCT, CIRN counts duplicate entries for
the PATIENT file (#2) in the DUPLICATE RECORD file (#15) by STATUS or MERGE
STATUS It then counts the match percentile for the following:\n
For STATUS it matches on (P) potential duplicates, (N) verified, notduplicate,
(V) verified duplicate, (X) verified in progress, and (R) required review.\n
For MERGE STATUS the matches are counted on (0) not ready, (1) ready, (2)
merged, and (3) in progress.\n
In routine RGMTDPSC, CIRN searches file #15 for duplicate pairs and displays
this information by the CIRN Master of Record (CMOR) activity score range.
The ranges are in 100'2 with a separate range for pairswhere both members have
no score and where both members have zero score or one member has a zero
score and the other has no score.\n
The reports will give sites an idea of the active patients (with a CMOR score,
incl 0) that are deemed duplicates.\n
File: DUPLICATE RECORD (#15)\n
^VA(15,D0,0) .01 RECORD1 0;1 Direct Global Read .02
RECORD2 0;2 Direct Global Read .03 STATUS
0;3 Direct Global Read .05 MERGE STATUS 0;5 Direct Global Read\n", "", "", ""], ["2533", "DBIA2533", "Routine", "KERNEL", "1998/09/08", "APPROVED", "Active", "Controlled Subscription", "", "
DSS has permission to use the Kernel function
DIV4^XUSER according to the following:\n
XUSER New file 200 API for DSS.
The call is S X=$$DIV4^XUSER(.ZZ[,duz])\n
Input: The first parameter is a local variable that
is passed by reference.
The second is an optional IEN to the New Person file.
If not passed it defaults to the current DUZ.\n
Output: Returns a 1 if the user has a Division entry
in the New Person file, else returns 0.
If it returns a 1 then the first parameter is an array
of IEN's for file 4 that have been assigned to the user.\n", "", "XUSER", ""], ["2534", "DBIA2534", "Routine", "OUTPATIENT PHARMACY", "1998/09/08", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement provides CPRS two entry points to call
that will return flags that indicate whether or not to ask various
Copay-related questions concerning the Outpatient order being entered through
CPRS. Prior to the effective date of the Veterans Millennium Health Care and
Benefits Act, the only question that should be asked in CPRS is the Service
Connected question. After the effective date of the Bill, seven additional
questions can potentially be asked during the medication order process in
CPRS.", "", "PSOCP", ""], ["2535", "DBIA2535", "Routine", "MENTAL HEALTH", "1998/09/08", "", "Active", "Supported", "", "
GAF API'S\n
The purpose of this patch is the creation of two API's for use with Mental
Health system's Global Assessment of Function (GAF) Scores. The API's will be
used to (1) return the most recent GAF score and diagnosis date the score was
assessed and (2) store a new GAF score and date in the Diagnostics Results
file (627.8). These two API's have been added to routine YSGAF.\n\n
10/30/13: The recently released Diagnostic and Statistical Manual of Mental
Disorders, Fifth Edition, abbreviated as DSM-5, eliminates the use of the
Global Assessment of Functioning (GAF) score. Starting with patch YS*5.01*108,
new GAF scores for patients will no longer be saved in the Mental Health
package. Historical data will continue to be available. The UPD call will set
the YSERR variable equal to 1 and write an informational message.", "", "YSGAF", ""], ["2536", "Prosthetics IA With the PAID Employee File (#450)", "File", "PAID", "1998/09/09", "APPROVED", "Active", "Private", "450", "
Prosthetics is requesting read access to the following
fields in the PAID Employee File (#450):\n
Field (#8) SSN,
(#19) Pay Basis,
(#28) Salary", "", "", ""], ["2537", "DBIA2537", "Routine", "INTEGRATED BILLING", "1998/09/15", "APPROVED", "Active", "Private", "", "
The IVM package requests use of the function
$$ADDSTF^IBCNBES to add a new entry to the INSURANCE BUFFER file (#355.33).
This data was received at the site from HEC (IVM Center).", "", "IBCNBES", ""], ["2538", "DBIA2538", "Routine", "INTEGRATED BILLING", "1998/09/15", "APPROVED", "Active", "Private", "", "
The Registration package requests use of REG^IBCNBME to
add/edit a INSURANCE BUFFER file (#355.33) entry for registration and use of
PREG^IBCNBME to add/edit a INSURANCE BUFFER file (#355.33) entry for
pre-registration.", "", "IBCNBME", ""], ["2539", "DELETE OPTIONS", "File", "KERNEL", "1998/09/21", "APPROVED", "Active", "Private", "19", "
This integration agreement is only for Registration.
Permission to loop through the "B" xref on the option file to delete all
'DG172' namespaced options created by the DG*5.3*172 patch.", "", "", ""], ["2540", "BROWSER SWITCHING", "Routine", "1", "1998/09/21", "APPROVED", "Active", "Private", "", "
The purpose of this DBIA is to provide a temporary
method for switching between 'documents' without the user having to mentally
resolve pointers between records in two different files. The needed
functionality is currently planned by the VA Fileman developers to released in
a patch. When that patch is released, the HL7 developers will modify the
Transmission Log code to use the released functionality.\n
See IA# 3594.", "", "DDBR2", ""], ["2541", "DBIA2541", "Routine", "KERNEL", "1998/09/21", "APPROVED", "Active", "Supported", "", "
This DBIA documents the supported calls to XUPARAM to
get some KERNEL SYSTEM parameters fields.", "", "XUPARAM", ""], ["2542", "DBIA2542", "Routine", "KERNEL", "1998/09/21", "APPROVED", "Active", "Supported", "", "
These are calls to set or get simple parameters from a
file that the site can edit. The file is KERNEL PARAMETERS (#8989.2)", "", "XUPARAM", ""], ["2543", "DBIA2543", "File", "1", "1998/10/07", "APPROVED", "Active", "Private", "1", "", "", "", ""], ["2544", "DBIA2544", "File", "INCOME VERIFICATION MATCH", "1998/10/08", "APPROVED", "Active", "Private", "301.5", "
When the AMIE package deletes entries from the PATIENT
file (#2) it also needs to delete entries from the IVM PATIENT file (#301.5).
^IVM(305.1,"B" is used to determined which entries are to be deleted in the
IVM PATIENT file.\n
A cleanup is done to delete current entries in the IVM PATIENT file which
point to non-existing or non-veterans in the PATIENT file. These entries are
deleted using a DIK call. ^IVM(301.5,D0,0 is used to determine if IVM PATIENT
file entries should be deleted.", "", "", ""], ["2545", "ALLERGY DATA FOR NDF", "File", "ADVERSE REACTION TRACKING", "2005/04/26", "APPROVED", "Active", "Private", "120.8", "
The data structure of the National Drug File changes
with version 4. Allergy Tracking uses a variable pointer to NDF. These data
elements must be converted when NDF version 4 is installed.\n
Pharmacy also needs to be able to directly access the DRUG INGREDIENTS
multiple in order to update any non-primary ingredients to their associated
primary ingredient. Direct global access to ^GMR(120.8,D0,2 is necessary in
order to perform this update.\n
Amended August 2022: Patch PSN*4.0*574 needs access to the REACTANT (#.02)
field. A correction is needed which was caused by an erroneous NDC/UPN
(#50.67) file entry for "COFLEX". (See patch description for more
information.)", "", "", "2022/08/29"], ["2546", "ACRP INTERFACE TOOLKIT (AIT)", "Routine", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
The ACRP Interface Toolkit (AIT) is a set of programmer tools that
provides access to outpatient encounter data. The toolkit contains
Application Programmer Interfaces (APIs) and Remote Procedure Calls
(RPCs) that provide access to procedure, diagnosis, provider, and
general data related to an encounter.\n
This AIT provides Class I packages, Class III software, and other local
code with one highly structured interface to the encounter data.\n\n\n
Note: For detail information on each specific API call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "", "SDOE", ""], ["2547", "DBIA2547", "Routine", "CLINICAL REMINDERS", "2001/09/19", "APPROVED", "Active", "Private", "", "", "", "PXRMMST", ""], ["2548", "ACRP INTERFACE TOOLKIT (AIT)", "Routine", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
The ACRP Interface Toolkit (AIT) is a set of programmer tools that
provides access to outpatient encounter data. The toolkit contains
Application Programmer Interfaces (APIs) and Remote Procedure Calls
(RPCs) that provide access to procedure, diagnosis, provider, and
general data related to an encounter.\n
This AIT provides Class I packages, Class III software, and other local
code with one highly structured interface to the encounter data.\n\n\n
Note: For detail information on each specific API call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "", "SDQ", ""], ["2549", "DBIA2549", "File", "LAB SERVICE", "1998/09/22", "", "Pending", "Private", "66", "
Direct global read of BLOOD PRODUCTS (#66). The codes
uses NAME(#.01) and PRODUCT CODE(#.05).", "", "", ""], ["2550", "DBIA2550", "File", "LAB SERVICE", "1998/09/22", "", "Pending", "Private", "", "
Direct global read of BLOOD BANK UTILITY(#65.4) The
code uses FULLNAME(#.03)", "", "", ""], ["2551", "DBIA2551", "File", "LAB SERVICE", "1998/09/22", "", "Pending", "Private", "60", "
Direct global read of LABORATORY TEST File(#60) The
code uses LOCATION(DATA NAME)(#5), ASK AMIS/CAP CODES(#501) TYPE(#3) and
FIELD(#13)", "", "", ""], ["2552", "ACRP INTERFACE TOOLKIT (AIT)", "Routine", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
The ACRP Interface Toolkit (AIT) is a set of programmer tools that
provides access to outpatient encounter data. The toolkit contains
Application Programmer Interfaces (APIs) and Remote Procedure Calls
(RPCs) that provide access to procedure, diagnosis, provider, and
general data related to an encounter.\n
This AIT provides Class I packages, Class III software, and other local
code with one highly structured interface to the encounter data.\n\n\n
Note: For detail information on each specific API call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "", "SDQUT", ""], ["2553", "SDOE ASSIGNED A DIAGNOSIS", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a boolean indicator on
whether at least one diagnosis has been associated with an encounter.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE ASSIGNED A DIAGNOSIS", "", ""], ["2554", "SDOE ASSIGNED A PROCEDURE", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a boolean indicator on
whether at least one procedure has been associated with an encounter.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE ASSIGNED A PROCEDURE", "", ""], ["2555", "SDOE ASSIGNED A PROVIDER", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a boolean indicator on
whether at least one provider has been associated with an encounter.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE ASSIGNED A PROVIDER", "", ""], ["2556", "SDOE FIND DIAGNOSIS", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a boolean indicator on
whether a specific diagnosis has been associated with an encounter.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE FIND DIAGNOSIS", "", ""], ["2557", "SDOE FIND FIRST ENCOUNTER", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns the internal entry number
of an Outpatient Encounter file (#409.68) entry for the first encounter
for a patient in a specified date range.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE FIND FIRST ENCOUNTER", "", ""], ["2558", "SDOE FIND FIRST STANDALONE", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns the internal entry number
of an Outpatient Encounter file (#409.68) entry for the first
standalone add/edit encounter for a patient in a specified date range.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE FIND FIRST STANDALONE", "", ""], ["2559", "SDOE FIND LAST STANDALONE", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns the internal entry number
of an Outpatient Encounter file (#409.68) entry for the last
standalone add/edit encounter for a patient in a specified date range.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE FIND LAST STANDALONE", "", ""], ["2560", "SDOE FIND PROCEDURE", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a boolean indicator on
whether a specific procedure has been associated with an encounter.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE FIND PROCEDURE", "", ""], ["2561", "SDOE FIND PROVIDER", "Remote Procedure", "SCHEDULING", "1998/09/22", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a boolean indicator on
whether a specific provider has been associated with an encounter.\n
---------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm\n", "SDOE FIND PROVIDER", "", ""], ["2562", "DBIA2562", "File", "REGISTRATION", "1998/09/22", "", "Pending", "Private", "2", "
Direct of PATIENT file(#2) Direct global read of "LR"
node. The code uses LABORATORY REFERENCE(#63)", "", "", ""], ["2563", "Linked option to CIRN", "Other", "CLINICAL INFO RESOURCE NETWORK", "1998/09/23", "APPROVED", "Active", "Private", "", "
Registration patch DG*5.3*172 is transporting in a KIDS
build the CIRN option, CIRN Pre-Implementation Menu (RGPR PRE-IMP MENU), as a
link for menu items.", "", "", ""], ["2564", "SDOE GET DIAGNOSES", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns an array of diagnoses for
an encounter.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE GET DIAGNOSES", "", ""], ["2565", "SDOE GET GENERAL DATA", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns the zeroth and other nodes
of an outpatient encounter.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE GET GENERAL DATA", "", ""], ["2566", "SDOE GET PRIMARY DIAGNOSIS", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns the internal entry number
of the primary diagnosis code (^ICD9) for an encounter.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
These files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE GET PRIMARY DIAGNOSIS", "", "2012/04/10"], ["2567", "SDOE GET PROCEDURES", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a subscripted array of
procedures for an encounter.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE GET PROCEDURES", "", ""], ["2568", "SDOE GET PROVIDERS", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a subscripted array of
providers for an encounter.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE GET PROVIDERS", "", ""], ["2569", "SDOE GET ZERO NODE", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns the zeroth node of an
outpatient encounter.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE GET ZERO NODE", "", ""], ["2570", "SDOE LIST ENCOUNTERS FOR DATES", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a list of outpatient encounters
for a date range.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE LIST ENCOUNTERS FOR DATES", "", ""], ["2571", "SDOE LIST ENCOUNTERS FOR PAT", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a list of outpatient
encounters for a specified patient and specified date range.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE LIST ENCOUNTERS FOR PAT", "", ""], ["2572", "SDOE LIST ENCOUNTERS FOR VISIT", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) returns a list of outpatient
encounters for a specified PCE visit.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE LIST ENCOUNTERS FOR VISIT", "", ""], ["2573", "SDOE PARSE GENERAL DATA", "Remote Procedure", "SCHEDULING", "1998/09/23", "APPROVED", "Active", "Supported", "", "\n
This remote procedure call (RPC) will parse the data returned by
SDOE GET GENERAL DATA remote procedure call into individual field
nodes.\n
------------------------------------------------------------------
This RPC is part of the ACRP Interface Toolkit (AIT).\n
The AIT is a set of programmer tools that provides access
to outpatient encounter data.\n
Note: For detail information on this RPC call, see the following
AIT documentation files:
sd_53_p131_tooldoc.doc or
sd_53_p131_tooldoc.pdf.
Theses files are distributed as part of patch SD*5.3*131.\n
Also, the documentation is available on-line at the following URL:
http://127.0.0.1/softserv/mip/wr/acrpapi.htm", "SDOE PARSE GENERAL DATA", "", ""], ["2574", "ADDITIONAL APIS FOR NDF", "Routine", "NATIONAL DRUG FILE", "1998/09/23", "APPROVED", "Active", "Supported", "", "
This DBIA describes additional Application Programmer
Interfaces (APIs) for the National Drug File. APIs described here are in
addition to those described in DBIA # 2531.", "", "PSNAPIS", "2025/04/15"], ["2575", "NATURE OF ORDER FILE ACCESS", "File", "ORDER ENTRY/RESULTS REPORTING", "1998/09/23", "APPROVED", "Active", "Controlled Subscription", "100.02", "
Reference to Nature of Order (100.02) file. This DBIA
allows a direct global read of the NAME (.01) and CODE (.02) fields of the
NATURE OF ORDER (100.02) file.", "", "", "2011/01/05"], ["2576", "DBIA2576", "File", "ORDER ENTRY/RESULTS REPORTING", "1998/09/23", "APPROVED", "Active", "Controlled Subscription", "100.03", "
Reference to Order Reason (100.03) file. This DBIA
allows a direct global read of the NAME (.01) field of the ORDER REASON
(100.03) file. Access is also allowed to the "C" cross reference on the file
to look for coded entries.", "", "", ""], ["2579", "SDAM", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The [HBHC APPOINTMENT] OPTION CALLS ROUTINE SDAM, USING
ENTRY POINT EN. This is IA is needed due to cloning the [SDAM APPT MGT]
option.", "", "SDAM", ""], ["2580", "SDAMEVT", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
THE [HBHC APPOINTMENT] OPTION CALLS ROUTINE SDAMEVT IN
ITS EXIT ACTION USING ENTRY POINT HDKILL.\n
This is IA is needed due to cloning the [SDAM APPT MGT] option.", "", "SDAMEVT", ""], ["2581", "SERVER ACTION edit during install", "File", "KERNEL", "1998/09/24", "APPROVED", "Active", "Controlled Subscription", "19", "
This integration agreement is for setting the SERVER
ACTION field (#221) of the OPTION file (#19) while a patch to the server logic
is being installed. The SERVER ACTION field will be reset in a post-init to
its original value.", "", "", ""], ["2582", "DBIA2582", "File", "LAB SERVICE", "1998/09/28", "", "Pending", "Private", "63", "
The Electron Microscopy (LAB) performs real time data
extraction using routine ^RGHOPATH for CIRN. The routine performs the
following databases function:\n
Direct global read of the LAB DATA file (#63) and PARENT FILE field (#.02).
Direct global read on the LAB DATA file (#63), NAME field (#.03). Direct
global read of the zero node of the SP, CY, and EM subscripts in the LAB DATA
file (#63). Direct global read using a $O through the EM subscript nodes .1
through .2 "EM" subscript includes: .1 node 63.202 Specimen subfile, .2 node
63.213 Brief Cliical History Subfile, .3 node 63.214 Preoperative Diagnosis
subfile .4 node 63.205 Operative Findings subfile, .5 node 63.206
Postoperative Diagnosis subfile, 1 node 63.201 Gross Description subfile, 1.1
node 63.211 Microsopic Examination subfile, 1.2 node 63.207 Supplementary
Report, 1.4 node 63.204 EM Diagnosis subfile, 2 node 63.212 EM Organ/Tissue
subfile", "", "", ""], ["2586", "OE/RR Read Access to GMR(123,", "File", "CONSULT/REQUEST TRACKING", "1998/09/25", "APPROVED", "Active", "Controlled Subscription", "123", "
This DBIA serves as documentation of Read Access made
from the OE/RR package to the REQUEST/CONSULTATION file (#123).\n
Please note that the OE/RR v3 orders conversion also deletes entries in
GMR(123,.", "", "", "2019/04/25"], ["2587", "OE/RR references to RAO(75.1,", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/09/25", "", "Retired", "Private", "75.1", "
The references in this DBIA are made from the OE/RR v3
orders conversion.only!\n
Please note in addition to the fields referenced, the following code is also
executed:\n
I '$D(^RADPT("AO",+ORPK)) S DA=+ORPK,DIK="^RAO(75.1," D ^DIK\n
So, if no entries in the RAD/NUC MED PATIENT FILE file, point to the processed
entry in the RAD/NUC MED ORDERS file, the entry is deleted.", "", "", ""], ["2588", "OR use of RADPT('AO' x-ref", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/09/25", "APPROVED", "Active", "Controlled Subscription", "70", "
This reference is used by the OE/RR v3 orders
conversion and the Care Management application, to link a case number to an
order.", "", "", ""], ["2589", "NEW PERSON editing", "File", "KERNEL", "2001/08/31", "APPROVED", "Active", "Private", "200", "\n
With patch RG*1*21, Master Patient Index/Patient Demographics exports
a new option, Add/Edit Point of Contact [RG UPDATE POINT OF CONTACT].
This option allows a facility to update the administrative, IRM and
HL7 points of contact name and phone number. This information is sent
to the MPI/PD Data Management staff so that they can update the website.\n
The point of contact names reside in the CIRN SITE PARAMETER (#991.8)
file and point to the NEW PERSON (#200) file. The option edits the
OFFICE PHONE (#.132) field in the NEW PERSON (#200) file, via a FileMan
^DIE call for the identified point of contact.", "", "", ""], ["2590", "SD OUTPATIENT GAF SCORE UTILS", "Routine", "SCHEDULING", "1998/09/30", "APPROVED", "Active", "Supported", "", "
The purpose of these API's is to facilitate the entry
of Global Assessment of Function (GAF) scores to the Mental Health package
from outpatient encounters. VHA Directive, 97-059, dated November 25, 1997,
"Instituting Global Assessment of Function (GAF) Scores in Axis V Mental
Health Patients", provides guidelines for the collection of these GAF scores.
These API's will be used to (1) return whether a new GAF score is required for
an outpatient and (2) whether the outpatient encounter clinic is a Mental
Health clinic for which GAF scores must be collected. These API's have been
added to the routine: SDUTL2.", "", "SDUTL2", ""], ["2591", "SD OUTPATIENT ENCOUNTER GAF SCORE CAPTURE", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
Patient Care Encounter needs to capture GAF scores for
outpatient encounters. This call will allow entry of the GAF score, Date/Time
of the GAF score, and provider determining the GAF score through the
Scheduling call used in appointment management. The internal entry number of
the patient, DFN, is passed into the call as variable DFN. There is no return
from the call. This call will ask for the score, date/time, and provider for
posting the GAF score.", "", "SDGAF", ""], ["2592", "TRAVERSE DD FOR FILE CONVERSION", "File", "1", "1998/09/30", "APPROVED", "Active", "Private", "", "
The post-install routine in the Registration patch
DG*5.3*172 is looping through the "PT" node in both the MARITAL STATUS file
(#11) and RELIGION file (#13) to convert the non-standard entries into
standard entries. The non-standard entries are deleted after the conversion.
However, the conversion cannot convert entries within a subfile, so the patch
identifies the subfile within the "PT" node and traverses back through the
"UP" nodes looking at the subfile zero nodes to report the subfile NAMES that
could not be converted. This information is placed in a mail message which is
reported back to the installer of patch DG*5.3*172.", "", "", ""], ["2593", "DBIA2593", "Routine", "LAB SERVICE", "1999/04/23", "", "Withdrawn", "Private", "", "
The CIRN data extaction routine for Microbiology (LAB)
^LRRGHOMI makes several references to the LAB DATA file (#63) in order to
generate the HL7 message for Microbiology results. This routine is called
from ^RGHOMI.", "", "LRRGHOMI", ""], ["2594", "DBIA2594", "File", "LAB SERVICE", "1998/10/16", "", "Pending", "Private", "60", "
For all CIRN Laboratory related packages, including:
MICROBIOLOGY and SURGICAL PATHOLOGY, the historical load routine (^RGHOLABB -
Historical load of lab results (all modules)), makes a reference to the
LABORATORY TEST file (#60), for the purpose of setting an entry in the CIRN
processing queue.", "", "", ""], ["2595", "DBIA2595", "File", "LAB SERVICE", "2005/05/25", "", "Retired", "Private", "61", "
For all CIRN Laboratory related packages, including:
MICROBIOLOGY and SURGICAL PATHOLOGY, the historical load routine (^RGHOLABB -
Historical load of lab results (all modules)), makes a reference to the
TOPOGRAPHY FIELD file (#61), for the purpose of setting an entry in the CIRN
processing queue.", "", "", ""], ["2596", "Audit File Reference to Protocol File", "File", "KERNEL", "1998/10/27", "APPROVED", "Active", "Controlled Subscription", "101", "\n
CIRN made a request to the FileMan Development Team to add to the Audit File
a field that would keep track of what menu Protocol was used to change the
data being audited.", "", "", ""], ["2597", "DBIA2597", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/14", "APPROVED", "Active", "Private", "9000010.12", "
The CIRN Skin Tests (PCE) data extraction routine
(^RGHOSKN - HL7 Message Generation for Skin Tests Results), makes several
references to fields in the SKIN TEST V file (#9000010.12), for the purpose of
creating the HL7 transmission records.", "", "", ""], ["2598", "DBIA2598", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/14", "APPROVED", "Active", "Private", "9000010", "
For all CIRN PCE related packages, including: SKIN
TESTS, IMMUNIZATIONS, HEALTH FACTORS, TREATMENTS, and MEASUREMENTS, the
historical load routine (RGHOVFB - Historical Load of V File Data), makes a
reference to the VISIT file (#9000010), for the purpose of setting an entry in
the CIRN processing queue.", "", "", ""], ["2599", "DBIA2599", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/14", "APPROVED", "Active", "Private", "9000010.23", "", "", "", ""], ["2600", "DBIA2600", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/15", "APPROVED", "Active", "Controlled Subscription", "9000010.11", "
The CIRN Immunizations (PCE) data extraction routine
(^RGHOIMM - HL7 Message Generation for Immunization Results), makes several
references to fields in the IMMUNIZATION V file (#9000010.11), for the purpose
of creating the HL7 transmission records.", "", "", ""], ["2601", "DBIA2601", "Routine", "LAB SERVICE", "1998/10/16", "", "Withdrawn", "Private", "", "
The CIRN data extraction routine ^LRRGPATH creates the
HL7 messages for Surgical Pathology, Electron Microscopy and Cytology (eg LAB
transfers). It makes several references to the LAB DATA file (#63) in order to
create the messages.", "", "LRRGPATH", ""], ["2602", "READING AUDIT FILE", "File", "1", "1998/10/02", "APPROVED", "Active", "Controlled Subscription", "1.1", "
The NDF Management System uses entries in the AUDIT
file (#1.1) to track changes made to files involved with NDF and to send these
changes to VAMCs using KIDS. To this end, the NDF Management System requests
permission to do direct global reads of entries in File #1.1\n\n", "", "", "2016/02/05"], ["2604", "DBIA2604", "File", "INCOME VERIFICATION MATCH", "1998/10/09", "APPROVED", "Active", "Private", "301.6", "
When the AMIE package deletes entries from the PATIENT
file (#2) it also needs to delete entries from the IVM PATIENT file (#301.5).\n
A cleanup is done to delete current entries in the IVM PATIENT file which
point to non-existing or non-veterans in the PATIENT file. Corresponding
entries in the IVM TRANSMISSION LOG file (#301.6) are also deleted. These
entries are deleted using a DIK call. ^IVM(301.6,"B" is used to determine
which IVM TRANSMISSION LOG file entries, if any, should be deleted.", "", "", ""], ["2605", "DBIA2605", "File", "KERNEL", "1998/10/13", "APPROVED", "Active", "Controlled Subscription", "9.4", "
^DIC(9.4,"C", cross reference - The software
facilitating this DBIA, orders through the "C" cross reference which is a
cross reference of the PREFIX field (#1) of the PACKAGE file (#9.4). If the
PREFIX is "YS", the code then checks the SHORT DESCRIPTION field (#2) of the
PACKAGE file (#9.4). If this field does NOT equal "Version 5.01 of Mental
Health", the code either (1) deletes the entry from the package file or (2)
renames the PREFIX from YS to YS_integer (beginning with 1, incremented by 1,
i.e. YS1, YS2, YS3, etc.) depending on the number of Mental Health entries
that are not version 5.01. User response to the 'Delete old PACKAGE file
entries?' question determines which action will be performed by the code.", "", "", ""], ["2606", "DBIA2606", "File", "IFCAP", "1998/10/14", "APPROVED", "Active", "Private", "440", "", "", "", ""], ["2607", "Browser API", "Routine", "1", "1998/10/14", "APPROVED", "Active", "Supported", "", "
The Browser displays ASCII text on a terminal which
supports a scroll region.", "", "DDBR", ""], ["2608", "Browser API", "Routine", "1", "1998/10/14", "APPROVED", "Active", "Supported", "", "
This function call returns a 1 or 0 (true or false) to
determine if the CRT being used can support a scroll region and reverse index.\n", "", "DDBRT", ""], ["2609", "Browser API", "Routine", "1", "1998/10/14", "APPROVED", "Active", "Supported", "", "
Browser device handler functions.", "", "DDBRZIS", ""], ["2610", "ScreenMan API: Form Utilities", "Routine", "1", "1998/10/14", "APPROVED", "Active", "Supported", "", "
$$GET() - This extrinsic function retrieves data from a
form-only field or a computed field. PUT() - This procedure stuffs data into
a form-only field.", "", "DDSVALF", ""], ["2611", "TIME ZONE DIFFERENTIAL", "File", "MAILMAN", "1998/11/20", "APPROVED", "Active", "Private", "4.4", "
CIRN would like an agreement to do a direct global read
of the DIFFERENTIAL (#2) field in the MAILMAN TIME ZONE file (#4.4). This is
used in conjunction with the CIRN REPOSITORY SITE PARAMETER file (#990.8)
fields, (#10) STANDARD TIMEZONE and (#11) DST TIMEZONE, to automatically
identify the current time and time differential for HL7 messaging.", "", "", ""], ["2612", "DBIA2612", "File", "PHARMACY DATA MANAGEMENT", "1998/10/18", "APPROVED", "Active", "Private", "50.3", "
As of 9/1/20 the ICR Team were requested to change the
custodial package to Pharmacy Data Management, instead of Inpatient
Medications. This resulted from the alignment of file ranges under specific
packages for the conversions from Rational to GitHub.\n
Actual Description from prior to 9/1/20: National Drug File (NDF) request
permission to look at the PRIMARY DRUG file (#50.3). Direct Global Read.\n
Field Name Node & Piece .01 NAME 0;1", "", "", "2020/09/01"], ["2613", "DBIA2613", "File", "PHARMACY DATA MANAGEMENT", "1998/10/18", "APPROVED", "Active", "Private", "59.7", "
National Drug File (NDF) requests to look at the
PHARMACY SYSTEM file (59.7). Direct Global R/W.", "", "", "2010/10/04"], ["2614", "DBIA2614", "Other", "PHARMACY DATA MANAGEMENT", "1998/10/18", "APPROVED", "Active", "Private", "", "
National Drug File (NDF) requests permission to export
templates to DRUG file (#50).\n
Print Templates
---------------
PSNFRMPRT PSNHEAD PSNLDG1 PSNRPT2 PSNRPT4\n
Sort Templates
--------------
PSNFRMSRT", "", "", ""], ["2615", "TERM OF VALM0", "Routine", "LIST MANAGER", "1998/10/19", "APPROVED", "Active", "Private", "", "\n
Inpatient Medications requests an integration agreement with List Manager to
call TERM^VALM0. This call is to set the variables that determine terminal
characteristics.", "", "VALM0", ""], ["2616", "DBIA2616", "Routine", "OUTPATIENT PHARMACY", "1998/10/19", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the Controlled Substances package
to call the Outpatient Pharmacy package to request that the last refill of a
prescription be deleted. This will be for Outpatient Version 7.0 and greater.
The Outpatient Pharmacy version check will be done by the Controlled
Substances package.", "", "PSOCAN", ""], ["2617", "DBIA2617", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/19", "APPROVED", "Active", "Private", "9000010", "
The CIRN Visit Tracking data extraction routine
(^RGHOPV1 - HL7 Message Generation for In-patient/Out-patient Visit Data) and
the historical load routine (^RGHOPV1B - Historical Backload of Visits), make
several references to nodes/fields in the VISIT file (#9000010), for the
purpose of creating the HL7 transmission records.", "", "", ""], ["2619", "DBIA2619", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/21", "APPROVED", "Active", "Private", "9000010.15", "
The CIRN Treatments (PCE) data extraction routine
(^RGHOVTX - HL7 Transmission of Non CPT Coded Procedures), makes several
references to nodes/fields in the V TREATMENT file (#9000010.15), for the
purpose of creating the HL7 transmission records.", "", "", ""], ["2620", "DBIA2620", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/21", "APPROVED", "Active", "Private", "9999999.17", "
The CIRN Treatments (PCE) data extraction routine
(^RGHOVTX - HL7 Transmission of Non CPT Coded Procedures), makes a reference
to a node in the TREATMENT file (#9999999.17), for the purpose of creating the
HL7 transmission records.", "", "", ""], ["2621", "DBIA2621", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Controlled Subscription", "59", "
This agreement will be retired on 12/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSO*7*213. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2622", "DBIA2622", "Routine", "KERNEL", "1998/10/20", "APPROVED", "Active", "Supported", "", "
Use of the XLFUTL APIs.", "", "XLFUTL", ""], ["2623", "DBIA2623", "File", "PCE PATIENT CARE ENCOUNTER", "1998/10/21", "APPROVED", "Active", "Private", "9999999.27", "
The CIRN Treatments (PCE) data extraction routine
(^RGHOVTX - HL7 Transmission of Non CPT Coded Procedures), makes a reference
to a node in the PROVIDER NARRATIVE file (#9999999.27), for the purpose of
creating the HL7 transmission records.", "", "", ""], ["2624", "DBIA2624", "Routine", "REGISTRATION", "1998/10/23", "APPROVED", "Active", "Private", "", "
CIRN would like a DBIA with Registration to use the
SEND^VAFHUTL function to identify the status of the PIMS ADT messaging or SEND
PIMS HL7 V2.3 MESSAGES field (391.7013) within the MAS PARAMETERS file (#43).", "", "VAFHUTL", ""], ["2625", "PACKAGE POINTER UPDATES", "File", "KERNEL", "1998/10/22", "", "Withdrawn", "Private", "19", "\n\n
In order to complete all corrections to the Package File #9.4
referenced in DBIA #2489, we would like to have permission to check
and update any Library Package Options stored in the Option File #19.
To locate the Library v.2.5 patches, we would like to use FIND^DIC and
extract the entries' corresponding data in their PACKAGE(12) field.
If the entry is not pointing to the correct Library Package File
entry, we would like to update this field with the correct pointer
using FILE^DIE. Error checking for each check and update will be
performed.\n", "", "", ""], ["2626", "PACKAGE FILE LINK UPDATES", "File", "KERNEL", "1998/10/22", "", "Withdrawn", "Private", "9.6", "\n\n
In order to complete all corrections to the Package File #9.4
referenced in DBIA #2489, we would like to have permission to check
and update any Library Package KIDS builds stored in the Build File
#9.6. To locate the Library v.2.5 patches, we would like to use
FIND^DIC and extract the entries' corresponding data in their PACKAGE
FILE LINK(1) field. If the entry is not pointing to the correct
Library Package File entry, we would like to update this field with
the correct pointer using FILE^DIE. Error checking for each check and
update will be performed.\n", "", "", ""], ["2627", "DBIA2627", "File", "PCE PATIENT CARE ENCOUNTER", "1998/11/24", "APPROVED", "Active", "Private", "9000010.18", "
The CIRN Procedures (PCE) data extraction routine
(^RGHOCPT - HL7 Transmission of CPT Coded Procedures), makes several
references to the nodes/fields in the V CPT file (#9000010.18), for the
purpose of creating the HL7 transmission records.", "", "", ""], ["2628", "DBIA2628", "File", "ADVERSE REACTION TRACKING", "1998/11/06", "APPROVED", "Active", "Private", "120.8", "
CIRN Allergy/Adverse reaction data extraction routine
^RGHOALR/^RGHOALRB make numerous direct global reads of the PATIENT ALLERGY
FILE(#120.8). The routines use this information to generate HL7 message for
transmission of results and to do historical backloading of data.\n", "", "", ""], ["2629", "EXPANSION FIELD FOR CIRN", "File", "PHARMACY DATA MANAGEMENT", "1998/11/09", "APPROVED", "Active", "Private", "51", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
TO GENERATE HL7 PRESCRIPTION MESSAGING.", "", "", ""], ["2630", "DBIA2630", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/10/28", "", "Under Revision", "Private", "70", "
PCE Clinical Reminders needs to build a list of
radiology procedures received by a patient. In order to do this we would like
to use $O on the following cross-references.", "", "", ""], ["2631", "DBIA2631", "File", "1", "1998/10/27", "APPROVED", "Active", "Controlled Subscription", "", "
Knowledge of file and subfile hierarchies is sometimes
required. The required information can be obtained from ^DD(D0,0,"UP").", "", "", ""], ["2632", "DBIA2632", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/10/27", "APPROVED", "Active", "Private", "70", "
The CIRN Radiology/Nuclear Medicine data extraction
routine (^RGHORAD - HL7 Message Generation for Radiology/Nuclear Results) and
the historical load routine (^RGHORADB - Historical Load of Radiology/Nuclear
Medicine Reports), make several references to radiology/nuclear related fields
in the RAD/NUC MED PATIENT file (#70), for the purpose of creating the HL7
transmission records.", "", "", ""], ["2633", "DBIA2633", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/10/27", "APPROVED", "Active", "Private", "71", "
The CIRN Radiology/Nuclear Medicine data extraction
routine (^RGHORAD - HL7 Message Generation for Radiology/Nuclear Results) and
the historical load routine (^RGHORADB - Historical Load of Radiology/Nuclear
Medicine Reports), make several references to radiology/nuclear related fields
in the RAD/NUC MED PROCEDURES file (#71), for the purpose of creating the HL7
transmission records.", "", "", ""], ["2634", "DBIA2634", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/10/27", "", "Retired", "Private", "74", "
The CIRN Radiology/Nuclear Medicine data extraction
routine (^RGHORAD - HL7 Message Generation for Radiology/Nuclear Results) and
the historical load routine (^RGHORADB - Historical Load of Radiology/Nuclear
Medicine Reports), makes several references to radiology/nuclear related
nodes/fields in the RAD/NUC MED REPORTS file (#74), for the purpose of
creating the HL7 transmission records.", "", "", ""], ["2635", "DBIA2635", "File", "LAB SERVICE", "1998/10/27", "APPROVED", "Active", "Private", "60", "
Dietetics package displays Lab Test results by using
Laboratory Test file #60.", "", "", ""], ["2636", "DBIA2636", "File", "LAB SERVICE", "1998/10/27", "APPROVED", "Active", "Private", "63", "
Dietetics package displays the Lab Test results by
using the Lab Data file #63.", "", "", ""], ["2637", "CIRN DATE/TIME CONVERSION/FORMAT", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1998/10/29", "", "Retired", "Controlled Subscription", "", "
This DBIA concerns a call to a CIRN utility routine to
convert and format date/times.", "", "RGUTDT", ""], ["2638", "ORDER STATUS file direct access", "File", "ORDER ENTRY/RESULTS REPORTING", "1998/10/29", "APPROVED", "Active", "Controlled Subscription", "100.01", "
The Consults package and CPRS are very tightly linked.
The Consults package has direct access to the Order Status File, 100.01.
Consult routines use the Order status to display the status and create lists
of consults for use by the Consults package List Manager, CPRS List Manager
Consults tab and the CPRS GUI Consults tab. The Consult package also uses the
direct access of the order status to create the Notification text for consult
alerts.\n
The Consults package may have read only direct access to the ^ORD(100.01,
global for the following information:\n
^ORD(100.01,D0,0)= (#.01) NAME [1F] ^ (#.02) SHORT NAME [2F] ^
^ORD(100.01,D0,.1)= (#.1) ABBREVIATION [E1,245F] ^ ^ORD(100.01,"B",STATUS,D0)\n", "", "", "2020/03/24"], ["2639", "CIRN CLASS NAME INTERNAL TO EXTERNAL", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1998/10/29", "", "Retired", "Controlled Subscription", "", "
This DBIA concerns a call to a CIRN utility routine to
return the name associated with a specified class.", "", "RGOBJ", ""], ["2640", "CIRN HEALTH SUMMARY DATA EXTRACT", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1998/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA concerns a call to the CIRN Health Summary
extract routine.", "", "RGDDHS00", ""], ["2641", "KIDS VARIABLES", "Other", "KERNEL", "1998/11/09", "APPROVED", "Active", "Supported", "", "
Variable(s) available pre, during, and post KIDS
installation.\n
Variable: XPDPKG = Package file entry ien for build that is currently
being processed.", "", "", ""], ["2642", "Set Rad/Nuc Med data dictionary 'ID','WRITE' node.", "File", "1", "1998/11/12", "APPROVED", "Active", "Private", "0", "
Radiology/Nuclear Medicine intends to modify the
following data dictionary attribute:\n
before: ^DD(71,0,"ID","WRITE") = W ?54,$$PRCCPT^RADD1()\n
after: ^DD(71,0,"ID","WRITE") = D EN^DDIOL($$PRCCPT^RADD1(),"","?54")\n
The intention of this correction is to eliminate the WRITE command from the
data dictionary. To execute this action, I must hard set the data dictionary
node in a post-init. At present, FileMan does not have a generic tool to
export specific file wide data dictionary attributes. I do not wish to carry
over the entire data dictionary for the Rad/Nuc Med Procedures file.", "", "", ""], ["2643", "DBIA2643", "File", "REGISTRATION", "1998/11/03", "APPROVED", "Active", "Private", "2", "
Since March 1994, the Integrated Billing package has
retained full authority for the INSURANCE TYPE (#2.312) sub-file and the field
COVERED BY HEALTH INSURANCE? (#.3192), both located in the PATIENT (#2) file.
In addition the INS node references the INSURANCE - NON-POLICY INFO for each
patient. Fields related to non-policy related insurance will be stored on this
node. This authority includes development of the data dictionary (DD) for
these fields, as well as responsibility for data entry into and data retrieval
from these fields.\n
This agreement is a "delegation of custody" of these fields from Registration
to Integrated Billing. It provides Integrated Billing all rights and
privileges to development and distribution for all DD elements and data in
these fields. In addition, all DBIAs required for access to the DD and data
for these fields will be between any subscriber and Integrated Billing as the
custodian.", "", "IBCNSU1", "2018/06/07"], ["2644", "DBIA2644", "Routine", "PROBLEM LIST", "1999/04/16", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMPLUTL3", ""], ["2645", "Classic FileMan API: Sort Template Compliation", "Routine", "1", "1998/11/17", "", "Withdrawn", "Supported", "", "
This entry point marks a sort template compiled or
uncompiled.", "", "DIOZ", ""], ["2646", "CIRN HEALTH SUMMARY DATA EXTRACTS", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1998/11/18", "", "Retired", "Controlled Subscription", "", "
This DBIA concerns a calls to two CIRN Health Summary
extract entry points.", "", "RGDDHS03", ""], ["2647", "ADD CIRN COMPONENTS", "Routine", "HEALTH SUMMARY", "1998/11/18", "APPROVED", "Active", "Private", "", "
CIRN requests permission to add three (3) new
components to the Health Summary Component file (#142.1) which will display
CIRN information while respecting time and occurrence limits. These
components will be exported in a disabled state by a Health Summary patch.
The IEN range set aside for CIRN use in the Health Summary Component file
(#142.1) will be 400-499. The sub-namespace used by the CIRN HS components
will be GMTSRG*. A CIRN post-install routine will add the components to the
Ad Hoc Health Summary type by calling the ENPOST^GMTSLOAD entry point. The
variable INCLUDE will be set to zero (0) or one (1) by user input before the
call to this entry point.", "", "GMTSLOAD", ""], ["2648", "Import Tool API", "Routine", "1", "1998/11/19", "APPROVED", "Active", "Supported", "", "
This procedure imports data from ASCII host files into
VA FileMan file entries.\n
Format FILE^DDMP([FILE],[[.]FIELDS],[.CONTROL],.SOURCE,[.]FORMAT)", "", "DDMP", ""], ["2649", "Classic FileMan API: Max. Routine Size", "Routine", "1", "1998/11/19", "APPROVED", "Active", "Supported", "", "
This argumentless function returns the maximum routine
size that should be used when compiling cross references, print templates, or
input templates.", "", "DILF", ""], ["2650", "DBIA2650", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/11/23", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management calls ADD^ORCMEDT1 to add a
single quick order located in the ORDER DIALOG FILE (#101.41) to a menu for
use in CPRS 1.0.\n
On installation, CPRS loops through all the Add Orders menus in the Protocol
file that are assigned to users as a default; all items on those menus are
converted to a new entry in a new format in the Order Dialog file for use with
CPRS. Utilities exist in both Pharmacy and CPRS to convert additional
protocols that did not get processed [successfully] during installation; the
entry point ADD^ORCMEDT1 being called here from the Pharmacy utility will
simply loop through the Protocol file and find all menus that the protocol
PITEM was attached to and add the corresponding converted dialog DITEM to the
same menus in the Order Dialog file. This will help minimize the impact on the
sites.", "", "ORCMEDT1", ""], ["2651", "DBIA2651", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/11/23", "APPROVED", "Active", "Private", "", "
Routine ORCONV2 is called by Pharmacy Data Management
to pass quick order data from the PHARMACY QUICK ORDER FILE (#57.1) to OERR.
In preparation for CPRS 1.0, these pharmacy quick orders are converted to
entries in the ORDER DIALOG FILE (#101.41). Entry points UD^ORCONV2 and
IV^ORCONV2 accomplish this task.", "", "ORCONV2", ""], ["2652", "DBIA2652", "File", "REGISTRATION", "1998/11/25", "APPROVED", "Active", "Controlled Subscription", "42.4", "
The Surgery package needs to store the specialty
associated with certain surgical admissions and requests permission to point
to and read by FileMan the NAME field (#.01) of SPECIALTY file (#42.4).", "", "", ""], ["2653", "Rad/Nuc Med - CPRS Orderable Item cleanup", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/11/30", "APPROVED", "Active", "Private", "", "
The purpose of this database integration agreement
(DBIA) is to correct a discrepancy between the Rad/Nuc Med Common Procedure
(#71.3) and the Orderable Items (#101.43) file. Rad/Nuc Med will use routine
ORYRA to inactivate records in the Orderable Items file, then initiate a whole
file update of the Rad /Nuc Med Procedure file. This final action will ensure
that the two files are in synch.", "", "ORYRA", ""], ["2654", "CIRN access to PSDRUG file", "File", "PHARMACY DATA MANAGEMENT", "1998/11/30", "APPROVED", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's.\n
CIRN needs a read access to the PSDRUG (file #50) to generate HL7 prescription
messaging", "", "", ""], ["2655", "DBIA2655", "File", "REGISTRATION", "1998/12/02", "APPROVED", "Active", "Private", "2", "
Direct Global access to ^DPT(DFN) For the purpose of
locking a patient file while updating demographic information. The following
code is used:\n
L +^DPT(DFN):2", "", "", ""], ["2656", "DBIA2656", "File", "KERNEL", "1998/12/03", "APPROVED", "Active", "Private", "9.4", "
I would like to kill the "AMRG" cross reference (x-ref)
for the 'Toolkit' entry in the Package File. The entry that created this
x-ref was manually killed by XT*7.3*33 Post-Init routine, but the x-ref was
inadvertently left. This would be a once time occurance to clean-up the
'Toolkit' entry in the Package File. The "AMRG" cross reference is a whole
file x-ref made on the "File Affected" (Field .01) for the "Affects Record
Merge Sub-File" (Field 20) in the Package File (#9.4).\n\n\n", "", "", ""], ["2657", "CLOZAPINE USE OF LABS", "File", "LAB SERVICE", "1992/09/15", "APPROVED", "Active", "Private", "63", "", "", "", ""], ["2658", "REMOVAL OF ID NODE", "Other", "1", "1998/12/10", "APPROVED", "Active", "Private", "", "
Deletion of "ID" node for identifier which is no longer
required.", "", "", ""], ["2659", "DISPOSITION HOSPITAL LOCATIONS", "File", "PCE PATIENT CARE ENCOUNTER", "1998/12/10", "APPROVED", "Active", "Controlled Subscription", "815", "
Patch SD*5.3*137 allows the site to convert old
Scheduling encounter information to the PCE/Visit Tracking database as
'historical' visits.\n
Registration disposition information is part of this conversion effort.
However, in order to create VISIT file entries for dispositions, the
disposition must be associated with a valid clinic entry in the HOSPITAL
LOCATION file. Furthermore, for old dispositions which are being conversion,
this association does not exist.\n
In order to link a disposition to valid disposition clinic, Scheduling needs
to match the medical center division of the disposition with tne medical
center division of a valid disposition clinc. The valid disposition clinics
are stored in the PCE PARAMETERS file in the DISPOSITION HOSPITAL LOCATIONS
multiple.\n
Patch SD*5.3*137 needs 'read' access to this multiple in order to accomplish
this mapping.", "", "", ""], ["2660", "SCHEDULING CONVERSION FIELDS", "File", "REGISTRATION", "1998/12/10", "APPROVED", "Active", "Private", "2", "
These two control fields are used to track whether the
appointment or disposition have been converted as part of patch SD*5.3*137.\n
This DBIA will allow Scheduling to distribute these fields in patch
DG*5.3*207. DG*5.3*207 will be distributed to the sites with SD*5.3*137 in a
KIDS host file.\n
Also, this DBIA will allow the Scheduling conversion software to update these
files via VA FileMan calls.", "", "", ""], ["2661", "DIR Special variable", "Other", "1", "1998/12/11", "APPROVED", "Active", "Controlled Subscription", "", "
The Alert processor makes use of a special input
parameter to Fileman DIR. This is done in XQALERT1, it makes a call with
DIR(0)="LV^..." to get user input validated.", "", "", ""], ["2662", "DBIA2662", "Other", "NETWORK HEALTH EXCHANGE", "1998/12/11", "APPROVED", "Active", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2663", "DBIA2663", "Other", "REGISTRATION", "1998/12/17", "APPROVED", "Active", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2664", "OBSERVATION API", "Routine", "REGISTRATION", "1998/12/24", "APPROVED", "Active", "Supported", "", "
Routine DGPMOBS provides three entry points (MVT, PT,
and SPEC) to determine if a patient's treating specialty for a specified
movement or date/time is or was an observation specialty.", "", "DGPMOBS", ""], ["2665", "DBIA2665", "Other", "FEE BASIS", "1998/12/17", "APPROVED", "Active", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2666", "DBIA2666", "Other", "HEALTH SUMMARY", "1998/12/17", "APPROVED", "Active", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2667", "DBIA2667", "Other", "LAB SERVICE", "1998/12/17", "APPROVED", "Active", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2668", "DBIA2668", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "1998/12/17", "", "Pending", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2669", "DBIA2669", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2670", "DBIA2670", "Other", "SURGERY", "1998/12/17", "APPROVED", "Active", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2671", "DBIA2671", "Other", "TEXT INTEGRATION UTILITIES", "1998/12/17", "APPROVED", "Active", "Private", "", "
AMIE II is an "umbrella" menu for VA Regional Office
users on VistA systems. The IA is for the options included on the menu.", "", "", ""], ["2672", "DBIA2672", "File", "ADVERSE REACTION TRACKING", "1998/12/15", "APPROVED", "Active", "Private", "120.82", "", "", "", ""], ["2673", "DBIA2673", "File", "PCE PATIENT CARE ENCOUNTER", "1998/12/16", "APPROVED", "Active", "Private", "9000010.06", "
CIRN needs read access to\n
^AUPNVPRV('AD'\n
^AUPNVPRV(D0, FIELD .03 LOCATION 0;3\n
^AUPNVPRV(D0, FIELD .04 LOCATION 0;4\n", "", "", ""], ["2674", "DBIA2674", "File", "LAB SERVICE", "1998/12/17", "", "Retired", "Controlled Subscription", "", "
The CIRN Term Mapping routine (^RGHOMAP) makes a direct
global read of the BLOOD BANK UTILITY file (#65.4), for the purpose of setting
up a mapping reference.", "", "", ""], ["2675", "IA2675", "File", "SCHEDULING", "2003/08/13", "APPROVED", "Active", "Private", "44", "
to determine the Medical Center Division IEN associated
with the Hospital Location when Batch Printing Progress Notes.", "", "", ""], ["2676", "Disable & Enable Rad/Nuc Med Order Dialog", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1998/12/22", "APPROVED", "Active", "Private", "", "
The purpose of this database integration agreement
(DBIA) is to allow the subscribing package to disable and enable Order Dialogs
in CPRS. This would allow the specific package the ability to shut down their
portion of the Order Dialog without impacting the functionality of other
packages that interact with CPRS. This request is part of RA*5.0*6, whose
goal is to synchronize the Orderable Items (#101.43) file and the Rad/Nuc Med
Common Procedure file. This DBIA is dependent on OR*3.0*4, which exports the
latest version of routine ORXD.", "", "ORXD", ""], ["2677", "DBIA2677", "File", "LAB SERVICE", "1998/12/30", "", "Pending", "Private", "61", "
The CIRN Cytology data extraction routine ^RGHOPATH
makes direct global reads of the TOPOGRAPHY FIELD(#61). The routine ^RGHOPATH
uses this information to generate HL7 message for transmission of Pathology
reports.", "", "", ""], ["2678", "DBIA2678", "File", "OUTPATIENT PHARMACY", "1998/12/30", "", "Pending", "Private", "52", "
The CIRN Outpatient Pharmacy data extraction routine
(^RGHORXO - HL7 Message Generation for Prescriptions), makes several
references to fields in the PRESCRIPTION file (#52), Version 6 only, for the
purpose of creating the HL7 transmission records. *Note: Some of the
referenced PRESCRIPTION file fields have already been defined in DBIA: 824.", "", "", ""], ["2679", "OE/RR calls RAO7MFN to populate radiology orderables", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1998/12/30", "APPROVED", "Active", "Private", "", "
ENALL^RAO7MFN is called from the post-installation
processes of OR*2.5*49 and CPRS (Order Entry/Results Reporting v3.0) to
populate radiology orderable items into OE/RR.", "", "RA07MFN", ""], ["2680", "OE/RR use of PSRX global", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
As part of the pre-CPRS functionality that is released
with OR*2.5*49, an estimate of global growth is given. One of the components
of that growth is the backfilling of outpatient pharmacy prescriptions.\n
In order to calculate the number of prescriptions that might be backfilled, we
loop through the PHARMACY PATIENT file and then through the "A" x-ref of the
PRESCRIPTION PROFILE multiple (#55.03). We then get the pointer to the
PRESCRIPTION file (from the cross-reference) where we check the status of the
prescription and the existence of a PATIENT file pointer.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2681", "OE/RR limited use of LAB(69.9", "File", "LAB SERVICE", "1998/12/30", "APPROVED", "Active", "Private", "69.9", "
Patch OR*2.5*49 releases some setup functionality in
advance of CPRS. This DBIA requests the listed access to LAB(69.9,1,7, for
the period of time between the release of OR*2.5*49 and time when the last
site installs CPRS. CPRS retrieves the information from calls to lab (which
don't exist prior to installation of CPRS).", "", "", ""], ["2682", "OE/RR references to PS(59.7,", "File", "PHARMACY DATA MANAGEMENT", "1998/12/30", "", "Retired", "Private", "59.7", "
This agreement will be retired on 12/31/2006. Please do
not add any
additional code that utilizes this Integration Agreement. APIs have been
created that can be used in place of any code needing to make use of this
agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code
that currently utilizes this Integration Agreement must be converted to
use the new API's. If any part of this Integration Agreement cannot be
satisfied with the APIs, please contact the PRE development team mail
group at EMAIL GROUP DEV using Microsoft Outlook.\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy
packages are still allowed to utilize this agreement past the expiration
date of December 31, 2006. OR*2.5*49 performs a check to ensure pharmacy
data management matching is complete prior to letting OR*2.5*49 be installed.", "", "", ""], ["2683", "OE/RR calls to 2683", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1998/12/30", "APPROVED", "Active", "Private", "79.2", "
OE/RR references RA(79.2 as follows: 1. During order
dialog a lookup is performed to select the IMAGING TYPE 2. The C index is
used to loop through entries by ABBREVIATION of the
IMAGING TYPE 3. The .01 and 3 fields are referenced via direct reads", "", "", ""], ["2684", "OE/RR needs to save/restore LM video attributes", "Other", "LIST MANAGER", "1998/12/31", "APPROVED", "Active", "Private", "", "
List Manager maintains video attributes in ^TMP("VALM
VIDEO". Within Order Entry/Results Reporting and Consult/Request Tracking,
list manager is used extensively. One of the key features used is to have
list manager actions which envoke other list manager displays. An example
would be entering CPRS on the patient selection screen, selecting a patient
and getting the cover sheet, selecting to change ot the orders tab (another
screen), and adding orders (yet another screen).\n
In order to maintain the video attributes of a particular display, it's
necessary for OE/RR and Consults to save off the values in ^TMP("VALM VIDEO"
prior to changing screens and kill existing values and restore them when
returning. Saving/restoring of this data is done with the MERGE command.\n
This DBIA requests authorization to access the ^TMP("VALM VIDEO",$J) data,
kill it, and reset it based on previous values.", "", "", ""], ["2685", "OE/RR direct reference to XTV(8989.51", "File", "TOOLKIT", "1998/12/31", "APPROVED", "Active", "Private", "8989.51", "
Within OE/RR, it's necessary to determine a parameter
definitions IEN. To do this, the 'B' index of the PARAMETER DEFINITION file
(#8989.51) is utilized.", "", "", ""], ["2686", "OE/RR direct reference to XTV(8989.5", "File", "TOOLKIT", "1998/12/31", "APPROVED", "Active", "Controlled Subscription", "8989.5", "
Within OE/RR, it's necessary to determine if a
parameter is in use. To do this, the parameter definition IEN is determined
based on the 'B' index of the PARAMETER DEFINITION file (#8989.51) (see DBIA
2685).\n
Using that IEN, the 'AC' x-ref in the PARAMETERS file (#8989.5) is utilized to
determine if any parameter entity is set to a given value. If so, deletion of
the item is prohibited.\n
In addition, a one time patch post-install routine (ORY27) used this x-ref
when populating a new parameter value based on an existing value.", "", "", ""], ["2687", "OE/RR calls GMRCPOS1 to populate consult orderables", "Routine", "CONSULT/REQUEST TRACKING", "1998/12/31", "APPROVED", "Active", "Private", "", "
During the OR*2.5*49 and OE/RR v3 (CPRS) post-install
processes, EN^GMRCPOS1 is called. This routine loops through those consult
services that can be selected and passes them back to OE/RR for population
into the Orderable Items file.", "", "GMRCPOS1", ""], ["2688", "OE/RR calls LR7OV1 to populate lab orderables", "Routine", "LAB SERVICE", "1998/12/31", "APPROVED", "Active", "Private", "", "
During the OR*2.5*49 post-install process, EN^LR7OV1 is
called. This routine takes values from lab files and uses them to populate LR
namespaced parameters in Parameter Tools (XPAR*). These parameters are
utilized from within CPRS.", "", "LR7OV1", ""], ["2689", "OE/RR references to ALERT file", "File", "KERNEL", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "8992", "
OE/RR utilizes the alerting functionality extensively.
While supported calls are often used, there are also direct references to the
ALERT file (#8992) as described in this DBIA.", "", "", ""], ["2690", "Consults calls to ORB3FUP1", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/01/02", "APPROVED", "Active", "Private", "", "
Consults calls ORB3FUP1 to delete a CPRS-related alert
after it has been processed.", "", "ORB3FUP1", ""], ["2691", "Calls to ORPR02", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/01/02", "", "Withdrawn", "Controlled Subscription", "", "
ORPR02 contains functionality to print various types of
CPRS-related outputs (chart copies, work copies, requisitions, etc.).", "", "ORPR02", ""], ["2692", "ORQPTQ1 calls", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/01/02", "APPROVED", "Active", "Controlled Subscription", "", "
ORQPTQ1 provides entry points to provide patient lists
by providers, etc. This DBIA will include those calls being used by outside
packages.", "", "ORQPTQ1", "2008/09/17"], ["2693", "TIULQ calls", "Routine", "TEXT INTEGRATION UTILITIES", "1999/01/02", "APPROVED", "Active", "Controlled Subscription", "", "
Entry points in this routine provide extract mechanisms
for TIU records.", "", "TIULQ", ""], ["2694", "TIURA1 calls", "Routine", "TEXT INTEGRATION UTILITIES", "1999/01/02", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls allowed to TIURA1.", "", "TIURA1", ""], ["2695", "DD AUDIT ACCESS", "File", "1", "1999/01/04", "APPROVED", "Active", "Private", "2", "
CIRN PD would like a DBIA for its direct global read of
^DD(2,"AUDIT". This direct global read is used to identify all of the top
level PATIENT (#2) file fields that are currently marked for auditing. We
realize this will not get subfile fields within the PATIENT (#2) and we are
willing to disregard those fields in our report until an API is provided for
all audited fields within the PATIENT (#2) file.", "", "", ""], ["2696", "RECOMPILATION OF PRINT TEMPLATES", "File", "1", "1999/01/06", "APPROVED", "Active", "Controlled Subscription", ".4", "
When installing a patch that includes changes to field
definitions in a data dictionary, KIDS does not recompile the compiled print
templates.\n
Recompilation of print templates may involve the following steps:\n
(1) Traverse the "AF" cross-reference of the ^DIPT global (file
#.4) to obtain a list of compiled print templates for the
affected fields. The structure of this cross-reference is
^DIPT("AF",file,field,template)=""\n
Subfields would be treated like fields of their respective
subfiles, i.e. ^DIPT("AF",subfile,subfield,template)="".\n
(2) For each template that is being recompiled, access
^DIPT(template,"ROU") to determine the compiled routine.\n
(3) Invoke EN^DIPZ to recompile that print template.\n", "", "", "2012/04/03"], ["2697", "DBIA2697", "File", "MENTAL HEALTH", "1999/01/06", "APPROVED", "Active", "Private", "603.01", "
The Outpatient and Inpatient Medications packages
request permission for read access CLOZAPINE PATIENT LIST file (603.01). The
packages also request read access to the ^YSCL(603.01,"B",$E(X,1,30),DA) and
^YSCL(603.01,"C",$E(X,1,30),DA) cross references.", "", "", ""], ["2698", "Direct access to the Urgency File (101.42)", "File", "ORDER ENTRY/RESULTS REPORTING", "1999/01/11", "APPROVED", "Active", "Private", "101.42", "
The Consults package uses the ORDER URGENCY file,
101.42 to convert the orders urgency to a protocol value. The Abbreviation
field is used to determine which Protocol to use. The abbreviation is what is
sent to Consults in an HL7 message.\n
The use of the Protocol file for recording Urgency will be converted to using
the ORDER URGENCY file in a future patch. Rather than storing the protocol
pointer representing the Urgency, a pointer will be stored to the ORDER
URGENCY file.\n
Until the conversion, direct access is needed to the ABBREVIATION field in the
ORDER URGENCY file.", "", "", ""], ["2699", "Direct access to TIU(8925,", "File", "TEXT INTEGRATION UTILITIES", "1999/01/11", "APPROVED", "Active", "Private", "8925", "
TIU is used by the Consult package to store the signed
notes resolving a Consult or Procedure request.\n
Consults checks for the existing node in ^TIU(8925,D0,0) before calling TIU
utilities.", "", "", ""], ["2700", "Direct access to the TIU CLASS file (8925.1)", "File", "TEXT INTEGRATION UTILITIES", "1999/01/11", "APPROVED", "Active", "Private", "8925.1", "
The Consults package uses the "B" cross-reference of
the TIU Document Definition file (8925.1) to find the "CONSULTS" entry. The
TYPE field, fourth piece of the zeroth node, of the consults entry is used to
check for "CL" or "DC" (Class or Document Class Type).", "", "", ""], ["2701", "MPIF001", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/12", "APPROVED", "Active", "Supported", "", "
Function APIs to return values on the MPI node in the
Patient file. This DBIA documents some entry points for accessing the MPI
node in the Patient file for use by the CIRN developers and others that may
need this data.", "", "MPIF001", ""], ["2702", "MPIFAPI", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/12", "APPROVED", "Active", "Supported", "", "
Functions to return the MPI node, Subscriptioon Control
Number from the MPI Node, the name of the HL7 Logical Link for the MPI and to
return the next Local Integration Control Number. These APIs are provided for
the CIRN developers and others that may need this data.", "", "MPIFAPI", ""], ["2703", "$$CHANGE MPIF001", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/12", "APPROVED", "Active", "Controlled Subscription", "", "
This function updates the CIRN Master of Record
(991.03) field in the Patient (#2) file on the MPI node. This is being
provided for use by the CIRN developers.", "", "MPIF001", ""], ["2704", "$$SETICN MPIF001", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/12", "", "Retired", "Private", "", "
This function updates the Intergration Control Number
(#991.01) and the ICN Checksum (#991.02) fields in the Patient (#2) file on
the MPI node. This is being provided for use by the CIRN developers.", "", "MPIF001", ""], ["2705", "$$SETLOC MPIF001", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/13", "", "Retired", "Private", "", "
This function allows the updating the the Local ICN
field (#991.04) in the Patient file (#2) on the MPI node. This is provided to
assist the CIRN developers.", "", "MPIF001", ""], ["2706", "$$UPDATE MPIFAPI", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/13", "APPROVED", "Active", "Controlled Subscription", "", "
This API will allow the calling package to update the
MPI node fields (991.01-991.05) in the Patient file (#2). This is being
provided for the CIRN developers.", "", "MPIFAPI", ""], ["2707", "MER MPIFMER", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/13", "APPROVED", "Active", "Private", "", "
This routine will trigger the merge/change ICN message
to be sent to the MPI and any sites subscribing to this patient via CIRN.
This is being provided to the CIRN/DG developers to support the CIRN/MPI
effort.", "", "MPIFMER", ""], ["2708", "DELETE MPIFQ1", "Routine", "MASTER PATIENT INDEX VISTA", "1999/01/13", "APPROVED", "Active", "Private", "", "
DELETE^MPIFQ1 is used to remove the entry in the
Patient file that was just created. It is to be used when the direct connect
to the MPI returned a list of patients that are potential matches and asked
the user to select one. The user then selects as the match, a patient that is
currently in the local Patient file. the Patient file entry that was just
created would then be removed. This will only happen if the patient was just
entered into the Patient file (#2). This is being supplied to support the
MPI/CIRN effort.", "", "MPIFQ1", ""], ["2709", "New Person file", "File", "KERNEL", "1999/04/26", "APPROVED", "Active", "Private", "200", "
The Laboratory package is cleaning up a reference to
the Person file (#16). We need read access only to the A16 cross reference of
the New Person file (#200). This access is only for use with patch
LR*5.2*237.", "", "", ""], ["2710", "CALC RGVCCMR2", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1999/01/13", "APPROVED", "Active", "Controlled Subscription", "", "
Function API to calculate the CIRN CMOR Activity Score
for an individual patient. This is being provided for the MPI developers to
allow for re-calculating the CIRN CMOR Activity Score during the CMOR Batch
Comparision job.", "", "RGVCCMR2", ""], ["2711", "DBIA2711", "File", "DRUG ACCOUNTABILITY", "1999/04/28", "APPROVED", "Active", "Private", "58.8", "\n
This DBIA is to be used as an open agreement between Drug Accountability
and Controlled Substances. The terms of this agreement are to allow
Controlled Substances access to any field within the DRUG ACCOUNTABILITY
STATS file (#58.8).\n
The access method can be either Direct Read/Write access, or by using
FileManager to obtain or create data.\n
The reason for this agreement is that prior to the release of Version 3.0
of Drug Accountability, this file was the property of Controlled
Substances.", "", "", ""], ["2712", "DBIA2712", "Routine", "AUTHORIZATION/SUBSCRIPTION", "1999/01/14", "APPROVED", "Active", "Private", "", "
The function ISTERM offers an approved means of
identifying whether a user is currently terminated, as supported by DBIA
10060, until such time as Kernel provides a comparable function.", "", "USRLM", ""], ["2713", "Consults calls to ORB3F1", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/01/14", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement will allow consults to call the
following tag(s) in routine ORB3F1.", "", "ORB3F1", ""], ["2714", "Input Template to CRIN Site Parameter 991.8", "File", "CLINICAL INFO RESOURCE NETWORK", "1999/01/19", "APPROVED", "Active", "Private", "991.8", "
MPIF is requesting to be able to create and utilize an
input template to the CIRN Site Parameter file (#991.8) called MPIF SITE
PARAMETERS to support in editing the CMOR Request related fields.", "", "", ""], ["2715", "READ NEW PERSON (#200) FILE NAME & SSN FIELDS", "File", "KERNEL", "1999/01/19", "", "Withdrawn", "Private", "200", "
Registration requires direct global read access to the
Name (#.01) and SSN (#9) fields in the New Person (#200) for Privacy Act
compliance. Routine DGSEC will be modified to obtain the user's name and SSN
from the New Person file.", "", "", ""], ["2716", "DG MST STATUS API'S", "Routine", "REGISTRATION", "1999/01/19", "APPROVED", "Active", "Supported", "", "
The purpose of these API's is to facilitate the entry
and retrieval of Military Sexual Trauma status information on veterans. The
primary mechanism is within the Registration package, but data will be
requested from, and eventually updated from Scheduling and Patient Care
Encounters. VAH Directive 98-058 "Sexual Trauma Counseling Care and
Services", provides the guidance on this data collection.\n", "", "DGMSTAPI", ""], ["2717", "MPIF OPTIONS/MENUS ON CIRN MENUS", "Other", "CLINICAL INFO RESOURCE NETWORK", "2005/10/11", "", "Retired", "Private", "", "
MPI is requesting to place some options/menus on CIRN
namespaced Menus.\n
MPIF VISTA MENU on the RG ADMIN COORD MENU
MPIF CMOR MGR on the RG ADMIN USER MENU
MPIFINIT DPT TO MPI on the RGINIT MENU
MPIF COMP MAIN on the RGINIT MENU
MPIF SITE PARAMETER on the RG ADMIN COORD MENU", "", "", ""], ["2718", "Check TaskMan State", "File", "KERNEL", "1999/01/20", "APPROVED", "Active", "Private", "", "
FileMan KIDS Enviromental Check routines:
DIENVWRN (Warn the installer, but allow the install to continue)
and
DIENVSTP (Stop the install)\n
need to check TaskMan's enviroment to see if TaskMan is in a STOPed state or
is in the "WAIT" state. There is a supported call to: $$TM^%ZTLOAD which
returns whether or not TaskMan is running, but not if TaskMan is in a "WAIT"
state. The following code is used in routines DIENVWRN and DIENVSTP to check
for these conditions:\n
TMCHK ; Check to see if TaskMan is still running
S X=$$TM^%ZTLOAD
I X,'$D(^%ZTSCH("WAIT")) D\n
FileMan would like a temporary intergration agreement, with the Kernel, until
such time as $$TM^%ZTLOAD can return all three conditions Running, Waiting,
and Stopped.", "", "", ""], ["2719", "Logons Inhibited", "File", "KERNEL", "1999/01/20", "APPROVED", "Active", "Private", "", "
FileMan KIDS Enviromental Check routines:
DIENVWRN (Warn the installer, but allow the install to continue)
and
DIENVSTP (Stop the install)\n
need to check if Logons have been Inhibited and the following code is being
used:\n
LINH ; Check to see if Logons are Inhibited
D GETENV^%ZOSV ; $P(Y,"^",2) = Installing Volume
S X=+$G(^%ZIS(14.5,"LOGON",$P(Y,"^",2)))
I 'X D Q ; Bail Out of Install\n
FileMan would like a temporary intergration agreement, with the Kernel, until
such time a single call can be developed that will return whether or not
Logons have been Inhibited.", "", "", ""], ["2720", "DBIA2720", "Routine", "LAB SERVICE", "1999/01/21", "", "Pending", "Private", "60", "
The CIRN Cytology data extraction routine ^RGHOPATH
makes direct global reads of the LABORATORY TEST(#60). The routine ^RGHOPATH
uses this information to generate HL7 message for transmission of Pathology
reports.\n", "", "", ""], ["2721", "DBIA2721", "File", "LAB SERVICE", "1999/01/21", "", "Pending", "Private", "63", "
The CIRN Cytology data extraction routine ^RGHOPATH
makes direct global reads of the LAB DATA(#63). The routine ^RGHOPATH uses
this information to generate HL7 message for transmission of Pathology
reports.\n", "", "", ""], ["2722", "DBIA2722", "Routine", "PCE PATIENT CARE ENCOUNTER", "1999/01/21", "APPROVED", "Active", "Private", "", "
Integration Agreement between PCE and EVENT CAPTURE for
use of CLASS^PXBAPI21.\n
After answering "No" to "Service Connected:", the user expects to see the
prompt(s) for AO/IR/EC/CLV as appropriate for the patient (just as in
Scheduling checkout), but these prompts are never seen for SC 50-100% vets.
The reason being that Event Capture uses calls to SC^SDCO22, AO^SDCO22,
EC^SDCO22, IR^SDCO22, and CLV^SDCO22 to determine which of the classification
questions should be asked. (That takes place in ASKCLASS^ECUTL1 and
GETCLASS^ECUTL1.) AO^SDCO22, EC^SDCO22, IR^SDCO22, and CLV^SDCO22 always
return zero for an SC 50-100% vet -- therefore Event Capture never prompts for
any of these classifications even though the encounter is not related to the
patient's service connected disabilities.\n
Looking into the Scheduling checkout functionality, it is CLASS^PXBAPI21 which
allows this scenario to be properly handled (starting in INTV^PXAPI) -- it
allows the user to answer AO/IR/EC/CLV for SC 50-100% vets after specifying
that the encounter isn't service connected.\n
Specifically, the call will be constructed as follows:\n
N PBXDATA
D NOW^%DTC S DATE=%
D CLASS^PXBAPI21("",DFN,DATE,1,"")\n
An example of user prompts for an SC 50-100% patient with exposure to AO, IR,
EC, and CLV follows:\n
--- Classification --- [Required]\n
Was treatment for SC Condition? NO
Was treatment related to Agent Orange Exposure? YES
Was treatment related to Ionizing Radiation Exposure? YES
Was treatment related to Environmental Contaminant Exposure? YES
Was treatment related to Camp Lejeune Exposure? YES\n
Data is returned as follows:\n
PXBDATA(1)=0^1 <-- Agent Orange
PXBDATA(2)=0^1 <-- Ionizing Radiation
PXBDATA(3)=0^0 <-- Service Connected
PXBDATA(4)=0^1 <-- Environmental Contaminants
PXBDATA(5)=0^1 <-- Camp Lejeune
where the 2nd piece indicates the user's answer to the
classification prompt -- 0=NO, 1=YES\n\n\n", "", "PXBAPI21", "2017/01/10"], ["2723", "MAILBOX AND BASKET API", "Routine", "MAILMAN", "1999/01/25", "APPROVED", "Active", "Supported", "", "
The APIs in this DBIA perform mailbox and basket
actions.\n
If any errors occur, the following variables will be defined:\n
XMERR - The number of errors\n
^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text>\n
Following is information on some common input parameters:\n
XMDUZ - The user (DUZ or enough of the user's name, alias, initials, or
nickname for a positive ID) for whom the API is being called. An FM lookup
into the ^VA(200, NEW PERSON file will be performed.\n
XMK - The basket (IEN or enough of its name for a positive ID) for which
the API is being called.\n
XMTROOT - (optional) The target root to receive the requested list. This
quoted string must be a closed root. The node "XMLIST" will be added
underneath it. This is an optional parameter. It defaults to
^TMP("XMLIST",$J).", "", "XMXAPIB", ""], ["2724", "OR*2.5*49 EXPORTS LAB PARAMETERS", "Other", "LAB SERVICE", "1999/01/26", "APPROVED", "Active", "Private", "", "
OR*2.5*49 sends out the following LR namespaced values
for the PARAMETER DEFINITION file. These parameters were needed for part of
the pre-CPRS setup activities.\n
LR ASK URGENCY LR COLLECT FRIDAY LR COLLECT MONDAY LR COLLECT SATURDAY LR
COLLECT SUNDAY LR COLLECT THURSDAY LR COLLECT TUESDAY LR COLLECT WEDNESDAY LR
DEFAULT TYPE QUICK LR EXCEPTED LOCATIONS LR IGNORE HOLIDAYS LR MAX DAYS
CONTINUOUS LR PHLEBOTOMY COLLECTION\n
This is a one time request.", "", "", ""], ["2725", "OE/RR READ RADIOLOGY PARAMETERS", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "1999/01/26", "APPROVED", "Active", "Private", "", "
These parameter definitions and values were originally
distributed via OR*2.5*49 as part of the pre-CPRS setup activities.\n
After the initial export, and beginning with OE/RR v3.0, these parameters have
been read by OE/RR when building the radiology order dialog for use in CPRS
GUI.\n
This ICR entry is being updated with the release of OR*3.0*608, CPRS GUI
v33SWD, to reflect the historical and ongoing usage of these parameter
definitions by OE/RR and CPRS GUI. No new functionality or access is included
or implied with this ICR update.\n\n
The two RADIOLOGY parameter definitions covered by this ICR are:\n\n
RA REQUIRE DETAILED\n
RA SUBMIT PROMPT", "", "", "2023/11/15"], ["2726", "OE/RR calls GMPL1", "Routine", "PROBLEM LIST", "1999/01/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine GMPL1.", "", "GMPL1", ""], ["2727", "OE/RR REFERENCES TO AUPNPROB", "File", "PROBLEM LIST", "1999/01/26", "APPROVED", "Active", "Controlled Subscription", "9000011", "
This DBIA documents OE/RR's use of the PROBLEM file
(9000011).", "", "", ""], ["2728", "USER ENVIRONMENT API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
Create the MailMan environment in which the user will
operate while in MailMan.\n
Set up the user's XMV array, which contains vital user information, user
preferences, and, if the user is a surrogate, the user's level of
authorization. The information in this array is used throughout MailMan.\n
If any errors occur, the following variables will be defined:\n
XMERR - the number of errors\n
^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text>", "", "XMVVITAE", ""], ["2729", "MESSAGE ACTION API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
The APIs in this DBIA perform message actions. They
are designed to be used individually or incorporated into a MailMan front end.\n
For usage instructions, please refer to the Programmer Manual, available at
the Infrastructure web site.\n
When used as part of a MailMan front end, INIT^XMVVITAE should be called to
create the MailMan environment in which the user will operate. Please see
DBIA 2728 for information on the XMVVITAE APIs.\n
When used individually, from a routine, the XMVVITAE APIs should not be
called.\n
After every API call, the calling routine should check for the existence of
XMERR. If any errors occur, the following variables will be defined:
XMERR - the number of errors
^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text>\n
Parameter definitions:\n
XMDUZ User's DUZ or enough of the name for a positive ID.\n
XMINSTR (optional) Array of special instructions
("ADDR FLAGS") Special addressing instructions, any or all of the
following:
I Do not Initialize (kill) the ^TMP addressee global, because it
already contains addressees for this message, as a result of a previous call
to an API.
R Do not Restrict message addressing:
- Ignore 'domain closed'
- Ignore 'keys required for domain'
- Ignore 'may not forward to domain'
- Ignore 'may not forward priority mail to groups'
- Ignore 'message length restrictions to remote addressees'
X Do not create the ^TMP addressee global, because addressees are only
being checked for validity.\n
("FLAGS") Message is any or all of the following:
P Priority
I Information only (may not be replied to)
X Closed message (may not be forwarded)
C Confidential message (surrogate may not read)
S Send to sender (make sender a recipient)
R Confirm receipt (return receipt requested)\n
("FROM") String saying who the message is from (default is user, as
identified by XMDUZ parameter). This string is placed in field 1 'from' in
the message file. Must not be any real person, except for Postmaster. DUZ is
not captured in field 1.1 'sender' of message file, thus making this option
well-suited for messages from VISTA packages.\n
("FWD BY") String saying who forwarded the message (default is user, as
identified by XMDUZ parameter). This string is placed in field 8 'forwarded
by' in the recipient multiple of the message file. Must not be any real
person, except for Postmaster. DUZ is not captured in field 8.01 'forwarded
by (xmduz)' in the recipient multiple of message file, thus making this option
well-suited for messages forwarded by VISTA packages.\n
("HDR") Print the messages with a header? (0=no; 1=yes) Default is yes.\n
("LATER") Date/time (any format understood by FM) on which to send this
message. Default is now.\n
("NET REPLY") Should reply be sent over the network? (0=no; 1=yes)
Default is no. Currently valid only if sender of original message is remote.\n
("NET SUBJ") Subject of reply to be sent over the network. Default is "Re:
<subject of original message>". Ignored unless XMINSTR("NET REPLY")=1.\n
("RCPT BSKT") Basket to deliver to for all recipients. Default is IN
basket. Recipients must have specified in their personal preferences that
such targeted basket delivery is allowed. Otherwise, this option is ignored.\n
("RECIPS") Print recipients along with the message?
0 No (default)
1 Print summary recipients
2 Print detailed recipients\n
("RESPS") Print which responses?
* Original message and all responses (default)
0 Original message only
range list (e.g. 0-3,5,7-99) - Print this range of responses. Ignored
if more than one message is printed. This parameter is not checked. It must
be correct. Range list may also be open-ended (e.g. 1,2,5- means print
responses 1 and 2 and responses 5 to the end).\n
("SCR KEY") Scramble key (implies that message should be scrambled). Must
be 3-20 characters long.\n
("SCR HINT") Hint for scramble key (mandatory if message is to be
scrambled). Must be 1-40 characters long.\n
("SELF BSKT") Basket to deliver to if sender is recipient. Default
is IN basket.\n
("SHARE BSKT") Basket to deliver to if SHARED,MAIL is recipient.
Default is IN basket.\n
("SHARE DATE") Date/time (any format understood by FM) to delete this
message from SHARED,MAIL if SHARED,MAIL is recipient.\n
("STRIP") String containing characters to strip from the message text
(XMBODY). Must be 1-20 characters long.\n
("TO PROMPT") During interactive message addressing, contains the
suggested initial addressee. Default is the user identified by XMDUZ.\n
("TYPE") Message type is one of the following special types:
D Document
S Spooled Document
X DIFROM
O ODIF
B BLOB (reserved for future use)
K KIDS\n
("VAPOR") Date/time (any format understood by FM) on which to delete
(vaporize) this message from recipient baskets. Recipients may override this
date. Also used to set vaporize date/time for messages already in one's own
baskets.\n
("WHEN") Date/time (any format understood by FM) on which to print
messages. Default is now.\n
[.]XMTO Addressee or addressee array (if array, must be passed by
reference). May be or contain any of the following:
User's DUZ, or enough of user's name for a positive ID
eg: 1301 or "lastname,firs" or ARRAY(1301)=""
ARRAY("lastname,firs")=""
G.group name (enough for positive ID)
S.server name (enough for positive ID)
D.device name (enough for positive ID)
You may prefix each addressee (except devices and servers) by:
I: for 'information only' recipient (may not reply)
eg: "I:1301" or "I:lastname,firs"
C: for 'copy' recipient (not expected to reply)
eg: "C:1301" or "C:lastname,firs"
L@datetime: for when (in future) to send to this recipient (datetime may be
anything accepted by FM)
eg: "L@25 DEC@0500:1301" or "L@1 JAN:lastname,firs"
or "L@2981225.05:1301"
(may combine IL@datetime: or CL@datetime:)
To delete recipient, prefix with -
eg: -1301 or "-lastname,firs"
Append "@<sitename>" for any addressees at another site:
eg: "I:G.group@site.dsn" or "LAST,FIRST@site.dsn"\n
XMK and XMKZ for APIs which act on one message:
XMK (optional, depending on XMKZ) Basket (IEN or name) containing the
message.
XMKZ Identifies the message. Must be one of the following:
Message number (XMZ) in Message global (XMK must not be specified)
Message number in the basket (XMK must be specified)\n
XMK and XMKZA for APIs which act on groups of messages:
XMK (optional, depending on XMKZA) Basket (IEN or name) containing the
messages.
XMKZA Identifies messages, using a list or list array, which may end
in a comma. Must be one of the following:
Message numbers (XMZ) in Message global (XMK must not be specified, AND
ranges are not allowed):
- List: "1234567" or "1234567,9763213"
- List array: ARRAY(1234567)=""
ARRAY(9763213)=""
Message numbers in the basket (XMK must be specified, ranges are OK):
- List: "1" or "1,3,5-7"
- List array: ARRAY("1,3")=""
ARRAY("5-7")=""", "", "XMXAPI", ""], ["2730", "MESSAGE EDIT API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs are intended for use by MailMan front ends.
They edit different parts of a message. They may only be used by the message
sender, and, with the exception of INFO^XMXEDIT, may only be used before the
message has been sent to anyone besides the sender. The APIs do not contain
any checks to ensure that it was appropriate to call them. That is the
responsibility of the calling routine.\n
For these APIs, it is expected that:\n
INIT^XMVVITAE has been called to set up the user's XMV array, with vital
user information, user preferences, and, if the user is a surrogate, determine
level of authorization. See DBIA 2728 for information on INIT^XMVVITAE.\n
The calling routine has determined that the user is authorized to see the
message. If the message is in the user's mailbox, then that's enough.
Otherwise, $$ACCESS^XMXSEC should be used to determine authorization. See
DBIA 2731 for information on $$ACCESS^XMXSEC.\n
OPTMSG^XMXSEC2 has been called and has given its permission to edit the
message or to toggle information only. (Note: $$EDIT^XMXSEC2 will also let
you know whether the user may edit the message.) See DBIA 2733 for information
on OPTMSG^XMXSEC2A and $$EDIT^XMXSEC2.\n
OPTEDIT^XMXSEC2 has been called and has given its permission to edit the
particular thing we are editing here. See DBIA 2733 for information on
OPTEDIT^XMXSEC2.\n
INMSG2^XMXUTIL2 has been called to set XMINSTR. These routines expect that
XMINSTR has been correctly set. They will change XMINSTR according to the
item being edited. See DBIA 2736 for information on INMSG2^XMXUTIL2.", "", "XMXEDIT", ""], ["2731", "SECURITY, PERMISSIONS, & RESTRICTIONS API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs perform security and permission functions.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXSEC", ""], ["2732", "SECURITY, PERMISSIONS, & RESTRICTIONS API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs perform security and permission functions.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXSEC1", ""], ["2733", "SECURITY, PERMISSIONS, & RESTRICTIONS API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs perform security and permission functions.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXSEC2", ""], ["2734", "MESSAGE & MAILBOX UTILITIES API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs are general message and mailbox utilities.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXUTIL", ""], ["2735", "DATE & STRING UTILITIES API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs perform date and string manipulation.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXUTIL1", ""], ["2736", "MESSAGE INFORMATION API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs return all kinds of information about a
message.
- Information that can be displayed.
- Information that can be used to determine what may (and may not) be done
with the message.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXUTIL2", ""], ["2737", "MESSAGE INFORMATION API", "Routine", "MAILMAN", "1999/01/27", "APPROVED", "Active", "Supported", "", "
These APIs provide information about how a message was
addressed and who has read it.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXUTIL3", ""], ["2738", "OE/RR references to GMR(120.8", "File", "ADVERSE REACTION TRACKING", "1999/01/28", "APPROVED", "Active", "Private", "120.8", "
This DBIA documents OE/RR references to the PATIENT
ALLERGIES file (#120.8).", "", "", ""], ["2739", "OE/RR references to GMR(123.5", "File", "CONSULT/REQUEST TRACKING", "1999/01/28", "APPROVED", "Active", "Private", "123.5", "
This DBIA documents OE/RR references tothe REQUEST
SERVICES file (#123.5).", "", "", ""], ["2740", "OE/RR calls to GMRCSLM1", "Routine", "CONSULT/REQUEST TRACKING", "1999/01/28", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to GMRCSLM1 as found in the
OE/RR v3 interface specification document.", "", "GMRCSLM1", ""], ["2741", "OE/RR calls to GMPLUTL2", "Routine", "PROBLEM LIST", "1999/01/28", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine GMPLUTL2.", "", "GMPLUTL2", "2014/11/05"], ["2742", "OE/RR calls to GMPLX", "Routine", "PROBLEM LIST", "1999/01/28", "APPROVED", "Active", "Private", "", "
This DBIA documents OE/RR calls to routine GMPLX.", "", "GMPLX", ""], ["2743", "OE/RR calls to GMPLX1", "Routine", "PROBLEM LIST", "1999/01/28", "APPROVED", "Active", "Private", "", "
This DBIA will document calls made from OE/RR (CPRS GUI
only) to routine GMPLX1.", "", "GMPLX1", "2015/08/17"], ["2744", "CIRN Access to DPT File", "File", "1", "1999/01/29", "", "Withdrawn", "Private", "2", "
CIRN needs a read access to the DPT 0 node file
(Patient File) in order to build the "B" cross reference to the DGCN(391.98
file. CIRN gets the first piece of the DPT 0 node field to build the "B"
cross reference.\n
CROSS-REFEREENCE: 391.98^B^MUMPS
1)= N A S A=$P($G(^DPT(X,0)),U,1) I A]"" S ^DGCN(391.98,
"B",A,DA)=""\n
2)= N A S A=$P($G(^DPT(X,0)),U,1) I A]"" K ^DGCN(391.98,
"B",A,DA)=""
This is the external to help in the sorting.\n
A precedent was set with DBIA 321 with the caveat:\n
It is further agreed that the following tools will not be used with
this file: KIDS, COMPARE/MERGE and TRANSFER. These tools rely on
an unmodified "B" index to function properly. Using the modified
"B" index of file 757.01 along with any of the named tools may
produce unexpected results.", "", "", ""], ["2745", "HEALTH SUMMARY TYPE LOOKUP", "Routine", "HEALTH SUMMARY", "1999/01/29", "", "Pending", "Supported", "", "
The lookup for the Healh Summay Type file has been
changed from a standard DIC lookup to a Multi-Term-Lookup effective patch
GMTS*2.7*30. The new lookup routines are in the GMTSULT namespace (Lookup
Type). The routine GMTSULT2 builds the list of possible Health Summary Types
to select from. The entry point LIST^GMTSULT2 is being support for potential
GUI applications which need an array of Health Summary Types to select from.", "", "GMTSULT2", ""], ["2746", "CIRN SITE PARAMETER 991.8", "File", "CLINICAL INFO RESOURCE NETWORK", "1999/02/03", "APPROVED", "Active", "Private", "991.8", "", "", "", ""], ["2747", "ORCSAVE2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/07/28", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement permits access to data stored in the
Orders file (#100) in OE/RR.", "", "ORCSAVE2", ""], ["2748", "MPIQ(DFN) in MPIFAPI", "Routine", "MASTER PATIENT INDEX VISTA", "1999/02/04", "APPROVED", "Active", "Controlled Subscription", "", "
MPI is providing support for the Registration package
to provide real-time queries to the MPI for assignment of an ICN and CMOR. If
the MPI is not available, a local ICN will be assigned instead. If the MPI
does not already know of this patient, the patient will be added and assigned
an ICN.\n
The call to accomplish this task is MPIQ^MPIFAPI(DFN), where DFN is the IEN of
the patient in the Patient file. This code is to be inserted after all the
required data has been collected on a new patient (new to the Patient file
(#2)). If the patient is already known, this code should be inserted after
the patient has been selected. Interaction will only occur with the MPI if
the patient does not have an ICN assignment.\n
This API is NOT a silent one. It can be made silent by setting the variable
MPIFS=1 prior to calling this API. The variable shouldn't be new'd prior to
calling MPIQ^MPIFAPI but should be killed after the call has been made.\n
NOTE: The following fields will be updated in the Patient file (#2) when a
successful interaction with the MPI has occurred: INTEGRATION CONTROL NUMBER
(#991.01), ICN CHECKSUM (#991.02), and CIRN MASTER OF RECORD (#991.03).\n
If the MPI was unavailable, in addition to the fields noted above, the LOCALLY
ASSIGNED ICN (#991.04) would be set to yes.", "", "MPIFAPI", ""], ["2749", "ABC", "Other", "IFCAP", "1999/02/08", "", "Withdrawn", "Private", "", "", "", "", ""], ["2750", "GMTSADOR ROUTINE", "Routine", "HEALTH SUMMARY", "1999/02/08", "APPROVED", "Active", "Private", "", "
The Women's Health package requests permission to call
the Health Summary package routine GMTSADOR at the line label of MAIN. This
entry point will allow Women's Health package users to create adhoc health
summary reports from within the Women's Health package.", "", "GMTSADOR", ""], ["2751", "DGCN(391.91 Treating Facility file", "File", "REGISTRATION", "1999/03/15", "APPROVED", "Active", "Private", "391.91", "
The Master Patient Index - VistA package is requesting
to add entries to the Treating Facility (#391.91) file via FILE^DICN call and
to check the "APAT" cross reference for the existence of the entry.", "", "", ""], ["2752", "OUTPATIENT PHARMACY: DD UPDATES", "Other", "1", "1999/03/15", "APPROVED", "Active", "Private", "", "
Outpatient Pharmacy V. 7.0 has permission to kill the
following ^DD entries in patch PSO*7*25. This is a one time agreement.\n
^DD(55,0,"P")
^DD(55,0,"PS")", "", "", ""], ["2753", "ADD entries to PATIENT DATA EXCEPTION (#391.98) File", "Routine", "REGISTRATION", "1999/03/16", "", "Withdrawn", "Private", "", "", "", "VAFCEHU1", ""], ["2755", "$$GETSRVR VAFCMSG5", "Routine", "REGISTRATION", "1999/02/17", "APPROVED", "Active", "Private", "", "
MPIF is requesting to use $$GETSRVR^VAFCMSG5 to get the
pointer to the HL7 server protocol for the A28 event type.", "", "VAFCMSG5", ""], ["2756", "$$BLDMSG VAFCMSG1", "Routine", "REGISTRATION", "1999/02/17", "APPROVED", "Active", "Private", "", "
MPIF is requesting to use $$BLDMSG^VAFCMSG1 to build
the HL7 ADT-A28 message for a given patient.", "", "VAFCMSG1", ""], ["2757", "OE/RR calls to MCARPS2", "Routine", "CLINICAL PROCEDURES", "1999/02/18", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA authorizes OE/RR v3 calling EN^MCARPS2(DFN)", "", "MCARPS2", ""], ["2758", "DBIA2758", "Other", "REGISTRATION", "1999/02/22", "APPROVED", "Active", "Private", "", "
REGISTRATION OPTIONS on CIRN namespaced menus.\n
Patient Data Review [VAFC EXCEPTION HANDLER] option on the MPI/PD Patient
Admin User Menu [RG ADMIN USER MENU]\n
Purge Patient Data Reviews [VAFC PDR PURGE] option on the MPI/PD Patient Admin
User Menu [RG ADMIN USER MENU]", "", "", ""], ["2760", "TEST PATIENT CHECK", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1999/02/26", "", "Withdrawn", "Private", "", "
This function will identify that a given patient is
either a dead patient, test patient, an employee, a non-veteran, or a Psuedo
patient. It will return a 1 if it meets the given parameter(s) or a 0 if it
does not meet the given parameter(s).", "", "RGRSUTL1", ""], ["2761", "ATTACH OR PROTOCOLS TO GMRC PROTOCOLS", "Other", "ORDER ENTRY/RESULTS REPORTING", "1999/02/26", "APPROVED", "Active", "Private", "", "
CONSULT/REQUEST TRACKING version 3.0 requests the
ability to attach three new OR namespaced protocols to GMRC protocols. This is
for the purpose of updating CPRS with staus updates to orders from
CONSULT/REQUEST TRACKING and updating CPRS with new orderable items from
CONSULT/REQUEST TRACKING.\n
The specific protocol linkage:\n
1) Attach OR RECEIVE and ORDER CHECK HL7 RECIEVE to GMRC EVSEND OR 2) Attach
OR ITEM RECEIVE to GMRC ORDERABLE ITEM UPDATE", "", "", ""], ["2762", "minus 9 nodes", "File", "KERNEL", "1999/03/01", "APPROVED", "Active", "Controlled Subscription", "2", "
MPI needs to check for the -9 node on the Patient file.
If the -9 node exists for a given entry, the MPI needs to not use this patient
entry.\n
NOTE: Duplicate Merge is responsible for setting the -9 node in the Patient
(#2) file. The Patient (#2) file is part of the Registration package.
However because Duplicate Merge is responsible for setting this node, it was
decided Kernel should be the Custodial Package as recommended by the DBA.", "", "", ""], ["2763", "Read %ZTSK Global", "File", "KERNEL", "1999/03/01", "APPROVED", "Active", "Private", "", "
Because Fileman supports both a non-VistA Kernel
environment and a VistA Kernel environment, a test is necessary to determine
which environment is present. A test that is used to determin if Queueing is
Allowed, therefore a VistA Kernel environment, is by checking whether or not
the %ZTSK global is present.", "", "", ""], ["2764", "BACKWARD COMPATIBILITY FOR ALERT FOLLOW-UP", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/03/02", "APPROVED", "Active", "Private", "", "
Consult/Request Tracking version 3.0 requests the
ability to call RPTCON^ORB3FUP2 from routine GMRCXQ. This will allow existing
alerts at the time of Consult/Request Tracking version 3.0 installation to be
processed correctly without conversion. This code would branch accordingly to
the proper code in the GMRC namespace.\n\n
This would be called as a result of processing three OE/RR NOTIFICATION types:
CONSULT/REQUEST RESOLUTION CONSULT/REQUEST CANCEL/HOLD SERVICE CONSULT/REQUEST", "", "ORB3FUP2", ""], ["2765", "FBUTL", "Routine", "FEE BASIS", "1999/03/04", "", "Retired", "Supported", "", "
FEE BASIS APIs.", "", "FBUTL", ""], ["2766", "Formatted Lab Results", "Routine", "LAB SERVICE", "1999/03/05", "APPROVED", "Active", "Supported", "", "
These calls get formatted Lab Results output into a
global array. These formats are based on definitions in the Lab Reports file
(64.5) for CH subscripted tests. For AP, Micro and Blood Bank, the format is
a hard coded traditional format.", "", "LR7OSUM", ""], ["2767", "Graph Lab Results", "Routine", "LAB SERVICE", "1999/03/05", "APPROVED", "Active", "Private", "", "
These are the entry points used by CPRS to display Lab
results graph.", "", "LRDIST4", ""], ["2768", "Lab Results", "Routine", "LAB SERVICE", "1999/03/05", "APPROVED", "Active", "Private", "", "
This is used by CPRS to get selected Lab Results
displayed.", "", "LRGEN", ""], ["2769", "Lab Results Interim Format", "Routine", "LAB SERVICE", "1999/03/05", "APPROVED", "Active", "Private", "", "
This is used by CPRS to get a display of lab results in
interim format.", "", "LRRP4", ""], ["2770", "GMTSLRPE ROUTINE", "Routine", "HEALTH SUMMARY", "1999/03/05", "APPROVED", "Active", "Controlled Subscription", "", "
The Women's Health package requests permission to call
the GMTSLRPE routine at the XTRCT line label. This routine returns cytology
data extracted from the LAB DATA file (#63) of the Laboratory package.", "", "GMTSLRPE", ""], ["2771", "GMTSLRAE ROUTINE", "Routine", "HEALTH SUMMARY", "1999/03/05", "APPROVED", "Active", "Controlled Subscription", "", "
The Women's Health package requests permission to call
the GMTSLRAE routine at the XTRCT line label. This routine returns surgical
pathology data extracted from the LAB DATA file (#63) of the Laboratory
package.", "", "GMTSLRAE", ""], ["2772", "WVLRLINK ROUTINE", "Routine", "WOMEN'S HEALTH", "1999/03/05", "APPROVED", "Active", "Private", "", "
The Women's Health (WH) package requests that the Lab
package will notify the WH package whenever lab test results are released or
changed for a cytology or surgical pathology test.", "", "WVLRLINK", "2023/08/09"], ["2773", "DBIA2773", "File", "HEALTH LEVEL SEVEN", "1999/03/09", "APPROVED", "Active", "Private", "774", "
CIRN Option RG SUBSCRIPT STAT INQ uses a Read with
FileMan to file ^HLS(774 (SUBSCRIPTION CONTROL) to do a lookup on a patient.
This allows users to identify which sites are currently receiving CIRN patient
information. It is display only.\n", "", "", ""], ["2774", "INTERACTIVE API", "Routine", "MAILMAN", "1999/03/09", "APPROVED", "Active", "Supported", "", "
These APIs are interactive.\n
Please see the Programmer Manual on the Infrastructure web site for further
information about the APIs and how to use them.", "", "XMXAPIU", ""], ["2775", "CIRN Subscription Bullentin", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1999/03/09", "", "Retired", "Private", "", "
This agreement identifies NOT2^RGRSBUL1 to be an entry
point that can be called to generate a bulletin to the RG CIRN DEMOGRAPHIC
ISSUE mail group informing that group with information passed in the parameter
list.", "", "RGRSBUL1", ""], ["2776", "CIRN Patient Match Bulletin", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1999/03/09", "", "Retired", "Private", "", "
This agreement identifies the entry point,
MTCHBULL^RGRSBULL, as a callable entry point that will generate a bulletin to
the RG CIRN DEMOGRAPHIC ISSUES mail group explaining the differences in the
inbound patient demographic information and the existing PATIENT (#2) file
informaton.", "", "RGRSBULL", ""], ["2777", "MODIFY ONCOLOGY PACKAGE ENTRIES", "File", "KERNEL", "1999/03/19", "APPROVED", "Active", "Private", "9.4", "
The ONCOLOGY package has two PACKAGE file entries. The
correct entry contains in incorrect PREFIX value which causes the KIDS
"Required Build" feature to function incorrectly. The incorrect entry
contains PATCH APPLICATION HISTORY data which belongs in the correct entry.\n
We would like to 1) modify the PREFIX values of both PACKAGE entries, 2) move
the PATCH APPLICATION HISTORY data from the incorrect entry to the correct
entry and 3) delete the PATCH APPLICATION HISTORY data from the incorrect
entry. These modifications will be achieved via standard FileMan calls.", "", "", ""], ["2778", "CIRN HL7 DYNAMIC ADDRESSING", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1999/03/19", "APPROVED", "Active", "Private", "", "
This agreement allows the REGISTRATION protocol, VAFC
MFU-TFL CLIENT, to contain the following routing logic:\n
N X S X="RGRSDYN1" X ^%ZOSF("TEST") Q:'$T D EN^RGRSDYN1("VAFC MFU-TFL
CLIENT",0)\n
This routing logic builds a dynamic link list of subscribering sites for the
patient being processed in the inbound HL7 message.", "", "RGRSDYN1", ""], ["2779", "DBIA2779", "Routine", "REGISTRATION", "1999/03/22", "APPROVED", "Active", "Private", "", "
This function will indentify that a given patient is
either a dead patient, test patient, an employee, a non-veteran, or a Psuedo
patient. It will return a 1 if it meets the given parameter or a 0 if it does
not meet the given parameter.", "", "VAFCUTL1", ""], ["2780", "DBIA2780", "File", "INTEGRATED BILLING", "1999/03/23", "APPROVED", "Active", "Private", "2", "
Integrated Billing allows PDX to read and write several
patient insurance data elements to support the exchange of insurance
information between facilities.\n
Update: IB*2*497 increased the length of the SUBSCRIBER ID field and the NAME
OF INSURED field to support the EDI New Standards and Operating Rules for VHA
providers. This required length increase made it necessary to move the
location of these 2 fields to new Data Dictionary nodes in the INSURANCE TYPE
sub-file. To support this implementation, all subscribers to this ICR will
need to make the necessary changes in their applications to reference the new
fields and remove the references to the old fields. When all subscribers have
implemented the use of the new fields, the old fields will be deleted with
IB*2*518. New fields are noted in the field list detail of this ICR.", "", "", "2014/02/21"], ["2781", "DBIA2781", "File", "INTEGRATED BILLING", "1999/03/23", "APPROVED", "Active", "Controlled Subscription", "2", "
This agreement allows certain applications to directly
read the field 'Covered by Health Insurance?' for the purpose of display only.\n", "", "", ""], ["2782", "DBIA2782", "File", "INTEGRATED BILLING", "1999/03/23", "APPROVED", "Active", "Private", "2", "
This agreement allows Mental Health to directly read
specific patient insurance fields for the purpose of display only.\n
Update: IB*2*497 increased the length of the SUBSCRIBER ID field to support
the EDI New Standards and Operating Rules for VHA providers. This required
length increase made it necessary to move the location of this field to a new
Data Dictionary node in the INSURANCE TYPE sub-file. To support this
implementation, all subscribers to this ICR will need to make the necessary
changes in their applications to reference the new field and remove the
reference to the old field. When all subscribers have implemented the use of
the new field, the old field will be deleted with IB*2*518. The new field is
noted in the field list detail of this ICR.", "", "", "2014/02/21"], ["2783", "DBIA2783", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1999/03/23", "", "Withdrawn", "Private", "", "
Registration needs an integration agreement with CIRN
to call the ASK2^RGMTAUD, patient audit entry point from within the Patient
Data Review [VAFC EXCEPTION HANDLER] option. This entry point allows the
users to view patient audit information from within the list manager Patient
exception review functionality.", "", "RGMTAUD", ""], ["2784", "Patient File Edit", "Routine", "REGISTRATION", "1999/03/23", "APPROVED", "Active", "Controlled Subscription", "", "
This private routine agreement allows packages to
update certain PATIENT (#2) file fields identified by each subscribing
package.", "", "VAFCPTED", "2007/07/16"], ["2785", "SCD Alert", "Other", "REGISTRATION", "1999/03/23", "", "Withdrawn", "Private", "", "
This request is to add a new item to the DGPM MOVEMENT
EVENTS protocol. The new item will be the SCD MOVEMENT EVENTS protocol. This
protocol will make a call to the SPNALERT routine, which in turn will run the
VADPT API. If its an admit event then an alert will be sent.", "", "", ""], ["2786", "DBIA2786", "File", "INTEGRATED BILLING", "1999/03/24", "APPROVED", "Active", "Private", "2", "
This agreement allows the DSS EXTRACTS application to
directly read specific patient insurance information for extraction by VISN
19.", "", "", ""], ["2787", "DBIA2787", "File", "REGISTRATION", "1999/03/24", "APPROVED", "Active", "Private", "2", "
In order to calculate the total number of in-patient
deaths in a given time period, the Laboratory package must utilize the DATE OF
DEATH cross-reference ^DPT("AEXP1" of the PATIENT file (#2). This is a
cross-reference of the DATE OF DEATH field (#.351). This a read-only usage of
this file.", "", "", ""], ["2788", "XQALBUTL", "Routine", "KERNEL", "1999/03/25", "APPROVED", "Active", "Supported", "", "
This DBIA lists and defines supported references within
the routine XQALBUTL.\n
AHISTORY(XQAID,ROOT) - Returns info on alert XQAID in ROOT in global format\n
$$PENDING(XQAID,XQAUSER) - Indicates whether alert XQAID is pending for user
XQAUSER (1=YES, 0=NO).\n
$$PKGPEND(XQAUSER,XQAPKG) - Returns 1 if the user indicated by XQAUSER has any
pending alerts in which the first ';'-piece of XQAID contain the package
identifier indicated by XQAPKG.\n
ALERTDAT(XQAID,ROOT) - Returns info on alert XQAID in ROOT by field and values
(if ROOT is not specified, returned in local variable XQALERTD)\n
USERLIST(XQAID,ROOT) - Returns list of users who received alert XQAID in array
under ROOT (if ROOT is not specified, returned in local variable XQAUSRS)\n
USERDATA(XQAID,XQAUSER,ROOT) - Returns info on user XQAUSER for alert XQAID in
ROOT by field and values (if ROOT is not specified, returned in local variable
XQALUSER).", "", "XQALBUTL", ""], ["2789", "DBIA2789", "Routine", "PHARMACY DATA MANAGEMENT", "1999/03/25", "APPROVED", "Active", "Controlled Subscription", "", "
This is the common lock routine for patient locks in
Inpatient Medications and Outpatient pharmacy. It also contains the entry
points for single order locks between Inpatient/Outpatient and Computerized
Patient Record System (CPRS).", "", "PSSLOCK", ""], ["2790", "XQALSURO", "Routine", "KERNEL", "1999/03/25", "APPROVED", "Active", "Supported", "", "
This DBIA describes supported references in the routine
XQALSURO which may be used to obtain information on, set, or remove a
surrogate for alerts for a user.", "", "XQALSURO", ""], ["2791", "DBIA2791", "File", "IMAGING", "1999/03/31", "", "Withdrawn", "Private", "2005", "
Imaging gives permission to Health Summary to read from
file 2005 for the purpose of displaying image descriptions. [MAGI]", "", "", ""], ["2792", "Add Entry to CIRN Event Queue", "Routine", "CLINICAL INFO RESOURCE NETWORK", "2003/06/17", "", "Retired", "Private", "", "
This agreement allows packages to create stub event
queue entries which are later processed by the Event Queue Daemon. The Event
Queue Daemon then creates and broadcasts HL7 messages.", "", "RGEQ", ""], ["2793", "CIRN CALLS TO RGED2", "Routine", "EXTENSIBLE EDITOR", "1999/04/06", "", "Retired", "Private", "", "
CIRN ROUTINE DBIA TO CALL RGED2\n", "", "RGED2", ""], ["2794", "CIRN AGREEMENT WITH EXTENSIBLE EDITOR FOR CALL TO RGEDS", "Routine", "EXTENSIBLE EDITOR", "1999/04/06", "", "Retired", "Private", "", "
Private Routine DBIA for call to PAINT^RGEDS", "", "RGEDS", ""], ["2795", "DBIA2795", "File", "SCHEDULING", "1999/04/23", "APPROVED", "Active", "Private", "404.51", "
The Clinical Reminder Package would like to reference
the following file directly :\n
TEAM #404.51 - Determine team's institution\n
As corresponding APIs are planned, this IA will be in effect until the
appropriate APIs are released.\n", "", "", ""], ["2796", "RGHLLOG line Tags", "Routine", "CLINICAL INFO RESOURCE NETWORK", "1999/04/06", "APPROVED", "Active", "Controlled Subscription", "", "
MPIF is requesting to utilize entry piotns EXC, START
and STOP of RGHLLOG to take advantage of the CIRN Exception Handling.", "", "RGHLLOG", ""], ["2797", "CIRN AGREEMENT WITH EXTENSIBLE EDITOR FOR CALLS TO RGED", "Routine", "EXTENSIBLE EDITOR", "1999/04/06", "", "Retired", "Private", "", "
CIRN AGREEMENT WITH EXTENSIBLE EDITOR FOR CALLS TO RGED", "", "RGED", ""], ["2798", "$$ADD VAFCPTAD(ARRAY)", "Routine", "REGISTRATION", "1999/04/06", "", "Retired", "Private", "", "
MPIF is requesting to add a patient to the patient file
via the call $$ADD^VAFCPTAD(ARRAY).\n
This call will happen when a list of potential matches has been displayed to
the user after requesting an ICN assignment from the MPI and the user has
selected from this list (list came from the MPI) a patient that would be new
to the local patient file.", "", "VAFCPTAD", ""], ["2799", "DBIA2799", "Routine", "HEALTH SUMMARY", "1999/04/16", "", "Retired", "Private", "", "", "", "GMTSLRSE", ""], ["2800", "DBIA2800", "File", "REGISTRATION", "1999/04/14", "", "Pending", "Private", "40.8", "
In order to accommodate multi-divisional sites, three
files have been modified to include references to the MEDICAL CENTER DIVISION
file (#40.8).\n
The files and fields are:\n
1. ESP DAILY JOURNAL FILE (#916)
field # .5 FACILITY (P40.8')\n
2. ESP POLICE REGISTRATION LOG FILE (#910.2)
field # .08 FACILITY (P40.8')\n
3. ESP EVIDENCE FILE (#910.8)
field # .05 FACILITY (P40.8')\n", "", "", ""], ["2801", "Notification/Alert Follow-up Access to GMRCEDIT", "Routine", "CONSULT/REQUEST TRACKING", "1999/04/16", "APPROVED", "Active", "Private", "", "
Allows subscribing package(s) access into the following
routine for Consult/Request Tracking notification/alert follow-up actions:\n
EN^GMRCEDIT", "", "GMRCEDIT", ""], ["2802", "Notification/Alert Follow-up Access to GMRCALRT", "Routine", "CONSULT/REQUEST TRACKING", "1999/04/16", "APPROVED", "Active", "Private", "", "
Allows subscribing package(s) access into the following
routine for Consult/Request Tracking notification/alert follow-up actions:\n
EN^GMRCALRT", "", "GMRCALRT", ""], ["2803", "DBIA2803", "File", "REGISTRATION", "1999/04/16", "", "Pending", "Private", "405", "
The Clinical Reminder Package would like to reference
the PATIENT MOVEMENT file #405 directly to identify current inpatients and
admissions within a date range for individual wards.", "", "", ""], ["2804", "DBIA2804", "File", "SCHEDULING", "2004/12/21", "APPROVED", "Active", "Private", "44", "
The Clinical Reminder Package would like to reference
the HOSPITAL LOCATION file #44 directly to determine the CLINIC GROUP and STOP
CODE NUMBER for a location and all patients with APPOINTMENTS at a clinic on a
given date.\n", "", "", ""], ["2805", "DBIA2805", "File", "INPATIENT MEDICATIONS", "1999/04/28", "APPROVED", "Active", "Private", "59.6", "
Pharmacy Benefits Management retrieves a data field
from\n
FILE: INPATIENT WARD PARAMETERS GLOBAL: ^PS(59.6, FILE #: 59.6 FIELD .03
DAYS UNTIL STOP DATE/TIME", "", "", ""], ["2806", "RAD/NUC MED PATIENT PROCEDURE STATUS", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1999/04/21", "APPROVED", "Active", "Private", "", "
CLIN^RAO7PC2 can be used to return information on the
most recent date that a list of procedures was completed for a given patient,
and if the procedure is currently in progress the appropriate date.
Information is also returned if a procedure was cancelled or if there is no
record of the procedure for the patient.", "", "RAO7PC2", ""], ["2807", "OE/RR sets ID WRITE node", "File", "1", "1999/04/25", "APPROVED", "Active", "Controlled Subscription", "1", "
This DBIA documents hard setting of the 'ID','WRITE'
node for a multiple in the ORDER DIALOG file. We would like to make this a
generic request, however, for OE/RR to set 'ID','WRITE' nodes as apporpriate.\n
The only alternative to hard setting this node is to send the entire DD of a
file out. Within a patch, sending the whole file can create an unnecessarily
large distribution which can cause us to move to an HFS file rather than
exporting the build via the National Patch Module.\n
The specific instance that generated this DBIA sends out post-installation
code in routine ORY46 as follows:
; -- Reset ID WRITE node for Items
S ^DD(101.412,0,"ID","WRITE")="N OR0,ORNM S OR0=^(0) I $P(OR0,U,2) S
ORNM=$P($G(^ORD(101.41,+$P(OR0,U,2),0)),U) D:$L(ORNM) EN^DDIOL(ORNM,,""?
10"")"", "", "", ""], ["2808", "DBIA2808", "File", "DRUG ACCOUNTABILITY", "1999/04/29", "APPROVED", "Active", "Private", "58.81", "\n
This is an open agreement between Drug Accountability and Controlled
Substances. The terms of this agreement are to allow Controlled
Substances access to any field in the DRUG ACCOUNTABILITY TRANSACTION
file (#58.81). The method of access can be either Direct Read/Write
or by using Filemanager.\n
The reason for this agreement is that prior to the release of Drug
Accountability 3.0, this file was the property of Controlled Substances.", "", "", ""], ["2809", "DBIA2809", "File", "DRUG ACCOUNTABILITY", "1999/04/29", "APPROVED", "Active", "Private", "58.811", "
This is an open agreement between Drug Accountability
and Controlled Substances. The terms of this agreement are to allow Controlled
Substances access to any field in the DRUG ACCOUNTABILITY ORDER file
(#58.811). The method of acccess can be either Direct Read/Write or by using
Filemanager.\n
The reason for this agreement is that prior to the release of Drug
Accountability 3.0, this file was the property of Controlled Substances.", "", "", ""], ["2810", "DBIA2810-A", "File", "SCHEDULING", "1999/04/29", "APPROVED", "Active", "Private", "404.57", "
The Clinical Reminder Package would like to reference
the following file directly :\n
TEAM POSITION #404.57 - Determine associated Clinic for Team Position\n
As corresponding APIs are planned, this IA will be in effect until the
appropriate APIs are released.\n", "", "", ""], ["2811", "DBIA2810-B", "File", "SCHEDULING", "1999/04/29", "APPROVED", "Active", "Private", "404.43", "
The Clinical Reminder Package would like to reference
the following files directly :\n
PATIENT TEAM POSITION ASSIGNMENT #404.43 - Determine Team Position\n
As corresponding APIs are planned, this IA will be in effect until the
appropriate APIs are released.\n", "", "", ""], ["2812", "TIU GET DOCUMENT COUNT", "Routine", "TEXT INTEGRATION UTILITIES", "1999/04/30", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIUSRVLV\n
^TMP("TIULIST",$J) may be killed before and after use.\n
Revision History
4/10/24: A new parameter (CNTSCND) was added to control if the API should
count documents that reference the Visit via the Secondary Visit field.
When the parameter is not passed in, it will behave as it did previously
(it will not include those document counts).", "", "TIUSRVLV", "2024/04/10"], ["2813", "TIU REMOVE TYPE AS IDENTIFIER FROM DOC DEF FILE (#8925.1)", "File", "1", "1999/04/30", "APPROVED", "Active", "Private", "8925.1", "
In initial test versions of TIU the .04 TYPE field of
the DOCUMENT DEFINITIONS FILE (#8925.1) was defined as an identifier. This
was changed prior to the release of TIU, but initial test sites still have the
.04 field defined as an identifier. To remove this relationship, TIU requests
permission to directly kill the Data Dictionary node defining this field as an
identifier, i.e. K ^DD(8925.1,0,"ID",.04). This kill will be performed during
the installation routine of TIU*1.0*38, which could not install properly
without removal of the identifier status.", "", "", ""], ["2815", "CPT FILE POINTERS", "File", "CPT/HCPCS CODES", "1999/05/05", "APPROVED", "Retired", "Supported", "81", "
Now covered by supported ICR #5408,CPT/HCPCS Procedure
File 81.This agreement will allow other packages' files to point to file #81,
CPT file.\n
Direct read of the "B" cross-reference will also be permitted.\n
Direct read of the "ACT" cross-reference will also be permitted.\n
This, along with DBIAs 1995-1997 will replace IA 10084, which will be
inactivated as of June, 2000.", "", "", ""], ["2816", "CPT MODIFIERS FILE", "File", "CPT/HCPCS CODES", "1999/05/05", "APPROVED", "Active", "Supported", "81.3", "
This will allow other packages to conduct FileMan
lookups and to point to the CPT MODIFIERS file #81.3.\n
Direct read of the "B", "BA" and "ACT" cross-references will be permitted.\n
Direct read of any node in file 81.3 by the Lexicon Environment Check Routines
will also be permitted.\n", "", "", ""], ["2817", "OE/RR looks at 'AD' x-ref in DG(40.8", "File", "REGISTRATION", "1999/05/17", "APPROVED", "Active", "Controlled Subscription", "40.8", "
OE/RR would like permission to reference the 'AD' x-ref
in file 40.8 (MEDICAL CENTER DIVISION). We need this to get the INSTITUTION
file pointers associated with a medical center. ALL^VASITE returns the
pointers to 40.8 and not file 4.", "", "", ""], ["2818", "OE/RR References to Alert Tracking File", "File", "KERNEL", "1999/05/17", "APPROVED", "Active", "Private", "8992.1", "
OE/RR utilizes the alert tracking file to obtain
information from existing alerts to process new alerts.\n
The routine ORB3REG directly accesses the XTV(8992.1 (Alert Tracking) global
to obtain information from existing alerts.", "", "", "2008/10/22"], ["2819", "ACCESS TO PTF RELEASE (#45.83) FILE", "File", "REGISTRATION", "1999/05/18", "APPROVED", "Active", "Private", "45.83", "
In one of the routines for the IB Billing Lag Time
Report (IBJDB11), the ^DGP(45.83 global for the PTF RELEASE file is being
accessed for the PTF Transmission Date.", "", "", "2018/04/09"], ["2820", "DBIA2820", "File", "REGISTRATION", "1999/05/18", "APPROVED", "Active", "Private", "45.84", "
In the IB Billing Lag Time Report, global ^DGP(45.84 is
being accessed for the PTF Transmission Date. In one of the routines for the
IB Billing Lag Time Report (IBJDB11), the ^DGP(45.84 global for the PTF CLOSE
OUT file is being accessed for the Release Date, which is used as the IEN of
the PTF RELEASE entry which has the PTF Transmission Date.", "", "", ""], ["2821", "DIALOG File", "Other", "1", "1999/08/09", "APPROVED", "Active", "Supported", ".84", "
To qantify supported DIALOG entries in the DIALOG file
#.84", "", "", ""], ["2822", "DBIA2822", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
This call is needed to determine if data passed to IB
is from the OUTPATIENT ENCOUNTER file or from PCE.", "", "SDOEUT", ""], ["2823", "DBIA2823", "File", "KERNEL", "1999/05/19", "APPROVED", "Active", "Private", "8932.1", "
IB is using a pointer to the Person Class file
(#8932.1) to define types of providers.", "", "", ""], ["2824", "DBIA2824", "File", "KERNEL", "1999/05/24", "APPROVED", "Active", "Private", "200", "\n\n
Nursing requires direct global read access to the following fields in the New
Person (#200) file which contain the telephone data used in the nursing End of
Shift Report:\n
.131 PHONE (HOME)
.132 OFFICE PHONE
.133 PHONE #3
.134 PHONE #4
.135 COMMERCIAL PHONE
.136 FAX NUMBER
.137 VOICE PAGER
.138 DIGITAL PAGER", "", "", ""], ["2825", "GMTSADH5", "Routine", "HEALTH SUMMARY", "2000/07/19", "APPROVED", "Active", "Private", "", "
These are the API's used to get information for the
Adhoc Health Summary.", "", "GMTSADH5", ""], ["2828", "RETURN ACTIVE ORDERS TO BCMA", "Routine", "INPATIENT MEDICATIONS", "1999/05/25", "APPROVED", "Active", "Private", "", "
The entry point EN^PSJBCMA is provided by Inpatient
Medications package to return patient active orders to Bar Code Med Admin to
be used in administering medications at patient's bedside.", "", "PSJBCMA", ""], ["2829", "RETURN DETAIL INFO ON PATIENT'S ORDER FOR BCMA", "Routine", "INPATIENT MEDICATIONS", "1999/05/25", "APPROVED", "Active", "Controlled Subscription", "", "
The entry point EN^PSJBCMA1 is provided by Inpatient
Medications package to return the detail information on a patient's order for
Bar Code Med Admin to use.", "", "PSJBCMA1", ""], ["2830", "DBIA2830", "Routine", "INPATIENT MEDICATIONS", "1999/05/25", "APPROVED", "Active", "Private", "", "
The entry point EN^PSJBCMA2 is provided by Inpatient
Medications package to return a patient order's activity logs for Bar Code Med
Admin to use.", "", "PSJBCMA2", ""], ["2831", "Calls to ORQPT2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/06/01", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA is a controlled subscription for calls to
routine ORQPT2.", "", "ORQPT2", "2018/07/06"], ["2832", "Calls to TIUSRV", "Routine", "TEXT INTEGRATION UTILITIES", "1999/06/01", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will act as a controlled subscription for
calls to TIUSRV.", "", "TIUSRV", ""], ["2833", "Calls to TIUBR1", "Routine", "TEXT INTEGRATION UTILITIES", "1999/06/01", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will act as a controlled subscription for
calls to TIUBR1.", "", "TIUBR1", ""], ["2834", "Calls to TIUSRVLO", "Routine", "TEXT INTEGRATION UTILITIES", "1999/06/01", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will act as a controlled subscription for
calls to TIUSRVLO.", "", "TIUSRVLO", ""], ["2835", "Access to file 101.43", "File", "ORDER ENTRY/RESULTS REPORTING", "1999/06/01", "APPROVED", "Active", "Controlled Subscription", "101.43", "
This is to document the use of the Orderable Items file
(101.43) in CPRS by the Laboratory Interface.", "", "", ""], ["2836", "Consults use of S.CSLT and S.PROC x-refs", "File", "ORDER ENTRY/RESULTS REPORTING", "1999/06/01", "APPROVED", "Active", "Private", "101.43", "
This is a private DBIA between Consults and OE/RR to
allow use of teh S.CSLT and S.PROC x-refs on the ORDERABLE ITEMS file.", "", "", ""], ["2837", "RPC Broker Programmatic Login", "Other", "RPC BROKER", "1999/06/10", "", "Withdrawn", "Private", "", "
The Event Monitor Service at VAPSHCS monitors incoming
HL7 messages so as to implement automated medical alerts and reminders. The
application must run as a Windows NT Service in unattended mode. The Event
Monitor Service extensively utilizes RPC Broker when implementing medical
alerts. As a consequence, I am requesting to use the undocumented "silent
login" feature released in XWB*1.1*4 until such time when an official Broker
patch supporting this functionality is released.", "", "", ""], ["2838", "RPC Broker Silent Feature", "Other", "RPC BROKER", "1999/06/01", "", "Withdrawn", "Supported", "", "
This request is for a new broker "silent running"
feature. This feature, when enabled, would dictate that under no
circumstances should the broker display message dialogs to the user. A
possible method of accomplishing this task would be to add an RPC Broker
boolean property, that, when set to true, disables the display of all user
dialogs. It is suggested that when the silent property is set, that the the
broker, as an alternative to displaying a message, merely throw an equivalent
silent exception. This feature will allow use of the broker by Windows NT
services that need to run in unattended mode.", "", "", ""], ["2839", "CPRS USE OF XPAR MENU", "Other", "TOOLKIT", "1999/06/03", "APPROVED", "Active", "Private", "", "
CPRS is requesting the ability to attach the XPAR MENU
TOOLS menu to the CPRS Configuration (IRM) menu. This will allow IRM users to
get to the tools menu for XPAR when editing using other CPRS-related IRM
tools.", "", "", ""], ["2840", "Use of TIU ACTION CWAD DISPLAY", "Other", "TEXT INTEGRATION UTILITIES", "1999/06/04", "APPROVED", "Active", "Controlled Subscription", "", "
The TIU ACTION CWAD DISPLAY protocol is exported with
the TIU package. This controlled subscription DBIA will allow other packages
to utilize this protocol.", "", "", ""], ["2841", "TIU MEDICATION OBJECTS READ DRUG FILE", "File", "PHARMACY DATA MANAGEMENT", "1999/09/15", "APPROVED", "Retired", "Private", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's.\n
TIU's medication objects now allow for the sorting of medications by drug
class, including pending orders for medications that may not yet have a
dispense drug. They also allow for the exclusion of supply items from
medication lists, if desired. To accomodate this functionality, TIU requests
direct global read access to the following pharmacy file:\n
^PSDRUG( - DRUG FILE (#50):
"B" cross reference
"ASP" cross reference
Node 0, piece 2 - VA CLASSIFICATION FIELD (#2).
Node 0, piece 3 - DEA, SPECIAL HDLG FIELD (#3)", "", "", ""], ["2842", "DBIA2842", "Routine", "ORDER ENTRY/RESULTS REPORTING", "1999/06/09", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORX8", ""], ["2843", "DBIA2843", "File", "ORDER ENTRY/RESULTS REPORTING", "1999/06/09", "APPROVED", "Active", "Controlled Subscription", "101.43", "
This agreement allows read access to the Orderable
Items file #101.43.", "", "", "2015/06/22"], ["2844", "DBIA 2844", "File", "OUTPATIENT PHARMACY", "1999/06/14", "APPROVED", "Active", "Private", "52.41", "
This agreement gives the Pharmacy Data Management
package access to the PLACER NUMBER (#.01) field in the PENDING OUTPATIENT
ORDERS (#52.41) file. This access will be needed every time an action is
taken on a pending Outpatient order, for the purpose of locking the order in
Outpatient Pharmacy and in Computerized Patient Record System (CPRS).", "", "", "2020/01/29"], ["2845", "DBIA 2845", "File", "OUTPATIENT PHARMACY", "1999/06/14", "APPROVED", "Active", "Private", "52", "
This agreement gives the Pharmacy Data Management
package access to the PLACER ORDER # (#39.3) field in the PRESCRIPTION (#52)
file. This access will be needed every time an action is taken on a
prescription, for the purpose of locking the order in Outpatient Pharmacy and
in Computerized Patient Record System (CPRS).", "", "", "2020/01/29"], ["2846", "DBA2846", "Routine", "KERNEL", "1999/06/14", "APPROVED", "Active", "Private", "", "
Broker uses $$BAT^XUPARAM in two situations to retrieve
the value of the Broker Activity Timeout, which is stored in the Kernel System
Parameters file: 1)to set the timeout on READs waiting for client requests.
2) to pass the tiemout value back to the client in order to determine the
frequency of polling from client to server.", "", "XUPARAM", ""], ["2847", "ALLOW DIE CALL WITHIN ANOTHER DIE", "Routine", "1", "1999/06/16", "APPROVED", "Active", "Private", "", "
This integration agreement is between IFCAP and
FileMan.\n
IFCAP is calling templates through a DIE programmer call. In the templates a
routine is called. Within that routine a call is made to both DIC and DIE
programmer calls to add a new sub-record entry and fill in additional data.
This second DIE call is a recursive call. FileMan needs to save a group of
variables to prevent the second DIE call from interfering with the first DIE
call, the one handling the template.\n
To properly call DIE the following variables need to be NEWed.
DIAA,I,J,X,DO,DC,DA,DE,DG,DIE,DR,DIC,D,D0,D1,D2,D3,D4,D5,D6,DI,DH,
DIA,DICR,DK,DIK,DL,DLAYGO,DM,DP,DQ,DU,DW,DIEL,DOV,DIOV,DIEC,DB,
DV,DIFLD\n
Any place within IFCAP that a recursive call to DIC/DIE needs to be done will
be allowed by this agreement.\n
This intregration agreement will stay in effect until FileMan DIC and DIE
programmer calls become recursive.", "", "", ""], ["2848", "GETALL API CALL", "Routine", "SCHEDULING", "1999/06/16", "APPROVED", "Active", "Supported", "", "", "", "SCAPMCA", ""], ["2849", "Use of ORDERS file (#100)", "File", "ORDER ENTRY/RESULTS REPORTING", "1999/06/18", "APPROVED", "Active", "Controlled Subscription", "100", "", "", "", ""], ["2850", "TIU use of SDAM1", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
TIU calls $$STATUS^SDAM1 to retrieve the status of an
appointment.", "", "SDAM1", ""], ["2851", "TIU use of SD(409.63,'ACO',1,STATUS)", "File", "SCHEDULING", "2004/08/05", "APPROVED", "Active", "Private", "409.63", "
TIU uses a global read of ^SD(409.63,"ACO",1,STATUS)
cross-reference on the 'Check Out Allowed?' field (#.06) of the Appointment
Status file (#409.63) to determine if the appointment is allowed for
check-out.\n
STATUS := appt status as determined by $$STATUS^SDAM1.", "", "", ""], ["2852", "Setting ID node (file #52)", "File", "1", "2003/06/10", "", "Retired", "Private", "52", "
Permission to re-set an ID node in file 52.", "", "", ""], ["2853", "FILE USE OVERLAP", "Other", "INCOME VERIFICATION MATCH", "1999/06/24", "APPROVED", "Active", "Private", "", "
Since IVM has custody of the numberspace from 300 to
304, the following files are delegated to the custody of INCOME VERIFICATION
NAT'L DB\n
300.1 IVM FACILITY 300.11 VETERANS ID VERIFICATION ACCESS 300.111
DEATH TRANSMISSIONS 300.113 AAC TRANSMISSIONS STATISTICS 300.114 IVM
AUSTIN TRANSMISSION STATUS 300.12 IVM MASTER CLIENT 300.121 IVM
ADJUDICATION 300.122 IVM VERIFIED INSURANCE 300.124 IVM CLOSED CASE
CODES 300.13 IVM CLIENT INCOME 300.1311 SITE COMPLETED MT STATISTICS
300.132 ENROLLMENT 300.133 IVM REVIEW RECORDS 300.15 SSA EARNINGS
REPORT TYPE 300.16 IRS DOCUMENT TYPE - UNEARNED INCOME 300.17 IVM
REFERENCE 300.18 IVM EMPLOYER 300.19 FINANCIAL INSTITUTION 300.2
IVM ELIGIBILITY STATUS 300.21 IVM HL7 SEGMENTS USED 300.22 IRS SUB
DOCUMENT TYPE 300.3 IVM EQUIPMENT 300.4 IVM DEVICE TYPE 300.6
IVM LOCATION 300.7 IVM ADDRESS FILE 300.8 IVM ADJUDICATION
LETTERS/FORMS 300.899 IVM CASE ASSIGNMENT 300.9 IVM COUNTY CODES
300.999 IVM CASE STATUS 301.1 DCD FINANCIAL/INCOME TEST DATA 301.11
DCD LETTERS 301.12 IVM BILLING TRANSACTIONS 301.13 IVM ELIGIBILITY
THRESHOLDS 301.15 PRIORITIZATION REASONS 301.2 DCD CORRESPONDENCE
301.3 DCD CONTACT REPRESENTATIVE/CASE ASSIGNMENT 301.4 DCD
DEPENDENTS", "", "", ""], ["2854", "DBIA2854", "File", "PHARMACY DATA MANAGEMENT", "1999/06/24", "APPROVED", "Active", "Private", "59.7", "
Pharmacy Benefits Managment requests the usage of the
PSU PBM JOB field (#90) in the PHARMACY SYSTEM file (#59.7) for monitoring the
status of current and previous extracts of the PSU PBM software.\n", "", "", ""], ["2855", "RPCBroker.AccessVerifyCodes", "Remote Procedure", "RPC BROKER", "1999/06/24", "", "Withdrawn", "Supported", "", "
I am using this call in the RPC Broker for a "silent
login" to VistA for an Active Server Page DLL component.", "", "", ""], ["2856", "DBIA2856", "Routine", "MAILMAN", "1999/06/25", "APPROVED", "Active", "Private", "", "\n
AR $Orders thru ^XMB(3.9,"B",XMSUBJ,XMZ) to retrieve mail messages.
AR references a messages first line in global ^XMB(3.9,XMZ,2,1,0).
AR calls D KILL^XMA32A(XMZ,.XMKILL,XMABORT) to delete a message.", "", "XMA32A", ""], ["2857", "XUS GET USER INFO", "Remote Procedure", "KERNEL", "1999/06/29", "", "Active", "Controlled Subscription", "", "
This rpc is used by BROKER to maintain a User object in
the Delphi environment.", "XUS GET USER INFO", "", ""], ["2858", "DBIA2858", "File", "PHARMACY DATA MANAGEMENT", "2000/02/17", "APPROVED", "Active", "Controlled Subscription", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.", "", "", ""], ["2859", "TAXID FIELDS IN 440", "File", "IFCAP", "1999/07/21", "APPROVED", "Active", "Private", "440", "
Accounts Receivable needs to pull data from fields 38
and 39 in IFCAP file 440. This is necessary to place the Tax ID number on the
TOP (Treasury Offset Program) documents.", "", "", ""], ["2860", "DBIA2860-A", "File", "MAILMAN", "1999/07/07", "APPROVED", "Active", "Private", "3.9", "
The Radiology/Nuclear Medicine package requests
permission to lookup the DATE ENTERED value for a message in file 3.9 of the
Mailman package.", "", "", ""], ["2861", "DBIA2860-B", "File", "MAILMAN", "1999/07/07", "APPROVED", "Active", "Private", "3.6", "
The Radiology/Nuclear Medicine package requests
permission to lookup the IEN of a bulletin and the ien of the mail group
that's linked to the same bulletin.", "", "", ""], ["2862", "DBIA2860-C", "File", "MAILMAN", "1999/07/07", "APPROVED", "Active", "Private", "3.8", "
The Radiology/Nuclear Medicine package requests
permission to lookup the type of a mailgroup.", "", "", ""], ["2863", "Calls to TIULE", "Routine", "TEXT INTEGRATION UTILITIES", "1999/07/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIULE", "", "TIULE", "2017/04/24"], ["2864", "DBIA2864", "Routine", "TEXT INTEGRATION UTILITIES", "1999/07/12", "APPROVED", "Active", "Controlled Subscription", "", "
This call evaluates whether the specified patient has
any postings (i.e., (C)risis Notes, Clinical (W)arnings, (A)llergies, or
Advanced (D)irectives on file, and returns a list of such documents, including
the dates and times on which addenda may have been entered for them.\n
Note that the existence of an Advance Directive posting does NOT necessarily
indicate that the patient has an Advance Directive. That an Advance Directive
exists can only be determined by reading the text of the 'D' postings, which
may (or may not) indicate that a Directive exists,", "", "TIUPP3", ""], ["2865", "DBIA2865", "Routine", "TEXT INTEGRATION UTILITIES", "1999/07/12", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point (CONTEXT) allows the calling
application to fetch lists of TIU Documents that satisfy various criteria
(e.g., All signed, unsigned by author, uncosigned notes, signed by author,
signed by date range).", "", "TIUSRVLO", ""], ["2866", "DDR DELETE ENTRY", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR DELETE ENTRY remote procedure call. This request is
necessary since FMDC is now a separate package with a different namespace and
still needs to access the DDR remote procedure calls which are the basis for
the functioning of the FMDC components.", "DDR DELETE ENTRY", "", ""], ["2867", "DDR FILER", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR FILER remote procedure call. This request is necessary
since FMDC is now a separate package with a different namespace and still
needs to access the DDR remote procedure calls which are the basis for the
functioning of the FMDC components.", "DDR FILER", "", ""], ["2868", "DDR FIND1", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR FIND1 remote procedure call. This request is necessary
since FMDC is now a separate package with a different namespace and still
needs to access the DDR remote procedure calls which are the basis for the
functioning of the FMDC components.", "DDR FIND1", "", ""], ["2869", "DDR FINDER", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR FINDER remote procedure call. This request is necessary
since FMDC is now a separate package with a different namespace and still
needs to access the DDR remote procedure calls which are the basis for the
functioning of the FMDC components.", "DDR FINDER", "", ""], ["2870", "DDR GET DD HELP", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR GET DD HELP remote procedure call. This request is
necessary since FMDC is now a separate package with a different namespace and
still needs to access the DDR remote procedure calls which are the basis for
the functioning of the FMDC components.", "DDR GET DD HELP", "", ""], ["2871", "DDR GETS ENTRY DATA", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR GETS ENTRY DATA remote procedure call. This request is
necessary since FMDC is now a separate package with a different namespace and
still needs to access the DDR remote procedure calls which are the basis for
the functioning of the FMDC components.", "DDR GETS ENTRY DATA", "", ""], ["2872", "DDR LISTER", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR LISTER remote procedure call. This request is necessary
since FMDC is now a separate package with a different namespace and still
needs to access the DDR remote procedure calls which are the basis for the
functioning of the FMDC components.", "DDR LISTER", "", ""], ["2873", "DDR LOCK/UNLOCK NODE", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR LOCK/UNLOCK NODE remote procedure call. This request is
necessary since FMDC is now a separate package with a different namespace and
still needs to access the DDR remote procedure calls which are the basis for
the functioning of the FMDC components.", "DDR LOCK/UNLOCK NODE", "", ""], ["2874", "DDR VALIDATOR", "Remote Procedure", "1", "1999/07/13", "APPROVED", "Active", "Private", "", "
The Filemanager Delphi Components (FMDC) package
requests a private integration agreement with the FileManager package for
access to the DDR VALIDATOR remote procedure call. This request is necessary
since FMDC is now a separate package with a different namespace and still
needs to access the DDR remote procedure calls which are the basis for the
functioning of the FMDC components.", "DDR VALIDATOR", "", ""], ["2875", "DBIA2875", "File", "MENTAL HEALTH", "1999/07/14", "APPROVED", "Active", "Controlled Subscription", "601", "", "", "", ""], ["2876", "DBIA2876", "Routine", "TEXT INTEGRATION UTILITIES", "1999/07/21", "APPROVED", "Active", "Controlled Subscription", "", "
APIs for Document Definition File (#8925.1)\n
Revisions: 9/13/23: Component $$BOIL^TIUSRVD added for use by OE/RR", "", "TIUSRVD", "2023/09/13"], ["2877", "DBIA2877", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "1999/12/06", "APPROVED", "Active", "Supported", "", "
Either EN3^RAO7PC3 or EN30^RAO7PC3 can be used to
return an entire Radiology/NM report, the same report that is automatically
e-mailed to the requesting physician when a report has been verified.", "", "RAO7PC3", ""], ["2878", "DELETE TRIGGER X-REF IN FILE 6926.01 FIELD .01", "File", "1", "1999/07/28", "APPROVED", "Active", "Private", "", "
This IA permits patch EN*7*62 to delete the TRIGGER
cross-reference (#2) of field #.01 in subfile #6926.01. Code similar to the
following will be placed in a pre-install routine of the patch to perform the
deletion.\n
N DA,DIK
S DIK="^DD(6926.01,.01,1," ;this is the root of "xref multiple"
S DA(2)=6926.01,DA(1)=.01,DA=2 ;DA(2) = subfile#
;DA(1) = field#
;DA = xref#
D ^DIK ;this deletes the xref definition\n
Patch EN*7*62 will bring in a new #2 cross-reference (regular, whole-file) on
the .01 field of #6926.01 during the install. The cross-reference deletion
performed during the pre-install will ensure that all the trigger logic is
completely removed.", "", "", ""], ["2879", "DBIA2879", "File", "PHARMACY DATA MANAGEMENT", "1999/07/28", "APPROVED", "Active", "Private", "51.1", "", "", "", ""], ["2880", "DBIA2880", "File", "PHARMACY DATA MANAGEMENT", "1999/07/28", "APPROVED", "Active", "Private", "50.7", "", "", "", ""], ["2881", "DBIA2881", "Routine", "SCHEDULING", "1999/07/29", "", "Pending", "Supported", "", "
Contains the supported reference to routine SCMCHLZ for
the supported API to be released with PCMM patch SD*5.3*177.", "", "SCMCHLZ", ""], ["2882", "DBIA2882", "Routine", "KERNEL", "1999/08/04", "APPROVED", "Active", "Controlled Subscription", "", "
XUSRB contains some API's that can be used by other
application to check user access.", "", "XUSRB", ""], ["2883", "DBIA2883", "File", "DSS - DECISION SUPPORT SYSTEM EXTRACTS", "1999/08/10", "APPROVED", "Active", "Private", "727.5", "
The purpose of DBIA #2883 is to allow the VistA Mental
Health package to perform direct global reads on the DSS MH TESTS file
(#727.5).", "", "", ""], ["2884", "DBIA2884", "Routine", "MENTAL HEALTH", "1999/08/10", "APPROVED", "Active", "Private", "", "
The purpose of DBIA #2884 is to allow the VistA DSS
Extracts package to call routine YSDSS at tag UPD.\n
The call to UPD^YSDSS will return Mental Health data to be placed in the DSS
Mental Health extract.", "", "YSDSS", ""], ["2885", "DBIA2885", "File", "DSS - DECISION SUPPORT SYSTEM EXTRACTS", "1999/08/10", "APPROVED", "Active", "Private", "727.812", "
The purpose of DBIA #2885 is to allow the VistA Mental
Health package to place data directly into the ^ECX(727.812, global. This
global is the storage location of the DSS MENTAL HEALTH EXTRACT file
(#727.812).", "", "", ""], ["2886", "Supported DataBase Server DIALOG Numbers", "Other", "1", "1999/08/11", "", "Withdrawn", "Supported", "", "
The listed components are the supported DIALOG numbers
that are associated with the DataBase Server calls and maybe used with the
following supported DIALOG calls:\n
BLD^DIALOG $$EZBLD^DIALOG MSG^DIALOG", "", "", ""], ["2887", "Application Parameter Inquire", "Routine", "HEALTH LEVEL SEVEN", "2003/09/30", "APPROVED", "Active", "Supported", "", "
This public API returns the Mail Group and the
"active/inactive" flag for an HL7 Application.", "", "HLCS2", ""], ["2888", "DBIA2888", "File", "ONCOLOGY", "1999/08/13", "APPROVED", "Active", "Private", "165.5", "
The Health Summary package has permission to extract
and display the following data from the ONCOLOGY PRIMARY (165.5) file:\n
3 DATE DX
20 ICDO-TOPOGRAPHY
22 HISTOLOGY
24 GRADE/DIFFERENTIATION
29 SIZE OF TUMOR
37.1 CLINICAL T
37.2 CLINICAL N
37.3 CLINICAL M
38 CLINICAL STAGE GROUP
85 PATHOLOGIC T
86 PATHOLOGIC N
87 PATHOLOGIC M
88 PATHOLOGIC STAGE GROUP
58.1 NON CANCER-DIRECTED SURGERY
58.3 NON CANCER-DIRECTED SURG DATE
58.2 SURGERY OF PRIMARY SITE
50 SURGERY OF PRIMARY SITE DATE
51.2 RADIATION
51 RADIATION DATE
442 REGIONAL DOSE:cGy
125 RADIATION TREATMENT VOLUME
127 INTENT OF RADIATION
128 RADIATION COMPLETION STATUS
53.2 CHEMOTHERAPY
53 CHEMOTHERAPY DATE
54.2 HORMONE THERAPY
54 HORMONE THERAPY DATE
55.2 IMMUNOTHERAPY (BRM)
55 IMMUNOTHERAPY DATE
346 PROTOCOL ELIGIBILITY STATUS
560 PROTOCOL PARTICIPATION
91 ABSTRACT STATUS", "", "", ""], ["2889", "DBIA2889", "Routine", "MENTAL HEALTH", "1999/08/16", "APPROVED", "Active", "Supported", "", "", "", "YTAPI", ""], ["2890", "DBIA2890", "Remote Procedure", "MENTAL HEALTH", "1999/08/16", "", "Pending", "Supported", "", "
This RPC returns all psychological test administrations
for a specified patient during a specified time period. No scoring is
returned.", "", "", ""], ["2891", "DBIA2891", "Routine", "MENTAL HEALTH", "1999/08/19", "APPROVED", "Active", "Supported", "", "
This API returns all scoring information for a
specified patient given a specified administration date for a specified test
or instrument. User must have adequate privileges to receive this information
(i.e. often the YSP KEY).", "", "YTAPI2", ""], ["2892", "DBIA2892", "Remote Procedure", "MENTAL HEALTH", "1999/08/19", "", "Pending", "Supported", "", "
This RPC returns all scoring information for a
specified patient given a specified administration date for a specified test
or instrument. User must have adequate privileges to receive this information
(i.e. often the YSP KEY).", "", "", ""], ["2893", "DBIA2893", "Routine", "MENTAL HEALTH", "1999/08/19", "APPROVED", "Active", "Supported", "", "
This API allows saving of patient responses to a test
or interview in the PSYCH INSTRUMENT PATIENT file (#601.2). The patient ien,
the test code, and administration date is required along with the responses.
All responses are checked for validity. No scoring is returned but successful
addition to the PSYCH INSTRUMENT PATIENT file (#601.2) is indicated.", "", "YTAPI1", ""], ["2894", "DBIA2894", "Remote Procedure", "MENTAL HEALTH", "1999/08/19", "", "Pending", "Supported", "", "
This RPC allows saving of patient responses to a test
or interview in the PSYCH INSTRUMENT PATIENT file (#601.2). The patient ien,
the test code, and administration date is required along with the responses.
All responses are checked for validity. No scoring is returned but successful
addition to the PSYCH INSTRUMENT PATIENT file (#601.2) is indicated.", "", "", ""], ["2895", "DBIA2895", "Routine", "MENTAL HEALTH", "1999/08/19", "APPROVED", "Active", "Supported", "", "", "", "YTAPI3", ""], ["2896", "DBIA2896", "Routine", "MENTAL HEALTH", "2003/06/04", "APPROVED", "Active", "Supported", "", "
This API returns the GAF scores for a specified
patient. It can be constrained by both date range and occurrence limit. Please
note that data for this API comes from the DIAGNOSTIC RESULTS - MENTAL HEALTH
file (#627.8).", "", "YSGAFAPI", ""], ["2897", "DBIA2897", "Routine", "IFCAP", "1999/08/25", "APPROVED", "Active", "Private", "", "
Routine PRCH7D is used as an interface between
Prosthetics Package, Administrative Home Oxygen Module and IFCAP for purchase
card transactions.", "", "PRCH7D", ""], ["2898", "Add ICN via LOCAL MPIFQ0", "Routine", "MASTER PATIENT INDEX VISTA", "1999/08/25", "", "Retired", "Private", "", "
This private agreement allows the PIMS software to call
the LOCAL^MPIFQ0 routine to create a local ICN and CMOR when adding a Treating
Facility for a patient that does not have an ICN.", "", "MPIFQ0", ""], ["2899", "DBIA2899", "File", "KERNEL", "1999/08/26", "", "Pending", "Private", "19", "
The PCMM package would like to do the following in
conjunction with a KIDs install:
o Look-up a PCMM Kernel menu option - Use ^DIC
o Rename option - Use FILE^DIE", "", "", ""], ["2900", "DBIA2900", "File", "HEALTH LEVEL SEVEN", "1999/08/26", "APPROVED", "Active", "Private", "771", "
A one time update to set the site number in HL7's table
for the Application entry in file 771.", "", "", ""], ["2901", "GMRCASF", "Routine", "CONSULT/REQUEST TRACKING", "1999/08/31", "APPROVED", "Active", "Private", "", "
This DBIA will allow calling routine GMRCASF.", "", "GMRCASF", ""], ["2902", "TIU/Health Summary by Visit Date", "Routine", "TEXT INTEGRATION UTILITIES", "1999/09/01", "APPROVED", "Active", "Controlled Subscription", "", "
The routine TIULAPIC controls the branching for
extracting documents by occurrence, date or type for a given patient.", "", "TIULAPIC", ""], ["2903", "CHANGING WRITE IDENTIFIERS", "Other", "1", "1999/09/08", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Accounts
Receivable package to change the write identifiers on the AR TRANSACTION File
#433.\n", "", "", ""], ["2905", "TIU MEDICATION OBJECTS READ PHARMACY FILE", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
TIU's medication objects now allow for the sorting of
medications by drug class, including pending orders for medications that may
not yet have a dispense drug. They also allow for the exclusion of supply
items from medication lists, if desired. To accomodate this functionality,
TIU requests direct global read access to the following pharmacy file:\n
^PSRX( - PRESCRIPTION FILE (#52)
Node 0, piece 6 - DRUG FIELD (#6)
Node "OR1", piece 1 - PHARMACY ORDERABLE ITEM FIELD (#39.2)\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2906", "TIU MEDICATION OBJECTS READ PHARMACY FILE", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52.41", "
TIU's medication objects now allow for the sorting of
medications by drug class, including pending orders for medications that may
not yet have a dispense drug. They also allow for the exclusion of supply
items from medication lists, if desired. To accomodate this functionality,
TIU requests direct global read access to the following pharmacy file:\n
^PS(52.41, - PENDING OUTPATIENT ORDERS FILE (#52.41)
Node 0, piece 8 - PHARMACY ORDERABLE ITEM FIELD (#8)
Node 0, piece 9 - DRUG FIELD (#11)\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["2907", "TIU MEDICATION OBJECTS READ PHARMACY FILE", "File", "INPATIENT MEDICATIONS", "1999/09/15", "APPROVED", "Active", "Controlled Subscription", "53.1", "
TIU's medication objects now allow for the sorting of
medications by drug class, including pending orders for medications that may
not yet have a dispense drug. They also allow for the exclusion of supply
items from medication lists, if desired. To accommodate this functionality,
TIU requests direct global read access to the following pharmacy file:\n
^PS(53.1, - NON-VERIFIED ORDERS FILE (#53.1)
Node .2, piece 1 - ORDERABLE ITEM FIELD (#108)\n
^PS(53.1,DA,1 - DISPENSE DRUG SUB-FILE (#53.11)
Node 0, piece 1 - DISPENSE DRUG FIELD (#.01)", "", "", ""], ["2908", "TIU MEDICATION OBJECTS READ PHARMACY FILE", "File", "PHARMACY DATA MANAGEMENT", "1999/09/15", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any
additional code that utilizes this Integration Agreement. APIs have been
created that can be used in place of any code needing to make use of this
agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code
that currently utilizes this Integration Agreement must be converted to
use the new API's. If any part of this Integration Agreement cannot be
satisfied with the APIs, please contact the PRE development team mail
group at EMAIL GROUP DEV using Microsoft Outlook.\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy
packages are still allowed to utilize this agreement past the expiration
date of December 31, 2006. TIU's medication objects now allow for the
sorting of medications by drug class, including pending orders for medications
that may not yet have a dispense drug. They also allow for the exclusion of
supply items from medication lists, if desired. To accomodate this
functionality, TIU requests direct global read access to the following
pharmacy file:\n
^PS(55, - PHARMACY PATIENT FILE (#55)
^PS(55,DFN,5, - UNIT DOSE SUB-FILE (#55.06)
Node .2, piece 1 - ORDERABLE ITEM FIELD (#108)\n
^PS(55,DFN,5,DA,1 - DISPENSE DRUG SUB-FILE (#55.07)
Node 0, Piece 1 - DISPENSE DRUG FIELD (#.01)\n
^PS(55,DFN,"IV", - IV SUB-FILE (#55.01)
Node .2, piece 1 - ORDERABLE ITEM FIELD (#130)\n
^PS(55,DFN,"IV",DA,"AD", - ADDITIVE SUB-FILE (#55.02)
Node 0, piece 1 - ADDITIVE FIELD (#.01)", "", "", ""], ["2909", "TIU MEDICATION OBJECTS READ PHARMACY FILE", "File", "PHARMACY DATA MANAGEMENT", "1999/09/15", "APPROVED", "Retired", "Private", "52.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's.\n
TIU's medication objects now allow for the sorting of medications by drug
class, including pending orders for medications that may not yet have a
dispense drug. They also allow for the exclusion of supply items from
medication lists, if desired. To accomodate this functionality, TIU requests
direct global read access to the following pharmacy file:\n
^PS(52.6, - IV ADDITIVES FILE (#52.6)
Node 0, piece 2 - GENERIC DRUG FIELD (#1)", "", "", ""], ["2910", "Delete Read Protection on Files", "File", "1", "1999/10/05", "APPROVED", "Active", "Private", "1", "
E3R PSN-4-12347 asked that the read protection on files
related to National Drug File be removed. To meet this request, NDF requests
a one time agreement with VA FileMan to KILL the global nodes
^DIC(50.6,0,"RD"), ^DIC(50.64,0,"RD"), ^DIC(50.67,0,"RD"), and
^DIC(50.68,0,"RD")", "", "", ""], ["2911", "TREATING FACILITY LIST (#391.91): relationship with CIRN PD", "File", "REGISTRATION", "2000/01/13", "APPROVED", "Active", "Private", "391.91", "
The CIRN PD package would like to use the TREATING
FACILITY (#391.91) file for the following functions:\n
1) Loop through "B" cross- reference in the TREATING FACILITY (#391.91) file
getting the INSTITUTION (#4) file IEN or the (#.02) INSTITUTION [2P] field.\n
2) Take each IEN and translate into a HL LOGICAL LINK (#870) file entry\n
3) Using the known SUBSCRIPTION CONTROL IEN, call GET^HLSUB, to get the
DESTINATIONS for that IEN.\n
4) Compare the logical links identified by the entries in the TREATING
FACILITY to the links returned by GET^HLSUB. If there is not a one-to-one
relationship add an entry to the SUBSCRIPTION CONTROL (#774) file for the
missing entry. The missing entry is added using $$ACT^HLSUB and UPD^HLSUB.\n
5) Utilize the "APAT" cross-reference to determine the internal entry number
(ien) of the TREATING FACILITY LIST (TFL) record. If an ien does not exist,
we add to the TFL file.\n
6) Utilize the "AINST" cross-reference to check for patients within a given
facility.\n
7) A direct global read for the DATE LAST TREATED field (#.03 ; node: 0 ;
piece: 3) to determine if the data on file is valid.\n
8) Write access with FileMan for the following fields: DATE LAST TREATED and
ADT/HL7 EVENT REASON (field: .07 ; node: 0 ; piece: 7). ADT/HL7 EVENT REASON
is a pointer data type pointing to the ADT/HL7 EVENT REASON (#391.72) file.\n
At this time we are only concerned about missing subscriptions and not missing
treating facilities.", "", "", ""], ["2912", "DBIA2912", "Routine", "HEALTH SUMMARY", "1999/09/15", "", "Pending", "Controlled Subscription", "", "\n\n
Network Health Exchange would like to be able to call GMTS1 at entry point
EN^GMTS1 to extract data from Health Summary.\n", "", "GMTS1", ""], ["2913", "SUPPORT TIU'S UPLOAD OF C&P EXAMS", "File", "AUTOMATED MED INFO EXCHANGE", "1999/09/20", "APPROVED", "Active", "Private", "396.3", "
This DBIA, along with #2914 and #2915, is intended to
support the upload of Compensation and Pension Exam Results into AMIE, using
TIU's batch upload facility.", "", "", ""], ["2914", "SUPPORT TIU'S UPLOAD OF C&P EXAMS", "File", "AUTOMATED MED INFO EXCHANGE", "1999/09/20", "APPROVED", "Active", "Private", "396.4", "
This DBIA, along with #2913 and #2915, is intended to
support the upload of Compensation and Pension Exam Results into AMIE, using
TIU's batch upload facility.", "", "", ""], ["2915", "SUPPORT TIU'S UPLOAD OF C&P EXAMS", "File", "AUTOMATED MED INFO EXCHANGE", "1999/09/20", "APPROVED", "Active", "Private", "396.6", "
This DBIA, along with #2913 and #2914, is intended to
support the upload of Compensation and Pension Exam Results into AMIE, using
TIU's batch upload facility.", "", "", ""], ["2916", "Data Base Server API: DD Modification Utilities", "Routine", "1", "1999/09/20", "APPROVED", "Active", "Supported", "", "", "", "DDMOD", ""], ["2917", "DBIA2917", "Routine", "TOOLKIT", "1999/09/23", "", "Retired", "Private", "", "\n
During special processing related to the Patient Merge, the routine PRCAMRG
needs to call the entry point SAVEMERG^XDRMERGB. This call is used to save
the file image of an entry involved in the merge process when only one of the
entries (the entry being merged or the entry being merged into) is present in
file 340. Normally, the merge process would handle when it can identify a
FROM or a TO entry which is not present based on the DINUMed values. For file
340, however, the internal entry numbers are determined from the "B"-cross-
reference, and missing entries need to be handled separately.\n\n
Retired and placed under IA 2338.", "", "XDRMERGB", ""], ["2918", "Patients Priority", "Routine", "REGISTRATION", "1999/09/23", "", "Withdrawn", "Supported", "", "
To look up a patients priority for report currently
using the call: $$PRIORITY^DGENA(DFN)", "", "DGENA", ""], ["2919", "Patients enrolled/preferred facility", "Routine", "REGISTRATION", "2006/08/25", "APPROVED", "Active", "Supported", "", "
Looks up a patients enrolled/preferred faility:", "", "DGENPTA", ""], ["2920", "Pharmacy copay information read", "Routine", "PHARMACY PRESCRIPTION PRACTICE", "1999/09/23", "", "Withdrawn", "Supported", "", "
Direct read of global for pharmacy copay information:
^PSRX(IEN,"IB")", "", "IEN,\"IB\"", ""], ["2921", "DBIA 2921", "Routine", "PHARMACY BENEFITS MANAGEMENT", "1999/09/24", "", "Withdrawn", "Private", "", "
This IA provides a common point for data retrieval
APIs. It presents a friendly front end to DIQ and DIQ1 with special features
for handling multiples.", "", "PSUTL", ""], ["2922", "DBIA 2292", "Routine", "PHARMACY BENEFITS MANAGEMENT", "1999/09/28", "", "Withdrawn", "Private", "", "
This API provides the ability to easily double queue
tasks into a compute cycle (no device attatched) and a print cycle (device
attatched). The compute and print routines are identified with appropriate
variables and the tasking is handled by the API.\n
Optional variables are available to provide controlling various aspects the
jobs and process.\n
Documentation is also included in the end of the routine.\n
General processing protocol information\n
%ZIS with "PQM" is called by PSUDBQUE if '$D(PSUIOP).\n
The user will be asked to queue if queuing has not been
selected.\n
IO variables for printing as necessary are automatically
stored.\n
PSUxx input variables are killed after loading into a PSU
array.\n
PSUDBQUE can be nested.\n
The compute and print phases can call PSUDBQUE individually
(PSUIOP is required).\n
The appropriate %ZTSK node is killed.\n
The use of ^XTMP in the compute cycle for storage of
information for the print cycle is typical. Subscript values
stored in one of the namespace save variables are automatically
reloaded for the next cycle.
..", "", "PSUDBQUE", ""], ["2923", "ASISTS use of $Order of File 450", "File", "PAID", "1999/10/08", "APPROVED", "Active", "Private", "450", "
Use of $Order of through the top level of ^PRSPC(I) is
needed in ASISTS. ASISTS needs to get a count of the number of PAID employees
at each facility who are not separated. That information will be used in
statistical analysis for blood-borne pathogen reporting. After getting the IEN
of each PAID employee, the routine will use a FileMan read to determine
whether the employee is separated. The routine will be executed on a monthly
basis.", "", "", ""], ["2924", "DBIA2924", "File", "ONCOLOGY", "1999/10/12", "APPROVED", "Active", "Private", "160", "
The Health Summary package has permission to do a
"Direct Global Read" of the ONCOLOGY PATIENT (160) file's "B" cross-reference.\n", "", "", ""], ["2925", "GMRCSLM2", "Routine", "CONSULT/REQUEST TRACKING", "1999/10/13", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to GMRCSLM2 as found in the
OE/RR v3 interface specification document.", "", "GMRCSLM2", ""], ["2926", "GMRCGUIA", "Routine", "CONSULT/REQUEST TRACKING", "1999/10/13", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to GMRCGUIA.", "", "GMRCGUIA", ""], ["2927", "POINTERS TO IMAGE FILE (#2005)", "File", "IMAGING", "1999/10/14", "APPROVED", "Active", "Controlled Subscription", "2005", "
To support many-to-many linkages between Images (stored
in file #2005) and other patient-oriented data (e.g., Documents, Orders,
Reports, etc.) the subscribing packages may retain POINTERS to file 2005.", "", "", ""], ["2928", "Delete Read Protection on PDM Files", "File", "1", "1999/10/15", "APPROVED", "Active", "Private", "", "
E3R PSN-4-12347 asked that the read protection on files
related to and shared by National Drug File and Pharmacy Data Management be
removed. To meet this request, PDM requests a one time agreement with VA
Fileman to KILL the global nodes ^DIC(51.2,0,"RD") and ^DIC(50.606,0,"RD").
This this agreement is simular to and requested in conjunction with DBIA#
2910.", "", "", ""], ["2929", "Health Summary/NDBI A7RHSM", "Routine", "NDBI", "1999/10/22", "APPROVED", "Active", "Private", "", "
National Database Integration routine A7RHSM contains
entry points that extract patient data from the legacy site in an integrated
system.", "", "A7RHSM", ""], ["2930", "DBIA2930", "File", "QUASAR", "1999/10/22", "APPROVED", "Active", "Private", "509850.5", "
In order to obtain CPT Modifier data, DSS EXTRACTS must
obtain a pointer value from file #509850.5, A&SP MODIFIER.", "", "", ""], ["2931", "Health Summary/NDBI A7RPSOHS", "Routine", "NDBI", "1999/10/22", "APPROVED", "Active", "Private", "", "
National Database Integration routine A7RPSOHS contains
an entry point that extracts patient data (Rx) from the legacy site in an
integrated system.", "", "A7RPSOHS", ""], ["2932", "Health Summary/NDBI A7RHSE", "Routine", "NDBI", "1999/10/22", "APPROVED", "Active", "Private", "", "
National Database Integration routine A7RHSE contains
an entry point that extracts patient data from the legacy site in an
integrated system.", "", "A7RHSE", ""], ["2933", "DBIA2933", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1999/10/22", "APPROVED", "Active", "Private", "73.1", "
Imaging requires to read the RAD MODALITY DEFINED TERMS
file to build a Modality worklist for a commercial PACS system, commercial
gateway or radiology modality.", "", "", ""], ["2934", "Health Summary/NDBI Global", "File", "NDBI", "1999/10/22", "APPROVED", "Active", "Private", "", "
The National Database Integration software contains
globals that store patient data from the legacy site in an integrated system.", "", "", ""], ["2935", "DRUG TEXT file", "File", "PHARMACY DATA MANAGEMENT", "2000/02/08", "APPROVED", "Active", "Private", "51.7", "
National Drug File (NDF) requests permission to do
direct global reads on the Pharmacy Data Management's DRUG TEXT file (#51.7).\n
This file stores rapidly changing drug restrictions, guidelines, and protocols
to help assure medications are being used according to formulary
specifications.\n", "", "", ""], ["2936", "GMTS/SCTM Team", "File", "SCHEDULING", "1999/10/26", "APPROVED", "Active", "Controlled Subscription", "404.51", "
Health Summary extracts references the following data
from the TEAM file (#404.51).\n
The Demographic component of Health Summary prints the Team Name and and Team
Phone Number of the Primary Care Team.", "", "", ""], ["2937", "OE/RR references to TIU DOCUMENT file", "File", "TEXT INTEGRATION UTILITIES", "1999/10/28", "APPROVED", "Active", "Controlled Subscription", "8925", "
This DBIA documents references from OR* routines to the
TIU DOCUMENT file (#8925).\n
Revisions:
- 3/6/23 Added 1207 SECONDARY VISIT field
- 9/11/23 Effective with Patch OR*3.0*535, ORDER NUMBER (#1210) field and
the REQUESTING PACKAGE REFERENCE (#1405) fields were added, to allow
CPRS to display the ordering provider related to certain Text
Integration Utilities (TIU) notifications to be determined.
- 3/20/24 Added 1205 HOSPITAL LOCATION", "", "", "2023/09/12"], ["2938", "OE/RR calls to GMRCGUIC", "Routine", "CONSULT/REQUEST TRACKING", "1999/10/28", "APPROVED", "Active", "Private", "", "
This DBIA documents calls from OE/RR to routine
GMRCGUIC.", "", "GMRCGUIC", ""], ["2939", "OE/RR direct views of DIC(49", "File", "KERNEL", "1999/10/28", "APPROVED", "Active", "Private", "49", "
This DBIA documents direct global references made by
OE/RR to the SERVICE/SECTION file (#49). These references are mainly used by
CPRS GUI to retrieve and display a list of selectable entries from file 49.", "", "", ""], ["2941", "DBIA2941", "Routine", "MASTER PATIENT INDEX VISTA", "1999/10/28", "APPROVED", "Active", "Controlled Subscription", "", "
CIRN PD uses this call to allow users to do a Display
Only Query to the MPI through the CIRN Exception Handling option.", "", "MPIFSAQ", ""], ["2942", "DBIA2942", "Routine", "MASTER PATIENT INDEX VISTA", "1999/10/28", "APPROVED", "Active", "Private", "", "
CIRN PD uses this call to allow users to do a Single
Patient Initialization to the MPI from the CIRN Exception Handling option.", "", "MPIFQ0", ""], ["2943", "DBIA2943", "Routine", "REGISTRATION", "1999/10/29", "", "Withdrawn", "Private", "", "
To support CIRN Exception Handling, CIRN PD needs to
include an option to Edit Patient Data.", "", "DG10", ""], ["2944", "Calls to TIUSRVR1", "Routine", "TEXT INTEGRATION UTILITIES", "1999/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to TIUSRVR1.", "", "TIUSRVR1", ""], ["2945", "Use of calls in PSIVSP", "Routine", "INPATIENT MEDICATIONS", "1999/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to PSIVSP.\n
Amended 7/29/22 to add the COMPONENT: $$INFRATE(X), effective with PSJ*5*375,
OR*3*439.", "", "PSIVSP", "1999/10/29"], ["2946", "Calls to PSSGSGUI", "Routine", "PHARMACY DATA MANAGEMENT", "1999/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
This call provides a Schedule validation check for
medication orders entered through Computerized Patient Record System (CPRS).", "", "PSSGSGUI", ""], ["2947", "Calls to LR7OGO", "Routine", "LAB SERVICE", "1999/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine LR7OGO.", "", "ORWLRR", ""], ["2950", "DBIA2950", "Routine", "LEXICON UTILITY", "2003/04/16", "APPROVED", "Active", "Supported", "", "
This entry point is silent and intended to support
Graphical User Interface (GUI) development. The lookup returns an array of
information on the expressions found. The lookup includes reordering the
selection list with the most frequently used at the top, and places any exact
match at the top of the list.", "", "LEXA", ""], ["2951", "LR7OSBR", "Routine", "LAB SERVICE", "1999/11/01", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to LR7OSBR to retrieve the
formatted text of a Blood Bank report for a patient.", "", "LR7OSBR", ""], ["2952", "LR7OSMZ0", "Routine", "LAB SERVICE", "1999/11/01", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to LR7OSMZ0 to retrieve the
formatted text of a Microbiology report for a patient.", "", "LR7OSMZ0", ""], ["2953", "STATUS OF PATIENT IN THE OUTPATIENT ENCOUNTER FILE", "File", "SCHEDULING", "1999/11/02", "APPROVED", "Active", "Controlled Subscription", "409.68", "
This database integration agreement (DBIA) is needed to
track a particular status of a patient in the OUTPATIENT ENCOUNTER (#409.68)
file. The input variable is the DFN of the patient, so our application needs
to roll down the 'ADFN' M cross-reference (Patient field) in file 409.68. Our
application intends to read, with FileMan, the STATUS (field .12) of the
patient in the OUTPATIENT ENCOUNTER (#409.68) file.\n
We are looking for a private subscription that would allow our application to
walk down the 'ADFN' cross-reference and then read, with FileMan, the STATUS
field in the OUTPATIENT ENCOUNTER file.", "", "", ""], ["2954", "Calls to LR7OGG", "Routine", "LAB SERVICE", "1999/11/04", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine LR7OGG", "", "LR7OGG", ""], ["2955", "Calls to LR7OU1", "Routine", "LAB SERVICE", "1999/11/03", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine LR7OU1", "", "LR7OU1", "2012/05/24"], ["2956", "Calls to LR7OGC", "Routine", "LAB SERVICE", "1999/11/03", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine LR7OGC.", "", "LR7OGC", ""], ["2957", "DBIA2957", "Routine", "CONSULT/REQUEST TRACKING", "1999/11/09", "APPROVED", "Active", "Private", "", "
This agreement allows the OE/RR package to call
CLNLIST^GMRCTU in order to remove pointers in the CONSULTS package for
terminated users. The calling routine is ORLPTU, which is triggered by a
Kernel event when a user is terminated.", "", "GMRCTU", ""], ["2958", "Calls to LR7OGM", "Routine", "LAB SERVICE", "1999/11/09", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine LR7OGM.
^TMP("LR7OG",$J) and ^TMP("LR7OGX",$J) may be killed before and after any
component call.", "", "LR7OGM", ""], ["2959", "Calls to LR7OGMU", "Routine", "LAB SERVICE", "1999/11/09", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine LR7OGMU.", "", "LR7OGMU", ""], ["2960", "Calls to TIULX", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/09", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine TIULX", "", "TIULX", ""], ["2961", "OE/RR use of HEALTH SUMMARY TYPE file", "File", "HEALTH SUMMARY", "1999/11/09", "APPROVED", "Active", "Private", "142", "
This DBIA documents CPRS's use of the Health Summary
Type file (#142). This file is used to allow displaying of health summaries
via the CPRS interface.", "", "", ""], ["2962", "Calls to GMPLHIST", "Routine", "PROBLEM LIST", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to rotuine GMPLHIST.", "", "GMPLHIST", ""], ["2963", "Direct access to %ZIS(1", "File", "KERNEL", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "3.5", "
This DBIA documents direct access to fields in the
DEVICE file (#3.5).", "", "", ""], ["2964", "Direct access to %ZIS(2", "File", "KERNEL", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "3.2", "
This DBIA documents direct access to the TERMINAL TYPE
file (#3.2).", "", "", ""], ["2965", "Direct access to file 405.1", "File", "REGISTRATION", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "405.1", "
This DBIA documents references to the FACILITY MOVEMENT
TYPE file (#405.1).", "", "", ""], ["2966", "Use of TYPE OF PATIENT file", "File", "REGISTRATION", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "391", "
This DBIA documents access to the TYPE OF PATIENT file
(#391)", "", "", ""], ["2967", "References to DISABILITY CONDITION file", "File", "HINQ", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "31", "
This DBIA documents references to the DISABILITY
CONDITION file (#31).", "", "", ""], ["2968", "Direct access to file 34", "File", "RADIOLOGY/NUCLEAR MEDICINE", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "34", "
This DBIA documents references to the CONTRACT/SHARING
AGREEMENTS file (#34).", "", "", ""], ["2969", "DBIA2969", "File", "REGISTRATION", "1999/11/10", "APPROVED", "Active", "Private", "2", "
To support CIRN Exception Handling, CIRN PD needs to
allow user editing of patient name, date of birth, social security number and
date of death fields. All appropriate security checking is done.", "", "", ""], ["2970", "Access to Problem List Parameters", "File", "PROBLEM LIST", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "125.99", "
This DBIA documents access to the PROBLEM LIST SITE
PARAMETER file (#125.99).", "", "", ""], ["2971", "Access to PROBLEM SELECTION LIST file", "File", "PROBLEM LIST", "2003/07/21", "APPROVED", "Active", "Controlled Subscription", "125", "
This DBIA documents access made to the PROBLEM
SELECTION LIST file (#125).", "", "", "2017/02/14"], ["2972", "References to file 125.1", "File", "PROBLEM LIST", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "125.1", "
This DBIA documents references made to the PROBLEM
SELECTION LIST CONTENTS file (#125.1).", "", "", ""], ["2973", "References to file 125.12", "File", "PROBLEM LIST", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "125.12", "
This DBIA documents references to the PROBLEM SELECTION
CATEGORY CONTENTS file (#125.12).", "", "", ""], ["2974", "Access to PROBLEM LIST AUDIT file", "File", "PROBLEM LIST", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "125.8", "
This DBIA documents references to the PROBLEM LIST
AUDIT file (#125.8).", "", "", ""], ["2975", "Use of REQUEST ACTION TYPES file", "File", "CONSULT/REQUEST TRACKING", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "123.1", "
This DBIA documents references to the REQUEST ACTION
TYPES file (#123.1).", "", "", ""], ["2976", "Access to Allergy Parameters File", "File", "ADVERSE REACTION TRACKING", "1999/11/10", "APPROVED", "Active", "Controlled Subscription", "120.84", "
This DBIA documents references made to the GMR ALLERGY
SITE PARAMETERS file (#120.84).", "", "", ""], ["2977", "Calls to GMPLEDT3", "Routine", "PROBLEM LIST", "1999/11/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine GMPLEDT3.", "", "GMPLEDT3", "2015/08/12"], ["2978", "Calls to GMPLSAVE", "Routine", "PROBLEM LIST", "1999/11/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine GMPLSAVE.", "", "GMPLSAVE", ""], ["2979", "Calls to GMPLMGR1", "Routine", "PROBLEM LIST", "1999/11/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to GMPLMGR1.", "", "GMPLMGR1", ""], ["2980", "Calls to GMRCGUIB", "Routine", "CONSULT/REQUEST TRACKING", "1999/11/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine GMRCGUIB.", "", "GMRCGUIB", ""], ["2981", "Calls to GMRCP5", "Routine", "CONSULT/REQUEST TRACKING", "1999/11/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine GMRCP5.", "", "GMRCP5", ""], ["2982", "Calls to GMRCPR0", "Routine", "CONSULT/REQUEST TRACKING", "1999/11/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine GMRCPR0", "", "GMRCPR0", ""], ["2983", "LR7OSOS1", "Routine", "LAB SERVICE", "1999/11/15", "APPROVED", "Active", "Private", "", "
This routine produces a formatted patient report of Lab
order status.", "", "LR7OSOS1", ""], ["2984", "LR7OSBB1", "Routine", "LAB SERVICE", "1999/11/15", "APPROVED", "Active", "Private", "", "
This routine is used to get Blood Bank patient
information for disiplay in CPRS. It is a 'silent' version of the routine
LRBLPD.", "", "LR7OSBB1", ""], ["2985", "LR7OSOS", "Routine", "LAB SERVICE", "1999/11/15", "APPROVED", "Active", "Private", "", "
This routine produces a lab status report for a
pre-selected patient. This report is interactive.", "", "LR7OSOS", ""], ["2986", "OE/RR calls to MCARP", "Routine", "CLINICAL PROCEDURES", "1999/11/15", "APPROVED", "Active", "Private", "", "
This routine is used to get parameters needed to
produce a report of Patient Procedures. This DBIA is only to be used for CPRS
Reporting and does not include any procedures for editing the Medicine
database.", "", "MCARP", ""], ["2987", "DBIA2987", "Routine", "INPATIENT MEDICATIONS", "1999/11/18", "", "Withdrawn", "Private", "", "", "", "PSJPATMR", ""], ["2988", "IAs for VAFCTFU utilities", "Routine", "REGISTRATION", "1999/11/19", "APPROVED", "Active", "Controlled Subscription", "", "
MPI Vista is requesting a DBIA with Registration to
call DELALLTF^VAFCTFU to remove all associated treating facilities for a
patient who's ICN has been inactivated.\n
DELALLTF(PAT) ;Entry point to delete all Treating Facilities for a single
patient.
;INPUT PAT - The patient's ICN
;OUTPUT 0 (zero) - If no errors
; 1^error description if an error\n
MPI/PD is requesting an IA with Registration to call FILE^VAFCTFU. This
subroutine is used to file data into the TREATING FACILITY LIST (TFL -
#391.91) file (via the ADT/HL7 PIVOT file) under certain conditions.\n
FILE(PDFN,FSTRG,TICN) ;this module files the individual entry
input: PDFN - patient dfn
FSTRG- string, three pieces delimited by an '^'
1st piece: treating facility
2nd piece: last treatment date for the patient
3rd piece: Event Reason (ADT/HL7 EVENT REASON
#391.72) file
TICN - boolean flag, do not update the TFL file
(via the PIVOT file) if TICN equals one.\n
MPI/PD needs to expand this DBIA to include a call to DELETE^VAFCTFU. This
call is necessary to address the issue of duplicate treating facilities
assigned to a patient, therefore the variable being passed is the internal
entry number in TREATING FACILITY LIST FILE (#391.91) not the IEN for a site
that the other calls are using.\n
DELETE(TFIEN) ;the actual deletion code
;
K DIK,DA
S DIK="^DGCN(391.91,"
S DA=TFIEN
D ^DIK K DIK,DA
Q", "", "VAFCTFU", ""], ["2989", "DBIA2989", "File", "1", "2003/06/10", "", "Retired", "Private", "90", "
This is a one time DBIA request to modify the field
definitions of two fields from the MENTAL HEALTH package's MEDICAL RECORDS
file (#90.) This is in response to NOIS calls PUG-1099-51192 and
HOU-0399-72142. Patch YS*5.01*58 was created to address these NOIS calls.
Here is the patch description from YS*5.01*58:\n
This patch corrects an error that occurs in menu option "Identify Potential
Merge Problems [XDR VALID CHECK]" of the MEDICINE package. Although it
originally appeared to be a FILEMAN error or a MEDICINE package error, it was
later determined to be a data dictionary problem with the MEDICAL RECORDS file
(#90) of the MENTAL HEALTH package.\n
The error appears as follows:\n
$ZE= DDENTRY+29^DIQGQ:3, %DSM-E-NAME, bad variable name\n
..D F S DIQGMDA=$O(@DIQGMGR@(DIQGMDA)) Q:DIQGMDA'>0 D
EN($S('DIQGDD:DIQGMDD,
1:$$OREF(DIQGMGR)),.DIQGMDA,"**",DIQGPARM,.DIQGTA,"",$S('DIQGDD:"",1:1))\n
Last Global Ref: ^DIC(.12,0,"GL")\n
The problem is caused by the DD definition of the COMMENTS field (Sub file
#90.02, Sub field #30) of the PHY field (Sub file #90.01, Sub field #100) of
the MEDICAL RECORDS file (#90.) The GETS^DIQ call in routine XDRDVAL was
extracting all fields and sub fields for the given record (due to the "**" in
the FIELD parameter.) See below:\n
D GETS^DIQ(FILE,IEN,"**","EIN",DATAROOT,MESGROOT)\n
The COMMENTS field (#30) is defined as a free text multiple but stored as a
word-processing field. In a multiple field, the header (or 0) node contains
the DD entry number of the sub file in the second piece. Because the DD
definition of the COMMENTS field (#30) is defined as a multiple field, FILEMAN
takes the value of the second piece (delimited by "^") of the header node and
pluses it (+) to get the DD entry number of the sub file. See below:\n
^MR(7180189,"PE",7069286,19,0) = ^^1^1^2930713^\n
The node above resembles a word processing field but in the DD it is defined
as a multiple. A multiple should have a sub file number in the second piece.
Since nothing is in the second piece, the resulting number returned to FILEMAN
was a 0 (zero) which confused FILEMAN, causing it to look at the wrong file.
The same DD problem exists in the INITIAL IMPRESSION field (Sub file #90.03,
Sub field #31.) This field is defined as a free text multiple but stored as a
word-processing field.\n
In this situation, no data problem exists. The data is correct and requires
no modifications. The solution is to change the definitions of these fields
from multiples to word-processing. Because MEDICAL RECORDS file is an old
file, it is not possible to make the data dictionary changes using FILEMAN.
Therefore, it is necessary to use hard SETS and KILLS to update the data
dictionary.\n
Here is the data as it exists prior to the installation of this patch. Please
note that, for better readability, not all nodes have been displayed:\n
COMMENTS field (#30)\n
^DD(90.01,30,0) = COMMENTS^90.02A^^19;0
^DD(90.01,30,21,0) = ^^1^1^2930202^
^DD(90.01,30,21,1,0) = Comments relating to the physical exam.\n
^DD(90.02,0) = COMMENTS SUB-FIELD^NL^.01^1
^DD(90.02,.01,0) = COMMENTS^MF^^0;1^K:$L(X)>70!($L(X)<2) X
^DD(90.02,.01,3) = ANSWER MUST BE 2-70 CHARACTERS IN LENGTH
^DD(90.02,.01,21,0) = ^^2^2^2930202^
^DD(90.02,.01,21,1,0) = Comments enter by the examiner relating to the
physical exam of the
^DD(90.02,.01,21,2,0) = patient.\n
INITIAL IMPRESSION field (#31)\n
^DD(90.01,31,0) = INITIAL IMPRESSION^90.03A^^20;0
^DD(90.01,31,21,0) = ^^1^1^2930202^
^DD(90.01,31,21,1,0) = Examiner's initial impression.\n
^DD(90.03,0) = INITIAL IMPRESSION SUB-FIELD^NL^.01^1
^DD(90.03,0,"NM","INITIAL IMPRESSION") =
^DD(90.03,0,"UP") = 90.01
^DD(90.03,.01,0) = INITIAL IMPRESSION^MF^^0;1^K:$L(X)>70!($L(X)<2) X
^DD(90.03,.01,3) = ANSWER MUST BE 2-70 CHARACTERS IN LENGTH\n
Routine YS58POST will run during installation of YS*5.01*58 to perform the
following:\n
1) Remove the "A" from the sub field number. The "A" indicates to
automatically add entries without asking: "ARE YOU ADDING A NEW ENTRY?" This
is no longer applicable for a word processing file.\n
S $P(^DD(90.01,30,0),U,2)=90.02 (COMMENTS)
S $P(^DD(90.01,31,0),U,2)=90.03 (INITITAL IMPRESSION)\n
2) Reset the field definition which is stored in the data dictionary's zero
node, field .01, of the sub file. The "MF" originally in the second piece
indicates this field is a multiple and free text. We replace it with "W"
which indicates a word processing field. The input transform Mumps code is
replaced with "Q" in the fifth piece.\n
S ^DD(90.02,.01,0)="COMMENTS^W^^0;1^Q"
S ^DD(90.03,.01,0)="INITIAL IMPRESSION^W^^0;1^Q"\n
3) Kill the help text in the 3 node. It is no longer needed.\n
K ^DD(90.02,.01,3) (COMMENTS)
K ^DD(90.03,.01,3) (INITIAL IMPRESSIONS)\n
4) Correct a spelling error for the COMMENTS field (#30.)\n
S ^DD(90.02,.01,21,1,0)="Comments entered by the examiner relating
to the physical exam"\n
This is how the data dictionary entries appear after the changes are made.\n
COMMENTS field (#30)\n
^DD(90.01,30,0) = COMMENTS^90.02^^19;0
^DD(90.01,30,21,0) = ^^1^1^2930202^
^DD(90.01,30,21,1,0) = Comments relating to the physical exam.\n
^DD(90.02,0) = COMMENTS SUB-FIELD^NL^.01^1
^DD(90.02,.01,0) = COMMENTS^W^^0;1^Q
^DD(90.02,.01,21,0) = ^^2^2^2930202^
^DD(90.02,.01,21,1,0) = Comments entered by the examiner relating to the
physical exam of the\n
INITIAL IMPRESSION field (#31)\n
^DD(90.01,31,0) = INITIAL IMPRESSION^90.03^^20;0
^DD(90.01,31,21,0) = ^^1^1^2930202^
^DD(90.01,31,21,1,0) = Examiner's initial impression.\n
^DD(90.03,0) = INITIAL IMPRESSION SUB-FIELD^NL^.01^1
^DD(90.03,.01,0) = INITIAL IMPRESSION^W^^0;1^Q\n", "", "", ""], ["2990", "Treating Facility List", "Routine", "REGISTRATION", "1999/11/23", "APPROVED", "Active", "Supported", "", "
As part of the initative to share clinical information
among VA facilities, a VA facility will have information about patients that
were seen at other locations for health care.\n
This routine will return (given an Integration Control Number or a DFN) a list
of facilities the patient was seen for care.", "", "VAFCTFU1", ""], ["2991", "DBIA2991", "File", "1", "1999/11/23", "APPROVED", "Active", "Controlled Subscription", "", "
Variable pointer information is sometimes required.
This information can be found in ^DD(file#,field#.,"V"). This DBIA provides
for read-only access of the nodes ^DD(file#,field#,"V",.\n", "", "", ""], ["2992", "PARAMETER DEFINITIONS", "File", "TOOLKIT", "1999/11/23", "APPROVED", "Active", "Supported", "8989.51", "
Parameter Tools is a generic method of handling
parameter definition, assignment, and retrieval. A parameter may be defined
for various entities where an entity is the level at which you want to allow
the parameter defined (e.g. package level, system level, division level,
location level, user level, etc.). A developer may then determine in which
order the values assigned to given entities are interpreted.\n
Parameter:
==========
A parameter is the actual name which values are stored under. The name of the
parameter must be namespaced and it must be unique. Parameters can be defined
to store the typical package parameter data (e.g. the default add order screen
in OE/RR), but they can also be used to store GUI application screen settings
a user has selected (e.g. font or window width). When a parameter is defined,
the entities that may set the parameter is also defined. The definition of
parameters is stored in the PARAMETER DEFINITION file (#8989.51). KIDS
exports them.", "", "", ""], ["2993", "DBIA2993", "Routine", "REGISTRATION", "1999/11/24", "APPROVED", "Active", "Private", "", "
RAI/MDS has requested Integrated Billing add cross
references to 5 Insurance Type (#2.312) fields to monitor changes to the
patient's insurance data. Execution of the cross reference will result in an
entry in the ADT/HL7 PIVOT file (#391.71) and mark it as requiring
transmission of an HL7 demographic A08 update message to the COTS interface.\n
The local variable DGRUGA08 will be set to 1 if the cross reference is not to
be executed as part of a re-indexing.\n
Update: IB*2*497 increased the length of the SUBSCRIBER ID field to support
the EDI New Standards and Operating Rules for VHA providers. This required
length increase made it necessary to move the location of this field to a new
Data Dictionary node in the INSURANCE TYPE sub-file. To support this
implementation, all subscribers to this ICR will need to make the necessary
changes in their applications. The ADGRU cross- reference cannot be
implemented at the new field (2.312, 7.02) until the old field (2.312, 1) has
been deleted. Therefore rather than IB*2*497, IB*2*518 will need to implement
the ADGRU cross-reference at the new field and delete ADGRU cross-reference at
the old field. The old and new field are noted in the field list detail of
this ICR.\n\n
Fields cross-referenced in the Patient File Insurance Type multiple:\n
2.312, .01 Insurance Type (x-ref #1)
2.312, .18 Group Plan (x-ref #1)
2.312, 1 *Subscriber ID (x-ref #1)
Note: IB*2*497 - replaced by SUBSCRIBER ID field (7.02)
2.312, 7.02 Subscriber ID (x-ref to be determined by IB*2*518)
2.312, 3 Insurance Expiration Date (x-ref #1)
2.312, 8 Effective Date of Policy (x-ref #1)\n
The following cross reference is added to all 5 fields:\n
CROSS-REFERENCE: ADGRUxx
TYPE: MUMPS
SET: D:($T(ADGRU^DGRUDD01)'="") ADGRU^DGRUDD01(DA(1))
KILL: D:($T(ADGRU^DGRUDD01)'="") ADGRU^DGRUDD01(DA(1))", "", "DGRUDD01", "2014/02/21"], ["2994", "Calls to TIUU", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine TIUU.", "", "TIUU", ""], ["2995", "Calls to TIURS", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIURS.", "", "TIURS", ""], ["2996", "Calls to TIURC", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIURC.", "", "TIURC", ""], ["2997", "Calls to TIURB", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIURB", "", "TIURB", ""], ["2998", "Calls to TIURA", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIURA.", "", "TIURA", ""], ["2999", "Calls to TIUPRPN3", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIUPRPN3.", "", "TIUPRPN3", ""], ["3000", "Calls to TIULM", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to TIULM.", "", "TIULM", ""], ["3001", "Calls to TIULA1", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routine TIULA1.", "", "TIULA1", ""], ["3002", "Calls to TIUDEV", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to routien TIUDEV.", "", "TIUDEV", ""], ["3003", "Calls to routine TIULG", "Routine", "TEXT INTEGRATION UTILITIES", "1999/11/29", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls made to routine TIULG.", "", "TIULG", ""], ["3004", "POINT TO DISPLAY GROUP (#100.98) FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "1999/11/30", "APPROVED", "Active", "Controlled Subscription", "100.98", "", "", "", ""], ["3005", "POINT TO OE/RR LIST (#100.21) FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "1999/11/30", "APPROVED", "Active", "Controlled Subscription", "100.21", "", "", "", ""], ["3006", "MAIL GROUP API", "Routine", "MAILMAN", "1999/11/30", "APPROVED", "Active", "Supported", "", "
The APIs in this DBIA perform mail group functions and
actions.\n
If any errors occur, the following variables will be defined:
XMERR - The number of errors
^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text>\n
Following is information on some common input parameters:\n
XMGROUP - Mail group IEN or name (exact, case-sensitive)", "", "XMXAPIG", ""], ["3007", "DBIA3007", "File", "IFCAP", "1999/12/02", "APPROVED", "Active", "Private", "423.6", "
This agreement allows AR to reference the IFCAP file
ISMS/FMS TRANS #423.6.", "", "", ""], ["3008", "POINT TO USR CLASS (#8930) FILE", "File", "AUTHORIZATION/SUBSCRIPTION", "1999/12/07", "APPROVED", "Active", "Controlled Subscription", "8930", "", "", "", ""], ["3009", "XQALFWD", "Routine", "KERNEL", "1999/12/08", "APPROVED", "Active", "Supported", "", "
This entry point can be used to forward alerts (in most
cases, for the current user only). It is a silent (no screen input or output)
entry point, and so can be used for windowed applications.\n
Example ; get open alerts for current user K A6AALRT D USER^XQALERT("A6AALRT")
;
I +A6AALRT D ; if any current alerts... .; loop through A6AALRT array, parse
alert id for each open alert .K A6AALRT1 S A6ASUB="",A6AI=0 .F S
A6ASUB=$O(A6AALRT(A6ASUB)) Q:'$L(A6ASUB) D ..S
A6AI=A6AI+1,A6AALRT1(A6AI)=$P(A6ASUB,"^",2)
.;
.;forward open alerts of current user to MAS CLERKS mailgroup .K A6AUSER S
A6AUSER="G.MAS CLERKS" .D FORWARD^XQALFWD(.A6AALRT1,A6AUSER,"A","Forwarded
Alert") Q", "", "XQALFWD", ""], ["3010", "XQALBUTL", "Routine", "KERNEL", "1999/12/08", "APPROVED", "Active", "Supported", "", "", "", "XQALBUTL", ""], ["3011", "XWB IS RPC AVAILABLE", "Remote Procedure", "RPC BROKER", "1999/12/08", "APPROVED", "Active", "Supported", "", "
This RPC allows an application to determine if a
particular RPC is available on a server.\n
INPUT PARAMETER: RPC PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 1 (Required)
DESCRIPTION: Name of the RPC to be tested. INPUT PARAMETER: RUN CONTEXT
PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 2 (Optional)
DESCRIPTION: Specific context in which RPC will run. Possible values
are:
L = run Locally (on the server the user is logged on to)
R = run Remotely (on a server the user is not logged on to)
If this parameter is not sent, RPC is checked for both local and remote.
The check is done against the value in the INACTIVE field in the Remote
Procedure file. See that field's description for more details. INPUT
PARAMETER: VERSION NUMBER PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 3 (Optional)
DESCRIPTION: Minimum version number of the RPC.
This parameter is only used if the RUN CONTEXT parameter = "R". If a
numeric value is in this parameter, the value must be less than or equal
to the value in the VERSION field of the Remote Procedure file for the
RPC is be marked available. Note: if the VERSION field is null, the
check will fail for any numeric value in this parameter.\n
RETURN VALUE DESCRIPTION:
Boolean. 1 = RPC available.
0 = RPC not available.", "", "", ""], ["3012", "XWB ARE RPCS AVAILABLE", "Remote Procedure", "RPC BROKER", "1999/12/08", "APPROVED", "Active", "Supported", "", "
This RPC allows an application to determine if a list
of RPCs are available for use on the server.\n
INPUT PARAMETER: RUN CONTEXT PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 1 (Optional)
DESCRIPTION: Specific context in which RPCs will run. Possible values
are:
L = run Locally (on the server the user is logged on to)
R = run Remotely (on a server the user is not logged on to)
If this parameter is not sent, RPC is checked for both local and remote.
The check is done against the value in the INACTIVE field in the Remote
Procedure file. See that field's description for more details. INPUT
PARAMETER: RPC PARAMETER TYPE: LIST
SEQUENCE NUMBER: 2 (Required)
DESCRIPTION: This 0-based array contains list of RPCs to be checked
along with (optionally) a minimum acceptable version of the RPC. The
format is:\n
RPCName^RPCVersionNumber\n
The RPCVersionNumber is only used if the RUN CONTEXT parameter = "R".
If a numeric value is in the second ^-piece and the RUN CONTEXT ="R",
the value must be less than or equal to the value in the VERSION field
of the Remote Procedure file for the RPC to be marked available. Note:
if the VERSION field is null, the check will fail for any numeric value.\n
RETURN VALUE DESCRIPTION:
A 0-based array. The index corresponds to the index of the RPC in the
RPC Input Parameter. A value of 1 means the corresponding RPC is
available; a value of 0 means it is not available.", "", "", ""], ["3013", "DBIA3013", "File", "PHARMACY DATA MANAGEMENT", "1999/12/21", "APPROVED", "Active", "Private", "52.7", "
Controlled Substances is given permission to reference
the fields identified in this integration agreement. The refernces are made
using the VA Fileman API ^DIC.\n
GLOBAL MAP DATA DICTIONARY #52.7 -- IV SOLUTIONS FILE STORED IN ^PS(52.7, (3
ENTRIES) SITE: BIRMINGHAM ISC (#14)\n
^PS(52.7,D0,0)= (#.01) PRINT NAME [1F] Read w/Fileman\n
^PS(52.7,D0,0)= (#2) VOLUME [3F] Read w/Fileman\n", "", "", ""], ["3015", "PID segment generation (CIRN PD)", "Routine", "REGISTRATION", "2000/01/12", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this IA is to create a PID segment when
a patient is:\n
1) admitted 2) discharged 3) checked out of a clinic\n
This segment is part of a HL7 message used by CIRN PD to DATE LAST TREATED
(#.03) and the ADT/HL7 EVENT REASON (#.07) fields in the TREATING FACILITY
LIST (#391.91) file. This is patient/facility specific information.", "", "VAFCPID", ""], ["3016", "EVN segment generation (CIRN PD)", "Routine", "REGISTRATION", "2000/01/12", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this IA is to create a EVN segment when
a patient is:\n
1) admitted 2) discharged 3) checked out of a clinic\n
This segment is part of a HL7 message used by CIRN PD to DATE LAST TREATED
(#.03) and the ADT/HL7 EVENT REASON (#.07) fields in the TREATING FACILITY
LIST (#391.91) file. This is patient/facility specific information.", "", "VAFHLEVN", "2015/12/15"], ["3017", "PD1 segment generator", "Routine", "REGISTRATION", "2000/01/12", "APPROVED", "Active", "Supported", "", "
Supported call for building of HL7 PD1 segment (Patient
Additional Demographics).", "", "VAFHLPD1", ""], ["3018", "PV1 segment generator", "Routine", "REGISTRATION", "2000/01/12", "APPROVED", "Active", "Supported", "", "
Supported calls for building of HL7 PV1 segment
(Patient Visit)", "", "VAFHLPV1", ""], ["3019", "DG CHK BS5 XREF Y/N", "Remote Procedure", "REGISTRATION", "2000/01/20", "APPROVED", "Active", "Supported", "", "", "DG CHK BS5 XREF Y/N", "", ""], ["3020", "DG CHK BS5 XREF ARRAY", "Remote Procedure", "REGISTRATION", "", "APPROVED", "Active", "Supported", "", "", "DG CHK BS5 XREF ARRAY", "", ""], ["3021", "DG CHK MEANS TEST DIV DISPLAY", "Remote Procedure", "REGISTRATION", "", "APPROVED", "Active", "Supported", "", "", "DG CHK MEANS TEST DIV DISPLAY", "", ""], ["3022", "DG CHK PAT MEANS TEST REQUIRED", "Remote Procedure", "REGISTRATION", "", "APPROVED", "Active", "Supported", "", "", "DG CHK PAT MEANS TEST REQUIRED", "", ""], ["3023", "DG CHK PAT/DIV MEANS TEST", "Remote Procedure", "REGISTRATION", "", "APPROVED", "Active", "Supported", "", "", "DG CHK PAT/DIV MEANS TEST", "", ""], ["3024", "ID Nodes in Patient (#2) file", "File", "1", "2003/06/10", "", "Retired", "Private", "2", "
DG*5.3*249, DGSEC Modifications and Privacy Act
Compliance for Employees, modifies the identifiers on the DOB (#.03) and
Social Security Number (#.09) fields in the Patient (#2) file to:\n
^DD(2,0,"ID",.03) = D EN^DDIOL($TR($$DOB^DPTLK1(Y,1),"/","-"),,"?$X+2")
^DD(2,0,"ID",.09) = D EN^DDIOL($$SSN^DPTLK1(Y),,"?$X+2")\n
The DOB and SSN function calls in DPTLK1 are new with this patch. If the
patient's primary eligibility code is Employee, *SENSITIVE* will be displayed
for the DOB and SSN fields until the user verifies they want to access the
restricted record.\n
The post-init routine, DG53249P, will set the "ID" nodes:\n
DG53249P ;ALB/JAP - Patch 249 postinstall ; 1/11/00 12:56pm
;;5.3;Registration;**249**;Aug 13, 1993
;
EN ;entry point from install
;update identifier code in patient file
S ^DD(2,0,"ID",.03)="D
EN^DDIOL($TR($$DOB^DPTLK1(Y,1),""/"",""-""),,""?$X+2"")"
S ^DD(2,0,"ID",.09)="D EN^DDIOL($$SSN^DPTLK1(Y),,""?$X+2"")"
Q", "", "", ""], ["3025", "DBIA3025", "File", "CPT/HCPCS CODES", "2000/01/24", "APPROVED", "Retired", "Private", "81", "
Please see supported ICR #5408, CPT/CPCS Procedure File
81.Integrated Billing and AICS require Fileman lookup to file 81 (^ICPT).", "", "", ""], ["3026", "DBIA3026", "File", "CPT/HCPCS CODES", "2000/01/24", "APPROVED", "Retired", "Controlled Subscription", "81.3", "
Now covered by supported ICR #2816,CPT MODIFIERS FILE.
Both Integrated Billing and AICS require Fileman lookup to file #81.3
(^DIC(81.3).", "", "", ""], ["3027", "Security/Sensitive Record access", "Routine", "REGISTRATION", "2000/01/31", "APPROVED", "Active", "Supported", "", "
This integration agreement provides 2 entry points in
DGSEC4:\n
PTSEC^DGSEC4 determines if patient's record is sensitive or if user is
accessing his/her own Patient (#2) file record.\n
NOTICE^DGSEC4 adds or updated the DG Security Log (#38.1) file and optionally
generates the Sensitive Record Access mail message.", "", "DGSEC4", ""], ["3028", "DBIA3028", "File", "AUTHORIZATION/SUBSCRIPTION", "2000/01/31", "APPROVED", "Active", "Controlled Subscription", "8930.3", "
QUASAR A&SP STAFF File, #509850.3, will point to USR
CLASS MEMBERSHIP FILE, #8930.3.\n
USR does not normally permit storing User Class memberships. Generally
membership is checked on the fly using APIs to determine a permission, or
checked and then a result is stored which does not point to the USR file. For
example, the TIU document file has field COSIGNATURE NEEDED which stores the
result of a lookup in the USR file and in TIU parameters.", "", "", ""], ["3029", "TRANSFER FACILITY", "File", "REGISTRATION", "2000/02/03", "APPROVED", "Active", "Private", "405", "
This integration agreement grants permission to the
subscribing package to read with FileMan the TRANSFER FACILITY field (#.05) in
the PATIENT MOVEMENT file (#405).", "", "", ""], ["3030", "Protect Broker Variables in KILL", "Routine", "RPC BROKER", "2000/02/03", "", "Withdrawn", "Private", "", "
This DBIA gives Kernel permission to access a tag in a
Broker routine to extract a list of variables that Broker needs protected when
KILL^XUSCLEAN is called by a package in an RPC.", "", "XWBLIB", ""], ["3031", "Remote RPCs", "Remote Procedure", "RPC BROKER", "2003/04/29", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA describes the Broker RPCs that provide the
capability of running any application RPC on a remote system. They were
developed to support the CPRS Remote Data Views project.\n
NOTE: This 'Server to Server RPC' functionality is currently limited to sites
that have implemented CIRN. CIRN makes it possible for an application to know
a patient's current list of treating facilities. Furthermore, CIRN has
assumed responsibility for supervising the proper configuration and activation
of the VA network nodes that will be used for HL7 message exchange.\n
XWB REMOTE RPC
This is the RPC that is called to request that an application RPC
be run on a remote system. The data is passed by HL7 to the remote system
as is the return value.\n
This RPC will return a HANDLE that can be used to check if the data has
been sent back from the remote system. The HANDLE can be used in another
RPC to check the status of the RPC.\n
Parameters:
(location<station #>,rpc name,[rpc version],[1 to 10 params to the RPC))\n
Return:
The return value is always an array. The first node of the array is equal to
a string that serves as a HANDLE. This is used to check the status of a RPC
request and to retrieve the results of the RPC.
In the case of an error condition, the first node of the array is equal to a
string with the syntax "-1^error text".\n
XWB REMOTE STATUS CHECK
This RPC will return the status of a remote RPC.\n
Parameters:
The HANDLE from the XWB REMOTE RPC.\n
Return:
The return value is always an array. The first node of the array is
equal to one of the following values:
"-1^Bad Handle" - An invalid handle has been passed.
"0^New" - The request has been sent.
"0^Running" - HL7 indicates that the message is being processed.
"1^Done" - RPC has completed and the data has returned to the local
server. The data is not returned by this RPC. Use the XWB REMOTE
GETDATA RPC to retrieve the data.
The second node of the array is the status from the HL7 package.\n
XWB REMOTE GETDATA
This RPC will return an ARRAY with what ever data has been sent back from
the remote site.\n
Parameters:
The HANDLE from the XWB REMOTE RPC. It is used to link the call to the
data.\n
Return:
The return value is the array of data. In the event of an error condition,
the first node of the array is equal to a string with the syntax "-1^error
text".\n
XWB REMOTE CLEAR
This RPC is used to CLEAR the data under the HANDLE in the ^XTMP global.\n
Parameters:
The HANDLE from the XWB REMOTE RPC.\n
Return:
The return value is always an array. The first node of the array is equal to
1", "", "", ""], ["3032", "Direct RPCs", "Remote Procedure", "RPC BROKER", "2000/02/03", "", "Withdrawn", "Controlled Subscription", "", "
XWB DIRECT RPC
This is the Broker RPC that is called to request that a RPC be run on a
remote system. The data is passed by HL7 to the remote system as is the
return value. The difference between this and the XWB REMOTE RPC is this is a
blocking call meaning the user's workstation will not process anything else
until the data returns from the remote system.\n
NOTE: This 'Server to Server RPC' functionality is currently limited to sites
that have implemented CIRN. CIRN makes it possible for an application to know
a patient's current list of treating facilities. Furthermore, CIRN has
assumed responsibility for supervising the proper configuration and activation
of the VA network nodes that will be used for HL7 message exchange.\n
Parameters:
(location<station #>,rpc name,[rpc version],[1 to 10 params to the RPC])\n
Return:
The return value is the array of data. In the case of an error condition,
the first node of the array is equal to a string with the syntax "-1^error
text".", "", "", ""], ["3033", "Deferred RPCs", "Remote Procedure", "RPC BROKER", "2000/02/03", "", "Withdrawn", "Supported", "", "
This describes the Broker RPCs that are used in support
of running a RPC as a background task.\n
This RPC will return a HANDLE that can be used to check if the data has
returned. The HANDLE can be used in another RPC to check the status of the
RPC.\n
XWB DEFERRED RPC
This is the RPC that is called to request that a RPC be run through taskman
in the background.\n
Parameters:
(rpc name[^rpc version],[1 to 10 params to the RPC])\n
Return:
The return value is always an array. The first node of the array is equal
to a string that serves as a HANDLE. This is used to check the status of a RPC
request and to retrieve the results of the RPC.
In the case of an error condition, the first node of the array is equal to a
string with the syntax "-1^error text".\n
XWB DEFERRED STATUS
This RPC will return the status of a deferred RPC.\n
Parameters:
The HANDLE from the XWB DEFERRED RPC.\n
Return:
The return value is always an array. The first node of the array is equal to
one of the following values:
"-1^Bad Handle" - An invalid handle has been passed.
"0^New" - The request has been sent.
"0^Running" - RPC is still processing
"1^Done" - RPC has completed and the data has returned to the local
server. The data is not returned by this RPC. Use the XWB REMOTE
GETDATA RPC to retrieve the data.\n
XWB DEFERRED GETDATA
This RPC is used to return the data from the XWB DEFERRED RPC call.\n
Parameters:
The HANDLE from the XWB DEFERRED RPC. It is used to link the call to the
data.\n
Return:
The return value is the array of data. In the event of an error
condition, the first node of the array is equal to a string with the
syntax "-1^error text".\n
XWB DEFERRED CLEAR
This RPC is used to CLEAR the data under the HANDLE in the ^XTMP global.\n
Parameters:
The HANDLE from the XWB DEFERRED RPC.\n
Return:
The return value is always an array. The first node of the array is
equal to 1.\n
XWB DEFERRED CLEARALL
This RPC is used to CLEAR ALL the data known to this job in the ^XTMP
global. Makes use of the list in ^TMP("XWBHDL",$J,handle).\n
Return:
The return value is always an array. The first node of the array is
equal to 1.", "", "", ""], ["3034", "DRUG ACCOUNTABILITY", "File", "PHARMACY DATA MANAGEMENT", "2000/02/04", "", "Withdrawn", "Private", "59.7", "\n
When the Drug Acountability package is trying to link the Drug/Item file,
the last drug linked is stored in the LAST DRUG LINKED (#70) field. This
field is also used as a point at which to resume the loop upon re-entry.", "", "", ""], ["3035", "DBIA3035-A", "Routine", "PCE PATIENT CARE ENCOUNTER", "2003/05/29", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V CPT (#9000010.18) file. The V CPT (#9000010.18) file is used to
store CPT related services performed during a visit.", "", "PXAAVCPT", ""], ["3036", "HL7 APPLICATION PARAMETER LOOKUP", "File", "HEALTH LEVEL SEVEN", "2000/02/15", "APPROVED", "Active", "Private", "771", "
This IA will allow MPI/PD to lookup an entry in the HL7
APPLICATION PARAMETER (#771) file using DBS FileMan calls.\n
The IA is needed because of the release of two seperate but related patches.
DG*5.3*261 exports the ADT/HL7 EVENT REASON (#391.72) file which has a field
named HL7 APPLICATION PARAMETER (#.02). This field is a pointer to the HL7
APPLICATION PARAMETER (#771) file. Our data in ADT/HL7 EVENT REASON file is
initially exported with the HL7 APPLICATION PARAMETER blank. The HL7
APPLICATION PARAMETER required for this field is being exported in RG*1.0*4.\n
RG*1.0*4 adds the HL7 APPLICATION PARAMETER, and a post-install process adds
that data to the ADT/HL7 EVENT REASON file. Our IA will permit our
post-install process to lookup the new application with silent FileMan calls
and subsequently add that data to the ADT/HL7 EVENT REASON file.", "", "", ""], ["3037", "ADT/HL7 EVENT REASON (#391.72) file access", "File", "REGISTRATION", "2000/02/15", "APPROVED", "Active", "Private", "391.72", "
This IA allows the subscribing package to access the
ADT/HL7 EVENT REASON (#391.72) file.", "", "", ""], ["3038", "DBIA3035-B", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V HEALTH FACTORS (#9000010.23) file. The V HEALTH FACTORS
(#9000010.23) file is used for storing patient health factors identified
during a visit.", "", "PXAAVHF", ""], ["3039", "TIU GET STATUS LIST", "Routine", "TEXT INTEGRATION UTILITIES", "2000/02/15", "APPROVED", "Active", "Controlled Subscription", "", "
This API returns the list of allowable signature
statuses supported by TIU.", "", "TIUSRVL", ""], ["3040", "Direct set DD node", "File", "1", "2000/02/15", "APPROVED", "Active", "Private", "", "
Agreement allowing the direct setting of the
^DD(file,0,"ACT") node.", "", "", ""], ["3041", "ACCESS TO FILE 20 NAME COMPONENTS", "File", "KERNEL", "2000/02/16", "APPROVED", "Active", "Controlled Subscription", "20", "
All fields can be accessed/edited using FileMan tools.
Each entry in the NAME COMPONENTS file (#20) corresponds to a single source
name field in another file. The following three fields in the NAME COMPONENTS
file contain information about the source name field. These three fields
comprise the Primary Key for the NAME COMPONENTS file.\n
.01 File Number of file that contains source name field
.02 Field Number of the field that contains the source name field
.03 IENS (Internal Entry Number string) of the record that contains the
name to which this entry corresponds.\n
The name field in the source file should have cross-references that keep its
value in synchronization with the corresponding entry in the NAME COMPONENTS
file. For an example of this, see the .01 field of the NEW PERSON file.\n
The following fields are normally available for editing by end-users.\n
Field # Name
1 FAMILY (LAST) NAME
2 GIVEN (FIRST) NAME
3 MIDDLE NAME
4 PREFIX (ex., MR, MS)
5 SUFFIX (ex., JR, III, ESQ)
6 DEGREE (ex., PHD)\n
(The DEGREE and PREFIX field are not part of the source name field (#.01) of
the NEW PERSON file.) Kernel APIs that return the name components are
available.\n
When any of the following fields in the NAME COMPONENTS file are edited via
FileMan tools:\n
Field # Name
.01 FILE
.02 FIELD
.03 IENS
1 FAMILY (LAST) NAME
2 GIVEN (FIRST) NAME
3 MIDDLE NAME
5 SUFFIX
7 SOURCE NAME FORMAT FLAGS\n
the "ANAME" MUMPS cross-reference automatically updates the corresponding
source name field in the source file to reflect the changes. To prevent this
cross-reference from firing, you can NEW the variable XUNOTRIG and SET it to 1
before editing the any of the above fields.", "", "", ""], ["3042", "SINGLE PROCEDURE DISPLAY API", "Routine", "CLINICAL PROCEDURES", "2000/02/16", "APPROVED", "Active", "Private", "", "\n\n\n
This DBIA authorizes CONSULT/REQUEST TRACKING to call ^MCAPI for the purpose
of retrieving a single patient procedure and displaying the selected procedure
in the Consult/Request Tracking Package.\n", "", "MCAPI", ""], ["3043", "DBIA3035-C", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V IMMUNIZATION (#9000010.11) file. The V IMMUNIZATION (#9000010.11)
file is used to store immunizations specific to a particular visit for a
particular patient. This file contains one record for each immunization.", "", "PXAAVIMM", ""], ["3044", "DBIA3035-D", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V MEASUREMENT (#9000010.01) file. The V MEASUREMENT (#9000010.01)
file is used to store measurements such as; weight, height, blood pressure,
etc., taken by a health professional during an outpatient encounter.", "", "PXAAVMSR", ""], ["3045", "DBIA3035-E", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V PATIENT ED (#9000010.16) file. The V PATIENT ED (#9000010.16) file
is used to store stores the patient education given to a patient or his
responsible care given.", "", "PXAAVPED", ""], ["3046", "DBIA3035-F", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V POV (#9000010.07) file. The V POV (#9000010.07) file is used to
store clinical data related to the "purpose of visit" or "problem of visit",
(POV).", "", "PXAAVPOV", ""], ["3047", "DBIA3035-G", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V PROVIDER (#9000010.06) file. This file, along with a Purpose of
Visit (POV), is required for each patient encounter at a facility.", "", "PXAAVPRV", ""], ["3048", "DBIA3035-H", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Controlled Subscription", "", "
The following is a description of the available APIs
for the VISIT (#9000010) file. The VISIT (#9000010) file contains a record of
all patient visits at health care facilities or by health care providers,
including direct outpatient and clinic visits, as well as inpatient encounters
with providers of care.", "", "PXAAVSIT", "2023/08/30"], ["3049", "DBIA3035-I", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V SKIN TEST (#9000010.12) file. The V SKIN TEST (#9000010.12) file
stores record details for each type of skin test given to a patient on a given
visit.", "", "PXAAVSK", ""], ["3050", "DBIA3035-J", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V TREATMENT (#9000010.15) file. The V TREATMENT (#9000010.15) file
stores a record for each treatment provided to a patient on a given patient
visit.", "", "PXAAVTRT", ""], ["3051", "DBIA3035-A", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/02/22", "APPROVED", "Active", "Supported", "", "
The following is a description of the available APIs
for the V EXAM (#9000010.13) file. The V EXAM (#9000010.13) file stores exam
information, one record for each exam for each visit.", "", "PXAAVXAM", ""], ["3052", "Nursing Ward Location API", "Routine", "NURSING SERVICE", "2000/02/24", "APPROVED", "Active", "Supported", "", "
Patch NUR*4*31 introduces a new supported Application
Programming Interface(API). This API provides a "Query" and "Look-up" on the
NURS LOCATION file (#211.4). This DBIA was developed as a way to provide
access to File #211.4 and allow Nursing to retire two existing private DBIAs.", "", "NURSUT5", ""], ["3053", "Obtain Description for PAID Code", "Routine", "PAID", "2000/02/29", "APPROVED", "Active", "Private", "", "
This IA allows the ASISTS package to call routine
PRSDUTIL to obtain a description of a code from the following tables in the
PAID CODE FILES (#454).\n
Use OT^PRSDUTIL for the following tables:
Table Subscript
---------- ---------
PAY BASIS PB
PAY PLAN PP
RETIREMENT RET
EDUCATION EDU\n
Use OST^PRSDUTIL for the OCCUPATION SERIES/TITLE table.", "", "PRSDUTIL", ""], ["3054", "DBIA3054", "File", "PCE PATIENT CARE ENCOUNTER", "2000/02/29", "APPROVED", "Active", "Private", "9000001", "
DG namespaced routine deletes PATIENT/IHS entries when
the patients that these entries point to in the PATIENT file are being
deleted.", "", "", ""], ["3055", "GET CODE MAPPING", "File", "PCE PATIENT CARE ENCOUNTER", "2000/03/01", "APPROVED", "Active", "Private", "811.1", "", "", "", ""], ["3056", "DNS lookup", "Routine", "KERNEL", "2000/03/01", "APPROVED", "Active", "Supported", "", "
Call a DNS to resolve Domain names.", "", "XLFNSLK", ""], ["3057", "SET~XUS1A", "Routine", "KERNEL", "2000/03/06", "APPROVED", "Active", "Supported", "", "
The is a API for use by code called from the XU USER
SIGN-ON protocol to pass text back to the user.", "", "XUS1A", ""], ["3058", "TIULX Document Class", "Routine", "TEXT INTEGRATION UTILITIES", "2000/03/08", "APPROVED", "Active", "Controlled Subscription", "", "
Text Integration Utilities Cross-reference library
functions.", "", "TIULX", ""], ["3059", "TIU(8925.1 Health Summary", "File", "TEXT INTEGRATION UTILITIES", "2000/03/08", "APPROVED", "Active", "Controlled Subscription", "8925.1", "
Access TIU DOCUMENT DEFINITION file #8925.1", "", "", ""], ["3060", "Reference to variable DICR", "Other", "1", "2000/03/08", "APPROVED", "Active", "Private", "", "
Reference to undocumented variable, DICR, for the
purpose of determining if lookup by patient is originating in a file other
than the PATIENT file.", "", "", ""], ["3061", "QAC ROLLUP FIELDS", "File", "QUALITY ASSURANCE INTEGRATION", "2000/03/09", "", "Withdrawn", "Private", "740", "
QAC Last Record field is being created to allow the
Patient Representative package (QAC) to keep track of the last record sent to
the national database. It is field #753.\n
QAC Rollup Task field is being created to hold the task number, at a site, of
the currently scheduled run of the QAC Data Rollup. The code will check,
before re-tasking the job, that the task has not already been scheduled. It
is field #754.", "", "", ""], ["3062", "TIULAPIS Selected Prog Note", "Routine", "TEXT INTEGRATION UTILITIES", "2000/03/09", "APPROVED", "Active", "Controlled Subscription", "", "
The routine TIULAPIS controls the branching for
extracting selected Progress Notes by occurrence, date or type for a given
patient.", "", "TIULAPIS", ""], ["3063", "PXRHS08 Patient Education", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/03/09", "APPROVED", "Active", "Controlled Subscription", "", "
Patient Education data extract.", "", "PXRHS08", ""], ["3064", "CONTROLLED SUBSTANCE API", "Routine", "OUTPATIENT PHARMACY", "2000/03/14", "APPROVED", "Active", "Private", "", "\n
When a prescription is returned to stock in Outpatient Pharmacy 7.0, the
entry is deleted from the prescription file. If the prescription was
a controlled substance, the pharmacy location's balance is not updated.
This API will check the prescription when it is being returned. If the
prescription is for a controlled substance, the user will be asked if they
want to update the balances for the associated pharmacy location.", "", "PSDOPT0", ""], ["3065", "Name Standardization APIs", "Routine", "KERNEL", "2000/03/15", "APPROVED", "Active", "Supported", "", "
Supported Name Standardization APIs.", "", "XLFNAME", ""], ["3066", "NAME COMPONENTS UPDATE", "Routine", "KERNEL", "2000/03/15", "APPROVED", "Active", "Controlled Subscription", "", "
Controlled Subscription Name Standardization APIs.", "", "XLFNAME2", ""], ["3067", "DISPLAY CONSULT PROCEDURE ORDER INFO", "File", "CONSULT/REQUEST TRACKING", "2000/03/16", "APPROVED", "Active", "Controlled Subscription", "123", "
PURPOSE: Provide Clinical Procedures with a way to
display Consult Procedure order information.", "", "", "2008/07/22"], ["3068", "DBIA3068", "Other", "HEALTH LEVEL SEVEN", "2000/03/22", "APPROVED", "Active", "Private", "", "
The Primary Care Management Module (PCMM) in Scheduling
requests permission to update the 'PCMM' entry in the HL7 APPLICATION
PARAMETER (#771) file. The following action will be performed during the post
initialization process of patch SD*5.3*210:\n
1. The Name (#.01) field of this entry will be changed from
'PCMM' to 'PCMM-210'.", "", "", ""], ["3069", "DBIA3069", "File", "KERNEL", "2000/03/22", "", "Pending", "Private", "200", "
PCMM requires direct read access to the Name (.01) and
SSN (#9) fields in the New Person (#200) for Programmer Management Advisory
board.", "", "", ""], ["3070", "SCAPMC Clinic List", "Routine", "SCHEDULING", "2000/03/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "SCAPMC", ""], ["3071", "ORX8", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2000/03/22", "APPROVED", "Active", "Controlled Subscription", "", "
This documents the function $$PKGID^ORX8(ORIFN), which
returns a package's order number or identifier given the CPRS order number.", "", "ORX8", ""], ["3072", "Return new or existing ICN", "Routine", "MASTER PATIENT INDEX VISTA", "2000/03/31", "APPROVED", "Active", "Controlled Subscription", "", "
This API will return an ICN if one exists or create and
return a Local ICN and updating the appropriate fileds if a Local was created.\n", "", "MPIF001", ""], ["3073", "determine the LAST TREATMENT DATE for a patient", "Routine", "CLINICAL INFO RESOURCE NETWORK", "2000/04/04", "APPROVED", "Active", "Private", "", "
This Integration Agreement (IA) will allow an
application to determine the LAST TREATMENT DATE for a single patient. The
events that define treatment are: patient admissions, patient discharges and
clinic checkouts.\n
This subroutine will trigger Master File Update (MFU) messages that update the
DATE LAST TREATED (#.07) field for the TREATING FACILITY LIST (#391.91) file.
The CIRN Master of Record (CMOR) and subscribers will have their TREATING
FACILITY LIST files updated.", "", "RGADT2", ""], ["3074", "RAD/NUC MED ORDERS FILE W/PROC. MODS", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2000/04/05", "APPROVED", "Active", "Controlled Subscription", "75.1", "
The following fields are being read from and written to
by subscribers to obtain and update patient specific radiology order data.\n
Please look carefully at the fields documented below to determine which can be
read from and written to.\n
Revision History:
- 9/11/24 added field #22 REQUESTING LOCATION with
patch MECH*1.0*1", "", "", "2023/10/04"], ["3075", "A7RCIRN GLOBAL", "Other", "NDBI", "2000/04/07", "", "Withdrawn", "Private", "", "", "", "", ""], ["3076", "ORQQPX SEARCH ITEMS", "Other", "ORDER ENTRY/RESULTS REPORTING", "2000/04/13", "APPROVED", "Active", "Controlled Subscription", "", "
Read access to the XPAR Parameter ORQQPX SEARCH ITEMS.", "", "", ""], ["3077", "Direct global access to the DRUG file (#50)", "File", "PHARMACY DATA MANAGEMENT", "2000/04/11", "", "Retired", "Private", "50", "
Pharmacy Data Management has defined certain data
change events within National Drug File that should delete certain fields in
the DRUG file (#50). To meet that request, National Drug File requests
permission to do direct global KILLs to nodes ^PSDRUG(D0,"DOS"),
^PSDRUG(D0,"DOS1"), and ^PSDRUG(D0,"DOS2").", "", "", ""], ["3078", "DBIA3078", "Routine", "CLINICAL REMINDERS", "2000/04/11", "APPROVED", "Active", "Controlled Subscription", "", "
These are the entry points for the PXRMRPCA routine:\n
1) ALIST^PXRMRPCA(.ORY,ORPT,.LIST) - Evaluate a list of reminders\n
2) APPL^PXRMRPCA(.ORY,ORPT,.LIST) - Evaluate reminders for CPRS cover sheet\n
3) CATEGORY^PXRMRPCA(.ORY,ORPT,ORLOC) - List of categories\n
4) LIST^PXRMRPCA(.ORY,ORPT,ORLOC) - List of reminders (unevaluated)\n
5) REMDET^PXRMRPCA(..ORY,ORPT,ORREM) - Clinical Maintenance display\n
6) WEB^PXRMRPCA(.ORY,ORREM) - Web sites for a reminder\n
Output is returned in ORY array", "", "PXRMRPCA", ""], ["3079", "DBIA3079", "Routine", "CLINICAL REMINDERS", "2000/04/11", "APPROVED", "Active", "Controlled Subscription", "", "
These are the entry points for the PXRMRPCB routine:\n
1) EDL^PXRMRPCB(.ORY,ORREM) - List education topics for a reminder\n
2) EDS^PXRMRPCB(.ORY,OREDU) - List sub-topics for an education topic\n
3) EDU^PXRMRPCB(.ORY,OREDU) - Display an education topic\n
Output is returned in ORY array", "", "PXRMRPCB", ""], ["3080", "CPRS REMOTE PROCEDURE CALLS", "Routine", "CLINICAL REMINDERS", "2000/04/11", "APPROVED", "Active", "Controlled Subscription", "", "
These are the entry points for routine PXRMRPCC:\n
1) ACTIVE^PXRMRPCC(.ORY,.LIST) - List active dialogs for selected reminders\n
2) DIALOG^PXRMRPCC(.ORY,ORREM) - Load a reminder dialog\n
3) HDR^PXRMRPCC(.ORY,ORLOC)- Progress Note Header by location/service/user\n
4) MH^PXRMRPCC(.ORY,ORTEST) - Load MH test details\n
5) MHR^PXRMRPCC(.ORY,ORMHR,.ORES) - Get MH test score and result (P/N text)\n
6) MHS^PXRMRPCC(.ORY,.ORES) - Save MH test results to MH package\n
7) MST^PXRMRPCC(.ORY,ORPT,ORDATE,ORSTAT,ORPROV,ORFTYP,ORFIEN,ORRES) - Update
MST\n
8) PROMPT^PXRMRPCC(.ORY,ORDLG,ORDCUR,ORFTYP,ORIEN) - Load additional
prompts\n
9) RES^PXRMRPCC(.ORY,ORREM) - Display reminder inquiry\n
10) WH^PXRMRPCC(.ORY,ORRESULT) - Save WH Exam Results to the WV package\n
Output is returned in the ORY array", "", "PXRMRPCC", "2018/06/18"], ["3081", "DBIA3081", "Other", "CLINICAL REMINDERS", "2000/04/12", "APPROVED", "Active", "Controlled Subscription", "", "
Read access to the following XPAR Parameter
Definitions:\n
PXRM GUI REMINDERS ACTIVE PXRM MENTAL HEALTH ACTIVE\n", "", "", ""], ["3082", "PROTOCOL Distribution", "Other", "REGISTRATION", "2000/04/17", "APPROVED", "Active", "Private", "", "
Clinical Information Resource Network (CIRN) is
establishing this integration agreement to include the following Registration
PROTOCOLS in CIRN builds, distributed as MERGE MENU ITEMS. The purpose of
including these event driver PROTOCOLS is to attach our subscriber PROTOCOLS
that are exported in the build.\n
Registration event driver PROTOCOLS
CIRN subscriber PROTOCOLS
------------------------------------------------
VAFC ADT-A04 SERVER
RG ADT-A04 TRIGGER
VAFC ADT-A08 SERVER
RG ADT-A08 TRIGGER", "", "", ""], ["3083", "Health Factors in Clinical Reminders and Health Summary", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/19", "APPROVED", "Active", "Private", "9999999.64", "
Health Factors are used as a finding in Clinical
Reminders. The Clinical Reminder Exchange Utility allows sites to exchange
Clinical Reminder definitions and all the associated components. Therefore
Clinical Reminders needs to read and write all fields in the file.", "", "", "2021/05/11"], ["3084", "DBIA3084", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Controlled Subscription", "9000010.23", "
Health Factors are used as a finding in Clinical
Reminders. Therefore Clinical Reminders needs to read the following fields.", "", "", "2009/06/08"], ["3085", "EDUCATION TOPICS IN CLINICAL REMINDERS AND HEALTH SUMMARY", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/19", "APPROVED", "Active", "Private", "9999999.09", "
Education Topics are used as a finding in Clinical
Reminders. The Clinical Reminder Exchange Utility allows sites to exchange
Clinical Reminder definitions and all the associated components. Therefore
Clinical Reminders needs to read and write all fields in the file.", "", "", "2021/05/11"], ["3086", "DBIA3086", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Private", "9000010.16", "
Education Topics are used as a finding in Clinical
Reminders. Therefore Clinical Reminders needs to read the following fields.", "", "", ""], ["3087", "EXAMS IN CLINICAL REMINDERS AND HEALTH SUMMARY", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/19", "APPROVED", "Active", "Private", "9999999.15", "
Exams are used as a finding in Clinical Reminders. The
Clinical Reminder Exchange Utility allows sites to exchange Clinical Reminder
definitions and all the associated components. Therefore Clinical Reminders
needs to read and write all fields in the file.", "", "", "2021/11/09"], ["3088", "DBIA3088", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Private", "9000010.13", "
Exams are used as a finding in Clinical Reminders.
Therefore Clinical Reminders needs to read the following fields.", "", "", ""], ["3089", "DBIA3089", "File", "PCE PATIENT CARE ENCOUNTER", "2004/07/15", "APPROVED", "Active", "Private", "9999999.14", "
Immunizations are used as a finding in Clinical
Reminders. The Clinical Reminder Exchange Utility allows sites to exchange
Clinical Reminder definitions and all the associated components. Therefore
Clinical Reminders needs to read and write all fields in the file.", "", "", ""], ["3090", "DBIA3090", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Private", "9000010.11", "
Immunizations are used as a finding in Clinical
Reminders. Therefore Clinical Reminders needs to read the following fields.", "", "", ""], ["3091", "DBIA3091", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/19", "APPROVED", "Active", "Private", "9999999.28", "
Skin Tests are used as a finding in Clinical Reminders.
The Clinical Reminder Exchange Utility allows sites to exchange Clinical
Reminder definitions and all the associated components. Therefore Clinical
Reminders needs to read and write all fields in the file.", "", "", ""], ["3092", "DBIA3092", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Private", "9000010.12", "
Skin Tests are used as a finding in Clinical Reminders.
Therefore Clinical Reminders needs to read the following fields.", "", "", ""], ["3093", "DBIA3093", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Private", "9000010.18", "
CPT procedures are used as a finding in Clinical
Reminders. Therefore Clinical Reminders needs to read the following fields.", "", "", ""], ["3094", "DBIA3094", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Controlled Subscription", "9000010.07", "
V POV diagnoses are used as a finding in Clinical
Reminders. Therefore Clinical Reminders needs to read the following fields.", "", "", ""], ["3095", "DBIA3095", "File", "PROBLEM LIST", "2000/05/16", "APPROVED", "Active", "Private", "9000011", "
Problem List diagnoses are used as a finding in
Clinical Reminders. Therefore Clinical Reminders needs to read the following
fields.", "", "", ""], ["3096", "DBIA3096", "File", "PCE PATIENT CARE ENCOUNTER", "2000/05/16", "APPROVED", "Active", "Private", "9999999.27", "
A Provider Narrative entry is associated with Problem
List, V POV, and V CPT entries. Each of these are used as a finding in
Clinical Reminders. The Provider Narrative is displayed in the Clinical
Maintenance output for each of this finding types. Therefore Clinical
Reminders needs to read the following field.", "", "", ""], ["3097", "DBIA3097", "File", "REGISTRATION", "2000/04/21", "APPROVED", "Active", "Controlled Subscription", "2", "", "", "", ""], ["3098", "HL7 APIs", "Routine", "HEALTH LEVEL SEVEN", "2000/04/24", "APPROVED", "Active", "Supported", "", "
APIs for HL7 package. These APIs are available after
patch HL*1.6*64.", "", "HLUTIL", ""], ["3099", "HL7 APIs", "Routine", "HEALTH LEVEL SEVEN", "2000/04/24", "APPROVED", "Active", "Supported", "", "
HL7 APIs for the routine HLCSUTL. These are available
after patch HL*1.6*64.", "", "HLCSUTL", ""], ["3100", "MPI-DNS domain set to send", "File", "MAILMAN", "2001/03/22", "APPROVED", "Active", "Private", "4.2", "
CIRN Patient Demographics has an agreement to do a read
with FileMan on the NAME (#.01) and FLAGS (#1) fields in the DOMAIN (#4.2)
file, as well as the TRANSMISSION SCRIPT (#4) multiple, the TRANSMISSION
SCRIPT (#.01) field, NETWORK ADDRESS (MAILMAN HOST) (#1.4) field and OUT OF
SERVICE (#1.5) field. This is used in environment check routine, RGP13ENV, to
ensure that the instructions in informational patch XM*DBA*144 have been
followed for domain MPI-DNS. The environment check routine will not allow
patch RG*1.0*13 to be installed in the production environment unless the FLAGS
field (#1) has been set to "S", the NETWORK ADDRESS (MAILMAN HOST) (#1.4)
field contains the correct address and the OUT OF SERVICE (#1.5) field is
null.", "", "", ""], ["3101", "DBIA3101", "File", "REGISTRATION", "2000/05/03", "APPROVED", "Active", "Private", "2", "
PCE name-spaced routine references $D(^DPT(IEN)) in
order to do a one-time file clean up.", "", "", ""], ["3102", "DBIA3102", "File", "TEXT INTEGRATION UTILITIES", "2000/05/03", "APPROVED", "Active", "Private", "8925", "
PCE name-spaced routine references
$D(^TIU(8925,"C",IEN)) in order to do a one-time file clean up.", "", "", ""], ["3103", "RESOURCE FILE MANAGEMENT", "File", "KERNEL", "2000/05/04", "APPROVED", "Active", "Private", "3.54", "
To prevent multiple jobs from running simultaneously
through a resource device, the device must be monitored. Also, if a job that
is utilizing a resource device fails, the device must be cleared manually.
This IA will allow the CMOP package to manage the PSX resource device and
prevent potentially harmful results from data merging.", "", "", ""], ["3104", "Direct Read of USR ACTION FILE (#8930.8)", "File", "AUTHORIZATION/SUBSCRIPTION", "2001/03/26", "APPROVED", "Active", "Private", "8930.8", "
TIU frequently sends "You may not..." messages such as
"You may not ATTACH this UNSIGNED TELEPHONE NOTE TO AN ID NOTE."\n
In order to create such messages, TIU reads the B cross-reference of file
8930.8 to get the record number of a given action, and then reads pieces 5 and
7 of the 0 node to get the USER VERB and the USER VERB MODIFIER for the given
action, for use in feedback messages such as the one above.", "", "", ""], ["3105", "TASK FILE LOOKUP", "File", "KERNEL", "2000/05/04", "APPROVED", "Active", "Private", "", "
The CMOP package requests the ability to perform a
check against a lock being held on ^%ZTSCH("TASK",ZTSK) to enable a background
reset of the resource device PSX.", "", "", ""], ["3106", "Problem List direct views of DIC(49", "File", "KERNEL", "2000/05/04", "APPROVED", "Active", "Private", "49", "
This DBIA documents direct global references made by
Problem List to the SERVICE/SECTION file (#49). These references are used by
Problem List to retrieve the service abbreviation from file 49. This data is
then provided to Health Summary for display.", "", "", ""], ["3107", "DBIA3107", "Routine", "PHARMACY DATA MANAGEMENT", "2000/05/08", "APPROVED", "Active", "Private", "", "
National Drug File requests permission to call entry
points in the Pharmacy Data Management package to perform updates related to
matching, re-matching and un-matching Dispense Drugs in the DRUG file (#50) to
and from NDF VA Products in the VA PRODUCT file (#50.68).\n
Note: These entry points should only be used for approved drug matching,
re-matching and un-matching functions.", "", "PSSUTIL", ""], ["3108", "DGMST ENTER NEW MST", "Other", "REGISTRATION", "2000/05/10", "APPROVED", "Active", "Private", "", "
The Women's Health (WH) package requests permission to
add the MST Status Add/Edit [DGMST ENTER NEW MST] option onto any WH menu.
This option will permit WH users to add/edit Military Sexual Trauma (MST) data
directly into the MST module of the Registration package without having to
exit the WH package menu structure.\n
Screening veterans for MST is required by the Veterans Millennium Health Care
and Benefits Act (PL 106-117). Adding the MST Status Add/Edit [DGMST ENTER NEW
MST] option to a WH package menu will aid the WH users to enter the screening
data for their patients.\n
The WH package will use a supported KERNEL API ($$ADD^XPDMENU) to add the
facility's copy of the option onto the WH menu. The WH pacakge will not export
a copy of the DGMST ENTER NEW MST option.", "", "", ""], ["3109", "DBIA3109", "Other", "REGISTRATION", "2000/05/12", "APPROVED", "Active", "Private", "", "
IB requests permission to check for the DG ELIGIBILITY
security key. This check is used to allow the updating of fields Date of
Birth, Sex, Marital Status, Veteran(Y/N), and Primary Eligibility while
creating a bill.", "", "", ""], ["3110", "DBIA3110", "File", "ORDER ENTRY/RESULTS REPORTING", "2000/05/16", "APPROVED", "Active", "Controlled Subscription", "101.41", "\n\n", "", "", ""], ["3111", "DBIA3111", "File", "NATIONAL DRUG FILE", "2000/05/17", "", "Retired", "Private", "50.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
VA GENERIC entries are used as findings in Clinical Reminders. Therefore
Clinical Reminders needs to point at the following fields.", "", "", ""], ["3112", "DBIA3112", "File", "GEN. MED. REC. - VITALS", "2000/05/17", "APPROVED", "Active", "Private", "120.51", "
GMRV VITAL TYPE entries are used as findings in
Clinical Reminders. Therefore Clinical Reminders needs to point to GMRV VITAL
TYPE entries. It also needs the PCE ABBREVIATION for reminder dialogs.", "", "", ""], ["3113", "DBIA3113", "File", "MENTAL HEALTH", "2000/05/17", "APPROVED", "Active", "Controlled Subscription", "601.6", "", "", "", ""], ["3114", "DBIA3114", "Other", "PCE PATIENT CARE ENCOUNTER", "2000/05/18", "APPROVED", "Active", "Private", "", "
Clinical Reminders is being split out of PCE. As part
of the split the reminder disclaimer is being moved from the PCE parameter
file to the Clinical Reminders parameter file. This makes the PCE options to
manage the disclaimer obsolete. As a service to PCE the Clinical Reminders
installation will clean up the obsolete options. The specific actions are:\n
Re-distributing the following PX prefixed options.
1 PX HS DISCLAIMER EDIT Distributed as Delete Site
2 PX HS/RPT PARAMETER MENU Changed the description text, removing
text
about the disclaimer.
3 PX HS/RPT PARAMETERS PRINT Changed the description text
4 PX REPORT PARAMETER EDIT Distributed as Attach to Menu\n
Redistributing the print template option PCE HS/RPT PARAMETERS PRINT used by
the PX HS/RPT PARAMETER PRINT option. Display of the disclaimers was removed,
and added text to refer to the new option to manage the disclaimer.\n\n", "", "", ""], ["3115", "DBIA3115", "Other", "HEALTH SUMMARY", "2000/05/19", "APPROVED", "Active", "Private", "", "
When a reminder manager is creating a Clinical Reminder
definition they may often need access to certain options from other packages.
As a convenience for users, Clinical Reminders would like to offer the PXRM
OTHER SUPPORTING MENUS option to provide easy access to these useful options.
Clinical Reminders would like to include the option GMTS COORDINATOR on this
menu.", "", "", ""], ["3116", "DBIA3116", "Other", "AUTOMATED INFO COLLECTION SYS", "2000/05/19", "APPROVED", "Active", "Private", "", "
When a reminder manager is creating a Clinical Reminder
definition they may often need access to certain options from other packages.
As a convenience for users, Clinical Reminders would like to offer the PXRM
OTHER SUPPORTING MENUS option to provide easy access to these useful options.
Clinical Reminders would like to include the option IBDF PRINT BLNK ENCOUNTER
FORM on this menu.", "", "", ""], ["3117", "DBIA3117", "Other", "ORDER ENTRY/RESULTS REPORTING", "2000/05/19", "APPROVED", "Active", "Private", "", "
When a reminder manager is creating a Clinical Reminder
definition they may often need access to certain options from other packages.
As a convenience for users, Clinical Reminders would like to offer the PXRM
OTHER SUPPORTING MENUS option to provide easy access to these useful options.
Clinical Reminders would like to include the option ORCM QUICK ORDERS on this
menu.", "", "", ""], ["3118", "DBIA3118", "Other", "PCE PATIENT CARE ENCOUNTER", "2000/05/19", "APPROVED", "Active", "Private", "", "
When a reminder manager is creating a Clinical Reminder
definition they may often need access to certain options from other packages.
As a convenience for users, Clinical Reminders would like to offer the PXRM
OTHER SUPPORTING MENUS option to provide easy access to these useful options.
Clinical Reminders would like to include the options PX PCE COORDINATOR MENU
and PXTT TABLE MAINTENANCE on this menu.", "", "", ""], ["3119", "Consult Default Reason for Request", "Routine", "CONSULT/REQUEST TRACKING", "2000/05/18", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMRCDRFR", ""], ["3120", "UNLINK RESULTS", "Routine", "CONSULT/REQUEST TRACKING", "2000/05/18", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMRCDIS", ""], ["3121", "Consult Ordering Utilities", "Routine", "CONSULT/REQUEST TRACKING", "2000/05/18", "APPROVED", "Active", "Controlled Subscription", "", "
Consult/Request Tracking provides utilities to CPRS for
the purpose of retrieving information about certaing consult orderables during
the ordering process.", "", "GMRCUTL1", ""], ["3122", "GUI resulting utilities for consults", "Routine", "CONSULT/REQUEST TRACKING", "2000/05/18", "APPROVED", "Active", "Controlled Subscription", "", "
Consult/Request Tracking provides utlities for
retrieving result information about a particular consult request. These
utilities are called by the CPRS GUI during the resulting of Consult procedure
requests.", "", "GMRCGUIU", ""], ["3123", "DBA3123", "File", "HEALTH LEVEL SEVEN", "2000/06/08", "APPROVED", "Active", "Private", "774", "
Ability to delete subscription record (file 774) with
FileMan when deleting the pointer to that record in the MPI node of the
Patient file (#2). This is necessary for duplicate record merge.", "", "", ""], ["3124", "DBIA3124", "Routine", "INTEGRATED BILLING", "2000/05/23", "APPROVED", "Active", "Private", "", "
Routine call to return ^TMP("IBRBT",$J,IBIFN,n and
^TMP("IBRBF",$J,IBIFN,n arrays which contain third party bill information and
first party bill information respectively.\n
The purpose of this call is to find associated Third and First Party bills.
The call returns arrays containing Third and First Party bills that cover the
same episodes of care as the Third Party bill that is passed in as input.", "", "IBRFN", ""], ["3125", "RADIOLOGY EXAM DATA RETURN (SLC)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2000/05/24", "APPROVED", "Active", "Controlled Subscription", "70", "
This Integration Agreement (IA) allows access to the
^RADPT global at the EXAMINATIONS (#70.03) sub-file level to obtain radiology
exam specific data for a patient within a date range or for a patient with a
PCE visit.", "", "", ""], ["3127", "DBIA3127", "File", "TOOLKIT", "2000/06/01", "APPROVED", "Active", "Controlled Subscription", "8989.51", "
Requesting read access/fileman to all fields in the
PARAMETER DEFINITION FILE (#8989.51) to retrieve the Clinical Procedures
Parameter definitions. Clinical Procedures is a strictly GUI application and
includes a Manager executable to setup and maintain site files and system
parameters. Additionally a lookup on the parameter definition file by name
screening by Entity Type allow for retrieval of all parameters for a specific
entity (i.e. Division) and display/update of these values. With the
information retrived from file 8989.51 this application dynamically configures
input screens for the user and sends data back to the server for the XPAR
API's to add/edit/delete parameter values in the XPAR utilities. Access is
read-only via GETS^DIQ, GET1^DIQ, FIND^DIC, and FIND1^DIC and is programmed to
only allow access to parameters in the subscribing package namespace.", "", "", ""], ["3128", "Direct Read of USR ROLE FILE (#8930.2)", "File", "AUTHORIZATION/SUBSCRIPTION", "2001/03/26", "APPROVED", "Active", "Private", "8930.2", "
In evaluating whether a user can perform a particular
action on a given TIU document, TIU needs the record number in the USER ROLE
FILE of each role played by that person with respect to the document. These
roles are determined by examining various fields of the document, and then the
role record number is read from the B cross-reference of the USER ROLE FILE.", "", "", ""], ["3129", "Direct Read of USR AUTHORIZATION/SUBSCRIPTION FILE", "File", "AUTHORIZATION/SUBSCRIPTION", "2001/03/26", "APPROVED", "Active", "Private", "8930.1", "
Document Definition titles for Interdisciplinary Notes
may not be used for both ID parent and ID child notes. If there are rules
permitting a title to be used for ID parent notes, any existing rules allowing
it to be used for ID child notes are ignored.\n
Therefore, ID notes needs to know if rules exist permitting a title to be used
as an ID parent.\n
To evaluate this, TIU reads the AR and AC cross-references of the
AUTHORIZATION/SUBSCRIPTION FILE (#8930.1).", "", "", ""], ["3130", "DBIA3130", "Routine", "INTEGRATED BILLING", "2000/06/13", "APPROVED", "Active", "Private", "", "
This function returns the primary division associated
with the care on a Third Party bill.", "", "IBJDF2", ""], ["3131", "DBIA3131", "Other", "ORDER ENTRY/RESULTS REPORTING", "2000/06/19", "", "Withdrawn", "Private", "", "
This DBIA is used to document Clinical Procedures
exporting the protocol OR EVSEND GMRC as USE AS LINK FOR MENU ITEMS so the
protocol MD RECEIVE will be linked to the OR EVSEND GMRC protocol.", "", "", ""], ["3132", "DBIA3132", "Routine", "NDBI", "2000/06/20", "APPROVED", "Active", "Controlled Subscription", "", "
Call HXDATA^A7RDPAGU from inside an RPC. This routine
is already being called by CPRS. It is similar to the call of A7RDPACT by
DGSEC whenever a patient is looked up.\n
Both A7RDPAGU and A7RDPACT refer to National Database Integration routines
which check whether a patient has historical data on a Legacy system.", "", "A7RDPAGU", ""], ["3134", "DBIA3134", "Routine", "CLINICAL REMINDERS", "2000/06/23", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXRMXX", ""], ["3135", "OR EVSEND GMRC", "Other", "ORDER ENTRY/RESULTS REPORTING", "2000/06/27", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when a new order, or
action to an order, is placed to the Consult/Request Tracking package.
Actions from any application area that are dependent on this event may be
added as Items upon approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order to Consults as defined in the 'OE/RR
Version 3 Package Interface Specifications' document.", "", "", ""], ["3136", "Health Summary Component Outpat Pharm (RXOP)", "File", "PHARMACY DATA MANAGEMENT", "2000/06/28", "", "Retired", "Private", "59.7", "
This agreement will be retired on 12/31/2006. Please do
not add any
additional code that utilizes this Integration Agreement. APIs have been
created that can be used in place of any code needing to make use of this
agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code
that currently utilizes this Integration Agreement must be converted to
use the new API's. If any part of this Integration Agreement cannot be
satisfied with the APIs, please contact the PRE development team mail
group at EMAIL GROUP DEV using Microsoft Outlook.\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy
packages are still allowed to utilize this agreement past the expiration
date of December 31, 2006. Health Summary needs to access the parameters
of the Pharmacy System to determine the appropriate displays for Outpatient
Pharmacy components.", "", "", ""], ["3137", "ORUS List Processor", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2000/06/28", "APPROVED", "Active", "Private", "", "
ORUS is a utility, which presents a user with a list of
entries in a columnar format and allows selection from this list. It is
possible to allow multiple items to be selected at one time. Selections made
are returned in Y. Since the selections are returned in Y, M code used for
screens, display actions, etc., must not change Y. Y(n) may not be
sequential, so Y should be processed with $O when returned.\n
Note: In order to allow multiple selections, the characters comma (,), dash
(-), equal (=), and apostrophe(') are reserved. Items presented on this list
should not contain these characters. Items should also be displayed in
uppercase.\n
Upon entry ORUS and ORUS(0) must be defined. All other ORUS variables are
optional.", "", "ORUS", ""], ["3138", "DBIA3138", "Routine", "CLINICAL PROCEDURES", "2000/06/28", "", "Retired", "Private", "", "
This DBIA is used to document the usage of the API
$$PDATETM^MDCON(MDINST).", "", "MDCON", ""], ["3139", "DBIA3139", "File", "CLINICAL PROCEDURES", "2000/06/28", "APPROVED", "Active", "Controlled Subscription", "702.01", "", "", "", ""], ["3140", "GMRC EVSEND OR", "Other", "CONSULT/REQUEST TRACKING", "2000/08/10", "APPROVED", "Active", "Controlled Subscription", "", "
The protocol name GMRC EVSEND OR is exported as USE AS
LINK FOR MENU ITEMS. This linkage will allow packages to monitor order
activity messages.", "", "", ""], ["3142", "DBIA3142", "Routine", "OUTPATIENT PHARMACY", "2000/07/13", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the Clinical Reminders package to
call the Outpatient Pharmacy package for patient and prescription information,
based on a specified date range and a specified list of medications.", "", "PSOORAPI", ""], ["3143", "DBIA3143", "Routine", "INPATIENT MEDICATIONS", "2000/07/13", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the Clinical Reminders package to
call the Inpatient Medications V.5.0 package for patient and order
information, based on a specified date range and a specified list of
medications.", "", "PSJORAPI", ""], ["3144", "DIRECT RPC CALL", "Routine", "RPC BROKER", "2000/10/27", "", "Active", "Controlled Subscription", "", "
This call is to make a RPC call on a remote facility.
Users of this API should be prepared to modifiy their calls to support support
strong authentication when made available by Infrastructure.", "", "XWB2HL7", ""], ["3145", "Health Summary Admissions Treating Spec", "File", "REGISTRATION", "2000/07/14", "APPROVED", "Active", "Private", "42.4", "
Retrieval and display of recognized PTF treating
specialties.", "", "", ""], ["3146", "TIU use of PXUTL1", "Routine", "PCE PATIENT CARE ENCOUNTER", "2001/09/27", "APPROVED", "Active", "Private", "", "
TIU calls $$APPOINT^PXUTL1, when the Visit IEN is not
available, to check if a Visit is associated with an appointment.", "", "PXUTL1", ""], ["3147", "Health Summary Facility Treating Specialty", "File", "REGISTRATION", "2000/07/14", "APPROVED", "Active", "Private", "45.7", "", "", "", ""], ["3148", "Health Summary Reminders/Maint Items (GUI)", "File", "CLINICAL REMINDERS", "2000/07/20", "APPROVED", "Active", "Controlled Subscription", "811.9", "", "", "", ""], ["3149", "XWBDRPC", "Routine", "RPC BROKER", "2000/07/26", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains API's for deferred RPC's used by
HL7 utilities.", "", "XWBDRPC", ""], ["3150", "DBIA 3150", "File", "1", "2003/06/10", "", "Retired", "Private", "50.7", "
The Pharmacy Data Management (PDM) application would
like to ask permission to create a new data dictionary global related to the
ORDERABLE ITEM file (# 50.7). The new global will be used to set the INACTIVE
DATE field (#.04) as an identifier in the ORDERABLE ITEM file (# 50.7).\n
Here is an example of the new DD global and contents.\n
^DD(50.7,0,"ID",.04) = W " ",$$FMTE^DILIBF($P(^(0),U,4),6)\n
The PSSP32 routine will contain the coding logic to set the new DD global.
The PSSP32 routine will only be used by PDM patch # 32 and KIDS will delete
the PSSP32 routine after the installation.\n
Here is a copy of the routine.\n
PSSP32 ;BIR/TTH-INACTIVE DATE FIELD IDENTIFIER ; 4-FEB-2000 14:17
;;1.0;PHARMACY DATA MANAGEMENT;**32**;9/30/97
;
ID ;In the ORDERABLE ITEM file (#50.7), set the INACTIVE DATE field
(#.04) a s an identifier.
S ^DD(50.7,0,"ID",.04)="W "" "",$$FMTE^DILIBF($P(^(0),U,4),6)"
Q", "", "", ""], ["3151", "ONCOLOGY DISEASE INDEX", "File", "PCE PATIENT CARE ENCOUNTER", "2000/07/28", "APPROVED", "Active", "Private", "9000010.07", "
ONCOLOGY needs to read with FileMan the following V POV
(9000010.07) fields for its [Disease Index] option:\n", "", "", ""], ["3152", "TIU use of PXBUTL2", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/07/31", "APPROVED", "Active", "Private", "", "
TIU calls PRV^PXBUTL2 to get the default provider.", "", "PXBUTL2", ""], ["3154", "Health Summary Current Orders", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2000/08/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORQ1", ""], ["3155", "TIU/Health Summary by Visit Date", "Routine", "TEXT INTEGRATION UTILITIES", "2000/08/01", "APPROVED", "Active", "Private", "", "
The routine TIULAPI controls the branching for
extracting documents by occurrence, date or type for a given patient.", "", "TIULAPI", ""], ["3156", "XLFCRC", "Routine", "KERNEL", "2000/08/04", "APPROVED", "Active", "Supported", "", "
This routine has two API's, CRC32 and CRC16.\n
SET CRC=$$CRC32^XLFCRC(string)\n
A check-sum can also be calculated over multiple strings.
SET (I,C)=0
FOR SET I=$ORDER(X(I)) QUIT:'I DO
. SET C=$$CRC16^XLFCRC(X(I),C)\n
or
SET I=0,C=4294967295
FOR SET I=$ORDER(X(I)) QUIT:'I DO
. SET C=$$CRC32^XLFCRC(X(I),C)\n
as long as the save method is used all the time.\n
These have been approved for inclusion in a future ANSI M[UMPS] language
standard as part of the library.", "", "XLFCRC", "2007/11/06"], ["3157", "PATIENT TREATMENT FILE DATA", "Routine", "REGISTRATION", "2000/08/07", "APPROVED", "Active", "Supported", "", "
This call (RPC^DGPTFAPI) will return data from the
Patient Treatment (#45) file. (This IA# is for the API and IA# 3164 is for
the RPC).\n
Input:
------
PTFNUMBR - The Patient Treatment IFN (.001 of the #45 file record)
RESULTS - Results array (passed by reference)\n
Output:
-------
RESULTS - Results array (passed by reference) with the following
nodes.
RESULTS(0) - 1 (entry found) OR -1 (error)
RESULTS(1) - Type of Disposition (#72)^Place of Disposition (#75)^
Principal Diagnosis (#79)^Coding System Version (pointer
to ICD Coding Systems #80.4 file)
RESULTS(2) - DX 2^DX 3^...^DX 24 (Secondary Diagnosis 2 through
Secondary Diagnosis 24)
RESULTS(3) - POA 1^POA 2^...^POA 25 (Present on Admission indicators
for Principal Diagnosis and Secondary Diagnosis 2 through
Secondary Diagnosis 24)", "", "DGPTFAPI", "2015/08/19"], ["3158", "$$CHECKDG", "Routine", "MASTER PATIENT INDEX VISTA", "2000/08/08", "APPROVED", "Active", "Controlled Subscription", "", "
$$CHECKDG^MPIFSPC calculates the checksum for a given
10 digit Integration Control Number (ICN).", "", "MPIFSPC", ""], ["3160", "PROCEDURE RESULTING", "Routine", "CONSULT/REQUEST TRACKING", "2000/08/09", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMRCMED", ""], ["3161", "Point to OR(100)", "File", "ORDER ENTRY/RESULTS REPORTING", "2000/08/09", "APPROVED", "Active", "Controlled Subscription", "100", "
This agreements documents the clinical packages that
have permission to point to the Orders file #100 from within their own package
files.", "", "", ""], ["3162", "POINT TO REQUEST/CONSULTATION (#123) FILE", "File", "CONSULT/REQUEST TRACKING", "2000/08/09", "APPROVED", "Active", "Controlled Subscription", "123", "
This Integration Agreement documents the clinical
packages that have permission to point to the REQUEST/CONSULTATION (#123)
file.", "", "", ""], ["3163", "ATTACH TO GMRC EVSEND OR", "Other", "CONSULT/REQUEST TRACKING", "2000/08/10", "", "Withdrawn", "Controlled Subscription", "", "
This event takes place when CPRS is updated as a result
of activity on Consult within Consult/Request Tracking.\n
Actions from any application area that are dependent on this event may be
added as Items upon approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order activity to CPRS as defined in the
'OE/RR Version 3 Package Interface Specifications' document.", "", "", ""], ["3164", "DG PATIENT TREATMENT DATA", "Remote Procedure", "REGISTRATION", "2000/08/14", "APPROVED", "Active", "Supported", "", "
This call (RPC^DGPTFAPI) will return data from the
Patient Treatment (#45) file. (This IA# is for the RPC and IA# 3157 is for the
API).\n
Input:
------
PTFNUMBR - The Patient Treatment IFN (.001 of the #45 file record)
RESULTS - Results array (passed by reference)\n
Output:
-------
RESULTS - Results array (passed by reference) with the following
nodes.
RESULTS(0) - 1 (entry found) OR -1 (error)
RESULTS(1) - Type of Disposition (#72)^Place of Disposition (#75)^
Principal Diagnosis (#79)^Coding System Version (pointer
to ICD Coding Systems #80.4 file)
RESULTS(2) - DX 2^DX 3^...^DX 24 (Secondary Diagnosis 2 through Secondary
Diagnosis 24)
RESULTS(3) - POA 1^POA 2^...^POA 25 (Present on Admission indicators for
Principal Diagnosis and Secondary Diagnosis 2 through
Secondary Diagnosis 24)", "DG PATIENT TREATMENT DATA", "", "2015/08/19"], ["3165", "DRUG FILE ACTIVITY LOG ADD/EDIT BY OUTPATIENT PHARMACY", "File", "PHARMACY DATA MANAGEMENT", "2000/08/14", "APPROVED", "Active", "Private", "50", "
CMOP functionality in the Outpatient Pharmacy
application has a need to enter comments into the ACTIVITY LOG field (# 214)
multiple of the Drug file (# 50).\n
This functionality also reads and sets the CMOP DISPENSE field (# 215) and its
index "^PSDRUG("AQ"," within the Drug file (# 50).\n
The node ^PSDRUG(D0,4,D1) is looped through to find the last entry in the
Activity Log multiple prior to inserting a new comment.\n
If the header node for the Activity Log field multiple is not present a header
node is inserted into the database.", "", "", ""], ["3166", "CALL FOR PSSDIN - NFI TEXT AVAIL. FOR ORD.ITEM/DISP.DRUG", "Routine", "PHARMACY DATA MANAGEMENT", "2000/08/15", "APPROVED", "Active", "Controlled Subscription", "", "
Outpatient Pharmacy, Inpatient Medications and
Computerized Patient Record System all request permission to call the function
provided by the Pharmacy Data Management package - routine name ^PSSDIN.\n
This call builds the temporary global ^TMP("PSSDIN" with the National
Formulary Indicator text for both orderable items and dispense drugs that are
marked as restricted items. Sending input of either orderable items or
dispense drugs is optional and the routine will only return text where it
receives either or both variables. The text may be displayed upon request.\n", "", "PSSDIN", ""], ["3167", "PSJORPOE API", "Routine", "INPATIENT MEDICATIONS", "2000/08/25", "APPROVED", "Active", "Private", "", "
Inpatient Medications is providing 3 entry points to
Computerized Patient Record System (CPRS) as a part of the Pharmacy Order
Enhancements project. 1) Entry point $$STARTSTP returns to CPRS the setting
for the DEFAULT START DATE CALCULATION for the ward the patient is on, Default
Start Date/Time based on the parameter, and the number of days or hours the
order would last. 2) Entry Point $$RESOLVE returns the parameter passed by
CPRS to be resolved and the Date/Time it was resolved to. 3) Entry point
$$SCHREQ returns a 1 if a schedule should be required for the order being
placed via the Inpatient Medications dialogue through CPRS or a 0 if no
schedule is required.", "", "PSJORPOE", "2011/06/08"], ["3168", "DBIA3168", "Routine", "TOOLKIT", "2000/08/16", "APPROVED", "Active", "Private", "", "
CIRN needs to use the Toolkit routine call
RMOVPAIR^XDRDVAL1 to remove pairs from the merge process based on CIRN
Exceptions.", "", "XDRDVAL1", ""], ["3169", "GLOBAL READ OF FILE 101.43", "File", "ORDER ENTRY/RESULTS REPORTING", "2000/08/21", "APPROVED", "Active", "Private", "101.43", "
Consult/Request Tracking utilizes global reads of the
global ^ORD(101.43, to facilitate a data conversion included in patch
GMRC*3*15.\n
This conversion only reads those orderable items of the Procedure type by
utilizing the "S.PROC" cross-reference.", "", "", ""], ["3170", "CHANGE ORDERABLE ITEM ID", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2000/08/21", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORDD43", ""], ["3171", "PRINT REPORT TO GLOBAL ARRAY", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2000/08/21", "APPROVED", "Active", "Controlled Subscription", "", "
The START^ORWRP call allows the opening of the OR
WORKSTATION device and printing of a report to that device, thereby returning
the text of the report in a global array descendant from ^TMP("ORDATA",$J,.", "", "ORWRP", ""], ["3172", "Special Printer Variables", "Routine", "KERNEL", "2000/08/28", "APPROVED", "Active", "Supported", "", "
Entry points for special printer variables.", "", "%ZISP", ""], ["3173", "XGF Function Library", "Routine", "KERNEL", "2000/08/28", "APPROVED", "Active", "Supported", "", "
This XGF Function Library supports terminals that are
ANSI-compatible and at least VT100-compatible. As a result, this software does
not support QUME QVT102/QVT102A terminals.\n
Programmer Tools > D ^XGFDEMO: Demo Program To run an interactive
demonstration showing the capabilities provided by the XGF Function Library,
you can run the XGF demo program. From the programmer prompt, type the
following: >D ^XGFDEMO <RET>\n
Functional Division of XGF Function Library Cursor/Text Output: IOXY^XGF,
SAY^XGF, SAYU^XGF. Keyboard Reader: $$READ^XGF. Setup/Cleanup: CLEAN^XGF,
INITKB^XGF, PREP^XGF, RESETKB^XGF. Text Window: CLEAR^XGF, FRAME^XGF,
RESTORE^XGF, SAVE^XGF, WIN^XGF. Video Attribute: CHGA^XGF, SETA^XGF.", "", "XGF", ""], ["3174", "DBIA3174", "Routine", "BAR CODE MED ADMIN", "2000/08/31", "APPROVED", "Active", "Private", "", "
The entry point EN^PSBIPM is provided by the Bar Code
Medication Administration (BCMA) package to provide information to Inpatient
Medications to be used in determining the start date for a renewed order.\n
The MOB entry point is used by Inpatient Medications to get information
obtained from the BCMA/CPRS Med Order function.\n
The MOBR is used by Inpatient Medications to notify BCMA that the order has
been accepted and processed by Inpatient Pharmacy.", "", "PSBIPM", ""], ["3175", "Measurement Functions", "Routine", "KERNEL", "2000/08/28", "", "Withdrawn", "Supported", "", "
This routine contains entry points to allow conversion
between U.S. (English) and Metric units.", "", "XLFMSMT", ""], ["3176", "DBIA3176-A", "Routine", "VBECS", "2003/09/16", "APPROVED", "Active", "Controlled Subscription", "", "
The entry point TRAN^VBECA4 is provided by the Blood
Bank package to collect transfusion record data based on the patient
identifier (DFN) value provided in the call. The API will create entries in
the ^TMP global for every record found by the function. This API will replace
the use of XTRCT^GMTSLRTE by Health Summary.", "", "VBECA4", ""], ["3177", "DBIA3176-B", "Routine", "VBECS", "2000/09/08", "APPROVED", "Active", "Controlled Subscription", "", "
The entry point AVUNIT^VBECA4 returns the available
units between two dates based on the patient identifier (DFN) value provided
in the call. The API will create entries in the ^TMP global for every record
found by the function. This API will replace the use of XTRCT^GMTSLRBE by
Health Summary.", "", "VBECA4", ""], ["3178", "Convert String to Soundex", "Routine", "KERNEL", "2000/08/29", "APPROVED", "Active", "Supported", "", "
Use this function to convert a string into a numeric
representation of the string, using soundex methods. Soundex represents the
phonetic properties of a string; its chief feature is that it assigns similar
strings the same soundex representation.", "", "XUA4A71", ""], ["3179", "3179", "Routine", "PHARMACY DATA MANAGEMENT", "2000/08/30", "APPROVED", "Active", "Private", "", "
This API provides Inpatient Medications and Outpatient
Pharmacy a means of getting the strength and unit for a specified drug from
the DRUG file (#50).", "", "PSSUTIL1", ""], ["3180", "DBIA 3180", "File", "1", "2000/08/29", "APPROVED", "Active", "Private", "27.16", "
There is a "LAYGO" node on the .01 field of ENROLLMENT
GROUP THRESHOLD file (#27.16). The code prevents any records from being added
to the file. Since there are no FileMan tools to remove a "LAYGO" node once
it's set, Enrollment would like permission to add an explicit KILL of the node
in a post-install routine. The line of code would be:\n
K ^DD(27.16,.01,"LAYGO")\n
The ENROLLMENT GROUP THRESHOLD file is part of the Enrollment package.", "", "", ""], ["3181", "DBIA3181-A", "Routine", "VBECS", "2003/09/16", "APPROVED", "Active", "Controlled Subscription", "", "
These API's are provided to return Blood Bank data to
subscribing packages.", "", "VBECA1", ""], ["3182", "DBIA3181-B", "Routine", "VBECS", "2000/09/06", "", "Retired", "Controlled Subscription", "", "
The entry point ABO^VBECA1 is provided by the Blood
Bank package to return data from the LAB DATA file (#63) including the field
ABO GROUP (#.05) for the DFN value provided in the call. The API will return
the value to the caller of the API for the record found.", "", "VBECA1", ""], ["3183", "DBIA3181-C", "Routine", "VBECS", "2000/09/06", "", "Retired", "Controlled Subscription", "", "
The entry point RH^VBECA1 is provided by the Blood Bank
package to return data from the LAB DATA file (#63) including the fields RH
TYPE (#.06) for the DFN value provided in the call. The API will return the
value to the caller of the API for the record found.", "", "VBECA1", ""], ["3184", "DBIA3181-D", "Routine", "VBECS", "2005/08/09", "", "Retired", "Controlled Subscription", "", "
The entry point ABID^VBECA1 is provided by the Blood
Bank package to return data from the ANTIBODIES IDENTIFIED sub-file (#63.075))
including the fields ANTIBODIES IDENTIFIED (#.01) and ANTIBODIES IDENTIFIED
COMMENT (#.02) for the DFN value provided in the call. The API will create an
array for each antibody record found by the function.", "", "VBECA1", ""], ["3185", "DBIA3181-E", "Routine", "VBECS", "2000/09/06", "", "Retired", "Controlled Subscription", "", "
The entry point AGAB^VBECA1 is provided by the Blood
Bank package to return data from the RBC ANTIGENS ABSENT (other) sub-file
(#63.016)) including the fields RBC ANTIGENS ABSENT (#.01) and RBC ANTIGENS
ABSENT COMMENT (#.02) for the DFN value provided in the call. The API will
create a .ARR array for every absent antigen record found by the function.", "", "VBECA1", ""], ["3186", "DBIA3181-F", "Routine", "VBECS", "2000/09/06", "", "Retired", "Controlled Subscription", "", "
The entry point AGPRES^VBECA1 is provided by the Blood
Bank package to return data from the RBC ANTIGENS PRESENT(other) sub-file
(#63.13)) including the fields RBC ANTIGENS PRESENT (#.01) and RBC ANTIGENS
PRESENT COMMENT (#.02) for the DFN value provided in the call. The API will
create a .ARR array for every antigen record found by the function.", "", "VBECA1", ""], ["3187", "DBIA3181-G", "Routine", "VBECS", "2005/08/09", "", "Retired", "Controlled Subscription", "", "
The entry point TRRX^VBECA1(DFN, .ARR) is provided by
the VistA Blood Establishment Computer Software (VBECS) package to return data
stored in 2 sub-files in the LAB DATA file (#63). The two sub-files and the
respective fields are: 1) TRANSFUSION RECORD sub-file (#63.017) at fields
TRANSFUSION DATE/TIME (#.01) and TRANSFUSION REACTION TYPE (#.11) which are
reactions that are associated with a particular transfusion; and 2)
TRANSFUSION REACTION DATE sub-file (#63.0171) at fields TRANSFUSION REACTION
DATE (#.01) and TRANSFUSION REACTION TYPE (#.02) which are reactions that
could not be associated with a particular transfusion episode. The
Application Programmer Interface (API) will build an array in which each
element will contain transfusion reaction data for the DFN value provided in
the call.", "", "VBECA1", ""], ["3188", "DBIA3181-H", "Routine", "VBECS", "2000/09/07", "", "Retired", "Controlled Subscription", "", "
The entry point BBCMT^VBECA1(DFN, .ARR) is provided by
the VistA Blood Establishment Computer Software (VBECS) package to return all
blood bank comments, for a particular patient, stored in BLOOD BANK COMMENTS
sub-file (#63.076) at field BLOOD BANK COMMENTS (.01). The Application
Programmer Interface (API) will build an array in which each element will
contain a record of the blood bank comments found for the DFN of the patient
provided in the function call.", "", "VBECA1", ""], ["3189", "DBIA3181-I", "Routine", "VBECS", "2000/09/07", "", "Retired", "Controlled Subscription", "", "
The entry point AUTO^VBECA1(DFN, .ARR) is provided by
the VistA Blood Establishment Computer Software (VBECS) package to return
data, for a particular patient, stored in the BLOOD INVENTORY file (#65) using
fields COMPONENT (.04), EXPIRATION DATE/TIME (#.06), and RESTRICTED FOR (#8).
The Application Programmer Interface (API) will build an array in which each
element will contain the available autologous units found for the DFN of the
patient provided in the call.", "", "VBECA1", ""], ["3190", "DBIA3190-A", "Routine", "VBECS", "2000/09/08", "", "Withdrawn", "Controlled Subscription", "", "
The entry point EN^VBECA3 is provided by the Blood Bank
package to collect data by calling EN^LR7OSBR with the Laboratory patient
identifier (LRDFN) value provided in the call. The API will create entries in
the ^TMP global for every record found by the function. This is a wrapper
call to replace the use of EN^LR7OSBR by CPRS.", "", "VBECA3", ""], ["3191", "DBIA3190-B", "Routine", "VBECS", "2000/09/08", "", "Withdrawn", "Controlled Subscription", "", "
The entry point EN1^VBECA3 is provided by the Blood
Bank package to collect data by calling EN1^LR7OSBR with the patient
identifier (DFN) value provided in the call. The API will create entries in
the ^TMP global for every record found by the function. This is a wrapper
call to replace the use of EN1^LR7OSBR by CPRS.", "", "VBECA3", ""], ["3192", "DBIA3192", "Routine", "VBECS", "2000/09/07", "", "Withdrawn", "Controlled Subscription", "", "
The entry point OBP^VBECA5 is provided by the VistA
Blood Establishment Computer Software (VBECS) package to return data found in
the BLOOD PRODUCT file (#66) in which the data found at the CAN BE REQUESTED
field (#. 15) is equal to "1". The Application Programmer Interface (API) will
create entries in the ^TMP global for the records found.", "", "VBECA5", ""], ["3194", "TIU AUTHORIZATION", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2000/09/12", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU AUTHORIZATION", "", ""], ["3195", "TIU CAN CHANGE COSIGNER?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/04/29", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU CAN CHANGE COSIGNER?", "", ""], ["3196", "GMVUTL7", "Remote Procedure", "GEN. MED. REC. - VITALS", "2000/09/13", "", "Withdrawn", "Private", "", "", "", "", ""], ["3197", "XQALBUTL", "Routine", "TOOLKIT", "2000/09/19", "APPROVED", "Active", "Supported", "", "
The DELSTAT entry point in XQALBUTL is a SUPPORTED
reference for obtaining information on the recipients of the most recent alert
with a specified alert id and the status of whether the alert has been deleted
or not for those recipients.\n
DELSTAT - For the most recent alert with XQAIDVAL as the PackageID passed in,
on return array VALUES contains the DUZ for users in VALUES along with an
indicator of whether the alert has been deleted or not, e.g., DUZ^0 if not
deleted or DUZ^1 if deleted. Note that contents of VALUES will be killed
prior to building the list.\n
Example: D DELSTAT^XQALBUTL("OR;14765;23",.RESULTS)\n
Returned: The value of RESULTS indicates the number of entries in
the array. The entries are then ordered in numerical
order in the RESULTS array.
RESULTS = 3
RESULTS(1) = "146^0" User 146 - not deleted
RESULTS(2) = "297^1" User 297 - deleted
RESULTS(3) = "673^0" User 673 - not deleted", "", "XQALBUTL", ""], ["3198", "TIU DOCUMENTS BY CONTEXT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2000/09/12", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU DOCUMENTS BY CONTEXT", "", ""], ["3201", "TIU IS THIS A CONSULT?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2006/11/06", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU IS THIS A CONSULT?", "", ""], ["3204", "TIU LONG LIST OF TITLES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU LONG LIST OF TITLES", "", ""], ["3205", "TIU PERSONAL TITLE LIST", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU PERSONAL TITLE LIST", "", ""], ["3208", "DBIA3208", "File", "CLINICAL INFO RESOURCE NETWORK", "2002/02/21", "APPROVED", "Active", "Private", "991.11", "
MPI-AUSTIN needs an integration agreement to support
direct reads to ^RGHL7(991.11 for the MPI exception handler.", "", "", ""], ["3209", "DDR GETS ENTRY DATA", "Remote Procedure", "1", "2000/09/20", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3210", "TIU UPDATE ADDITIONAL SIGNERS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU UPDATE ADDITIONAL SIGNERS", "", ""], ["3211", "DBIA3211", "File", "PCE PATIENT CARE ENCOUNTER", "2000/09/22", "APPROVED", "Active", "Private", "9000010", "
The Scheduling Package desires an Integration Agreement
with the PCE Package to access and update the #9000010 VISIT file. The .01
VISIT/ADMIT DATE&TIME field will be validated and updated if necessary.", "", "", ""], ["3213", "XQALSURO", "Routine", "KERNEL", "2000/09/27", "APPROVED", "Active", "Supported", "", "
This integration agreement adds two additional
SUPPORTED entry points or APIs to XQALSURO.\n
SETSURO1 should be used in the future instead of SETSURO to establish a
surrogate for alerts. SETSURO1 returns a value of 1 if the surrogate was
created successfully, otherwise, it returns a text string explaining why the
surrogate was not created. SETSURO simply added the specified surrogate, but
did not test for cyclic relationships (such that the user eventually would
become the surrogate). SETSURO1 does these tests and therefore has the
possibility of failure.\n
GETSURO is an API which can be used to obtain information about the current
surrogate, including start and end date/times if they are specified.\n
SUROLIST is an API which can be used to obtain a list of the current and
future surrogate periods for a selected user.\n
SUROFOR is an API which can be used to obtain a list of any current users that
the selected user is acting as a surrogate for.", "", "XQALSURO", "2009/07/29"], ["3214", "GMRYAPI", "Routine", "GEN. MED. REC. - I/O", "2000/10/16", "APPROVED", "Active", "Private", "", "
This routine provides entry points to return GEN. MED.
REC. - I/O (aka Intake and Output) data to the calling application.", "", "GMRYAPI", ""], ["3215", "DDR DELETE ENTRY", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3216", "DDR FILER", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3217", "DDR FIND1", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3218", "DDR FINDER", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3219", "DDR KEY VALIDATOR", "Remote Procedure", "1", "2000/09/20", "", "Withdrawn", "Private", "", "
This agreement indicates that the DDR KEY VALIDATOR RPC
necessary for use of the Fileman Delphi Components is a supported reference.", "DDR KEY VALIDATOR", "", ""], ["3220", "DDR GET DD HELP", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3221", "DDR LISTER", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3222", "DDR LOCK/UNLOCK NODE", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3223", "DDR VALIDATOR", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3224", "DDR KEY VALIDATOR", "Remote Procedure", "1", "2000/10/03", "APPROVED", "Active", "Supported", "", "
This RPC entry may be referenced from the Option file
to support invoking the RPC from its corresponding FM Delphi Component. The
RPC must not be invoked directly.", "", "", ""], ["3225", "Service Catagory Calculation API", "Routine", "PCE PATIENT CARE ENCOUNTER", "2000/10/05", "APPROVED", "Active", "Private", "", "
CPRS requests an integration agreement to call the
SVC^PXKCO routine. This routine calculates the appropriate service category
for an encounter, and is needed to correct problems with some encounters
generated in CPRS.", "", "PXKCO", ""], ["3226", "XUTMUTL", "Routine", "KERNEL", "2003/05/19", "", "Retired", "Supported", "", "
This routine has some supported API's for access to
Taskman data.", "", "XUTMUTL", ""], ["3227", "NURAPI", "Routine", "NURSING SERVICE", "2000/10/17", "APPROVED", "Active", "Private", "", "
This routine provides entry points to return Nursing
package data to the calling package.", "", "NURAPI", ""], ["3228", "VIEW MERGE IMAGES FOR FEE BASIS", "File", "TOOLKIT", "2000/10/18", "APPROVED", "Active", "Private", "15.4", "
This integration agreement permits the patch FB*3.5*19
post install to examine data in the MERGE IMAGES (#15.4) file. This data will
be used to identify and correct problems in the Fee Basis software that may
have occurred when patients were merged before installation of patch
FB*3.5*19.\n
In addition to reading data in the global, the post install will loop (using
$Order) through the following parts of the XDRM global to locate the Fee Basis
data.\n
XDRM(D0) loop thru all patient pairs in MERGED IMAGES file
XDRM(D0,1,"B", loop thru FROM FILE# "B" x-ref to locate Fee files
XDRM(D0,1,D1,1,D2) loop thru GLOBAL DATA for a specific FROM FILE
XDRM(D0,2,"B", loop thru TO FILE# "B" x-ref to locate Fee files
XDRM(D0,2,D1,1,D2) loop thru GLOBAL DATA for a specific TO FILE XDRM(D0,3,"B",
loop thru POINTERS CHANGED "B" x-ref to find Fee files\n
Data in the MERGE IMAGES fill will not be modified under this integration
agreement.", "", "", ""], ["3229", "DBIA3229", "Routine", "PHARMACY DATA MANAGEMENT", "2000/10/24", "", "Withdrawn", "Private", "", "
If the APPLICATION PACKAGES' USE field (#63) in DRUG
file (#50) for at least one of the dispense drugs associated with the
orderable item is marked for IV use and at least one of the IV additives/IV
solutions associated with the dispense drug are flagged for IV FLUID ORDER
ENTRY, this field shall be optional. If not, a value in the schedule field
shall be mandatory. CPRS shall be passed this information from Pharmacy Data
Management to make this determination.", "", "PSSCPRS", ""], ["3230", "DBIA 3230 Imaging Device file entry", "Other", "KERNEL", "2000/10/24", "APPROVED", "Active", "Private", "", "
This request is to allow the VistA Imaging package to
add a HFS device to the DEVICE file and a Terminal Type entry; this is done
during the installation of the Imaging application. The entry for the Device
file will be named IMAGING WORKSTATION and the Terminal Type file entry will
be named P-IMAGING. This device is used by the GUI portions of VistA Imaging
to generate DHCP reports into a global array format.\n
The following is the code used to create this device:\n
EN ;Create an entry in the Device file for an Imaging workstation.
;
TERM N A,DA,DD,DO,DIC,DIE,ENTRY,X,Y
W !,"I will setup the 'P-IMAGING' entry in the Terminal Type file."
I $D(^%ZIS(2,"B","P-IMAGING")) D G DEV
. W !,"An entry already exists for 'P-IMAGING' in the Terminal Type
file
."
;Set the entry
S DIC="^%ZIS(2,"
S X="P-IMAGING",DIC(0)="O" K DD,D0 D FILE^DICN
S ENTRY=+Y G:'ENTRY ERRDEV
S DR=".02///0;1///80;2///"_"#"_";4///"_"$C(8)"_";7///"_"D
CLOSE^MAGGTU5; 3///64"
S DA=ENTRY,DIE="^%ZIS(2," D ^DIE
;.02/SELECTABLE AT SIGNON;1/RIGHT MARGIN;2/FORM FEED;4/BACK SPACE
;7/CLOSE EXECUTE;3/PAGE LENGTH DEV N
A,DA,DD,DO,DIC,DIE,ENTRY,X,Y,MAGOS
W !,"I will setup an 'Imaging Workstation' entry in the Device file."
I $D(^%ZIS(1,"B","IMAGING WORKSTATION")) D Q
. W !,"An entry already exists for 'IMAGING WORKSTATION' in the Device
f ile."
S DIC="^%ZIS(1,"
S X="IMAGING WORKSTATION",DIC(0)="O" K DD,D0 D FILE^DICN
S ENTRY=+Y G:'ENTRY ERRDEV
I ^%ZOSF("OS")["DSM" D
. S MAGOS="DSM"
. S DA=ENTRY,DR=".02///"_"BROKER"_";3///"_"P-IMAGING"_";1///"_"WS.DAT"
. S DR=DR_";4///0;5///0;19///"_"(NEWVERSION,DELETE)"_";2///"_"HFS"
. S DIE="^%ZIS(1,"
I ^%ZOSF("OS")["OpenM" D
. S MAGOS="OPENM"
. S DA=ENTRY,DR=".02///"_"BROKER"_";3///"_"P-IMAGING"_";1///"_"WS.DAT"
. S DR=DR_";4///0;5///0;19///"_"""NWS"""_";2///"_"HFS"
. S DIE="^%ZIS(1,"
I ^%ZOSF("OS")["MSM" D
. S MAGOS="MSM"
. S DA=ENTRY,DR=".02///"_"BROKER"_";3///"_"P-IMAGING"_";1///"_"WS.DAT"
. S DR=DR_";4///0;5///0;19///"_"(""WS.DAT"":""M"")"_";2///"_"HFS"
. S DIE="^%ZIS(1,"
I $D(MAGOS) D ^DIE
;.02/LOCATION OF TERMINAL;3/SUBTYPE;1/$I;4=ASK DEVICE;5/ASK PARAMETERS
;19/OPEN PARAMETERS;2/TYPE
Q ERRDEV ;
W !,"Could not setup the IMAGING WORKSTATION entry in the Device
file."
W !,"Could not setup the P-IMAGING entry in the Terminal Type file."
MSG W !,"Please review the Installation Manual to create this entry."
Q", "", "", ""], ["3231", "LOCAL TIMEZONE", "File", "MAILMAN", "2000/10/27", "APPROVED", "Active", "Controlled Subscription", "4.3", "
The Vista Imaging application supports site reporting
on a monthly basis and the reporting of critical events that require customer
support intervention. Tracking these events remotely is easier if the
"TIMEZONE" associated with these events is included in the message. We seek
direct read access to the ^XMB("TIMEZONE") for this purpose.", "", "", "2023/04/05"], ["3232", "FILE COMMENTS", "File", "KERNEL", "2000/10/27", "", "Withdrawn", "Private", "9.7", "
The Vista Imaging application supports the acquisition
and storage of clinical images received from diverse, foreign devices and
databases. It is our experience that the flexibility necessary to support a
broad range of products requires timely updates. This trend results in a loss
of homogeneity in the software distribution as sites are not always able keep
their systems current. It is an FDA requirement that we track our product so
that we can anticipate local issues and provide comprehensive support. It is
for this reason that the Imaging usage report, which triggers monthly reports
that update a local Vista Imaging development database, requires a more
granular build reference.", "", "", ""], ["3233", "DBIA3233", "Routine", "PHARMACY DATA MANAGEMENT", "2000/10/27", "APPROVED", "Active", "Controlled Subscription", "", "
With the implementation of the Pharmacy Ordering
Enhancements project, Dosages will now be stored in the DRUG file (#50), in
the form of Possible Dosages and Local Possible Dosages. When a medication
(Orderable Item) is selected in CPRS (Computerized Patient Record System) in
the medication order entry process, that Orderable Item will be passed to the
Pharmacy Data Management package, along with the Pharmacy application and
patient internal entry number. The Pharmacy Data Management package will pass
back to CPRS Dosage information from the Drugs in the DRUG file (#50) that are
matched to that Orderable Item.", "", "PSSORUTL", "2015/12/15"], ["3234", "DBIA3234", "Routine", "PHARMACY DATA MANAGEMENT", "2000/10/30", "APPROVED", "Active", "Controlled Subscription", "", "
With the implementation of the Pharmacy Ordering
Enhancements project, Dosages will now be stored in the DRUG file (#50), in
the form of Possible Dosages and Local Possible Dosages. When a Dispense Drug
is selected during the medication order entry process in the Outpatient
Pharmacy and Inpatient Medications applications, that drug will be passed to
the Pharmacy Data Management application, along with the Pharmacy application
and Patient. Pharmacy Data Management will pass back the available Dosages
from the DRUG file (#50) and other related information.", "", "PSSORPH", "2015/09/02"], ["3236", "MSG GMPLX", "Routine", "PROBLEM LIST", "2000/10/30", "APPROVED", "Active", "Private", "", "
The entry point into the routine GMPLX which is MSG
when called as a function, Will return a line of text "+ Next Screen - Prev
Screen ?? More actions"", "", "GMPLX", ""], ["3237", "DBIA3237", "Routine", "OUTPATIENT PHARMACY", "2000/10/30", "APPROVED", "Active", "Private", "", "
This call, provided by Outpatient Pharmacy, will return
a default Quantity value or a default Days Supply to CPRS for the Outpatient
medication order entry process through CPRS. A value will only be returned if
a value can appropriately be determined, based on data passed into the call.
If a Quantity value is not received in this call, then a default Quantity
value will be calculated. If a Quantity value is received in this call, then a
default Days Supply value will be calculated.", "", "PSOSIG", ""], ["3238", "Activate Vista Imaging Health Summary Component", "File", "HEALTH SUMMARY", "2000/10/30", "APPROVED", "Active", "Private", "142.1", "\n\n
The following code is designed to conditionly enable the Imaging Health
Summary Component upon package install.
; Enable the Imaging Health Summary component
I $D(^GMT(142.1,235)) D
. S (DIE,DIC)=142.1,DA=235
. S DR="5///@;8///@"
. D ^DIE The request is for direct read and a fileman edit. This code
is processed during the Imaging post init.", "", "", ""], ["3239", "DBIA3239", "Routine", "PHARMACY DATA MANAGEMENT", "2000/10/31", "APPROVED", "Active", "Private", "", "
This agreement allows Computerized Patient Record
System (CPRS) to pass into Pharmacy Data Management a Pharmacy Orderable Item,
and the Pharmacy application for which a medication order is being entered in
CPRS. In return, Pharmacy Data Management will return an array of active
Dispense Drugs for that Pharmacy application that are tied to the Pharmacy
Orderable Item. This call will be used by CPRS so order checks can be
performed on all Dispense Drugs tied to an Orderable Item, when a Dispense
Drug cannot be associated with a medication order in CPRS.", "", "PSSUTIL1", "2015/10/26"], ["3240", "Mailgroup Updates", "File", "MAILMAN", "2000/11/01", "APPROVED", "Active", "Private", "3.812", "
In order to meet the FDA requirements to track the
usage of the medical device known as "Vista Imaging" (the IMAGING package) VA
maintains a Vista mailman mail server. The server processes monthly site
usage parameters and critical event driven alerts. The 2 issues: 1) We create
and populate a local mail group, "MAG SERVER", into which we add the local
installer and our own, "G.IMAGING DEVELOPMENT TEAM@DNS", remote member. We
also, as cleanup, remove a formerly installed remote member which failed often
as a result of mail scripts not always having our development domain in place,
"G.MAG SERVER@LAVC.DNS". 2) Also, for clarity and because remotes may not
have access to the resolved DUZ of local recipient's we place the entire
recipient list in the text of the message so when coordinating efforts to
resolve critical events, the contacts are most assuredly identified.", "", "", ""], ["3241", "DBIA3241", "File", "PROBLEM LIST", "2000/11/01", "", "Pending", "Controlled Subscription", "9000011", "
This DBIA documents Dental Record Manager use of the
PROBLEM file (9000011). This IA shall be replaced with an API as the
Integration Agreement as soon
as Problem List can provide the necessary API. The Dental Record Manager
Uses FILEMAN to deactivate a Problem List Entry.", "", "", ""], ["3242", "DIRECT READ OF XMB(3.9", "File", "MAILMAN", "2000/11/02", "APPROVED", "Active", "Private", "3.9", "
NDF requests a one time agreement with MailMan to do
direct global reads to XMB(3.9,DA(1),2,DA\n
Patch PSN*4*41 identified several entries in file 50 as being improperly
matched to NDF. Many of these entries were incorrectly so identified. The
patch generated a message to users listing the items. Sites have requested a
supplemental list showing not only the name of the item, but also the IEN,
inactivation date, and whether the item is an investigational drug. The data
in file 50 which was used to identify these items was deleted by patch
PSN*4*41. The only way to generate these new lists is to read the original
message and use the B cross reference in file 50 to get the requested
information. LIST^DIC will be used to identify and retrieve the messages.", "", "", ""], ["3243", "Active Flag", "Routine", "INPATIENT MEDICATIONS", "2000/11/02", "APPROVED", "Active", "Private", "", "
This API returns a flag indicating the status of the
Orderable Item, Dispense Drug, Additive and/or Solution within the order.\n
A call to $$ACTIVE^PSJORREN(DFN,ON) returns one of the following data:\n
1 - The drug(s) within the order is active\n
2^New Orderable Item - A new Orderable Item is found for Unit Dose order\n
0^Inactive reason - This order has no active drugs", "", "PSJORREN", ""], ["3244", "Invalid MPI/PD exception messages sent to FORUM", "File", "HEALTH LEVEL SEVEN", "2000/11/06", "APPROVED", "Active", "Controlled Subscription", "773", "
Exception messages are being sent to the MPI/PD team
under the wrong circumstances. Non-MPI/PD applications trigger exception
messages under inappropriate conditions because of issues in the execution of
the VistA Health Level Seven (HL7) software. This IA will eliminate the
possibility of non-MPI/PD applications generating exception messages.", "", "", ""], ["3245", "TIU GET ASSOCIATED IMAGES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2000/11/13", "APPROVED", "Active", "Controlled Subscription", "", "
This Remote Procedure Call (RPC) allows the calling
application to access a list of Images that have been captured and maintained
by VistA Imaging, and have been asscociated with a given Document in TIU.\n
NAME: TIU GET ASSOCIATED IMAGES TAG: GETILST
ROUTINE: TIUSRVPL RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION
DESCRIPTION:
Given a Document, get the list of associated images. INPUT PARAMETER: TIUDA
PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
This is the record number (IEN) of the document in the TIU DOCUMENT FILE
(#8925).
RETURN PARAMETER DESCRIPTION:
This is the list of Images associated with the Document identified by
TIUDA.\n
For example:\n
TIUY(1)=21734
TIUY(2)=21799
TIUY(3)=21803\n
Where the rvalue of each list element is the record number (IEN) of each
image in the IMAGE FILE (#2005).", "TIU GET ASSOCIATED IMAGES", "", ""], ["3246", "TIU GET DOCUMENTS FOR IMAGE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2000/11/13", "APPROVED", "Active", "Controlled Subscription", "", "
This Remote Procedure Call (RPC) allows the calling
application to access a list of Documents that have been captured and
maintained by TIU, and have been asscociated with a given Image in VistA
Imaging.\n
NAME: TIU GET DOCUMENTS FOR IMAGE TAG: GETDLST
ROUTINE: TIUSRVPL RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION
DESCRIPTION:
Given an image, get the list of associated documents. INPUT PARAMETER:
IMGDA PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
This is the record number (IEN) of the image in the IMAGE FILE (#2005).
RETURN PARAMETER DESCRIPTION:
This is the list of Documents associated with the Image identified by
IMGDA.\n
For example:\n
TIUY(1)=721734
TIUY(2)=721799
TIUY(3)=721803\n
Where the rvalue of each list element is the record number (IEN) of
image in the TIU DOCUMENT FILE (#8925).", "TIU GET DOCUMENTS FOR IMAGE", "", ""], ["3247", "TIU LINK DOCUMENT TO IMAGE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2000/11/13", "APPROVED", "Active", "Controlled Subscription", "", "
This Remote procedure call will allow the calling
application to link a specific Document in the TIU Document File (#8925) with
a specific Image in the Image File (#2005). The call will support a
many-to-many cardinality between Documents and Images.\n
NAME: TIU LINK DOCUMENT TO IMAGE TAG: PUTIMAGE
ROUTINE: TIUSRVPL RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
DESCRIPTION:
This RPC links a document with an image. It will support a many-to-many
association between documents and images. INPUT PARAMETER: TIUDA
PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
This is the record number (IEN) of the document in the TIU DOCUMENT FILE
(#8925). INPUT PARAMETER: IMGDA PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 2
DESCRIPTION:
This is the record number (IEN) of the document in the IMAGE FILE
(#2005).
RETURN PARAMETER DESCRIPTION:
The return variable is a scalar result. If a link is successfully
created, it will be the record number of the link in the TIU EXTERNAL
LINKAGE FILE (#8925.91). If a link cannot be made (e.g., the document
and image are already linked), the return variable will be a two
'^'-piece result, with zero in the first '^'-piece, and an explanatory
message in the second (e.g., 0^ Document already linked to this image).", "TIU LINK DOCUMENT TO IMAGE", "", ""], ["3248", "TIU REMOVE LINK TO IMAGE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2000/11/13", "APPROVED", "Active", "Controlled Subscription", "", "
This Remote procedure call will allow the calling
application to REMOVE the link between a specific Document in the TIU Document
File (#8925) and a specific Image in the Image File (#2005).\n
NAME: TIU REMOVE LINK TO IMAGE TAG: DELIMAGE
ROUTINE: TIUSRVPL RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
DESCRIPTION:
This RPC will remove a link between a document and an image. Only valid
links may be removed. INPUT PARAMETER: TIUDA PARAMETER
TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
This is the record number (IEN) of the document in the TIU DOCUMENT FILE
(#8925). INPUT PARAMETER: IMGDA PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 2
DESCRIPTION:
This is the record number (IEN) of the document in the IMAGE FILE
(#2005).
RETURN PARAMETER DESCRIPTION:
This is a BOOLEAN result. If the call is made with record numbers for
which a valid link exists, it will remove the link, and the return value
will be 1 (TRUE), otherwise, the return value will have two '^'-pieces
(i.e., zero and an explanatory message (e.g., 0^ Document and Image not
currently linked)).", "TIU REMOVE LINK TO IMAGE", "", ""], ["3249", "Imaging Medicine Procedure field", "Routine", "CLINICAL PROCEDURES", "2000/11/14", "APPROVED", "Active", "Private", "", "
Vista Imaging is requesting permission to use API
$$PRCFLD^MCUIMAG0. This is needed needed to lookup the Procedure/Subspecialty
pointer field during an image capture via the DICOM Image gateway. The
gateway receive images directly from Image Acquisition devices (IFA, Olympus,
etc.) and each device sends a pseudo transaction number consisting of the
Medicine file and internal entry number for the images to be attached to.
This call is required to get the procedure field name/number to do a Fileman
lookup on the entry sent.", "", "MCUIMAG0", ""], ["3250", "Imaging 3250", "Routine", "CLINICAL PROCEDURES", "2000/11/14", "APPROVED", "Active", "Private", "", "
Vista Imaging is requesting permission to call
$$VALID^MCUIMAG0 to validate an entry in a Medicine file. This is used on an
Imaging workstation to obtain a psuedo transaction number to be used to
capture DICOM images directly from image acquisition devices (IFA, Olympus,
etc.).", "", "MCUIMAG0", ""], ["3251", "Imaging 3251", "Routine", "CLINICAL PROCEDURES", "2000/11/14", "", "Withdrawn", "Private", "", "
Vista Imaging is requesting permission to call
KILL^MCUIMAG0. This is required to delete an image pointer in a Medicine file
entry.", "", "MCUIMAGO", ""], ["3252", "CALL TO GMRCASV1", "Routine", "CONSULT/REQUEST TRACKING", "2000/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will allow an application to call
GUI^GMRCASV1. When this routine is called with the appropriate variables it
will pass back the selected consult services, synonyms, indicate if it is a
parent or the IEN of the parent, and if there are children (sub services).", "", "GMRCASV1", ""], ["3253", "Imaging 3253", "File", "CLINICAL PROCEDURES", "2000/11/15", "", "Withdrawn", "Private", "691", "
This request is for the purpose of displaying a list of
entries for a specified patient and date range in the Medicine file 691
(ECHO).\n
Vista Imaging is acquiring images directly from modalities and on occassion
the provided pseudo transaction number assigned is incorrect and the automatic
image processing will require user interaction. During this user interaction
the user will be provided with the patient name of the failed image. The
end-user will need to match the image to a Medicine file entry that is
displayed on the screen.", "", "", ""], ["3254", "Imaging 3254", "File", "CLINICAL PROCEDURES", "2000/11/15", "", "Withdrawn", "Private", "694", "
This request is for the purpose of displaying a list of
entries for a specified patient and date range in the Medicine file 694
(HEMATOLOGY)\n\n
Vista Imaging is acquiring images directly from modalities and on occasion the
provided pseudo transaction number assigned is incorrect and the automatic
image processing will require user interaction. During this user interaction
the user will be provided with the patient name of the failed image. The
end-user will need to match the image to a Medicine file entry that is
displayed on the screen.", "", "", ""], ["3255", "Imaging 3255", "File", "CLINICAL PROCEDURES", "2000/11/15", "", "Withdrawn", "Private", "691.1", "
This request is for the purpose of displaying a list of
entries for a specified patient and date range in the Medicine file 691.1
(CARDIAC CATHETERIZATION)\n\n
Vista Imaging is acquiring images directly from modalities and on occasion the
provided pseudo transaction number assigned is incorrect and the automatic
image processing will require user interaction. During this user interaction
the user will be provided with the patient name of the failed image. The
end-user will need to match the image to a Medicine file entry that is
displayed on the screen.", "", "", ""], ["3256", "IMAGING 3256", "File", "CLINICAL PROCEDURES", "2000/11/15", "", "Withdrawn", "Private", "691.5", "
This request is for the purpose of displaying a list of
entries for a specified patient and date range in the Medicine file 691.5
(ELECTROCARDIOGRAPHY).\n\n
Vista Imaging is acquiring images directly from modalities and on occasion the
provided pseudo transaction number assigned is incorrect and the automatic
image processing will require user interaction. During this user interaction
the user will be provided with the patient name of the failed image. The
end-user will need to match the image to a Medicine file entry that is
displayed on the screen.", "", "", ""], ["3257", "IMAGING 3257", "File", "CLINICAL PROCEDURES", "2000/11/15", "", "Withdrawn", "Private", "699", "
This request is for the purpose of displaying a list of
entries for a specified patient and date range in the Medicine file 699
(ENDOSCOPY).\n\n
Vista Imaging is acquiring images directly from modalities and on occasion the
provided pseudo transaction number assigned is incorrect and the automatic
image processing will require user interaction. During this user interaction
the user will be provided with the patient name of the failed image. The
end-user will need to match the image to a Medicine file entry that is
displayed on the screen.", "", "", ""], ["3258", "IMAGING 3258", "File", "CLINICAL PROCEDURES", "2000/11/15", "", "Withdrawn", "Private", "699.5", "
This request is for the purpose of displaying a list of
entries for a specified patient and date range in the Medicine file 699.5
(GENERIC MEDICINE).\n
Vista Imaging is acquiring images directly from modalities and on occasion the
provided pseudo transaction number assigned is incorrect and the automatic
image processing will require user interaction. During this user interaction
the user will be provided with the patient name of the failed image. The
end-user will need to match the image to a Medicine file entry that is
displayed on the screen.", "", "", ""], ["3259", "CHECK FOR ADFN X-REF IN 991.1", "File", "CLINICAL INFO RESOURCE NETWORK", "2000/11/16", "APPROVED", "Active", "Private", "991.1", "
In order to keep the number of repeating Local ICNs
being sent to the MPI for resolution when their is still an exception
outstanding, the Local/Missing ICN Resolution job will no longer send up
patients that have a Potential Match Exception. The only way that a potential
match patient can get an ICN assignment would be via the Single Patient
Initialization Option, so there is no need to send them up during the
background job.\n
Having said that, MPIF would like to be able to check for the Potential match
exception by check for:\n
$D(^RGHL7(991.1,"ADFN",218,<DFN>))\n
Where DFN is the IEN of the patient in the Patient File.", "", "", ""], ["3260", "Imaging 3260 - Lab Referral file.", "File", "LAB SERVICE", "2000/11/17", "APPROVED", "Active", "Controlled Subscription", "67", "
Images captured for Laboratory are associated to the
Lab accession number which identifies the entry in appropriate sub-file in
Laboratory. It is possible to have an accession number associated to the
REFERRAL FILE and not the patient file. For this precaution, Imaging is
requesting FM read access to this file.", "", "", ""], ["3261", "BLOOD BANK AND DIRECT ACCESS TO DD GLOBAL", "File", "1", "2000/11/24", "APPROVED", "Active", "Private", "", "
The Blood Bank module of the LAB SERVICES package has
been granted permission by the custodial package (VA FileMan) to access the DD
global as detailed in this DBIA.", "", "", ""], ["3262", "DEVICE FILE", "File", "KERNEL", "2000/12/04", "", "Withdrawn", "Private", "3.5", "
The GEN. MED. REC. - VITALS package (aka Vitals)
requests permission to read File 3.5 values to handle printing from within the
GUI environment.", "", "", ""], ["3264", "PROCESSING RTN FIELDS", "File", "KERNEL", "2000/11/29", "APPROVED", "Active", "Private", "101", "
One time IA for the pre-init for patches LA*5.2*58 and
LR*5.2*266: The letter "Q" will need to be entered in the Processing RTN field
(#771) and the Response Processing RTN field (#772) of the Protocol file
(#101) for the LA7D CARELIFE RESULTS and the LA7D CARELIFE SERVER entries.
Leaving this field blank will, in some instances, cause an error. FileMan
utilities will be used to set these fields.", "", "", ""], ["3265", "TERMINAL TYPE FILE", "File", "KERNEL", "2000/12/04", "", "Withdrawn", "Private", "3.2", "
The GEN. MED. REC. - VITALS package (aka Vitals)
requests permission to read File 3.2 values to handle printing from within the
GUI environment.", "", "", ""], ["3266", "OBTAIN PATIENT DOB FROM DPTLK1", "Routine", "REGISTRATION", "2000/12/05", "APPROVED", "Active", "Controlled Subscription", "", "
The patient lookup routine, DPTLK1, has a useful api
for obtaining a formated date of birth. Imaging is requesting permission to
use this api.", "", "DPTLK1", ""], ["3267", "OBTAIN PATIENT SSN FROM DPTLK1", "Routine", "REGISTRATION", "2000/12/05", "APPROVED", "Active", "Controlled Subscription", "", "
The patient lookup routine, DPTLK1, has a useful api
for obtaining the patient's social security number. Imaging is requesting
permission to use this api.", "", "DPTLK1", ""], ["3268", "Read file 8925", "File", "TEXT INTEGRATION UTILITIES", "2000/12/07", "APPROVED", "Active", "Controlled Subscription", "8925", "
Imaging is requesting read permission to file 8925 to
obtain the document type, patient name, and document entry date/time.", "", "", ""], ["3269", "Imaging - Rad variable set", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2000/12/08", "APPROVED", "Active", "Controlled Subscription", "", "
Imaging is requesting permission to call RASET^RAUTL2
to set radiology variables needed to call RAO7PC3. Imaging stores only the
Radiology Report pointer and not all the information needed by api RAO70C3.", "", "RAUTL2", ""], ["3270", "DBIA 3270", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2000/12/18", "APPROVED", "Active", "Controlled Subscription", "", "
Imaging request permission to subscribe to routine
RAUTL20, sub-modules EN1 and EN2, that have useful information for print sets.
These modules will pass variables that assist in determining if a case is part
of a print set.", "", "RAUTL20", ""], ["3271", "Direct writes to the DRUG file (#50)", "File", "PHARMACY DATA MANAGEMENT", "2000/12/19", "", "Retired", "Private", "50", "
National Drug File requests approval to directly write
to the ACTIVITY LOG multiple field (#4) in the DRUG file (#50).", "", "", ""], ["3272", "DBIA3272", "File", "KERNEL", "2000/12/20", "APPROVED", "Active", "Private", "200", "
The Integrated Billing package requests a DBA exemption
to allow the .01 field of the IB BILLING PROVIDER ID file (355.9) to point to
the NEW PERSON file (200). This field is actually a variable pointer field
and the NEW PERSON file would be one of the files included in that variable
pointer file set. This will allow IB to access VA provider data without
duplicate entry for determining the correct provider id to use for claims.", "", "", ""], ["3273", "DBIA3273", "File", "HEALTH LEVEL SEVEN", "2000/12/20", "APPROVED", "Active", "Controlled Subscription", "773", "
This is a request for the MPI/PD package to have
Fileman Read access to several fields for the purpose of improving the
information provided in the exception messages,generated while processing HL7
messages, that are sent to the MPI/PD team via Mailman.\n
The exception message currently includes the message id of the message where
the exception was encountered. We would like to add to the exception message
some information about the HL7 message,including the Logical Link, Message
Type,and Event Type.\n
For that purpose we request Fileman read access to the following fields:\n
HL7 Message Administration file (#773):
Logical Link (#7)
Message Type (#15)
Event Type (#16)", "", "", ""], ["3274", "HINQ", "Routine", "HINQ", "2003/04/21", "", "Retired", "Private", "", "
The GUI Load/Edit process created for the Registration
Smart Card requires HINQ information and needs to be able to trigger a HINQ
Inquiry. Modifications in an existing API (EN^DVBHQZ4) to make it
non-interactive. The new API is EN^DVBLEHNQ.", "", "DVBLEHNQ", ""], ["3275", "GET IB DATA", "Routine", "INTEGRATED BILLING", "2000/12/27", "", "Withdrawn", "Private", "", "
The Smart Card GUI client side needs to gather Sponsor
information for the GUI Load/Edit Registration process. A Registration RPC
call will call the existiong IB API GET^IBCNSU4.", "", "DGLEG7", ""], ["3276", "DBIA3276", "Routine", "INTEGRATED BILLING", "2003/04/21", "", "Retired", "Private", "", "
This agreement allows the Smart Card GUI client to file
sponsor information in Integrated Billing from the GUI Load/Edit Registration
process. Smart Card will utilize a non-interactive call to the new routine
IBCNSU42 (which mirrors the interactive routine IBCNSU41) to file the sponsor
information collected from the GUI client.", "", "IBCNSU42", ""], ["3277", "XUSRB", "Routine", "KERNEL", "2000/12/29", "APPROVED", "Active", "Supported", "", "
This IA records supported API's in the XUSRB routine.
This routine is used by Broker for GUI sign-on.", "", "XUSRB", ""], ["3278", "DBIA3278", "Routine", "OUTPATIENT PHARMACY", "2000/12/29", "APPROVED", "Active", "Private", "", "
These calls, provided by Outpatient Pharmacy, will
return default values to Computerized Patient Record System (CPRS) for Days
Supply and Maximum Number of Refills for the medication order entry process.", "", "PSOSIGDS", ""], ["3279", "MCARUTL2", "Routine", "CLINICAL PROCEDURES", "2001/01/02", "APPROVED", "Active", "Supported", "", "\n
These APIs allow the Imaging package access to the Medicine package
data. The APIs will do lookups on the MEDICAL PATIENT File (#690) and
the PROCEDURE/SUBSPECIALTY file (#697.2) and return data from the
associated Medicine files.", "", "MCARUTL2", ""], ["3280", "MCARUTL3", "Routine", "CLINICAL PROCEDURES", "2001/01/02", "APPROVED", "Active", "Supported", "", "\n
This API allows the Imaging package access to the Medicine package
data. The API will do a lookup on the MEDICAL PATIENT File (#690)
and the PROCEDURE/SUBSPECIALTY file (#697.2) for the indicated
entry and return the associated Medicine package data.", "", "MCARUTL3", ""], ["3281", "Kernel Installation & Distribution System build status.", "File", "KERNEL", "2001/01/03", "APPROVED", "Active", "Controlled Subscription", "9.7", "
The status of a Kernel Installation & Distribution
System (KIDS) build needs to be determined so a single distribution build
Alpha, can queue build Beta, another single distribution.\n\n
Before build Alpha queues build Beta, build Beta must be loaded from a
distribution.", "", "", ""], ["3282", "GMT(142", "File", "HEALTH SUMMARY", "2001/01/03", "APPROVED", "Active", "Private", "142", "
Health Summary grants Imaging permission to read the
following fields in the HEALTH SUMMARY TYPE FILE (142).\n
Field Node;Piece Field Name
----- ---------- -----------
.01 0;1 NAME
.02 T;1 Title", "", "", ""], ["3283", "DBIA3283", "File", "HEALTH LEVEL SEVEN", "2001/01/18", "APPROVED", "Active", "Private", "870", "
The Registration package requests permission to perform
a Read with FileMan of file 870 in order to get the name of links subscribed
to by a record.", "", "", ""], ["3284", "DBIA3284", "Routine", "SCHEDULING", "2003/04/21", "APPROVED", "Active", "Private", "", "", "", "SCAPMCU2", ""], ["3285", "DBIA3285", "File", "SCHEDULING", "2001/01/04", "APPROVED", "Active", "Private", "404.57", "", "", "", ""], ["3286", "DBIA3286", "File", "SCHEDULING", "2001/01/04", "APPROVED", "Active", "Private", "404.51", "", "", "", ""], ["3287", "DBIA3287", "File", "KERNEL", "2001/01/04", "APPROVED", "Active", "Private", "8989.3", "
The IA is requested for a one-time-use for a set of
extract routines to read the value of the field. This version of the extract
routines will retire after successfully gathered data for qualified patients
at the sites.\n", "", "", ""], ["3288", "ORQOR LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORQOR LIST", "", ""], ["3289", "ORWCS LIST OF CONSULT REPORTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWCS LIST OF CONSULT REPORTS", "", ""], ["3290", "ORWCS REPORT TEXT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWCS REPORT TEXT", "", ""], ["3291", "ORWPT LAST5", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT LAST5", "", ""], ["3292", "ORWPT PTINQ", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPT PTINQ", "", ""], ["3293", "ORWU CLINLOC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWU CLINLOC", "", ""], ["3294", "ORWMC PATIENT PROCEDURES", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWMC PATIENT PROCEDURES", "", ""], ["3295", "PXRM REMINDER DIALOG (TIU)", "Remote Procedure", "CLINICAL REMINDERS", "2003/04/25", "APPROVED", "Active", "Controlled Subscription", "", "
Returns reminder dialog for a given dialog ien.", "", "", ""], ["3296", "PXRM REMINDER CATEGORY", "Remote Procedure", "CLINICAL REMINDERS", "2003/04/25", "APPROVED", "Active", "Controlled Subscription", "", "
Returns list of reminders for a reminder category in
display order.", "", "", ""], ["3297", "DBIA3297", "Routine", "INCOME VERIFICATION MATCH", "2003/04/21", "APPROVED", "Active", "Supported", "", "
This DBIA is being entered to request access to two IVM
APIs by the Registration package. The Registration package is creating a GUI
version of the Load/Edit Patient Data option. In this option a financial
query will be sent if indicated, just as in the roll and scroll Load/Edit.
The APIs called are NEED^IVMCQ and QUERY^IVMCQ1. They mirror the
functionality performed by the roll and scroll Load/Edi in REQ^IVMCQ.", "", "DGLEIVM", ""], ["3298", "Reference CMOR Request", "File", "MASTER PATIENT INDEX VISTA", "2001/01/11", "APPROVED", "Active", "Controlled Subscription", "984.9", "
The Registration package is requesting a DBIA with
Master Patient Index (MPIF) to read with FileMan the MPIF CMOR REQUEST
(#984.9) file as well as a direct global read on the "C" and "AC" cross
references. This information is used to display need information need to make
decision about changing the CMOR.", "", "", ""], ["3299", "DBIA3299", "Routine", "REGISTRATION", "2001/01/12", "APPROVED", "Active", "Private", "", "
The CIRN package is requesting an integration agreement
with the registration package to call START^VAFCPDAT. An action has been added
to the CIRN Exception Handling [RG CIRN EXCEPTION HANDLING] option. This
option allows the user for view Treating Facility and Subscription data
associated with the selected patient.", "", "VAFCPDAT", ""], ["3300", "$$MPIQQ MPIFAPI", "Routine", "MASTER PATIENT INDEX VISTA", "2004/05/21", "APPROVED", "Active", "Controlled Subscription", "", "
The Smart Card folks has requested an API to be able to
task off the real-time connection to the MPI for an ICN request. This process
will be the same as the MPIQ^MPIFAPI(DFN) API, but will task the process off
to the background.", "", "MPIFAPI", ""], ["3301", "3301", "File", "REGISTRATION", "2001/01/30", "APPROVED", "Active", "Controlled Subscription", "2", "
Consolidated Mail Outpatient (CMOP) is allowed access
to field # .6 Test Patient Indicator so that it may screen such patients from
having data transmitted to CMOP hosts.", "", "", ""], ["3302", "DBIA3302", "Routine", "INTEGRATED BILLING", "2001/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
The ENROLLMENT APPLICATION SYSTEM (EAS) package
requests use of the function $$BUFF^IBCNBES1 to add new entries to the
INSURANCE BUFFER file (#355.33).\n
Update: IB*2*497 increased the length of the SUBSCRIBER ID field, NAME OF
INSURED field, and GROUP NUMBER field to support the EDI New Standards and
Operating Rules for VHA providers. This required length increase made it
necessary to move the location of these 3 fields to new Data Dictionary nodes.\n
To support this implementation, all subscribers to this ICR will need to make
the necessary changes in their applications to reference the new fields and
remove the references to the old fields. When all subscribers have
implemented the use of the new fields, the old fields will be deleted with
IB*2*518. Old and new fields are noted in the field list detail of this ICR.", "", "IBCNBES1", "2014/02/21"], ["3303", "DBIA3303", "File", "REGISTRATION", "2001/02/07", "APPROVED", "Active", "Private", "391.98", "
THE CLINICAL INFORMATION RESOURCE NETWORK PACKAGE NEEDS
TO ORDER THROUGH THE PATIENT DATA EXCEPTION (#391.98) FILE TO PRODUCE A
DISPLAY SHOWING THE STATUS AND COUNT OF OUTSTANDING PATIENT DATA REVIEW ITEMS.\n", "", "", ""], ["3304", "DBIA3304", "File", "REGISTRATION", "2001/02/07", "APPROVED", "Active", "Private", "391.984", "
THE CLINICAL INFORMATION RESOURCE NETWORK PACKAGE NEEDS
TO GET THE EXTERNAL VALUE OF THE EXCEPTION STATUS OF PATIENT DATA REVIEW
ENTRIES FOR THE MPI/PD STATUS DISPLAY.", "", "", ""], ["3306", "SC TEAM INFORMATION List Template", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The [PXCE SC DISPLAY TEAM INFO] protocol uses the SC
TEAM INFORMATION List Template.", "", "", ""], ["3307", "DBIA 3307 - Imaging & Fileman routines", "Other", "1", "2005/03/10", "", "Retired", "Private", "", "
Fileman gives Imaging permission to distribute and
download Fileman routines onto their DICOM gateway.", "", "", ""], ["3308", "DBIA 3308 - Imaging points to file1", "Other", "1", "2001/03/02", "", "Withdrawn", "Private", "", "
Fileman gives permission to the Imaging package to
point out to File #1 from the Imaging's PARENT DATA FILE (#2005.03). No LAYGO
access is allowed to file #1.", "", "", ""], ["3309", "PCLINE-SDPPTEM Function Call", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
PXCE functionality requires access a patient's PC
Provider, Associate Provider and Team Information. Routine PXCE makes a call
to the API $$PCLINE^SDPPTEM passing Patient's DFN and Date information.
$$PCLINE^SDPPTEM as a function returns the necessary data formatted as an 80
character line, or "" if none.", "", "SDPPTEM", ""], ["3310", "EN and PAT - SCMCQK Access", "Routine", "SCHEDULING", "2001/02/13", "APPROVED", "Active", "Private", "", "
The PC Assign or Unassign, [PXCE SC PC
Assign/Unassign], protocol uses the Scheduling routine SCMCQK as a means to
acquire Team information for display and possible processing. [PXCE SC PC
Assign/Unassign], PC Assign or Unassign, is an action item on the PXCE MAIN
and PXCE SDAM menus and accesses SCMCQK using the "EN" and "PAT" entry points.\n", "", "SCMCQK", ""], ["3311", "PXCE SC DISPLAY TEAM INFO Protcol", "Routine", "SCHEDULING", "2001/02/13", "APPROVED", "Active", "Private", "", "
The entry action for the Display Team Information,
[PXCE SC DISPLAY TEAM INFO], protocol has the potential to use routine SCMCU1
as means to select a patient. PXCE SC DISPLAY TEAM INFO (TI Display Team
Information) is an action item on the PXCE MAIN and PXCE SDAM menus and may
access ^SCMCU1 at its "SEL" entry point.", "", "SCMCU1", ""], ["3312", "SC PCMM ROLL Security Key", "Other", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The PC Assign or Unassign, [PXCE SC PC
Assign/Unassign], protocol is locked by the SC PCMM ROLL security key and can
only be used by users who have this key assigned.", "", "", ""], ["3313", "ELSTAT and COLLAT - SDUTL2", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "", "
The routine PXCE uses the SCHEDULING "miscellaneous
utilities" program SDUTL2 to access patient eligibility statuses. Accessing
SDUTL2 at entry points ELSTAT and COLLAT, PXCE accesses "eligibility status"
and "collateral eligibility status" functions respectively.", "", "SDUTL2", ""], ["3314", "Outpatient Pharmacy/NDBI A7RPSOUB", "Routine", "NDBI", "2001/02/13", "APPROVED", "Active", "Private", "", "
The Outpatient Pharmacy package makes a call into the
National Database Integration function $$ZIEN52^A7RPSOUB(STATION#,RX#). This
function will return either a NDBI Drug Table ien value if the Prescription
number for the station supplied was moved to the priamry site in an integrated
system or null.\n
Calls into NDBI $$ZIEN52^A7RPSOUB(STATION#,RX#) from Outpatient Pharmacy are
contingent on:\n
1) the presence of the sub-routine $$ZIEN52^A7RPSOUB.
2) a variable that contains a three-digit station
number associated with the RX#.\n
If any one of these two conditions is not met, then
Outpatient Pharmacy will not make the call.", "", "A7ROUSB", ""], ["3315", "UPDATE DIE", "Routine", "1", "2001/02/14", "APPROVED", "Active", "Private", "", "
Registration is requesting to export a new cross
reference to the .01 and .09 fields of the Patient file (#2) by hardsetting
the ^DD("IX" global nodes and using UPDATE^DIE to get the IEN in ^DD("IX" to
use. The reason to hardset the global rather than have KIDS export the x-ref
is that the .01 of the Patient file (#2) is has changes in test in the field
for the Name Standardization patch which is on indefinate hold.", "", "DIE", ""], ["3316", "HARSET DD('IX'", "File", "1", "2004/07/22", "", "Retired", "Private", ".11", "
Registration is requesting to export a new cross
reference to the .01 and .09 of the Patient file (#2) by hardsetting the
^DD("IX" global nodes and using UPDATE^DIE to get the IEN in ^DD("IX" to use.
The reason to hardset the global rather than have KIDS export the x-ref is
that the .01 and .09 of the Patient file (#2) is has changes in test in the
field for the Name Standardization patch which is on indefinate hold.", "", "", ""], ["3317", "Imaging Update Radiology files #3317", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2001/02/15", "APPROVED", "Active", "Controlled Subscription", "", "
Routine RARIC1 has callable modules to: 1) to stuff the
physician data into an exam record and 2) delete Imaging pointers in the
Radiology Report file.", "", "RARIC1", ""], ["3319", "DBIA3319", "File", "1", "", "APPROVED", "Retired", "Private", "", "\n
************************************************************************
The Library package was decommissioned with LBR*2.5*15. This ICR was retired
with the release of the Library patch.
************************************************************************", "", "", ""], ["3320", "UPDATE BCMA STATUS INFORMATION", "Routine", "INPATIENT MEDICATIONS", "2001/02/21", "APPROVED", "Active", "Private", "", "
The purpose of this API is to get information from BAR
CODE MEDICATION ADMINSTRATION (BCMA) to put in the PHARMACY PATIENT FILE
(#55).", "", "PSJBCMA3", ""], ["3321", "DBIA 3321", "Other", "CLINICAL PROCEDURES", "2001/02/26", "APPROVED", "Active", "Controlled Subscription", "", "
Medicine gives permission to the VistA Imaging
application to copy the following routines into their Imaging gateways. These
routines are not renamed or modified at the destination.", "", "", ""], ["3322", "RADIOLOGY RTNS 3322", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "2005/03/10", "", "Retired", "Private", "", "
Radiology gives Imaging permission to copy routines
associated with APIs used by Imaging to update imaging pointers and delete
image pointers from the Radiology Report file. These routines are downloaded
unto Imaging gateways. The routines are not renamed nor modified on the
gateways.\n
This IA will also request the following be provided on any future patches to
these routines. This will inform Imaging users on the procedures to follow
for downloading the Imaging routines on the gateways.\n
If you are running Vista Imaging, use the menu option to copy the routines to
the Imaging DICOM gateways as follows: "On the Vista server (hospital
database), use menu option 'Copy Routines to DICOM Gateway' located under the
'Imaging System Manager' Menu. Then on all Text and Image gateways use the
'System Maintenance' menu to select Gateway Configuration and DICOM Master
File and then select 'Download Current Radiology and MAS Routines'. This will
cause the up-to-date versions of all radiology and MAS routines to be copied
to the gateway systems."", "", "", ""], ["3323", "DBIA3323 - Image file points to Rad Report", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2001/03/01", "APPROVED", "Active", "Private", "74", "
Radiology gives permission to the Imaging package to
point to the Radiology Report file (#74) from the Image (#2005) and Image
Audit (#2005.1) data dictionaries.", "", "", ""], ["3324", "DBIA3324 - Imaging points to file 71", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2001/03/01", "APPROVED", "Active", "Controlled Subscription", "71", "
Radiology gives permission to the Imaging package to
point to the RAD/NUC MED PROCEDURE file (#71) from the Image (#2005) and Image
Audit (#2005.1) data dictionaries.", "", "", ""], ["3325", "DBIA3325", "Routine", "REGISTRATION", "2001/03/01", "APPROVED", "Active", "Private", "", "
The Enrollment Application System requests use of entry
point GETPAT^DGRPTU for use by the 1010EZ module. The VistA-resident portion
of the 1010EZ module accepts data transmitted to the site electronically from
a web-based application where a veteran has entered enrollment data.\n
Before the electronically submitted data can be stored by the 1010EZ module
within the site's Patient database, user acceptance of the data is required.
The first step in that process is for the user to match, if possible, the
veteran's identifying data with an existing Patient record.\n
This entry point, which was previously implemented by the 1010T module, will
provide the user interface with standard patient lookup and duplicate checking
functions within Registration.\n", "", "DGRPTU", ""], ["3326", "DBIA3326", "Routine", "REGISTRATION", "2001/03/01", "APPROVED", "Active", "Private", "", "", "", "DGMTU", ""], ["3327", "DBIA3327", "File", "REGISTRATION", "2001/03/01", "APPROVED", "Active", "Private", "2", "
The Enrollment Application System requests ability to
read data via FileMan from numerous fields in the PATIENT (#2) file.\n
The VistA-resident portion of the 1010EZ module accepts data transmitted to
the site electronically from a web-based application where a veteran has
entered enrollment data. In a some cases, information about the veteran
applicant will already reside in the site's patient database. If that is the
case, then the 1010EZ module is required to display both the newly submitted
data and the existing data for comparison purposes.\n
The Enrollment Application System requests ability to write data using FileMan
to the same fields in the PATIENT (#2) file.\n
Since the 1010EZ is a means of initiating enrollment/registration, it is of
course necessary to commit the data to the database. Medical center users may
review and edit the data, as needed, before filing.\n", "", "", ""], ["3328", "DBIA3328", "File", "REGISTRATION", "2001/03/01", "APPROVED", "Active", "Private", "408.12", "
The Enrollment Application System requests ability to
read data via FileMan from several fields in the PATIENT RELATION (#408.12)
file.\n
The VistA-resident portion of the 1010EZ module accepts data transmitted to
the site electronically from a web-based application where a veteran has
entered enrollment data. In a some cases, information about the veteran
applicant will already reside in the site's patient database. If that is the
case, then the 1010EZ module is required to display both the newly submitted
data and the existing data for comparison purposes.\n
The Enrollment Application System requests ability to write data using FileMan
to the same fields in the PATIENT RELATION (#408.12) file.\n
Since the 1010EZ is a means of initiating enrollment/registration, it is of
course necessary to commit the data to the database. Medical center users may
review and edit the data, as needed, before filing. The data placed in file
#408.12 will be further edited at the time of formal Registration and Means
Testing.", "", "", ""], ["3329", "DBIA3329", "File", "REGISTRATION", "2001/03/01", "APPROVED", "Active", "Private", "408.13", "
The Enrollment Application System requests ability to
read data via FileMan from several fields in the INCOME PERSON (#408.13) file.\n
The VistA-resident portion of the 1010EZ module accepts data transmitted to
the site electronically from a web-based application where a veteran has
entered enrollment data. In a some cases, information about the veteran
applicant will already reside in the site's patient database. If that is the
case, then the 1010EZ module is required to display both the newly submitted
data and the existing data for comparison purposes.\n
The Enrollment Application System requests ability to write data using FileMan
to the same fields in the INCOME PERSON (#408.13) file.\n
Since the 1010EZ is a means of initiating enrollment/registration, it is of
course necessary to commit the data to the database. Medical center users may
review and edit the data, as needed, before filing. The data placed in file
#408.13 will be further edited at the time of formal Registration and Means
Testing.", "", "", ""], ["3330", "DBIA3330", "File", "REGISTRATION", "2001/03/01", "APPROVED", "Active", "Private", "408.21", "
The Enrollment Application System requests ability to
read data via FileMan from several fields in the INDIVIDUAL ANNUAL INCOME
(#408.21) file.\n
The VistA-resident portion of the 1010EZ module accepts data transmitted to
the site electronically from a web-based application where a veteran has
entered enrollment data. In a some cases, information about the veteran
applicant will already reside in the site's patient database. If that is the
case, then the 1010EZ module is required to display both the newly submitted
data and the existing data for comparison purposes.\n
The Enrollment Application System requests ability to write data using FileMan
to the same fields in the INDIVIDUAL ANNUAL INCOME (#408.21) file.\n
Since the 1010EZ is a means of initiating enrollment/registration, it is of
course necessary to commit the data to the database. Medical center users may
review and edit the data, as needed, before filing. The data placed in file
#408.21 will be further edited at the time of formal Registration and Means
Testing.", "", "", ""], ["3331", "DBIA3331", "File", "REGISTRATION", "2001/03/01", "APPROVED", "Active", "Private", "408.22", "
The Enrollment Application System requests ability to
read data via FileMan from several fields in the INCOME RELATION (#408.22)
file.\n
The VistA-resident portion of the 1010EZ module accepts data transmitted to
the site electronically from a web-based application where a veteran has
entered enrollment data. In a some cases, information about the veteran
applicant will already reside in the site's patient database. If that is the
case, then the 1010EZ module is required to display both the newly submitted
data and the existing data for comparison purposes.\n
The Enrollment Application System requests ability to write data using FileMan
to the same fields in the INCOME RELATION (#408.22) file.\n
Since the 1010EZ is a means of initiating enrollment/registration, it is of
course necessary to commit the data to the database. Medical center users may
review and edit the data, as needed, before filing. The data placed in file
#408.22 will be further edited at the time of formal Registration and Means
Testing.", "", "", ""], ["3332", "PXRM REMINDERS AND CATEGORIES", "Remote Procedure", "CLINICAL REMINDERS", "2003/04/25", "APPROVED", "Active", "Controlled Subscription", "", "
Returns list of reminders and categories that may be
selected.", "", "", ""], ["3333", "PXRMAPI0", "Routine", "CLINICAL REMINDERS", "2004/03/02", "APPROVED", "Active", "Controlled Subscription", "", "
API calls for the reminder package:\n
1) CATREM^PXRMAPI0 Returns list of reminders and
sub-categories for a given category.\n", "", "PXRMAPI0", ""], ["3334", "DBIA 3334 Imaging download of XUSRB1", "Other", "KERNEL", "2005/03/10", "", "Retired", "Private", "", "
Kernel developers allow Imaging to dowload the XUSRB1,
XUMF333, and XULFDT routines onto satellite DICOM gateways. The routines are
not renamed nor modified on the gateways. Imaging is using supported APIs
from these routines. The Imaging DICOM workstations do not have KERNEL
installed, it has Micronetic M and a limited translation table to the hospital
datasets.\n
This IA will also request the following be provided on any future patches to
these routines. This will inform Imaging users on the procedures to follow
for downloading the Imaging routines on the gateways.\n
If you are running Vista Imaging, use the menu option to copy the routines
to the Imaging DICOM gateways as follows: "On the Vista server (hospital
database), use menu option 'Copy Routines to DICOM Gateway' located under the
'Imaging System Manager' Menu. Then on all Text and Image gateways use the
'System Maintenance' menu to select 'Gateway Configuration and DICOM Master
File' and then select 'Download Current Radiology and MAS Routines'. This will
cause the up-to-date versions of all radiology and MAS routines to be copied
to the gateway systems."", "", "", ""], ["3335", "Gather Logical Link Domain", "File", "HEALTH LEVEL SEVEN", "2001/03/06", "APPROVED", "Active", "Controlled Subscription", "870", "", "", "", ""], ["3336", "IB REFERENCING 433", "File", "ACCOUNTS RECEIVABLE", "2001/03/07", "APPROVED", "Active", "Private", "433", "
Various places in the IB package, such as MRA Extract
and Diagnostic Measures, need to pull transactions from AR. This agreement
allows IB to directly access the AR Transaction file (433).", "", "", "2021/11/09"], ["3337", "IB referencing 430.3", "File", "ACCOUNTS RECEIVABLE", "2006/04/27", "APPROVED", "Active", "Private", "430.3", "", "", "", ""], ["3338", "DBIA 3338 - Imaging & VADPT routines", "Other", "REGISTRATION", "2005/03/10", "", "Retired", "Private", "", "
Registration gives permission to VistA Imaging for
downloading VADPT* routines. Imaging is executing supported calls to
DEM^VADPT, INPT^VADPT and ADD^VADPT on satellite PC that have Micronetic M
installed.\n
In addition, Imaging is requesting that any future patches to these routines
will include a message informing Vista Imaging users to update their Imaging
gateways. A possible example follows.\n
If you are running Vista Imaging, use the menu option to copy the routines to
the Imaging DICOM gateways as follows: "On the Vista server (hospital
database), use menu option 'Copy Routines to DICOM Gateway' located under the
'Imaging System Manager' Menu. Then on all Text and Image gateways use the
'System Maintenance' menu to select Gateway Configuration and DICOM Master
File and then select 'Download Current Radiology and MAS Routines'. This will
cause the up-to-date versions of all radiology and MAS routines to be copied
to the gateway systems."", "", "", ""], ["3339", "DBIA 3339 - FBCS & File 2 fields", "File", "REGISTRATION", "2001/03/09", "APPROVED", "Active", "Controlled Subscription", "2", "
The subscribers are given permission to read the
following fields from the Patient file (#2).\n
Fields: .01 -NAME .02 -SEX .03 -DATE OF BIRTH .09 -SOCIAL SECURITY NUMBER 301
-TYPE 391 -SERVICE CONNECTED? 1901 -VETERAN (Y/N)?", "", "", "2008/12/11"], ["3340", "DBIA 3340 - Imaging & file 2 xreferences", "File", "REGISTRATION", "2001/03/09", "", "Withdrawn", "Private", "2", "
Registration gives VistA Imaging permission to create a
cross reference on the following fields: .01 (NAME), .03 (DATE OF BIRTH), and
.09 (SOCIAL SECURITY NUMBER). The cross reference created will not add to the
patient file global growth but execute a routine to create an HL7 message
during the initial entry into these field values or the editing of the field
values.", "", "", ""], ["3341", "DBIA3341", "File", "MAILMAN", "2001/03/26", "", "Pending", "Private", "3.8", "
Add POSTMASTER as member to MAIL GROUP "YS GAF
TRANSMISSION ACK", if no member(s) exist(s).", "", "", ""], ["3342", "DBIA3342", "File", "PAID", "2001/03/27", "APPROVED", "Active", "Private", "450", "
Integrated Billing has permission to access the PAID
EMPLOYEE file (#450) for the following fields described in this DBIA:", "", "", ""], ["3343", "DBIA3343", "Routine", "INTEGRATED BILLING", "2001/04/18", "APPROVED", "Active", "Private", "", "
Accounts Receivable has permission to make the
following calls to IB in order to get information about bills:", "", "IBCOIVM1", ""], ["3344", "DG FIELD MONITOR", "Other", "REGISTRATION", "2001/03/28", "APPROVED", "Active", "Controlled Subscription", "", "\n
This protocol is an event point which monitors the editing of
fields in DG* application files. At the time of this event point, the
following variables will be present in the environment:\n
Variable Description
-------- -----------------------------------------------
DGDA DA array as exists during Fileman editing
DGFILE File or subfile number where changed field resides
DGFIELD Number of changed field
DGTYPE Type of cross reference action (ADD, DELETE or UPDATE)
DGDTH Date/time of change in $Horolog format
DGUSER DUZ of user that made the change
DGOPT Current menu option in "option_name^menu_text" format
DGX X array as documented for Fileman new style x-refs
DGX1 X1 array as documented for Fileman new style x-refs
DGX2 X2 array as documented for Fileman new style x-refs\n
This protocol is triggered by "listener" cross references on selected
fields. By employing logic such as "If DGFILE=2, DGFIELD=.361,
DGTYPE="SET", then...", subscribers to this protocol may take action
based on edit activity which involves those fields.\n
This event point is designed to occur only once per field editing
activity. The DGTYPE variable can be interpreted as follows:\n
o ADD transactions indicate that data has been added to a field
that was previously null. The DGX, DGX1 and DGX2 arrays will
contain the Fileman X, X1 and X2 arrays (respectively) as
documented for the execution of 'SET' logic.\n
o DELETE transactions indicate that previously existing data has
been deleted without being replaced. The DGX, DGX1 and DGX2
arrays will contain the Fileman X, X1 and X2 arrays
(respectively) as documented for the execution of 'KILL' logic.\n
o UPDATE transactions indicate that existing data has been
deleted and new data has been filed. The DGX, DGX1 and DGX2
arrays will contain the Fileman X, X1 and X2 arrays
(respectively) as documented for the execution of 'SET' logic.", "", "", ""], ["3345", "DBIA3345", "Routine", "INTEGRATED BILLING", "2001/04/18", "APPROVED", "Active", "Private", "", "
Accounts Receivable has permission to make the
following calls to IB in order to get the classification (First or Third
Party) for an AR Category.", "", "IBJD1", ""], ["3346", "DBIA3346", "Routine", "ACCOUNTS RECEIVABLE", "2001/03/28", "APPROVED", "Active", "Private", "", "
Integrated Billing has permission to make the following
calls to AR in order get information about Repayment Plans. This information
is used in 2 reports: First Party Follow-up Report and Repayment Plan
Follow-up Report. Both of these reports belong to the Diagnostic Measures
module.", "", "RCBECHGA", ""], ["3347", "DBIA3347", "File", "ACCOUNTS RECEIVABLE", "2001/03/28", "APPROVED", "Active", "Private", "340", "
Integrated Billing has permission to access the
following fields on the AR DEBTOR file (#340):\n", "", "", ""], ["3348", "DBIA3348", "Routine", "ACCOUNTS RECEIVABLE", "2001/03/28", "APPROVED", "Active", "Private", "", "
Integrated Billing has permission to make the following
calls to AR in order to get information about Transactions (File #433):", "", "RCRJRCOT", ""], ["3349", "DBIA3349", "File", "OUTPATIENT PHARMACY", "2001/03/28", "", "Withdrawn", "Private", "52", "
Integrated Billing has permission to access the
following fields on the PRESCRIPTION file (#52):\n
GLOBAL REFERENCE:\n
^PSRX(D0,0)\n
.01 RX # 0;1 Direct Global Read
6 DRUG 0;6 Direct Global Read\n", "", "", ""], ["3350", "DBIA3350", "File", "INTEGRATED BILLING", "2001/03/28", "APPROVED", "Active", "Private", "351.73", "
Accounts Receivable has permission to access the
following fields on the IB DM WORKLOAD PARAMETERS file (#351.73):", "", "", ""], ["3351", "API CALL TO GET DOCUMENT TITLE IEN", "Routine", "TEXT INTEGRATION UTILITIES", "2001/04/03", "APPROVED", "Active", "Controlled Subscription", "", "
The Extrinsic Function $$WHATITLE^TIUPUTU will accept
the freetext name of a TIU DOCUMENT DEFINITION of type TITLE, and return its
Internal Entry Number in the TIU DOCUMENT DEFINITION File (#8925.1).", "", "TIUPUTU", ""], ["3352", "INPUT TEMPLATE RECOMPILATION", "Routine", "1", "2001/04/05", "APPROVED", "Active", "Controlled Subscription", "", "
Recompile compiled input templates that contain
specific fields within a file.", "", "DIKCUTL3", ""], ["3354", "Master File Server - IFR project", "Routine", "KERNEL", "2001/04/12", "", "Withdrawn", "Controlled Subscription", "", "
There are 2 API's used by the Master File Server
implemented by the Institution File Redesign (IFR) project -- XU*8.0*126.\n
MAIN^XUMFP sets up required parameters, and MAIN^XUMFI builds and sends the
HL7 message.", "", "XUMFP XUMFI", ""], ["3355", "EXPORTING NEW ASU STATUS ENTRIES", "File", "AUTHORIZATION/SUBSCRIPTION", "2001/04/13", "APPROVED", "Active", "Private", "8930.6", "
Periodically, when new functions for document
management are introduced by applications making use of ASU, it is necessary
to introduce new definitions for the state (or status) of the object being
acted upon, following the new processing event.\n
One example is support for the retraction of a TIU Document that was entered
in error for the wrong patient. To implement retraction, we needed to be able
to identify the new status "retracted," and declare business rules specifying
privileges for specific users to act on such documents. Such extensions
necessitate adding new entries to the USR RECORD STATUS FILE (#8930.6), and
distributing them with patches that implement the new functionality.\n
ASU grants permission to TIU to issue such updates to the USR RECORD STATUS
FILE (#8930.6), until otherwise agreed.", "", "", ""], ["3356", "Kernel Variable XQY0", "Other", "KERNEL", "2001/04/13", "APPROVED", "Active", "Controlled Subscription", "", "
Registration requests permission to reference the
variable XQY0 to obtain the current menu option. DG FIELD MONITOR logic will
be designed to run reguardless of the XQY0 being defined or set to "null".\n
The DG FIELD MONITOR protocol provides an event point to monitor field editing
in the DG* application files. Cross references and subscribers are added when
applications need to monitor activity on a field. XQY0 contains the current
menu option in the option name^menu text format when the cross references and
event point are executed. This information is made available to the
subscribing applications.\n
Variable: XQY0 = First node(zero subscript) of the current option.\n
Patient Name Standardization uses the XQY0 variable to identify the option
name. It will populate the NOTES ABOUT NAME (#11) field in the NAME
COMPONENTS (#20) file with the User's name, DUZ, and option name when an entry
is added or updated in the Name Components file.", "", "", ""], ["3357", "DBIA3357", "File", "1", "2001/04/16", "APPROVED", "Active", "Private", "", "
Inpatient Medications requests an agreement to allow
the deletion of the 'V' level for the .01 field of the MAR LABELS file
(#53.41). The level was apparently left over when the field was converted
from a 'VARIABLE POINTER' data type to a 'SET OF CODES' data type. The 'V'
level will be deleted in PSJ*5.0*57 with a direct KILL to the global.", "", "", ""], ["3358", "BRIEF CONSULTS HS COMP", "File", "CONSULT/REQUEST TRACKING", "2001/04/18", "APPROVED", "Active", "Private", "123", "", "", "", "2009/01/21"], ["3359", "DBIA3359", "File", "MAILMAN", "2001/04/23", "APPROVED", "Active", "Private", "3.8", "
This DBIA allows Accounts Receivable to delete a mail
group.\n
The Accounts Receivable code will first look to see if the mail group exists
in file 3.8 by looking at the B cross reference on the NAME (.01) field. If
the mail group exists, the code will next loop the AD cross reference on the
MEMBER GROUP NAME sub-field (.01) of the MEMBER GROUPS field (11) in file 3.8.
If the mail group is a member of another mail group, the mail group will be
removed from the MEMBER GROUPS field using DIK. Finally, the mail group will
be removed using DIK. The following is an example of the code that deletes
the IRS mail group:\n
S RCMIRSDA=+$O(^XMB(3.8,"B","IRS",0))
I RCMIRSDA D
. ; check to see if IRS mail group is a member of another
. ; mail group. If so, delete it from the other mail group.
. S RCDA(1)=0 F S RCDA(1)=$O(^XMB(3.8,"AD",RCMIRSDA,RCDA(1)))
Q:'RCDA(1) D
. . S RCDA=0 F S RCDA=$O(^XMB(3.8,"AD",RCMIRSDA,RCDA(1),RCDA))
Q:'RCDA D
. . . S DA(1)=RCDA(1),DA=RCDA,DIK="^XMB(3.8,"_RCDA(1)_",5,"
. . . D ^DIK
. ;
. ; delete the mail group
. S DA=RCMIRSDA,DIK="^XMB(3.8,"
. D ^DIK\n", "", "", ""], ["3362", "ACCESS TO FILE OPERATING ROOM FILE (131.7)", "File", "SURGERY", "2001/04/27", "APPROVED", "Active", "Controlled Subscription", "131.7", "
IFCAP developers are permitted to directly access the
NAME field (.01) of the OPERATING ROOM file (131.7) so that this information
can be accurately reported on the IFCAP PATIENT DISTRIBUTION COST REPORT.
This will resolve a NOIS that was generated due to the fact that previously
the report has used the pointer from the SURGERY file (130) field OPERATING
ROOM (.02) to access the HOSPITAL LOCATION file (44) field NAME (.01). With
this agreement in place IFCAP will be able to use the proper pointer to the
HOSPITAL LOCATION file (44) field NAME (.01), namely the NAME field (.01) of
the OPERATING ROOM file (131.7).", "", "", ""], ["3363", "ORWU DT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWU DT", "", ""], ["3364", "ORWLRR CHART", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWLRR CHART", "", ""], ["3365", "ORQQPL PROBLEM LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/03/18", "APPROVED", "Active", "Controlled Subscription", "", "
Parameters:\n
Patient DFN - DFN of patient from VistA\n
Context - The status of problems to return, passed as a single letter:
(A)ctive, (I)nactive, (B)oth, (R)emoved. If null, Active problems will be
returned.\n
Data is returned in ROOT. ROOT(0) is the number of items returned.
Subsequent entries in ROOT are the problems found along with other
information.\n\n
ROOT(#)=1 ifn ^ 2 status ^ 3 description ^ 4 ICD code ^ 5 onset date ^ 6 last
modified date ^ 7 Service Connected ("SC","NSC",or "") ^ 8 Special Exposures ^
9 Condition (T)ranscribed or (P)ermanent ^ 10 Location ^ 11 Location Type ^ 12
Provider (DFN;NAME) ^ 13 Service ^ 14 Priority ^ 15 Has Comment ^ 16 Date
Recorded ^ 17 SC Condition ^ 18 Inactive (set to # if the ICD code is
inactive) ^ 19 ICD Long Description (for problems with ICD codes only) ^ 20
ICD Coding System Abbreviation (ICD or 10D)\n
Sample return array\n
ROOT(0)=2\n
ROOT(1)="638^A^Hypertension (ICD-9-CM 401.9)^401.9^3050407^3070410^NSC
^^^^^10000000031;CPRSPROVIDER,FIFTY^1018;MEDICAL^C^0^3070410^NSC^^ UNSPECIFIED
ESSENTIAL HYPERTENSION^ICD"\n
ROOT(2)="1035^A^CAD - Coronary Artery Disease (SCT 53741008)^I25.10^
3170921^3170921^NSC^^P^^^10000000424;CPRSPROVIDER,ONE^^A^1^3170921^NSC ^^^10D"", "ORQQPL PROBLEM LIST", "", "2018/02/13"], ["3366", "ORWORR AGET", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWORR AGET", "", ""], ["3367", "ORWORR GET4LST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWORR GET4LST", "", ""], ["3368", "ORWLRR MICRO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWLRR MICRO", "", ""], ["3369", "ORWRP1 LISTNUTR", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWRP1 LISTNUTR", "", ""], ["3370", "DBIA3370", "Routine", "BAR CODE MED ADMIN", "2001/04/30", "APPROVED", "Active", "Private", "", "
For the Pharmacy Ordering Enhancements (POE) project it
is necessary to convert the orderable item in the PHARMACY PATIENT file (#55),
IV sub-file (#55.01). The same orderable item is also stored in the BCMA
MEDICATION LOG file (#53.79).\n
Inpatient Medications is requesting a one-time integration agreement with Bar
Code Medication Administration to allow updates to the BCMA MEDICATION LOG
file (#53.79) using FileMan. The updates would occur at the time of the POE
installation.", "", "PSJ0050", ""], ["3371", "ORWU HASKEY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2001/05/04", "APPROVED", "Active", "Controlled Subscription", "", "
Returns 1 if a user holds a security key, otherwise 0.", "", "", ""], ["3372", "TIU TEMPLATE FIELD", "File", "TEXT INTEGRATION UTILITIES", "2001/05/09", "APPROVED", "Active", "Private", "8927.1", "", "", "", ""], ["3373", "PSSUTLA1", "Routine", "PHARMACY DATA MANAGEMENT", "2001/05/10", "APPROVED", "Active", "Controlled Subscription", "", "
Pharmacy Data Management returns a DEA Special Handling
code for a Pharmacy Orderable Item, based on the Dispense Drugs that are
matched to that Pharmacy Orderable Item.\n
Pharmacy Data Management also returns the Computerized Patient Record System
(CPRS) Order Number when a Pharmacy Order Number is passed into the PLACER
component.\n
Pharmacy Data Management also returns the most appropriate Order Location when
a Pharmacy Order Number is passed into the LOC component.", "", "PSSUTLA1", "2019/10/02"], ["3374", "DBIA3374", "Routine", "ACCOUNTS RECEIVABLE", "2001/05/10", "APPROVED", "Active", "Private", "", "\n
Integrated Billing has permission to make the following call to AR to
determine if AR has cancelled a specific receivable associated with a
bill. The IB option [IB CANCEL BILL] allows a clerk to cancel a bill
which then invokes the call $$CANCEL^RCBEIB.\n", "", "RCBEIB", "2011/03/21"], ["3375", "CREATE/DELETE TIU DOCUMENT RECORDS", "Routine", "TEXT INTEGRATION UTILITIES", "2001/05/14", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Procedures will be using the MAKE^TIUSRVP API
to create TIU Document records and the DELETE^TIUSRVP API to delete TIU
DOCUMENT records.", "", "TIUSRVP", ""], ["3376", "DBIA3376", "File", "TEXT INTEGRATION UTILITIES", "2001/05/14", "APPROVED", "Active", "Controlled Subscription", "8925", "
This IA will document the fact that in the CP
TRANSACTION file (#702) has a field called TIU NOTE (Field #.06) which points
to the TIU DOCUMENT file (#8925).", "", "", ""], ["3377", "DBIA3377", "File", "TEXT INTEGRATION UTILITIES", "2001/05/14", "APPROVED", "Active", "Private", "8925.1", "
This IA is to document the fact that the CP DEFINITION
file (#702.01) has a field called DEFAULT TIU NOTE (Field #.04) which points
to the TIU DOCUMENT DEFINITION file (#8925.1).\n
This IA also documents the fact that field (#.05), USE TIU NOTE TITLE, of the
Sub-file (#703.91), MEDICINE FILE PARAMETERS, in the CP CONVERSION file
(#703.9) points to the TIU DOCUMENT DEFINITION file (#8925.1).", "", "", ""], ["3378", "DBIA3378", "Routine", "CLINICAL PROCEDURES", "2005/04/07", "APPROVED", "Active", "Controlled Subscription", "", "
This IA documents calls to MDAPI.", "", "MDAPI", ""], ["3380", "PSB VALIDATE ESIG", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
PSB VALIDATE ESIG is used to validate the data in
PSBESIG against the user currently signed on (DUZ).", "PSB VALIDATE ESIG", "", ""], ["3381", "DBIA3380-B", "Other", "BAR CODE MED ADMIN", "2001/05/21", "", "Pending", "Supported", "", "
Dictates to the client what RPC's a user can execute.", "", "", ""], ["3382", "PSB FMDATE", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
Used to validate Fileman dates.", "PSB FMDATE", "", ""], ["3383", "PSB SCANPT", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
This RPC is used to validate the data scanned in at the
scan patient wristband prompt of the mnOpenPatient component. The value
passed in is either the full SSN scanned in from the patient wristband -or-
the 1U4N syntax of the patient lookup. In either case the call must return
only one patient from the lookup. If the 1U4N syntax is used and multiple
patients are found the call returns an error. If only one patient is found
the RESULTS array is loaded with the patient data and passed back to the
client for verification.", "PSB SCANPT", "", ""], ["3384", "PSB USERLOAD", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
This RPC is called at application startup to populate
the BCMA_User object with the users defaults. No paramters are passed, the
current DUZ is assumed.", "PSB USERLOAD", "", ""], ["3385", "PSB DISPLAY ORDER", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
Returns a display for a selected order when double
clicked on the VDL.", "PSB DISPLAY ORDER", "", ""], ["3386", "PSB GETPRNS", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
Returns all administrations of a PRN order that have
NOT had the PRN Effectiveness documented for the last 30 days.", "PSB GETPRNS", "", ""], ["3387", "PSB GETORDERLIST", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
Returns the current order set for today to display on
the client VDL.", "PSB GETORDERLIST", "", ""], ["3388", "PSB REACTIONS", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
Returns detailed listing of reactions when Reactions
Button is clicked.", "PSB REACTIONS", "", ""], ["3389", "PSB SERVER CLOCK VARIANCE", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/21", "APPROVED", "Active", "Supported", "", "
Returns the variance from the server to the client in
minutes.", "PSB SERVER CLOCK VARIANCE", "", ""], ["3390", "PSB VALIDATE ORDER", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/22", "APPROVED", "Active", "Supported", "", "
Final check of order against an actual administration
date/time used immediately after scanned med has been validated to be a good
unadministered order and by the PSBODL (Due List) output.", "PSB VALIDATE ORDER", "", ""], ["3391", "PSB PARAMETER", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/22", "APPROVED", "Active", "Supported", "", "
Return a parameter list.", "PSB PARAMETER", "", ""], ["3392", "DBIA3390-C", "File", "BAR CODE MED ADMIN", "2001/05/22", "", "Pending", "Supported", "8989.51", "
Listing of division specific reasons why a meication is
given PRN. Up to 60 reasons are allowed.", "", "PSBPAR", ""], ["3393", "DBIA3390-D", "File", "BAR CODE MED ADMIN", "2001/05/22", "", "Pending", "Supported", "8989.51", "
Listing of division specific reasons why a medication
is held. Up to 60 reasons are allowed.", "", "PABPAR", ""], ["3394", "DBIA3390-E", "File", "BAR CODE MED ADMIN", "2001/05/22", "", "Pending", "Supported", "8989.51", "
Listing of division specific reasons why a medication
is refused. Up to 60 reasons are allowed.", "", "PSBPAR", ""], ["3395", "PSB TRANSACTION", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/22", "APPROVED", "Active", "Supported", "", "
This is the filing RPC for all data returning from the
client regarding the medication log. Filing is handled by business rules on
the server and this RPC will return either '1^Data Filed' or '-1^reason for
not filing data' to the client.\n
Business rules are conducted via the [0] node data. If a '+1^MEDPASS' is
encountered it is a complete new med pass and is validated as such.
Transaction type MEDPASS is the only type that requires a +1 in the first
piece of the header, all other transactions MUST supply a valid medication log
entry in the IENS.", "PSB TRANSACTION", "", ""], ["3396", "PSB SUBMIT MISSING DOSE", "Remote Procedure", "BAR CODE MED ADMIN", "2001/05/22", "APPROVED", "Active", "Supported", "", "
Allows the client to submit a missing dose
interactively.", "PSB SUBMIT MISSING DOSE", "", ""], ["3397", "Medicine Report Support", "File", "ORDER ENTRY/RESULTS REPORTING", "2001/05/29", "APPROVED", "Active", "Private", "", "
This DBIA documents the setting of data into a ^TMP
global that is used by CPRS to get a list of patient procedures for display on
the CPRS Reports Tab.\n
See DBIA #2757 for related information on API's used.", "", "", ""], ["3398", "ROUTINE SCMCUT", "Routine", "SCHEDULING", "2003/04/21", "", "Retired", "Controlled Subscription", "", "
In support of the Smart Card initiative, Registration
needs to use routine SCMCUT and the APIs in the routine to ensure that server
and client software running on both the local site and the remote site can run
together.", "", "SCMCUT", ""], ["3399", "ROUTINE SCUTBK3", "Routine", "SCHEDULING", "2001/05/30", "APPROVED", "Active", "Controlled Subscription", "", "
In support of hte Smart Card initiative the
Registration Package needs the use of Scheduling APIs contained in this
routine.", "", "SCUTBK3", ""], ["3400", "FILE 404.45", "File", "SCHEDULING", "2001/05/30", "APPROVED", "Active", "Controlled Subscription", "404.45", "
In support of the Smart Card initiative the
Registration package needs to use file 404.45 - PCMM SERVER PATCH file.", "", "", ""], ["3401", "FILE 404.46", "File", "SCHEDULING", "2001/05/30", "APPROVED", "Active", "Controlled Subscription", "404.46", "
In support of the Smart Card initiative the
Registration package needs to use file 404.46 - PCMM CLIENT PATCH file.", "", "", ""], ["3402", "DG SENSITIVE RECORD ACCESS", "Remote Procedure", "REGISTRATION", "2003/05/15", "APPROVED", "Active", "Supported", "", "\n
This Remote Procedure Call (RPC) will:\n
- Verify user is not accessing his/her own Patient file record if
the Restrict Patient Record Access (#1201) field in the MAS parameters
(#43) file is set to yes and the user does not hold the DG RECORD ACCESS
security key. If parameter set to yes and user is not a key holder , a
social security number must be defined in the New Person file for the
user to access any Patient file record.\n
- Determine if user accessing a sensitive record or an employee's
record.", "DG SENSITIVE RECORD ACCESS", "", ""], ["3403", "DG SENSITIVE RECORD BULLETIN", "Remote Procedure", "REGISTRATION", "2003/05/15", "APPROVED", "Active", "Supported", "", "\n
This Remote Procedure Call (RPC) will add an entry to the DG SECURITY LOG
(#38.1) file and/or generate the sensitive record access bulletin
depending on the value in ACTION input parameter. If ACTION parameter
not defined, defaults to update DG Security Log file and generate
Sensitive Record Access mail message.", "DG SENSITIVE RECORD BULLETIN", "", ""], ["3404", "UPDATE NEW-STYLE X-REF ONLY", "File", "1", "2001/06/01", "APPROVED", "Active", "Private", ".11", "\n\n
Registration is requesting to export New Style-Cross References to
registration files by setting the ^DD("IX" global nodes of the INDEX file
using UPDATE^DIE and WP^DIE. This methodology allows us to create New Style
cross-references without exporting the field itself. Listed below is an
example how the Filer Array would be populated.\n\n
;Create filer array
S DGFDA(.11,"+1,",.01)= ;FILE NUMBER
S DGFDA(.11,"+1,",.02)= ;X-REF NAME
S DGFDA(.11,"+1,",.11)="This X-ref invokes DG FIELD MONITOR "
;SHORT
DESCRIPTION
S DGFDA(.11,"+1,",.2)= ;TYPE
S DGFDA(.11,"+1,",.4)= ;EXECUTION
S DGFDA(.11,"+1,",.41)= ;ACTIVITY
S DGFDA(.11,"+1,",.5)= ;ROOT TYPE
S DGFDA(.11,"+1,",.51)= ;ROOT FILE NUMBER
S DGFDA(.11,"+1,",.42)= ;USE
S DGFDA(.11,"+1,",1.1)= ;SET LOGIC
S DGFDA(.11,"+1,",2.1)= ;KILL LOGIC
;CROSS REFERENCE VALUES
S DGFDA(.114,"+2,+1,",.01)= ;ORDER NUMBER
S DGFDA(.114,"+2,+1,",1)= ;TYPE OF VALUE
S DGFDA(.114,"+2,+1,",2)= ;FILE NUMBER
S DGFDA(.114,"+2,+1,",3)= ;FIELD NUMBER
S DGFDA(.114,"+2,+1,",7)= ;COLLATION
;DESCRIPTION
S DGWP(1)="This cross reference activates the DG FIELD MONITOR event
point."
S DGWP(2)="Applications that wish to monitor edit activity related to
this field may"
S DGWP(3)="subscribe to that event point and take action as indicated
by the changes"
S DGWP(4)="that occur. Refer to the DG FIELD MONITOR protocol for a
description of"
S DGWP(5)="the information available at the time of the event."
;File INDEX record
D UPDATE^DIE("","DGFDA","DGIEN","DGERR")
I $D(DIERR) D Q ;CHECK FOR ERROR
.N DGI S DGI=""
.F S DGI=$O(DGERR("DIERR",1,"TEXT",DGI)) Q:DGI="" D
..D MES^XPDUTL(DGERR("DIERR",1,"TEXT",DGI)) ;DISPLAY ERROR
..Q
.Q
;File DESCRIPTION field
D WP^DIE(.11,DGIEN(1)_",",.1,"","DGWP") ;FILE DESCRIPTION
Q", "", "", ""], ["3405", "TRIG DICR", "Routine", "1", "2001/06/01", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
Registration is requesting to use TRIG^DICR for the purposes of updating the
trigger logic when exporting New Style-Cross References in conjunction with
DBIA 3404 to registration files. Usage of this routine is outlined below.\n
TRIG^DICR(.fieldList,.outputList)\n
Where,\n
fieldList = (Input) Array of file/fields that may be triggered. The
trigger logic of fields that trigger the fields in
this list is modified, as necessary.\n
Format: fieldList(file#,field#)=""\n
outputList = (Output) This array is returned with the list of
fields whose trigger logic was modified.\n
Format: outputList(file#,field#)=""\n\n", "", "DICR", ""], ["3406", "MPIF* OPTIONS EXPORTED IN RG* PATCH", "Other", "MASTER PATIENT INDEX VISTA", "2001/06/20", "APPROVED", "Active", "Private", "", "\n
MPI/PD exports some MPIF* namespaced options in RG*1.0*19.\n
The following options are distributed via KIDS as "ATTACH TO MENU."
Master Patient Index Menu [MPIF VISTA MENU]
Coordinating Master of Record (CMOR) Request [MPIF CMOR MGR]
Patient File Initialization to MPI [MPIFINIT DPT TO MPI]
Site Parameters Edit for CMOR [MPIF SITE PARAMETER]", "", "", ""], ["3407", "DEFINITIONS AND ENTITIES", "File", "TOOLKIT", "2001/06/05", "", "Pending", "Controlled Subscription", "8989.51", "", "", "", ""], ["3408", "PARAMETER ENTITY", "File", "TOOLKIT", "2001/06/05", "APPROVED", "Active", "Controlled Subscription", "8989.518", "", "", "", "2001/06/30"], ["3409", "DIRECT READ OF USER CLASS FILE", "File", "AUTHORIZATION/SUBSCRIPTION", "2004/11/29", "APPROVED", "Active", "Private", "8930", "
TIU requests the ability to directly read the "B" cross
reference of USR(8930 (The ASU User Class File #8930). This is to support the
ability to check if a specific USER class exists.", "", "", ""], ["3410", "3410", "File", "CLINICAL REMINDERS", "2004/10/28", "APPROVED", "Active", "Controlled Subscription", "801.41", "
Clinical Reminders is allowing access to the Reminder
Dialog file.", "", "", ""], ["3411", "DBIA3411", "Routine", "CLINICAL REMINDERS", "2001/06/25", "APPROVED", "Active", "Private", "", "
Routine to delete the reminder patient data cache for a
selected patient.", "", "PXRMPINF", ""], ["3412", "Print Encounter Forms", "Routine", "AUTOMATED INFO COLLECTION SYS", "2001/06/25", "APPROVED", "Active", "Supported", "", "
The Registration package needs to be able to Print an
Encounter Form while Registering a Patient through the GUI Registration.", "", "IBDF1B1", ""], ["3413", "Download VIC Data", "Routine", "REGISTRATION", "2001/06/25", "", "Withdrawn", "Supported", "", "
The Registration package needs to be able to download
VIC data during the GUI Registration process.", "", "DGQESC5", ""], ["3414", "Request Record", "Routine", "RECORD TRACKING", "2001/06/25", "", "Withdrawn", "Private", "", "
The Registration package needs to be able to request
records (and print bar code labels) while Registering a Patient.", "", "RTQ2", ""], ["3415", "DBIA3415", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2001/06/26", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management will invoke this CPRS routine
for conversions, as part of the install process of phase 2 of the Pharmacy
Ordering Enhancements project. This phase 2 is released as 1 build, containing
patches OR*3*94, PSJ*5*50, PSO*7*46 and PSS*1*38.", "", "ORY94", ""], ["3416", "DBIA3416", "Routine", "INPATIENT MEDICATIONS", "2001/06/27", "APPROVED", "Active", "Private", "", "
The purpose of this API is to allow Bar Code Medication
Administration (BCMA) to expire/reinstate Inpatient Medications orders based
on an administration event.", "", "PSJBCMA4", ""], ["3417", "EXAM STATUS ORDER", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2001/06/28", "APPROVED", "Active", "Controlled Subscription", "72", "
As data is gathered, it may be stored in ^TMP("RAE",$J,
which global may be killed before and after use.", "", "", ""], ["3418", "DBIA3418", "Routine", "LAB SERVICE", "2001/07/15", "", "Withdrawn", "Controlled Subscription", "63", "
This API retrieves and returns data from the ABO GROUP
field #.05 and RH TYPE field #.06 in the Lab Data file #63 for a given patient
if available.", "", "LRBLAPI", ""], ["3419", "TIU use of Appt. Multiple (#2.98)", "File", "SCHEDULING", "2003/04/03", "", "Retired", "Private", "2.98", "
TIU uses a call to EN^DIQ1 to retrieve fields
.01;100;9.5 from the Appointment multiple (#2.98) for a Patient.\n
TIU loops through the ^DPT(DFN,"S",IEN global to obtain the Appointment
multiple IEN for the patient.\n
The variable DA is set to DFN and DA(1) is set to IEN before calling EN^DIQ1
to obtain the field values.\n
The information obtained is then displayed to the user in External Format when
prompting the user to select a Scheduled Visit in TIU.\n
This agreement will have to change with the Scheduling Redesign.", "", "", ""], ["3420", "NOK Work Phone", "File", "REGISTRATION", "2001/07/19", "APPROVED", "Active", "Controlled Subscription", "2", "
CPRS GUI users have requested to see the Next-of-Kin's
work phone number on the CPRS patient inquiry display. Other NOK data is
pulled from VADPT, but work phone is not available.\n
Registration developers from 2001 determined that VADPT should enter an
integration agreement to reference this field until such time as VADPT can be
modified to add the work number to the array returned.", "", "", ""], ["3421", "IFR MFS and HL7 AC x-ref", "Routine", "HEALTH LEVEL SEVEN", "2001/07/20", "", "Withdrawn", "Private", "", "
The IFR project performs a clean up of the INSTITUTION
file #4. It first queries FORUM using the HL7 package direct connect. If for
some reason the connection drops, HL7 may not clean up HLMA("AC","O",link,mid)
which causes problems with subsequent direct connects to the same link.\n
The HL7 team is working on a patch. In the mean time I'd like to check for
this bad x-ref before I try to connect. This would allow IFR to proceed with
patch XU*8*206 (the check would be implemented in XU*8*209.)", "", "XUMF4", ""], ["3422", "DBIA3422", "File", "REGISTRATION", "2001/07/23", "APPROVED", "Active", "Private", "391.71", "
MPI/PD requires read only access to ^VAT(391.71,"AXMIT"
to order through the cross-reference and get a count of the number of Treating
Facility Updates and Data Updates waiting to be processed.", "", "", ""], ["3423", "DBIA3423", "Routine", "PHARMACY DATA MANAGEMENT", "2001/07/25", "APPROVED", "Active", "Private", "", "
This call provides a Schedule validation check for
medication orders entered through Computerized Patient Record System (CPRS).", "", "PSSGS0", ""], ["3424", "DBIA3424", "Routine", "PHARMACY DATA MANAGEMENT", "2001/07/25", "APPROVED", "Active", "Private", "", "
When phase 2 of the Pharmacy Ordering Enhancements
project is installed, a rematching process will occur at the time of install,
where IV Additives and IV Solutions will be matched to new Pharmacy Orderable
Items. Pharmacy needs to provide this new information to CPRS, so CPRS can
update as many of their Quick Orders as possible. The old pointer values will
be stored in an XTMP global for 30 days to assist in this process.", "", "PSSQORD", ""], ["3425", "Consult editing utilities", "Routine", "CONSULT/REQUEST TRACKING", "2001/08/03", "APPROVED", "Active", "Controlled Subscription", "", "
The included entry points allow access to information
about editng and resubmitting records in the Consult/Request Tracking package.\n", "", "GMRCEDT2", ""], ["3426", "DBIA3426", "File", "REGISTRATION", "2001/08/06", "APPROVED", "Active", "Private", "45", "
Incomplete Records Tracking is accessing the CLOSE OUT
FILE Field (#7.1). CLOSE OUT FILE Field (#7.1) is a pointer to the PTF CLOSE
OUT File (#45.84) which will be use to return a close out date entry.", "", "", ""], ["3427", "Purchase Card info", "File", "IFCAP", "2001/11/14", "APPROVED", "Active", "Controlled Subscription", "440.6", "
This is a one time request, limited duration
integration agreement. This request is limited to use within changes to
Prosthetics version 3.0 made by patch RMPR*3*67. This agreement and the
changes made by patch RMPR*3*67 will be terminated at the time that IFCAP
releases patch PRC*5.1*45 which is an updated API that meets the extended
needs of Prosthetics. This agreement is needed to allow sites to reconcile
Prosthetics Orders that had their Purchase Card numbers changed by the credit
card supplier.\n
This agreement includes a direct global read only access of the "D" cross-
reference at ^PRCH(440.6,"D",date) for processing time needs. As part of this
one time request, limited duration integration agreement, direct global read
only access of ^PRC(442,ien,0) first piece is requested.", "", "", ""], ["3428", "DBIA3428", "File", "REGISTRATION", "2001/08/08", "", "Withdrawn", "Private", "45.84", "
Incomplete Records Tracking is accessing two fields in
the PTF CLOSE OUT File (#45.84). CLOSE OUT DATE Field (#2) is a date field
and CLOSE OUT BY Field (#3) is a pointer to the NEW PERSON File (#200). Both
calls use the $DATA function on the zero node to varify that the node exists
prior to getting the fields.", "", "", ""], ["3429", "DBIA #3429", "File", "ORDER ENTRY/RESULTS REPORTING", "2001/11/14", "APPROVED", "Active", "Private", "101.24", "", "", "", ""], ["3430", "DBIA3430", "File", "REGISTRATION", "2001/08/09", "APPROVED", "Active", "Private", "40.8", "
Incomplete Records Tracking is accessing the NAME
(#.01) field of the MEDICAL CENTER DIVISION (#40.8) file.\n
Incomplete Records Tracking uses the following reference: "B" cross reference
^DG(40.8,"B",DA)\n
-----------------------------\n
Incomplete Records Tracking has retained full authority for the "DT" node and
its fields located and maintained in the MEDICAL CENTER DIVISION (#40.8) File.
This includes development of the data dictionary (DD) for these fields, as
well as responsibility for data entry into and data retriveval from these
fields.\n
This agreement is a "delegation of custody" of these fields from Registration
to Incomplete Records Tracking. It provides Incomplete Records Tracking all
rights and privileges to development and distribution for all DD elements and
data in these fields. In addition, all DBIAs required for access to the DD
and data for these fields will be between any subscriber and Incomplete
Records Tracking as the custodian.", "", "", ""], ["3431", "DBIA3431", "File", "REGISTRATION", "2001/08/09", "APPROVED", "Active", "Private", "43", "
1. Incomplete Records Tracking has retained full
authority for the "IRT" node and its field IRT BACKGROUND JOB LAST RUN (#401)
located in the MAS PARAMETERS (#43) File.\n
2. Incomplete Records Tracking has retained full authority for the field IRT
SHORT FORM LIST GROUP (#513) located in the MAS PAREMETERS (#43) File.\n
This includes development of the data dictionary (DD) for these fields, as
well as responsibility for data entry into and data retriveval from these
fields.\n
This agreement is a "delegation of custody" of these fields from Registration
to Incomplete Records Tracking. It provides Incomplete Records Tracking all
rights and privileges to development and distribution for all DD elements and
data in these fields. In addition, all DBIAs required for access to the DD
and data for these fields will be between any subscriber and Incomplete
Records Tracking as the custodian.", "", "", ""], ["3432", "DBIA3432", "File", "REGISTRATION", "2001/08/09", "APPROVED", "Active", "Private", "405", "
Incomplete Records Tracking has retained full authority
for the "IRT" node and its field IRT BACKGROUND JOB RUN (#60.01) located in
the PATIENT MOVEMENT (#405) File. This includes development of the data
dictionary (DD) for these fields, as well as responsibility for data entry
into and data retriveval from these fields.\n
This agreement is a "delegation of custody" of these fields from Registration
to Incomplete Records Tracking. It provides Incomplete Records Tracking all
rights and privileges to development and distribution for all DD elements and
data in these fields. In addition, all DBIAs required for access to the DD
and data for these fields will be between any subscriber and Incomplete
Records Tracking as the custodian.", "", "", ""], ["3433", "DBIA3433", "File", "REGISTRATION", "2001/08/09", "APPROVED", "Active", "Private", "40.8", "
Incomplete Records Tracking is accessing the NAME Field
(#.01) of the MEDICAL CENTER DIVISION (#40.8) File.\n
Incomplete Records Tracking uses the following cross references: "B" cross
reference ^DG(40.8,"B",DA)", "", "", ""], ["3434", "DIALOG File Entry Deletion", "File", "1", "2001/08/13", "APPROVED", "Active", "Private", ".84", "\n
When creating patch RGED*2.6*1 to remove Extensible Editor v.2.6,
we tried to eliminate the DIALOG (#.84) file entries distributed
with the package (9960001 - 9960070) by placing them in the build
and marking them as DELETE AT SITE. KIDS did not remove them
on the target system because delete access on File .84 is set
to an "^".\n
Therefore, a private integration agreement is established to
allow the reference to ^DI(.84 using the following code in RGEDPST.\n
;Delete DIALOG file entries 9960001 through 9960070.
N RGEDLOG
W !!," Deleting Extensible Editor dialog entries.",!," "
S DIK="^DI(.84,"
F RGEDLOG=9960001:1:9960070 S DA=RGEDLOG D ^DIK W "."
W !!," DIALOG entries 9960001 through 9960070 have been deleted."", "", "", ""], ["3435", "CONTROL CODES SUBFILE", "File", "KERNEL", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "3.2", "
The purpose of this agreement is to allow direct MUMPS
read access to the CONTROL CODES subfile (#3.2055) of the TERMINAL TYPE file
(#3.2). Any subscribing package must coordinate the ABBREVIATION and FULL
NAME information with the KERNEL developers when subscribing to this
agreement. Also, the agreed upon control codes should be added to this
agreement for documentation.\n
Inpatient Medications is using the control codes to create generic print
routines for barcode printing. Inpatient Medications will use the following
control codes, as will Registration and Bar Code Medication Administration
(BCMA).:\n
ET - End Text
ETF - End Text Field
EB - End Barcode
EBF - End Barcode Field
EL - End Label
FE - Format End
FI - Format Initialization
FI1 - Format Initialization 1
FI2 - Format Initialization 2
SB - Start Barcode
SBF - Start Barcode Field
SL - Start Label
ST - Start Text
STF - Start Text Field
SM - Start Med Route
SMF - Start Med Route field
EM - End Med Route
EMF - End Med Route field\n
Outpatient Pharmacy is using the control codes to create a generic print
routine for laser labels. Outpatient Pharmacy will use the following control
codes:\n
ACI = ADDRESS CHANGE INITIALIZATION
ALI = ALLERGY SECTION INITIALIZATION
AWI = ALLERGY WARNING INITIALIZATION
BLB = BOTTLE LABEL BODY INITIALIZATION
BLBC = BOTTLE LABEL BARCODE
BLF = BOTTLE LABEL FOOTER INITIALIZATION
BLH = BOTTLE LABEL HEADER INITIALIZATION
CDII = CRITICAL DRUG INTERACTION INITIALIZATION
CNI = COPAY NARRATIVE INITIALIZATION
EBLBC = END OF BOTTLE LABEL BARCODE
EBT = END OF BARCODE TEXT
F10 = TEN POINT FONT - NO BOLD
F10B = TEN POINT FONT, BOLDED
F12 = TWELVE POINT FONT - NO BOLD
F12B = 12 POINT FONT BOLDED
F6 = SIX POINT FONT - NO BOLD
F8 = EIGHT POINT FONT - NO BOLD
F9 = NINE POINT FONT - NO BOLD
FDU = FONT DISABLE UNDERLINE
FWU = FONT WITH UNDERLINE
LL = LASER LABEL
LLI = LASER LABEL INIT
MLI = MAILING LABEL INITIALIZATION
NR = NORMAL ROTATION
PFDI = PHARMACY FILL DOCUMENT INITIALIZATION
PFDQ = PHARMACY FILL DOCUMENT QUANTITY
PFDT = PHARMACY FILL DOCUMENT TRAILER
PFDW = PHARMACY FILL DOCUMENT WARNING
PFI = PATIENT FILL INITIALIZATION
PII = PATIENT INSTRUCTION INITIALIZATION
PMII = PMI SECTION INITIALIZATION
RMI = RETURN MAIL INITIALIZATION
RNI = REFILL NARRATIVE INITIALIZATION
RPI = REFILL PRINT INITIALIZATION
RT = ROTATE TEXT
SBT = START OF BARCODE TEXT
SPI = SUSPENSE PRINT INITIALIZATION
ST = START OF TEXT
WLI = WARNING LABEL INITIALIZATION", "", "", "2021/08/17"], ["3436", "CALLS TO TIUSRVR", "Routine", "TEXT INTEGRATION UTILITIES", "2001/08/15", "APPROVED", "Active", "Controlled Subscription", "", "", "", "TIUSRVR", ""], ["3437", "REGISTRATION FILE USED BY TIU - DG(40.8", "File", "REGISTRATION", "2001/08/15", "APPROVED", "Active", "Private", "40.8", "
TIU extracts INSTITUTION FILE POINTER data from the
MEDICAL CENTER DIVISION file (#40.8) for a one-time use in the installation
environment check routine TIUEN113.", "", "TIUEN113", ""], ["3438", "TIU GET REQUEST", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2001/08/15", "APPROVED", "Active", "Controlled Subscription", "", "
This Remote Procedure returns the variable pointer to
the REQUESTING PACKAGE REFERENCE (File #8925, Field #1405). This would be the
record in the Requesting Package (e.g., Consult/Request Tracking or Surgery)
for which the resulting document has been entered in TIU.\n
INPUT PARAMETER: TIUDA PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1 DESCRIPTION:
This is the record number (IEN) of the document in the TIU Document File
(#8925).\n
RETURN PARAMETER DESCRIPTION:
This is the Variable pointer (e.g., "15741;GMR(123,") to the
corresponding request.", "", "", ""], ["3439", "TIU GET ALERT INFO", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2001/08/15", "APPROVED", "Active", "Controlled Subscription", "", "
Given a TIU XQAID, return the patient and document type
for the item being alerted.\n
INPUT PARAMETER: XQAID PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 60 REQUIRED: YES DESCRIPTION:
The XQAID of the alert.\n
RETURN PARAMETER DESCRIPTION:
TIUDA^DFN^<gui tab indicator>\n
where\n
TIUDA is the document IEN in the TIU DOCUMENT File (#8925),
DFN is the IEN of the Patient in the PATIENT File (#2), and
<gui tab indicator> is an arbitrarily set constant based on the
document type.", "", "", ""], ["3440", "TIU PRINT DRIVER", "Routine", "TEXT INTEGRATION UTILITIES", "2001/08/15", "APPROVED", "Active", "Controlled Subscription", "", "
The API RPC^TIUPD is called both from the remote
procedure TIU PRINT RECORD, as documented in DBIA #1834 and MUMPS-to-MUMPS, to
print a given record to a named device, either for work or chart copies, and
will accommodate both Windows and host printers.", "", "TIUPD", ""], ["3441", "CALLS TO TIUSRVLI", "Routine", "TEXT INTEGRATION UTILITIES", "2001/08/16", "APPROVED", "Active", "Controlled Subscription", "", "
CPRS makes use of several APIs in TIUSRVLI to determine
the complete hierarchical context of a given document when building the
TreeView for the Notes, Summaries, and Consults tabs.", "", "TIUSRVLI", ""], ["3442", "ZIS GLOBAL", "File", "KERNEL", "2003/02/27", "APPROVED", "Active", "Controlled Subscription", "3.2", "
This DBIA describes access needed by packages to
various parts of the global/file ^%ZIS(2", "", "", ""], ["3443", "Check RAD/NUC MED REPORTS file header", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2001/08/17", "APPROVED", "Active", "Private", "74", "
There are two permissions granted through this
Integration Agreement (IA).\n
The first is that VistA Imaging will be granted permission to examine the file
header of the RAD/NUC MED REPORTS (#74) file. The purpose is to allow Imaging
to verify that the counter in the file header (third piece of ^RARPT(0)) has
not decreased significantly since it was last inspected.\n
This approach will enable us to detect major status changes in the global that
could be caused by a global restoration, compression, or global move.\n\n
The second is that VistA Imaging will be granted permission to traverse the
top-level 'B' cross reference for records in the RAD/NUC MED REPORTS file. The
'B' cross reference is created via VA FileMan and is placed on the .01 field
of the file. The name of the .01 field of the RAD/NUC MED REPORTS file is
DAY-CASE#.", "", "", "2010/08/13"], ["3444", "REGISTRATION FILE USED BY TIU - DG(43", "File", "REGISTRATION", "2001/08/16", "APPROVED", "Active", "Controlled Subscription", "43", "
TIU extracts MULTIDIVISION MED CENTER? data from the
MAS PARAMETERS file (#43) for use in routine TIULA and TIULA1 to determine if
a facility is multidivisional.", "", "", ""], ["3445", "Determine the Service associated with a ward.", "File", "REGISTRATION", "2001/08/22", "APPROVED", "Active", "Private", "42", "
In order to determine whether an exam gets sent to PCE
for crediting, a check on the patient's physical location must be performed.
If the patient is currently being seen in a clinic, or if the patient is
assigned to a ward and that ward has a Service defined as Domiciliary, then
the record passed this check and can be passed to PCE if other checks are
successful.\n
I need to get the Service associated with a ward location, and I am requesting
to achieve this by utilizing a "read with FileMan" utility:\n
$$GET1^DIQ(42,ien of file 42 record,.03,"I" -or- "E") where:\n
Where '42' is the file number for the WARD LOCATION file, the second subscript
is self-explanatory, '.03' is the SERVICE field number and 'I' indicates we'd
like the internal representation, while 'E' indicates that we'd like the
external representation of the data.", "", "", ""], ["3446", "coreFLS Foreign File Format", "File", "1", "2001/08/23", "APPROVED", "Active", "Private", ".44", "
coreFLS needs to obtain data from various files to
populate their tables with legacy data. One method being used is the FileMan
data export tools. Since it is not possible to send FileMan Foreign File
formats via KIDS, we will need to populate FOREIGN FORMAT file (#.44) with an
entry.", "", "", ""], ["3447", "coreFLS Export Templates", "File", "1", "2001/08/23", "APPROVED", "Active", "Private", ".4", "
With the new entry into the FOREIGN FORMAT file (#.44)
(see IA 3446), the PRCL* namespaced export templates in the PRINT TEMPLATE
file (#.4) will need to have the EXPORT FORMAT field (#105) updated to be the
foreign format IEN.", "", "", ""], ["3448", "PSB MEDICATION HISTORY REPORT", "Routine", "BAR CODE MED ADMIN", "2001/09/10", "APPROVED", "Active", "Private", "", "
The purpose of this agreement is to provide other
packages with the ability to call the BCMA Medication History report. It
returns a report of medications a patient has received by orderable item.", "", "PSBML", "2015/08/03"], ["3449", "ADVERSE REACTION ASSESSMENT", "File", "ADVERSE REACTION TRACKING", "2001/09/11", "APPROVED", "Active", "Controlled Subscription", "120.86", "", "", "", "2014/09/30"], ["3450", "VITALS TYPE POINTER", "File", "GEN. MED. REC. - VITALS", "2001/09/11", "", "Pending", "Controlled Subscription", "120.51", "", "", "", ""], ["3451", "TIU/SELECTED PROGRESS NOTES", "File", "TEXT INTEGRATION UTILITIES", "2001/09/11", "APPROVED", "Active", "Private", "8925.1", "", "", "", ""], ["3452", "MAIL.CIO.DNS Domain", "File", "MAILMAN", "2001/09/13", "APPROVED", "Active", "Private", "4.2", "\n
CIRN MPI/PD has an agreement to do a read with FileMan on the
NAME (#.01) field in the DOMAIN (#4.2) file. This is used in
environment check routine, RGP22ENV, to ensure that the instructions
in informational patch XM*DBA*139 have been followed for domain
"MAIL.CIO.DNS". The environment check routine will not allow
patch RG*1.0*22 to be installed unless the "MAIL.CIO.DNS"
entry exists. Patch RG*1.0*22 is in support of GCPR.", "", "", ""], ["3453", "Enter/Edit OFFICE OF INFORMATION SRV CNTR Entry", "File", "KERNEL", "2001/09/13", "APPROVED", "Active", "Private", "4", "\n
CIRN MPI/PD has an agreement to use a FileMan FILE^DICN call to
edit the following fields in the INSTITUTION (#4) file.
NAME (#.01), STATE (#.02), STATUS (#11), FACILITY TYPE (#13),
STATION NUMBER (#99) and OFFICAL VA NAME (#100).\n
This is done in pre-install routine, PRE^RGP22, to create the
OFFICE OF INFORMATION SRV CNTR entry in the INSTITUTION file if
it is not present. This functionality is in support of GCPR.\n
The entry created has the following values.
NAME: OFFICE OF INFORMATION SRV CNTR
STATE: OHIO", "", "", ""], ["3454", "Enter/Edit NODE Entry in HL LOGICAL LINK (#870)", "File", "HEALTH LEVEL SEVEN", "2001/09/13", "APPROVED", "Active", "Private", "870", "\n
MPI/PD build RG*1.0*22 exports (via KIDS) the following HL LOGICAL LINK.
NODE: NODE
INSTITUTION: OFFICE OF INFORMATION SRV CNTR
LLP TYPE: TCP AUTOSTART: Enabled
DOMAIN: MAIL.CIO.DNS QUEUE SIZE: 10
EXCEED RE-TRANSMIT ACTION: restart TCP/IP ADDRESS: 127.0.0.1
TCP/IP PORT: XXXX TCP/IP SERVICE TYPE: CLIENT (SENDER)\n
Post-install routine PST^RGP22, determines if the account is the
production or test account. (IA #3335 and #2525 allow the read
access necessary to do this.)\n
If the account is the test account, we do not want the 'NODE' node
to be actively used. Therefore, the DOMAIN (#.03) and TCP/IP ADDRESS
(#400.01) fields are omitted in the post-install.\n
CIRN MPI/PD has an agreement to use a FileMan DIE call to edit/eliminate
the DOMAIN (#.03) and TCP/IP ADDRESS (#400.01) fields in the HL LOGICAL
LINK (#870) file for entry 'NODE'. This functionality is in support
of GCPR.", "", "", ""], ["3455", "DBIA3455", "File", "PCE PATIENT CARE ENCOUNTER", "2001/09/14", "APPROVED", "Active", "Private", "9000010.06", "", "", "", ""], ["3456", "DBIA3456-A", "Routine", "REGISTRATION", "2001/09/18", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this API is to facilitate the filing of
the Head/Neck Cancer Diagnosis into the NOSE AND THROAT RADIUM HISTORY
(#28.11) file when verified through an external application (i.e. PCE
Encounter Checkout).", "", "DGNTAPI1", ""], ["3457", "DBIA3457", "Routine", "REGISTRATION", "2001/09/18", "APPROVED", "Active", "Supported", "", "
The purpose of this API is to facilitate the retrieval
of veterans' Nose/Throat Radium (NTR) Treatment information from the NOSE AND
THROAT RADIUM HISTORY (#28.11) file. The primary mechanism is within the
Registration package.", "", "DGNTAPI", ""], ["3458", "OUTPATIENT PHARMACY ORDER STATUS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2001/09/25", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORQOR2", ""], ["3459", "PSB MEDICATION HISTORY REPORT", "Routine", "BAR CODE MED ADMIN", "2001/09/25", "APPROVED", "Active", "Supported", "", "
The purpose of this agreement is to provide other
packages with the ability to call the BCMA Medication History report. It
returns a report of medications a patient has received by orderable item.\n
This DBIA is for BCMA Version 2.0 only.", "", "PSBMLHS", "2015/08/03"], ["3460", "TIU pointer validation", "File", "TEXT INTEGRATION UTILITIES", "2001/09/26", "APPROVED", "Active", "Private", "8925", "", "", "", ""], ["3461", "TIU pointer validation", "File", "TEXT INTEGRATION UTILITIES", "2001/09/26", "APPROVED", "Active", "Controlled Subscription", "8925.91", "
The Text Integration Utilities application grants
Imaging permission to read data in file 8925.91. At the time of image
acquisition on the DICOM gateway, the only piece of information sent with the
image is the associated TIU note entry in file 8925. The gateway needs to
determine if an Imaging pointer exists for this document in file 8925.91.", "", "", ""], ["3462", "DBIA3462", "Routine", "OUTPATIENT PHARMACY", "2001/10/01", "APPROVED", "Active", "Private", "", "
A private IA for IB to call PSO to make them aware of a
billing event that has taken place.", "", "PSOCPIB", ""], ["3463", "PHARMACY ORDER DISCONTINUED DATE/TIME", "File", "ORDER ENTRY/RESULTS REPORTING", "2001/10/02", "APPROVED", "Active", "Controlled Subscription", "100", "\n\n
Outpatient Pharmacy package request permission to access the ORDER file
(#100).\n
Outpatient Pharmacy option, the Expire Prescriptions [PSO EXPIRE
PRESCRIPTIONS], routine PSOHLEXP, flags prescriptions that have passed the
expire date as expired and sends an HL7 message across to CPRS to flag those
prescriptions as expired. Recently we noticed that it not only sends the
expire message for expired prescriptions but also for discontinued
prescriptions, and as a result in CPRS the discontinued prescriptions are
flagged as expired, which is incorrect. Outpatient Pharmacy will correct the
statuses of all those prescriptions in CPRS from expired status to
discontinued status. This will be a one-time request.", "", "", ""], ["3464", "HL(772 Diagnostic Utility", "File", "HEALTH LEVEL SEVEN", "2001/10/03", "APPROVED", "Active", "Controlled Subscription", "772", "\n
This IA supports a diagnostic utility used for problem resolution
with messaging issues associated with HL7 data transmissions for
MPI/PD. The tool will be available for diagnostic purposes as
needed by the development team or NVS.\n
The utility compiles data from the HL7 MESSAGE TEXT (#772) file
for a selected date range. Each HL7 message in the date range
is examined. If the RELATED EVENT PROTOCOL (#10) field contains
the MPI/PD protocols (e.g., ""VAF"", ""RG"", or ""MPI"") data is
stored in the ^XTMP("RGMT","HL" array. A cross-reference is built
on patient ICN and DFN for faster data retrieval for the associated
reports. Direct global reads are necessary for efficiency and speed
for the data compilation process.\n
A number of diagnostic reports are generated from the compiled data
including the following.
HL7 Activity by Patient for a Single Protocol for Date Range
HL7 Activity by Patient for All MPI/PD Protocols for Date Range
HL7 Message Status Summary Report (total number of messages
for each date in range, transmission type, and status)
Detailed HL7 Message Status Report", "", "", ""], ["3465", "Clinical Registries", "File", "LAB SERVICE", "2001/10/16", "APPROVED", "Active", "Private", "63", "
The Clinical Registries package requires the ability to
send Autopsy data to the national registry. Therefore access to the
^LR(D0,"AU" node is required.\n
1) Access Autopsy node:\n
^LR(D0,"AU") - ("AU";1)("AU";5)("AU";6)("AU";12)", "", "", ""], ["3466", "DBIA3466-A", "Routine", "GENERIC CODE SHEET", "2001/10/05", "APPROVED", "Active", "Supported", "", "
This IA allows a package to set a key for easily
looking up a Generic Code Sheet Stack File document in file 2100.1.", "", "GECSSTAA", ""], ["3467", "DBIA3466-B", "Routine", "GENERIC CODE SHEET", "2001/10/05", "APPROVED", "Active", "Supported", "", "
This IA allows a package to lookup a Generic Code Sheet
Stack File document in file 2100.1 based on a key set by SETKEY^GECSSTAA.", "", "GECSSGET", ""], ["3468", "CLINICAL PROCEDURE UTILITIES", "Routine", "CONSULT/REQUEST TRACKING", "2001/10/10", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement describes several utilities
used to gather information or update Consult records involved in the Clinical
Procedures interface to Consult/Request Tracking.", "", "GMRCCP", "2008/03/19"], ["3469", "RGJUSITE", "Routine", "CLINICAL INFO RESOURCE NETWORK", "2001/10/11", "APPROVED", "Active", "Private", "", "\n
This function call is used to determine if the MPI/PD messages
should be fired. It will check the STOP MPI/PD MESSAGING (#16)
field in the CIRN SITE PARAMETER (#991.8) file.", "", "RGJUSITE", ""], ["3470", "DBIA3470", "Routine", "REGISTRATION", "2001/10/18", "APPROVED", "Active", "Private", "", "
Incomplete Records Tracking requests access to the
Patient Movement routine DGPMV. IRT Enter/Edit screen contains a Treating
Specialty Update protocol which calls CA^DGPMV. This protocol is the action to
update the Treating Specialty and Primary and Attending physicians for the IRT
package and ADT without exiting the IRT enter/edit option.", "", "DGPMV", ""], ["3471", "HLCSAC", "Routine", "HEALTH LEVEL SEVEN", "2001/10/19", "APPROVED", "Active", "Private", "", "", "", "HLCSAC", ""], ["3472", "TIU use of GMRCCP", "Routine", "CONSULT/REQUEST TRACKING", "2001/10/24", "APPROVED", "Active", "Private", "", "
This integration agreement describes calls used by TIU
in GMRCCP.", "", "GMRCCP", ""], ["3473", "TIU use of GMRCTIU", "Routine", "CONSULT/REQUEST TRACKING", "2001/10/26", "APPROVED", "Active", "Private", "", "
This integration agreement describes calls used by TIU
in GMRCTIU.", "", "GMRCTIU", ""], ["3475", "DBIA3475", "File", "REGISTRATION", "2001/11/05", "APPROVED", "Active", "Controlled Subscription", "2", "
The purpose of this DBIA is to allow Surgery to display
the patient's status related to environmental contaminants for patients having
ambulatory surgery.", "", "", ""], ["3476", "DIEZ UNCOMPILE INPUT TEMPLATES/DELETE COMPILED ROUTINES", "Routine", "1", "2001/11/05", "APPROVED", "Active", "Controlled Subscription", "", "
UNC^DIEZ is a silent VA FileMan call that allows the
deletion of compiled Input Templates and their associated compiled routines.
The entry point 'UNC' can accept two input parameters:\n
DIEZ = The IEN of the input template to uncompile. DIFLAGS = "D" indicates all
associated compiled routines are to be deleted.\n
The variable DIEZ is required; the variable DIFLAGS is optional.", "", "DIEZ", ""], ["3477", "TIU Uploads to SURGERY file", "File", "SURGERY", "2001/11/06", "APPROVED", "Active", "Private", "130", "
This DBIA documents references from TIU upload routines
to the SURGERY (#130), for upload of Surgeon's Dictation into the SURGERY
file.\n
Revision History:
- 11/12/24 Added Global Reference SRF(D0,"TIU"", "", "", "2024/11/12"], ["3478", "PSODRG", "Routine", "OUTPATIENT PHARMACY", "2001/11/15", "APPROVED", "Active", "Private", "", "
Allows CPRS to use EN^PSODRG to obtain information
regarding lab tests linked to clozapine medications.", "", "PSODRG", ""], ["3479", "RECORD TRACKING RTPSET1 FOR GUI REGISTRATION", "Routine", "RECORD TRACKING", "2003/04/21", "", "Retired", "Private", "", "
Registration needs to call RTPSET1 during the GUI
version of the Register a Patient functionality. Entry points SAVE and
restore will save RT namespaced variables into a temporary array and then
later restore them to their original values.", "", "RTPSET1", ""], ["3481", "SC 0% NON COMPENSABLE", "Routine", "REGISTRATION", "2001/11/23", "APPROVED", "Active", "Controlled Subscription", "", "
For the Long Term Care Copay initiative IB has a
requirement to determine if a patient is SC 0% non-compensable. Currently we
are calling $$SC^DGMTR(DFN) to make that determination.", "", "DGMTR", "2012/06/04"], ["3482", "DBIA3482", "File", "DRG GROUPER", "2001/11/26", "APPROVED", "Withdrawn", "Controlled Subscription", "80", "
Whenever the data in file 80 (ICD DIAGNOSIS) changes,
the subscribing packages need advance notification in case they need to
prepare a patch to their software product to be released simultaneously with
the ICD patch.", "", "", ""], ["3483", "DBIA3483", "File", "CPT/HCPCS CODES", "2001/11/26", "", "Withdrawn", "Controlled Subscription", "81", "
Whenever the data in file 81 (CPT) changes, the
subscribing packages need advance notification in case they need to prepare a
patch to their software product to be released simultaneously with the ICPT
patch.", "", "", ""], ["3484", "HL7 Capacity Management Phase I API", "Routine", "HEALTH LEVEL SEVEN", "2001/11/26", "APPROVED", "Active", "Supported", "", "
Returns Health Level 7 (HL7) activity totals for a
parameter-supplied time range. Additional control over the HL7 activity
included in the totals is available using passed parameters. (See HL*1.6*103
for additional information.)", "", "HLUCM", ""], ["3485", "DBIA3485", "File", "DRUG ACCOUNTABILITY", "2001/11/28", "APPROVED", "Active", "Private", "58.84", "\n
This is an open agreement between Drug Accountability and Controlled
Substances. The terms of this agreement are to allow Controlled Substances
access to the NAME (#.01) field in the DRUG ACCOUNTABILITY TRANSACTION TYPE
file (#58.84). The method of access can be either Direct Read/Write or by
using Filemanager.\n
The reason for this agreement is that prior to the release of Drug
Accountability 3.0, this file was the property of Controlled Substances.", "", "", ""], ["3486", "IAS FOR OMGCOAS1", "Routine", "CORBA SERVICES", "2004/02/05", "APPROVED", "Active", "Controlled Subscription", "", "
This API is invoked by the server code for Remote Data
Views to request Department of Defense patient data through Station 200 to the
FHIE Framework system. The DoD data is retrieved and placed in the common
CPRS Remote Data View format.", "", "OMGCOAS1", ""], ["3487", "HEALTH SUMMARY COMPONENT FILE #142.1", "File", "HEALTH SUMMARY", "2002/01/08", "APPROVED", "Active", "Supported", "142.1", "", "", "", ""], ["3488", "HL7 Capacity Management Phase II API", "Routine", "HEALTH LEVEL SEVEN", "2001/12/03", "APPROVED", "Active", "Supported", "", "
Returns Health Level 7 (HL7) activity totals for a
parameter-supplied time range. Additional control over the Hl7 activity
included in the totals is available using passed parameters. (See HL*1.6*103
for additional information.)\n
COMPARISON OF $$CM & $$CM2:
---------------------------
Patch HL*1.6*79 holds phase I software, and is associated with DBIA# 3484.
Phase I software is almost identical to phase II software, except in the
number of "messages" returned by the two APIs. The call point for\n
DBIA# 3484 - phase I software - is $$CM^HLUCM. The call point for this DBIA -
phase II software - is $$CM2^HLUCM.\n
$$CM^HLUCM returns the number of discrete message occurring during a
parameter-defined period of time. $$CM2^HLUCM returns the number of "message
units" during the same period of time. All other totals returned by both
parameters are identical.\n
A message is an individual message, such as an application acknowledgement. A
message unit is made up of all related messages.\n
The difference between a message (phase I, $$CM^HLUCM) and a message unit
(phase II, $$CM2^HLUCM) can be illustrated using the following sequence of
events.\n
* Baltimore sends a message to Washington. * Washington sends back a commit
acknowledgement to Baltimore. * Washington sends an application
acknowledgement to Washington. * Baltimore sends back to Washington a commit
acknowledgement
for the just sent application acknowledgement.\n
In the above example, $$CM^HLUCM would report a count of 4 messages.
$$CM2^HLUCM would report a count of 1 message, or "message unit." (Since all 4
messages are "related", they are combined into one reported "message.")", "", "HLUCM", ""], ["3489", "DBIA3489", "File", "REGISTRATION", "2001/12/04", "APPROVED", "Active", "Private", "13", "
A direct read is used to display the CODE (#3) field if
the zero node exists using $DATA on the zero node.", "", "", ""], ["3490", "DBIA3490", "File", "REGISTRATION", "2001/12/04", "", "Withdrawn", "Private", "43", "
Beneficiary Travel has retained full authority for the
"BT" node and its fields located and maintained in the MAS PARAMETERS (#43)
File. This includes development of the data dictionary (DD) for these fields,
as well as responsiblility for data entry into and data retriveval from these
fields.\n
This agreement is a "delegation of custody" of these fields from Resistration
to Beneficiary Travel. It provides Beneficiary Travel all rights and
privileges to development and distribution for all DD elements and data in
these fields. In addition, all DBIAs required for access to the DD and data
for these fields will be between any subscriber and Beneficiary Travel as the
custodian.", "", "", ""], ["3491", "DBIA3491", "File", "SCHEDULING", "2001/12/07", "APPROVED", "Active", "Private", "40.7", "", "", "", ""], ["3492", "NAME VAFCPID2", "Routine", "REGISTRATION", "2001/12/12", "APPROVED", "Active", "Private", "", "
Master Patient Index VistA application would like to
formalize the use of this API for standardization of the name as was done in
patch DG*5.3*149 for transmission of patient names to the MPI in the query
messages and for comparing existing names to MPI names. No updates to the
patient file name would occur during this process.", "", "VAFCPID2", ""], ["3493", "VAFCDD01", "Routine", "REGISTRATION", "2001/12/12", "APPROVED", "Active", "Private", "", "
Master Patient Index VistA would like to formalize the
DBIA with Registration for use of AVAFC and XMITFLAG entry points for
VAFCDD01.\n\n
AVAFC - is being used to create an A08 message when the data on the ICN has
been correlated but not updated on the site and then the site changes data but
the update is not transmitted to the other sites and the MPI.\n
XMITFLAG - is being used to set the REQUIRES TRANSMISSION field in the ADT/HL7
PIVOT file used in conjunction with the $$PIVNW^VAFHPIVT call to create a
Treating Facility update entry in the ADT/HL7 PIVOT file.", "", "VAFCDD01", ""], ["3494", "VAFHPIVT", "Routine", "REGISTRATION", "2001/12/12", "APPROVED", "Active", "Private", "", "
This function returns 0 node of the ADT/HL7 Pivot file
and ADT/HL7 Pivot file entry number, if no entry in the if no entry in pivot
file, create one and return #:0 node", "", "VAFHPIVT", ""], ["3495", "IAS FOR OMGPID01", "Routine", "CORBA SERVICES", "2001/12/13", "APPROVED", "Active", "Private", "", "
NEWGCPR^OMGPID01 is the API that the MPI code calls
when a new patient is added to the VA MPI. This API performs the
findOrRegisterIds interface to the Framework for patient correlation. It is
the reverse of the findCandidates interface.", "", "OMGPID01", ""], ["3496", "VAFC REMOTE PDAT", "Remote Procedure", "REGISTRATION", "2001/12/19", "APPROVED", "Active", "Controlled Subscription", "", "\n
MPI/PD developers request the use of the VAFC REMOTE PDAT remote
procedure call distributed in patch DG*5.3*414.\n
This remote procedure call returns the text Patient MPI/PD Data
Inquiry report to a remote site.\n
Usage:
I +LOC>0 D EN1^XWB2HL7(.RETURN,LOC,"VAFC REMOTE PDAT",1,ICN,"")", "VAFC REMOTE PDAT", "", ""], ["3497", "coreFLS/Pharmacy Interface", "Routine", "DRUG ACCOUNTABILITY", "2001/12/19", "APPROVED", "Active", "Controlled Subscription", "", "
Define the use of ^XTMP("PSAPUSH") in the
coreFLS/Pharmacy interface.", "", "CSLPHAR", ""], ["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", ""], ["3499", "DBIA3499", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2002/01/14", "APPROVED", "Active", "Supported", "", "
The purpose of this API is to facilitate the check for
a required means test for a veteran during appointment management. A
deficiency noted in the "Report of Task Force to Review Enrollment, Means
Testing and Income Verification", item #22, required VHA to identify a means
to acquire veterans' signatures on means tests at a local level. This API
provides a procedure that when called will check on a veteran means test
status and return a flag on whether a means test is required or not, and
optionally, a related text message that can be displayed by the calling
procedure. This API is provided in the Enrollment Application Systems
namespace.", "", "EASMTCHK", ""], ["3500", "PDM CONVERSION ACCESS", "File", "OUTPATIENT PHARMACY", "2002/01/16", "APPROVED", "Active", "Private", "52", "
Pharmacy Data Management (PDM) requests a one-time DBIA
with Outpatient Pharmacy to allow direct read access to the PRESCRIPTION file
(#52), to retrieve the LOGIN DATE field (#21). As part of the Pharmacy
Benefits Management project, PDM is processing through all Unit Dose, IV and
Outpatient Pharmacy orders/prescriptions to find the first Pharmacy service
date. In order to do this, PDM needs to be able to retrieve the login date
information for a prescription. This will be in a multi-package build titled
PSS PSJ PSO Service Date.", "", "", ""], ["3501", "DBIA3501", "File", "OUTPATIENT PHARMACY", "2002/01/17", "APPROVED", "Active", "Private", "52", "", "", "", ""], ["3502", "PHARMACY DATA MANAGEMENT", "File", "PHARMACY DATA MANAGEMENT", "2002/01/24", "APPROVED", "Active", "Private", "55", "", "", "", ""], ["3503", "PATIENT DATES OF LEAVE FOR A BILLING DATE RANGE", "Routine", "REGISTRATION", "2002/01/28", "APPROVED", "Active", "Private", "", "
Integrated Billing requires a list of the # of
leave/pass and ASIH days in a billing cycle period and the start and end dates
of each leave period used to compile this number.", "", "DGUTL2", ""], ["3504", "3504", "File", "REGISTRATION", "2002/01/30", "APPROVED", "Active", "Private", "2", "
The Pharmacy Benefits Management package extracts
patient demographic data monthly to support the VA National Formulary, disease
management issues and patient safety initiatives. The following read only
patient information is needed for the extract:", "", "", ""], ["3505", "Imaging Type File - READ ONLY", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2002/01/30", "APPROVED", "Active", "Controlled Subscription", "79.2", "
Radiology gives Imaging permission to read file 79.2,
IMAGING TYPE.", "", "", ""], ["3506", "Imaging (file 79)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2002/02/01", "APPROVED", "Active", "Controlled Subscription", "79", "
Radiology gives Imaging permission to read file 79,
RAD/NUC MED DIVISION.", "", "", ""], ["3507", "Imaging - RAUTL", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2002/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
Radiology gives Imaging permission to execute D^RAUTL.", "", "RAUTL", ""], ["3508", "Imaging - RAUTL11", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2002/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
Radiology gives Imaging permission to execute
SVTCOM^RAUTL11.", "", "RAUTL11", ""], ["3509", "Imaging - RAO7PC1A", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2002/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
Radiology gives Imaging permission to call
SETDATA^RAO7PC1A.", "", "RAO7PC1A", ""], ["3510", "Imaging - Complication Types", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2002/02/01", "APPROVED", "Active", "Controlled Subscription", "78.1", "
Radiology gives Imaging permission to read the
COMPLICATIONS TYPES file.", "", "", ""], ["3511", "DBIA3511", "File", "REGISTRATION", "2002/02/04", "APPROVED", "Active", "Private", "45", "
The Pharmacy Benefits Management package extracts
outpatient and inpatient visit data monthly to support the VA National
Formulary, disease management issues and patient safety initiatives. Patient
information is needed from cross references, as well as admission date and ICD
codes. These fields are included in the following references:", "", "", ""], ["3512", "DBIA3512", "File", "PCE PATIENT CARE ENCOUNTER", "2002/02/04", "APPROVED", "Active", "Controlled Subscription", "9000010", "
The Pharmacy Benefits Management package extracts
outpatient visit data monthly to support the VA National Formulary, disease
management issues and patient safety initiatives. The following references
are needed for extract.", "", "", ""], ["3513", "Imaging - RAORD5", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2002/02/05", "APPROVED", "Active", "Controlled Subscription", "", "
Radiology gives Imaging permission to call RAORD5.", "", "RAORD5", ""], ["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", ""], ["3519", "TIU EXTRACT SELECTED FIELDS BY CLASS", "Routine", "TEXT INTEGRATION UTILITIES", "2002/02/11", "APPROVED", "Active", "Controlled Subscription", "", "
Extraction of selected fields from TIU by Document
Class.", "", "TIULAFC", ""], ["3520", "%ZTSCH(TASK Global", "File", "KERNEL", "2002/02/12", "APPROVED", "Active", "Controlled Subscription", "", "\n
CLINICAL INFO RESOURCE NETWORK - Master Patient Index/Patient
Demographics (MPI/PD) will make our RGMTRUN utility routine
class I at all VA facilities. We will create a remote query tool
on the Master Patient Index (MPI) to query a site for the currently
running task information.\n
The following code in RGMTRUN examines the currently running tasks in
the SCHEDULE file. For each task found, it examines the ROUTINE field.
If the ROUTINE field contains "HL" (Health Level Seven), then for
that task, EN^XUTMTP(TASK) is called to display the task information.\n
S TASK=0 F S TASK=$O(^%ZTSCH("TASK",TASK)) Q:'TASK Q:QFLG D
.S ROU=$P(^%ZTSCH("TASK",TASK),"^",2)
.I ROU["HL" D EN^XUTMTP(TASK)\n
This IA is for direct global read of the ^%ZTSCH("TASK",TASK)
node of the SCHEDULE file and for direct global read, $P(^%ZTSCH(
"TASK",TASK),"^",2) for pieces 2 and 4, ROUTINE and OPTION NAME.", "", "", ""], ["3521", "XUTMTP Routine", "Routine", "KERNEL", "2002/02/12", "APPROVED", "Active", "Controlled Subscription", "", "\n
CLINICAL INFO RESOURCE NETWORK - Master Patient Index/Patient
Demographics (MPI/PD) will make our RGMTRUN utility routine
class I at all VA facilities. We will create a remote query tool
on the Master Patient Index (MPI) to query a site for the currently
running task information.\n
The following code in RGMTRUN examines the currently running tasks in
the SCHEDULE file. For each task found, it examines the ROUTINE field.
If the ROUTINE field contains "HL" (Health Level Seven), then for
that task, EN^XUTMTP(TASK) is called to display the task information.\n
S TASK=0 F S TASK=$O(^%ZTSCH("TASK",TASK)) Q:'TASK Q:QFLG D
.S ROU=$P(^%ZTSCH("TASK",TASK),"^",2)
.I ROU["HL" D EN^XUTMTP(TASK)\n
This IA allows MPI/PD to call the EN entry point in routine XUTMTP.", "", "XUTMTP", ""], ["3522", "$$OS EXTRINSIC FUNCTION IN ROUTINE %ZOSV", "Routine", "KERNEL", "2002/02/12", "APPROVED", "Active", "Supported", "", "
The $$OS^%ZOSV() extrinsic function is only available
under Cache'/OpenM systems. This function returns the underlying operating
system such as VMS, UNIX or NT.", "", "%ZOSV", ""], ["3523", "DBIA3523", "Routine", "REGISTRATION", "2002/02/20", "APPROVED", "Active", "Supported", "", "", "", "DGMTU", ""], ["3524", "XDRDFPD", "Routine", "TOOLKIT", "2002/02/14", "APPROVED", "Active", "Private", "", "
This integration agreement is for access from the top
of the routine XDRDFPD. Entry at this location will result in the user being
prompted for a specific file to check for duplicate entries, then prompted for
a specific entry within that file. To proceed there must be an entry for the
selected file in the DUPLICATE RESOLUTION file (#15.1). The routine then
checks other entries within the specified file to determine whether they are
potential duplicates based upon the information and routines specified in the
DUPLICATE TESTS sub-file (field #1100) for the specified file.\n
Entries which are identified as potential duplicates are entered into the
DUPLICATE RECORD file (#15).", "", "XDRDFPD", ""], ["3525", "EN XDRDFPD", "Routine", "TOOLKIT", "2002/02/14", "APPROVED", "Active", "Private", "", "
This entry point provides the ability to perform a
search on a specified file for potential duplicates to a specified file entry,
using user specified criteria in the DUPLICATE RESOLUTIION file (#15.1). The
routine creates entries in the DUPLICATE RECORD file (#15) of potential
duplicates identified for subsequent verification.\n
The users must create an entry in the DUPLICATE RESOLUTION file for the file
that will be analyzed. This entry must include data in the CANDIDATE
COLLECTION ROUTINE field (#.09) which will specify the routine to be used as
the basis for identifying those that might be potential duplicates. These
candidates are then compared using the data and routines specified in the
DUPLICATE TESTS sub-file (field #1100) for the analyis. The weighted result
from these tests is then compared to the POTENTIAL DUPLICATE THRESHOLD% value
to determine if an entry should be considered a potential duplicate and
entered into the DUPLICATE RECORD file.", "", "XDRDFPD", ""], ["3526", "SETUP XDRDFPD", "Routine", "TOOLKIT", "2002/02/14", "APPROVED", "Active", "Private", "", "
Master Patient Index Austin is utilizing the Duplicate
Record Merge software from within Kernel Toolkit to search for patients
already existing in the index.", "", "XDRDFPD", ""], ["3527", "CHECK XDRDMAIN", "Routine", "TOOLKIT", "2002/02/14", "APPROVED", "Active", "Private", "", "
Master Patient Index Austin is utilizing the Duplicate
Record Merge software from within Kernel Toolkit to search for patients
already existing in the index.", "", "XDRDMAIN", ""], ["3528", "FILE XDRDQUE", "Routine", "TOOLKIT", "2002/02/14", "APPROVED", "Active", "Private", "", "
Master Patient Index Austin is utilizing the Duplicate
Record Merge software from within Kernel Toolkit to search for patients
already existing in the index.", "", "XDRDQUE", ""], ["3529", "DBIA3529", "File", "REGISTRATION", "2002/02/15", "APPROVED", "Active", "Controlled Subscription", "21", "
Beneficiary Travel uses a direct read on the zero node
of the PERIOD OF SERVICE (#21) File.", "", "", ""], ["3530", "DBIA3530", "File", "PCE PATIENT CARE ENCOUNTER", "2002/02/27", "APPROVED", "Active", "Controlled Subscription", "9000010", "
Integrated Billing receives encounters from PCE but
screens out many based on certain criteria. One of these criteria is the Data
Source of the encounter. The following reference is needed to identify the
Data Source of an encounter to determine if the encounter should pass to
Integrated Billing.", "", "", ""], ["3531", "DBIA3531", "File", "PCE PATIENT CARE ENCOUNTER", "2002/02/27", "APPROVED", "Active", "Controlled Subscription", "839.7", "
Integrated Billing receives encounters from PCE but
screens out some based on the Data Source of the encounter. The following
reference is needed to identify the Data Source of an Encounter to determine
if the encounter is billable.", "", "", ""], ["3532", "Imaging DIBT read", "File", "1", "2002/02/27", "APPROVED", "Active", "Controlled Subscription", ".401", "
FileMan gives Imaging permission to read the DIBT
global. The Fileman team reserves the right to make changes allowing Imaging
developers 3 to 6 months notice prior modifications. This request is to read
the search criteria stored in the DIBT global. A call to EN^DIS is initiated
to start the FileMan search logic dialog. Imaging understands that the nodes
read from the DIBT global are not documented and may change.", "", "", ""], ["3533", "Calls to Routine SROESTV", "Routine", "SURGERY", "2002/02/28", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to the routine SROESTV.", "", "SROESTV", ""], ["3534", "Setting DD fields in post-init routine", "File", "1", "2002/02/28", "APPROVED", "Active", "Private", "", "
An integration agreement is needed for Registration to
set ^DD nodes for several PATIENT (#2) file fields in the post initialization
routine DG53244R for patch DG*5.3*244, Patient Name Standardization. The
INPUT TRANSFORM (#.5), 'HELP'-PROMPT (#3) and DESCRIPTION (#21) fields for the
following PATIENT (#2) file fields and subfields is updated by DG*5.3*244.\n
DG*5.3*620 will also set ^DD nodes for the following fields in its post
initialization routine DG53620D. This patch will switch the API called from
the ^DD, $$FORMAT^DPTNAME, to its equivalent in Kernel, $$FORMAT^XLFNAME7.
Thus the Input transform referred to in patch DG244 is not longer valid.\n
NAME (#.01)
K-NAME OF PRIMARY NOK (#.211)
K2-NAME OF SECONDARY NOK (#.2191)
FATHER'S NAME (#.2401)
MOTHER'S NAME (#.2402)
MOTHER'S MAIDEN NAME (#.2403)
E-NAME (#.331)
E2-NAME OF SECONDARY CONTACT (#.3311)
D-NAME OF DESIGNEE (#.341)\n
Subfields:\n
NAME (#.01) field in the ALIAS (#2.01) multiple
ATTORNEY'S NAME (#30) field in the DISPOSITION LOG-IN DATE/TIME
(#2.101) multiple\n
Also, the SET and KILL logic will be updated for the name field.", "", "", ""], ["3535", "TIUSRVP Calls", "Routine", "TEXT INTEGRATION UTILITIES", "2002/03/01", "APPROVED", "Active", "Controlled Subscription", "", "
Entry points in this routine provide mechanisms for
creating, updating, deleting and addending TIU records. Note that users are
asked to call MAKEADD^TIUSRVP2 and SIGN^TIUSRVP2 when editing or writing new
code. This is effective when TIU*1*184 is released. See IA 4795.", "", "TIUSRVP", ""], ["3536", "TIU GET DOCUMENTS FOR REQUEST", "Routine", "TEXT INTEGRATION UTILITIES", "2002/03/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "TIUSRVLR", ""], ["3537", "TIUSROI Calls", "Routine", "TEXT INTEGRATION UTILITIES", "2002/03/01", "APPROVED", "Active", "Controlled Subscription", "", "
This IA documents calls in the routine TIUSROI.", "", "TIUSROI", ""], ["3538", "DBIA3538", "File", "REGISTRATION", "2002/03/05", "APPROVED", "Active", "Private", "43.1", "
Beneficiary Travel needs access to add DATE (#.01)
field entries in the MAS EVENT RATES (#43.1) file. Entry is done using a
Fileman call.\n
-------------------------------\n
Beneficiary Travel will retain full authority for the "BT" node and its fields
located in the MAS EVENT RATES (#43.1) File. This includes development of the
data dictionary (DD) for these fields, as well as responsibility for the data
entry into and data retriveval from these fields.\n
This agreement is a "delegation of custody" of these fields from Registration
to Beneficiary Travel. It provides Beneficiary Travel all rights and
privileges to development and distribution for all DD elements and data in
these fields. In addition, all DBIAs required for access to the DD and data
for these fields will be between any subscriber and Beneficiary Travel as the
custodian.", "", "", ""], ["3539", "Digital Signature Storage", "Routine", "KERNEL", "2002/04/22", "APPROVED", "Active", "Controlled Subscription", "", "
This IA is for a set of API's to facilitate the use of
PKI Digital Signatures in VistA applications.", "", "XUSSPKI", ""], ["3540", "TIUSRVP, Entry Point: FILE", "Routine", "TEXT INTEGRATION UTILITIES", "2002/03/06", "APPROVED", "Active", "Controlled Subscription", "", "
This IA documents the call to FILE^TIUSRVP.", "", "TIUSRVP", ""], ["3541", "GET OPTOP", "Routine", "SURGERY", "2002/03/07", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents the call to SROSRPT to return optop
information on a surgical case.", "", "SROSRPT", ""], ["3542", "GET OPTOP FOR NON-OR PROCEDURE", "Routine", "SURGERY", "2002/03/07", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents the call to SRONP to return optop
information on a non-OR procedure.", "", "SRONP", ""], ["3544", "IMAGING - NEW PERSON FILE", "File", "KERNEL", "2002/03/12", "APPROVED", "Active", "Controlled Subscription", "200", "
Kernel gives Imaging permission to read the Radiology
Classification in the New Person file.", "", "", "2002/03/12"], ["3545", "DBIA3545", "File", "REGISTRATION", "2002/03/13", "APPROVED", "Active", "Private", "45", "
The Clinical Case Registries system needs access to the
'AAD' x-ref (admission date) and for field #80 (principle diagnosis).", "", "", ""], ["3546", "File 40.8 access", "File", "REGISTRATION", "2002/03/14", "", "Retired", "Controlled Subscription", "40.8", "
The Patient Representative package would like access to
the "AD" cross-reference of the MEDICAL CENTER DIVISION file (#40.8), a
cross-reference on the Institution File Pointer field (#.07). Patient Rep will
use this cross-reference to screen choices for it's Division field.", "", "", ""], ["3547", "File TYPE OF VISIT(#357.69) read access by CPT code", "File", "AUTOMATED INFO COLLECTION SYS", "2002/03/20", "APPROVED", "Active", "Private", "357.69", "
Patient Care Encounter will use $D(^IBE(357.69,D0)) to
verify if a CPT code in the V CPT(#9000010.18) file exists in the Type of
Visit(#357.69) file. If the CPT code is found in this file, the QUANTITY(#.16)
field in the V CPT file will be set to 1.\n\n", "", "", ""], ["3548", "TIUCL1, Entry Point: DOCCLASS", "Routine", "TEXT INTEGRATION UTILITIES", "2002/03/25", "APPROVED", "Active", "Controlled Subscription", "", "", "", "TIULC1", ""], ["3549", "VAFC HFS SCRATCH", "Other", "REGISTRATION", "2002/04/01", "APPROVED", "Active", "Private", "", "\n
The MPI/PD Data Quality Management team, working on the Master
Patient Index (MPI) at Austin, needs access to facility information
to improve data quality and resolve differences on the MPI.
Functionality was provided in DG*5.3*414, released Jan 03, 2002,
to enable them to remotely retrieve facility data through remote
procedure calls (RPCs). This was done by establishing the "VAFC
HFS SCRATCH" entry in the PARAMETER DEFINITION (#8989.51) file
in DG*5.3*414.\n
CLINICAL INFO RESOURCE NETWORK routines would like to use the
"VAFC HFS SCRATCH" entry in the PARAMETER DEFINITION (#8989.51)
file to access, open, use, and close the HFS directory for RPCs.\n
Master Patient Index/Patient Demographics (MPI/PD) is requesting
an IA with Registration to reference the "VAFC HFS SCRATCH" entry
in routine RGMTHFS.", "", "VAFCHFS", ""], ["3550", "HLCS(870,'C'", "File", "HEALTH LEVEL SEVEN", "2002/08/22", "APPROVED", "Active", "Private", "870", "
This general purpose integration agreement exists for
packages needing to access the "C" cross-reference in the HL Logical Link file
(#870).\n
All packages that desire to be subscribers to this integration agreement must
submit the details for their use of the "C" cross-reference to the VistA HL7
package developers for approval. The cross-reference access details will be
included in the individual subscriber section of this agreement.", "", "", ""], ["3551", "DBIA3551", "File", "ORDER ENTRY/RESULTS REPORTING", "2002/04/04", "APPROVED", "Active", "Private", "101.43", "
With the development of the Med Order Button for BCMA
version 2.0, BCMA requires the ability to perform direct global reads on the
following fields;\n\n
^ORD(101.43,D0,.1)= (#.1) INACTIVATED [1D] Used to validate that the scanned
medication is still active for use as a medication.\n\n
^ORD(101.43,D0,0)= (#.01) NAME [1F] Used to display the medication name back
to the user when they scan a medication.\n
^ORD(101.43,D0,PS)= (#50.1) INPATIENT MED [1S] ^ (#50.2) OUTPATIENT MED [2S]
==>^ (#50.3) IV BASE [3S] ^ (#50.4) IV ADDITIVE [4S] ^
==>(#50.5) SUPPLY [5S] ^ (#50.6) NON-FORMULARY [6S] ^ Used to
determine that the medication scanned is marked for Inpatient Med and if the
med is an IV base or additive.\n
"ID" cross-reference file to determine if the drug scanned is not in the CPRS
orderable item file.\n", "", "", ""], ["3552", "$$PARAM EXTRINSIC FUNCTION IN ROUTINE HLCS2", "Routine", "HEALTH LEVEL SEVEN", "2002/04/04", "APPROVED", "Active", "Controlled Subscription", "", "
The $$PARAM^HLCS2 API is used extensively by the Health
Level 7 (HL7) package. This API returns a string of text, delimited by the
up-arrow, holding critical environment information. This API is being made
available to the VistA community on a controlled subscription basis.", "", "HLCS2", ""], ["3553", "SET TEST SYSTEM PATIENT ICN", "Routine", "MASTER PATIENT INDEX VISTA", "2002/04/04", "APPROVED", "Active", "Private", "", "", "", "MPIF001", ""], ["3554", "DBIA3554", "Routine", "CLINICAL INFO RESOURCE NETWORK", "2002/04/08", "APPROVED", "Active", "Private", "", "
MPI requries the use of the GETEX^RGEX03 API for a
remote procedure call to the VA sites from the MPI Austin. This is to
retrieve exception data from the treating facilities for data quality
management.", "", "RGEX03", ""], ["3555", "Enter/edit Austin Entry", "File", "KERNEL", "2002/04/09", "APPROVED", "Active", "Private", "4", "
The HL7 package has an agreement to use a FileMan
FILE^DICN call to edit the following fields in the INSTITUTION (#4) file.
NAME (#.01), STATE (#.02), STATUS (#11), FACILITY TYPE (#13), STATION NUMBER
(#99) and OFFICAL VA NAME (#100).\n
This is done in pre-install routine, PRE^HLP92, to create the AUSTIN entry in
the INSTITUTION file if it is not present. This functionality is in support
of the Federal Heath Information Exchange (FHIE).\n
The entry created will have the following values. NAME: AUSTIN STATE: TEXAS
STATUS: National FACILITY TYPE: DPC STATION NUMBER: 200 OFFICAL VA NAME:
AUSTIN GLOBAL REFERENCE:
^DIC(4,D0,0)
.01 NAME 0;1 Write w/Fileman
.02 STATE 0;2 Write w/Fileman
11 STATUS 0;11 Write w/Fileman GLOBAL REFERENCE:
^DIC(4,D0,3)
13 FACILITY TYPE 3;1 Write w/Fileman GLOBAL REFERENCE:
^DIC(4,D0,99)
99 STATION NUMBER 99;1 Write w/Fileman
100 OFFICIAL VA NAME 99;3 Write w/Fileman", "", "", ""], ["3556", "GET LAB RESULTS", "Routine", "AUTOMATED LAB INSTRUMENTS", "2002/04/11", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Registries system requires access to the API
GCPR^LA7QRY to analyze lab tests and results. This API is required during the
registry update process and the data extract process.", "", "LA7QRY", "2010/07/14"], ["3557", "DBIA3557", "File", "LAB SERVICE", "2002/04/11", "APPROVED", "Active", "Private", "69.9", "
The Clinical Registries system requires access to field
#95.3 of file #69.9 (this field indicates if the Loinc historical mapper has
been run) and field #.01 of file #95.3 (to check if the Loinc code exists and
if so get it's value and control digit).", "", "", ""], ["3558", "Process orders after Surgery", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2002/04/12", "APPROVED", "Active", "Private", "", "
This agreement allows the Surgery package to call
routine ORMEVNT1 when a patient has a surgical procedure, for the purpose of
automatically discontinuing and/or releasing orders.", "", "ORMEVNT1", ""], ["3559", "Read access to Surgery file", "File", "SURGERY", "2002/04/12", "APPROVED", "Active", "Private", "130", "
This agreement allows CPRS to look at specific fields
in the Surgery file to be able to properly manage orders when the patient
leaves the OR.", "", "", ""], ["3560", "DBIA3560", "File", "PCE PATIENT CARE ENCOUNTER", "2002/04/15", "APPROVED", "Active", "Private", "9000010.18", "", "", "", ""], ["3561", "M XML PARSER", "Routine", "TOOLKIT", "2003/07/03", "APPROVED", "Active", "Supported", "", "
This utility provides a M based XML version 1.0 parser.\n
It supports both the SAX interface and the DOM interface.", "", "MXMLDOM", ""], ["3562", "Calls to Routine SROTIUD", "Routine", "SURGERY", "2002/04/16", "APPROVED", "Active", "Private", "", "
This DBIA documents calls to the routine SROTIUD.", "", "SROTIUD", ""], ["3563", "RAO7PC4", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2002/04/17", "APPROVED", "Active", "Private", "", "
Allows CPRS to use EN1^RAO7PC4 and SET1^RAO7PC4 to
obtain and display infomation for alert follow-up actions.", "", "RAO7PC4", ""], ["3564", "DBIA3564", "Routine", "BAR CODE MED ADMIN", "2002/04/25", "APPROVED", "Active", "Controlled Subscription", "", "
The entry point EN^PSBAPIPM is provided by the Bar Code
Medication Administration (BCMA) package to provide information to Inpatient
Medications to be used in determining the start date for a renewed order.\n
The MOB entry point is used by Inpatient Medications to get information
obtained from the BCMA/CPRS Med Order function.\n
The MOBR is used by Inpatient Medications to notify BCMA that the order
has been accepted and processed by Inpatient Pharmacy.", "", "PSBAPIPM", "2010/11/03"], ["3565", "LR7O ALL EVSEND RESULTS", "Other", "LAB SERVICE", "2002/05/07", "APPROVED", "Active", "Controlled Subscription", "", "
This event protocol is invoked by the lab package when
lab results have been verified by a lab technician. Packages can hang their
own protocols off this event to carry out various actions when lab results are
verified, by editing this protocol in the PROTOCOL file (#101).\n
At the time the event is triggered the variable OREMSG holds the pointer to
the array containing the HL7 message created by Lab. Currently, this hold the
value of ^TMP("LRCH",$J). Looking in this global will give all the
order/result information in HL7 format. For example:\n
^TMP("LRCH",2176,1)=MSH|^~\\&|LABORATORY|5000|||ORM
2)=PID||16|16;DPT(|HOOD,ROBIN
3)=PV1|I|14||||||||
4)=ORC|RE|7090879^OR|17;3020507;1;CH;6979491.865777^LRCH||CM|
|^ ^^20020507134223-0600^20020507134246-0600|20020507134223-0600
|5^MALMROSE,CARY|14^ANDERSON,DOCTOR||20020507134223-0600|
7)=OBR|1||81744.0000^Lithium^99NLT^198^LITHIUM^99LRT||2002050
7134223-0600||1||20020507134240-0600|0X500;SERUM;SNM;1;BLOOD ;99LRS^^^72;SER
UM;99LRX|||CH 0507 1||20020507134246-0600||F|^^^^^R;9|14
8)=OBX|1|ST|81744.0000^Lithium^99NLT^198^LITHIUM^99LRT||3|
mEq/L |.5-1.5|HH||F|||5^MALMROSE,CARY\n", "", "", ""], ["3566", "Imaging - TIUSRVPL", "Routine", "TEXT INTEGRATION UTILITIES", "2002/04/25", "APPROVED", "Active", "Controlled Subscription", "", "
Execution at GETILST is called to retrieve a list of
associated images for a document entry in TIU. Execution at PUTIMAGE is
called to store an image pointer in file 8925.91, creating an
Image-To-Document link. Execution at DELIMAGE is called to delete an image
pointer in a TIU document. Execution at GETDLST is called to get a list of
associated TIU documents for a given image entry.", "", "TIUSRVPL", ""], ["3567", "Imaging - MAGGSIUI", "Routine", "IMAGING", "2002/04/26", "APPROVED", "Active", "Controlled Subscription", "", "
Imaging v3.0 patch MAG*3.0*7 introduces an Image Import
API that can be used to automatically import image files into VistA Imaging.
The image files can be from a medical device (instrument) or a network or
local drive. Once image files are imported, they are available for display
from the VistA Imaging Clinical Display application.\n
Importing image/report files is a two step process:\n
Step 1: The calling program initiates the import proces by sending an input
array to the Import API. The import API uses the input array to create an
entry in the Import Queue file and returns a status array to the calling
program.\n
Step 2: After the entries in the Import Queue file are processed (by the
Background Processor residing on the network), the Import API reports back to
the calling program in a result array.\n
Note: The Import API, as part of the VistA Imaging software, is regulated as
a medical device. The Import API cannot be used without a written agreement
between the VistA Imaging SD&D group and the party wishing to use the Import
API.\n\n
To secure an agreement for the use of the Import API, the following criteria
must be met:\n\n
1) Any products built or interfaced using the VistA Imaging Import API
must be tested with VistA Imaging. Testing will be performed by the VistA
Imaging team with assistance from field sites and the calling package. This
testing must demonstrate that there are no adverse interactions affecting the
safety, efficacy or performance of the VistA Imaging software or the devices
interfaced to VistA Imaging.\n
2) Any changes to packages/product(s) using the VistA Imaging Import API
must be reported to the VistA Imaging Project Office for review and testing
before release. Retesting of VistA Imaging with the product(s) is required
with any change.\n
3) Documentation that imported reports/objects meet VHA, regulatory, and
quality requirements must be on file with the Vista Imaging Project Office
prior to any clinical use. Sample imported reports/objects shall be provided
initially to the VistA Imaging Project Office by the package using the API.
Sites installing the VistA Imaging API must comply with all VistA Imaging
requirements and are responsible for filing all required documentation with
the VistA Imaging Project Office, including image quality and data forms and
sample reports/objects from any interfaced device.\n
4) Additional requirements may apply to non-VA software using the Import
API.", "", "MAGGSIUI", ""], ["3568", "DBIA3568", "Routine", "TEXT INTEGRATION UTILITIES", "2003/08/07", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Procedures API(s)", "", "TIUCP", ""], ["3569", "REQUEST TO ACCESS THE 'NAME' NODE OF XMB", "File", "MAILMAN", "2002/04/26", "", "Withdrawn", "Private", "", "
IB needs to determine Production or Test account and
would like to use ^XMB("NAME") and ^XMB("NETNAME") to compare with each other
and to determine if the first "." piece of this value indicates we're in the
test account. We're looking for TEST, MIRROR, TRAIN, MIR, etc. in the node
name.", "", "", ""], ["3570", "WHO IS THE CODER OF PCE", "File", "SCHEDULING", "2002/04/26", "", "Withdrawn", "Private", "409.68", "
IB would like to determine the name of the coder for
outpatient encounters/claims. We shall determine this by the person who most
recently edited the outpatient encounter file.", "", "", ""], ["3571", "SENDING THE DIVISION ID TO CLAIMSMANAGER", "File", "REGISTRATION", "2002/04/26", "", "Withdrawn", "Private", "40.8", "
IB would like to be able to send the division
identifier to ClaimsManager which is a COTS claims scrubbing tool. The
division ID will allow ClaimsManager to separate claims by their
'organization' id field and will allow for reports to be able to be broken out
by VistA division.", "", "", ""], ["3572", "ORWORB FASTUSER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2004/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
The Mental Health Assistant GUI (part of the Mental
Health package) would like an agreement to use the ORWORB FAST USER remote
procedure.", "ORWORB FASTUSER", "", ""], ["3573", "Get Institution from file 870", "File", "HEALTH LEVEL SEVEN", "2002/05/09", "", "Retired", "Controlled Subscription", "870", "
MPIF application needs to be able to get the
institutions for the logical links returned in GET^HLSUB(sub,0,"",.array)\n
The following is the actual code that will be used to get the institutions:\n
.S INST=$$GET1^DIQ(870,+$P(ARRAY("LINKS",SUBNUM),"^",6)_",",.02,"E")\n
IA retired. See IA 3335 for current documentation.", "", "", ""], ["3574", "HL7 LINK MANAGER", "Routine", "HEALTH LEVEL SEVEN", "2002/05/13", "APPROVED", "Active", "Controlled Subscription", "", "
This routine manages various activities of the HL7 Link
Manager.", "", "HLCSLM", ""], ["3575", "TIU use of GMRCTIU1", "Routine", "CONSULT/REQUEST TRACKING", "2002/05/13", "APPROVED", "Active", "Private", "", "
This integration agreement describes calls used by TIU
in GMRCTIU1.", "", "GMRCTIU1", ""], ["3576", "TIU use of GMRCTIU", "Routine", "CONSULT/REQUEST TRACKING", "2002/05/13", "", "Retired", "Private", "", "
This integration agreement describes calls used by TIU
in GMRCTIU.", "", "GMRCTIU", ""], ["3577", "DBIA-3577", "Routine", "HEALTH SUMMARY", "2002/05/14", "", "Withdrawn", "Private", "", "", "", "GMTSDVR", ""], ["3578", "DBIA3578", "Routine", "HEALTH SUMMARY", "2002/05/15", "APPROVED", "Active", "Private", "", "
1) OPTION GMTS TYPE ENTER/EDIT will allow the CAC to
Create and/or modified a Health Summary Report from the TIU HS Object Menu", "", "GMTSRM", ""], ["3579", "DBIA3579", "Routine", "HEALTH SUMMARY", "2002/05/15", "APPROVED", "Active", "Private", "", "\n\n", "", "GMTSRI", ""], ["3580", "TIU use of Global AUPNVSIT(+VSIT,0)", "File", "PCE PATIENT CARE ENCOUNTER", "2002/05/15", "APPROVED", "Active", "Private", "9000010", "
Direct global read of the 0th node of the Visit file
(#9000010), $G(^AUPNVSIT(+VSIT,0)).", "", "", ""], ["3581", "DIQ FOR DATE ENTERED INTO FILE AND ALIAS", "File", "REGISTRATION", "2002/05/16", "APPROVED", "Active", "Private", "2", "
Master Patient Index VistA wil use GETS^DIQ to retreive
the DATE ENTERED INTO FILE (#.097) and ALIAS (#1) fields from the PATIENT (#2)
file, to be stored in an array and returned in a remote RPC call.", "", "", ""], ["3582", "INPATIENT CLEANUP", "File", "ORDER ENTRY/RESULTS REPORTING", "2002/05/20", "APPROVED", "Active", "Private", "100", "", "", "", ""], ["3583", "ORBCMA5 GETUDID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/05/21", "APPROVED", "Active", "Private", "", "
Get Unit/Dose Order Dialog Form ID for BCMA V2.0 RPC:
GETUDID^ORBCMA5", "ORBCMA5 GETUDID", "", ""], ["3584", "ORBCMA5 GETIVID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/05/21", "APPROVED", "Active", "Private", "", "
Get IV Order Dialog Form ID for BCMA V2.0 RPC:
GETIVID^ORBCMA5", "ORBCMA5 GETIVID", "", ""], ["3585", "ORWUBCMA USERINFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/05/21", "APPROVED", "Active", "Private", "", "
Get the relevant information of current user for BCMA
V2.0 RPC: USERINFO^ORWUBCMA", "ORWUBCMA USERINFO", "", ""], ["3586", "New Style Xref and Fileman Variables", "Other", "1", "2002/05/22", "APPROVED", "Active", "Private", "", "
The HUI Project is using a new style cross-reference,
type Action and is executed at the Record level. In the routine XUHUI the
following Fileman array/variables are being read:\n
DIFILE() to get the file and sub-file numbers and pass them on in a name
spaced variable XUHUIFIL().\n
DIFLD() to get the field(s) and pass them on in a name spaced variable
XUHUIFLD().\n
DA() to get the IEN(s) and pass them on in a name spaced variable XUHUIDA().\n
The being used is as follows:\n
ZL XUHUI ZP S2:S2+6 S2 ;Section 2
N XUHUIFIL,XUHUIFLD,XUHUIDA,XUHUIX,XUHUIX1,XUHUIX2
S XUHUIFIL=DIFILE ;File #
I $D(DIFLD) M XUHUIFLD=DIFLD ;Field #
I '$D(DIFLD) S XUHUIFLD=""
S XUHUIXR=$G(XUHUIXR)
M XUHUIDA=DA ;IEN(s) of record\n
It is realized some of these variables may be undefined or null and that
Fileman reserves the right to changed the variables. It is with this intent
that it would be nice if a notice was given to the XUHUI* developer that these
are being changed so that patch coordination can happen.", "", "", ""], ["3587", "SPOOLED HEALTH SUMMARY DOCUMENT", "File", "KERNEL", "2002/05/23", "APPROVED", "Active", "Controlled Subscription", "3.51", "
Health Summary uses Mailman to track spooled documents
for transmission.", "", "", ""], ["3588", "HEALTH SUMMARY SPOOLED DATA", "File", "KERNEL", "2002/05/23", "APPROVED", "Active", "Private", "3.519", "", "", "", ""], ["3589", "Tasking An Event From a New Style Xref", "Routine", "KERNEL", "2002/05/24", "APPROVED", "Active", "Supported", "", "
This support API allows other packages to task an
Option(s) or Protocol(s) from a New Style cross-reference.\n
For more details on usage please see:
http://vista.url/kernel/apis/OPKG^XUHUI.htm", "", "XUHUI", ""], ["3590", "HEALTH SUMMARY SURGICAL EXTRACT", "Routine", "SURGERY", "2002/05/29", "APPROVED", "Active", "Private", "", "", "", "SROGMTS", ""], ["3591", "Install 'AXUHUI' and 'AXUHUIKEY' Xrefs", "File", "1", "2002/05/29", "APPROVED", "Active", "Private", ".11", "
Patch XU*8*236 needs to install/tranport two New Style
xrefs: 'AXUHUI' and 'AXUHUIKEY' without sending the necessary field DDs too.
This request is for a one time IA.", "", "XUHUI236", ""], ["3592", "DBIA3592", "File", "1", "2003/06/10", "", "Retired", "Private", "20", "
Clean up routines, as part of the Patient Name
Standardization (DG*5.3*244) patch, will need to be run at 8-10 test sites.
This clean up will correct the name standardization performed in previous test
versions of the patch. This is a one time only clean up.\n
In addition to correcting the standardization of patient names, the clean up
routines will need to populate the SOURCE NAME FORMAT FLAGS (#7) field of the
NAME COMPONENTS (#20) file for every component entry not having a value.\n
In this agreement we are requesting access to add a flag value to the SOURCE
NAME FORMAT FLAGS (#7) field of the NAME COMPONENTS (#20) file. And, in order
to prevent the ANAME cross reference from being executed we are requesting the
ability to set XUNOTRIG=1 before making the DIE^FILE call to add a value to
the field.", "", "", ""], ["3593", "DBIA3593", "Routine", "REGISTRATION", "2002/06/03", "APPROVED", "Active", "Supported", "", "
Allow access to the Patient Lookup components for
checking Means Test Requirements and the Cleveland Alert.", "", "DPTLK6", ""], ["3594", "BROWSER SWITCHING", "Routine", "1", "2002/06/03", "APPROVED", "Active", "Private", "", "
The purpose of this DBIA is to provide a temporary
method for switching between 'documents' without the user having to mentally
resolve pointers between records in two different files. The needed
functionality is currently planned by the VA Fileman developers to released in
a patch. When that patch is released, the HL7 developers will modify the
Transmission Log code to use the released functionality.\n
See IA# 2540. (This is a continuation of IA# 2540, and is used to cover
references to the PSR subroutine tag in routine DDBR0.)", "", "DDBR0", ""], ["3595", "INSURANCE PLAN TYPE", "File", "INTEGRATED BILLING", "2002/06/11", "APPROVED", "Active", "Controlled Subscription", "355.1", "", "", "", "2012/07/10"], ["3596", "INSURANCE COMPANY NAME", "File", "INTEGRATED BILLING", "2002/06/11", "", "Pending", "Controlled Subscription", "36", "", "", "", ""], ["3597", "DIA(985", "File", "1", "2002/06/12", "APPROVED", "Active", "Private", "1.1", "
The MPI Austin software is running an audit purge to
clean up the ^DIA(985 entries for a time range. The FileMan audit purge ran
too slow and was not cleaning up completely each of the entries in the purge
date range. So MPI Austin wrote its own purge for the ^DIA(985, entries.\n
The MPI Austin software is therefore, requesting a DBIA to have direct global
read and kill of ^DIA(985, ^DIA(985,"C" and direct global kill of ^DIA(985,"D"
and ^DIA(985,"B".", "", "", ""], ["3598", "DBIA 3598", "Routine", "INPATIENT MEDICATIONS", "2002/06/12", "APPROVED", "Active", "Private", "", "
The purpose of this API is to allow Computer Patient
Record System (CPRS) to reinstate Inpatient Medications orders based on a
patient being discharged from an Observation treating specialty and
re-admitted within 24 hours to another treating specialty.", "", "PSJOERI", ""], ["3599", "OPTION SCHEDULING (#19.2) file", "File", "KERNEL", "2002/06/18", "APPROVED", "Active", "Controlled Subscription", "19.2", "\n
The Master Patient Index (MPI) will read (with FileMan) the following
fields from the OPTION SCHEDULING (#19.2) file. The data is used by
the MPI Data Quality Management team on the Austin MPI. The report
shows the status of various tasks that routinely run.\n
Example:
MPI STATUS REPORT
(generated Jun 15, 2002@18:52)\n
Scheduled Background Job Last Completed Run Next Scheduled Run
------------------------ ------------------ ------------------
MPI Stat Report JUN 14, 2002@08:21 JUN 16, 2002@02:00
Audit Data Purge JUN 14, 2002@22:00 JUN 15, 2002@22:00
Invalid Site Monitor JUN 14, 2002@22:00 JUN 15, 2002@22:00
Dup SSN Compile JUN 15, 2002@18:45 NOT SCHEDULED\n", "", "", ""], ["3600", "LTC co-pay API", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2002/06/24", "APPROVED", "Active", "Controlled Subscription", "", "
$$COPAY^EASECCAL(DFN,MNTH,LOS) This extrinsic function
returns LTC status and maximal monthly LTC copay amounts for the patient for
specific month if applicable. It is used in calculation of LTC copays in IB
package.", "", "EASECCAL", ""], ["3601", "DBIA3601", "Routine", "ACCOUNTS RECEIVABLE", "2002/06/28", "APPROVED", "Active", "Private", "", "
This IA is between PRCA and IB as a temporary IA in
relation to the Hartford/USAA settlement agreement.", "", "RCBEADJI", ""], ["3602", "PROSTHETIC HCPCS FILE", "File", "PROSTHETICS", "2002/07/02", "", "Withdrawn", "Private", "661.1", "", "", "", ""], ["3603", "PROSTHETIC SUSPENSE", "File", "PROSTHETICS", "2002/07/02", "", "Withdrawn", "Private", "668", "", "", "", ""], ["3604", "PROSTHETICS SITE PARAMETERS", "File", "PROSTHETICS", "2002/07/02", "", "Withdrawn", "Private", "669.9", "", "", "", ""], ["3605", "PROSTHETICS ORDER CONTROL SERVER OPTIONS", "Other", "PROSTHETICS", "2002/07/02", "", "Withdrawn", "Private", "", "
The COMMUNICATIONS SERVICE LIBRARY needs to send an
e-mail message to Prosthetics Server type options announcing the arrival of
data from the coreFLS database and to indicate in which part of the ^XTMP
global the data is stored. This is the mechanism for handoff of data from the
COMMUNICATIONS SERVICE LIBRARY to PROSTHETICS.\n
Option Names Interface Message Content
RMPR_OC_SPL Send Patient List ^XTMP("CSLPRSP;"_MCID,doc#
RMPR_OC_PURGE Purge Patient List ^XTMP("CSLPRSU8;"_MCID,doc#
RMPR_OC_HO Send Bulk Order ^XTMP("CSLPRSU5;"_MCID,doc#
RMPR_OC_SPO_OK Send Approved PO (ok) ^XTMP("CSLPRPO;"_MCID
RMPR_OC_SPO_RJT Send Approved PO (reject) ^XTMP("CSLPRPO;"_MCID
RMPR_OC_UNFREEZE Send Unfreeze Request ^XTMP("CSLPRPO;"_MCID\n
Note: MCID is the Message Control ID of the initial HL7 message in the
dialog.", "", "", ""], ["3606", "RMPR9EOU", "Routine", "PROSTHETICS", "2002/07/02", "", "Withdrawn", "Private", "", "", "", "RMPR9EOU", ""], ["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.\n
MCID is the Message Control ID from the HL7 message's MSH segment.\n
GLOBAL REFERENCES:\n
^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\n
Note: All dates are in FileMan format, converted from HL7 date format, if
necessary.", "", "", ""], ["3612", "Calls to Routine SROESL", "Routine", "SURGERY", "2002/07/03", "APPROVED", "Active", "Controlled Subscription", "", "
Build TMP global of Surgery cases electronically signed
for a given Report Identifier (RI) to be used in Reports Tab in CPRS (GUI).\n
^TMP("SROLST",$J,case #,RI)=Report Status^TIU DOCUMENT FILE #", "", "SROESL", ""], ["3613", "Imaging - Visit Info", "Routine", "CLINICAL PROCEDURES", "2002/07/03", "APPROVED", "Active", "Private", "", "
Imaging has permission, for a limited time, to call
GETVST^MDRPCOP and obtain a list of patient visit information. The time frame
to be identified by Clinical Procedures when the code in GETVST^MDRPCOP is
changed to call the approved API (SELECTED^VSIT). Clinical Procedures will
coordinate with Imaging on the release of the patch and identify the passing
parameters used in the call to SELECTED^VSIT to ensure continuity with both
applications (Imaging and Clinical Procedures).", "", "MDRPCOP", ""], ["3614", "PROSTHETICS PATIENT ELIGIBILITY", "File", "REGISTRATION", "2002/07/03", "", "Withdrawn", "Private", "2", "
The following are patient data to be passed to coreFLS
to support Purchasing and Inventory functions.", "", "", ""], ["3615", "Surgery on CPRS Reports Tab", "File", "SURGERY", "2002/07/08", "", "Other", "Controlled Subscription", "130", "
Read access to selected fields from SURGERY file, #130.\n
This Integration Agreement also allows direct global read access to the "B"
cross reference of the Surgery file.", "", "", ""], ["3616", "ORDERABLE ITEM DATA", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2002/07/09", "APPROVED", "Active", "Private", "", "
The entry point EN^ORBCMA2 is provided by OE/RR to
return orderable item data to Bar Code Med Admin to be used for administering
medications.", "", "ORBCMA2", ""], ["3617", "DBIA3617", "File", "KERNEL", "2002/07/10", "APPROVED", "Active", "Controlled Subscription", "101", "
Clinical Reminders Package requests to access the B
index on the protocol file (#101) directly.\n
Existing Reminder Package options with LIST MANAGER interfaces use XQORM to
allow selection from a list by entering the list item number.\n
e.g.\n
XQORM S XQORM("#")=$O(^ORD(101,"B",PROTOCOL_NAME,0))_U_"1:"_VALMCNT
S XQORM("A")="Select Item: "
Q\n", "", "", ""], ["3618", "POSTAL CODE AND COUNTY CODE APIS", "Routine", "KERNEL", "2002/07/11", "APPROVED", "Active", "Supported", "", "
Allow access to look-up Postal Code and County Code
data based on supported API references.", "", "XIPUTIL", "2007/01/25"], ["3619", "GMT SECURITY KEY API", "Routine", "REGISTRATION", "2002/07/11", "APPROVED", "Active", "Controlled Subscription", "", "
This API will be used to determine if the user
attempting to edit a patient's state and county (outside of population based
on Address Indexing) holds the appropriate security key to make to edit (based
on Address Indexing business rules). If the Postal code entered does not
exist in the Postal Code (#5.12) file, then the security key is not necessary
for the edit.", "", "DGREGDD1", ""], ["3620", "ORCFLAG", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2002/07/15", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement documents an interactive entry point
that allows an order to be flagged or unflagged.", "", "ORCFLAG", ""], ["3621", "Data updates", "Routine", "PHARMACY DATA MANAGEMENT", "2002/07/17", "APPROVED", "Active", "Controlled Subscription", "", "
In support of the Hawaii DoD project, Pharmacy Data
Management needs to know when changes are made to entries in the DRUG file
(#50). National Drug File data updates make changes to entries in this file.
To meet this need, NDF requests permission to call routine PSSHUIDG at entry
point PSN. The array ^TMP($J,"^",IEN where IEN is the internal entry number
in the DRUG file (#50) wil be sent to this entry point. The matching and
unmatching processes also make changes to the drug file that need to be sent
to PDM. To this end, NDF requests permission to call routine PSSHUIDG at
entry point DRG with the variable PSNB (if an entry is being matched) or DA
(if an entry is being unmatched) representing the internal entry number in the
drug file.", "", "PSSHUIDG", ""], ["3622", "DBIA 3622 - IMAGING", "Other", "TEXT INTEGRATION UTILITIES", "2003/09/30", "APPROVED", "Active", "Private", "", "
Text Integration Utilities developers give permission
to the VistA Imaging application to copy the TIUSRVPL, TIULC1 and TIULS
routines into their Imaging gateways. These routines will not be renamed or
modified at the destination.\n
Routine PNAME^TIULC1 is used by the output transform on field .01 (DOCUMENT
TYPE) of file 8925 (TIU DOCUMENT). This module will also execute
$$MIXED^TIULS.", "", "", ""], ["3623", "DBIA3623", "File", "1", "2002/07/23", "APPROVED", "Active", "Private", ".46", "
DSS is granted permission to export the INPUT TEMPLATE
file via KIDS with a single entry. This entry is used when importing data
into the DSS Department Table. This is a one time agreement. Patch number is
ECX*3.0.45.", "", "", ""], ["3624", "PATIENT ENROLLMENT DATE", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2002/07/23", "APPROVED", "Active", "Private", "", "
This IA is between EAS and Scheduling as a temporary IA
in relation to the Clinic Waiting Time report. This report requires the
correct enrollment date from the PATIENT ENROLLMENT File, #27.11. Until
corrections and data cleanup are accomplished on both the Health Eligibility
Center and VistA sides, this IA will need to remain in effect.", "", "EASWTAPI", ""], ["3625", "DBIA3625", "File", "REGISTRATION", "2002/07/23", "", "Withdrawn", "Private", "405", "", "", "", ""], ["3626", "DBIA3626", "File", "1", "2002/07/24", "APPROVED", "Active", "Private", "1", "
This integration agreement is necessary in order to
facilitate a change to the write access on field #20.51 (ADDRESS CHANGE DATE)
of the #300.11 (VIVA) file. The write access is currently set to the "^"
character, and will be changed to "@", in order to allow the filing of new
data into the field.\n
The PRE^IVMB686 tag will be used for this purpose. The patch number,
IVMB*2*686, will only be installed on the HEC system, and this request is for
a one-time use only. The Fileman team provided preliminary approval of this
request.", "", "", ""], ["3627", "'D' X-REF", "File", "KERNEL", "2002/07/26", "APPROVED", "Active", "Controlled Subscription", "4", "\n
MPI/PD has permission to execute a $ORDER direct global read
of the 'D' Cross Reference on the INSTITUTION (#4) file. This
is done specifically to identify existing anomalies with the HL
links used for MPI/PD messaging (e.g., multiple "D" cross
references in the file for a station number).", "", "", ""], ["3628", "SET VARIABLES FOR OPERATION REPORT", "Routine", "SURGERY", "2002/07/30", "APPROVED", "Active", "Controlled Subscription", "", "
DBIA for AMIE II (Automated Medical Information
Exchange) to use SET^SROVAR routine in a remote procedure to run Surgery
Operation Report. Integration Agreement will be only until the Electronic
Signature for Operative Reports patch (SR*3*100) is installed.", "", "SROVAR", ""], ["3629", "PRINT OPERATION REPORT", "Routine", "SURGERY", "2002/07/30", "APPROVED", "Active", "Controlled Subscription", "", "
DBIA for AMIE II (Automated Medical Information
Exchange) to use ^SROPRPT1 routine in a remote procedure to print Surgery
Operation Report. Integration Agreement will be only until the Electronic
Signature for Operative Reports patch (SR*3*100) is installed.", "", "SROPRPT1", ""], ["3630", "VAFCQRY APIs", "Routine", "REGISTRATION", "2002/07/30", "APPROVED", "Active", "Controlled Subscription", "", "
MPIF and RG would like to call the generic segment
builders for version 2.4 messages for the PID, EVN and PD1 segments.", "", "VAFCQRY", ""], ["3631", "VBECS/Surgery API", "Routine", "VBECS", "2002/07/30", "APPROVED", "Active", "Private", "", "
The VBECA5A API has been created to allow the Surgery
package to convert the existing pointer fields used to list available Blood
Products contained in the Blood Product file (#66), with a free text field.
The transition of the Blood Bank system from the existing M based system to a
.NET/SQL based system will eliminate the ability of the Surgery package to
access the Blood Product data using the current method. The affected files
and fields are:
File Field
SURGERY (#130) REQ BLOOD KIND (.01 field in
sub-file #130.14)
SURGERY SITE PARAMETERS (#133) DEFAULT BLOOD REQUEST", "", "VBECA5A", ""], ["3632", "Use of $$ES,$$AND api's", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2002/08/05", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement documents the api's $$ES^ORX8, which
returns the signature status of an order, and $$AND^ORX8, which returns a true
or false value if all conjunctions in the medication order are "AND".", "", "ORX8", ""], ["3633", "DBIA3633", "File", "ACCOUNTS RECEIVABLE", "2002/08/05", "APPROVED", "Active", "Private", "340", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3634", "MPIF002", "Routine", "MASTER PATIENT INDEX VISTA", "2002/08/05", "APPROVED", "Active", "Private", "", "
$$GETDFNS(SSN) returns all DFNs for a given SSN.", "", "MPIF002", ""], ["3635", "DBIA3635", "File", "ACCOUNTS RECEIVABLE", "2002/08/06", "APPROVED", "Active", "Private", "342.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3636", "DBIA3636", "File", "ACCOUNTS RECEIVABLE", "2002/08/06", "APPROVED", "Active", "Private", "430", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3637", "DBIA3637", "Routine", "REGISTRATION", "2002/08/06", "APPROVED", "Active", "Private", "", "
Means Test generic utilities routine.", "", "DGMTUTL", ""], ["3638", "DBIA3638", "File", "FEE BASIS", "2002/08/07", "APPROVED", "Retired", "Private", "161.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.\n
M Data Extractor is on the TRM and approved with constraints. However no
routines in the M Data Extractor (DES) namespace were found. No documentation
in the VDL and no entries in the National Patch Module. A search of Fee Basis
routines did not find any calls to routines in the DES namespace. The ICR
description states the ICR was created in 2002 as a temporary ICR for CoreFLS
and expected to be retired after data was extracted from the sites. Based on
on the description in the ICR and recommendations by reviewers, this ICR was
retired on 2/26/18.", "", "", ""], ["3639", "DBIA3639", "File", "KERNEL", "2002/08/07", "APPROVED", "Active", "Private", "4", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3640", "DBIA3640", "File", "KERNEL", "2002/08/07", "APPROVED", "Active", "Private", "20", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3641", "DBIA3641", "File", "KERNEL", "2002/08/07", "APPROVED", "Active", "Private", "200", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3642", "DBIA3642", "File", "INTEGRATED BILLING", "2002/08/07", "APPROVED", "Active", "Private", "36", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3643", "DBIA3643", "File", "PAID", "2002/08/07", "APPROVED", "Active", "Private", "450", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3644", "DBIA3644", "File", "REGISTRATION", "2002/08/07", "APPROVED", "Active", "Private", "2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3645", "DBIA3645", "File", "CPT/HCPCS CODES", "2002/08/07", "", "Retired", "Private", "81", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3646", "EMPLOYEE ELIGIBILITY CODE CHECK", "Routine", "REGISTRATION", "2004/05/25", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGSEC4", ""], ["3647", "GMVPXRM", "Routine", "GEN. MED. REC. - VITALS", "2003/11/07", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMVPXRM", ""], ["3648", "DBIA3648", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6911", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3649", "DBIA3649", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6912", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3650", "DBIA3650", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6914", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3651", "DBIA3651", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6914.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3652", "DBIA3652", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6914.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3653", "DBIA3653", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6914.4", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3654", "DBIA3654", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6915.9", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3655", "DBIA3655", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6917", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3656", "DBIA3656", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6920", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3657", "DBIA3657", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6920.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3658", "DBIA3658", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6921", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3659", "DBIA3659", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6922", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3660", "DBIA3660", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6926", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3661", "DBIA3661", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6927", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3662", "DBIA3662", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6928", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3663", "DBIA3663", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6928.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3664", "DBIA3664", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6928.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3665", "DBIA3665", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6928.3", "
ICR originally created for MDE to pull data from this
file to support populating COREFLS.", "", "", "2022/09/12"], ["3666", "DBIA3666", "File", "ENGINEERING", "2002/08/12", "APPROVED", "Active", "Private", "6929", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3667", "DBIA3667-A", "File", "EQUIPMENT/TURN-IN REQUEST", "2002/08/12", "APPROVED", "Active", "Private", "413", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3668", "DBIA3667-B", "File", "EQUIPMENT/TURN-IN REQUEST", "2002/08/12", "APPROVED", "Active", "Private", "413.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3669", "DBIA3667-C", "File", "EQUIPMENT/TURN-IN REQUEST", "2002/08/12", "APPROVED", "Active", "Private", "413.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3670", "DBIA3667-D", "File", "EQUIPMENT/TURN-IN REQUEST", "2002/08/12", "APPROVED", "Active", "Private", "413.3", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3671", "DBIA3667-E", "File", "EQUIPMENT/TURN-IN REQUEST", "2002/08/12", "APPROVED", "Active", "Private", "413.5", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3672", "DBIA3672", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "410.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3673", "DBIA3673", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "410.4", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3674", "DBIA3674", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "410.5", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3675", "DBIA3675", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "410.6", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3676", "DBIA3676", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "410.7", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3677", "DBIA3677", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "410.8", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3678", "DBIA3678", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "411", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3679", "DBIA3679", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "420", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3680", "DBIA3680", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Controlled Subscription", "420.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3681", "DBIA3681", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "420.6", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3682", "DBIA3682", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "420.7", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3683", "DBIA3683", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "420.8", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3684", "DBIA3684", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "421", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3685", "DBIA3685", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "421.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3686", "DBIA3686", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "421.5", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3687", "DBIA3687", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "424", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3688", "DBIA3688", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "424.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3689", "DBIA3689", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "440.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3690", "DBIA3690", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "440.5", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3691", "DBIA3691", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "440.6", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3692", "DBIA3692", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "440.7", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3693", "DBIA3693", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "441.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3694", "DBIA3694", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "441.3", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3695", "DBIA3695", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "441.6", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3696", "DBIA3696", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "441.7", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3697", "DBIA3697", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "442", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3698", "DBIA3698", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "442.7", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3699", "DBIA3699", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "442.8", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3700", "DBIA3700", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "443", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3701", "DBIA3701", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "443.4", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3702", "DBIA3702", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "443.6", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3703", "DBIA3703", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "443.8", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3704", "DBIA3704", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "444", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3705", "DBIA3705", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "444.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3706", "DBIA3706", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "445", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3707", "DBIA3707", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "445.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3708", "DBIA3708", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "445.3", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3709", "DBIA3709", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "445.4", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3710", "DBIA3710", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "445.6", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3711", "DBIA3711", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "445.7", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3712", "DBIA3712", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "445.8", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3713", "DBIA3713", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "446", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3714", "DBIA3714", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "446.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3715", "DBIA3715", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "446.5", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3716", "DBIA3716", "File", "IFCAP", "2002/08/14", "APPROVED", "Active", "Private", "446.6", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is short-term and will be
retired after the data has been extracted from all sites.", "", "", ""], ["3717", "DBIA3717", "Routine", "INTEGRATED BILLING", "2002/08/13", "APPROVED", "Active", "Private", "", "
Integrated Billing API to return the maximum daily
rates for LTC copayments.", "", "IBAECU", ""], ["3718", "DBIA3718-A", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2002/08/14", "", "Withdrawn", "Private", "", "
RPC BROKER CALL TIU SIGN RECORD", "", "", ""], ["3719", "DBIA3718-B", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL IS ORWPT APPTLST", "", "", ""], ["3720", "DBIA3718-C", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL IS ORWPT ADMITLST", "", "", ""], ["3722", "DBIA3718-E", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL IS ORQPT WARD PATIENTS", "", "", ""], ["3723", "DBIA3718-F", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL TIU REQUIRES COSIGNATURE", "", "", ""], ["3724", "DBIA3718-G", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL IS TIU GET PERSONAL PREFERENCES", "", "", ""], ["3725", "DBIA3718-H", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL IS ORWPCE LEX", "", "", ""], ["3726", "DBIA3718-I", "Remote Procedure", "CONSULT/REQUEST TRACKING", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL IS GMRCLIST CONSULT REQUEST", "", "", ""], ["3727", "DBIA3718-J", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL is ORWPT ENCTITL", "", "", ""], ["3729", "DBIA3728-B", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2002/08/14", "", "Pending", "Private", "", "
RPC CALL IS TIU LONG LIST OF TITLES", "", "", ""], ["3730", "DBIA3728-C", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2002/08/14", "", "Pending", "Private", "", "
TIU LOCK RECORD is the RPC call.", "", "", ""], ["3731", "RAPXRM", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2004/07/28", "", "Under Revision", "Controlled Subscription", "", "
This agreement allows the Clinical Reminders package to
call routine RAPXRM with the exam node string, to receive external values of
certain fields of that exam.\n
RA*5.0*153: returns HOSPITAL DIVISION and IMAGING LOCATION data from the
REGISTERED EXAMS (#70.02) sub-file to our Clinical Reminders subscriber.", "", "RAPXRM", ""], ["3732", "REMOVE OPTION FROM FILE #19.2", "File", "KERNEL", "2002/08/20", "APPROVED", "Active", "Controlled Subscription", "19.2", "
Permission to lookup and delete entries in 19.2 with VA
FileMan APIs for entries in the custody of the application doing the lookup.", "", "", ""], ["3733", "GMT Related IB utilities (IA#3733)", "Routine", "INTEGRATED BILLING", "2002/08/21", "APPROVED", "Active", "Supported", "", "
This IA provides one GMT-related API call from the IB
Package to be used by the PRCA (Accounts Receivable) package.", "", "IBAGMT", ""], ["3734", "HLCS(870,IEN,0) - NODE field (#.01)", "File", "HEALTH LEVEL SEVEN", "2002/08/27", "APPROVED", "Active", "Private", "870", "
This integration agreement covers direct global reads
of the NODE field (#.01) of the HL Logical Link file (#870.) The NODE field
is the first piece of the ^HLCS(870,IEN,0) node of an entry in this file.", "", "", ""], ["3735", "DBIA3735", "File", "NATIONAL DRUG FILE", "2002/08/28", "APPROVED", "Active", "Controlled Subscription", "50.68", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSN*4*94. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.\n
Pharmacy Data Management requests an integration agreement to have read access
to the National Drug file 50.68.", "", "", ""], ["3736", "CROSS-REFERENCE CREATION ERROR MESSAGE", "Routine", "CLINICAL REMINDERS", "2002/08/29", "APPROVED", "Active", "Private", "", "
This will give calling packages the ability to generate
a cross-reference creation error message.", "", "PXRMP12I", ""], ["3737", "PSSOPKI", "Routine", "PHARMACY DATA MANAGEMENT", "2002/08/29", "APPROVED", "Active", "Controlled Subscription", "", "
Pharmacy Data Management returns the most restrictive
CS FEDERAL SCHEDULE code / DEA SPECIAL HDLG code for a Pharmacy Orderable
Item, based on the Dispense Drugs that are associated with that Pharmacy
Orderable Item. The CS FEDERAL SCHEDULE code / DEA SPECIAL HDLG code is
derived as follows: If any of the active dispense drugs associated with the
orderable item for the specified package are matched to an entry in the
National Drug File, then the most restrictive CS FEDERAL SCHEDULE code from
the National Drug File will be returned. If there is no match or the CS
FEDERAL SCHEDULE code is undefined then the most restrictive DEA SPECIAL HDLG
code mapped to the corresponding CS FEDERAL SCHEDULE code as listed below will
be returned.\n
DEA, SPECIAL HDLG CS FEDERAL SCHEDULE
1 1 (Schedule I narcotics)
2A 2 (Schedule II narcotics)
2C 2n (Schedule II non-narcotics)
3A 3 (Schedule III narcotics)
3C 3n (Schedule III non-narcotics)
4 4 (Schedule IV narcotics)
5 5 (Schedule V narcotics)", "", "PSSOPKI", "2011/12/07"], ["3738", "PXRM INDEX FOR PHARMACY PATIENT FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will set an Inpatient Pharmacy index
entry.", "", "PXRMXRFS", ""], ["3739", "PSSOPKI1", "Routine", "PHARMACY DATA MANAGEMENT", "2002/08/29", "APPROVED", "Active", "Controlled Subscription", "", "
When a medication (Orderable Item) is selected in
Computerized Patient Record System (CPRS) in the medication order entry
process, that Orderable Item will be passed to the Pharmacy Data Management
package (PDM), along with the Pharmacy application and patient internal entry
number. The PDM will pass back to CPRS, Dosage information from the Drugs in
the DRUG file (#50) that are associated to that Orderable Item.", "", "PSSOPKI1", "2015/12/15"], ["3740", "Vendor Query (for CoreFLS)", "Routine", "COMMUNICATIONS SERVICE LIBRARY", "2002/09/12", "APPROVED", "Active", "Controlled Subscription", "", "
Vendor Query
-------------\n
Purpose: To allow a user to query CoreFLS for a vendor matching a given set of
search criteria\n
Behavior: The user is prompted for prompted for one or more query strings, as
follows.\n
>D VENQ^CSLVQ(.out,"NCS","A")\n
Vendor Name: CITI City: San Francisco State: CA\n
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).\n
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).\n
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.,\n
Vendor Name: "CITI%NK" City: "L_s Ang%es"\n\n
Example:\n
Vendor Name: "%TEMS%"
. . . . . . . .\n
Choose from:
1 ACCESS SYSTEMS
1116 SMITH ST
CHARLESTON, WV 25301\n
2 BARD ACCESS SYSTEMS
5425 W AMELIA EARHART DR
SALT LAKE CITY, UT 84116-3713\n
etc.\n\n
Select QUERY RESULTS SEQ NO: 2 BARD ACCESS SYSTEMS
5425 W AMELIA EARHART DR
SALT LAKE CITY, UT 84116-3713\n\n\n\n\n
Syntax:\n
D VENQ^CSLVQ(.out,flags,display_flags)\n\n
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).\n
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\n
N = Name\n
n = Vendor Number\n
a = Area Code\n
p = Phone Number\n
C = City\n
S = State\n
T = Tax ID/SSN\n
1 = Address Line 1\n
2 = Address Line 2\n
3 = Address Line 3\n
P = Postal Code\n
c = Chain number\n
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.\n
The display_flags parameter may contain any combination of the following flags
(again, order is unimportant):\n
n = CoreFLS Vendor ID / CoreFLS Site ID\n
A = address\n
t = telephone no.\n
T = Tax ID\n
C = Chain no.\n
P = Participation code\n
a = Attributes (Purchasing, Pay-to, etc.)\n
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.\n
If this parameter is missing or null, the default is to display only address
information (i.e., the default is "A").\n
OUTPUT\n
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:\n\n
out("NAME") - Vendor name\n
out("NUMBER") - numeric vendor ID\n
out("INACTIVE") - vendor will be inactive after this date (FM format)\n
out("TAXID") - Tax ID\n
out("AREA_CODE") - area code\n
out("PHONE") - phone number\n
out("FAX_AREA_CODE") - FAX area code\n
out("FAX") - FAX number\n
out("ADDRESS1") - address line 1\n
out("ADDRESS2") - address line 2\n
out("ADDRESS3") - address line 3\n
out("CITY") - City\n
out("STATE") - State\n
out("COUNTY") - County\n
out("ZIP") - Postal code\n
out("COUNTRY") - Country\n
out("SITE_CODE") - Site Code\n
out("CHAIN_NO") - Chain Number\n
out("COMMENTS") - Comments\n
out("PARTICIPATION_CODE") - Participation Code\n
out("LAST_UPDATED") - date vendor record last updated on CoreFLS\n
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\n
out("EDI_VENDOR")=1\n
The complete list of attribute subscripts is\n
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\n\n
Fields have no value will not appear in the out array\n
Errors: If an error should occur during the query, the node out("ERROR") will
be set. There are two special cases:\n
Network timeout - In this case, out("ERROR")="NETWORK TIMEOUT"\n
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"\n
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).\n
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", ""], ["3742", "ACCESS TO ADDRESS FIELDS IN DPT", "File", "REGISTRATION", "2002/08/29", "APPROVED", "Active", "Private", "2", "
Scheduling is requesting access to several address
fields in the Patient (#2) file.", "", "", ""], ["3743", "PXRM DELETE FOR PHARMACY PATIENT FILE INDEX", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will delete an Inpatient Pharmacy
index entry.", "", "PXRMXRFK", ""], ["3744", "DBIA3744", "Routine", "REGISTRATION", "2002/09/03", "APPROVED", "Active", "Supported", "", "", "", "VADPT", ""], ["3745", "DBIA3745", "Routine", "REGISTRATION", "2002/09/03", "APPROVED", "Active", "Private", "", "", "", "VAFHLRO3", ""], ["3746", "DBIA3746", "File", "1", "2003/02/03", "APPROVED", "Active", "Private", "0", "
This IA will document that the Medicine package can
loop through the ^DD(file number,0,"ID") with $O to get the identifier
numbers. The file numbers that the Medicine will loop through ranges from 690
to 701.", "", "", ""], ["3747", "PXRM INDEX FOR PRESCRIPTION FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will set an Outpatient Pharmacy index
entry.", "", "PXRMXRFS", ""], ["3748", "PXRM DELETE FOR PRESCRIPTION FILE INDEX", "Routine", "CLINICAL REMINDERS", "2002/09/05", "APPROVED", "Active", "Private", "", "
This entry point will delete an Outpatient Pharmacy
index entry.", "", "PXRMXSRFK", ""], ["3749", "KERNEL SITE PARAMETERS", "File", "KERNEL", "2002/09/06", "APPROVED", "Active", "Private", "8989.3", "
MailMan requests read access to KERNEL SITE PARAMETERS
file (#8989.3)", "", "", ""], ["3750", "PKI VERIFY DS DATA", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2002/09/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement is between CPRS and Pharmacy to handle
calls used in the processing of digitally signed orders for the DEA/PKI
project.\n", "", "ORWOR1", ""], ["3752", "PXRM INDEX FOR GMRV VITAL MEASUREMENT FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will set a GMRV Vital Measurement
index entry.", "", "PXRMXRFS", ""], ["3753", "PXRM DELETE FOR GMRV VITAL MEASUREMENT FILE INDEX", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will delete a Gen. Med. Rec. - Vitals
index entry.", "", "PXRMXRFK", ""], ["3754", "PXRM INDEX FOR LAB DATA FILE", "Routine", "CLINICAL REMINDERS", "2002/09/11", "APPROVED", "Active", "Private", "", "
This routine will set a Lab Data index entry or delete
one.", "", "PXRMXLAB", ""], ["3755", "TIU UNLOCK RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2002/09/18", "", "Pending", "Private", "", "
TIU UNLOCK RECORD", "TIU UNLOCK RECORD", "", ""], ["3756", "PXRM INDEX FOR THE RAD/NUC MED PATIENT FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will set an Radiology index entry.", "", "PXRMXRFS", ""], ["3757", "PXRM DELETE FOR THE RAD/NUC MED PATIENT FILE INDEX", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will delete an Radiology/Nuclear
Medicine index entry.", "", "PXRMXRFK", ""], ["3758", "PXRM INDEX FOR PSYCH INSTRUMENT PATIENT FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will set a Mental Health index entry.", "", "PXRMXRFS", ""], ["3759", "PXRM DELETE FOR PSYCH INSTRUMENT PATIENT FILE INDEX", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will delete a Mental Health index
entry.", "", "PXRMXRFK", ""], ["3760", "PXRM INDEX FOR THE PROBLEM FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will set a Problem List index entry.", "", "PXRMXRFS", ""], ["3761", "PXRM DELETE FOR PROBLEM FILE INDEX", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will delete a Problem List index
entry.", "", "PXRMXRFK", ""], ["3762", "test", "File", "PROSTHETICS", "2002/09/16", "", "Withdrawn", "Private", "660", "", "", "", ""], ["3763", "TIU SET DOCUMENT TEXT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2004/11/30", "APPROVED", "Active", "Private", "", "
TIU SET DOCUMENT TEXT", "TIU SET DOCUMENT TEXT", "", ""], ["3764", "ORWCV VST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/11", "APPROVED", "Active", "Controlled Subscription", "", "
ORWCV VST This RPC returns a list of appointments and
admissions for a patient based on parameters that define the beginning and
ending range for CPRS GUI.\n
Input:
DFN [required] = IEN from the Patient file #2
BEG [optional] = Beginning Date
END [optional] = End Date
SKIP [optional] = 0 or null if you want to return the list of
admissions for a patient, otherwise, 1.\n
Output:
ORVISIT = Return the values in a subscripted array format.\n
Return Parameter Description\n
- If successful find, then return the following data:
ORVISIT(n)=p1^p2^p3^p4 for n=1,2,3,4,. . .\n
Where: p1 :=appointment status code; appointment date/time;IEN from file #44
p2 :=appointment date/time p3 :=location name from #44,.01, the external
value p4 :=appointment status\n
- If problems are encountered, then return:
ORVISIT(1)=^error_message^error_message", "ORWCV VST", "", ""], ["3765", "$$A31 MPIFA31B", "Routine", "MASTER PATIENT INDEX VISTA", "2002/09/20", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point will create an A31 HL7 2.4 standard
message for the patient specified by DFN.", "", "MPIFA31B", ""], ["3766", "DBIA3766", "Other", "KERNEL", "2002/09/23", "APPROVED", "Active", "Private", "", "
This is a temporary IA to clean up the "AD" x-ref of
the OPTION (#19) file so IB can delete some old options.\n
In this IA, IB will KILL the "AD" cross reference of the whole OPTION (#19)
file. Then IB will loop through every entry in the OPTION (#19) file and
re-build the multiple cross reference using ENALL^DIK.\n
This will be performed during a pre-install to ensure the "AD" cross reference
is clean prior to the patch being installed to delete old options.", "", "", ""], ["3767", "PIDP RGADTP1", "Routine", "CLINICAL INFO RESOURCE NETWORK", "2002/09/24", "APPROVED", "Active", "Private", "", "
This API will process the PID segment into an array
subscripted by the fields that are taken from the PID segment (v2.4).", "", "RGADTP1", ""], ["3768", "DBIA3768", "Routine", "OUTPATIENT PHARMACY", "2002/09/25", "APPROVED", "Active", "Private", "", "
The purpose of this agreement is to provide the APIs
necessary for the My HealtheVet system to make refill requests via the
internet. The APIs will provide the ability to submit a request and get the
status of each request.", "", "PSOPRA", ""], ["3769", "PXRM INDEX FOR PTF FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
These entry point will set a PTF index entry for ICD0
and ICD9 data.", "", "PXRMXRFS", ""], ["3770", "PXRM INDEX FOR PCE FILES", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
These entry points will set indexes for a regular V
file entry and set indexes for V Files with coded entries.", "", "PXRMXRFS", ""], ["3771", "XUDHGUI", "Routine", "KERNEL", "2002/10/01", "APPROVED", "Active", "Supported", "", "
VISTA Graphical User Interface (GUI)-based applications
can use this API to look up devices. This API retrieves the first 20 devices
that meet the specifications passed. This API was made available with Kernel
Patch XU*8.0*220.\n
See the Web for more info: http://vista.DNS/kernel/apis/index.shtml", "", "XUDHGUI", "2009/01/22"], ["3772", "PXRM DELETE FOR PTF FILE INDEX", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
These entry point will delete a PTF index entry for
ICD0 and ICD9 data.", "", "PXRMXRFK", ""], ["3773", "PXRM DELETE FOR PCE FILES", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
These entry points will delete indexes for a regular V
file entry and delete indexes for V Files with coded entries", "", "PXRMXRFK", ""], ["3774", "HEALTH SUMMARY PARAMETERS", "File", "HEALTH SUMMARY", "2002/10/04", "APPROVED", "Active", "Controlled Subscription", "142.99", "
Network Health Exchange (NHE) and Patient Data Exchange
(PDX) seek to legalize existing code which does a FileMan read, using
$$GET1^DIQ, of fields in the HEALTH SUMMARY PARAMETERS file #142.99.", "", "", ""], ["3775", "TIU DIRECT READ OF USER CLASS FILE", "File", "AUTHORIZATION/SUBSCRIPTION", "2002/10/07", "APPROVED", "Active", "Private", "8930.3", "
TIU requests the ability to directly read the ASU User
CLass Memebership File #8930.3 - ^USR(8930.3, specifically the "AUC" cross
reference and the 0 node fields (#.03) EFFECTIVE DATE and (#.04) EXPIRATION
DATE to verify the user's membership status.", "", "", ""], ["3776", "TIU DIRECT READ OF USER CLASS FILE", "File", "AUTHORIZATION/SUBSCRIPTION", "2002/10/07", "APPROVED", "Active", "Private", "8930", "
TIU requests the ability to directly read the ASU User
CLass File #8930; specifically, ^USR(8930, using only the subclass multiple
^USR(8930,D0,1,D1,0) -- the SUBCLASS field (#.01) to verify a user's
applicable subclasses and membership status.", "", "", ""], ["3777", "DBIA3777", "Routine", "INTEGRATED BILLING", "2002/10/07", "APPROVED", "Active", "Private", "", "
Integrated Billing API to release billing charges that
were placed on hold as of 10/1/02 (effective date for Geographic Means
Testing). The charges will be released from hold when the during the
conversion process that will determine if the veteran's means test status will
become GMT Copay Required or remain MT Copay Required.", "", "IBAGMT", ""], ["3778", "DBIA3778", "Routine", "CLINICAL PROCEDURES", "2002/10/07", "APPROVED", "Active", "Private", "", "
This IA documents the
HL1^MCORMN(SAP,PATID,BDATE,EDATE,OCC,ATYPE) entry point in Medicine version
2.3 after the installation of patch MC*2.3*36. This interface will allow
Health Summary to get patient data for a brief summary, a brief summary for
only abnormal values, a full summary, a full captioned summary, and one line
medicine summary. This interface is setup in an HL7 compliant manner. HS
will need to have the Patient DFN, Beginning Date, Ending Date, # of
occurrences, and Type of report (Full or Brief). The
HL1^MCORMN(SAP,PATID,BDATE,EDATE,OCC,ATYPE) call will retrieve data based on
the above specifications and returned the data via a ^TMP("MCAR1",$J,#)
global. The data that will be returned is the DATE/TIME, PROCEDURE, SUMMARY,
PROCEDURE SUMMARY, and the PROCEDURE REPORT.", "", "MCORMN", ""], ["3779", "LOOKUP AND READ", "File", "MAILMAN", "2002/10/07", "APPROVED", "Active", "Controlled Subscription", "4.2", "
Permission is granted to:\n
1. Perform a FileMan lookup on file #4.2, DOMAIN, using the B and C cross
references.\n
2. Read the FLAGS field #1, using either direct global access or FileMan read.\n", "", "", ""], ["3780", "DBIA3780", "Routine", "CLINICAL PROCEDURES", "2002/10/08", "APPROVED", "Active", "Private", "", "
This IA documents the API interface between Medicine
version 2.3 and Immunology Case Registry version 2.1. Prior to calling the
API GET^MCARAPI(RESULTS,MCARDFN,MCSDT,MCEDT,MCFLDS), ICR should check the
existence of patch MC*2.3*34.", "", "MCARAPI", ""], ["3781", "AUTOMATIC ADDITION OF CONTROL CODES", "Routine", "KERNEL", "2002/10/09", "", "Withdrawn", "Private", "", "", "", "", ""], ["3782", "Vendor Update API", "Routine", "COMMUNICATIONS SERVICE LIBRARY", "2002/10/10", "APPROVED", "Active", "Controlled Subscription", "", "
Vendor Update API\n
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.\n
The format of the array is\n
...
ARRAY(index) = vendor_id^site_id^timestamp
...\n
(where timestamp is in Fileman format).\n
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.\n
Example:\n
^TMP(4375,1)="ACME_DRUGS_AND_SUPPLIES^SAN_FRANCISCO_2^3021008.191213"
^TMP(4375,2)="PEERLESS_AMBULANCE_CO^ATLANTA_7^3020721.1542"\n
The name of this array (not a reference) will be one parameter to the vendor
update.\n
Example:\n
In this case, the array name is $NA(^TMP(4375)), or simply "^TMP(4375)".\n
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\n
D UPDATE^CSLVQ(ARRAY,"ENTRY^ROUTINE")\n
The array passed as the first parameter may safely be KILLed by the caller at
any point after this call returns.\n
If an error occurs, CSLERR will be set a value in the format
"errno^description".\n
The callback has one parameter, the name of an array containing one or more
vendor records. The format of the array is\n
ARRAY(index, field_subscript) = value\n
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.\n
The possible values of field_subscript are\n\n
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\n
Notes:\n
[1] Dates are Fileman format\n
[2] A word-processing field will be stored in the format\n\n\n
SUBARRAY(1,0)=line 1 SUBARRAY(2,0)=line 2
...\n
For example, the comments field might be stored as\n
^TMP(1,34567830,"COMMENTS",1,0)="Line 1 of comments
^TMP(1,34567830,"COMMENTS",2,0)="Line 2 of comments\n\n
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\n
ARRAY(index,"EDI_VENDOR")=1\n
The complete list of attribute subscripts is\n\n\n\n
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\n\n\n
WARNING\n
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.\n
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", ""], ["3783", "PATIENT LIST READ FROM GLOBAL", "File", "ORDER ENTRY/RESULTS REPORTING", "2002/10/11", "APPROVED", "Active", "Controlled Subscription", "100.21", "
Package is reading node 10 of ^OR(100.21 to build an
array of patients on a specific CPRS patient list.", "", "", ""], ["3784", "DEA SPECIAL HANDLING CODE", "Routine", "PHARMACY DATA MANAGEMENT", "2002/10/15", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management will return a DEA Special
Handling code to Computerized Patient Record System (CPRS) for an Orderable
Item, when selected through the CPRS IV Fluids order dialogue, for an
outpatient. This DEA code will be based on the Dispense Drugs matched to that
Orderable Item. If the second parameter in this call is an "A" for Additive,
then a DEA Special Handling code will only be evaluated for a Dispense Drug if
that Dispense Drug has at least one active IV Additive matched to the Dispense
Drug. If the second parameter is an "S" for Solution, then a DEA Special
Handling code will only be evaluated for a Dispense Drug if that Dispense Drug
has at least one active IV Solution matched to the Dispense Drug.", "", "PSSUTIL1", ""], ["3785", "PXRM DIRECT READ OF PHARMACY PATIENT FILE", "File", "PHARMACY DATA MANAGEMENT", "2002/10/15", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
Clinical Reminders requests the ability to do a global read on the Patient
File #55 specifically, ^PS(55, using multiple fields from the Unit Dose
multiple, and the IV multiple to populate the new Clinical Reminders Index.", "", "PXRMSXRD", ""], ["3786", "PXRM RETRIEVE THE DRUG VALUE FROM FILE 52.6", "File", "PHARMACY DATA MANAGEMENT", "2002/10/15", "APPROVED", "Active", "Private", "52.6", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
Clinical Reminders request the ability to populate the new Clinical Reminders
Index with the IEN of the Drug file found in the IV ADDITIVES File, file 52.6
(piece two of the zero node).", "", "PXRMSXRD", ""], ["3787", "DBIA3787", "Other", "REGISTRATION", "2003/08/06", "APPROVED", "Active", "Private", "", "
In conjunction with the "fuzzy" lookup capacity that
will be introduced by the Patient Name Standardization patch DG*5.3*244, a
flag variable DPTNOFZY has been implemented to allow the suppression of fuzzy
lookups where appropriate.", "", "", ""], ["3788", "Work Phone Number", "File", "REGISTRATION", "2002/10/19", "", "Pending", "Controlled Subscription", "2", "", "", "", ""], ["3789", "DISPLAY MEANS TEST & ELIGIBILITY INFO", "Routine", "REGISTRATION", "2002/10/20", "APPROVED", "Active", "Controlled Subscription", "", "
Display Means Test info.", "", "DGMTU", ""], ["3790", "SERVICE OF WARD LOCATION", "File", "REGISTRATION", "2002/10/20", "", "Pending", "Controlled Subscription", "42", "", "", "", ""], ["3791", "DISPLAY COPAYMENT EXEMPTION INFO", "Routine", "INTEGRATED BILLING", "2002/10/20", "", "Pending", "Controlled Subscription", "", "", "", "IBARXEU", ""], ["3792", "PXRM DIRECT READ OF THE PRESCRIPTION FILE", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
Clinical Reminders requests the ability to do a global
read on the PRESCRIPTION FILE #52 specifically, ^PSRX(, using multiple fields
from the Refill multiple, and the Partial Date multiple to populate the new
Clinical Reminders Index.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["3793", "PSOPXRM1", "Routine", "OUTPATIENT PHARMACY", "2002/10/21", "", "Under Revision", "Controlled Subscription", "", "", "", "PSOPXRM1", ""], ["3794", "PUT PMI SHEET INFO IN TMP", "Routine", "NATIONAL DRUG FILE", "2003/03/04", "APPROVED", "Active", "Private", "", "
The purpose of this call is to return the appropriate
Patient Medication Information (PMI) text in a TMP global in the following
format:\n
^TMP($J,"PSNPMI",0)=DRUG NAME ^TMP($J,"PSNPMI",SECTION,0)=^^# OF LINES OF TEXT
^TMP($J,"PSNPMI",SECTION",n,0)=SECTION TEXT\n
The valid values for SECTION are: C - Common Brand Names D - Missing Dose F -
Phonetics H - How to Take I - Drug Interactions M - Medic Alert N - Notes O -
Overdose P - Precautions R - Storage S - Side Effects U - Uses W - Warnings Z
- Disclaimer", "", "PSNPPIO", ""], ["3795", "XUMF", "Routine", "KERNEL", "2002/10/22", "APPROVED", "Active", "Supported", "", "
Master File Server API", "", "XUMF", ""], ["3796", "SCHEDULED ADMISSIONS", "File", "REGISTRATION", "2002/10/23", "", "Active", "Controlled Subscription", "41.1", "", "", "", ""], ["3797", "PATIENT ENROLLMENT CLINIC/APPOINTMENTS", "File", "REGISTRATION", "2002/10/23", "APPROVED", "Active", "Controlled Subscription", "2", "", "", "", ""], ["3798", "HS OBJECT EXIST IN TIU", "Routine", "TEXT INTEGRATION UTILITIES", "2002/10/23", "APPROVED", "Active", "Private", "", "", "", "TIUHSOBJ", ""], ["3799", "DBIA3799", "Routine", "REGISTRATION", "2002/10/23", "APPROVED", "Active", "Supported", "", "
This integration agreement contains the listing of
supported calls for interaction with the RACE (#10), ETHNICITY (#10.2), and
RACE AND ETHNICITY COLLECTION METHOD (#10.3) files.\n
Calls supported are:
1) $$PTR2TEXT^DGUTL4(VALUE,TYPE)
2) $$INACTIVE^DGUTL4(VALUE,TYPE)
3) $$PTR2CODE^DGUTL4(VALUE,TYPE,CODE)
4) $$CODE2PTR^DGUTL4(VALUE,TYPE,CODE)", "", "DGUTL4", ""], ["3800", "PXRM DIRECT READ OF ORDER FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2002/10/23", "APPROVED", "Active", "Private", "100", "
Clinical Reminders requests the ability to do a global
read on the Order File #100 specifically, ^OR(100, using multiple fields from
the Zero node, and the Orderable Items multiple to populate the new Clinical
Reminders Index.\n
Amended: Added 01/18/2023: New functionality was released in patch PXRM*2*45,
with a compliance date of 09/30/2020, which used the WHEN ENTERED (#4) and
PATIENT LOCATION (#6) fields. Clinical Reminders uses these fields to
determine whether a patient is pregnant and if that conflicts with the data
stored in the Women's Health package.", "", "", "2023/01/19"], ["3801", "PXRM INDEX FOR THE ORDER FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will set an Order Entry/Results
Reporting index entry.", "", "PXRMXRFS", ""], ["3802", "PXRM DELETE FOR THE ORDER FILE", "Routine", "CLINICAL REMINDERS", "2003/09/24", "", "Retired", "Private", "", "
This entry point will delete an Order Entry/Results
Reporting index entry.", "", "PXRMXRFK", ""], ["3803", "PXRM DIRECT READ OF RAD/NUC MED PATIENT FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2002/10/23", "APPROVED", "Active", "Private", "70", "
Clinical Reminders requests the ability to do a global
read on the Rad/Nuc Med patient File, specifically, ^RADPT( using multiple
fields from the Zero Node, Registered Exams multiple, and the Examinations
multiple to populate the new Clinical Reminders Index.", "", "", ""], ["3804", "DBIA3804", "Routine", "INTEGRATED BILLING", "2002/10/24", "APPROVED", "Active", "Private", "", "
Patch PRCA*4.5*179 formally releases the MCCF Data Mart
Extract as an official part of the AR package. All sites have been running the
monthly MCCF Extract for over 2 years as Class III software. This patch serves
to convert the MCCF Data Mart Extract to Class I software. The extract now can
be run from a menu option instead of programmer mode. It solely performs
read-only processing on all data.\n
The Revenue Office has assigned a name to the extract and the associated
database on the VHA/CFO Data Mart. The name is VA Revenue Information (VARI).
All previous references in the software and documentation have been changed
from MCCF extract to VARI extract.\n
The information and analysis derived from these data are currently shared with
the VISNs and Facilities CFOs, as well as the Operations and Revenue Offices.
MCCF Collections supports ADP procurements and other medical care operations.\n
This Integration Agreement accesses the following functions within routine
IBCVA1: PROC", "", "IBCVA1", ""], ["3805", "File restriction issues within VistA Blood Bank.", "File", "1", "2002/10/25", "APPROVED", "Active", "Private", "0", "
The purpose on this integration agreement is to
restrict certain VistA Blood Bank files from all VistA users.\n
The manipulation of data within these files is prohibited. The following
VistA Blood Bank files are targeted for restricted status:\n
File Name File Number File Restriction Method
===============================================================
BLOOD INVENTORY 65 S ^DD(65,0,"DI")="^Y" BLOOD BANK
UTILITY 65.4 S ^DD(65.4,0,"DI")="^Y" BLOOD DONOR
65.5 S ^DD(65.5,0,"DI")="^Y" BLOOD PRODUCT 66
S ^DD(66,0,"DI")="^Y" BLOOD BANK VALIDATION 66.2 S
^DD(66.2,0,"DI")="^Y" OPERATION (MSBOS) 66.5 S
^DD(66.5,0,"DI")="^Y" BLOOD COMPONENT REQUEST 66.9 S
^DD(66.9,0,"DI")="^Y"", "", "", ""], ["3806", "Add/Update Vendor", "Routine", "FEE BASIS", "2002/10/29", "APPROVED", "Retired", "Private", "", "
Logic is called by subscribing software at entry point
UPD^FBAAVUP. It is defined with 1 argument in the formal parameter list,
which is the name of a local or global array. The array is indexed and could
contain one to many vendor records to be added or updated in file 161.2. The
call will be executed as: D UPD^FBAAVUP(ARRAY) Logic will add a new record
or access an existing record and update the record with the values contained
in ARRAY.", "", "FBCSLVUP", ""], ["3807", "DBIA3807", "Routine", "INTEGRATED BILLING", "2002/10/25", "APPROVED", "Active", "Private", "", "
This Integration Agreement accesses function
$$NAME^IBCSC61 for the MCCF Data Mart Extract.", "", "IBCSC61", ""], ["3808", "DBIA3808", "Routine", "INTEGRATED BILLING", "2002/10/25", "APPROVED", "Active", "Private", "", "
This Integration Agreement accesses function
SET^IBCSC4D for the MCCF Data Mart Extract.", "", "IBCSC4D", ""], ["3809", "DBIA3809", "Routine", "INTEGRATED BILLING", "2002/10/25", "APPROVED", "Active", "Private", "", "
This Integration Agreement accesses function 32^IBCF32
for the MCCF Data Mart Extract.", "", "IBCF32", ""], ["3810", "DBIA3810", "Routine", "INTEGRATED BILLING", "2002/10/25", "APPROVED", "Active", "Private", "", "
This Integration Agreement accesses functions
$$PIN^IBCSC5B and SET^IBCSC5B for the MCCF Data Mart Extract.", "", "IBCSC5B", ""], ["3811", "DBIA3811", "Routine", "INTEGRATED BILLING", "2002/10/25", "APPROVED", "Active", "Private", "", "
This Integration Agreement accesses function
SET^IBCSC5A for the MCCF Data Mart Extract.", "", "IBCSC5A", ""], ["3812", "DBIA3812", "Routine", "REGISTRATION", "2002/10/25", "APPROVED", "Active", "Controlled Subscription", "", "
Patch PRCA*4.5*179 formally releases the MCCF Data Mart
Extract as an official part of the AR package. All sites have been running the
monthly MCCF Extract for over 2 years as Class III software. This patch serves
to convert the MCCF Data Mart Extract to Class I software. The extract now can
be run from a menu option instead of programmer mode. It solely performs
read-only processing on all data.\n
The Revenue Office has assigned a name to the extract and the associated
database on the VHA/CFO Data Mart. The name is VA Revenue Information (VARI).
All previous references in the software and documentation have been changed
from MCCF extract to VARI extract.\n
The information and analysis derived from these data are currently shared with
the VISNs and Facilities CFOs, as well as the Operations and Revenue Offices.
MCCF Collections supports ADP procurements and other medical care operations.\n
This Integration Agreement accesses the following functions within routine
DGENA: $$FINDPRI\n
-----------------------------
Patch DG*5.3*909 added 4 new fields to the output array DGENR. The Enrollment
Application System (EAS) have a need to obtain enrollment data from Patient
Enrollment File (#27.11). This can be accomplished using the API in the
Registration Enrollment routine DGENA.\n
This Integration Agreement accesses the following functions within routine
DGENA: $$GET\n
Added piece 24, 25, 26, and 27 to the variable NODE from file 27.11. The
DGENR array is set up from the variable NODE.\n
CAMP LEJEUNE INDICATED?
CAMP LEJEUNE DATE
CAMP LEJEUNE CHANGE SITE
CAMP LEJEUNE SOURCE
-----------------------------", "", "DGENA", "2015/08/07"], ["3813", "HEALTH SUMMARY OBJECTS API", "Routine", "HEALTH SUMMARY", "2002/10/26", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement details APIs that may be subscribed to
to access and edit Health Summary Objects.", "", "GMTSOBJ", ""], ["3814", "TIU/HEALTH SUMMARY OBJECT CONVERSION", "File", "HEALTH SUMMARY", "2002/10/27", "APPROVED", "Active", "Private", "142.5", "", "", "", ""], ["3815", "DBIA3815", "File", "1", "2002/10/30", "APPROVED", "Active", "Private", "1", "
In order to protect against database corruption, this
Integration Agreement will be used as a one-time only action to check for the
existance of the ^DD(5.12,0,"UP") global node prior to the installation of
patch XU*8*246.\n
This node was found to have existed in one of our test accounts, and may exist
in one or more Production VistA accounts. If this node exists during
installation of the patch, the install will halt and prompt the user to
contact NVS for further assistance.", "", "", ""], ["3817", "PXRM DIRECT READ OF THE PTF FILE", "File", "REGISTRATION", "2002/11/15", "APPROVED", "Active", "Private", "45", "
Clinical Reminders requests the ability to do a global
read on the PTF File, specifically, ^DGPT(, using multiple fields from the
Zero Node, 70 node, 601, 501, and 401 to populate the new Clinical Reminders
Index.", "", "", ""], ["3818", "PTF PROCEDURES", "Routine", "HEALTH SUMMARY", "2002/11/01", "APPROVED", "Active", "Private", "", "", "", "GMTSDGP", ""], ["3819", "PXRM DIRECT READ OF THE PSYCH INSTRUMENT PATIENT FILE", "File", "MENTAL HEALTH", "2002/11/01", "APPROVED", "Active", "Private", "601.2", "
Clinical Reminders requests the ability to do a global
read on the Psych Instrument Patient File, specifically, ^YTT(601.2, using the
first piece from the Zero Node, Instrument multiple, and the Date multiple to
populate the new Clinical Reminders Index.", "", "", ""], ["3820", "DBIA3820-A", "File", "INTEGRATED BILLING", "2002/11/03", "APPROVED", "Active", "Private", "399", "
Requesting a direct global read of the following fields
to file 399 Bill Claims.", "", "", ""], ["3821", "DBIA3820-B", "File", "INTEGRATED BILLING", "2002/11/04", "APPROVED", "Active", "Private", "399.1", "
The Accounts Receivable package is requesting a direct
global read access of file 399.1 MCCR UTILITY file, for the following fields
listed.", "", "", ""], ["3822", "DBIA3820-C", "File", "INTEGRATED BILLING", "2002/11/04", "APPROVED", "Active", "Private", "399.3", "
The subscribing packages are requesting direct global
and FileMan read access to file 399.3 RATE TYPE for the NAME field (.01).", "", "", "2010/08/25"], ["3823", "DBIA3820-D", "File", "INTEGRATED BILLING", "2002/11/04", "", "Pending", "Controlled Subscription", "355.3", "
The Accounts Receivable package is requesting direct
global read access to file 355.3 GROUP INSURANCE PLAN for the following fields
listed below.", "", "", ""], ["3824", "DBIA3820-E", "File", "INTEGRATED BILLING", "2002/11/04", "", "Pending", "Private", "362.3", "
The Accounts Receivable package is requesting direct
global read access to file 362.3 IB BILL/CLAIMS DIAGNOSIS for the following
fields listed below.", "", "", ""], ["3825", "DBIA3820-F", "File", "INTEGRATED BILLING", "2002/11/04", "", "Pending", "Private", "362.4", "
The Accounts Receivable package is requesting direct
global read access to file 362.4 IB BILL/CLAIMS PRESCRIPTION REFILL for field
(.02) BILL NUMBER on the AIFN1 cross-reference.", "", "", ""], ["3826", "DBIA3820-G", "File", "INTEGRATED BILLING", "2002/11/04", "", "Pending", "Private", "362.5", "
The Accounts Receivable package is requesting direct
global read access to file 362.5 IB BILL/CLAIMS PROSTHETICS for field (.02)
BILL NUBER.", "", "", ""], ["3827", "DBIA3820-H", "File", "INTEGRATED BILLING", "2002/11/04", "", "Pending", "Private", "350.9", "
The Accounts Receivable package is requesting direct
global read access to file 350.9 IB SITE PARAMETERS for field (1.21) MEDICARE
PROVIDER NUMBER.", "", "", ""], ["3828", "DBIA3820-I", "File", "INTEGRATED BILLING", "2002/11/04", "APPROVED", "Active", "Controlled Subscription", "355.1", "
The Accounts Receivable package is requesting direct
global read access to file 355.1 TYPE OF PLAN for the following fields listed
below.^", "", "", "2002/11/20"], ["3829", "DBIA3829-A", "File", "REGISTRATION", "2002/11/04", "", "Pending", "Private", "35", "
Accounts Receivable package requesting a Direct global
read of the following field (1) ABBREVIATION in file 35 OTHER FEDERAL AGENCY
to set into a variable for use by the package.", "", "", ""], ["3830", "DBIA3829-B", "File", "REGISTRATION", "2002/11/04", "", "Pending", "Private", "81.3", "
Accounts Receivable package requesting a Direct global
read of the following field (.03) CODE in file 81.3 CPT MODIFIER to set into a
variable for use by the package.", "", "", ""], ["3831", "DBIA3829-C", "File", "INTEGRATED BILLING", "2002/11/04", "", "Pending", "Private", "36", "
The Accounts Receivable package is requesting a Direct
global read of the following fields in file 36 INSURANCE COMPANY to set into a
variable for use by the package.", "", "", ""], ["3832", "Imaging - Consult/Request HL7 message", "Routine", "CONSULT/REQUEST TRACKING", "2002/11/04", "APPROVED", "Active", "Controlled Subscription", "", "
The Consult/Request Tracking developer has given
Imaging permission to call routine GMRCHL7 to generate HL7 message segments.", "", "GMRCHL7", ""], ["3833", "Imaging - GMRCHL72", "Routine", "CONSULT/REQUEST TRACKING", "2002/11/04", "APPROVED", "Active", "Controlled Subscription", "", "
The Consult/Request Tracking developer has given
Imaging permission to call routine GMRCHL72 to generate HL7 message segments.", "", "GMRCHL72", ""], ["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.\n
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.\n
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:\n
S X=$$CCTBL^CSLEC() to send CC table update query to CoreFLS system\n
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).\n
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.\n
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.\n
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)\n
The following logic decide whether the update is successful or not:\n
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.\n
If Request date <= Start date
Start date > End date table partially updated and data
is not usable.
Start date <= End date table updated successfully\n", "", "CSLEC", ""], ["3835", "PXRM DIRECT READ OF GMRV VITAL MEASUREMENT FILE", "File", "GEN. MED. REC. - VITALS", "2002/11/05", "APPROVED", "Active", "Private", "120.5", "
Clinical Reminders requests the ability to do a global
read on the GMRV Vital Measurement File, specifically, ^GMR(120.5. using
multiple fields from the Zero Node to populate the new Clinical Reminders
Index.", "", "", ""], ["3836", "PSJPXRM1", "Routine", "INPATIENT MEDICATIONS", "2002/11/06", "", "Under Revision", "Controlled Subscription", "", "
The entry point OEL^PSJPXRM1 is provided by Inpatient
Medciations package to return the detailed information on a patient's unit
dose or IV order for the Clinical Reminders package to use.", "", "PSJPXRM1", ""], ["3837", "PXRM DIRECT READ OF THE PROBLEM FILE", "File", "PROBLEM LIST", "2002/11/18", "APPROVED", "Active", "Private", "9000011", "
Clinical Reminders requests the ability to do a global
read on the Problem File, specifically, ^AUPNPROB(, using multiple fields from
the Zero Node, and the first node to populate the new Clinical Reminders
Index.", "", "", "2023/02/07"], ["3838", "PXRM DIRECT READ OF THE VISIT FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2002/11/18", "", "Withdrawn", "Private", "9000010", "
Clinical Reminders requests the ability to do a global
read on the Visit File, specifically, the first piece of the zero node to
populate the new Clinical Reminders Index.", "", "", ""], ["3839", "PXRM DIRECT READ OF THE V CPT FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2002/11/18", "APPROVED", "Active", "Private", "9000010.18", "
Clinical Reminders requests the ability to do a global
read on the V CPT File, specifically, ^AUPNVCPT(, using multiple fields from
the Zero Node to populate the new Clinical Reminders Index.", "", "", ""], ["3840", "ACCESS TO DRG FILE #80.2", "Routine", "DRG GROUPER", "2003/04/02", "", "Withdrawn", "Controlled Subscription", "", "", "", "", ""], ["3841", "PXRM DIRECT READ OF THE V IMMUNIZATION FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2002/11/18", "", "Withdrawn", "Private", "9000010.11", "
Clinical Reminders requests the ability to do a global
read on the V Immunization File, specifically, ^AUPNVIMM(, using multiple
fields from the Zero Node to populate the new Clinical Reminders Index.", "", "", ""], ["3842", "PXRM DIRECT READ OF THE V PATIENT ED FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2002/11/18", "", "Withdrawn", "Private", "9000010.16", "
Clinical Reminders requests the ability to do a global
read on the V Patient Ed File, specifically, ^AUPNVPED(, using multiple fields
from the Zero Node to populate the new Clinical Reminders Index.", "", "", ""], ["3843", "PXRM DIRECT READ OF THE V POV FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2002/11/18", "APPROVED", "Active", "Private", "9000010.17", "
Clinical Reminders requests the ability to do a global
read on the V POV File, specifically, ^AUPNVPOV(, using multiple fields from
the Zero Node to populate the new Clinical Reminders Index.", "", "", ""], ["3844", "PXRM DIRECT READ OF THE V SKIN TEST FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2002/11/18", "", "Withdrawn", "Private", "9000010.12", "
Clinical Reminders requests the ability to do a global
read on the V Skin Test File, specifically, ^AUPNVSK(, using multiple fields
from the Zero Node to populate the new Clinical Reminders Index.", "", "", ""], ["3845", "PXRM DIRECT READ OF THE V EXAM FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2002/11/18", "", "Withdrawn", "Private", "9000010.13", "
Clinical Reminders requests the ability to do a global
read on the V Exam File, specifically, ^AUPNVXAM(, using multiple fields from
the Zero Node to populate the new Clinical Reminders Index.", "", "", ""], ["3846", "Print Full (Patient Profile MAS) Report", "Routine", "SCHEDULING", "2002/11/19", "APPROVED", "Active", "Private", "", "
DBIA for AMIE II (Automated Medical Information
Exchange) to use routine PRINT^SDPPRT in a remote procedure to print Full
(Patient Profile MAS) Report. Integration Agreement will be only until
Scheduling Replacement begin.", "", "SDPPRT", ""], ["3847", "dba-test", "File", "ACCOUNTS RECEIVABLE", "2002/11/20", "", "Withdrawn", "Private", "430", "
testing", "", "", ""], ["3848", "DBIA 3848", "File", "OUTPATIENT PHARMACY", "2002/11/20", "APPROVED", "Active", "Private", "52.41", "
This agreement gives the Controlled Substance package
read access to the PENDING OUTPATIENT ORDERS (#52.41) file and the "AD" (LOGIN
DATE) cross reference. This access will be needed to generate the Digitally
Signed CS Order Report for controlled substance orders entered electronically
and signed digitally through Computerized Patient Record System (CPRS) as part
of the DEA/VA PKI project.", "", "", ""], ["3849", "Surgery file #130", "File", "SURGERY", "2002/11/21", "", "Withdrawn", "Private", "130", "
Integration agreement to use the several fields from
Surgery file #130 in a remote procedure call. The fields will be used to list
the patient case status.\n", "", "", ""], ["3850", "Fund Query", "Routine", "COMMUNICATIONS SERVICE LIBRARY", "2003/06/02", "APPROVED", "Active", "Controlled Subscription", "", "
Fund Query
----------\n
Purpose: To allow a user to query coreFLS for funds matching a given query
string.\n
Behavior: The user is prompted for a query string as follows\n
Fund:\n
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.\n
Example:\n
>D FUNDQ^CSLARACS\n
Fund: 8180
. .\n
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\n
Select QUERY RESULTS SEQUENCE NO: 1 8180DA100XXXX GENERAL POST
FUND-ALLOCATIO N >W CSLY 8180DA100XXXX
>\n\n
Syntax:\n
D FUNDQ^CSLARACS\n\n
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
----------\n
Purpose: To allow a user to query coreFLS for BOC or RSC matching a given
query string.\n
Behavior: The user is prompted for a query string as follows\n
RSC:\n
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.\n
Example:\n\n
>D BOCQ^CSLARACS\n
BOC/RSC: R101
. . .
1 R10100 INTEREST REVENUE\n
Select QUERY RESULTS SEQUENCE NO: 1 R10100 INTEREST REVENUE\n\n\n
Syntax:\n
D BOCQ^CSLARACS\n\n
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.\n
The CSL Cost Center file, 536.3, contains 3 fields: Cost Center Code,
description, and Active Flag.", "", "", ""], ["3853", "LAB file 60 'B' x-ref", "File", "LAB SERVICE", "2002/11/26", "APPROVED", "Active", "Private", "60", "", "", "", ""], ["3854", "DBIA3854", "Routine", "CLINICAL PROCEDURES", "2002/11/26", "APPROVED", "Active", "Private", "", "
This IA documents the API interface between Clinical
Procedures and Clinical Case Registries version 1.0. Prior to calling the API
GET^MDAPI1(RESULTS,MDARDFN,MDSDT,MDEDT,MDFLDS), the subscriber should check
the existence of patch MD*1*1.", "", "MDAPI1", ""], ["3855", "Registration For DGRP Routine", "Routine", "REGISTRATION", "2002/12/06", "APPROVED", "Active", "Private", "", "
AMIE will need to access the View Registration report
for use in the CAPRI GUI application. This Integration Agreement covers the
use of EN1^DGRP.", "", "DGRP", ""], ["3856", "TIU use of LR7OR2", "Routine", "LAB SERVICE", "2002/12/06", "APPROVED", "Active", "Private", "", "
This integration agreement describes a call by TIU to
LR7OR2.\n
Routine: LR7OR2 Component: TEST(.TIUY,DFN, ,$G(TIUEDT),$G(TIULDT), ,TIUSTS)\n
This call returns labs in the format:\n
^TMP("LRAPI",$J,CTR)=9999999-IVDT_"^"_SSUB_"^"_^TMP("LRRR"
,$J,DFN,SSUB,IVDT,SEQ)\n
^TMP("LRRR",$J,DFN,SUB,inverse d/t,sequence #) =
Test^result^L/N flag^ units^reference range^result
status^^^Nat'l Code^Name^System^Verified by^^Therapeutic
flag^Print Name^Accession^Order#", "", "LR7OR2", ""], ["3857", "PATIENT SECURITY CHECK", "Routine", "REGISTRATION", "2002/12/03", "APPROVED", "Active", "Controlled Subscription", "", "
The Record Tracking package has several NOIS calls
indicating that the patient sensitivity/security check is no longer being done
on patient lookups.\n
This problem surfaced after DG*5.3*223 was released on May 1, 2000. Prior to
that release, the patient security/sensitivity check was done as part of the
post-selection process when looking up a patient on the Patient File #2 using
File Manager. DG/223 prevented this check if the DIC(0) variable contained an
"I" which was the case for CIRN. Record Tracking also contains an "I" when
doing these lookups, therefore the security check stopped being done.\n
The solution is to call ^DGSEC from two routines: RTB for normal patient
lookup RTDPA for lookup using bar code scanner", "", "DGSEC", ""], ["3858", "Reference EMAIL ADDRESS field in the New Person file", "File", "KERNEL", "2002/12/09", "APPROVED", "Active", "Private", "200", "", "", "", ""], ["3859", "APPOINTMENT DATA BY PATIENT", "Routine", "SCHEDULING", "2002/12/12", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA contains a list of the supported calls for
interaction with Appointment data contained in the Patient appointment
sub-file 2.98 and the Hospital Location appointment sub-file 44.001. This
DBIA is associated with Scheduling patch SD*5.3*275, to be released to NVS on
1/10/03.\n
The supported calls are:\n
GETAPPT^SDAMA201 and $$NEXTAPPT^SDAMA201", "", "SDAMA201", ""], ["3860", "DGPF PATIENT RECORD FLAG", "Routine", "REGISTRATION", "2003/07/08", "APPROVED", "Active", "Controlled Subscription", "", "\n
The purpose of this API is to facilitate the retrieval of specific data
that can be used for the displaying of or the reporting of only ACTIVE
Patient Record Flag (PRF) Assignment information for a patient.
The following Patient Record Flag files are used:
(#26.15) PRF NATIONAL FLAG
(#26.11) PRF LOCAL FLAG
(#26.13) PRF ASSIGNMENT
(#26.14) PRF ASSIGNMENT HISTORY
(#26.16) PRF TYPE
The primary mechanism is from within the Registration package.", "", "DGPFAPI", ""], ["3861", "REFERENCES TO REQUEST SERVICES FILE", "File", "CONSULT/REQUEST TRACKING", "2003/01/03", "APPROVED", "Active", "Controlled Subscription", "123.5", "", "", "", ""], ["3862", "DBIA3862", "File", "BENEFICIARY TRAVEL", "2003/04/01", "APPROVED", "Active", "Private", "392.31", "
This file contains vendors of the Core Financial
Logistics System (coreFLS) used by the site's local system. Entries should
only be added and updated through the applications interfaced with coreFLS,
routine DGBTCSL.", "", "", ""], ["3864", "SCHEDULING API", "Routine", "SCHEDULING", "2003/01/06", "", "Withdrawn", "Controlled Subscription", "", "", "", "", ""], ["3865", "DBIA3865", "Routine", "BENEFICIARY TRAVEL", "2003/04/01", "APPROVED", "Active", "Private", "", "
The DGBTCSL routine is the interface for the Patient
Management System packages (Beneficiary Travel, Incomplete Records Tracking,
and Library) to the CoreFLS system. This routine consists of a module for a
standalone query to add CoreFLS vendors to the LOCAL VENDOR file (#392.31).
It also handles output transform and Filemanager calls from Library and
Beneficiary Travel templates and routines when edits to there pointed fields
to the LOCAL VENDOR file (#392.31) are made.", "", "DGBTCSL", ""], ["3866", "DBIA3866", "File", "LIBRARY", "2003/04/01", "APPROVED", "Retired", "Private", "680", "\n
************************************************************************
The Library package was decommissioned with LBR*2.5*15. This ICR was retired
with the release of the Library patch. A Beneficiary Travel patch will be
released in the future removing references to the Library package.
************************************************************************\n
LOCAL SERIALS file (#680) contains the field MICROFILM COREFLS VENDOR (#2.6)
which is a pointer containing CoreFLS vendors from the LOCAL VENDOR file
(#392.31).\n
Through the Library application when entering a MICROFILM COREFLS VENDOR, if
the query to CoreFLS is made to enter a new vendor to the LOCAL VENDOR file,
then the routine DGBTCSL is executed that will add the new vendor to the LOCAL
VENDOR file and add the entry to the MICROFILM COREFLS VENDOR field.\n
This agreement allows the routine DGBTCSL of the Beneficiary Travel package
which controls the LOCAL VENDOR file of CoreFLS vendors with the ability to
update the MICROFILM COREFLS VENDOR from the DGBTFLS routine.", "", "", ""], ["3867", "DBIA3867", "File", "LIBRARY", "2003/04/01", "", "Retired", "Private", "680.6", "\n
***********************************************************************
The Library package was decommissioned with LBR*2.5*15. This ICR was retired
with the release of the Library patch. A Beneficiary Travel patch will be
released in the future removing references to the Library package.
***********************************************************************\n
LIBRARY PARAMETERS file (#680.6) contains the field DEFAULT COREFLS VENDOR
(#.09) which is a pointer containing CoreFLS vendors from the LOCAL VENDOR
file (#392.31).\n
Through the Library application when entering a DEFAULT COREFLS VENDOR, if the
query to CoreFLS is made to enter a new vendor to the LOCAL VENDOR file, then
the routine DGBTCSL is executed that will add the new the LOCAL VENDOR file
and add the entry to the DEFAULT COREFLS VENDOR field.\n
This agreement allows the routine DGBTCSL of the Beneficiary Travel package
which controls the LOCAL VENDOR file of CoreFLS vendors with the ability to
update the DEFAULT COREFLS VENDOR from the DGBTFLS routine.", "", "", ""], ["3868", "DBIA3868", "File", "LIBRARY", "2003/04/01", "APPROVED", "Retired", "Private", "681", "\n
************************************************************************
The Library package was decommissioned with LBR*2.5*15. This ICR was retired
with the release of the Library patch. A Beneficiary Travel patch will be
released in the future removing references to the Library package.
************************************************************************\n
LBRY DISPOSITION file (#681) contains the field COREFLS VENDOR (#3.01) which
is a pointer containing CoreFLS vendors from the LOCAL VENDOR file (#392.31).\n
Through the Library application when entering a COREFLS VENDOR, if the query
to CoreFLS is made to enter a new vendor to the LOCAL VENDOR file, then the
routine DGBTCSL is executed that will add the new vendor to the LOCAL VENDOR
file and add the entry to the COREFLS VENDOR field.\n
This agreement allows the routine DGBTCSL of the Beneficiary Travel package
which controls the LOCAL VENDOR file of CoreFLS vendors with the ability to
update the COREFLS VENDOR from the DGBTFLS routine.", "", "", ""], ["3869", "APPOINTMENT DATA BY CLINIC", "Routine", "SCHEDULING", "2003/01/08", "APPROVED", "Active", "Controlled Subscription", "", "
This IA contains a list of the supported calls for
interaction with Appointment data contained in the Patient sub-file 2.98 and
the Hospital Location appointment sub-file 44.001. This IA is associated with
Scheduling patch SD*5.3*275, to be released to NVS on 1/10/03.", "", "SDAMA202", ""], ["3870", "DG OPTIONS/MENUS ON SECURITY OFFICER MENU", "Other", "REGISTRATION", "2003/01/10", "APPROVED", "Active", "Private", "", "
Health Information Security Service is requesting to
place some DG options/menus on INFORMATION SECURITY OFFICER MENU [XUSPY].\n
DG SECURITY OFFICER MENU
DG PATIENT INQUIRY
DG PARAMETER ENTRY
DG BULLETIN LOCAL", "", "", ""], ["3872", "DBIA3872", "File", "PROSTHETICS", "2003/01/10", "APPROVED", "Active", "Private", "661.1", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is sort-term and will be retired
after the data has been extracted from all sites.", "", "", ""], ["3873", "DBIA3873", "File", "PROSTHETICS", "2003/01/10", "APPROVED", "Active", "Private", "661.2", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is sort-term and will be retired
after the data has been extracted from all sites.", "", "", ""], ["3874", "DBIA3874", "File", "PROSTHETICS", "2003/01/10", "APPROVED", "Active", "Private", "661.3", "
MDE will pull the data from this file to support the
population of the new CoreFLS system. This IA is sort-term and will be retired
after the data has been extracted from all sites.", "", "", ""], ["3875", "ID Write identifier node File #441", "File", "1", "2003/01/14", "APPROVED", "Active", "Private", "441", "
The National Item File's Item Number (NIF ITEM NUMBER
field #51) needs to be added as a write identifier to the ITEM MASTER File
#441. Field #51, is not a user-editable field, therefore it can not be
defined as a field identifier. As KIDS does not have a mechanism to transport
write identifiers without exporting the entire file definition, it is
requested that for patch PRC*5.1*63 (NATIONAL ITEM FILE - PHASE 1) IFCAP be
permitted to set the ID node via the post-init routine PRC5163P. The proposed
code is as follows:\n
EN ;Entry point
;Adding NIF Item # as write identifier for ITEM MASTER file (#441)
S ^DD(441,0,"ID","Z")="W:$P($G(^(0)),U,15)>0 "" NIF#""_
$P($G(^(0)),U,1 5)"
Q", "", "", ""], ["3876", "PSJBCBU", "Routine", "INPATIENT MEDICATIONS", "2003/01/15", "APPROVED", "Active", "Private", "", "
This API is for use with the BCMA National Contingency
Plan.\n
Entry point EN returns in an array specified by the calling routine Inpatient
Meds order data in an HL7 format.\n
Entry point EN2 returns an ^TMP global with active orders.\n
OUTPUT DEFINITION:\n
^TMP("PSJBU",$J,Index,0) = DFN ^ ON (Order number from Inpatient Medications
V. 5.0 package)^ ON_V/U/P\n
NOTE:\n
- ^TMP("PSJBU",$J,1,0) = -1 will be returned if no active orders are found.", "", "PSJBCBU", ""], ["3877", "DBIA 3877", "File", "INTEGRATED BILLING", "2003/01/16", "APPROVED", "Active", "Private", "354.7", "
Purpose is to retrieve billing information with regard
to missing Outpatient Pharmacy copay bills.", "", "", ""], ["3878", "Resource device filing in server option", "File", "KERNEL", "2003/01/20", "APPROVED", "Active", "Private", "19", "
When a KIDS distribution installs a server type option
that has an attached resource device (SERVER DEVICE field #227), the internal
entry number (ien) of the device on the origin system and not the resolved ien
of the corresponding device on the destination system files. Thus the
installed server type option is usually now pointing to the wrong device or a
non-existent device. As KIDS does not have a mechanism for finding the
appropriate device entry and resolving the pointer value, it is requested that
for patch PRC*5.1*63 (NATIONAL ITEM FILE - PHASE 1) IFCAP be permitted by VA
FileMan database server calls to lookup the appropriate entry and file its ien
into the server type option PRCHITEM_UPDATE during execution of the post-init
routine PRC5163P.\n
The proposed code from module EN^PRC5163P is:\n
;Linking resource device to server option
N PRCERR,PRCD,PRCDA,PRCDA2
K PRCERR
S PRCDA=$$FIND1^DIC(3.5,"","X","PRCHITEM","B","I $P(^(""TYPE""),U)=
""RES""","PRCERR")
I PRCDA'>0!$D(PRCERR) D G EX
. N PRCT S PRCT(1)="Lookup of resource device PRCHITEM failed."
. S PRCT(2)=" You will have to manually link resource device PRCHITEM
to server"
. S PRCT(3)=" option PRCHITEM_UPDATE."
. D MES^XPDUTL(.PRCT)
K PRCERR
S PRCDA2=$$FIND1^DIC(19,"","X","PRCHITEM_UPDATE","B","","PRCERR")
I PRCDA2'>0!$D(PRCERR) D G EX
. N PRCT S PRCT(1)="Lookup of server option PRCHITEM_UPDATE failed."
. S PRCT(2)=" Please contact NVS as there were patch installation
problems."
. D MES^XPDUTL(.PRCT)
K PRCD,PRCERR
S PRCD(19,PRCDA2_",",227)=PRCDA
D FILE^DIE("K","PRCD","PRCERR")
I $D(PRCERR) D G EX
. N PRCT S PRCT(1)="Automated linkage of resource device PRCHITEM to
server option"
. S PRCT(2)=" PRCHITEM_UPDATE failed. You will have to manually link
it."
. D MES^XPDUTL(.PRCT)
N PRCT S PRCT(1)="Resource device PRCHITEM was successfully linked to
server"
S PRCT(2)=" option PRCHITEM_UPDATE."
D MES^XPDUTL(.PRCT)\n
EX ;
Q", "", "", ""], ["3879", "DBIA3879-A", "Routine", "VBECS", "2003/01/21", "APPROVED", "Active", "Controlled Subscription", "", "
The entry point DFN^VBECA3A is provided by the Blood
Bank package to return Blood Bank patient related data for use by CPRS. This
data will be used to populate the Blood Bank Report listed under the Reports
tab.", "", "VBECA3A", ""], ["3880", "DBIA3879-B", "Routine", "LAB SERVICE", "2003/01/21", "APPROVED", "Active", "Controlled Subscription", "", "
The entry point CPRS^VBECA3B is provided by the Blood
Bank package to convert data from the ^TMP array created by VBECA3A for use by
CPRS. This data will be used to populate the Blood Bank Report listed under
the Reports tab.", "", "VBECA3B", ""], ["3881", "DBIA3879-C", "Routine", "LAB SERVICE", "2003/01/21", "APPROVED", "Active", "Controlled Subscription", "", "
The entry point PAT^VBECA1A is provided by the Blood
Bank package to validate the patient information used when calling the VBECS
API's.", "", "VBECA1A", ""], ["3882", "DBIA3882", "Other", "KERNEL", "2003/01/22", "APPROVED", "Active", "Private", "", "
The Controlled Substance V3.0 Narcotics Monitoring Menu
[PSD NM MENU] will include Kernel's Option Access by User [XUOPTWHO] option.\n
The Narcotics Monitoring enhancement is distributed in the PSD*3.0*41 KIDS
build which transports the [XUOPTWHO] option as an 'Attach to Menu'.", "", "", ""], ["3883", "Use of DOLRO~ZOSV by VistA HL7 Application Developers", "Routine", "KERNEL", "2003/01/28", "APPROVED", "Active", "Controlled Subscription", "", "
Patch HL*1.6*93 allows application developers to modify
four routing- related fields in the MSH segment of HL7 messages. There are
two ways these changes can be made:\n
(1) Calling GENERATE^HLMA or DIRECT^HLMA with the string literal value to
be used for the routing-related fields, or\n
(2) Call GENERATE^HLMA or DIRECT^HLMA and specify M code to evaluate the
environment and make changes to specified (and a limited number of)
local variables.\n
Even though the M code called by the new HL*1.6*93 software can only make a
limited number of changes to local variables, evaluation of the total local
variable environment is extremely important.\n
The DOLRO^%ZOSV API has been built into the current HL7 software to make it
easier for application developers to perform the necessary evaluation and
actions.", "", "%ZOSV", ""], ["3884", "BUILD CONTROL CODES", "File", "KERNEL", "2003/03/04", "APPROVED", "Active", "Controlled Subscription", "3.2", "
Outpatient Pharmacy V. 7.0 utilizes the CONTROL CODES
field (#55) of the TERMINAL TYPE file (#3.2) in order to provide a generic
print routine that will handle laser labels.\n
There are 30+ control codes to be built in order to properly format the
output. Since standard PCL 5 escape sequences are being used 90% of them will
be the same for every printer. In order to assist sites with building the
control codes, this agreement will allow Outpatient Pharmacy V. 7.0 to provide
a routine to automatically build the control codes.", "", "PSOLLU2", ""], ["3885", "DI OPTIONS/MENUS ON SECURITY OFFICER MENU", "Other", "1", "2003/02/03", "APPROVED", "Active", "Private", "", "
Health Information Security Service is requesting to
place some DI options/menu on INFORMATION SECURITY MENU [XUSPY].\n
DIPRINT on the XUDIACCESS FOR ISO menu. DISEARCH on the XUDIACCESS FOR ISO
menu. DIINQUIRE on the XUDIACCESS FOR ISO menu. DILIST on the XUDIACCESS FOR
ISO menu. DIAUDIT on the XUDIACCESS FOR ISO menu. DIAUDITED FIELDS on the
DIAUDIT menu. DIAUDIT DD on the DIAUDIT menu. DIAUDIT PURGE DATA on the
DIAUDIT menu. DIAUDIT PURGE DD on the DIAUDIT menu. DIAUDIT TURN ON/OFF on
the DIAUDIT menu.", "", "", ""], ["3886", "XM OPTION ON SECURITY OFFICER MENU", "Other", "MAILMAN", "2003/02/03", "APPROVED", "Active", "Private", "", "
Health Information Security Service is requesting to
place a XM option on INFORMATION SECURITY MENU [XUSPY].\n
XM SUPER SEARCH on XUAUDIT MAINT menu.", "", "", ""], ["3887", "LM MPIFCMRP", "Routine", "MASTER PATIENT INDEX VISTA", "2003/02/04", "APPROVED", "Active", "Private", "", "
Patient Data Review List Manager entry point for
pushing the CMOR was requested by the MPI/PD team", "", "MPIFCMRP", ""], ["3888", "GMTSXAL", "Routine", "HEALTH SUMMARY", "2003/02/06", "APPROVED", "Active", "Controlled Subscription", "", "
Get Health Summary Type Parameter List.", "", "GMTSXAL", ""], ["3889", "BCMA GUI REPORTS", "Routine", "BAR CODE MED ADMIN", "2003/02/06", "APPROVED", "Active", "Controlled Subscription", "", "
This Remote Procedure Call returns specific information
for the BCMA report requested.\n
The temp global, ^TMP("PSBO", is where the report text that will be displayed
or printed is returned. Killing of the ^TMP("PSBO" global is permitted with
this integration agreement.", "", "PSBO", ""], ["3890", "BULLETIN LOOKUP AND EDIT", "File", "MAILMAN", "2003/02/11", "APPROVED", "Active", "Supported", "3.6", "
MailMan does not have any APIs which enable a package
to edit its own bulletins. Therefore, for the purpose of editing an existing
bulletin, owned by a package, permission is granted to:\n
1. Look up a bulletin using FileMan's ^DIC, such as $$FIND1^DIC.\n
2. Add/edit data in the bulletin using FileMan's ^DIE, such as UPDATE^DIE or
FILE^DIE.", "", "", ""], ["3891", "This is a Test", "Remote Procedure", "COMMUNICATIONS SERVICE LIBRARY", "2003/02/12", "", "Withdrawn", "Private", "", "", "", "csl", ""], ["3892", "TIU GET ADDITIONAL SIGNERS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET ADDITIONAL SIGNERS", "", ""], ["3893", "GMRC LIST CONSULT REQUESTS", "Remote Procedure", "CONSULT/REQUEST TRACKING", "2003/02/12", "APPROVED", "Active", "Controlled Subscription", "", "", "GMRC LIST CONSULT REQUESTS", "", "2018/01/23"], ["3894", "TIU GET DS URGENCIES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET DS URGENCIES", "", ""], ["3895", "TIU IDENTIFY CONSULTS CLASS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU IDENTIFY CONSULTS CLASS", "", ""], ["3896", "TIU JUSTIFY DELETE?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU JUSTIFY DELETE?", "", ""], ["3897", "TIU LOCK RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU LOCK RECORD", "", ""], ["3898", "TIU LONG LIST CONSULT TITLES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU LONG LIST CONSULT TITLES", "", ""], ["3899", "TIU NOTES 16 BIT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU NOTES 16 BIT", "", ""], ["3900", "TIU UNLOCK RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU UNLOCK RECORD", "", ""], ["3901", "TIU WHICH SIGNATURE ACTION", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU WHICH SIGNATURE ACTION", "", ""], ["3902", "TIU TEMPLATE CHECK BOILERPLATE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE CHECK BOILERPLATE", "", ""], ["3903", "TIU TEMPLATE CREATE/MODIFY", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE CREATE/MODIFY", "", ""], ["3904", "TIU TEMPLATE DELETE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE DELETE", "", ""], ["3905", "TIU TEMPLATE GETPROOT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GETPROOT", "", ""], ["3906", "TIU TEMPLATE LISTOWNR", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE LISTOWNR", "", ""], ["3907", "TIU TEMPLATE SET ITEMS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE SET ITEMS", "", ""], ["3908", "TIU TEMPLATE ACCESS LEVEL", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE ACCESS LEVEL", "", ""], ["3909", "TIU TEMPLATE GET DEFAULTS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GET DEFAULTS", "", ""], ["3910", "TIU TEMPLATE GET DESCRIPTION", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GET DESCRIPTION", "", ""], ["3911", "TIU TEMPLATE SET DEFAULTS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE SET DEFAULTS", "", ""], ["3912", "TIU TEMPLATE PERSONAL OBJECTS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE PERSONAL OBJECTS", "", ""], ["3913", "TIU TEMPLATE LOCK", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE LOCK", "", ""], ["3914", "TIU TEMPLATE GETBOIL", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GETBOIL", "", ""], ["3915", "TIU TEMPLATE GETITEMS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GETITEMS", "", ""], ["3916", "TIU TEMPLATE GETROOTS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GETROOTS", "", ""], ["3917", "TIU TEMPLATE GETTEXT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GETTEXT", "", ""], ["3918", "TIU TEMPLATE ISEDITOR", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE ISEDITOR", "", ""], ["3919", "TIU TEMPLATE UNLOCK", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE UNLOCK", "", ""], ["3920", "TIU TEMPLATE GETLINK", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE GETLINK", "", ""], ["3921", "TIU TEMPLATE ALL TITLES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU TEMPLATE ALL TITLES", "", ""], ["3922", "TIU GET LIST OF OBJECTS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET LIST OF OBJECTS", "", ""], ["3923", "TIU GET DOCUMENT TITLE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET DOCUMENT TITLE", "", ""], ["3924", "TIU GET DEFAULT PROVIDER", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET DEFAULT PROVIDER", "", ""], ["3925", "TIU GET SITE PARAMETERS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET SITE PARAMETERS", "", ""], ["3926", "TIU IS USER A PROVIDER?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU IS USER A PROVIDER?", "", ""], ["3927", "TIU GET PRINT NAME", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET PRINT NAME", "", ""], ["3928", "TIU WAS THIS SAVED?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU WAS THIS SAVED?", "", ""], ["3929", "TIU LONG LIST BOILERPLATED", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU LONG LIST BOILERPLATED", "", ""], ["3930", "TIU GET BOILERPLATE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU GET BOILERPLATE", "", ""], ["3931", "TIU FIELD CAN EDIT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD CAN EDIT", "", ""], ["3932", "TIU FIELD EXPORT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD EXPORT", "", ""], ["3933", "TIU FIELD IMPORT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD IMPORT", "", ""], ["3934", "TIU FIELD LIST", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD LIST", "", ""], ["3935", "TIU FIELD DELETE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD DELETE", "", ""], ["3936", "TIU FIELD LOAD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD LOAD", "", ""], ["3937", "TIU FIELD LOAD BY IEN", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD LOAD BY IEN", "", ""], ["3938", "TIU FIELD LOCK", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD LOCK", "", ""], ["3939", "TIU FIELD NAME IS UNIQUE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD NAME IS UNIQUE", "", ""], ["3940", "TIU FIELD SAVE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD SAVE", "", ""], ["3941", "TIU FIELD UNLOCK", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD UNLOCK", "", ""], ["3942", "TIU REMINDER DIALOGS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU REMINDER DIALOGS", "", ""], ["3943", "TIU REM DLG OK AS TEMPLATE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU REM DLG OK AS TEMPLATE", "", ""], ["3944", "TIU FIELD DOLMTEXT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD DOLMTEXT", "", ""], ["3945", "TIU DIV AND CLASS INFO", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU DIV AND CLASS INFO", "", ""], ["3946", "TIU USER CLASS LONG LIST", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU USER CLASS LONG LIST", "", ""], ["3947", "TIU ID ATTACH ENTRY", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU ID ATTACH ENTRY", "", ""], ["3948", "TIU ID CAN ATTACH", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU ID CAN ATTACH", "", ""], ["3949", "TIU ID CAN RECEIVE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU ID CAN RECEIVE", "", ""], ["3950", "TIU ID DETACH ENTRY", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU ID DETACH ENTRY", "", ""], ["3951", "TIU FIELD CHECK", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD CHECK", "", ""], ["3952", "TIU FIELD LIST ADD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD LIST ADD", "", ""], ["3953", "TIU FIELD LIST IMPORT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU FIELD LIST IMPORT", "", ""], ["3954", "TIU SET DOCUMENT TEXT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU SET DOCUMENT TEXT", "", ""], ["3955", "PSB REPORT", "Remote Procedure", "BAR CODE MED ADMIN", "2003/02/13", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC returns specific information for BCMA reports.\n", "PSB REPORT", "PSBO", ""], ["3956", "YS GAF API", "Remote Procedure", "MENTAL HEALTH", "2003/06/04", "APPROVED", "Active", "Controlled Subscription", "", "", "YS GAF API", "", ""], ["3957", "TIU CALL TO GMRCP513", "Routine", "CONSULT/REQUEST TRACKING", "2003/02/19", "", "Withdrawn", "Private", "", "", "", "GMRCP513", ""], ["3959", "GLOBAL READ OF PXD(811.9", "File", "PCE PATIENT CARE ENCOUNTER", "2003/02/19", "", "Withdrawn", "Private", "811.9", "", "", "", ""], ["3960", "File 811.7", "File", "CLINICAL REMINDERS", "2004/03/02", "APPROVED", "Active", "Controlled Subscription", "811.7", "
This DBIA allows for a global read of the .01 field of
file 811.7.", "", "", ""], ["3962", "File 8925.98", "File", "TEXT INTEGRATION UTILITIES", "2003/07/18", "", "Withdrawn", "Private", "8925.98", "", "", "", ""], ["3963", "File 8926", "File", "TEXT INTEGRATION UTILITIES", "2003/02/19", "", "Withdrawn", "Private", "8926", "", "", "", ""], ["3964", "GMRCP5A", "Routine", "CONSULT/REQUEST TRACKING", "2003/05/15", "APPROVED", "Active", "Private", "", "", "", "GMRCP5A", ""], ["3965", "GMTSADOR", "Routine", "HEALTH SUMMARY", "2003/04/25", "APPROVED", "Active", "Private", "", "", "", "GMTSADOR", ""], ["3966", "TIU IS THIS A SURGERY?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2003/07/16", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU IS THIS A SURGERY?", "", "2014/03/13"], ["3967", "GMTSMCMA", "Routine", "HEALTH SUMMARY", "2003/04/29", "APPROVED", "Active", "Private", "", "", "", "GMTSMCMA", ""], ["3968", "GMTSRAE", "Routine", "HEALTH SUMMARY", "2003/04/29", "APPROVED", "Active", "Private", "", "", "", "GMTSRAE", ""], ["3969", "GMTSROB", "Routine", "HEALTH SUMMARY", "2003/04/25", "APPROVED", "Active", "Controlled Subscription", "", "", "", "GMTSROB", ""], ["3970", "GMTSXAL", "Routine", "HEALTH SUMMARY", "2003/07/29", "", "Retired", "Private", "", "", "", "GMTSXAL", ""], ["3971", "CALL TO IBDF18A", "Routine", "INTEGRATED BILLING", "2003/02/19", "", "Withdrawn", "Private", "", "", "", "IBDF18A", ""], ["3972", "CALL TO LR7OGU", "Routine", "LAB SERVICE", "2004/02/05", "APPROVED", "Active", "Private", "", "", "", "LR7OGU", ""], ["3973", "CALL TO LRAPS3", "Routine", "LAB SERVICE", "2003/02/19", "", "Withdrawn", "Private", "", "", "", "LRAPS3", ""], ["3974", "CALL TO LRBLPD1", "Routine", "LAB SERVICE", "2003/02/19", "", "Withdrawn", "Private", "", "", "", "LRBLPD1", ""], ["3975", "CALL TO PSBO", "Routine", "BAR CODE MED ADMIN", "2003/02/19", "", "Withdrawn", "Private", "", "", "", "PSBO", ""], ["3976", "Screen Default Cosigner selection for USER", "Routine", "TEXT INTEGRATION UTILITIES", "2004/01/16", "APPROVED", "Active", "Private", "", "", "", "TIULA3", ""], ["3977", "Boolean fn to screen selection of classes", "Routine", "TEXT INTEGRATION UTILITIES", "2004/01/16", "APPROVED", "Active", "Private", "", "", "", "TIULA4", ""], ["3978", "CALL TO TIUVSIT", "Routine", "TEXT INTEGRATION UTILITIES", "2004/02/14", "APPROVED", "Active", "Private", "", "", "", "TIUVSIT", ""], ["3979", "YSGAFAP1", "Routine", "MENTAL HEALTH", "2003/02/19", "APPROVED", "Active", "Private", "", "
10/30/13: The recently released Diagnostic and
Statistical Manual of Mental Disorders, Fifth Edition, abbreviated as DSM-5,
eliminates the use of the Global Assessment of Functioning (GAF) score.
Starting with patch YS*5.01*108, new GAF scores for patients will no longer be
saved in the Mental Health package. Historical data will continue to be
available. The ENT call will return the following:\n
YSDATA(1)="[ERROR]"
YSDATA(2)="With DSM 5, no new GAFs allowed"", "", "YSGAFAP1", "2013/11/08"], ["3980", "OR CALL TO YTAPI4", "Routine", "MENTAL HEALTH", "2003/02/19", "", "Withdrawn", "Private", "", "
This API allows scoring of patient responses to a test
or interview without making changes in the M database. The patient ien, the
test code, and administration date is required along with the responses. All
responses are checked for validity. Scoring is returned in the output
documented in the SCOREIT API.", "", "YTAPI4", ""], ["3981", "GLOBAL READ OF 69.51", "File", "LAB SERVICE", "2004/07/28", "APPROVED", "Active", "Private", "69.51", "
Clinical Reminders request permission to do a direct
global read on file # 69.51 "B" cross-reference for the Hep C. EPI Extract
project.", "", "", ""], ["3982", "YTAPI4", "Routine", "MENTAL HEALTH", "2005/01/26", "APPROVED", "Active", "Private", "", "", "", "YTAPI4", ""], ["3983", "DBIA3983", "File", "CONSULT/REQUEST TRACKING", "2003/02/24", "APPROVED", "Active", "Private", "123", "
Patch TIU*1*144, CONSULTS WITH MISMATCHED PATIENTS,
generates a list of TIU Consult documents whose patient differs from the
patient of the associated Consult Request. The site is asked to clean up the
patient mismatches for these documents. So far as we know, the software
errors which created these mismatches have all been corrected, so we expect
this cleanup effort to be a one-time effort, though it may take the site some
time.\n
When displaying these documents in a list, TIU needs to provide enough
information on each document for the site to identify and locate the document
and the associated Consult Request. For this, TIU needs to read fields .02,
1, 5, and 8.\n
Also, TIU needs to identify on the list any documents which are linked on the
Consults side with a request in addition to or different from the request with
which the document is linked on the TIU side. So far as we know, this
situation occurs only when sites have edited file GMR(123 with FileMan. It
causes the appropriate TIU cleanup action, LINK WITH REQUEST, to misbehave.
In such cases, the patch asks sites to request help from NVS. For this, TIU
needs to read the "R" cross-reference on field 50, ASSOCIATED RESULTS.\n
Amendment: Added 10/12/22, effective with patch TIU*1.0*354 the Community Care
Referrals and Authorization (CCRA) project uses the CPRS STATUS field to reset
the status to its original state once a CCRA note is filed with the consult.", "", "", ""], ["3984", "FEE BASIS AUTHORIZATION INFO", "Routine", "FEE BASIS", "2003/03/06", "", "Retired", "Controlled Subscription", "", "", "", "FBGMT2", ""], ["3985", "Direct access to 8989.5 and 8989.51", "File", "TOOLKIT", "2003/02/25", "APPROVED", "Active", "Private", "8989.5", "
As part of the installation of patch OR*3*141 (GUI
v20), 4 CPRS parameters became obsolete and were deleted. However, the
parameters were deleted directly and their corresponding entities were not
removed before the parameters were deleted.\n
Patch OR*3*177 will include a post-init (ORY177) that will go through file
8989.5 and identify any system level entities that are pointing to
non-existent entries in 8989.51. The entries from 8989.5 will then be deleted.\n", "", "", ""], ["3986", "DBIA3986", "Routine", "VENDOR - DOCUMENT STORAGE SYS", "2003/04/09", "APPROVED", "Active", "Private", "", "
The IB package requests use of EN^VEJDIBSC to send a
single bill to the QuadraMed Claims Scrubber. The bill passed to the scrubber
will have passed all IB edits but will not yet be authorized. If the bill
does not pass the scrubber then the bill will not be allowed to be authorized.\n", "", "VEJDIBSC", ""], ["3987", "DBIA3987", "Routine", "VENDOR - DOCUMENT STORAGE SYS", "2003/04/09", "APPROVED", "Active", "Private", "", "
The IB package requests use of DSS/Quadramed calls to
sequence a bill's procedures and assign the CPT codes associated Diagnosis.", "", "VEJDIBE1", ""], ["3988", "Dynamic Routing Header Help Code", "Routine", "HEALTH LEVEL SEVEN", "2003/03/06", "APPROVED", "Active", "Supported", "", "
The Dynamic Routing patch HL*1.6*93 gives application
developers writing calls to the VistA HL7 package's DIRECT^HLMA and
GENERATE^HLMA APIs the ability to directly control the routing-related fields.
These fields are the SENDING APPLICATION (MSH-3), SENDING FACILITY (MSH-4),
RECEIVING APPLICATION (MSH-5), and the RECEIVING FACILITY (MSH-6).\n
Refer to chapter 12 of the VistA HL7 Site Manager and Developer manual for
complete information about the use of the DIRECT^HLMA and the GENERATE^HLMA
APIs.\n
The Dynamic Routing patch HL*1.6*93 expands the data that can be passed into
these APIs to include HLP("SUBSCRIBER") and HLP("SUBSCRIBER",n) local array
entries. When passing HLP("SUBSCRIBER") or HLP("SUBSCRIBER",n) local array
data, an M API created by the application developer can be called to evaluate
the environment and, if appropriate, change the local variables used to create
the routing-related fields in the MSH segment.\n
A new API, M^HLCSHDR4, has been created to assist application developers in
the early stages of using M code to control the routing-related fields in the
MSH segment.\n
When the HLP("SUBSCRIBER") or HLP("SUBSCRIBER",n) local array data references
M^HLCSHDR4, this is how M^HLCSHDR4 is executed, and the actions taken:\n
Step Action and Comments
-------------------------------------------------------------------------
#1 DIRECT^HLMA or GENERATE^HLMA is called, with HLP("SUBSCRIBER") or
HLP("SUBSCRIBER",n) local array defined with a reference to
M^HLCSHDR4.
#2 Execution of DIRECT^HLMA or GENERATE^HLMA code proceeds, coming to
the code that creates the MSH segment.
#3 The HLP("SUBSCRIBER") and HLP("SUBSCRIBER",n) data is evaluated, and
the call to M^HLCSHDR4 is found.
#4 M^HLCSHDR4 is called, and the following actions occur:
- The local variables that will be used in the creation of the
routing-related fields in the MSH segment are displayed,
accompanied with explanation of each variable, it's significance,
and from what source the variable was created.
- Application developer can interactively enter new values for the
routing-related fields.
- If new values are entered, the application developer is informed
on-screen the actions taken by M^HLCSHDR4 based on the newly
entered value for the routing-related field(s). (I.e., the
local variable(s) used in the creation of the routing-related
fields is reset to the new value entered by the developer.)
#5 The MSH segment is built using the routing-related
local variables, (some of which might have been interactively
changed by the developer when answering the M^HLCSHDR4 queries.)
#6 Execution of DIRECT^HLMA or GENERATE^HLMA code proceeds, the MSH
segment and the complete message is created, and all processing of
the message completes.\n
Because of the display of explanatory information by M^HLCSHDR4, and because
the developer is informed of the actions being taken in resetting the
routing-related variables, this API is a valuable training tool.\n
Application developers calling M code via HLP("SUBSCRIBER") or
HLP("SUBSCRIBER",n) are encouraged to use the M^HLCSHDR4 API during the
initial phases of their development. After learning how to use M code to
control the routing-related fields in the MSH segment, developers must remove
the educational M^HLCSHDR4 reference, substituting their own M code API.", "", "HLCSHDR4", ""], ["3989", "NOTIFICATION OF FEE BASIS AITHORIZATION CHANGE", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2003/03/06", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA contains a supported Enrollment API call that
Fee Basis uses to notify Enrollment about every change of the value of the
field "TO DATE" of the file #161 FEE BASIS PATIENT. The DBIA is associated
with Enrollment patch EAS*1.0*25.", "", "EASUER", ""], ["3990", "ICD Code APIs", "Routine", "DRG GROUPER", "2003/03/12", "", "Retired", "Supported", "", "
This agreement contains the references to routine
ICDCODE for the supported APIs. These entry points will retrieve ICD-9 code
related data. For ICD-10 data see routine ICDEX (ICR 5747)\n
All entry points will return
-1^error description in an error condition. in an error condition.\n\n", "", "ICDCODE", "2014/09/04"], ["3991", "ICD Utility APIs", "Routine", "DRG GROUPER", "2003/03/12", "", "Retired", "Supported", "", "
This ICR will be retired upon ICD10 Implementation
(retire action estimated to occur April 1,2016). New development efforts
should use ICR 5747.\n
This contains the references to routine ICDAPIU for the supported APIs to be
released with v.20.0 of ICD.\n
These include extrinsic functions for retieving Code History, performing
Status checks, retrieving Next/Previous Codes, retrieving Dates based on the
Business Rules, and retrieving a notice of a code's textual inaccuracy.", "", "ICDAPIU", ""], ["3992", "DBIA3992", "File", "MAILMAN", "2004/05/05", "", "Pending", "Private", "4.2", "
The API in patch SD*5.3*301 makes a call to the DOMAIN
file (#4.2) to pull the STATION field (#5.5). This AI will allow the
Scheduling software to access this data to provide it to application teams in
the encapsulation process of Scheduling Replacement.", "", "", ""], ["3993", "File 8925", "File", "TEXT INTEGRATION UTILITIES", "2003/03/12", "", "Withdrawn", "Private", "8925", "
Consults $ORDERs thru the "F" x-ref on the ENTRY
DATE/TIME field and $GETs the 5th piece (REQUESTING PACKAGE REFERENCE field)
on the 14 node. It also checks for data on the 0 node.", "", "", ""], ["3994", "File 8925.97", "File", "TEXT INTEGRATION UTILITIES", "2003/03/12", "", "Withdrawn", "Private", "8925.97", "", "", "", ""], ["3995", "File 8989.5", "File", "TOOLKIT", "2003/03/12", "", "Withdrawn", "Private", "8989.5", "", "", "", ""], ["3996", "GMV ADD VM", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: GMV ADD VM
TAG: EN1
ROUTINE: GMVDCSAV
RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
This remote procedure call is used to enter a new Vital/Measurement
record in the GMRV Vital Measurement file (#120.5).\n
This remote procedure call is documented in Integration Agreement 3996.
INPUT PARAMETER: GMRVDATA
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 255
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
This variable contains the data needed to create a Vital/Measurement
record in the GMRV Vital Measurement (#120.5) file. The values are parsed
out of the GMRVDATA variable and filed.\n
GMRVDATA has the following data:
piece1^piece2^piece3^piece4^piece5\n
where:
piece1 = date/time in FileMan internal format
piece2 = patient number from FILE 2 (i.e., DFN)
piece3 = vital type, a semi-colon, the reading, a semi-colon, and
oxygen flow rate and percentage values [optional] (e.g.,
21;99;1 l/min 90%)
piece4 = hospital location (FILE 44) pointer value
piece5 = user number from FILE 200 (i.e., DUZ), an asterisk, and the
qualifier (File 120.52) internal entry numbers separated by
colons (e.g., 547*50:65)
RETURN PARAMETER DESCRIPTION:
RESULT does not return a value.\n
The data is filed in the GMRV VITAL MEASUREMENT (#120.5) file.\n
Example:\n
> S GMRVDATA="3051011.1635^134^1;120/80;^67^87*2:38:50:75"
> D EN1^GMVDCSAV(.RESULT,GMRVDATA)", "GMV ADD VM", "", ""], ["3997", "File 9999999.27", "File", "PROBLEM LIST", "2003/03/12", "", "Withdrawn", "Private", "9999999.27", "", "", "", ""], ["3998", "File 405", "File", "REGISTRATION", "2003/03/12", "", "Withdrawn", "Private", "405", "", "", "", ""], ["3999", "PSB INSTRUCTOR", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "\n\n", "PSB INSTRUCTOR", "", ""], ["4000", "PSB CHECK SERVER", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "\n\n", "PSB CHECK SERVER", "", ""], ["4001", "XTMP('ORLK'", "Other", "ORDER ENTRY/RESULTS REPORTING", "2003/04/01", "APPROVED", "Active", "Private", "", "
Background: DBIA #867 is not usable. The existing
process of protecting orders in OE/RR by using a system of locks on the order
file is not usable due to the limited capacity of the lock tables and the
number of prescriptions that are in CONSOLIDATED MAIL OUTPATIENT PHARMACY
(CMOP) transmissions.\n
CMOP is given direct write and read permission of the ^XTMP("ORLK-"_ORDER)\n
global.\n
CMOP will set for each prescription RXIEN:\n
where ORDER=+$P($G(^PSRX(RXIEN,"OR1")),"^",2)\n
1. S NOW=$$NOW^XLFDT,NOW1=$$FMADD^XLFDT(NOW,1) 2. S
^XTMP("ORLK-"_+ORDER,0)=NOW1_U_NOW_"^CPRS/CMOP Order Lock",^(1)=DUZ_U_$J\n
^XTMP("ORLK-14913",0) = 3030328.104006^3030327.104006^CPRS/CMOP Order Lock
^XTMP("ORLK-14913",1) = 11872^541086169\n
CMOP will delete ^XTMP("ORLK-"_+ORDER) when each transmission completes. CMOP
recovery will include clearing entries from ^XTMP("ORLK"_+ORDER) if
^(0)["CPRS/CMOP"\n
CPRS/OERR will include in calls to $$LOCK1^ORX2(order ien), the test of
existence of ^XTMP("ORLK-"_+ORDER,0) and if it exists with (^0) containing
"CPRS/CMOP", will return "0^CMOP Transmission".", "", "", ""], ["4002", "PSB USERLOAD", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "\n
(0) = -1^Error Description\n
or\n
(0) = DUZ
(1) = User name
(2) = Student Key Flag
(3) = Manager Key flag
(4) = CPRS Med Order Button Key Flag
(5) = Window settings
Window Left
Window Height
Window Top
Window Width
(6) = Virtual Due List Setup
(7) = Division number ^ Site ID ^ (if production system "1", if test
system "0")
(8) = Division name
(9) = ESIG flag
(10) = BCMA Online flag
(11) = Time
(12) = Unit Dose column widths
(13) = Check digit
(14) = IVPB column widths
(15) = IV column widths
(16) = Printer user default IEN
(17) = Printer user default IEN^Name
(18) = Read Only Security Key flag
(19) = User's preference per Coversheet Views' column sort
Medication Overview sort col #_ /
PRN Overview sort col #_ /
IV Overview sort col #_ /
Expired/Expiring sort col #
(20) = User's preference per Coversheet View1 columns' widths
(21) = User's preference per Coversheet View2 columns' widths\n
(22) = User's preference per Coversheet View3 columns' widths\n
(23) = User's preference per Coversheet View4 columns' widths
(24) = BCMA Managing Scanning Failure Security Flag ( 1 if user holds
BCMA MSF key, 0 if not )
(25) = 5 Rights Override/Unit Dose Administration Flag (0 = no override,
1 = override) [PSB FR UNIT DOSE OVERRIDE]
(26) = 5 Rights Override/IV Administration Flag (0 = no override, 1 =
override) [PSB FR IV OVERRIDE]", "PSB USERLOAD", "", "2008/12/08"], ["4003", "PSB PARAMETER", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB PARAMETER", "", ""], ["4004", "PSB SERVER CLOCK VARIANCE", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB SERVER CLOCK VARIANCE", "", ""], ["4005", "PSB SCANPT", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "
If no patient or multiple patients are found with the
scan value an error is returned in the following format:\n
Results[0] = 1
Results[1] = '-1^Unable to Determine Patient ID'\n
If a unique patient is found the following data is returned to the user:\n
Results[0] = Count of returned records\n
In the case of an error:
Results[1] = '-1^ "the appropriate error message" '\n
Results[1] = DFN
Results[2] = Name
Results[3] = SSN^Dashed SSN
Results[4] = Internal DOB^External DOB
Results[5] = Age
Results[6] = Internal Sex^External Sex
Results[7] = Internal Last Mvmt^External Last Mvmt
Results[8] = Internal Type Mvmt^External Type Mvmt
Results[9] = Internal Ward Location^External Ward Location^
Internal Hospital Location^External Hospital Location
Results[10] = Internal Bed Location^External Bed Location
Results[11] = Internal P-Care Physician^External P-Care Physician
Results[12] = Internal Treating Speciality^
External Treating Speciality
Results[13] = Movement Diagnosis
Results[14] = 1 if in Bed Status 0 if not in Bed Status (i.e. Pass)
Results[15] = Expected return date from Pass
Results[16] = Reactions
Results[17] = Height
Results[18] = Weight
Results[19] = Means Tests
Results[20] = ICN umber
Results[21] = " Admission Status message "
Results[22] = This NODE begins 'other' patient information.
This NODE may be null. Records on this NODE will
have a header. A header will consist of one of the
following:\n\n
"PATFLG"\n
The PATFLG header will initiate a patient
flag record. The patient flag record will
be constructed as follows:
"PATFLG" ^ FLAG NAME ^ index#", "PSB SCANPT", "", ""], ["4006", "File 40.8", "File", "REGISTRATION", "2003/03/18", "", "Withdrawn", "Private", "40.8", "", "", "", ""], ["4007", "File 45.7", "File", "REGISTRATION", "2003/03/18", "", "Withdrawn", "Private", "45.7", "", "", "", ""], ["4008", "File 63", "File", "LAB SERVICE", "2003/03/18", "", "Withdrawn", "Private", "63", "", "", "", ""], ["4009", "File 2005", "File", "IMAGING", "2003/03/18", "", "Withdrawn", "Private", "2005", "", "", "", ""], ["4011", "File 8994", "File", "KERNEL", "2006/01/19", "APPROVED", "Active", "Controlled Subscription", "8994", "
Permission to add or delete entries via FM APIs.", "", "", ""], ["4012", "File 9.8", "File", "KERNEL", "2003/03/18", "", "Withdrawn", "Private", "9.8", "", "", "", ""], ["4013", "File 9000001", "File", "PCE PATIENT CARE ENCOUNTER", "2003/03/18", "", "Withdrawn", "Private", "9000001", "", "", "", ""], ["4014", "File 9999999.06", "File", "PCE PATIENT CARE ENCOUNTER", "2003/03/18", "", "Withdrawn", "Private", "9999999.06", "", "", "", ""], ["4015", "File 405.3", "File", "REGISTRATION", "2003/03/18", "", "Withdrawn", "Private", "405.3", "", "", "", ""], ["4016", "File 405.4", "File", "REGISTRATION", "2003/03/18", "", "Withdrawn", "Private", "405.4", "", "", "", ""], ["4017", "File 8927.1", "File", "1", "2003/03/18", "", "Withdrawn", "Private", "8927.1", "", "", "", ""], ["4018", "File 45.6", "File", "REGISTRATION", "2003/03/18", "", "Withdrawn", "Controlled Subscription", "45.6", "", "", "", ""], ["4020", "DBIA4020", "File", "MAILMAN", "2004/05/05", "", "Pending", "Private", "4.3", "
The API in patch SD*5.3*301 makes a call to the MAILMAN
SITE PARAMETERS file (#4.3) to pull the NAME field (#.01). This AI will allow
the Scheduling software to access this data to provide it to application teams
in the encapsulation process of Scheduling Replacement.", "", "", ""], ["4021", "OR call to GMRVSC0", "Routine", "GEN. MED. REC. - VITALS", "2003/03/18", "", "Withdrawn", "Private", "", "", "", "GMRVSR0", ""], ["4022", "OR call to GMRPNOR1", "Routine", "TEXT INTEGRATION UTILITIES", "2003/03/18", "", "Withdrawn", "Private", "", "", "", "GMRPNOR1", ""], ["4023", "OR call to GMRVSR0", "Routine", "GEN. MED. REC. - VITALS", "2003/03/18", "", "Withdrawn", "Private", "", "", "", "GMRVSR0", ""], ["4024", "OR call to GMRVUTL", "Routine", "GEN. MED. REC. - VITALS", "2003/03/18", "", "Withdrawn", "Private", "", "", "", "GMRVUTL", ""], ["4025", "GMTS reference to 55", "File", "PHARMACY DATA MANAGEMENT", "2003/03/18", "", "Withdrawn", "Private", "55", "", "", "", ""], ["4026", "PSB ALLERGY", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB ALLERGY", "", ""], ["4027", "PSB GETORDERTAB", "Remote Procedure", "BAR CODE MED ADMIN", "2003/03/25", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB GETORDERTAB", "", ""], ["4028", "PSB FMDATE", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB FMDATE", "", ""], ["4029", "PSB VALIDATE ORDER", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB VALIDATE ORDER", "", ""], ["4030", "PSB SCANMED", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB SCANMED", "", ""], ["4031", "PSB TRANSACTION", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB TRANSACTION", "", ""], ["4032", "PSB SUBMIT MISSING DOSE", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB SUBMIT MISSING DOSE", "", ""], ["4033", "PSB GETPRNS", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB GETPRNS", "", ""], ["4034", "PSB IV ORDER HISTORY", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB IV ORDER HISTORY", "", ""], ["4035", "PSB BAG DETAIL", "Remote Procedure", "BAR CODE MED ADMIN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB BAG DETAIL", "", ""], ["4036", "XMAPHOST User Interactions", "Routine", "MAILMAN", "2003/03/25", "APPROVED", "Active", "Private", "", "
Kernel requests an IA to use entry points in routine
XMAPHOST to be called by routine ZISPL, which converts spool documents to mail
messages.", "", "XMAPHOST", ""], ["4037", "File 8925.9", "File", "TEXT INTEGRATION UTILITIES", "2003/08/04", "APPROVED", "Active", "Private", "8925.9", "
Order Entry $ORDERs thru the B x-ref and $GETs the 6th
piece of the 0 node, the ICD9 DIAGNOSIS field.", "", "", ""], ["4038", "OR reference to file 1", "File", "KERNEL", "2003/03/26", "", "Withdrawn", "Private", "1", "", "", "", ""], ["4040", "TIU reference to file 405.1", "File", "REGISTRATION", "2003/03/26", "", "Withdrawn", "Private", "405.1", "", "", "", ""], ["4041", "OR call to YTAPI5", "Routine", "MENTAL HEALTH", "2003/03/26", "", "Withdrawn", "Private", "", "", "", "YTAPI5", ""], ["4042", "DBIA4042", "Routine", "INTEGRATED BILLING", "2003/04/10", "APPROVED", "Active", "Private", "", "
File 361.1 EXPLANATION OF BENEFITS is shared by
Accounts Receivable and Integrated Billing. While A/R has full read access to
the data in this file, adding the data and updating it require entrypoints in
Integrated Billing. There are also certain standard functions that are
needed/used by both Integrated Billing and Accounts Receivable to manipulate
the data in this file. AR would like to be able to use these functions.", "", "IBCEOB", ""], ["4043", "DBIA4043", "Routine", "ACCOUNTS RECEIVABLE", "2003/04/02", "APPROVED", "Active", "Private", "", "
It has been decided that an auto-audit of bills in AR
should be performed when certain electronic claim status messages are received
in IB. A new entrypoint is needed with AR to accomplish this.\n
ACTION NEEDED: PERFORM AUTO-AUDIT OF A SPECIFIC BILL IN AR", "", "PRCAUDT", ""], ["4044", "DBIA4044", "Routine", "INTEGRATED BILLING", "2003/04/08", "APPROVED", "Active", "Private", "", "
Return the data from an EOB in a display format.", "", "IBCECSA6", ""], ["4045", "DBIA4045", "Routine", "INTEGRATED BILLING", "2003/04/14", "APPROVED", "Active", "Private", "", "
An entrypoint is needed by A/R to access the TPJI
(Third Party Joint Inquiry) option from a PROTOCOL action. The level of entry
needs to be at the point where a bill number can be assumed and the
appropriate TPJI list manager screen will be invoked. This entry point
already exists at line EN^IBJTCA and A/R would like to have access to this
call.", "", "IBJTCA", ""], ["4046", "TIU DOCUMENTS", "Routine", "TEXT INTEGRATION UTILITIES", "2003/04/09", "APPROVED", "Active", "Private", "", "
For CPRS Query application, user is allowed to run a
query to retrieve the TIU document results by specifying the document date
range, document class, document title etc. An existed TIU API QUERY^TIUQRY
need to be called to return all of the TIU document query results.", "", "TIUQRY", ""], ["4047", "DBIA4047", "Routine", "INTEGRATED BILLING", "2003/04/09", "APPROVED", "Active", "Private", "", "
Entrypoint to invoke the Cancel/Edit/Add Patient
Charges option from Accounts Receivable ERA Worklist option.", "", "IBECEA", ""], ["4048", "DBIA4048", "Routine", "INTEGRATED BILLING", "2003/04/11", "APPROVED", "Active", "Private", "", "
Entrypoint to invoke the LIST ON HOLD CHARGES option
from Accounts Receivable ERA Worklist option.", "", "IBOHPT1", ""], ["4049", "DBIA4049", "File", "INTEGRATED BILLING", "2003/04/07", "", "Retired", "Private", "350.9", "
When an electronic EOB is received in error at a site,
EDI Lockbox has functionality to transfer that EOB electronically to another
site. The AGENT CASHIER PHONE NUMBER field contains the contact information
for the receiving site to use to contact the sending site if there are
questions regarding the EOB. Accounts Receivable needs to have read access to
this data to allow it to be included in the transferred EOB.", "", "", ""], ["4050", "DBIA4050", "Routine", "INTEGRATED BILLING", "2003/04/07", "APPROVED", "Active", "Private", "", "
File 361.1 EXPLANATION OF BENEFITS is shared by
Accounts Receivable and Integrated Billing. When an EOB is applied to A/R
bills, sometimes a payment is made to the wrong bill or the payment is made to
one bill and it should have been split between multiple bills. In order to
keep the AR system in balance with the EOBs on file in file 361.1, AR needs to
update the AR AMOUNTS DISTRIBUTION field in this file. This IA is requested
for an entrypoint to a call within IB to allow A/R to update this data in file
361.1, field 8 AR DISTRIBUTION AMOUNTS (multiple field).", "", "IBCEOBAR", ""], ["4051", "DBIA4051", "File", "INTEGRATED BILLING", "2003/04/07", "APPROVED", "Active", "Private", "361.1", "
File 361.1 EXPLANATION OF BENEFITS is used by
Integrated Billing to store Electronic Remittance Advices (ERA) that are
received electronically from MEDICARE (MRAs). The Accounts Receivable system
will be receiving Electronic Remittance Advices from payers other than
MEDICARE via the Third Party Lockbox system. The file is currently structured
to allow both types of ERAs to be stored, so it was decided to use the same
file to store the data, since the data for both is derived from an X12 835
message and is delivered to VistA using the same file format. As a result of
this decision, this IA is requested to allow Accounts Receivable to have full
direct read access and the ability to use Fileman to define a field as a
pointer to this file so it can access the data for functions specific to AR
needs.", "", "", ""], ["4052", "DRG Code APIs", "Routine", "DRG GROUPER", "2003/07/14", "APPROVED", "Active", "Private", "", "", "", "ICDGTDRG", ""], ["4053", "DBIA4053", "Routine", "RPC BROKER", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "XWBSEC", ""], ["4054", "DBIA4054", "Routine", "KERNEL", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "XUSRB", ""], ["4055", "DBIA4055", "Routine", "KERNEL", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "XUSRB2", ""], ["4056", "DBIA4056", "Routine", "KERNEL", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "
VistaLink requests use of the following API:\n
GETPEER^%ZOSV\n
The VistaLink security module uses this to retrieve an IP address value for
the current session, which is required as input (in the XWBTIP variable) into
another call, SETUP^XUSRB.", "", "%ZOSV", ""], ["4057", "DBIA4057", "Routine", "KERNEL", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "", "", "XUS2", ""], ["4058", "DBIA4058", "File", "KERNEL", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "200", "", "", "", ""], ["4059", "DBIA4059", "Other", "RPC BROKER", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "", "
VistaLink requests permission to set, check and kill
the local variables XQY and XQY0 which represent a user's RPC Broker context.", "", "", ""], ["4060", "DBIA4060", "Routine", "KERNEL", "2003/05/29", "APPROVED", "Active", "Private", "", "
VistaLink wishes to use the Kernel entry point
$$AUTOXWB^XUS1B to support Kernel auto-signon.", "", "XUS1B", ""], ["4061", "DBIA4061", "Routine", "KERNEL", "2003/06/04", "APPROVED", "Active", "Private", "", "
VistaLink wishes to use two calls, NOW^XUSRB and
$$POST^XUSRB, to complete Kernel auto-signon for users that pass the initial
auto-signon check ($$AUTOXWB^XUS1B).", "", "XUSRB", ""], ["4069", "HL7 MESSAGE TEXT FILE (#772)", "File", "HEALTH LEVEL SEVEN", "2003/04/01", "APPROVED", "Active", "Controlled Subscription", "772", "
This integration agreement will be used for all
references to all structures in the HL7 Message Text File (#772) file. Each
reference by package is included in the SUBSCRIBING DETAILS for each
subscribing package.\n
As new requests to this file are received and accepted by the VistA HL7
development staff, this integration agreement will be updated.", "", "", "2007/01/24"], ["4071", "4071", "Routine", "OUTPATIENT PHARMACY", "2003/04/01", "APPROVED", "Active", "Private", "", "", "", "PSOLBL3", ""], ["4072", "Access to TIU STATUS file", "File", "TEXT INTEGRATION UTILITIES", "2003/04/10", "APPROVED", "Active", "Controlled Subscription", "8925.6", "
Users using CPRS Query application are allowed to query
TIU document results by defining the query categories such as document status,
document class etc. In order to present users the list of document statuses
for selection, the access to the "TIU STATUS" file is needed.", "", "ORRHCT", ""], ["4073", "XUS GET TOKEN", "Other", "RPC BROKER", "2003/04/03", "APPROVED", "Active", "Private", "", "
From inside CPRS, the Event Capture Interface could be
launched without presenting the scond log on window for user(so called silent
sign-on). In order to fulfill it, CPRS need to call broker's RPC "XUS GET
TOKEN" to get application handle and pass this handle to the Event Capture for
silent log on. Because the RPC "XUS GET TOKEN" is not automatically available
to the CPRS user, OE/RR has to export this RPC into the CPRS menu option "OR
CPRS GUI CHART" to avoid missing RPC error when launching Event Capture
Interface application.\n
CPRS will insert RPC "XUS GET TOKEN" into "OR CPRS GUI CHART" menu option by
following code: EN ; N RPC,MENU
S RPC="XUS GET TOKEN"
S MENU="OR CPRS GUI CHART"
D INSERT(MENU,RPC)
Q
;
INSERT(OPTION,RPC) ; Call FM Updater with each RPC
; Input -- OPTION Option file (#19) Name field (#.01)
; RPC RPC sub-file (#19.05) RPC field (#.01)
; Output -- None
N FDA,FDAIEN,ERR,DIERR
S FDA(19,"?1,",.01)=OPTION
S FDA(19.05,"?+2,?1,",.01)=RPC
D UPDATE^DIE("E","FDA","FDAIEN","ERR")
Q\n
Will no longer be needed after release of XWB*1.1*30.", "XUS GET TOKEN", "", ""], ["4074", "OR Call to PSJORUT2", "Routine", "INPATIENT MEDICATIONS", "2003/04/02", "APPROVED", "Active", "Private", "", "
This API is intended for use only for Med Order Button
IV Orders. It will return the list of valid Additives and Solutions to CPRS
for the creation of an IV Order.", "", "PSJORUT2", "2008/07/28"], ["4075", "OR CALL TO TIUSRVP", "Routine", "TEXT INTEGRATION UTILITIES", "2004/03/02", "APPROVED", "Active", "Private", "", "", "", "TIUSRVP", ""], ["4076", "TIU Reference to file DGPM", "File", "REGISTRATION", "2004/08/16", "APPROVED", "Active", "Private", "405", "", "", "", ""], ["4077", "OR Call to XQORM1", "Routine", "KERNEL", "2003/04/02", "", "Withdrawn", "Private", "", "", "", "XQORM1", ""], ["4078", "ID Node in PATIENT (#2) file, field 994", "File", "1", "2003/04/09", "APPROVED", "Active", "Private", "2", "\n
DG*5.3*505 exports a new field, MULTIPLE BIRTH INDICATOR (#994), to the
PATIENT (#2) file. This field is to be an identifier.\n
KIDS does not automatically export the identifier on the new field, as
it is distributed in a partial DD.\n
The post-init routine, DG505PST, will set the "ID" node:\n
DG505PST --
;BIR/PTD-PATCH DG*5.3*505 POST INSTALLATION ROUTINE ;4/7/03
;;5.3;Registration;**505**;Aug 13, 1993
;
EN ;Entry point
;Update identifier code for MULTIPLE BIRTH INDICATOR (#994) field
in PATIENT (#2) file
D BMES^XPDUTL(" Updating the identifier code for the MULTIPLE
BIRTH INDICATOR (#994) field.")
S ^DD(2,0,"ID",994)="D EN^DDIOL($$GET1^DIQ(2,Y_"","",994),"""",
""?$X+2"")"
Q
;", "", "", ""], ["4079", "Edit PATIENT (#2) file fields", "File", "REGISTRATION", "2003/04/08", "APPROVED", "Active", "Private", "2", "\n
To support the MPI Changes Project - Iteration One, selected identifying
fields in the PATIENT (#2) file must be asked before the query to the MPI
system. This allows these fields to be available to be used in an enhanced
matching algorithm.\n
Therefore, Master Patient Index Vista requests permission to add the
following PATIENT (#2) file fields to the API that is currently called
from the various registration options where this functionality is needed.\n
The code added to routine ^MPIFAPI does the following.
1. check for variable MPIFS - if it exists, don't ask anything since
this is from the background job for SmartCard.
2. check for variable DGNEW
If $G(DGNEW)=1, this is registration of a new patient; only ask
for the following fields since NAME, DOB, SEX, SSN, MULTIPLE
BIRTH INDICATOR have just been asked.
MOTHER'S MAIDEN NAME
PLACE OF BIRTH [CITY]
PLACE OF BIRTH [STATE]
ALIAS
If DGNEW="" or doesn't exist, this is an existing patient; so
also ask/verify the following fields.
NAME
DATE OF BIRTH
SEX
SOCIAL SECURITY NUMBER
MULTIPLE BIRTH INDICATOR\n", "", "", ""], ["4080", "BAD ADDRESS INDICATOR", "Routine", "REGISTRATION", "2003/04/09", "APPROVED", "Active", "Supported", "", "
This DBIA will allow applications outside of
Registration to access the Bad Address Indicator field added with patch
DG*5.3*506. This should help prevent the mailing of medication and other
correspondence to known bad addresses, and will also prevent Bad Addresses
from being shared with other facilities through the Health Eligibility Center
(via Z07/Z05 messaging).", "", "DGUTL3", ""], ["4081", "Advanced Directives Query", "File", "TEXT INTEGRATION UTILITIES", "2003/04/25", "APPROVED", "Active", "Private", "8925", "
We have been tasked to report the total 30-day count of
advanced directives at sites and to compare that count to the Imaging packages
"scanned" Advanced directives. This report is to be used by Vista
administrators as a productivity tool (metric) and has been requested by Laura
Miller, the VHA's Deputy under-secretary of Health. I have a server job that
runs on the 15th of every month that gathers a comprehensive set of Vista
activity values that includes Images captured and displayed, software version
numbers, patient counts, provider counts, image types. My plan is to use
this server methodology to deliver the advanced directives counts to our local
account that rolls up this data into a viewable database.", "", "", ""], ["4082", "Access to TIU DOCUMENT DEFINITION file", "File", "TEXT INTEGRATION UTILITIES", "2003/04/10", "APPROVED", "Active", "Private", "8925.1", "
Users using CPRS Query application are allowed to query
TIU document results by defining the query categories such as document status,
document class etc. In order to present users the list of TIU document
classes for selection, the access to "TIU DOCUMENT DEFINITION" file is needed", "", "", ""], ["4083", "LEXICON CODE STATUS", "Routine", "LEXICON UTILITY", "2003/04/14", "APPROVED", "Active", "Supported", "", "", "", "LEXSRC2", "2008/09/18"], ["4084", "FILE 44 AC X-REF", "File", "SCHEDULING", "2003/04/30", "APPROVED", "Active", "Controlled Subscription", "44", "
This agreement allows permission to loop through the AC
cross-reference on the HOSPITAL LOCATION file (#44). The AC cross-reference is
on the TYPE EXTENSION field (#2.1). Using the AC cross-reference will allow us
to get the internal entry numbers (IENs) for locations by their type (e.g.,
retrieve only clinics). Using the AC cross-reference will speed up the
retrieval of IENs.", "", "", "2007/01/31"], ["4085", "DBIA4085", "File", "RPC BROKER", "2003/04/30", "", "Withdrawn", "Private", "", "", "", "", ""], ["4086", "MODIFY OPTION SCHEDULING FILE FIELDS", "File", "KERNEL", "2003/05/05", "APPROVED", "Active", "Controlled Subscription", "19.2", "
Add VistALink option XOBV LISTENER STARTUP to the
OPTIONS SCHEDULING file (#19.2) during the post-installation phase of the
VistALink package. Also, perform a lookup on the "B" cross reference of the
new entry, and as part of the post-installation display this record's zero
node.\n
Revision History:
- 2/28/25, effective with DVBA*2.7*253, added new OTHER PARAMETERS (#10)
multiple, and the VARIABLE NAME (#.01) and VALUE (#1) fields, where field
content can be added, modified or removed when the package owns the namespaced
entry being modified.", "", "", ""], ["4087", "DBIA4087", "File", "KERNEL", "2003/05/05", "APPROVED", "Active", "Private", "14.7", "
Perform a "B" cross reference lookup on the BOX-VOLUME
PAIR field of the TASKMAN SITE PARAMETERS file (#14.7) to obtain the
BOX-VOLUME pair for the current system. This will be used to lookup the
correct entry in the VISTALINK SITE PARAMETERS file (#18.01) prior to starting
a VistALink Listener configuration on a Cache-NT system.", "", "", ""], ["4088", "DBIA4088", "File", "KERNEL", "2003/05/15", "APPROVED", "Active", "Private", "8989.3", "
Perform a lookup on the "B" cross reference of the
VOLUME SET sub-field (#.01) within the VOLUME SET multiple (#8989.304) of the
KERNEL SITE PARAMETERS file (#8989.3) to obtain the volume set. This will be
used as an input variable (XUVOL) to the call $$INHIBIT^XUSRB() to determine
if a new process can be started.", "", "", ""], ["4089", "DBIA4089", "Other", "KERNEL", "2003/05/05", "APPROVED", "Active", "Private", "", "
During the installation of the VistALink package, add
the Foundations Management submenu to the Operations Management menu under the
Systems Manager (EVE) menu.", "", "", ""], ["4090", "VISTALINK SUPPORTED CALLS", "Routine", "VISTALINK", "2003/06/16", "APPROVED", "Active", "Supported", "", "
Supported reference to allow other packages to access
VistALink application developer calls. These calls address XML processing and
RPC timeout handling.\n
XML processing call tags
========================
$$XMLHDR()
$$CHARCHK(STR)\n
RPC timeout handling call tags
==============================
$$STOP()
$$GETTO()
$$SETTO(TO)", "", "XOBVLIB", ""], ["4092", "COREFLS INTERFACE UPDATES", "Routine", "FEE BASIS", "2003/04/29", "APPROVED", "Retired", "Private", "", "
CSL will need to call several Fee Basis APIs for the
processing of authorization and payment documents and records. Depending on
the HL7 message event, the respective API will be invoked by the subscribing
package (CSL) after receiving and processing the HL7 message exported to VistA
by CoreFLS.", "", "FBCSL01", ""], ["4093", "Setting ID node (file #392.31)", "File", "1", "2003/04/24", "APPROVED", "Active", "Private", "392.31", "
Beneficiary Travel would like to add a hard-set routine
call in the "ID" node of the ^DD file of #392.31. This hard-set routine call
will display phone, fax, and address information needed to distinguish between
like vendors. The variable Y will be used as the input variable and the
EN^DDIOL call will be used to output the information. Hard-set in the ^DD
will look like the following:\n
^DD(392.31,0,"ID","Z") = G START^DGBTID\n
With the letter 'I' being placed in the 2nd piece of the File Header:\n
^DGBT(392.31,0) = LOCAL VENDOR^392.31OI^12^11", "", "", ""], ["4094", "Advanced Directives Query", "File", "TEXT INTEGRATION UTILITIES", "2003/04/25", "APPROVED", "Active", "Controlled Subscription", "8925.1", "
We have been tasked to report the total 30-day count of
advanced directives at sites and to compare that count to the Imaging packages
"scanned" Advanced directives. This report is to be used by Vista
administrators as a productivity tool (metric) and has been requested by Laura
Miller, the VHA's Deputy under-secretary of Health. I have a server job that
runs on the 15th of every month that gathers a comprehensive set of Vista
activity values that includes Images captured and displayed, software version
numbers, patient counts, provider counts, image types. My plan is to use this
server methodology to deliver the advanced directives counts to our local
account that rolls up this data into a viewable database.", "", "", ""], ["4095", "Advanced Directives Query", "File", "TEXT INTEGRATION UTILITIES", "2003/04/25", "APPROVED", "Active", "Controlled Subscription", "8925.6", "
We have been tasked to report the total 30-day count of
advanced directives at sites and to compare that count to the Imaging packages
"scanned" Advanced directives. This report is to be used by Vista
administrators as a productivity tool (metric) and has been requested by Laura
Miller, the VHA's Deputy under-secretary of Health. I have a server job that
runs on the 15th of every month that gathers a comprehensive set of Vista
activity values that includes Images captured and displayed, software version
numbers, patient counts, provider counts, image types. My plan is to use this
server methodology to deliver the advanced directives counts to our local
account that rolls up this data into a viewable database.", "", "", ""], ["4097", "CLINICAL REMINDER DIALOG EXCLUDE FROM PROGRESS NOTE", "File", "CLINICAL REMINDERS", "2003/05/05", "APPROVED", "Active", "Controlled Subscription", "801.41", "
Order entry request the ability to do a direct read on
Reminder Dialog File, file number 801.41, fields' numbers four and 51. Order
Entry also requests the ability to do a direct set to field number 23.", "", "", ""], ["4098", "PSSPOIDT", "Routine", "PHARMACY DATA MANAGEMENT", "2003/05/19", "APPROVED", "Active", "Private", "", "
Allow CPRS to use EN1^PSSPOIDT during the
post-installation of patch OR*3*176. EN1^PSSPOIDT will update CPRS files to
be in synch with Pharmacy files for the Herbal/OTC/Non-VA Meds project.", "", "PSSPOIDT", ""], ["4099", "PHARMACY ORDERABLE ITEM FILE", "File", "PHARMACY DATA MANAGEMENT", "2003/05/05", "", "Pending", "Private", "50.7", "
Allow CPRS to use the Pharmacy Orderable Item file
[^PS(50.7] during the post-installation of patch OR*3*176. OR*3*176 post-init
routine ORY176 loops through ^PS(50.7 for each call into EN1^PSSPOIDT to synch
CPRS files with Pharmacy files for the Herbal/OTC/Non-VA Meds project.", "", "", ""], ["4100", "XQALERT1", "Routine", "KERNEL", "2003/05/19", "APPROVED", "Active", "Controlled Subscription", "", "", "", "XQALERT1", ""], ["4101", "WVSITE", "Routine", "WOMEN'S HEALTH", "2003/11/18", "APPROVED", "Active", "Private", "", "", "", "WVSITE", ""], ["4102", "WVALERTS", "Routine", "WOMEN'S HEALTH", "2003/11/18", "APPROVED", "Active", "Private", "", "", "", "WVALERTS", ""], ["4103", "WVRPCNO1", "Routine", "WOMEN'S HEALTH", "2003/11/18", "APPROVED", "Active", "Private", "", "", "", "WVRPCNO1", ""], ["4104", "WVRPCNO", "Routine", "WOMEN'S HEALTH", "2003/11/18", "APPROVED", "Active", "Private", "", "", "", "WVRPCNO", ""], ["4105", "WVRPCPR", "Routine", "WOMEN'S HEALTH", "2003/11/18", "APPROVED", "Active", "Private", "", "", "", "WVRPCPR", ""], ["4106", "WVALERTF", "Routine", "WOMEN'S HEALTH", "2003/10/06", "APPROVED", "Active", "Private", "", "", "", "WVALERTF", ""], ["4107", "DBIA4107", "File", "WOMEN'S HEALTH", "2003/05/06", "", "Pending", "Private", "790.403", "", "", "", ""], ["4108", "DBIA4108", "File", "WOMEN'S HEALTH", "2004/07/02", "APPROVED", "Active", "Private", "790.404", "", "", "", ""], ["4109", "ACTIVATE DOCUMENT DEFINITIONS", "Routine", "TEXT INTEGRATION UTILITIES", "2003/05/15", "APPROVED", "Active", "Private", "", "
In some patches, TIU exports new Document Definitions,
and a companion USR patch exports a new User Class and new Business Rules on
the new Document Definitions and User Class. USR would like to be able to
activate these new Document Definitions AFTER the Business Rules have been
installed successfully.", "", "TIULG", ""], ["4110", "Imaging Consults", "File", "CONSULT/REQUEST TRACKING", "2003/07/31", "APPROVED", "Active", "Controlled Subscription", "123", "
Imaging reads fields from the REQUEST/CONSULTATION file
to gather information regarding the consult or procedure being performed to
produce a patient worklist for modalities. The worklist is displayed on the
modality for the technician or physician to select the patient and attach
images to the consult\\procedure.", "", "", "2008/05/14"], ["4111", "Calls to Routine SRSCLM", "Routine", "SURGERY", "2003/05/29", "APPROVED", "Active", "Private", "", "
This DBIA documents calls to the routine SRSCLM.", "", "SRSCLM", ""], ["4112", "Look Up Radiology Diagnostic Code Number from Name", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2003/05/29", "APPROVED", "Active", "Private", "78.3", "
This agreement allows the VistA Imaging Package to
reference the "B" index and 0 subscript of the Radiology DIAGNOSTIC CODE File
(#78.3) in order to obtain a Diagnostic Code number given a Diagnostic Code
name.", "", "", ""], ["4113", "PXRM INDEX ERROR MESSAGE", "Routine", "CLINICAL REMINDERS", "2003/06/11", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXRMSXRM", ""], ["4114", "DIRECT SET AND KILL OF CLINICAL REMINDERS INDEX", "File", "CLINICAL REMINDERS", "2003/07/31", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will allow the subcribing packages to do a
direct set and a direct kill to the Clinical Reminders Index.", "", "", "2016/09/19"], ["4115", "DBIA4115", "Routine", "INTEGRATED BILLING", "2003/05/29", "APPROVED", "Active", "Private", "", "
The OUTPATIENT PHARMACY package will call the entry
point PTCOV in the routine IBCNSU3 to allow Outpatient Pharmacy to provide a
report of patients who had prescription insurance coverage on the fill date of
prescriptions which had copay charges back-billed by patch PSO*7*123.", "", "IBCNSU3", ""], ["4116", "NCEDIT DPTNAME", "Routine", "REGISTRATION", "2003/06/04", "APPROVED", "Active", "Private", "", "
This routine was introduced with Patient Name
Standardization. MPI allows editing of the patient name. To be consistent
with Registration options they want to display and allow editing of the
individual name component values as well.", "", "DPTNAME", ""], ["4117", "HL7 Capacity Management $$CM2F API", "Routine", "HEALTH LEVEL SEVEN", "2003/06/05", "APPROVED", "Active", "Controlled Subscription", "", "
Returns Health Level 7 (HL7) activity totals for a
parameter-supplied time range. Additional control over the HL7 activity
included in the totals is available using passed parameters.\n
Patch HL*1.6*103 fully documents the $$CM2F^HLUCM API covered by this
integration agreement. In addition, the patch documentation discusses the
$$CM^HLUCM (DBIA# 3484) and $$CM2^HLUCM (DBIA# 3489) APIs.\n
COMPARISON OF $$CM, $$CM2 & $$CM2F:
-----------------------------------
$$CM^HLUCM and $$CM2^HLUCM are almost identical to each other. Both have
identical parameters and both return data in the same format. The only
difference is that $$CM^HLUCM returns the number of messages during the
user-supplied time range, and $$CM2^HLUCM returns the number of "message
units" within a time range.\n
Messages are individually transmitted messages. The initially transmitted
message is considered a "message" by $$CM^HLUCM, and the return
acknowledgement is considers a separate and unique "message." If a message is
transmitted, and an acknowledgement message returned, $$CM^HLUCM returns a
total of two messages.\n
Message "units" are collections of functionally related messages. In the
above example, $$CM^HLUCM counts two messages, but since the message and it's
acknowledgement are functionally related, $$CM2^HLUCM returns a count of one
"unit."\n
$$CM2F^HLUCM counts message units in an identical manner to $$CM2. The only
difference between these two APIs is the $$CM2F^HLUCM counts only message
units involving remote sites. $$CM2^HLUCM (and $$CM^HLUCM, for that matter)
counts both locally and remotely sent message units.", "", "HLUCM", ""], ["4118", "ALLOW A/R TO UPDATE RATE TYPE FILE", "File", "INTEGRATED BILLING", "2003/06/05", "APPROVED", "Active", "Private", "399.3", "
The EDI Third Party Lockbox module includes
functionality where, when electronic bill status messages are received in
Integrated Billing containing specific data, the auto-audit function of A/R is
automatically invoked, based on the rate type of the bill. The IB portion of
the patch is modifying the RATE TYPE file (#399.3 - which it owns) to add
field #.11 BILL RESULTING FROM. From an A/R standpoint then, if this field is
filled in for a rate type, then all bills with that rate type are eligible for
the auto-audit function.\n
As a result, a request is being made to grant A/R Fileman write access to the
RATE TYPE file (#399.3) to allow A/R personnel to update this field in this
file so they can control which rate types can be auto-audited.", "", "", ""], ["4119", "CALL TO USRPS23", "Routine", "AUTHORIZATION/SUBSCRIPTION", "2003/06/05", "APPROVED", "Active", "Private", "", "
Patches TIU*1*137 and USR*1*23 create new Document
Definitions and a new User Class and new Business Rules in support of Anat
Path. They are sent out as a combined build.\n
The actual creation is done in an option sent out with TIU*1*137 but run after
the distribution is installed.\n
Being able to create both the TIU and the USR entities from one option makes
less work for sites, and ensures that the Document Definitions do not get
created without the Business Rules which restrict their use.\n
This agreement permits TIU to call MAIN^USRPS23 and to kill the temp global
created in USRPS23: ^TMP("USR23").", "", "USRPS23", ""], ["4120", "BCMA CONTINGENCY UPDATE", "Routine", "BAR CODE MED ADMIN", "2003/07/08", "APPROVED", "Active", "Private", "", "
The purpose of this API is to allow for Inpatient
Pharmacy to cause an order update to the BAR CODE MEDICATION ADMINISTRATION
(BCMA) CONTINGENCY software.\n", "", "ALPBCBU", ""], ["4121", "A/R access to TPJI for patient name OR bill number", "Routine", "INTEGRATED BILLING", "2003/06/11", "APPROVED", "Active", "Private", "", "
An entrypoint is needed by A/R to access the TPJI
(Third Party Joint Inquiry) option from a PROTOCOL action. The level of entry
needs to be at the point where the user is prompted to enter EITHER a patient
name OR a bill number and the appropriate TPJI list manager screen will be
invoked. This entry point already exists at line OPTION^IBJTLA and A/R would
like to have access to this call.", "", "IBJTLA", ""], ["4122", "SET AUDIT ON NEW PERSON FILE #200 FIELDS", "File", "KERNEL", "2010/12/13", "APPROVED", "Active", "Private", "200", "
The LAB SERVICE package (LSRP project) has a
requirement that specific fields are to be set to be audited on patch
installation for the NEW PERSON file (#200). We are requesting a one-time use
ICR that allows us to set this access on specific fields in file 200 using the
supported API for this purpose (TURNON^DIAUTL). This would be done in our
post installation routine for patch LR*5.2*393 The fields are:\n
Top level:\n
.01 NAME
.132 OFFICE PHONE
.137 VOICE PAGER
.138 DIGITAL PAGER
4 SEX
5 DOB
7 DISUSER
9 SSN
9.2 TERMINATION DATE
41.99 NPI
9000 VPID\n
51 KEYS (subfile #200.051)
.01 KEY", "", "", "2010/12/15"], ["4123", "4123", "File", "TOOLKIT", "2004/08/24", "APPROVED", "Active", "Private", "409.61", "
If a List template has been distributed to a site and
subsequent changes are made and KIDS is used to send the updated version, IT
DOES NOT UPDATE to the new version but the old version is left in place. This
gives the subscriber permission to directly KILL an entry and SET the zero
node of file 409.61 (LIST TEMPLATE). This includes the use of the "B" cross
reference.", "", "", ""], ["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", ""], ["4125", "CPT CODE UPDATE", "Other", "CPT/HCPCS CODES", "2003/07/21", "APPROVED", "Active", "Supported", "", "
attached package protocols will be notified of a code
set update. Packages may attach protocols using KIDS' "USE AS LINK FOR MENU
ITEMS"", "", "", ""], ["4126", "ICD CODE UPDATE", "Other", "DRG GROUPER", "2003/07/21", "APPROVED", "Active", "Supported", "", "
attached package protocols will be notified of a code
set update. Packages may attach protocols using KIDS' "USE AS LINK FOR MENU
ITEMS"", "", "", ""], ["4127", "CALL TO USRPS24", "Routine", "AUTHORIZATION/SUBSCRIPTION", "2003/06/11", "APPROVED", "Active", "Private", "", "
Patches TIU*1*165 and USR*1*24 create new Document
Definitions and a new User Class and new Business Rules in support of Patient
Record Flags. They are sent out as a combined build.\n
The actual creation is done in an option sent out with TIU*1*165 but run after
the distribution is installed.\n
Being able to create both the TIU and the USR entities from one option makes
less work for sites, and ensures that the Document Definitions do not get
created without the Business Rules which restrict their use.\n
This agreement permits TIU to call MAIN^USRPS24 and to kill the temp global
created in USRPS24: ^TMP("USR24",$J).", "", "USRPS24", ""], ["4128", "REVENUE CODE", "File", "INTEGRATED BILLING", "2003/06/20", "APPROVED", "Active", "Private", "399.2", "
This IA allows Fee Basis to establish a field that
points to the REVENUE CODE (#399.2) file. LAYGO is not allowed.", "", "", ""], ["4129", "INVOKE DUZ~XUP", "Routine", "KERNEL", "2003/06/30", "APPROVED", "Active", "Controlled Subscription", "", "
Noted by Custodian on 11/3/23 that it has been
mentioned in the past that this API needs to be improved. That is, Kernel
needs to find a better solution to allow VistA Kernel direct-authentication of
the actual user logged in to VistA. Setting the DUZ variable should be done
only by Kernel after verification of valid and secure credentials. If we
continue allowing applications to "arbitrarily search" for an IEN in the NEW
PERSON (#200) file, and then call DUZ^XUP to set the DUZ variable, it may
cause additional problems.", "", "XUP", "2010/12/16"], ["4130", "LES ORDER CHECK", "Routine", "LAB SERVICE", "2003/06/17", "", "Pending", "Private", "", "
In CPRS GUI, when user edited the lab order, the new
generated lab order needs the validation check by the "Lab Expert
System"(LES), the existed LES API "COM^AVJLES" need to be called by CPRS for
this purpose.", "", "AVJLES", ""], ["4131", "ECS REPORT", "Routine", "EVENT CAPTURE", "2003/07/16", "APPROVED", "Active", "Private", "", "
The API "RPTEN^ECRRPC" returns the patient event
capture report's data. CPRS need to call the API for displaying the event
capture report.", "", "ECRRPC", ""], ["4132", "DG FIELD MONITOR", "Other", "KERNEL", "2003/06/17", "APPROVED", "Active", "Private", "", "
Automatically adding the following entries to the
following files.\n\n
File #3.5\n
NAME: DG FIELD MONITOR $I: DG FIELD MONITOR
LOCATION OF TERMINAL: DG field editing protocol
RESOURCE SLOTS: 9 SUBTYPE: P-OTHER
TYPE: RESOURCES\n\n
File #3.54\n
NAME: DG FIELD MONITOR AVAILABLE SLOTS: 9", "", "", ""], ["4133", "IMO QUALIFIER", "Routine", "SCHEDULING", "2003/06/25", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this DBIA is asking for permission to
call the scheduling API from OE/RR at server side to determine if a specific
patient at a specific clinic is qualified to receive inpatient medication.", "", "SDAMA203", ""], ["4134", "ORCHECK", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/06/23", "APPROVED", "Active", "Private", "", "
Allergy tracking requests the use of the BLD entry
point in ORCHECK. This call will put the patient's order in the correct
format for order checking code to process.", "", "ORCHECK", ""], ["4135", "ORKCHK", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/06/23", "APPROVED", "Active", "Private", "", "
Adverse reaction tracking requests the ability to call
into the order checking software.", "", "ORKCHK", "2014/03/26"], ["4136", "Look For 'PT' Nodes in File 5.12", "File", "1", "2003/06/24", "APPROVED", "Active", "Private", "5.12", "\n\n
In routine XIPENV (enviroment check routine) it is necessary to look for "PT"
nodes of files that should NOT be Pointing To this file. The need for this
check is because in the pre-installation routine will be deleting this file
prior to the new DD and data being installed.", "", "", ""], ["4137", "Look For 'PT' Nodes in File 5.13", "File", "1", "2003/06/24", "APPROVED", "Active", "Private", "5.13", "
In routine XIPENV (enviroment check routine) it is
necessary to look for "PT" nodes of files that should NOT be Pointing To this
file. The need for this check is because in the pre-installation routine will
be deleting this file prior to the new DD and data being installed.", "", "", ""], ["4138", "NON-INTERACTIVE PATIENT LOOKUP LIST", "Routine", "REGISTRATION", "2003/06/26", "", "Withdrawn", "Controlled Subscription", "", "", "", "DPTLK1", ""], ["4139", "PATIENT FILE (#2) DATE OF BIRTH FIELD (.03) IDENTIFIER", "File", "1", "2010/12/13", "APPROVED", "Active", "Private", "2", "
This is a one-time agreement to allow Registration to
set the IDENTIFIER node as follows for the PATIENT (#2) file:\n
^DD(2,0,"ID",.03)="D EN^DDIOL($TR($$DOB^DPTLK1(Y,1),""/"",""-""),,""?$X+2"")"\n
This api will add the IDENTIFIER parameter back to the PATIENT file (#2). It
was an unknown fact that the IDENTIFIER parameter would be removed when the
DG*5.3*754 pre-init routine (DG53754P) initialized the field definition for
the DATE OF BIRTH field (#.03) from the PATIENT file (#2).", "", "", "2010/12/13"], ["4140", "Remove ID Node From File #5.12", "File", "1", "2003/06/30", "APPROVED", "Active", "Private", "5.12", "
During the install of data at the target site for patch
XU*8*292 it is necessary to have 'UNIQUE KEY (VA)' (#8) field brought in as an
Identifier so duplicate Zip Code entries can be resolved, then during the
post-install it is necessary to remove it via:\n
K ^DD(5.12,0,"ID",8) ; IA #4140\n
This would be a one time agreement.", "", "", ""], ["4141", "Closing Legacy Queues", "File", "MAILMAN", "2003/07/02", "APPROVED", "Active", "Private", "4.2", "
When CoreFLS is implemented at a site, the IFCAP and
Engineering (AEMS/MERS) packages will be inactivated by the Legacy Software
Shut Down patch and there should not be transmission of documents to the
domains or queues set up to support their business. As the deployment of
CoreFLS nationally will be phased in over a period of a few years, it seems
more appropriate that the software involved in the inactivation of IFCAP and
Engineering, rather than an nationally released MailMan patch, should close
these domains/queues. It is requested that as part of the Legacy Software Shut
Down process, PRCL namespaced code be allowed to set the DOMAIN file (#4.2)
entry's FLAGS field (#1) to 'C' (CLOSED) and delete the current value of the
RELAY DOMAIN field (#2) for the following domains:
CONST.RD4-REGION4.DNS
NESC.DNS
Q-CRD.DNS
Q-EDP.DNS
Q-EDV.DNS
Q-FAM.DNS
Q-FMZ.DNS
Q-ISM.DNS
Q-LOG.DNS
Q-PRC.DNS\n
Before filing the changes, the current values of those domains/queues will be
extracted and stored in the LEGACY SOFTWARE SHUT DOWN file (#449.1), so that
they are available for restoration if necessary. As part of this integration
agreement, we are also requesting that the software be permitted to file the
original values back into the DOMAIN file entries, in the remote likelihood
that the CoreFLS implementation needs to be temporarily reversed.\n
The extraction of current values and the filing would be performed by calls to
supported FileMan database server APIs.", "", "", ""], ["4142", "Entry Action Setting in Option", "File", "KERNEL", "2003/07/16", "APPROVED", "Active", "Private", "19", "
As part of the Legacy Software Shut Down process,
IFCAP, Engineering (AEMS/MERS) and Equipment/Turn-In Request options that
change the database will be disabled. Only read access to the database will
be allowed once the site comes up on CoreFLS. Although putting a string in the
OUT OF ORDER MESSAGE field (#2) can put the option offline, it seems
preferable to also inactivate the option by putting "S XQUIT=1" in the ENTRY
ACTION field (#20). There currently is not a supported Kernel API
specifically for editing the ENTRY ACTION field. Management has previously
instructed our team not to edit the application routines in order to
inactivate the option.\n
Specifically this request is to permit PRCL namespaced code to file "S
XQUIT=1" in the ENTRY ACTION field of selected options of these three legacy
packages using supported FileMan (FM) database server APIs. Before filing the
new value, the existing value will be extracted via a FM supported API and
stored in the LEGACY SOFTWARE SHUT DOWN file (#449.1) so that it is available
if needed. In the remote possibility the the site temporarily needs to resume
business activity in the legacy systems, it is also requested that the
software be permitted to restore the original value for each entry again using
supported FM APIs. [Note: The software is also filing of an Out of Order
Message using the supported OUT^XPDMENU() API.]", "", "", ""], ["4143", "Scheduled Option Removal", "File", "KERNEL", "2003/07/03", "APPROVED", "Active", "Private", "19.2", "
The Legacy Software Shut Down project will be
converting the IFCAP, Engineering (AEMS/MERS) and Equipment/Turn-In Request
packages to Read-Only as part of the site's coming on line with CoreFLS.
Scheduled options, especially those which may alter the database, must be
removed from the OPTION SCHEDULING file (#19.2). This request is to permit
PRCL namespaced code to remove any entries in the namespaces of these legacy
packages from file 19.2.\n
Specifically it is requested that the Legacy Sofware Shut Down software be
permitted to extract via supported FileMan database server APIs, the current
value of most fields of the entry to be removed so that they can be stored in
the LEGACY SOFTWARE SHUT DOWN file (#449.1) in case the values are needed
later. The TASK ID field (#12) and the computed TASK DEFIND field (#99.1),
however, will not be backed up. The request further asks for permission to
remove the entry from file 19.2 via a ^DIK call. Finally, in the highly
unlikely event that the site must temporarily resume using these packages,
instead of CoreFLS, for business activities, it is requested that the software
be permitted to create a new entry in file 19.2 to reschedule each of the
affected options. This again would be accomplished through supported FileMan
APIs. TaskManager, not this software, would establish the value for the TASK
ID field.", "", "", ""], ["4144", "Dequeueing Legacy Software Tasks", "File", "KERNEL", "2003/07/03", "APPROVED", "Active", "Private", "14.4", "
The Legacy Software Shut Down patch will be converting
the IFCAP, Engineering (AEMS/MERS) and Equipment/Turn-In Request packages to
Read-Only when the site comes up on CoreFLS. Queued tasks for these packages,
especially those that may alter the database, must be dequeued. Specifically,
this request asks that PRCL namespaced software be permitted to $Order()
through the ^%ZTSK global and to identify tasks to be dequeued through
examination by direct global read of the Routine Name field (#2) [node 0,
piece 2], comparing the routine's prefix to the namespaces of the above
packages. (For dequeueing, the status of the task must also be verified as
"Active: Pending" using the supported Kernel API STAT^%ZTLOAD.) Where the task
is to be dequeued via supported Kernel API DQ^%ZTLOAD, it is requested that
the software be permitted to file via a supported FileMan database server API
a value of one year from the run date into the Remember Untill field (#59.8)
so that the task is still available, in the highly unlikely case that the site
needs to temporarily resume business processing using these legacy packages
instead of CoreFLS and wishes to requeue the task. Finally, for reporting
tasks dequeued as part of the shut down, it is requested that the software be
permitted to extract via a supported FileMan database server API, the values
for the Entry Point field (#.01), Routine Name field (#2) and the Task
Description field (#41), so they can be displayed in addition to the task
number.", "", "", ""], ["4145", "Kernel Part 3 - Modifying File Access Permissions", "File", "KERNEL", "2003/07/03", "APPROVED", "Active", "Private", "200.032", "
The Legacy Software Shut Down patch will convert the
IFCAP, Engineering (AEMS/MERS), and Equipment/Turn-In Request packages to
Read-Only. Users must not be able to edit via FileMan, files of the above
packages. Although some restriction can be accomplished by the IRM removing
Write and Delete/Purge permissions to application namespaced globals, some
Engineering files still store data in the ^DIC global, whose protection can
not be changed by this patch. In addition, as a temporary workaround for
Prosthetics during the initial deployment of CoreFLS at VAMC Bay Pines, the
protection of the IFCAP ^PRC global can not be modified so access to files
stored in this global has to be controlled via VA FileMan or Kernel Part 3
setups. This request concerns sites that have implemented the Kernel Part 3
access controls.\n
Specifically, this request asks that PRCL namespaced code be permitted to
$Order() through the AFOF cross reference in the NEW PERSON file (#200) in
order to identify individuals with access to the files of interest and the
internal number of the accessible file multiple entry. It is further
requested that the software be permitted to extract via a supported FileMan
API, the current access values in case they are needed later. They will be
stored in the LEGACY SOFTWARE SHUT DOWN file (#449.1). It is requested that
the software be permitted to file via a supported FileMan API, '0' (NO) for
DATA DICTIONARY ACCESS, DELETE ACCESS, LAYGO ACCESS, and WRITE ACCESS to the
files of these packages. Finally, in the highly unlikely situation that users
need to temporarily resume using these legacy packages, rather than CoreFLS
for their business activities, it is requested that the software be permitted
to file via a supported FileMan API, the original values back into the
ACCESSIBLE FILE multiple of the NEW PERSON entries that were modified during
the shut down.", "", "", ""], ["4146", "BPSUTIL", "Routine", "E CLAIMS MGMT ENGINE", "2007/02/22", "APPROVED", "Active", "Controlled Subscription", "", "
The application programming interfaces covered by this
agreement have been designed to support ePharmacy/ECME Enhancements project
and:
- provide the Integrated Billing package with the status, date of service
and amount paid for the claim by the third party ($$PAIDAMNT),
- allow the Integrated Billing user to select and use ePharmacy divisions
for reporting purposes ($$SELPHARM, $$MULTPHRM, $$GETPHARM),
- return NDPDP # and NPI for Controlled Substance Pharmacy.\n
Amended 8/2022: $$CSNPI added, effective with BPS*1.0*33 and PSO*7.0*680, not
used by IB.", "", "BPSUTIL", "2022/08/03"], ["4147", "CALL TO THE TIU TEMPLATE REMINDER DIALOGS PARAMETER", "Other", "TEXT INTEGRATION UTILITIES", "2007/02/22", "APPROVED", "Active", "Private", "", "
This IA will allow Clinical Reminders to be able to
call the TIU parameter TIU TEMPLATE REMINDER DIALOGS from a Clinical Reminder
option.\n", "", "", "2007/02/26"], ["4148", "VistALink J2M Java APIs [vljConnector-x.x.x.xxx.jar]", "Other", "VISTALINK", "2007/02/23", "", "Withdrawn", "Supported", "", "\n
This ICR describes the supported VistALink J2M (v1.5) Java APIs for
the vljConnector-x.x.x.xxx.jar file.\n
It is strongly recommended that you consult the javadoc for the
VistALink J2M software for more detail on all supported VistALink
J2M Java APIs.\n\n
Jar:
vljConnector-x.x.x.xxx.jar\n
Connector Packages:
gov.va.med.vistalink.adapter.cci
gov.va.med.vistalink.adapter.heartbeat
gov.va.med.vistalink.adapter.record
gov.va.med.vistalink.adapter.spi\n
RPC Package:
gov.va.med.vistalink.rpc\n
Institution Mapping Utilities Package:
gov.va.med.vistalink.institution\n\n\n
Package gov.va.med.vistalink.adapter.cci
========================================
Implements the Common Client Interface (CCI) portion of the Java
Connector Architecture (JCA) for VistaLink.\n
Interface Summary
=================
VistaLinkConnection
This interface represents an application level connection
handle that is used by a component to access an EIS instance.\n
VistaLinkConnectionSpec
This interface defined the common properties needed by any
connection spec implementation.\n
Class Summary
=============
VistaLinkAppProxyConnectionSpec
This is the connection spec class for Application Proxy
re-authentication.\n
VistaLinkConnectionFactory
This implementation class provides an interface for getting
connection to an EIS instance.\n
VistaLinkConnectionMetaData
Provides information about an EIS instance connected through a
Connection instance.\n
VistaLinkConnectionSpecImpl
This is the base implementation class for
VistaLinkConnectionSpec.\n
VistaLinkDuzConnectionSpec
This is the connection spec class for Duz re-authentication.\n
VistaLinkResourceAdapterMetaData
Implementation class provides info about the capabilities of a
resource adapter.\n
VistaLinkVpidConnectionSpec
This is the connection spec class for VPID re-authentication.\n
Exception Summary
=================
VistaLinkResourceException
Represents a ResourceException thrown by the VistaLink
adapter.\n\n
Package gov.va.med.vistalink.adapter.heartbeat
==============================================
Implements the heartbeat keepalive timer process for VistaLink.\n
Exception Summary
=================
HeartBeatFailedException
This exception class is used to notify the managed connection
and its event listeners that a scheduled heart beat has
failed.\n
HeartBeatInitializationFailedException
This exception class is thrown when the heart beat fails to
make its first interaction to retrieve the heartbeat rate from
M.\n\n
Package gov.va.med.vistalink.adapter.record
===========================================
Implements basic request- and response-related classes for
VistaLink.\n
Interface Summary
=================
VistaLinkRequestRetryStrategy
Base strategy interface for determining if request should be
re-executed.\n
VistaLinkRequestVO
Base request interface.\n
Class Summary
=============
VistaLinkRequestRetryStrategyAllow
Simple 'Allow' strategy implementation that indicates request
should be re-executed.\n
VistaLinkRequestRetryStrategyDeny
Simple 'Deny' strategy implementation that indicates request
should not be re-executed.\n
VistaLinkRequestVOImpl
Base request implementation.\n
Exception Summary
=================
LoginsDisabledFaultException
This exception represents the case where the M side has logins
disabled; this is when the site sets the parameter to not
allow any logins.\n
NoJobSlotsAvailableFaultException
This exception represents the case where on the M side there
are no license slots available to start another process.\n
VistaLinkFaultException
Exception encapsulates Fault information coming from M side.\n\n
Package gov.va.med.vistalink.adapter.spi
========================================
Implements the Service Provider Interface (spi) portion of the Java
Connector Architecture (JCA) for VistaLink.\n
Class Summary
=============
VistaLinkServerInfo
Represents M VistA connection information, like address and
port.\n
Exception Summary
=================
ConnectionHandlesExceededException
This exception class is thrown when a
VistaLinkManagedConnection object has exceeded its maximum
allowable connection handles.\n
VistaLinkSocketAlreadyClosedException
Represents a situation where, when attempting to close a
socket, the socket is already closed.\n
VistaLinkSocketClosedException
This exception class is thrown when an attempt is made to
access the VistaLinkManagedConnection's underlying
VistaSocketConnection after it has been closed or invalidated.\n\n
Package gov.va.med.vistalink.rpc
================================
Implements RPC requests and responses over VistaLink.\n
Class Summary
=============
RpcReferenceType
Represents a reference type object for an RPC parameter.\n
RpcRequest
Represents a RPC request to an M VistA server.\n
RpcRequestFactory
Factory class to creates instances of RpcRequest.\n
J2SE Example: //request and response objects
RpcRequest vReq = null;
RpcResponse vResp = null; //The Rpc Context
String rpcContext = "XOBV VISTALINK TESTER"; //The Rpc to call
String rpcName = "XOBV TEST PING"; //Construct the request
object
vReq = RpcRequestFactory.getRpcRequest(rpcContext, rpcName);
//Execute the Rpc and get the response
vResp = myConnection.executeRPC(vReq); //Work with the
response...\n
RpcRequestParams
Represents the collection of parameters associated with an
RPC.\n
RpcResponse
Represents a data structure which holds the response value(s).\n
Exception Summary
=================
NoRpcContextFaultException
This exception represents the case where the request RPC
context does not exist or the current user does not have
access to the B-option representing the context.\n
RpcFaultException
This fault exception class is used for all Rpc-related errors
returned from the M system.\n
RpcNotInContextFaultException
This exception represents the case where the requested RPC is
not contained in the current RPC context.\n
RpcNotOkForProxyUseException
This exception represents the case where the requested RPC is
not marked as OK for use by an application proxy user, but has
been attempted to be invoked by one.\n
RpcResponseTypeIsNotXmlException
Represents an exception indicating the RpcResponse type if not
XML.\n
RpcTimeOutFaultException
This exception represents the case where the RPC execution
took too long on the server and the application gracefully
stopped the RPC's processing.\n\n
Package gov.va.med.vistalink.institution
========================================
Foundations utilities for working with VistaLink-related Institution
data.\n
Class Summary
=============
InstitutionMappingDelegate
The in-memory mapping is initialized during connector startup.\n
Exception Summary
=================
InstitutionMapNotInitializedException
Represents an attempt to access some functionality of the
InstitutionMappingImpl instance when that instance has not
been created.\n
InstitutionMappingNotFoundException
Represents a failure to retrieve an institution mapping based
on station number, due to requested station number not being
found in the list of instituion mappings maintained by the
InstitutionMappingImpl instance.", "", "", "2007/03/06"], ["4149", "M XML EVENT-DRIVEN API", "Routine", "TOOLKIT", "2003/07/03", "APPROVED", "Active", "Supported", "", "
An event-driven interface that is modeled after the
widely used SAX interface specification. In this implementation, a client
application provides a special handler for each parsing event of interest.
When the client invokes the parser, it conveys not only the document to be
parsed, but also the entry points for each of its event handlers. As the
parser progresses through the document, it invokes the client's handlers for
each parsing event for which a handler has been registered.", "", "MXMLPRSE", ""], ["4150", "STORE POINTERS TO BDP PHARMACYS", "File", "E CLAIMS MGMT ENGINE", "2007/02/26", "APPROVED", "Active", "Private", "9002313.56", "
Integrated Billing requests to be able to store
pointers to BPS Pharmacies file (#9002313.56) in IB file #366.14.", "", "", "2007/03/04"], ["4151", "CoreFLS/Legacy Software Shut Down Status Check", "Routine", "IFCAP", "2003/07/30", "APPROVED", "Active", "Supported", "", "
As the legacy software packages IFCAP, Engineering
(AEMS/MERS) and Equipment/Turn-In Request are converted to Read-Only
functionality, data conversions are started and then CoreFLS comes on-line for
each site, a new PRCL LSSD SHUTDOWN STATUS parameter in VistA will be updated.
The API described below will enable other packages to check its value, perhaps
directing the flows their software execution on the basis of it. For example,
the IFCAP interface partners might continue to use APIs to IFCAP code if IFCAP
is fully functional and switch to use APIs to the Communications Service
Library (CSL) code if CoreFLS is on-line.", "", "PRCLOP4", ""], ["4152", "Person Service Lookup java components", "Other", "759", "2007/02/28", "", "Pending", "Controlled Subscription", "", "
Person Service Lookup includes components necessary to
support the search and retrieval operations for patient and provider lookups
for both web and swing versions. PSL components include both a web and java
swing-based GUI application client to be used within a consuming host
application. These GUI components represent the API for consuming
applications that must embed the GUI Person Service Lookup Client components
into the design of their application. GUI PSL components internally use CAIP
(Cross Application Integration Protocol) delegate to access PSL services
needed to perform a lookup.\n
PSL provider lookup components do not include any GUI components. The
provider lookup API consists of a CAIP provider lookup delegate class that is
intended for programmatic access from a consuming application.\n
PSL Services will be deployed both nationally and locally.", "", "", ""], ["4153", "MXMLUTL", "Routine", "TOOLKIT", "2003/07/15", "APPROVED", "Active", "Supported", "", "
Utility API's to help when building XML messages.", "", "MXMLUTL", "2011/05/13"], ["4154", "FILE 61", "File", "LAB SERVICE", "2003/07/11", "", "Withdrawn", "Private", "61", "
The Womens Health package requests permission to point
to the TOPOGRAPHY FIELD (#61) file.", "", "", ""], ["4155", "FILE 61.1", "File", "LAB SERVICE", "2003/07/11", "", "Withdrawn", "Private", "61.1", "
The Womens Health package requests permission to point
to the MORPHOLOGY FIELD (#61.1) file.", "", "", ""], ["4156", "COMBAT VETERAN STATUS", "Routine", "REGISTRATION", "2003/07/21", "APPROVED", "Active", "Supported", "", "
As per directive 2002-049 patients who qualify as
Combat Veterans will be treated for two years after separation even in the
absence of supporting evidence that their condiditons are combat related.
This supported DBIA covers an API that will be used during patient lookups,
Registration, Billing, Outpatient Pharmacy and treatment checkout that will
provide whether or not the veteran being processed has been assigned combat
status and whether that combat status is still in effect.", "", "DGCV", ""], ["4157", "VDEMCUS1", "Routine", "VDEM", "2003/07/24", "", "Withdrawn", "Supported", "", "
VDEM extraction tool utility which contains calls and
conversion of data from dictionary.", "", "VDEMCUS1", ""], ["4158", "VDEMRMBD Routine Calling File 405.4.", "File", "VDEM", "2003/07/25", "", "Withdrawn", "Private", "405.4", "
This IA was created becuase of the routine dependancy
with the Room-Bed file # 405.4. The routine will loop through the file and
extract data elements of key fields. The data will be used to support the VDEM
extraction application.", "", "VDEMRMBD", ""], ["4159", "VDEMRACE Routine Calling File 10", "File", "VDEM", "2003/07/25", "", "Withdrawn", "Private", "10", "
This IA was created becuase of the routines dependancy
with the Race file #10. The routine will loop through the file and extract
data elements of key fields. The data will be used to support the VDEM
extraction application.", "", "VDEMRACE", ""], ["4160", "VDEMDSMM Routine Calling file 627.9", "File", "VDEM", "2003/07/25", "", "Withdrawn", "Private", "627.9", "
This IA was created becuase of the routine dependancy
with the DSM MODIFIER file 627.9. The routine will loop through the file and
extract data elements of key fields. The data will be used to support the VDEM
extraction", "", "VDEMDSMM", ""], ["4161", "VDEMVITL", "Routine", "VDEM", "2003/07/25", "", "Withdrawn", "Supported", "", "
This IA was created to address the dictionary
references (#120.51), (#120.52), (#120.53), (#126.56) & (#126.8)", "", "VDEMVITL", ""], ["4162", "VDEMSIGN Routine Calling File 120.83", "File", "ADVERSE REACTION TRACKING", "2003/07/25", "", "Withdrawn", "Private", "120.83", "
This IA is defined to address issues from dictionary
(#120.83)", "", "VDEMSIGN", ""], ["4163", "DBIA4163", "Routine", "TEXT INTEGRATION UTILITIES", "2003/07/29", "APPROVED", "Active", "Private", "", "", "", "TIUPXPM", ""], ["4164", "XPARDD", "Routine", "TOOLKIT", "2003/07/29", "APPROVED", "Active", "Private", "", "
The HealtheVet Desktop allows the setting and changing
of parameter values that control its behavior from within the application
itself; since this is a GUI application it must do its own presentation and
thus needs access to some lower-level calls to manipulate those values.", "", "XPARDD", ""], ["4165", "XPARLIST", "Routine", "TOOLKIT", "2003/07/29", "APPROVED", "Active", "Private", "", "
The HealtheVet Desktop allows the setting and changing
of parameter values that control its behavior from within the application
itself; since this is a GUI application it must do its own presentation and
thus needs access to some lower-level calls to manipulate those values.", "", "XPARLIST", ""], ["4166", "RORAPI01", "Routine", "CLINICAL CASE REGISTRIES", "2003/07/30", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement documents the use of entry points in
routine RORAPI01 to get lists of patients from the Clinical Case Registries.", "", "RORAPI01", ""], ["4167", "Care Mgt access to OR(100", "File", "ORDER ENTRY/RESULTS REPORTING", "2003/07/30", "APPROVED", "Active", "Private", "100", "
This documents the Care Management application's use of
the Orders file.", "", "", ""], ["4168", "VDEMORDR Routine calling File", "File", "VDEM", "2003/07/30", "", "Withdrawn", "Private", "", "
This routine is used by the VDEM package that will
reference several dictionary (#100.98), (#101.43), (#60), (#71), (#50.7),
(#100.01), & (#101.43).", "", "VDEMORDR", ""], ["4169", "VDEMPDRG Routine Calling File 50.3", "File", "VDEM", "2003/07/30", "", "Withdrawn", "Private", "50.3", "
This IA was created becuase of the routines dependancy
with the PRIMARY DRUG File 50.3. The routine will loop through the file and
extract data elements of key fields. The data will be used to support the VDEM
extraction application.", "", "VDEMPDRG", ""], ["4170", "ADD~ORRCACK", "Routine", "CARE MANAGEMENT", "2003/07/30", "APPROVED", "Active", "Private", "", "
This agreement documents the user of ADD^ORRCACK by
OE/RR to create stubs in the Order Acknowledgments file when order results
come in.", "", "ORRCACK", ""], ["4171", "IA 4171 Imaging Consults", "File", "CONSULT/REQUEST TRACKING", "2003/07/31", "APPROVED", "Active", "Controlled Subscription", "123.5", "", "", "", ""], ["4172", "BUILD CLINICAL REMINDERS INDEX", "Routine", "PHARMACY DATA MANAGEMENT", "2003/08/01", "APPROVED", "Active", "Private", "", "
This integration agreement grants Clinical Reminders
the access to call a routine in Pharmacy Data Management to build an index for
the PHARMACY PATIENT file (#55).", "", "PSSSXRD", ""], ["4173", "VistALink J2M Java APIs [vljSecurity-x.x.x.xxx.jar]", "Other", "VISTALINK", "2007/02/28", "", "Withdrawn", "Supported", "", "\n
This ICR describes the supported VistALink J2M (v1.5) Java APIs for
the vljSecurity-x.x.x.xxx.jar file.\n
It is strongly recommended that you consult the javadoc for the
VistALink J2M software for more detail on all supported VistALink
J2M Java APIs.\n\n
Jar:
vljSecurity-x.x.x.xxx.jar\n
Security Packages:
gov.va.med.vistalink.security
gov.va.med.vistalink.security.m\n\n\n
Package gov.va.med.vistalink.security
=====================================
J2SE security module for VistaLink; contains JAAS login module
supporting a JAAS client/server login to a Vista M system.\n
Class Summary
=============
CallbackHandlerSwing
Implements the JAAS CallbackHandler interface.\n
CallbackHandlerSwingCCOW
Implements the JAAS CallbackHandler interface.\n
CallbackHandlerUnitTest
Implements the JAAS CallbackHandler interface.\n
DialogConfirm
Swing Dialog to display an error, informational message,
help, or post-sign-in text to user, and collect their response
(OK or CANCEL, depending on type of message).\n
VistaKernelPrincipalImpl
A JAAS principal representing a logged on Kernel user on an M
system.\n
VistaLoginModule
A JAAS-compliant LoginModule to log users on to a Vista
system.\n
Exception Summary
=================
VistaLoginModuleException
Represents a LoginException thrown by the LoginModule.\n
VistaLoginModuleIPLockedException
If thrown, the user's IP has been locked due to too many times
with invalid credentials.\n
VistaLoginModuleLoginsDisabledException
If thrown, logins are disabled on the M server.\n
VistaLoginModuleNoJobSlotsAvailableException
If thrown, job slot maximum has been exceeded on M server.\n
VistaLoginModuleNoPathToListenerException
If thrown, no reachable listener was found on the path
represented by the specified IP address and Port.\n
VistaLoginModuleTooManyInvalidAttemptsException
If thrown, the user tried to login too many times with invalid
credentials.\n
VistaLoginModuleUserCancelledException
Represents a user cancellation of Login.\n
VistaLoginModuleUserTimedOutException
User timed out of a login.\n\n
Package gov.va.med.vistalink.security.m
=======================================
Base Security implementation (J2SE and J2EE).\n
Interface Summary
=================
VistaKernelPrincipal
Provides an interface to mark a principal that represents a
logged on Kernel user on an M system.\n
Class Summary
=============
VistaInstitutionVO
Represents a Vista Institution, including IEN, Station Name
and Station Number.\n
Exception Summary
=================
SecurityAccessVerifyCodePairInvalidException
Represents an authentication failure during an access/verify
code-based re-authentication attempt, where either the access
code, verify code (or both) authentication credentials are
invalid.\n
SecurityConnectionProxyException
This exception fault is returned from M, and signifies that
the connection proxy used to create the connection was invalid
in some way, and a connection could not be established to the
EIS.\n
SecurityDivisionDeterminationFaultException
Represents an authentication failure during a
re-authentication attempt, in which an invalid division has
been passed for the user on whose behalf re-authentication is
being attempted.\n
SecurityFaultException
This fault exception class is used for all security-related
errors returned from the M system.\n
SecurityIdentityDeterminationFaultException
Represents an authentication failure during a
re-authentication attempt, in which the credentials passed for
re-authentication (DUZ, VPID, etc.) could not be matched with
an actual Kernel user.\n
SecurityIPLockedFaultException
This exception fault is returned from M, and signifies that
the IP address has been locked due to too many invalid
logins.user's login credentials were invalid too many times,
and the M system is rejecting further login attempts as a
result.\n
SecurityPrimaryStationMismatchException
This exception fault is returned from M, and signifies that
there was a mismatch between the client primary station
(mapped to the connector) and the primary station of the M
account the connector accessed (based on the value of the
DEFAULT INSTITUTION field of the Kernel System Parameters
file).\n
SecurityProductionMismatchException
This exception fault is returned from M, and signifies that
there was a mismatch between the client and the server in the
designation of each side as production or non-production.\n
SecurityTooManyInvalidLoginAttemptsFaultException
This exception fault is returned from M, and signifies that
the user's login credentials were invalid too many times, and
the M system is rejecting further login attempts as a result.\n
SecurityUserAuthorizationException
Represents an authorization failure during a re-authentication
attempt, e.g., DISUSER flag is set for the re-authentication
user, prohibited times of day is set, etc.\n
SecurityUserVerifyCodeException
Represents a failure during a re-authentication attempt, where
the user's verify code is expired or requires changing.", "", "", ""], ["4174", "APIs in TIULS", "Routine", "TEXT INTEGRATION UTILITIES", "2003/08/04", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents calls to the routine TIULS that can
be re-used by subscribing applications.", "", "TIULS", "2023/05/18"], ["4175", "APIs in TIUSRVP1", "Routine", "TEXT INTEGRATION UTILITIES", "2003/08/04", "APPROVED", "Active", "Controlled Subscription", "", "
This IA documents MUMPS-to-MUMPS calls to the routine
TIUSRVP1, some of which are also documented as RPC-type agreements.", "", "TIUSRVP1", ""], ["4176", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "PCE PATIENT CARE ENCOUNTER", "2004/06/29", "APPROVED", "Active", "Private", "", "
The following global references are made:\n
Global Nodes
AUPNVCPT $P(^AUPNVCPT(0),U,4)
AUPNVXAM $P(^AUPNVXAM(0),U,4)
AUPNVHF $P(^AUPNVXHF(0),U,4)
AUPNVIMM $P(^AUPNVIMM(0),U,4)
AUPNVPED $P(^AUPNVPED(0),U,4)
AUPNVPOV $P(^AUPNVPOV(0),U,4)
AUPNVSK $P(^AUPNVSK(0),U,4)
AUPNPROB $P(^AUPNPROB(0),U,4)", "", "", ""], ["4177", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "REGISTRATION", "2004/06/29", "APPROVED", "Active", "Private", "", "
The following global references are made:\n
Global Nodes\n
DGPT $O(^DGPT(DA))
$P(^DGPT(DA,0),U,1)\n
$O(^DGPT(DA, S ,D1))
$P(^DGPT(DA, S ,D1,0),U,M)
M=1,8,9,10,11,12\n
$O(^DGPT(DA, P ,D1))
$P(^DGPT(DA, P ,D1,0),U,M)
M=1,5,6,7,8,9\n
$P(^DGPT(DA,70),U,M)
M=10,11,16,17,18,19,20,21,22,23,24\n
$O(^DGPT(DA, M ,D1))
$P(^DGPT(DA, M ,D1,0),U,N)
N=5,6,7,8,9,10,11,12,13,14,15", "", "", ""], ["4178", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "GEN. MED. REC. - VITALS", "2003/08/05", "APPROVED", "Active", "Private", "120.5", "", "", "", ""], ["4179", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "LAB SERVICE", "2005/09/29", "APPROVED", "Active", "Private", "63", "
The following global references are made:\n
Global Nodes\n
LR (CH) $O(^LR(LRDFN))
$P(^LR(LRDFN,0),U,2)
$O(^LR(LRDFN,"CH",LRIDT))
$P(^LR(LRDFN,"CH",LRIDT,0),U,3)
$O(^LR(LRDFN,"CH",LRIDT,LRDN))\n
LR (AP) $O(^LR(LRDFN))
$P(^LR(LRDFN,0),U,2)
$O(^LR(LRDFN,APSUB,LRIDT)
APSUB="CY","EM","SP"
$P(^LR(LRDFN,APSUB,LRIDT,0),U,M)
M=3,6,11
$O(^LR(LRDFN,APSUB,LRIDT,.1,SPEC))
$P(^LR(LRDFN,APSUB,LRIDT,.1,SPEC,0),U,1)
$O(^LR(LRDFN,APSUB,LRIDT,.1,SPEC,1,PREP))
$O(^LR(LRDFN,APSUB,LRIDT,.1,SPEC,1,PREP,1,TEST))
$P(^LR(LRDFN,APSUB,LRIDT,.1,SPEC,1,PREP,1,TEST,0),U,1)\n
$O(^LR(LRDFN,APSUB,LRIDT,3,ICD))
$G(^LR(LRDFN,APSUB,LRIDT,3,ICD,0))\n
$O(^LR(LRDFN,APSUB,LRIDT,2,I))
$G(^LR(LRDFN,APSUB,LRIDT,2,I,0))\n
$O(^LR(LRDFN,APSUB,LRIDT,2,I,SUB,II)
SUB=1,2,3,4
$G(^LR(LRDFN,APSUB,LRIDT,2,I,SUB,II,0)
$O(^LR(LRDFN,APSUB,LRIDT,2,I,SUB,II,1,III))
$G(^LR(LRDFN,APSUB,LRIDT,2,I,SUB,II,1,III,0))\n
$G(^LR(LRDFN,"AU"))
$O(^LR(LRDFN,33,SPEC))
$G(^LR(LRDFN,33,SPEC,0))
$O(^LR(LRDFN,80,ICD))
$G(^LR(LRDFN,80,ICD,0))
$O(^LR(LRDFN,"AY",I))
$G(^LR(LRDFN,"AY",I,0))
$O(^LR(LRDFN,"AY",I,SUB,II))
SUB=1,2,3,4
$G(^LR(LRDFN,"AY",I,SUB,II,0))
$O(^LR(LRDFN,"AY",I,SUB,II,1,III))
$G(^LR(LRDFN,"AY",I,SUB,II,1,III,0))\n
LR (Micro) $O(^LR(LRDFN))
$P(^LR(LRDFN,0),U,2)
$O(^LR(LRDFN,"MI",LRIDT))
$G(^LR(LRDFN,"MI",LRIDT,0))\n
$O(^LR(LRDFN,"MI",LRIDT,3,ORGNUM))
$G(^LR(LRDFN,"MI",LRIDT,3,ORGNUM,0))
$O(^LR(LRDFN,"MI",LRIDT,3,ORGNUM,ABDN))
$G(^LR(LRDFN,"MI",LRIDT,3,ORGNUM,ABDN))\n
$O(^LR(LRDFN,"MI",LRIDT,SUB))
SUB=5,8,11,16
$O(^LR(LRDFN,"MI",LRIDT,SUB+1,ORGNUM))
$G(^LR(LRDFN,"MI",LRIDT,SUB+1,ORGNUM,0))
$O(^LR(LRDFN,"MI",LRIDT,12,ORGNUM,TBDN))
$G(^LR(LRDFN,"MI",LRIDT,12,ORGNUM,TBDN))", "", "", ""], ["4180", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "ORDER ENTRY/RESULTS REPORTING", "2003/08/11", "APPROVED", "Active", "Private", "100", "", "", "", ""], ["4181", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "PHARMACY DATA MANAGEMENT", "2004/06/29", "", "Retired", "Private", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006. The following global references are made:\n
Global Nodes\n
PS(55) $O(^PS(55,DFN))\n
$O(^PS(55,DFN,5,DA)
$P(^PS(55,DFN,5,DA,2),U,M)
M=2,4
$O(^PS(55,DFN,5,DA,1,DA1))
$P(^PS(55,DFN,5,DA,1,DA1,0),U,1)\n
$O(^PS(55,DFN, IV ,DA))
$P(^PS(55,DFN, IV ,DA,0),U,M)
M=2,3\n
$O(^PS(55,DFN, IV ,DA, AD ,DA1))
ADD=$P(^PS(55,DFN, IV ,DA, AD ,DA1,0),U,1)
$P(^PS(52.6,ADD,0),U,2)\n
$O(^PS(55,DFN, IV ,DA, SOL ,DA1))
SOL=$P(^PS(55,DFN, IV ,DA, SOL ,DA1,0),U,1)
$P(^PS(52.7,SOL,0),U,2)", "", "", ""], ["4182", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52", "
The following global references are made:\n
Global Nodes\n
PSRX $O(^PSRX(DA))
$P(^PSRX(DA,0),U,M)
M=2,6,8
$P(^PSRX(DA,2),U,13)\n
$O(^PSRX(DA,1,DA1))
$P(^PSRX(DA,1,DA1,0),U,M)
M=10,18\n
$O(^PSRX(DA, P ,DA1))
$P(^PSRX(DA, P ,DA1,0),U,M)
M=10,19\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["4183", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2003/08/05", "APPROVED", "Active", "Private", "70", "
The following global references are made:\n
Global Nodes\n
RADPT $O(^RADPT(IEN))
$P(^RADPT(IEN,"DT",0),U,4)\n", "", "", ""], ["4184", "KIDS Install Start/Complete Times", "File", "KERNEL", "2004/10/22", "APPROVED", "Active", "Private", "9.7", "", "", "", ""], ["4185", "DISK CONSUMPTION ESTIMATE FOR CLINICAL REMINDERS", "File", "LAB SERVICE", "2003/08/06", "APPROVED", "Active", "Private", "68", "
The following global references are made:\n
Global Nodes\n
LRO(68, $O(^LRO(68,AA))
$G(^LRO(68,AA,0))
$O(^LRO(68,AA,1,LRAD,1,LRAN,4,TEST))", "", "", ""], ["4186", "M2M BROKER - M Client/Server Connection", "Routine", "RPC BROKER", "2003/08/07", "APPROVED", "Active", "Supported", "", "
$$CONNECT^XWBM2MC()- This API establishes the initial
connection to the VISTA M server. It is a function call that returns a
success/fail indicator of 1 or 0, respectively.", "", "", ""], ["4187", "M2M BROKER - Set Application Context", "Routine", "RPC BROKER", "2003/08/07", "APPROVED", "Active", "Supported", "", "
$$SETCONTX^XWBM2MC() - This API sets the context. It
sets up the necessary environment to run the RPCs. It is a function call that
returns a success/fail indicator of 1 or 0, respectively.", "", "", ""], ["4188", "M2M BROKER - Build the PARAM Data Structure", "Routine", "RPC BROKER", "2003/08/07", "APPROVED", "Active", "Supported", "", "
$$PARAM^XWBM2MC() - This API sets up the PARAM data
structure necessary to run the RPCs. This is a function call that returns a
success/fail indicator of 1 or 0, respectively.", "", "", ""], ["4189", "M2M BROKER - Build the Remote Procedure Data Structure", "Routine", "RPC BROKER", "2003/08/07", "APPROVED", "Active", "Supported", "", "
$$CALLRPC^XWBM2MC() - This API builds the Remote
Procedure Call (RPC) data structure, and then makes the call to the RPC on the
server. The request message is transported in XML and is parsed by using the
VISTA Extensible Markup Language (XML) Parser, introduced in Kernel Toolkit
Patch XT*7.3*58.\n
This API is a function call returning a success/fail indicator of 1 or 0,
respectively.", "", "", ""], ["4190", "M2M BROKER - Close Connection", "Routine", "RPC BROKER", "2003/08/07", "APPROVED", "Active", "Supported", "", "
$$CLOSE^XWBM2MC() - This API closes the connection
between that particular instance of the "requesting" VISTA M server and the
"receiving" VISTA M server, and does any necessary cleanup. It is a function
call that returns a success/fail indicator of 1 or 0, respectively.", "", "", ""], ["4191", "M2M BROKER - Returns CURRENT Application Context", "Routine", "RPC BROKER", "2003/08/07", "APPROVED", "Active", "Supported", "", "
$$GETCONTX^XWBM2MC() - This API returns the current
application context so that a new context may be established, thereby
restoring the previous application context prior to switching to the new one.
It is a function call returning a success/fail indicator of 1 or 0,
respectively.", "", "", ""], ["4192", "DBIA4192", "Routine", "REGISTRATION", "2003/08/13", "APPROVED", "Active", "Private", "", "
As part of the Transitional Pharmacy Benefit project, a
patient must be enrolled to become eligible for the benefit, along with other
criteria. One of the functions to determine enrollment is to determine the
category of the current enrollment, which is what the $$CATEGORY^DGENA4 call
provides.", "", "DGENA4", "2019/09/20"], ["4193", "DBIA4193", "Routine", "SCHEDULING", "2003/08/20", "APPROVED", "Active", "Private", "", "
As part of the Transitional Pharmacy Benefit project, a
list of eligible patients must be built upon install of the patches that make
up this project. There are various criteria used to determine eligibility, and
part of this process involves retrieving appointment information from the
PATIENT (#2) file, which is what the SDPHARM routine does.", "", "SDPHARM", ""], ["4194", "DBIA4194", "Routine", "SCHEDULING", "2003/08/13", "APPROVED", "Active", "Private", "", "
As part of the Transitional Pharmacy Benefit project, a
list of eligible patients must be built upon install of the patches that make
up this project. There are various criteria used to determine eligibility, and
part of this process involves retrieving information from the SD WAIT LIST
(#409.3) file, and it's associated files, which is what the SDPBE routine
does.", "", "SDPBE", ""], ["4195", "DBIA4195", "Routine", "OUTPATIENT PHARMACY", "2003/08/11", "APPROVED", "Active", "Private", "", "
This call tells a subscribing package if a prescription
has been designated as a Transitional Pharmacy Benefit prescription.", "", "PSOTPCUL", ""], ["4196", "DBIA4196", "Routine", "SCHEDULING", "2003/08/20", "APPROVED", "Active", "Private", "", "
The Scheduling package will provide a default
Institution and default Station Number to Outpatient Pharmacy, based on future
appointments for patients, when someone is attempting to add a patient to the
TPB ELIGIBILITY (#52.91) File. The Scheduling package will also provide the
nearest Primary Care Appointment date and Hospital Location of that
appointment for a patient.", "", "SDPHARM1", ""], ["4197", "Imaging - Procedure Modifier", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2003/08/11", "APPROVED", "Active", "Private", "71.2", "
Imaging is granted permission to read Radiology file
#71.2 (PROCEDURE MODIFIER). The information is being displayed on VistARad
workstations.", "", "", ""], ["4198", "PATIENT ADDRESS EDIT API", "Routine", "REGISTRATION", "2003/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
The API allows the user to edit patient's mailing
address.", "", "DGREGAED", "2021/07/06"], ["4199", "Order verification calls", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/13", "APPROVED", "Active", "Private", "", "
This documents Care Management's use of code in ORCACT1
to ensure that order verification by nurses is done consistently with CPRS.", "", "ORCACT1", ""], ["4200", "NMSP~ORCD", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/13", "APPROVED", "Active", "Private", "", "
Routine ORCD contains CPRS utilities for order dialogs;
Care Management would like permission to call the $$NMSP function.", "", "ORCD", ""], ["4201", "EN~ORCSEND", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/13", "APPROVED", "Active", "Controlled Subscription", "", "
This routine handles the release of orders from CPRS to
the ancillary services when appropriate.", "", "ORCSEND", ""], ["4202", "TEXT~ORQ12", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/13", "APPROVED", "Active", "Controlled Subscription", "", "
Returns the text of an order for display.", "", "ORQ12", "2023/08/21"], ["4203", "DETAIL~ORQ2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/13", "APPROVED", "Active", "Controlled Subscription", "", "
Returns the Detailed Display report for an order.", "", "ORQ2", ""], ["4204", "DEFLIST~ORQPTQ11", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
CPRS Patient List api's.", "", "ORQPTQ11", ""], ["4205", "DBIA4205", "Routine", "REGISTRATION", "2003/12/23", "APPROVED", "Active", "Controlled Subscription", "", "
API to allow access to Inpatient CPTs and Inpatient
POVs.", "", "DGAPI", ""], ["4206", "TEAMPTS~ORQPTQ1", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
CPRS Patient List api's.", "", "ORQPTQ1", ""], ["4207", "PTS~ORQPTQ2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
CPRS Patient List api's.", "", "ORQPTQ2", ""], ["4208", "MY TEST", "Other", "KERNEL", "2010/12/13", "", "Pending", "Private", "", "", "", "", ""], ["4209", "VistALink J2M Java APIs [vljFoundationsLib-x.x.x.xxx.jar]", "Other", "VISTALINK", "2007/03/01", "", "Withdrawn", "Supported", "", "\n
This ICR describes the supported VistALink J2M (v1.5) Java APIs for
the vljFoundationsLib-x.x.x.xxx.jar file.\n
It is strongly recommended that you consult the javadoc for the
VistALink J2M software for more detail on all supported VistALink
J2M Java APIs.\n\n
Jar:
vljFoundationsLib-x.x.x.xxx.jar\n
Foundations Library Utilities Packages:
gov.va.med.crypto
gov.va.med.environment
gov.va.med.exception
gov.va.med.monitor.time
gov.va.med.net
gov.va.med.xml\n\n\n
Package gov.va.med.crypto
=========================
Contains cryptology related utility classes (Kernel hash).\n
Class Summary
=============
VistaKernelHash
Implements static methods to provide the encoding algorithms
used by the RPC Broker and Kernel to encode and decode data
strings.\n
Exception Summary
=================
VistaKernelHashCountLimitExceededException
Represents an exception identifying that the Hash Count Limit
(for a call to the VistaKernelHash encrypt method) has been
exceeded.\n\n
Package gov.va.med.environment
==============================
APIs for accessing J2EE environment information.\n
Class Summary
=============
Environment
Environment settings for J2EE server use.\n
ServerType
Enumerated J2EE server types.\n\n
Package gov.va.med.exception
============================
Contains exception handling utility classes.\n
Interface Summary
=================
FoundationsExceptionInterface
Represents the interface that all Foundations exceptions
implement.\n
Class Summary
=============
ExceptionUtils
Exposes utility methods for handling exceptions.\n
Exception Summary
=================
FoundationsException
Nested exception handling code is identical to
VistaLinkResourceException nested exception handling code.\n\n
Package gov.va.med.monitor.time
===============================
Contains resource execution time monitoring utility classes.\n
Class Summary
=============
AuditTimer
This class gives an easy way to capture performance statistics
and log them to a log file.\n\n
Package gov.va.med.net
======================
Foundations TCP socket functionality for communicating with IP
endpoints.\n
Class Summary
=============
SocketManager
Represents a socket that can be used to communicate with IP
endpoints.\n
Exception Summary
=================
VistaSocketException
Represents an exception thrown during read/write operations
on a socket.\n
VistaSocketTimeOutException
Represents an exception identifying a timeout has occurred
during read/write operations.\n\n
Package gov.va.med.xml
======================
General Foundations utility class for working with XML.\n
Class Summary
=============
XmlUtilities
This class contains a number of static utility methods to help
developers work with XML documents, nodes, attributes and
strings.", "", "", ""], ["4210", "ORQQVS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
APIs to return the details or text of documents.", "", "ORQQVS", ""], ["4211", "VST~ORWCV", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
Returns patient visits within a timeframe.", "", "ORWCV", ""], ["4212", "ORWPCE", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
CPRS visit utilities", "", "ORWPCE", ""], ["4213", "ORWPCE2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
Returns CPRS visit parameter values.", "", "ORWPCE2", ""], ["4214", "ORWPCE3", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
CPRS utilities to return encounter data.", "", "ORWPCE3", ""], ["4215", "ORWPT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/08/15", "APPROVED", "Active", "Private", "", "
CPRS patient utilities.", "", "ORWPT", ""], ["4216", "PATIENT APPOINTMENT EXISTS", "Routine", "SCHEDULING", "2003/08/25", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA contains an API that checks for the existence
of any appointment for a specific patient.", "", "SDAMA204", ""], ["4217", "VDEMINST Routine calling File 4", "File", "VDEM", "2003/08/20", "", "Withdrawn", "Private", "4", "
This IA was created becuase of the routines dependancy
with the Instatution file #4. The routine will loop through the file and
extract data elements of key fields. The data will be used to support the VDEM
extraction application.", "", "VDEMINST", ""], ["4218", "VDEMRADN Routine Calling file #71", "File", "VDEM", "2003/08/20", "", "Withdrawn", "Private", "71", "
This IA was created becuase of the routines dependancy
with the file #71. The routine will loop through the file and extract data
elements from key fields. The data will be used to support the VDEM extration
application.", "", "VDEMRADN", ""], ["4219", "VDEMLABG", "Routine", "VDEM", "2003/08/20", "", "Withdrawn", "Supported", "", "
This routine is used by the VDEM to handle Lab
information. It uses global ^LAB(60, ^LAB(61, ^LAB(62, ^LAB(64.061, ^LAB(95.3
and LAM(......", "", "VDEMLABG", ""], ["4220", "DBIA4220-A", "File", "REGISTRATION", "2003/11/17", "APPROVED", "Active", "Controlled Subscription", "46", "
Allow the use of the .01 field in file 46 to logically
conect the orders file to the Inpatient CPT file. All access to the Inpatient
CPT file will be made using the DGAPI routine.", "", "", ""], ["4221", "INPATIENT POV FILE", "File", "REGISTRATION", "2003/11/12", "APPROVED", "Active", "Controlled Subscription", "46.1", "", "", "", ""], ["4222", "BPS NCPDP DELAY REASON CODE", "File", "E CLAIMS MGMT ENGINE", "2010/12/13", "APPROVED", "Active", "Private", "9002313.29", "
Integrated Billing (IB) is using a Fileman look-up into
the BPS NCPDP DELAY REASON CODE (#9002313.29) file in order to ask the user to
choose a valid delay reason code during the IB back billing process.\n
Amendment: Effective 5/15/23, added fields .02, .03 and 2", "", "", "2023/05/16"], ["4223", "DBIA4223", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52.91", "
The Scheduling package looks at the 0 node of the TPB
ELIGIBILITY file (#52.91) to see if an entry has already been created for a
patient in that file. This is done so that on subsequent installs of patch
PSO*7*145 (Phase I of the Transitional Pharmacy Benefit project), a patient is
not flagged as potentially being automatically entered in that file by the
Appointment and EWL logic, if a patient is already in the file from a previous
install. This is done to prevent automatic changes to an entry that has
already been manually edited.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["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", ""], ["4225", "Event Monitor APIs - HLEVAPI", "Routine", "HEALTH LEVEL SEVEN", "2003/08/26", "", "Withdrawn", "Controlled Subscription", "", "
Enhancement patch HL*1.6*106 contains the VistA HL7
Event Monitor system. The Event Monitor system facilitates the process of
monitoring the VistA HL7 environment for conditions and events, as well as
notification of the VistA HL7 support and development personnel.\n
The Event Monitor system includes new files and options, as well as the eight
application program interfaces (APIs) documented in this integration
agreement.\n
The Event Monitor system is built around:\n
- Monitors
- Master Job\n
The Monitor is built around an entry in the HL7 Monitor file (#776.1) that
"points" to an M code API. The monitor also includes a field that specifies
how many minutes should elapse between every "run" of the monitor.\n
The Master Job runs every few hours perpetually. It checks every monitor
entered in the HL7 Monitor file to determine whether the monitor should be
run. If it is time for a monitor "run", the master job queues a background
job for the specific monitor.\n
The primary task of the master job is to start individual monitor jobs, and to
record the result of it's evaluation of every monitor; whether it was started
or not, and the reason for the action taken.\n
The APIs created by patch HL*1.6*106 and included in integration agreements
4225, 4226 and 4227 are:\n
- $$START^HLEVAPI - CHECKIN^HLEVAPI - CHECKOUT^HLEVAPI
- MAILIT^HLEVAPI - ABORT^HLEVAIP - VARIABLE^HLEVAPI
- ONOFF^HLEVAPI0 - APPSTAT^HLEVAPI1 - MSGTEXT^HLEVAPI
- RUNDIARY^HLEVAPI1\n
Application developers wishing to use the Event Monitor system, including
these APIs, must secure permission from the VistA HL7 development team.\n
--------------------------------------------------------------------------\n
Please peruse the APIs documented in this integration agreement in the
following order:\n
- START^HLEVAPI - CHECKIN^HLEVAPI - CHECKOUT^HLEVAPI
- VARIABLE^HLEVAPI\n
The above APIs form a conceptual unit.\n
The MAILIT^HLEVAPI and the ABORT^HLEVAPI APIs may be reviewed in any order,
but they should be reviewed after the four APIs listed above.", "", "HLEVAPI", ""], ["4226", "Event Monitor APIs - HLEVAPI0", "Routine", "HEALTH LEVEL SEVEN", "2003/08/26", "", "Withdrawn", "Controlled Subscription", "", "
Integration agreements 4225, 4226 and 4227 cover the
supported APIs for the VistA HL7 Event Monitor system. Integration agreement
4225 covers the HLEVAPI routine APIs, and agreement 4227 covers the HLEVAPI1
routine APIs. This agreement covers the HLEVAPI0 routine's APPSTAT^HLEVAPI0
API.\n
Please read the GENERAL DESCRIPTION of integration agreement# 4225 before
continuing.\n
-------------------------------------------------------------------------\n
Monitors are defined in the HL7 Monitor file (#776.) The STATUS field (#2) in
this file can be used to turn monitors on (when set to ACTIVE) or off (when
set to INACTIVE.) The $$ONOFFM^HLEVAPI0 API, covered by this integration
agreement, is discussed below.\n
Application developers wishing to use the Event Monitor system, including
these APIs, must secure permission from the VistA development team.", "", "HLEVAPI0", ""], ["4227", "Event Monitor APIs - HLEVAPI1", "Routine", "HEALTH LEVEL SEVEN", "2003/08/26", "", "Withdrawn", "Controlled Subscription", "", "
Integration agreements 4225, 4226 and 4227 cover the
supported APIs for the VistA HL7 Event Monitor system. Integration agreement
4225 covers the HLEVAPI routine APIs, and agreement 4227 covers the HLEVAPI1
routine APIs. This agreement covers the HLEVAPI0 routine's APPSTAT^HLEVAPI0
API.\n
Please read the GENERAL DESCRIPTION of integration agreement# 4225 before
continuing.\n
-------------------------------------------------------------------------\n
The APIs covered in the COMPONENT sections below are:\n
- APPSTAT^HLEVAPI1 - MSGTEXT^HLEVAPI1 - RUNDIARY^HLEVAPI1\n
Application developers wishing to use the Event Monitor system, including
these APIs, must secure permission from the VistA development team.", "", "HLEVAPI1", ""], ["4228", "DISTRIBUTION OF XHD PARAMETER CATEGORY FILE (#8935.91)", "File", "HEALTHEVET DESKTOP", "2003/09/09", "APPROVED", "Active", "Private", "8935.91", "
This agreement is provided to the CARE MANAGEMENT
package version 1.0, to distribute both data and full data dictionary from the
XHD PARAMETER CATEGORY file (#8935.91).", "", "", ""], ["4229", "DBIA 4229", "File", "1", "2003/08/29", "APPROVED", "Active", "Private", "", "
A dangling "IX" node needs to be cleaned up for subfile
811.22102.", "", "", ""], ["4230", "DBIA4230", "Routine", "CLINICAL PROCEDURES", "2004/05/25", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA documents the usage of the MDPS1 entry points
for displaying the Clinical Procedures result reports.", "", "MDPS1", ""], ["4231", "DBIA4231", "Routine", "HEALTH SUMMARY", "2004/05/07", "APPROVED", "Active", "Private", "", "
This IA is used to document the CKP^GMTSUP entry point
usage.\n
CKP^GMTSUP Checks for the end of page and issues a page break if the number of
lines printed is equal to or greater than the page length minus the offset
(IOSL-GMTSLO).\n
There are no input parameters, however, this entry point expects to see the
following pre-existing variables in the environment:\n
IOST Terminal Type IOF
Form Feed IOSL
Page Length GMTSLO Lines
Off-Set (number of lines before IOSL where you break the
page) GMTSLPG
Last Page Indicator Flag (set to 0 except on last page) GMTSDTM Date
and Time (external) GMTSEG( Segment
Array GMTSEGN Segment Number
- GMTSEG(GMTSEGN) GMTSLCMP Last Component Number
GMTSTITL Component Title
GMTSPHDR( Header Array w/Patient Demographics\n\n
Note: The GMTSPHDR can be set by setting DFN and calling DEM^GMTSU.", "", "GMTSUP", "2018/04/20"], ["4232", "XUSERP", "Routine", "KERNEL", "2003/09/22", "APPROVED", "Active", "Controlled Subscription", "", "
When the user file is edited a call should be made to
CALL^XUSERP(...) so that other applications or system can be updated.", "", "XUSERP", ""], ["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", ""], ["4237", "DBIA4237", "Routine", "PHARMACY DATA MANAGEMENT", "2003/09/22", "APPROVED", "Active", "Supported", "", "
This supported reference is available to allow users to
pass in a patient's internal file number (dfn) in the form of a function call
to indicate if that patient has at least one active prescription.\n
S X=$$EN^PSSRXACT(DFN). 1 is returned if the patient has at least one active
Rx, else 0 (zero) is returned indicating no active prescriptions.", "", "PSSRXACT", ""], ["4238", "DBIA4238-A", "Routine", "REGISTRATION", "2003/09/16", "APPROVED", "Active", "Private", "", "
Integrated Billing calls the HL7 function
$$MFE^VAFHLMFE when constructing the HL7 messages that are passed on through
Vitria for insurance confirmation.", "", "VAFHLMFE", ""], ["4239", "DBIA4238-B", "Routine", "REGISTRATION", "2003/09/16", "APPROVED", "Active", "Private", "", "
Integrated Billing calls the HL7 function
$$MFI^VAFHLMFI when constructing the HL7 messages that are passed on through
Vitria for insurance confirmation.", "", "VAFHLMFI", ""], ["4240", "DBIA4240", "File", "PCE PATIENT CARE ENCOUNTER", "2003/09/16", "APPROVED", "Active", "Private", "9000010", "
The IIV (Insurance Identification and Verification)
enhancement patch IB*2.0*184, performs a direct file reference to the "B" and
"AA" cross- references as it loops through visit records as part of the IIV
data extracts. This applies only to extract #3 (Past encounters, non-verified
ins.) and #4 (Past encounters, No Insurance). These extracts reside
in routines IBCNEDE3 and IBCNEDE4 respectively.\n
In addition, the extract routines also performs a direct global read of
the "0" node ^AUPNVSIT(IEN,0) to retrieve the patient's DFN (5th piece)
value from the visits as they are looped-through.", "", "", ""], ["4241", "DBIA4241", "File", "HEALTH LEVEL SEVEN", "2004/08/18", "APPROVED", "Active", "Controlled Subscription", "870", "\n
The BPS 1.0 Master Build, performs Fileman references and modifications to
the HL7 LOGICAL LINK File (#870) to retrieve and/or modify the IP address,
port number, Domain and startup node information for the logical links that
are installed by the BPS software. This information is needed when installing
the above patch and subsequently when the BPS applications validate the status
of the links.", "", "", ""], ["4242", "DBIA4242", "File", "REGISTRATION", "2003/09/16", "APPROVED", "Active", "Private", "43", "
The IIV (Insurance Identification and Verification)
enhancement patch IB*2.0*184, performs a direct file references to the CLINIC
EXCLUSION (43.04,.01) cross-reference, ^DG(43,DA(1),"DGPREC","B",CLNC) and
also the ELIGIBILITY EXCLUSION (43.08,.01)cross-reference, ^DG(43,DA(1),
"DGPREE","B",ELG) of the MAS PARAMETERS File (#43). These references
are made as part of the future appointment data extract (#2 - in routine
IBCNEDE2),to determine whether or not future visits should be excluded
from the IIV extract.", "", "", ""], ["4243", "DBIA4243", "File", "REGISTRATION", "2003/09/16", "APPROVED", "Active", "Private", "408.13", "
The IIV (Insurance Identification and Verification)
enhancement patch IB*2.0*184, performs a direct file reference to the PATIENT
RELATION file (#408.12). It is used to determine if the insured is the
veteran, the spouse, or another relationship. If it is the veteran or the
spouse the demographic information is pulled directly from the PATIENT file
(#2). If the relationship is 'other', the associated entry in the insured
INCOME PERSON file (#408.13) is examined. If the PATIENT field (#365.13, .04)
in the INCOME PERSON file is populated, the demographic information is pulled
from that relative's record in the PATIENT file. Otherwise, the demographic
information is directly retrieved from the INCOME PERSON file. This call is
used in the routine IBCNEHLQ.", "", "", ""], ["4244", "DBIA4244", "File", "REGISTRATION", "2003/09/16", "APPROVED", "Active", "Private", "408.12", "
The IIV (Insurance Identification and Verification)
enhancement patch IB*2.0*184, performs a direct file reference to the PATIENT
RELATION file (#408.12). It is used to determine if the insured is the
veteran, the spouse, or another relationship. If it is the veteran or the
spouse the demographic information is pulled directly from the PATIENT file
(#2). If the relationship is 'other', the associated entry in the insured
INCOME PERSON file (#408.13) is examined. If the PATIENT field (#365.13, .04)
in the INCOME PERSON file is populated, the demographic information is pulled
from that relative's record in the PATIENT file. Otherwise, the demographic
information is directly retrieved from the INCOME PERSON file. This call is
used in the routine IBCNEHLQ.", "", "", ""], ["4245", "DBIA4245", "Routine", "LAB SERVICE", "2003/11/06", "APPROVED", "Active", "Controlled Subscription", "", "
APIs for retrieving Lab data.\n
Arguments enclosed with brackets are optional. Arguments without brackets are
required. Arguments preceded by a period should be called by reference.\n", "", "LRPXAPI", ""], ["4246", "DBIA4246", "Routine", "LAB SERVICE", "2003/11/06", "APPROVED", "Active", "Controlled Subscription", "", "
APIs for use with Lab data.\n
Arguments enclosed with brackets are optional. Arguments without brackets are
required. Arguments preceded by a period should be called by reference.\n", "", "LRPXAPIU", ""], ["4247", "4247", "Routine", "LAB SERVICE", "2004/11/20", "APPROVED", "Active", "Private", "", "
This routine and entry point is used fo building the
Clinical Reminders Index for the LAB DATA file, #63. There are no required
variables.", "", "LRPXSXRL", ""], ["4248", "VDEF MESSAGE-BUILDING UTILITIES", "Routine", "VISTA DATA EXTRACTION FRAMEWORK", "2004/08/24", "APPROVED", "Active", "Controlled Subscription", "", "
In the VDEF process, domain-specific routines build
messages that are sent to the HL7 system for distribution. This IA contains
utilities that perform common functions often needed by these message building
routines.", "", "VDEFEL", ""], ["4249", "DIRECT READ OF THE MORPHOLOGY FIELD FILE", "File", "LAB SERVICE", "2004/08/24", "APPROVED", "Active", "Controlled Subscription", "61.1", "
Clinical Reminders is requesting permission to do a
direct read on piece 1 and 2 of File #61.1 zero node.", "", "", ""], ["4250", "PCE APIs FOR THE CLINICAL REMINDERS INDEX", "Routine", "PCE PATIENT CARE ENCOUNTER", "2004/09/15", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR will provide subscribing packages the ability
to get data from the PCE V-files\n", "", "PXPXRM", "2024/03/14"], ["4251", "GMVDCEXT", "Routine", "GEN. MED. REC. - VITALS", "2003/09/29", "APPROVED", "Active", "Private", "", "", "", "GMVDCEXT", ""], ["4252", "SET LAYGO NODE IN FILE 50.416", "File", "1", "2004/08/31", "APPROVED", "Active", "Private", "50.416", "
National Drug File requests a one time integration
agreement with VA FileMan to set the LAYGO node in DD(50.416) to prevent sites
from making local additions to this national file. Additions will only be
made by data update patches.\n", "", "", ""], ["4253", "VDEF MESSAGE QUEUING", "Routine", "VISTA DATA EXTRACTION FRAMEWORK", "2004/09/01", "APPROVED", "Active", "Controlled Subscription", "", "
This IA decribes the API used to request that a message
be created and sent by the VDEF system. It's successful use is dependent on
entries made in the correct VDEF and HL7 files.", "", "VDEFQM", ""], ["4254", "JULIE TESTING", "Routine", "VENDOR - AUDIOFAX, INC.", "2007/03/06", "", "Pending", "Private", "", "
TESTING", "", "TEST", ""], ["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:\n
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)", "", "", ""], ["4256", "VDEMPROC Routine calling File 71.2", "File", "VDEM", "2003/09/24", "", "Withdrawn", "Private", "71.2", "
This IA was created becuase of the routines dependancy
with the Rad-Nuc file 71.2. The routine will loop through the file and extract
data elements from key fields. The data will be used to support the VDEM
extraction application.", "", "VDEMPROC", ""], ["4257", "Get *ALL* TIU Title IENS", "Routine", "TEXT INTEGRATION UTILITIES", "2007/03/08", "APPROVED", "Active", "Controlled Subscription", "", "
The CPRS GUI Graphing Utility requires a list of ALL
TIU TITLES. This API facilitates Progress Note Graphing as it looks up TIU
documents via TIU Titles.\n
This API does not make ANY checks on the Titles returned.
Examples: -
They may (or may not) be active, 'NORMAL' Progress Note Titles.\n
- They could be of any status.\n
- They could be used only by a package uploading notes into TIU.\n
- They may or may not be in the Progess Notes Document Type Class, or even in
the Clinical Documents Hierarchy.\n
- USR business rules may not permit various actions such as Entering notes on
these Titles, Viewing them, or Printing them.", "", "TIULX", "2007/03/06"], ["4258", "PXRM CPRS CALLS FOR GEC", "Routine", "CLINICAL REMINDERS", "2003/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will cover the GEC entry points use by CPRS
in PXRMGECU:\n
API^PXRMGECU Evaluate what Visit the GEC Referral should be store with.\n
FINISHED^PXRMGECU Use to determine if a GEC Referral is completed.\n
$$STATUS^PXRMGECU Return text describing the status of a GEC Referral", "", "PXRMGECU", ""], ["4259", "WOMEN VETERAN REPORT LOOKUP", "Remote Procedure", "WOMEN'S HEALTH", "2003/09/25", "", "Withdrawn", "Controlled Subscription", "", "
This API will return the most recent unprocessed entry
report text in the WV PROCEDURE FILE, file# 790.1", "", "", ""], ["4260", "AR/CSL Application ACK process", "Routine", "ACCOUNTS RECEIVABLE", "2004/01/13", "APPROVED", "Active", "Controlled Subscription", "", "
After process the acknowledgement from CoreFLS, CSL
will pass the information to AR.", "", "PRCAFLS3", ""], ["4261", "AR/CSL Status Update Process", "Routine", "ACCOUNTS RECEIVABLE", "2003/09/26", "", "Withdrawn", "Controlled Subscription", "", "
After process the Status Update from CoreFLS, CSL will
pass the information back to AR.", "", "PRCAFLS6", ""], ["4262", "MESSAGE BODY DELETION", "Routine", "HEALTH LEVEL SEVEN", "2003/09/29", "APPROVED", "Active", "Supported", "", "
This integration covers the use of the DELBODY^HLUOPT2
API. This API deletes all segments of a VistA HL7 message except the MSH
segment. See patch HL*1.6*98 for additional explanation and information.", "", "HLUOPT2", ""], ["4263", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "ADVERSE REACTION TRACKING", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of
ADVERSE REACTION TRACKING:
ADT^A60\n
The folllowing VDEF extraction lists are under the custody of ADVERSE REACTION
TRACKING:\n
PID-0-PTALG
IAM-0-PTALG
IAM-5-PTALG-S-REACTS
ROL-0-PTALG-ALORG
ROL-0-PTALG-ALVER
ROL-0-PTALG-ALERR
ROL-0-PTALG-S-ALCHM
NTE-0-PTALG-S-CMTS
NTE-3-PTALG-S-CMTS-S-CMTS
ROL-0-PTALG-S-CMTS
Z01-0-PTALG
Z01-13-PTALG-S-DI
Z01-14-PTALG-S-DC
Z03-0-PTALG-S-REACTS
Z03-2-PTALG-S-REACTS
XXX-0-PTALG-RESET-COUNTER", "", "", ""], ["4264", "PDM ACCESS TO PSJXRFS", "Routine", "INPATIENT MEDICATIONS", "2003/11/04", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management has requested permission to
store Inpatient Medications cross-reference set routine PSJXRFS in the Data
Dictionary for a new cross-reference. The new cross reference will create an
index to the to the PHARMACY PATIENT file (#55) at both the UNIT DOSE multiple
(#62) and the IV multiple (#100).", "", "PSJXRFS", ""], ["4265", "PDM ACCESS TO PSJXRFK", "Routine", "INPATIENT MEDICATIONS", "2003/11/04", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management has requested permission to
store Inpatient Medications cross-reference kill routine PSJXRFK in the Data
Dictionary for a new cross-reference. The new cross reference will create an
index to the to the PHARMACY PATIENT file (#55) at both the UNIT DOSE multiple
(#62) and the IV multiple (#100).", "", "PSJXRFK", ""], ["4266", "AMIE 2507 Request APIs", "Routine", "AUTOMATED MED INFO EXCHANGE", "2004/09/07", "APPROVED", "Active", "Controlled Subscription", "", "
These APIs are used to obtain 2507 Request information,
and to create a link between an Appointment and a 2507 Request.\n
Refer to the Components for more information.", "", "DVBCMKLK", ""], ["4267", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "REGISTRATION", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of
REGISTRATION:\n
ADT^A28^PAT
ADT^A28^PTF\n
The following VDEF extraction lists are under the custody REGISTRATION:\n
PID-0-PATIENT-APICALL
PV1-0-PATIENT
ZSP-0-PATIENT-APICALL
ZEL-0-PATIENT-APICALL
ZEM-0-PATIENT-APICALL
PID-0-PTF
PV1-0-PTF
PV1-6-PTF
PV2-0-PTF
Z09-0-PTF
Z09-3-PTF
ROL-0-PTF-S-CC
OBX-0-PTF-SVCCNCT
OBX-0-PTF-AGENTORA
OBX-0-PTF-RADEXP
OBX-0-PTF-ENVCONT
OBX-0-PTF-MST
OBX-0-PTF-HNCA
OBX-0-PTF-SSIIND
OBX-0-PTF-LEGDIS
OBX-0-PTF-SUBSTAB
OBX-0-PTF-PCSEV
OBX-0-PTF-CURRFA
OBX-0-PTF-HLPC
DG1-0-PTF-DXLS
DG1-0-PTF-ICD2-ICD10
DRG-0-PTF-DRG
PR1-0-PTF-S-401
Z07-0-PTF-S-401
PR1-0-PTF-S-601
Z07-0-PTF-S-601
Z08-0-PTF-S-501
Z08-3-PTF-S-501
ROL-0-PTF-S-501
OBX-0-PTF-S-501-SVCCNCT
OBX-0-PTF-S-501-AGENTORA
OBX-0-PTF-S-501-RADEXP
OBX-0-PTF-S-501-ENVCONT
OBX-0-PTF-S-501-MST
OBX-0-PTF-S-501-HNCA
OBX-0-PTF-S-501-SSIIND
OBX-0-PTF-S-501-LEGDIS
OBX-0-PTF-S-501-SUBSTAB
OBX-0-PTF-S-501-PCSEV
OBX-0-PTF-S-501-CURRFA
OBX-0-PTF-S-501-HLPC
DG1-0-PTF-S-501-ICD1
DG1-0-PTF-S-501-ICD2
DG1-0-PTF-S-501-ICD3
DG1-0-PTF-S-501-ICD4
DG1-0-PTF-S-501-ICD5
DG1-0-PTF-S-501-ICD6
DG1-0-PTF-S-501-ICD7
DG1-0-PTF-S-501-ICD8
DG1-0-PTF-S-501-ICD9
DG1-0-PTF-S-501-ICD10
DRG-0-PTF-S-501
Z10-0-PTF-S-CY
XXX-0-PTF-RESET-COUNTER
PV1-0-PTMOVE
PV1-3-PTMOVE-POC
PV1-3-PTMOVE-POC-1
PV1-3-PTMOVE-POC-2
PV1-3-PTMOVE-ROOM
PV1-3-PTMOVE-BED
PV2-0-PTMOVE
Z11-0-PTMOVE
Z11-4-PTMOVE
Z11-5-PTMOVE
Z11-7-PTMOVE
Z11-9-PTMOVE", "", "", ""], ["4268", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "PCE PATIENT CARE ENCOUNTER", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of PCE
PATIENT CARE ENCOUNTER:\n
ADT^A28^ENC
VXU^V04^HFCT
VXU^V04^IMMU
VXU^V04^SKIN\n
The following VDEF extraction lists are under the custody of PCE PATIENT CARE
ENCOUNTER:\n
PID-0-VISIT
PV1-0-VISIT
PV1-3-VISIT
PV1-19-VISIT-IEN
PV1-19-VISIT-ID
PV1-39-VISIT
PV1-50-VISIT
PV2-0-VISIT
ROL-0-VPROV
ROL-3-VPROV-PS
ROL-3-VPROV-OA
ROL-9-VPROV-PC-1-1
ROL-9-VPROV-PC-1-2
ROL-9-VPROV-PC-2-1
ROL-9-VPROV-PC-2-2
ROL-9-VPROV-PC-3-1
ROL-9-VPROV-PC-3-2
NTE-0-VPROV
OBX-0-VISIT-SVCCNCT
OBX-0-VISIT-AGENTORA
OBX-0-VISIT-RADEXP
OBX-0-VISIT-PGEXP
OBX-0-VISIT-MST
OBX-0-VISIT-HNCA
NTE-0-VISIT
PR1-0-VCPT
PR1-3-VCPT
PR1-15-VCPT
PR1-16-VCPT
Z12-0-VCPT
Z12-1-VCPT
Z12-2-VCPT
ROL-0-VCPT-OP
ROL-0-VCPT-EP
NTE-0-VCPT
PR1-0-VEXAM
ROL-0-VEXAM-OP
ROL-0-VEXAM-EP
OBX-0-VEXAM
NTE-0-VEXAM
PRB-0-VPOV
PRB-10-VPOV-PN
PRB-10-VPOV-CT
ROL-0-VPOV-OP
ROL-0-VPOV-EP
OBX-0-VPOV-SVCCNCT
OBX-0-VPOV-AGENTORA
OBX-0-VPOV-RADEXP
OBX-0-VPOV-PGEXP
NTE-0-VPOV
PID-0-HF
PV1-0-HF
ORC-0-HF
RXA-0-HF
OBX-0-HF
NTE-0-HF
PID-0-IMMU
PV1-0-IMMU
PV1-3-IMMU-VISIT-1
PV1-3-IMMU-VISIT-2
ORC-0-IMMU
RXA-0-IMMU
OBX-0-IMMU
NTE-0-IMMU
NTE-0-IMMU-S-REM
PID-0-SKIN
PV1-0-SKIN
PV1-3-SKIN-VISIT-1
PV1-3-SKIN-VISIT-2
ORC-0-SKIN
RXA-0-SKIN
OBX-0-SKIN
NTE-0-SKIN", "", "", ""], ["4269", "VDEF VDEF EXTRACTION LISTS", "Other", "HEALTH LEVEL SEVEN", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF extraction lists are under the
custody of HEALTH LEVEL SEVEN:\n
MSH-0
EVN-0", "", "", ""], ["4270", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "TEXT INTEGRATION UTILITIES", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of TEXT
INTEGRATION UTILITIES:\n
MDM^T02\n
The following VDEF extraction lists are under the custody of TEXT INTEGRATION
UTILITIES:\n
PID-0-TIU
PV1-0-TIU
TXA-0-TIU
TXA-2-TIU
Z41-0-TIU
Z41-0-TIU-EXTLINK
OBX-0-TIU-S-REPTXT", "", "", ""], ["4271", "HL7 MESSAGE TYPE ACCESS", "File", "HEALTH LEVEL SEVEN", "2004/08/31", "APPROVED", "Active", "Private", "771.2", "
This IA allows the VDEF package to point-to and lookup
entries in file #771.2. This access is used to verify that VDEF Extract
Descriptions are based on existing HL7 Message Types.", "", "", ""], ["4272", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "LAB SERVICE", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of LAB
SERVICE:\n
ORU^R01^CHEM
ORU^R01^MICB
ORU^R01^ELMC
ORU^R01^PATH
ORU^R01^CYTO
ORU^R01^AUTP\n
The following VDEF extraction lists are under the custody of LAB SERVICE:\n
PID-0-LABCH
XXX-0-LABCH-APICALL
PID-0-LABMI
XXX-0-LABMI-APICALL
PID-0-LABEM
XXX-0-LABEM-APICALL
PID-0-LABSP
XXX-0-LABSP-APICALL
PID-0-LABCY
XXX-0-LABCY-APICALL
PID-0-LABAU
OBR-0-LABAU
OBX-0-LABAU-AUTINFO
OBX-0-LABAU-DEATH
OBX-5-LABAU-DEATH-TREATSPEC
OBX-0-LABAU-HEIGHT
OBX-0-LABAU-WEIGHT
OBX-0-LABAU-LUNGRT
OBX-0-LABAU-LUNGLT
OBX-0-LABAU-LIVER
OBX-0-LABAU-SPLEEN
OBX-0-LABAU-KIDNEYRT
OBX-0-LABAU-KIDNEYLT
OBX-0-LABAU-HEART
OBX-0-LABAU-BRAIN
OBX-0-LABAU-PGLAND
OBX-0-LABAU-TGLAND
OBX-0-LABAU-PARATHLTUP
OBX-0-LABAU-PARATHLTLO
OBX-0-LABAU-PARATHRTUP
OBX-0-LABAU-PARATHRTLO
OBX-0-LABAU-ADRENLT
OBX-0-LABAU-ADRENRT
OBX-0-LABAU-PANCREAS
OBX-0-LABAU-TESTISLT
OBX-0-LABAU-TESTISRT
OBX-0-LABAU-OVARYLT
OBX-0-LABAU-OVARYRT
OBX-0-LABAU-TVALVE
OBX-0-LABAU-PVALVE
OBX-0-LABAU-MVALVE
OBX-0-LABAU-AVALVE
OBX-0-LABAU-RVENT
OBX-0-LABAU-LVENT
OBX-0-LABAU-PLEURCAVLT
OBX-0-LABAU-PLEURCAVRT
OBX-0-LABAU-PCARDCAV
OBX-0-LABAU-PTONECAV
OBX-0-LABAU-ORGAN-S-OT
OBX-0-LABAU-ORGAN-S-OT-S-IG
OBX-0-LABAU-ORGAN-S-OT-S-IM
OBX-0-LABAU-ORGAN-S-ICD9
NTE-0-LABAU-ORGAN-S-CMTS
NTE-0-LABAU-ORGAN-S-CLINDX
NTE-0-LABAU-ORGAN-S-PATHDX
OBX-0-LABAU-ORGAN-S-ASR
NTE-0-LABAU-ORGAN-S-ASR-S-DESC", "", "", ""], ["4273", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "GEN. MED. REC. - VITALS", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custoday of
GEN. MED. REC. - VITALS:\n
ORU^R01^VTLS\n
The following VDEF extraction list are under the custoday of GEN. MED. REC. -
VITALS:\n
PID-0-VITAL
OBR-0-VITAL
OBX-0-VITALNAME
OBX-15-VITALNAME
OBX-0-VITALINFO
OBX-15-VITALINFO
OBX-0-VITALERR
OBX-0-VITALQUAL
OBX-17-VITALQUAL-1
OBX-17-VITALQUAL-2", "", "", ""], ["4274", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "KERNEL", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of
KERNEL:\n
PMU^B01
PMU^B02\n
The following VDEF extraction lists are under the custody of KERNEL:\n
STF-0-NP
STF-2-NP-PN
STF-2-NP-SS
STF-3-NP
PRA-0-NP
PRA-3-NP-S-RNMC
PRA-6-NP-SW
PRA-6-NP-DEA
PRA-6-NP-VA
ORG-0-NP-S-PC
ORG-6-NP-S-PC-1
ORG-6-NP-S-PC-2
ORG-7-NP-S-PC-1
ORG-7-NP-S-PC-2
ORG-8-NP-S-PC-1
ORG-8-NP-S-PC-2", "", "", ""], ["4275", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "OUTPATIENT PHARMACY", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of
OUTPATIENT PHARMACY:\n
RDE^O11^PRES
RDS^O13^PPAR
RDS^O13^PREF\n
The following VDEF extraction lists are under the custoday of OUTPATIENT
PHARMACY:\n
PID-0-PRES
PV1-0-PRES
PV2-0-PRES
ORC-0-PRES
RXE-0-PRES
RXE-2-PRES-1
RXE-2-PRES-2
RXE-21-PRES-S-PI
RXR-0-PRES-S-MR
OBX-0-PRES-SVCCNCT
OBX-0-PRES-MST
OBX-0-PRES-AGENTORA
OBX-0-PRES-RADEXP
OBX-0-PRES-ENVCONT
OBX-0-PRES-HNCA
NTE-0-PRES-RE
NTE-0-PRES-S-SIG1
NTE-3-PRES-S-SIG1
NTE-0-PRES-S-PC
NTE-3-PRES-S-PC
NTE-0-PRES-PAT
NTE-0-PRES-S-PAT2
NTE-3-PRES-S-PAT2
Z14-0-PRES
Z14-1-PRES
Z14-11-PRES-S-SCHEDS
Z15-0-PRES-S-REFILL
Z16-0-PRES-S-PARTIAL
Z17-0-PRES-S-MEDINSTRS
Z18-0-PRES-S-LOTEXP", "", "", ""], ["4276", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "MENTAL HEALTH", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of
MENTAL HEALTH:\n
PPR^PC1^MTLH\n
The following VDEF extraction lists are under the custody of MENTAL HEALTH:\n
PID-0-MTLH
PRB-0-MTLH
PRB-3-MTLH
ROL-0-MTLH-DB
ROL-0-MTLH-TRANS
OBX-0-MTLH-S-MODS
OBX-0-MTLH-PS
OBX-0-MTLH-S-COMMENT", "", "", ""], ["4277", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "PROBLEM LIST", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of
PROBLEM LIST:\n
PPR^PC1^PROB\n
The following VDEF extraction lists are under the custody of PROBLEM LIST:\n
PID-0-PROB
PV1-0-PROB
PV1-3-PROB-POC
PV1-3-PROB-FACILITY
PRB-0-PROB
ROL-0-PROB-EB
ROL-0-PROB-RECPR
ROL-0-PROB-RESPR
OBX-0-PROB-SVCCNCT
OBX-0-PROB-AGENTORA
OBX-0-PROB-RADEXP
OBX-0-PROB-PGEXP
OBX-0-PROB-HNCA
OBX-0-PROB-MST
OBX-0-PROB-PN
OBX-0-PROB-S-NF
OBX-5-PROB-FACILITY
OBX-0-PROB-S-NF-S-NOTE-NMBR
OBX-0-PROB-S-NF-S-NOTE-NARR
XXX-0-PROB-RESET-COUNTER", "", "", ""], ["4278", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody of
RADIOLOGY/NUCLEAR MEDICINE:\n
ORU^R01^RAD\n
The following VDEF extraction lists are under the custody of RADIOLOGY/NUCLEAR
MEDICINE:\n
PID-0-RAD
PV1-0-RAD
PV1-3-RAD-POC-WARD
PV1-3-RAD-POC-WARD-1
PV1-3-RAD-POC-WARD-2
PV1-3-RAD-POC-PC
PV1-3-RAD-HOSPDIV-FT
OBR-0-RAD-PTCASE
OBR-4-RAD-PTCASE
OBR-16-RAD-POC-REQLOC
OBR-33-RAD-PTCASE-PRIMINTRES
OBR-33-RAD-PTCASE-PRIMINTSTF
OBR-33-RAD-PTCASE-S-SECINTSTF
OBR-33-RAD-PTCASE-S-SECINTRES
OBR-34-RAD-PTCASE-S-TECH
OBR-0-RAD-RNMR
OBX-0-RAD-PTCASE-PDC
OBX-0-RAD-PTCASE-S-SDC
OBX-0-RAD-PTCASE-S-CH
OBX-0-RAD-PTCASE-CMPL
OBX-0-RAD-PTCASE-CT
OBX-0-RAD-PTCASE-S-PM
OBX-0-RAD-PTCASE-S-CPT
OBX-0-RAD-PTCASE-S-MEDS
OBX-5-RAD-MEDADMIN-1
OBX-5-RAD-MEDADMIN-2
OBX-5-RAD-MEDADMIN-3
OBX-0-RAD-RNMR-S-RT
OBX-0-RAD-RNMR-S-IT
OBX-0-RAD-RNMR-S-ER
OBX-0-RAD-RNMR-S-ER-S-ET
OBX-0-RAD-RNMR-RT-IL
OBX-0-RAD-RNMR-S-OC
OBX-0-RAD-RNMR-S-IMG
OBX-0-RAD-RNMR-S-ACH
OBX-0-RAD-PTCASE-CM
Z42-0-RAD-NMD-CONTRAST
Z42-0-RAD-NMD-S-RADIOPHARM
Z42-1-RAD-NMD-S-RADIOPHARM-1
Z42-1-RAD-NMD-S-RADIOPHARM-2
Z42-1-RAD-NMD-S-RADIOPHARM-3", "", "", ""], ["4279", "VDEF EVENTS AND EXTRACTION LISTS", "Other", "BAR CODE MED ADMIN", "2004/08/23", "", "Retired", "Supported", "", "
The following VDEF events are under the custody BAR
CODE MED ADMIN:\n
RDS^O13^BCMA\n
The following VDEF extraction lists are under the custody of BARE CODE MED
ADMIN:\n
PID-0-BCMA
PV1-0-BCMA
ORC-0-BCMA
RXE-0-BCMA
RXE-2-BCMA
RXC-0-BCMA-BASE
RXC-0-BCMA-ADD
RXG-0-BCMA
RXG-2-BCMA
RXG-4-BCMA-EDIT
RXG-3-BCMA
OBX-0-BCMA-PRNREASON
OBX-2-BCMA-EFFECTIVENESS
OBX-3-BCMA-ENTERED
OBX-4-BCMA-ENTEREDAT
OBX-5-BCMA-MINUTES
OBX-6-BCMA-DIVISION
OBX-7-BCMA-ACTION
OBX-8-BCMA-VARIANCE
NTE-0-BCMA
Z25-0-BCMA", "", "", ""], ["4280", "DIC(21", "File", "REGISTRATION", "2004/05/27", "APPROVED", "Active", "Private", "21", "", "", "", ""], ["4281", "Field selection/lookup based on DD global with call to DIC", "File", "1", "2010/12/14", "APPROVED", "Active", "Controlled Subscription", "", "
The LAB SERVICE package (LSRP project) has a
requirement for the user to be able to select specific fields in the
LABORATORY TEST (#60) file and to set auditing on and off for these fields.
In order for the users to select the fields available for a file, a DIC call
would be used with the variable DIC set to "^DD(". This ICR will allow the
LAB SERVICE package to use ^DD in this manner.\n
S DIC="^DD(60,"
S DIC(0)="AEQMZ",DIC("A")="Field: "
D ^DIC", "", "", "2010/12/15"], ["4282", "PROCEDURE CODE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2003/10/06", "", "Withdrawn", "Private", "71.2", "
The VDEM package requests permission to view the Name
field and the Type of Imaging pointer of the Procedure Modifiers file (71.2)
to extract the data from the database.", "", "", ""], ["4283", "PSB DEVICE", "Remote Procedure", "BAR CODE MED ADMIN", "2003/10/23", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB DEVICE", "", ""], ["4284", "PSB NURS WARDLIST", "Remote Procedure", "BAR CODE MED ADMIN", "2003/10/23", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB NURS WARDLIST", "", ""], ["4285", "PSB CHECK IV", "Remote Procedure", "BAR CODE MED ADMIN", "2003/10/23", "APPROVED", "Active", "Controlled Subscription", "", "", "PSB CHECK IV", "", ""], ["4286", "VDEMWKLD Routine Calling File 64", "File", "LAB SERVICE", "2003/10/09", "", "Withdrawn", "Private", "64", "
This IA was created becuase of the routines dependancy
with the WKLD Code file #64. The routine will loop through the file and
extract data elements of key fields. The data will be used to support the VDEM
extraction application.", "", "", ""], ["4287", "ORB3LAB ROUTINE", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2003/10/20", "APPROVED", "Active", "Private", "", "
CPRS requests that the Lab package will notify CPRS
(the OR package) whenever lab test results are released for a Cytology,
Surgical Pathology, Electron Microscopy, and Autopsy section.", "", "ORB3LAB", "2008/03/14"], ["4288", "RETRIEVE INSURANCE DATA", "Routine", "INTEGRATED BILLING", "2003/10/22", "APPROVED", "Active", "Private", "", "
Register Once Messaging will initiate a %ZTLOAD call to
BACKGND^IBCNRDV to retrieve insurance data from sites of record each time a
veteran is registered at a new site for the first time.\n
IB*2.0*763 adds a switch to enable/disable retrieval of insurance data.
DG*5.3*1102 checks the status of the switch. (See ICR 7429)", "", "IBCNRDV", "2023/07/17"], ["4289", "PRCAHV", "Routine", "ACCOUNTS RECEIVABLE", "2003/10/30", "APPROVED", "Active", "Private", "", "", "", "PRCAHV", ""], ["4290", "READ OF CLINICAL REMINDER INDEX (PXRMINDX)", "File", "CLINICAL REMINDERS", "2005/12/08", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will allow any packages with the DBA approval
to be able to read from
the Clinical Reminders index.\n", "", "", "2016/09/19"], ["4291", "DG10 REFERENCE", "Routine", "INCOME VERIFICATION MATCH", "2003/11/04", "APPROVED", "Active", "Private", "", "", "", "IVMCQ", ""], ["4292", "DBIA4292", "Routine", "REGISTRATION", "2003/11/06", "APPROVED", "Active", "Supported", "", "
Supported calls for building of HL7 ZPD segment (VA
Specific Patient Demographics).", "", "VAFHLZPD", ""], ["4293", "Update DIC(5,'%D'", "File", "1", "2003/11/06", "APPROVED", "Active", "Private", "5", "
Update the file DESCRIPTION for the STATE(#5) file.", "", "", ""], ["4294", "$$A40 MPIFA40", "Routine", "MASTER PATIENT INDEX VISTA", "2003/11/13", "APPROVED", "Active", "Controlled Subscription", "", "
This is the entry point used to tell the MPI that two
records at a local site hasve been merged and that they both had National ICNs
that should know be under one ICN. It will build an A40 Merge Patient HL7
message.", "", "MPIFA40", ""], ["4295", "HEALTH FACTORS INFO", "File", "PCE PATIENT CARE ENCOUNTER", "2004/02/23", "APPROVED", "Active", "Controlled Subscription", "9999999.64", "
This agreement is to access basic information about a
Health Factor, and the necessary cross-references to access them by Category.", "", "", ""], ["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").\n
The expected structure of the input array (CSLIN) is as follows:\n
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\n
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.\n
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:\n
^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\n
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.\n
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.\n\n\n
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.\n
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.\n
Invalid input parameter list HL7 error - the input message
string sent to CoreFLS was invalid\n
Query aborted due to error: HL7 error when initializing HL7
parameters\n
Message send failure: HL7 error when transmitting
message to CoreFLS\n
Network Timeout the query request to CoreFLS
timed or the check for results
in ^XTMP timed out\n
Not Found no results obtained for query in
CoreFLS\n
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", ""], ["4297", "ELECTRONIC SIGNATURE-RELATED DATA IN THE NEW PERSON FILE", "File", "KERNEL", "2003/12/23", "APPROVED", "Active", "Controlled Subscription", "200", "
Electronic Signature is a collection of Java APIs to
validate, retrieve, and save electronic signature codes and related data on
the M server, as well as APIs to encrypt and decrypt strings similar to the
APIs provided by the existing VA Kernel 8.0 electronic signature APIs.\n
The Java APIs provide HSD&D developers that are rehosting their applications
to a new Java environment a standardized method for migrating their electronic
signature functionality. It is hoped that this will reduce duplication of
effort, promote more efficient use of limited development resources, and
satisfy the VistA user's business needs.\n
This IA permits Electronic Signature to access electronic signature-related
data in the NEW PERSON file (#200) as listed in the GLOBAL REFERENCE section
of this Integration Agreement. All fields are accessed via VA FileMan calls,
such as $$GET1^DIQ and FILE^DIE, rather than direct global reads.", "", "", ""], ["4298", "SNOMED CODES FOR WH", "File", "LAB SERVICE", "2003/12/10", "APPROVED", "Active", "Private", "63", "
The Women's Health (WH) package requests permission to
look at the following FILE 63 fields:\n
GLOBAL REFERENCE: ^LR(D0,'SP',D1,2,D2,0)
SUBFILE: 63.12
FIELD #: .01
FIELD NAME: ORGAN/TISSUE
NODE/PIECE: 0;1\n
GLOBAL REFERENCE: ^LR(D0,'SP',D1,2,D2,2,D3,0)
SUBFILE: 63.16
FIELD #: .01
FIELD NAME: MORPHOLOGY
NODE/PIECE: 0;1\n
These fields hold pointer values to other Lab package files containing SNOMED
codes (FILES 61 and 61.1) used to identify the kind of lab test performed.\n
1) In the WH package, a new option has been created to allow each site to
select the SNOMED codes from FILEs 61 and 61.1 that are used locally for Pap
Smears. WH will point to these two files and store the pointer values in a WH
file (IAs 4154 and 4155).\n
2) There is already an event point in the Lab package that calls WH whenever a
Cytology or Surgical Pathology Lab test is verified. When the Lab test is
verified, the WH package will check these fields of the Lab test to see what
SNOMED codes, if any, are used. If any of the SNOMED codes used in the Lab
test match the SNOMED code(s) selected in #1, the WH package will assume that
Lab test is a Pap Smear. Direct global reads are needed because internal entry
numbers of file entries are being checked, not external values.", "", "", ""], ["4299", "EPHARMACY API", "Routine", "INTEGRATED BILLING", "2003/11/25", "APPROVED", "Active", "Controlled Subscription", "", "
The Outpatient Pharmacy, CMOP, and ECME packages
request the usage of the Integrated Billing functions to support ePharmacy
billing.", "", "IBNCPDP", "2011/12/22"], ["4300", "DBIA4300", "Routine", "E CLAIMS MGMT ENGINE", "2005/11/09", "", "Retired", "Private", "", "\n\n
The Outpatient Pharmacy Package requests access to call the Electronic Claims
Management Engine (ECME) Package to perform the following functions:", "", "BPSOSRX", ""], ["4301", "DBIA4301", "File", "E CLAIMS MGMT ENGINE", "2005/11/09", "", "Retired", "Private", "9002313.56", "
Outpatient Pharmacy requests to use direct reads to the
BPS Electronic Claims Management Engine's (ECME) BPS Pharmacies file
(#9002313.56) to verify that a particular Pharmacy is defined to bill third
party claims.", "", "IBNCPDP", ""], ["4302", "DBIA4302", "File", "OUTPATIENT PHARMACY", "2005/11/17", "", "Retired", "Private", "52", "
The Electronic Claims Management Engine (ECME) package
requests direct read/write access to store the billed NDC in the Prescription
file (#52).", "", "", ""], ["4303", "DBIA4303", "File", "OUTPATIENT PHARMACY", "2006/01/06", "", "Retired", "Private", "59", "
The Electronic Claims Management Engine (ECME) package
requests read access to the Outpatient Site file (#59).", "", "", ""], ["4304", "DBIA4304", "Routine", "OUTPATIENT PHARMACY", "2003/12/03", "APPROVED", "Active", "Private", "", "
CMOP requests access to call Outpatient Pharmacy's
function $$EN^PSONCPDP.", "", "PSONCPDP", ""], ["4305", "DBIA4305", "File", "E CLAIMS MGMT ENGINE", "2005/11/09", "", "Retired", "Private", "9002313.99", "
Outpatient Pharmacy requests read access to the ECME
BPS Setup file (#9002313.99).", "", "", ""], ["4306", "LEXICAL SERVICES UPDATE Protocol", "Other", "LEXICON UTILITY", "2003/12/03", "APPROVED", "Active", "Controlled Subscription", "", "
This protocol is used to notify other applications and
processes when the Lexicon Utility or the Lexicon Change file is updated.\n
The Lexicon is updated using a temporary maintenance global, ^LEXM. This
global is processed by the routine LEXXGI. Once processed, this protocol is
triggered and the global ^LEXM is deleted.\n
Required Variable LEXSCHG Array contains a listing of those Lexicon Files
(#757 - 757.41) that were updated as a result of a recent install. In the
case of the CHANGE LOG (file #757.9), new changes to SDO controlled files will
be indicated by file number and the internal entry number to the CHANGE LOG.\n
The variable LEXSCHG is created while processing the Lexicon Maintenance
global ^LEXM. It will indicate what files were updated.\n
Example:\n
LEXSCHG(757,0)=""
LEXSCHG(757.001,0)=""
LEXSCHG(757.01,0)=""
LEXSCHG(757.02,0)=""
LEXSCHG(757.1,0)=""
LEXSCHG(757.11,0)=""
LEXSCHG(757.9,0)=""
LEXSCHG(757.9,2)=80
LEXSCHG(757.9,3)=80.1
LEXSCHG(757.9,4)=81
LEXSCHG(757.9,"B",80,2)=""
LEXSCHG(757.9,"B",80.1,3)=""
LEXSCHG(757.9,"B",81,4)=""\n
If ICD-9-CM and/or CPT-4 changes are included in the ^LEXM
global, then the following entries will be found in the
local array LEXSCHG:\n
LEXSCHG(80,0)=""
LEXSCHG(80.1,0)=""
LEXSCHG(81,0)=""\n", "", "", ""], ["4307", "PSB VITAL MEAS FILE", "Remote Procedure", "BAR CODE MED ADMIN", "2003/12/08", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC has been built specifically to process the
filing of BCMA Pain Score data. The processing of other VITAL type may be
incorporated with some adjustments.\n\n
This routine is to service BCMA 3.0 functionality and store VITALs'
data into the VITAL MEASUREMENT FILE - ^GMR(120.5 using the API
GMRVPCE0\n
Parameters:
Input -
DFN (r) Pointer to the PATIENT (#2) file
RATE (r) BCMA trigger event/transaction
VTYPE (o) Pointer to GMRV VITAL TYPE FILE (#120.51)
(default = Pain ["PN"])
DTTKN (o) Date/time (FileMan) measurement was taken
(default = $$NOW^XLFDT())
Output - RESULTS(0) = 1
RESULTS(1) ="1^Pain Score successfully filed"
or RESULTS(1) ="-1^ERROR * Pain Score NOT filed
successfully"\n
Process results in the storing of VITAL Measurement rate into the VITAL
MEASUREMENT FILE per the given patient and vital type.", "PSB VITAL MEAS FILE", "", ""], ["4308", "NEW FILE #350 FIELD", "File", "INTEGRATED BILLING", "2003/12/02", "", "Withdrawn", "Private", "350", "
A new field called HOLD-REVIEW DATE (#17) will be added
to the INTEGRATED BILLING ACTION (#350) file, so that when a charge is put in
'HOLD-REVIEW' status in the file, this field will be automatically "stuffed"
with the current date. This will be similar to the file field ON HOLD DATE
(#16), where if a charge in the file is put in 'ON HOLD' status, it's stuffed
with the current date.", "", "", ""], ["4309", "Allow looping through 'AUDIT' nodes of DD", "File", "1", "2010/12/14", "APPROVED", "Active", "Controlled Subscription", "", "
The LAB SERVICE package (LSRP project) has a
requirement that we set specific fields to be audited on patch installation
and remove any audit indicators on any fields that are not in the predefined
list for the LABORATORY TEST file (#60) and for a few file 60 subfiles. In
order to reset the existing audit indicators, it will be necessary to use hard
code to traverse the ^DD(60,"AUDIT", fields.\n
S LRFLD=0 F S LRFLD=$O(^DD(60,"AUDIT",LRFLD)) Q:'LRFLD D
. If audit on and field LRFLD is not on list, turn audit off for LRFLD
. If audit off and field LRFLD is on list, turn audit on for LRFLD\n
The subfiles that are also included for this task are:\n
Field # Field Name Subfile # Direct reference needed
==================================================================
100 SITE/SPECIMEN 60.01 ^DD(60.01,"AUDIT"
2 SYNONYM 60.1 ^DD(60.1,"AUDIT"
6 ACCESSION AREA 60.11 ^DD(60.11,"AUDIT"
500 VERIFY WKLD CODE 60.12 ^DD(60.12,"AUDIT"
500.1 ACCESSION WKLD CODE 60.13 ^DD(60.13,"AUDIT"", "", "", "2010/12/15"], ["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", ""], ["4312", "COMBAT VET STATUS EXPIRED", "Routine", "REGISTRATION", "2003/12/12", "APPROVED", "Active", "Controlled Subscription", "", "
This API will provide a list of any veterans with
expired CV Status. It is being produced so that IB can check to see if any
veterans were improperly billed due to a bug in the Combat Vet Interim
Solution patch (DG*5.3*528). It is not intended for any other use.", "", "DGCVEXP", ""], ["4313", "CAPACITY PLANNING TIMING METRIC DATA", "File", "CAPACITY MANAGEMENT TOOLS", "2003/12/16", "APPROVED", "Active", "Controlled Subscription", "", "", "", "", ""], ["4314", "Does User Have *ANY* TIU Documents", "Routine", "TEXT INTEGRATION UTILITIES", "2007/03/08", "", "Pending", "Private", "", "
For efficient graphing of Progress Notes, the CPRS GUI
Graphing Utility begins by determining whether the patient has any documents
at all in the TIU DOCUMENT File 8925. This Boolean extrinsic function makes
that determination.\n
This API does not limit in ANY way the file entries which it considers
documents. Any entry at all produces a 1 (Yes) value.", "", "", ""], ["4315", "Does Patient Have *ANY* TIU Documents", "Routine", "TEXT INTEGRATION UTILITIES", "2007/03/12", "APPROVED", "Active", "Private", "", "
This Boolean function facilitates Progress Note
Graphing in the CPRS GUI Graphing Utility. The Utility first checks to see if
the patient has ANY TIU documents at all. ANY entry at all in the TIU
DOCUMENT file [8925] for the given patient will yield a YES (1) answer. This
may include non-Progress Notes including documents entered from other packages
which are not displayed except perhaps in reports. It will also include
documents of all statuses (some not generally viewable) including retracted
documents.", "", "TIULX", "2007/03/12"], ["4316", "VDEF access to Institution and Mail Group data", "File", "HEALTH LEVEL SEVEN", "2004/08/24", "APPROVED", "Active", "Private", "869.3", "
This IA exposes Institution and Mail Group (File 869.3,
fields .04 and .05) to VDEF that builds the MSH segment for VDEF-built HL7
messages.", "", "", ""], ["4317", "ALLOW USEAGE OF DGUTQ", "Routine", "REGISTRATION", "2003/12/23", "", "Withdrawn", "Private", "", "", "", "", ""], ["4318", "ALLOW ACCESS TO ROUTINE DGUTQ", "Routine", "REGISTRATION", "2003/12/29", "APPROVED", "Active", "Private", "", "", "", "DGUTQ", ""], ["4319", "KERNEL ACCESS TO TIME ZONE INFORMATION", "File", "MAILMAN", "2003/12/26", "", "Withdrawn", "Private", "4.3", "
This IA is used to allow Kernel access time zone
information that is owned by MailMan, specificaly field 1 of file 4.3.", "", "", ""], ["4320", "KERNEL ACCESS TO MAILMAN'S TIME ZONE INFORMATION", "File", "MAILMAN", "2003/12/26", "", "Withdrawn", "Private", "4.4", "
This IA is used to let the part of VDEF that is in the
custody of Kernel to access time zone information in the custody of MailMan.", "", "", ""], ["4321", "HL7 EVENT TYPE ACCESS", "File", "HEALTH LEVEL SEVEN", "2004/08/31", "APPROVED", "Active", "Private", "779.001", "
This IA allows the VDEF package to point-to and lookup
entries in file #779.001. This access is used to verify that VDEF Extract
Descriptions are based on existing HL7 Event Types.", "", "", ""], ["4322", "TASKMAN NUMBER ASSOCIATED WITH LOGICAL LINK -- RETRIEVAL", "File", "HEALTH LEVEL SEVEN", "2004/08/31", "APPROVED", "Active", "Private", "870", "
This integration agreement allows the VDEF package to
retrieve the TaskMan number that is invoking a Logical Link in order to report
information about the link to the user.", "", "", ""], ["4323", "DBIA 4323", "File", "1", "2004/09/01", "APPROVED", "Active", "Private", "0", "
Pharmacy Data Management will have access to look at
the ^DD(50,0,"IX" nodes to get the field number of the file based on the cross
reference. Then by using the FIELD^DID API, the data type will be determined.", "", "", ""], ["4324", "DBIA4324", "File", "KERNEL", "2003/12/31", "APPROVED", "Active", "Private", "200", "
During Phase II patch installation of MyHealtheVet the
following user is created, these fields can also be reset to existing values
by IRM staff in the event of problems. Fields are filled, via supported
FileMan calls, for MHV project in File 200 (New Person). Access and Verify
codes are "pre-hashed" for security and consistency across all VAMC's to allow
National Patient access via a secure eVault Server.\n
User: MYHEALTHEVET,SECURE SERVER", "", "", ""], ["4325", "NATIONAL TIU MONITOR", "Routine", "TOOLKIT", "2004/01/06", "APPROVED", "Active", "Private", "", "
A software package to monitor CPRS GUI response time
for data retrievals of Lab, TIU and Clinical Reminders.", "", "AWCMCPR1", ""], ["4326", "DBIA 4326", "File", "1", "2004/09/01", "APPROVED", "Active", "Private", "0", "
Pharmacy Data Management will have access to look at
the ^DD(51.5,0,"IX" nodes to get the field number of the file based on the
cross reference. Then by using the FIELD^DID API, the data type will be
determined.", "", "", ""], ["4327", "DBIA4327", "File", "ORDER ENTRY/RESULTS REPORTING", "2004/02/03", "APPROVED", "Active", "Private", "101.24", "
This is a one time only integration agreement for the
conversion of Medicine components to Medicine/Clinical Procedures components.
This integration agreement is used to document that patch 2 of Clinical
Procedures, MD*1*2, can use FileMan to lookup the entry ORRPW MEDICINE in the
OE/RR Report file (#101.24) and use FileMan to modify ORRPW MEDICINE to ORRPW
MEDICINE/CP and add "Medicine/CP" to the Heading and Descriptive Text fields.", "", "", ""], ["4328", "DBIA4328", "File", "HEALTH SUMMARY", "2004/01/30", "APPROVED", "Active", "Private", "142.1", "
This is a one time only integration agreement for the
conversion of Medicine Components to Medicine/Clinical Procedures Components.
This integration agreement is to document that patch 2 of Clinical Procedures,
MD*1*2, can lookup with FileMan the following entries in the Health Summary
Components file (#142.1):
1 MEDICINE ABNORMAL BRIEF
2 MEDICINE BRIEF REPORT
3 MEDICINE FULL CAPTIONED
4 MEDICINE FULL REPORT
5 MEDICINE SUMMARY
Clinical Procedures can write to the entries to change the print routine,
prefix, and description to reflect both Medicine and CP.", "", "", ""], ["4329", "DBIA4329", "File", "KERNEL", "2004/01/22", "APPROVED", "Active", "Controlled Subscription", "200", "", "", "", "2009/09/22"], ["4330", "DBIA4330", "File", "KERNEL", "2004/01/22", "APPROVED", "Active", "Private", "49", "", "", "", ""], ["4331", "Document Parameters", "Routine", "TEXT INTEGRATION UTILITIES", "2004/02/02", "APPROVED", "Active", "Controlled Subscription", "", "
This integration aggreement allows subscribing packages
to call DOCPARM^TIUSRVP to get TIU Document Parameters for a TIU Document
without knowing the Document's type.", "", "TIUSRVP1", ""], ["4332", "Workload Required?", "Routine", "TEXT INTEGRATION UTILITIES", "2004/02/02", "APPROVED", "Active", "Private", "", "
The $$CHKWKL^TIUPXAP2 api determines if workload is
required for a TIU Document", "", "TIUPXAP2", ""], ["4333", "GMTSRAD", "Routine", "HEALTH SUMMARY", "2004/01/30", "APPROVED", "Active", "Controlled Subscription", "", "
This routine is called to extract Radiology Order Data.\n", "", "GMTSRAD", ""], ["4334", "XU USER TERMINATE", "Other", "KERNEL", "2004/01/30", "APPROVED", "Active", "Supported", "", "
Other pachages can attach to this protocol option and
they will be called when a USER is Terminated. The call will be just after the
users Access and Verify codes have been removed. DUZ will be the person that
is running the terminate option. XUIFN will point to the NEW PERSON file
entry that is being terminated. Returns selected file 200 data to XUSR(field
name) array for New Person components.\n
It is called in XUSTERM from XUSERP.\n
Packages may attach or de-attach their options using KIDS.", "", "", ""], ["4335", "Microbiology data API", "Routine", "AUTOMATED LAB INSTRUMENTS", "2004/02/17", "APPROVED", "Active", "Controlled Subscription", "", "
Returns Microbiology data for a patient that either has
specimen a collection date(s) or completion date(s) that fall within the
passed in date parameters.", "", "LA7UTL1A", ""], ["4336", "AP Status Update (from CoreFLS to VistA Prosthetics)", "Routine", "COMMUNICATIONS SERVICE LIBRARY", "2004/02/09", "APPROVED", "Active", "Private", "", "
AP Status Update\n
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.\n
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.\n
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.\n
Information that is transmitted from CoreFLS is put into an ^XTMP global for
use by VistA Prosthetics.\n
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.\n
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.\n
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.\n
The CSL routine evaluates the data sent by CoreFLS for the following structure
and content:\n
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\n
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", "", "", ""], ["4337", "File 62.06", "File", "LAB SERVICE", "2004/02/05", "APPROVED", "Active", "Private", "62.06", "
Access to data in the ANTIMICROBIAL SUSCEPTIBILITY FILE
(#62.06)", "", "", ""], ["4338", "Person Service Patient Construct Java APIs - used by PATS", "Other", "757", "2007/03/23", "", "Pending", "Private", "", "
The following lists supported Java APIs for the Patient
Service Construct (PSC) software package that are used by PATS.", "", "", ""], ["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.\n", "", "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.\n
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.\n
Information from CoreFLS is put into a global ^XTMP for use by VistA
Prosthetics.\n", "", "CSLPRPC*", ""], ["4342", "Visitor", "Routine", "KERNEL", "2004/02/17", "APPROVED", "Active", "Controlled Subscription", "", "
The routine XUESSO1 has entry points used to create a
Visitor record in the New Person File. Use of this routine is restricted.", "", "XUESSO1", "2017/09/29"], ["4343", "Surgical Pathology data API", "Routine", "AUTOMATED LAB INSTRUMENTS", "2004/02/13", "APPROVED", "Active", "Controlled Subscription", "", "
Returns data for a given Surgical Pathology encounter.", "", "LA7UTL03", ""], ["4344", "Cytopathology data API", "Routine", "AUTOMATED LAB INSTRUMENTS", "2004/02/17", "APPROVED", "Active", "Controlled Subscription", "", "
Returns data for a Cytopathology Encounter.", "", "LA7UTL02", ""], ["4345", "PROSTHETICS 1358 FIELDS", "File", "PROSTHETICS", "2004/02/18", "APPROVED", "Active", "Private", "664", "
The purpose of the change is to enable IFCAP users to
view IFCAP Purchase
Orders with Prosthetic Line Item Detail. IFCAP patch PRC*5.1*103.", "", "", "2010/07/13"], ["4346", "VAFHLU", "Routine", "REGISTRATION", "2004/02/17", "APPROVED", "Active", "Supported", "", "
Valid after patches DG*5.3*508 and SD*5.3*293 are
released.", "", "VAFHLU", ""], ["4347", "SCMSVUT5", "Routine", "SCHEDULING", "2004/02/17", "APPROVED", "Active", "Supported", "", "
Supported calls for parsing of an HL7 segment
Valid after patches DG*5.3*508 and SD*5.3*293 are released.", "", "SCMSVUT5", ""], ["4348", "1358 DAILY RECORD ACCESS", "File", "IFCAP", "2004/02/17", "", "Withdrawn", "Private", "424", "
Fee Basis will be accessing record entries (read-access
only) contained in the 1358 DAILY RECORD (#424) for use during the conversion
of FEE BASIS 7078 documents (file 162.4). Conversion program(s) in the Fee
Basis namespace will be evaluating the data stored in specific record entries
contained in file 424 to logically decide if a specific record in file 162.4
should be converted determinant on certain criteria.", "", "", ""], ["4349", "AR DATA QUEUE FILE", "File", "ACCOUNTS RECEIVABLE", "2004/02/18", "APPROVED", "Active", "Private", "348.4", "
The Integrated Billing Package desires an Integration
Agreement with the Accounts Receivable package to add bill number entries in
to the AR DATA QUEUE File (#348.4) as they are modified in the BILL/CLAIMS
File (#399). BILL NUMBER entries will be created with the standard FileMan
functions; FILE^DICN, UPDATE^DIE, and FILE^DIE.\n
The bill number will be retrieved from the ACCOUNTS RECEIVABLE File (#430) by
a direct global read from the BILL NO. cross-reference.
[PRCA(430,"D",BillNumber]", "", "", ""], ["4350", "GMV ALLERGY", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV ALLERGY
TAG: ALLERGY
ROUTINE: GMVUTL3
RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
This remote procedure call retrieves the patient's allergy information.\n
This remote procedure call is documented in Integration Agreement 4350.
INPUT PARAMETER: DFN
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 30
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
DFN is a pointer to the PATIENT file (#2).
RETURN PARAMETER DESCRIPTION:
Returns the patient allergy information in the array specified.\n
The result array returns:
RESULT(n)=This patient has the following allergy(ies):
(n+1)=piece1\n
where piece1 = the allergy name
n = sequential number starting at 1.\n
If there is no data, then the following is returned:
RESULT(1)=No Allergy Assessment\n
Example:
> S DFN=134
> D ALLERGY^GMVUTL3(.RESULT,DFN) ZW RESULT
> RESULT(1)="This patient has the following allergy(ies): "
> RESULT(2)="PENICILLIN"", "GMV ALLERGY", "", ""], ["4351", "GMV CHECK DEVICE", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "", "Pending", "Private", "", "
This procedure calls a KERNEL utility to return a list
of printers the user may select to print output. Returns a maximum of twenty
entries.", "", "", ""], ["4352", "GMV CLINIC PT", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "", "Pending", "Private", "", "
This procedure lists patients who have an appointment
for a selected clinic and a given period of time.", "", "", ""], ["4353", "GMV CONVERT DATE", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV CONVERT DATE
TAG: GETDT
ROUTINE: GMVGETQ
RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
This remote procedure call converts a user-supplied date/time into VA
FileMan's internal and external date format.\n
This remote procedure call is documented in Integration Agreement 4353.
INPUT PARAMETER: GMRDATE
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 30
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
GMRDATE is the user-supplied date/time text.
RETURN PARAMETER DESCRIPTION:
RESULT=Date in internal FileMan format^Date in external FileMan format\n
Example:
> S GMRDATE="10/11/2005@10:30AM"
> D GETDT^GMVGETQ(.RESULT,GMRDATE) ZW RESULT
> RESULT="3051011.103^OCT 11, 2005@10:30:00"", "GMV CONVERT DATE", "", ""], ["4354", "GMV GET CATEGORY IEN", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV GET CATEGORY IEN
TAG: CATEGORY
ROUTINE: GMVUTL8
RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
DESCRIPTION:
Returns the IEN if the value is found in the GMRV VITAL CATEGORY
(#120.53) file.\n
This remote procedure call is documented in Integration Agreement 4354.
INPUT PARAMETER: GMVCAT
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 45
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
GMVCAT = Name of Category (from FILE 120.53) (e.g., METHOD)
RETURN PARAMETER DESCRIPTION:
Returns the IEN if GMVCAT exists in FILE 120.53\n
Example:
> S GMVCAT="METHOD"
> D CATEGORY^GMVUTL8(.RESULT,GMVCAT) ZW RESULT
> RESULT=2", "GMV GET CATEGORY IEN", "", ""], ["4355", "GMV GET CURRENT TIME", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: GMV GET CURRENT TIME
TAG: TIME
ROUTINE: GMVUTL7
RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: FALSE
DESCRIPTION:
Gets the current date and time from the server.\n
This remote procedure call is documented in Integration Agreement 4355.
RETURN PARAMETER DESCRIPTION:
Returns current date and time in FileMan internal and external format.\n
Example:
> D TIME^GMVUTL7(.RESULT) ZW RESULT
> RESULT=3051011.143332\n
Note: There is an input parameter, P2, listed in the TIME line tag of the
GMVUTL7 routine. However, it is not used. It can be set to any value or
omitted. It remains for backwards compatibility.", "GMV GET CURRENT TIME", "", ""], ["4356", "GMV GET DATA", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "", "Pending", "Private", "", "", "", "", ""], ["4357", "GMV GET VITAL TYPE IEN", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV GET VITAL TYPE IEN
TAG: TYPE
ROUTINE: GMVUTL8
RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
DESCRIPTION:
Returns the IEN if the value is found in the GMRV VITAL TYPE (#120.51)
file.\n
This remote procedure call is documented in Integration Agreement 4357.
INPUT PARAMETER: GMVTYPE
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 55
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
GMVTYPE = Name of Vital Type (from FILE 120.51) (e.g., WEIGHT)
RETURN PARAMETER DESCRIPTION:
Returns the IEN if GMVTYPE exists in FILE 120.51.\n
Example:
> S GMVTYPE="WEIGHT"
> D TYPE^GMVUTL8(.RESULT,GMVTYPE) ZW RESULT
> RESULT=9", "GMV GET VITAL TYPE IEN", "", ""], ["4358", "GMV LATEST VM", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: GMV LATEST VM
TAG: GETLAT
ROUTINE: GMVGETD
RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
This remote procedure call retrieves the latest vital records for a given
patient.\n
This remote procedure call is documented in Integration Agreement 4358.
INPUT PARAMETER: GMRDFN
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 10
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
GMRDFN variable is a pointer to the Patient (#2) file (i.e., DFN).
RETURN PARAMETER DESCRIPTION:
Returns the name of the global array (i.e., ^TMP($J,"GRPC")) containing
the latest vitals for the selected patient.\n
The TMP global contains:
^TMP($J,"GRPC",n)=piece1\n
where piece1 = is a formatted line of text.
n = sequential number starting at 1.\n
The formatted line of text includes the vital type, value and unit
(U.S.), value and unit (metric), qualifiers, supplemental oxygen, body
mass index value, and person who entered the record.\n
If there is no data for the patient, the following is returned:
^TMP($J,"GRPC",1)=There are no results to report\n
Example:
> S GMRDFN=134
> D GETLAT^GMVGETD(.RESULT,GMRDFN) ZW RESULT
> RESULT="^TMP(539349605,"GRPC")"
> D ^%G
> Global ^TMP($J,"GRPC"
> ^TMP(539349605,"GRPC",1)=Temp.: (08/09/05@08:00) 102 F (38.9 C)*
(ORAL) _VITPROVIDER,ONE
> 2)=Pulse: (07/14/05@16:33) 55
(LEFT,CAROTID,PALPATED,LYING) _VITPROVIDER,ONE
> 3)=Resp.: (07/14/05@16:33) 31
(SPONTANEOUS,SITTING) _VITPROVIDER,ONE
> 4)=Pulse Ox: (08/22/05@13:48) 99% with
supplemental O2 1 L/min 90% NASAL CANNULA _VITPROVIDER,ONE
> 5)=B/P: (09/26/05@11:30) 120/80* (L
ARM,SITTING,CAROTID,CALF) _VITPROVIDER,TWO
> 6)=Ht.: (09/14/05@17:18) 5 ft 6 in (167.64
cm) (ACTUAL) _VITPROVIDER,ONE
> 7)=Wt.: (09/14/05@17:18) 135 lb (61.36 kg)
(ACTUAL,STANDING) _VITPROVIDER,ONE
> 8)=Body Mass Index: 22
9)=CVP: (08/22/05@17:09) 15 cmH2O
(11.0 mmHg) _VITPROVIDER,ONE
10)=Circ/Girth: (07/22/05@10:22) 1 in (2.54 cm)
(DRY,ABDO MINAL) _VITPROVIDER,TWO
11)=Pain: (09/15/05@16:43) 5 _VITPROVIDER,ONE", "GMV LATEST VM", "", ""], ["4359", "GMV VITALS/CAT/QUAL", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: GMV VITALS/CAT/QUAL
TAG: GETVITAL
ROUTINE: GMVUTL7
RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
Returns all qualifier information for the vital types selected.\n
This remote procedure call is documented in Integration Agreement 4359.
INPUT PARAMETER: GMVLIST
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 60
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
A list of vital type abbreviations (FILE 120.51, Field 1) separated by
up-arrows (e.g., "HT^WT" for height and weight). When the value is null,
all qualifier information will be returned for all vital types.
RETURN PARAMETER DESCRIPTION:
Returns the qualifier information for the selected vital types in the
array specified. Includes the abnormal high and low values for the vital
type, if any.\n
The result array contains:\n
RESULT(n)=piece1^piece2^piece3^piece4^piece5^piece6^piece7^piece8^piece9
RESULT(n.nnn)=pieceA^pieceB^pieceC^pieceD\n
where n is a sequential number starting with 1
piece1 = V for vital type
piece2 = FILE 120.51 IEN for this vital type
piece3 = vital type name (FILE 120.51, Field .01)
piece4 = Abbreviation (FILE 120.51, Field 1)
piece5 = PCE Abbreviation (FILE 120.51, Field 7)
piece6 = If vital type is Blood Pressure this is the
abnormal systolic high value (File 120.57, Field 5.7).
If vital type is Temperature, this is the abnormal high
value (File 120.57, Field 5.1)
If vital type is Respiration, this is the abnormal high
value (File 120.57, Field 5.5)
If vital type is Pulse, this is the abnormal high value
(File 120.57, Field 5.3)
If vital type is Central Venous Pressure, this is the
abnormal high value (File 120.57, Field 6.1)
piece7 = If vital type is Blood Pressure this is the
abnormal diastolic high value (File 120.57, Field 5.71).
If vital type is Temperature, this is the abnormal low
value (File 120.57, Field 5.2)
If vital type is Respiration, this is the abnormal low
value (File 120.57, Field 5.6)
If vital type is Pulse, this is the abnormal low value
(File 120.57, Field 5.4)
If vital type is Central Venous Pressure, this is the
abnormal low value (File 120.57, Field 6.2)
piece8 = If vital type is Blood Pressure this is the
abnormal systolic low value (File 120.57, Field 5.8).
If vital type is Central Pressure, this is the abnormal
O2 saturation (File 120.57, Field 6.3)
piece9 = If vital type is Blood Pressure this is the
abnormal diastolic low value (File 120.57, Field 5.81).\n
RESULT(n.nnn)=pieceA^pieceB^pieceC^pieceD
where pieceA = C for CATEGORY or Q for QUALIFIER\n
if pieceA is C, then
pieceB = FILE 120.53 IEN for this category
pieceC = category name (FILE 120.53, Field .01)
pieceD = null\n
if pieceB is Q, then
pieceB = FILE 120.52 IEN for this qualifier
pieceC = qualifier name (FILE 120.52, Field .01)
pieceD = synonym (FILE 120.52, Field .02)\n
Example:
> S GMVLIST="HT^WT"
> D GETVITAL^GMVUTL7(.RESULT,GMVLIST) ZW RESULT
> RESULT(1)="V^8^HEIGHT^HT^HT^"
> RESULT(1.001)="C^4^QUALITY"
> RESULT(1.002)="Q^42^ACTUAL^A"
> RESULT(1.003)="Q^43^ESTIMATED^E"
> RESULT(1.004)="Q^107^Stated^St"
> RESULT(2)="V^9^WEIGHT^WT^WT^"
> RESULT(2.001)="C^2^METHOD"
> RESULT(2.002)="Q^39^OTHER^Oth"
> RESULT(2.003)="Q^50^SITTING^Si"
> RESULT(2.004)="Q^51^STANDING^St"
> RESULT(2.005)="C^4^QUALITY"
> RESULT(2.006)="Q^42^ACTUAL^A"", "GMV VITALS/CAT/QUAL", "", ""], ["4360", "GMV MANAGER", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV MANAGER
TAG: RPC
ROUTINE: GMVRPCM
RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
Performs many functions for the Manager module.\n
This remote procedure call is documented in Integration Agreement 4360.
INPUT PARAMETER: OPTION
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 10
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Routine tag line in GMVRPCM to call.
INPUT PARAMETER: DATA
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 100
REQUIRED: YES
SEQUENCE NUMBER: 2
DESCRIPTION:
Other data as required for the call.
RETURN PARAMETER DESCRIPTION:
This remote procedure call performs various actions such as building
selection lists and modifying package parameters. The entry point is
RPC^GMVRPCM. It has input parameters of RESULTS, OPTION and DATA (ex:
RPC^GMVRPCM(.RESULTS,OPTION,DATA).\n
The RESULTS variable will contain the ^TMP("GMVMGR",$J) global array
reference. The ^TMP("GMVMGR",$J) global array contains the results.\n
The OPTION variable identifies a line label in the GMVRPCM routine
that will be invoked to process the call.\n
The DATA variable contains any additional values needed by the OPTION
variable to process the call.\n\n
1) When the OPTION value is ADDQUAL, this RPC will link a GMRV VITAL
QUALIFIER (#120.52) file entry to a GMRV VITAL TYPE (#120.51) file
entry.\n
The DATA value is a three part value separated by semi-colons(;). The
first value is the FILE 120.51 internal entry number (IEN). The second
value is the GMRV VITAL CATEGORY (#120.53) IEN. The third value is the
GMRV VITAL QUALIFIER (#120.52).\n
Example:\n
> S DATA="1;1;1"
> S OPTION="ADDQUAL"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^Qualifier Assigned\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
2) When the OPTION value is DELQUAL, this RPC will unlink a qualifier to
a GMRV VITAL TYPE (#120.51) file entry.\n
The DATA value is a three part value separated by semi-colons. The first
value is the FILE 120.51 internal entry number (IEN). The second value
is the GMRV VITAL CATEGORY (#120.53) IEN. The third value is the GMRV
VITAL QUALIFIER (#120.52) IEN.\n
Example:
> S DATA="1;1;1"
> S OPTION="DELQUAL"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^Qualifier removed.\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
3) When the OPTION value is DELTEMP, this RPC will delete a data input
template definition.\n
The DATA value is a two part value separated by a caret (^). The first
value is the ENTITY value. See IA #2263 for a list of entity values.
The second value is the name of the data input template.\n
Example:
> S DATA="USR^PAIN ONLY"
> S OPTION="DELTEMP"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^Template Removed.\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
4) When the OPTION value is GETCATS, this RPC will return a list of
qualifiers (FILE 120.52) associated with a vital type (FILE 120.51).\n
The DATA value is a one part value. It is a pointer value to FILE 120.51\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=piece1^piece2
^TMP("GMVMGR",$J,n)=piece3^piece4^piece5\n
where piece1 = number of categories (FILE 120.53) associated with this
vital type
piece2 = vital type name
piece3 = category IEN (FILE 120.53)
piece4 = category name (FILE 120.53, Field .01)
piece5 = qualifier names (FILE 120.52, Field .01) separated by a
comma and space
n = sequential number starting with 1\n
Example:
> S DATA="21"
> S OPTION="GETCATS"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^PULSE OXIMETRY
1)=2^METHOD^AEROSOL/HUMIDIFIED MASK, CPAP, FACE
TENT, L ARM, MASK, NASAL CANNULA, NON RE-BREATHER, PARTIAL
RE-BREATHER, ROOM AIR, T-PIECE, TRACHEOSTOMY COLLAR, VENTILATOR,
VENTURI MASK\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
5) When the OPTION value is GETDATA, this RPC will return the value of
the entry you specify.\n
The DATA value is a three part value. The first part is the file number.
The second part is the IEN number of the entry. The third part is the
field number.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=external value of the field\n
Example:
> S DATA="120.51^1^1"
> D RPC(.RESULT,"GETDATA",DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539339804)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539339804,0)=BP\n
If a value cannot be found, then a null value is returned.\n\n
6) When the OPTION value is GETDEF, this RPC will return default template
names.\n
The DATA value is a one part value. If it is null, then all default
templates for that user will be returned.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=piece1
^TMP("GMVMGR",$J,n)=piece2^piece3\n
where piece1 = number of templates found
piece2 = an IEN value, a semi-colon, and a global reference
piece3 = template name
n = sequential number starting with 1\n
Example A:
> S DATA=""
> S OPTION="GETDEF"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=4
1)=125;SC(^WARD 10A
2)=334;DIC(4.2,^TEST
3)=4601;VA(200,^Height ONLY
4)=547;VA(200,^All Vital Signs\n
If the DATA value is an entity value (see IA 2263 for a list of entity
values), then the default template name for that entity will be returned.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=template name\n
Example B:
> S DATA="USR"
> S OPTION="GETDEF"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=MY DEFAULT\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
7) When the OPTION value is GETHILO, this RPC will return the abnormal
high or low value for a vital type.\n
The DATA value is a one part value which identifies a field number in
the GMRV VITALS PARAMETERS (#120.57) field.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=field value\n
Example:
> S DATA=5.2
> S OPTION="GETHILO"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=94\n
A zero is returned if there is no value in the field.\n\n
8) When the OPTION value is GETLIST, this RPC returns a list of entries
for the file number specified.\n
The DATA value is a one part value. It is a file number.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=piece1^piece2
^TMP("GMVMGR",$J,n)=piece3^piece4\n
where piece1 = number of entries returned
piece2 = file name [not returned in all cases]
piece3 = file number, a semi-colon and record IEN
piece4 = the .01 value of the record
n = sequential number starting with 1\n
Examples:
Retrieve a list of wards.
> S DATA=42
> S OPTION="GETLIST"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539363784)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539363784,0)=26^WARD LOCATION
1)=42;14^10A
n)=42;15^10B
26)=42;39^10Z\n
Retrieve a list of clinics.
> S DATA=44
> S OPTION="GETLIST"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539363784)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539363784,0)=61
1)=44;6^HOUSE/A
n)=44;8^HOUSE/C
61)=44;39^HOUSE/ZZ\n
Retrieve a list vital types.
> S DATA=120.51
> S OPTION="GETLIST"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539363784)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539363784,0)=10^GMRV VITAL TYPE
1)=120.51;1^BLOOD PRESSURE
N)=120.51;19^CENTRAL VENOUS PRESSURE
10)=120.51;9^WEIGHT\n
Retrieve a list of qualifiers.
> S DATA=120.52
> S OPTION="GETLIST"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539363784)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539363784,0)=80^GMRV VITAL QUALIFIER
1)=120.52;74^ABDOMINAL
n)=120.52;42^ACTUAL
80)=120.52;99^WRIST\n
Retrieve a list of CPRS teams.
> S DATA=100.21
> S OPTION="GETLIST"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539363784)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539363784,0)=103
1)=100.21;28^1AS
n)=100.21;60^1ASO
103)=100.21;96^consult team\n
Retrieve a list of nursing units.
> S DATA=211.4
> S OPTION="GETLIST"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539363784)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539363784,0)=21
1)=211.4;7^10E
n)=211.4;17^10W
21)=211.4;9^SICU\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
9) When the OPTION value is GETQUAL, this RPC returns a list of
qualifiers associated with this vital type.\n
The DATA value is a two part value separated by a semi-colon. The first
part is vital type (FILE 120.51) IEN. The second part is a category (FILE
120.53) IEN.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=piece1^piece2
^TMP("GMVMGR",$J,n)=piece3^piece4\n
where piece1 = number of entries found
piece2 = category name (FILE 120.53, Field .01)
piece3 = qualifier IEN
piece4 = qualifier name (FILE 120.52, Field .01)
n = sequential number starting with 1\n
Example:
> S DATA="1;1",OPTION="GETQUAL"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=6^LOCATION
1)=139^Test Qualifier
2)=53^FEMORAL
3)=2^L ARM
4)=4^L LEG
5)=24^PERIPHERAL
6)=1^R ARM\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
10) When the OPTION value is GETTEMP, this RPC will return a list data
input templates defintions.\n
The DATA value is a two part value separated by a caret. The first part
is an entity value. See IA 2263 for a list of entities. The second part
is a data input template name.\n
When DATA is null, all data input template definitions are returned.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=piece1
^TMP("GMVMGR",$J,n)=piece2^piece3^piece4^piece5^piece6\n
where piece1 = number of entries returned
piece2 = 1, 2, 3, or 4. (1 = Domain, 2 = Institution, 3 =
Hospital location and 4 = New Person)
piece3 = file IEN, a semi-colon and global reference
piece4 = Field .01 value of the file specified in piece3
piece5 = template name
piece6 = template description text, a bar, vital type IEN (FILE
120.51), a colon, a metric flag (0=U.S. and 1=metric), category IEN
(FILE 120.53), a coma, and a qualifier IEN (FILE 120.52), a tilde
indicates additional category and qualifier combinations for the vital
type. A semi-colon indicates the start of the next vital type.
n = sequential number starting with 1\n
Example:
> S DATA="USR",OPTION="GETTEMP"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1
1)=4^547;VA(200,^VITUSER,ONE^MY DEFAULT^ALL
VITALS|1:0:1,2~2,59~3,50;20:1|\n\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
11) When the OPTION value is LOOKUP, this RPC will do a file lookup\n
The DATA value is a three part value separated by a caret. The first
part is a file number. The second part is a value to look up. The third
part is the field or fields to do the look up on. If the third piece is
not defined, the lookup is done on the .01 field of the file.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=piece1
^TMP("GMVMGR",$J,n)=piece2^piece3\n
where piece1 = number of entries found
piece2 = file number, a semi-colon and record IEN
piece3 = field value\n
Example:
> S DATA="44^OUTPAT^.01",OPTION="LOOKUP"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539359648)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539359648,0)=3
1)=44;75^OUTPATIENT NUC MED
2)=44;74^OUTPATIENT RADIOLOGY
3)=44;80^OUTPATIENT ULTRASOUND\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
12) When the OPTION value is NEWQUAL, this RPC will always return an
error message instructing the user to use the New Term Rapid Turnaround
process.\n
The DATA value is always null.\n
Example:
> S DATA=""
> S OPTION="NEWQUAL"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=-1^Use the New Term Rapid Turnaround
(NTRT) process to add qualifiers\n\n
13) When the OPTION value is NEWTEMP, this RPC will file a new data
input template.\n
The DATA value is a three part value separated by a caret. The first
part is an entity. See IA 2263 for a list of entities. The second part is
the name of the data input template. The third part is the description
text. If the third part is null, the template description will default to
"No Description".\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=piece1^piece2^piece3^piece4\n
where piece1 = 1, 2, 3, or 4 (1 = DOMAIN (#4.2), 2 = INSTITUTION (#4),
3 = HOSPITAL LOCATION, and 4 = NEW PERSON)
piece2 = IEN, a semi-colon, and global reference (e.g.,
3;DIC(4.2)
piece3 = the .01 field value for the record in piece2
piece4 = data input name\n
Example:
> S DATA="USR^1 EAST^All Vital Types"
> S OPTION="NEWTEMP"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539343036)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539343036,0)=4^547;VA(200,^VITUSER,ONE^1 EAST\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
14) When the OPTION value is RENTEMP, this RPC will rename a data input
template.\n
The DATA value is a three part value separated by a caret. The first
part is an entity. See IA 2263 for a list of entities. The second part is
the current template name. The third part is the new name of the
template.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=1^Renamed\n
Example:
> S DATA="USR^FRANK'S DEFAULT^MY DEFAULT"
> S OPTION="RENTEMP"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^Renamed\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
15) When the OPTION value is SETDATA, this RPC always returns an error
message that instructs the user to use the New Term Rapid Turnaround
process.\n
The DATA value is null.\n
Example:
> S DATA=""
> S OPTION="SETDATA"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=-1^Use the New Term Rapid Turnaround
(NTRT) process to add qualifiers\n\n
16) When the OPTION value is SETDEF, this RPC will set that data input
template as a default.\n
The DATA value is a two part value separated by a caret. The first part
is an entity. See IA 2263 for a list of entities. The second part is the
name of the template that will become the default template.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=1^Set As Default\n
Example:
> S DATA="USR^FRANK'S LIST"
> S OPTION="SETDEF"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^Set As Default.\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
17) When the OPTION value is SETHILO, this RPC will set the high and low
abnormal values for a vital type.\n
The DATA value is a two part value separated by a caret. The first part
is a field number in the GMRV VITALS PARAMETERS (#120.57) file. The
second part is the value that field should be set to.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=1^Update Complete.\n
Example:
> S DATA="5.1^102",OPTION="SETHILO"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^Update Complete.\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
18) When the OPTION value is SETTEMP, this RPC will save the input
template definition.\n
DATA is a three part value separated by a caret. The first part is
an entity. See IA 2263 for a list of entities. The second part is the
template name. The third part is the template definition.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=1^Template Saved.\n
Example:
> S DATA="USR^ONE VITAL TYPE ONLY^CONTAINS ONLY ONE VITAL
TYPE|2:0:1,102"|
> S OPTION="SETTEMP"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539356158)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539356158,0)=1^Template Saved.\n\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n
19) When the OPTION value is VALID, this RPC will validate data.\n
DATA is a four part value separated by a caret. The first part is the
a file number. The second part is a record number. The third part is a
field number. The fourth part is the value to validate.\n
The TMP global contains:
^TMP("GMVMGR",$J,0)=1^Valid Data\n
Example:
> S DATA="120.5^8864^.01^3051012.1034",OPTION="VALID"
> D RPC^GMVRPCM(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVMGR",539343036)"
> D ^%G
> Global ^TMP("GMVMGR",$J
> ^TMP("GMVMGR",539343036,0)=1^Valid Data\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.", "GMV MANAGER", "", ""], ["4361", "GMV NUR UNIT PT", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "", "Pending", "Private", "", "
This procedure returns a list of active patients for a
nursing location.", "", "", ""], ["4362", "GMV PTSELECT", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "APPROVED", "Active", "Private", "", "
Used as a method of processing a patient DFN and
returning all warnings and notices (i.e. sensitivity or same last 4 of SSN) to
the client application for processing. Also includes a call to log access of
sensitive patients to the DG SECURITY LOG file.", "GMV PTSELECT", "", ""], ["4363", "GMV ROOM/BED", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "", "Pending", "Private", "", "
This procedure extracts room/bed information from
Room-Bed file (#405.4) for a given MAS ward.", "", "", ""], ["4364", "GMV TEAM PATIENTS", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "", "Pending", "Private", "", "
This procedure retrieves patients assigned to a given
team.", "GMV TEAM PATIENTS", "", ""], ["4365", "GMV WARD PT", "Remote Procedure", "GEN. MED. REC. - VITALS", "2004/02/20", "", "Pending", "Private", "", "
This procedure lists patients registered on a
particular MAS ward.", "GMV WARD PT", "", ""], ["4366", "GMV USER", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV USER
TAG: RPC
ROUTINE: GMVRPCU
RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
Retrieves data about the user (e.g., parameter settings).\n
This remote procedure call is documented in Integration Agreement 4366.
INPUT PARAMETER: OPTION
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 10
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Routine tag line to call in GMVRPCU.
INPUT PARAMETER: DATA
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 100
REQUIRED: YES
SEQUENCE NUMBER: 2
DESCRIPTION:
Other data as required for the call.
RETURN PARAMETER DESCRIPTION:
This Remote Procedure Call (RPC) performs various actions focusing on
the user. The entry point is RPC^GMVRPCU. It has input parameters of
RESULTS, OPTION and DATA (e.g., RPC^GMVRPCU(RESULTS,OPTION,DATA)).\n
The RESULTS variable contains the results of the call or the location
where the results can be found.\n
The OPTION variable identifies another entry point in the GMVRPCU
routine that is invoked to process the call.\n
The DATA variable contains any values needed by the OPTION variable to
process the call.\n
1) When the OPTION value is SETPAR, this RPC will set and/or delete the
value of a GMV USER DEFAULTS setting (e.g., the user's default template).\n
The DATA value is a two part value separated by a caret. The first part
is name of a setting. The second part is the value of the setting. If
the second part is null, the existing value of the setting is deleted.\n
The TMP global contains:
^TMP("GMVUSER",$J,0)=1^Parameter set.
or
^TMP("GMVUSER",$J,0)=1^Parameter cleared\n
Example:
> S DATA="DefaultTemplate^547;VA(200,|MY DEFAULT",OPTION="SETPAR"|
> D RPC^GMVRPCU(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVUSER",539374023)"
> D ^%G
> Global ^TMP("GMVUSER",$J
> ^TMP("GMVUSER",539374023,0)=1^Parameter set.\n
If an error is encountered, a "-1" followed by a caret and the error
message text (i.e., -1^error message) is returned.\n\n\n
2) When the OPTION value is GETPAR, this RPC will return the value of the
GMV USER DEFAULTS setting specified in the DATA value.\n
The DATA value is a one part value. It is the name of a setting (e.g.,
the user's default template).\n
The TMP global contains:
^TMP("GMVUSER",$J,0)=value of setting or null\n
Example:
> S DATA="DefaultTemplate",OPTION="GETPAR"
> D RPC^GMVRPCU(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVUSER",539374023)"
> D ^%G
> Global ^TMP("GMVUSER",$J
> ^TMP("GMVUSER",539374023,0)=547;VA(200,|ONE VITAL TYPE ONLY|\n\n
3) When the OPTION value is SIGNON, this RPC will return information
about the user who is currently signed onto the system.\n
The DATA value is not used. The user's IEN (i.e., DUZ) to the NEW PERSON
(#200) file value must be defined when this call is made.\n
The RESULT variable will return the following array:
RESULT(0)=NEW PERSON (#200) file internal entry number (DUZ)
RESULT(1)=User's name (FILE 200, Field .01)
RESULT(2)=Domain (FILE 4.2) internal entry number
RESULT(3)=Domain name (FILE 4.2, Field .01)
RESULT(4)=Institution (FILE 4) internal entry number the user is signed
into (i.e., DUZ(2))
RESULT(5)=Institution name (FILE 4, Field .01)
RESULT(6)="0" or "1". "1" indicates the user has the GMV MANAGER or
programmer key. "0" indicates the user has neither key.
RESULT(7)=The user's title (FILE 200, Field 8)
RESULT(8)=This value is always null.
RESULT(9)=Number of seconds the system will wait for a response from
the user (i.e., DTIME). The default time is 300 seconds.
RESULT(10)=INSTITUTION (#4) file IEN^FILE 4 external value^station
number (e.g., 499^SUPPORT ISC^499).\n
Example:
> S OPTION="SIGNON"
> D RPC(.RESULT,OPTION) ZW RESULT
> RESULT="^TMP("GMVUSER",539375907)"
> D ^%G
> Global ^TMP("GMVUSER",$J
> ^TMP("GMVUSER",539375907,0)=547
1)=VITUSER,ONE
2)=334
3)=DEV.DEV.DNS
4)=499
5)=SUPPORT ISC
6)=1
7)=PROGRAMMER
8)=
9)=9999
10)=499^SUPPORT ISC^499", "GMV USER", "", ""], ["4367", "GMV PARAMETER", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV PARAMETER
TAG: RPC
ROUTINE: GMVPAR
RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
Sets and retrieves parameter values used by the graphical user interface.\n
This remote procedure call is documented in Integration Agreement 4367.
INPUT PARAMETER: OPTION
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 10
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Routine tag line to call.
INPUT PARAMETER: ENT
PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 2
DESCRIPTION:
The entity value to use. See Integration Agreement 2263 and FILE 8989.518
for a list of entity values.
INPUT PARAMETER: PAR
PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 3
DESCRIPTION:
The parameter value to use. See FILE 8989.51 for a list of parameter
values. This value must start with the letters "GMV" (no quotes).
INPUT PARAMETER: INST
PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 4
DESCRIPTION:
The instance to use.
INPUT PARAMETER: VAL
PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 6
DESCRIPTION:
The value assigned to a parameter. Values are stored in FILE 8989.5.
RETURN PARAMETER DESCRIPTION:
This remote procedure call sets and retrieves parameter settings that
are used in the graphical user interface.\n
The entry point is RPC^GMVPAR.. It has input parameters of RESULTS,
OPTION, ENT, PAR, INST and VAL (ex:
RPC^GMVPAR(RESULTS,OPTION,ENT,PAR,INST,VAL).\n
The RESULTS variable contains the results of the call or the location
where the results can be found.\n
The OPTION variable identifies the entry point in the GMVPAR routine
that will be invoked to process the call.\n
If an error occurrs, the ^TMP global contains:
^TMP($J,0)=-1^error message text\n\n
1) When the OPTION value is DELPAR, this RPC deletes the value for the
instance, parameter and entity specified.\n
The TMP global contains:
^TMP($J,0)=1^Instance deleted\n
Example:
> S OPTION="DELPAR",ENT="SYS",PAR="GMV DLL VERSION"
> S INST="GMV_VITALSVIEWENTER.DLL:v. 07/21/05 10:34"
> D RPC^GMVPAR(.RESULT,OPTION,ENT,PAR,INST) ZW RESULT
> RESULT="^TMP(538999278)"
> D ^%G
> Global ^TMP($J
> ^TMP(538999278,0)=1^Instance deleted\n\n
2) When the OPTION value is ENTVAL, this RPC returns the external value
of the entity specified.\n
The TMP global contains:
TMP($J,0)=external value\n
Example:
> S OPTION="ENTVAL",ENT="USR"
> D RPC(.RESULT,OPTION,ENT) ZW RESULT
> RESULT="^TMP(538993252)"
> D ^%G
> Global ^TMP($J
> ^TMP(538993252,0)=TRAXLER,FRANK\n\n
3) When the OPTION value is GETLST, this RPC returns a list of instances
and their values for the parameter and entity specified.\n
The TMP global contains:
^TMP($J,0)=piece1
^TMP($J,n)=piece2^piece3\n
where piece1 = number of entries returned
piece2 = instance name
piece3 = instance value
n = sequential number starting with 1\n\n
Example:
> S OPTION="GETLST",ENT="USR",PAR="GMV USER DEFAULTS"
> D RPC(.RESULT,OPTION,ENT,PAR) ZW RESULT
> RESULT="^TMP(538993252)"
> D ^%G
> Global ^TMP($J
> ^TMP(538993252,0)=44
1)=DefaultTemplate^547;VA(200,|MY DEFAULT|
n)=UNIT_INDEX^0
44)=WARD_INDEX^-1\n\n
4) When the OPTION value is GETPAR, this RPC will get the value for the
instance, parameter and entity specified.\n
The TMP global contains:
^TMP($J,0)=piece1\n
where piece1 = value\n
Example:
> S ENT="USR",PAR="GMV USER DEFAULTS",INST="DefaultTemplate"
> S OPTION="GETPAR"
> D RPC(.RESULT,OPTION,ENT,PAR,INST) ZW RESULT
> RESULT="^TMP(538993252)"
> D ^%G
> Global ^TMP($J
> ^TMP(538993252,0)=547;VA(200,|MY DEFAULT|\n\n
5) When the OPTION value is SETPAR, this RPC set the value of an
instance for the instance, parameter and entity specified.\n
The TMP global contains:
^TMP($J,0)=1^Parameter updated\n
Example:
> S OPTION="SETPAR",ENT="USR",PAR="GMV USER DEFAULTS",INST="SearchDelay"
> S VAL=1.5
> D RPC^GMVPAR(.RESULT,OPTION,ENT,PAR,INST,VAL) ZW RESULT
> RESULT="^TMP(538999278)"
> D ^%G
> Global ^TMP($J
> ^TMP(538999278,0)=1^Parameter updated", "GMV PARAMETER", "", ""], ["4368", "Person Service Patient Lookup Java APIs", "Other", "759", "2007/03/23", "", "Pending", "Private", "", "
The following lists supported Java APIs for the Patient
Service Lookup (PSL) software package that are used by PATS.", "", "", ""], ["4369", "Standard Data Service Java APIs - used by PATS", "Other", "763", "2007/03/23", "", "Pending", "Private", "", "
The following lists supported Java APIs for the
Standard Data Service (SDS) software package that are used by PATS.", "", "", ""], ["4370", "AR API to return Billing Data", "Routine", "ACCOUNTS RECEIVABLE", "2007/03/28", "APPROVED", "Active", "Private", "", "
This API is being implemented in support of the
Automated Service Connected Designation (ASCD) project. The ASCD project has a
Recovered Cost Report where they want to look for bills and payments for
encounters that have had their Service Connected status changed by the ASCD
options. This project has requested access to the Accounts Receivable (AR)
package data in support of this report.\n
It should be noted that it was recommended that this access to the AR package
not be given because the data for this report is not accurate at the encounter
level. This recommendation was overridden.", "", "PRCAAPI", "2007/09/27"], ["4371", "REMINDER EXCHANGE APIs", "Routine", "CLINICAL REMINDERS", "2004/02/25", "APPROVED", "Active", "Controlled Subscription", "", "
This describes the Reminder Exchange Utility APIs that
can be used to transport and install Reminder Exchange file (#811.8) entries
as part of a KIDS build. ICR #5687 allows subscribing packages to transport
Reminder Exchange file entries using KIDS.\n
The subscribing package should create a routine, referred to as ROUTINE in the
descriptions below, with an entry point referred to as ENTRY. The purpose of
this routine is to build a list of Reminder Exchange file entries that are to
be transported and installed.\n
The entry point should have the following arguments:\n
ENTRY(MODE,ARRAY)\n
Where MODE can be "I" for include in the build and "A" for install action. The
APIs documented below will set MODE to the appropriate value. ARRAY is the
name of an array that contains the list of Reminder Exchange File entries.
You need the following for each Reminder Exchange entry you want to include:\n
S LN=LN+1
S ARRAY(LN,1)="NAME"
I MODE["I" S ARRAY(LN,2)="DATE/TIME"
I MODE["A" S ARRAY(LN,3)=ACTION\n
LN is a counter, ARRAY(LN,1) is the name of the entry, ARRAY(LN,2) is the
date/time the entry was created (these can be cut and pasted from the Exchange
File display), ARRAY(LN,3) is the install action. These are single letter
codes such as install ("I"), merge ("M"), and overwrite ("O"). For example,\n
I MODE["A" S ARRAY(LN,3)="M"\n
If you would like the number of Reminder Exchange file entries that are going
to be installed to be displayed during the KIDS install, include the following
in ENTRY^ROUTINE after the list of Reminder Exchange file entries has been
populated:\n
I MODE="IA" D BMES^XPDUTL("There are "_LN_" Reminder Exchange entries to be
installed.")\n\n\n\n\n\n\n", "", "PXRMEXSI", "2013/05/23"], ["4372", "PXRM Post KIDS Install", "Routine", "CLINICAL REMINDERS", "2004/02/25", "APPROVED", "Active", "Private", "", "
Use of the Reminder Exchange Utility Post-KIDS after
the installation of a reminder exchange file entry.", "", "PXRMEXU5", ""], ["4373", "PXRM Delete Reminder Exchange Entry", "Routine", "CLINICAL REMINDERS", "2004/02/25", "APPROVED", "Active", "Private", "", "
Use of the Reminder Exchange Utility Delete action for
removal of a reminder exchange file entry.", "", "PXRMEXU1", "2025/03/17"], ["4374", "Free text bulletin", "Routine", "ADVERSE REACTION TRACKING", "2004/02/25", "APPROVED", "Active", "Private", "", "
This documents the use of the $$SENDREQ function to
send a bulletin to a mail group indicating a request to add a free text
allergy for a patient. A message is sent when a user cannot find an adequate
match when entering an allergy for a patient. The message includes important
allergy data as well as contact information for the user.", "", "GMRAPES0", ""], ["4375", "PXRM Health Factor Delete", "Routine", "CLINICAL REMINDERS", "2004/02/26", "APPROVED", "Active", "Private", "", "
This DBIA documents the call to Clinical Reminders to
delete health factors associated with a TIU document.", "", "PXRMGECU", ""], ["4376", "DBIA4376", "File", "1", "2004/03/02", "APPROVED", "Active", "Private", "393", "
DGBT*1*1 added a variable pointer L.LOCAL VENDOR to the
TRANSCRIBED BY (#10.04) of the INCOMPLETE RECORDS (#393) file. Unknowingly to
the developer, the DD entries were not cleaned up properly. Request killing
off the bad DD node entries to clean up the problem.\n
Request is one time only.", "", "", ""], ["4377", "TMP('TIUPR',$J)", "File", "TEXT INTEGRATION UTILITIES", "2004/03/03", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA grants permission to Surgery to reference the
global ^TMP("TIUPR",$J) identifying the specific report to be printed when the
print method for surgical reports is executed.\n
The following is an example of a reference identifying an Anesthesia Report,
document #2002 stored in the TIU DOCUMENT file (#8925).\n
^TMP("TIUPR",559965892,"3$ANESTHESIA REPORT;769",1,2002) = Vice SF 517", "", "", ""], ["4378", "SD-PAIT HL LOGICAL LINK STATUS", "File", "HEALTH LEVEL SEVEN", "2004/04/29", "APPROVED", "Active", "Private", "870", "
SD*5.3*333 allows for generating HL7 batches to be sent
to local VistA Interface Engines as the first step of that transmission. There
are possibilities of communication problems that would be reflected in the
status of fields in the SD-PAIT entry of the HL LOGICAL LINK - file # 870.\n
Fld # Fld name\n
4 STATE
5 IN QUEUE FRONT POINTER
6 IN QUEUE BACK POINTER
7 OUT QUEUE FRONT POINTER
8 OUT QUEUE BACK POINTER
400.01 TCP/IP ADDRESS\n
SD-PAIT internal entry number would be determined by accessing "B" crss
reference (IA # 3335).\n", "", "", ""], ["4379", "Post-Selection Action in Patient (#2) file", "File", "1", "2004/05/04", "", "Retired", "Private", "2", "\n\n
DG*5.3*582, Registration is sending multiple ISO bulletins. A flag has been
added to DGRPEIS1, and the post-selection action for the Patient (#2) file
needs to be modified to check for this flag so additional bulletins will be
suppressed.\n
Old value:
^DD(2,0,"ACT")= I '$G(DICR),$G(DIC(0))'["I" D ^DGSEC\n
Changing to:
^DD(2,0,"ACT")= I '$G(DICR),$G(DIC(0))'["I",'$G(DGBULSUP) D ^DGSEC\n
DG53P582 ;ALB/BWF; Pre-Init; ; 3/19/2004 8:36am
;;5.3;Registration;**582**;Aug 13, 1993 ENV ;Environment check
point
S XPDABORT=""
D PROGCHK(.XPDABORT)
I XPDABORT="" K XPDABORT
Q PROGCHK(XPDABORT) ;checks for necessary programmer variables
I '$G(DUZ)!($G(DUZ(0))'="@")!('$G(DT))!($G(U)'="^") D
. D BMES^XPDUTL("*****")
. D MES^XPDUTL("Your programming variables are not set up properly.")
. D MES^XPDUTL("Installation aborted.")
. D MES^XPDUTL("*****")
. S XPDABORT=2
Q PRE ;
S ^DD(2,0,"ACT")="I '$G(DICR),$G(DIC(0))'["I",'$G(DGBULSUP) D ^DGSEC"
Q", "", "", ""], ["4380", "TIU APIs for Patient Record Flags", "Routine", "TEXT INTEGRATION UTILITIES", "2004/03/23", "", "Withdrawn", "Controlled Subscription", "", "
These APIs provide functionality needed by Registration
for associating PRF flags with TIU Titles, and for linking PRF Assignment
History records (i.e., actions) to TIU notes.", "", "TIUPRF", ""], ["4381", "Contrast Media seeding between OE/RR & Rad/Nuc Med", "File", "ORDER ENTRY/RESULTS REPORTING", "2004/06/03", "APPROVED", "Active", "Private", "101.43", "
Radiology will release a patch, RA*5*45, that will
shift emphasis from AMIS Codes to CPT Codes regarding contrast media
associations. This will lead the user to associate a relevant contrast medium,
when appropriate, to a detailed or series procedure.\n
The old contrast media data set consisted of the following: Barium, Oral
Cholecystogram, & Unspecified Contrast Media\n
The new data set consists of the following: Iodinated ionic, Iodinated
non-ionic, Gadolinium, Oral Cholecystographic, Gastrografin, Barium, &
unspecified contrast media.\n
Patch RA*5*45 will eliminate keystrokes by mapping barium to barium and oral
cholecystogram to oral cholecystographic. To update the new CONTRAST MEDIA
(#125) in the RAD/NUC MED PROCEDURE (#71) file, Rad/Nuc Med will need to look
at Radiology/Nuclear Medicine specific data located on the "RA" node of the
ORDERABLE ITEMS (#101.43) file.", "", "", ""], ["4382", "Synch up contrast media between files 71 & 101.43", "File", "ORDER ENTRY/RESULTS REPORTING", "2004/03/25", "APPROVED", "Active", "Private", "101.43", "
Requesting this IA for the purpose of efficient
traversal of the ORDERABLE ITEMS (#101.43) file. Rad/Nuc Med needs to know
which orderable items are linked to Rad/Nuc Med procedures. Traversing the
'S.XRAY' cross-reference is the most efficient way to confirm this
relationship.\n
This is related to IA 4381 and patches: RA*5*45 & OR*3*211.", "", "", ""], ["4383", "DGPF ASSIGNMENT LINK TIU PN", "Routine", "REGISTRATION", "2004/03/29", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this API is to facilitate the retrieval
of specific data for an active or inactive Patient Record Flag Assignment to
determine whether a TIU Progress Note has been entered for each assignment
history record. If the request is not from the Owner Site of the Assignment,
no data is returned.", "", "DGPFAPI1", "2018/05/29"], ["4384", "DGPF FILE/DELETE TIU PN LINK", "Routine", "REGISTRATION", "2004/03/29", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this API is to facilitate the Filing
(Linking) and Deleting (Un-Linking) of the TIU PN LINK (#.06) field of the PRF
ASSIGNMENT HISTORY file (#26.14). The TIU PROGRESS NOTE pointer IEN to the
TIU DOCUMENT file (#8925) will be used.", "", "DGPFAPI2", ""], ["4385", "MRA related function Calls from AR into IB", "Routine", "INTEGRATED BILLING", "2004/03/31", "APPROVED", "Active", "Private", "", "
Two MRA related function calls made from AR into the IB
system:\n
1) Determine the MRA Type for a given bill. Pre-MRA bills, post-MRA Medicare
bills or post-MRA non-Medicare bills. This function returns 1, if the bill is
a pre-MRA bill, returns 2 if the bill is a post-MRA Medicare bill, or 3 if the
bill is a post-MRA Medicare bill.\n
2) Return the date Medicare Remittance Advice (MRA) was first activated at
site.", "", "IBCEMU2", ""], ["4386", "DGPF ASSOCIATED FLAG PN TITLE", "File", "TEXT INTEGRATION UTILITIES", "2004/03/29", "APPROVED", "Active", "Controlled Subscription", "8925.1", "
This IA will document the fact that in the PRF LOCAL
FLAG file (#26.11) and the PRF NATIONAL FLAG file (#26.15), there is a field
called TIU PN TITLE (Field #.07) which points to the TIU DOCUMENT DEFINITION
file (#8925.1).\n
The Registration package request permission to store a pointer to the NAME
field (#.01) of the TIU DOCUMENT DEFINITION file (#8925.1).\n", "", "", ""], ["4387", "DGPF ASSIGNMENT TIU PN LINK", "File", "TEXT INTEGRATION UTILITIES", "2004/03/29", "APPROVED", "Active", "Controlled Subscription", "8925", "
This IA will document the fact that in the PRF
ASSIGNMENT HISTORY file (#26.14), there is a field called TIU PN LINK (Field
#.06) which points to the TIU DOCUMENT file (#8925).\n
The Registration package request permission to store the pointer IEN of a TIU
PROGRESS NOTE to the PRF ASSIGNMENT HISTORY file (#26.14) field (#.06).\n", "", "", ""], ["4388", "PRCA(430", "File", "ACCOUNTS RECEIVABLE", "2004/03/29", "", "Pending", "Private", "430", "
Integrated Billing system is referencing the AR global:
^PRCA(430,D0,13). The two data elements checked by the IB system and stored
at this level are: Medicare Contractual Adjustment and Medicare Unreimbursable
Amount.", "", "", ""], ["4389", "Imaging - Install file #9.7", "File", "KERNEL", "2004/04/13", "APPROVED", "Active", "Private", "9.7", "\n\n", "", "", ""], ["4390", "Imaging - PACKAGe file (#9.4)", "File", "KERNEL", "2004/04/13", "APPROVED", "Active", "Private", "9.4", "", "", "", ""], ["4391", "INSURANCE COMPANY FILE ACCESS", "File", "INTEGRATED BILLING", "2004/04/07", "APPROVED", "Active", "Private", "36", "
It has come to my attention that Accounts Receivable
has no Integration Agreement with Integrated Billing to allow A/R to access
the insurance file (#36), even though A/R uses this file extensively for the
following:\n
INSURANCE COMPANY NAME (#.01 field), direct read
INSURANCE COMPANY ADDRESS (fields #.111-#.116), direct read
As a file lookup using ^DIC
As a pointer directly to ^DIC(36) in ACCOUNTS RECEIVABLE file
(#430 - 2 fields - SECONDARY INSURANCE CARRIER (#19) and TERTIARY
INSURANCE CARRIER (#19.1))
As part of a variable pointer on the DEBTOR field (#.01) of the AR
DEBTOR file (#340)\n
An IA is needed to cover these usages.", "", "", ""], ["4392", "PAID EMPLOYEE", "File", "PAID", "2004/04/07", "APPROVED", "Active", "Private", "450", "
Kernel has permission to have read access to the PAID
EMPLOYEE file fields as described in this DBIA.", "", "", ""], ["4393", "DPTNAME", "Routine", "REGISTRATION", "2004/05/03", "", "Retired", "Private", "", "
Kernel has the permission to use FORMAT^DPTNAME to
standardize person name as described in this DBIA.", "", "DPTNAME", ""], ["4394", "Data updates", "Routine", "PHARMACY DATA MANAGEMENT", "2004/04/07", "APPROVED", "Active", "Controlled Subscription", "", "
In support of the Outpatient Pharmacy Automation
Dispense project, Pharmacy Data Management needs to know when changes are made
to entries in the DRUG file (#50). National Drug File data updates make
changes to entries in this file. To meet this need, NDF requests permission
to call routine PSSDGUPD at entry point PSN. The array ^TMP($J,"^",IEN where
IEN is the internal entry number in the DRUG file (#50) wil be sent to this
entry point. The matching and unmatching processes also make changes to the
drug file that need to be sent to PDM. To this end, NDF requests permission
to call routine PSSHUIDG at entry point DRG with the variable PSNB (if an
entry is being matched) or DA (if an entry is being unmatched) representing
the internal entry number in the drug file.", "", "PSSDGUPD", ""], ["4395", "FEE PHARMACY API", "Routine", "FEE BASIS", "2004/05/04", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains APIs related to the Pharmacy
module of Fee Basis.", "", "FBRXUTL", ""], ["4396", "DBIA4396", "Routine", "FEE BASIS", "2004/05/04", "APPROVED", "Active", "Controlled Subscription", "", "
FEE BASIS APIs.", "", "FBUTL", ""], ["4397", "DIAUTL", "Routine", "1", "2004/04/08", "APPROVED", "Active", "Supported", "", "
Auditing Utilities. Auditing allows VA FileMan users
and developers to look back through the dimension of time at prior values in
any file. Auditing is not just a tool that enhances quality control and system
security. It also allows the easy retrieval of "old" values (e.g., "address",
"maiden name," and so on).\n", "", "DIAUTL", "2016/02/05"], ["4398", "DBIA4398", "Routine", "REGISTRATION", "2004/04/09", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VAUTOMA", "2015/09/08"], ["4399", "Local FileMan Array DIPA()", "Other", "1", "2004/04/13", "APPROVED", "Active", "Supported", "", "
Allow usage of the DIPA() array for developers.", "", "", ""], ["4400", "DBIA4400 MODIFY OPTIONS FOR LSSD SHUTDOWN", "Routine", "IFCAP", "2004/04/12", "", "Withdrawn", "Controlled Subscription", "", "\n\n
At the beginning of a site's conversion to CoreFLS software, the Legacy
Software Shut Down (LSSD) program is run to convert the IFCAP, AEMS/MERS, and
Equipment/Turn-In Request packages to a read-only state. These packages will
be referred to as legacy packages. One of the steps in the program is
disabling any options in the legacy systems which could effect an addition,
modification, or deletion of data to the site's VistA database. All legacy
options are disabled except those in a pre-determined list, which is known as
the 'Options to Leave ALone' list. The list is in the LSSD (#449.1) file and
will be referred to here as the List.\n
Before a site converts to CoreFLS, the site will continue to install patches
as necessary to fix bugs or add functionality to the legacy packages. When
adding functionality, a patch may add or enhance or delete an option or group
of options. Later on, when the site runs the LSSD shutdown and converts to
CoreFLS, the site may need to continue using the functionality provided by
those new options. In that case, it will become necessary to prevent those
options from being disabled by the shutdown. To do this, the options must
have been added to the List before the shutdown was run. Likewise, there may
be options in the List that a future patch may remove or enhance such that
those options should be disabled by the legacy shutdown. Those options should
then be removed from the List before the legacy shutdown is run. This IA
describes the API that patch developers should use to add or remove options
from the List. The API must be invoked in the post-install executable of a
patch.\n
In any patch that uses this API, the patch must also include a patch
dependency for the LSSD patch, PRC*5.1*65.", "", "PRCLOP11", ""], ["4401", "EXCEPTION PURGE", "File", "CLINICAL INFO RESOURCE NETWORK", "2004/04/23", "APPROVED", "Active", "Private", "991.1", "
The Registration package is writing a clean-up routine
to purge patient records that exist with only the CURRENT MEANS TEST INDICATOR
field (#.14) and the MPI node existing. We are also checking the CIRN HL7
EXCEPTION LOG file (991.1) and purging exceptions if they exist for these
records. Registration is requesting an integration agreement with the CIRN
package to purge these exceptions.", "", "", ""], ["4402", "ID Nodes in CPT file (#81)", "File", "1", "2004/04/22", "APPROVED", "Active", "Private", "81", "
The Code Text Descriptors project modifies the
identifier on the SHORT NAME (#2) field in the CPT file (81).\n
The new identifier makes a function call into $$IDCPS^ICPTID to return
versioned data for both the SHORT NAME and the status in the INACTIVE FLAG.
The function has one input parameter, the Internal Entry Point for file #81.
Routine ICPTID will also look to see if the package namespaced variable
ICPTVDT is in the environment. ICPTVDT is a versioning date. If ICPTVDT is
not found in the environment (not supplied) then TODAY will be used and the
SHORT NAME and INACTIVE FLAG for TODAY will be displayed. If the variable
ICPTVDT is found in the environment, and is a date other than TODAY, then the
appropriate SHORT NAME and INACTIVE FLAG will be displayed for the date.\n
The identifiers will be changed to:\n
^DD(81,0,"ID",2)= D EN^DDIOL((" "_$$IDCPS^ICPTID(+Y)),"","?0") D:$D(SRSITE)
^SROCPT\n
This will be exported in the combined build CTD UTIL 1.0, containing
ICPT*6.0*19, ICD*18.0*12 and LEX*2.0*30.\n", "", "", ""], ["4403", "ID Nodes in CPT Modifier file (#81.3)", "File", "1", "2004/04/22", "APPROVED", "Active", "Private", "81.3", "
The Code Text Descriptors project modifies the
identifier on the NAME (#.02) field in the CPT Modifier file (81.3).\n
The new identifier makes a function call into $$IDMDS^ICPTID to return
versioned data for both the NAME and the status in the INACTIVE FLAG. The
function has one input parameter, the Internal Entry Point for file #81.3.
Routine ICPTID will also look to see if the package namespaced variable
ICPTVDT is in the environment. ICPTVDT is a versioning date. If ICPTVDT is
not found in the environment (not supplied) then TODAY will be used and the
NAME and INACTIVE FLAG for TODAY will be displayed. If the variable ICPTVDT
is found in the environment, and is a date other than TODAY, then the
appropriate NAME and INACTIVE FLAG will be displayed for the date.\n
The identifier will be changed to:\n
^DD(81.3,0,"ID",.02)= D EN^DDIOL((" "_$$IDMDS^ICPTID(+Y)),"","?0")\n
This will be exported in the combined build CTD UTIL 1.0, containing
ICPT*6.0*19, ICD*18.0*12 and LEX*2.0*30.", "", "", ""], ["4404", "ID Nodes in ICD Dx file (#80)", "File", "1", "2004/04/22", "APPROVED", "Active", "Private", "80", "
The Code Text Descriptors project modifies the
identifier on the DIAGNOSIS (#3) field in the ICD DIAGNOSIS file (80).\n
The new identifier makes a function call into $$IDDXS^ICDID to return
versioned data for both the DIAGNOSIS and the status in the INACTIVE FLAG.
The function has only one input parameter, the Internal Entry Number for file
#80. Routine ICDID will also look to see if the package namespaced variable
ICDVDT is in the environment. ICDVDT is a versioning date. If ICDVDT is not
found in the environment (not supplied) then TODAY will be used and the
DIAGNOSIS and INACTIVE FLAG for TODAY will be displayed. If the variable
ICDVDT is found in the environment, and is a date other than TODAY, then the
appropriate DIAGNOSIS and INACTIVE FLAG will be displayed for the date.\n
The identifier will be changed to:\n
^DD(80,0,"ID",3)= D EN^DDIOL((" "_$$IDDXS^ICDID(+Y)),"","?0")\n
This will be exported in the combined build CTD UTIL 1.0, containing
ICPT*6.0*19, ICD*18.0*12 and LEX*2.0*30.\n", "", "", ""], ["4405", "ID Nodes in ICD OP file (#80.1)", "File", "1", "2004/04/22", "APPROVED", "Active", "Private", "80.1", "
The Code Text Descriptors project modifies the
identifier on the OPERATION/PROCEDURE (#4) in the ICD OPERATION/PROCEDURE file
(80.1).\n
The new identifier makes a function call into $$IDOPS^ICDID to return
versioned data for both the OPERATION/PROCEDURE and the status in the INACTIVE
FLAG. The function has only one input parameter, the Internal Entry Number
for file #80.1. Routine ICDID will also look to see if the package namespaced
variable ICDVDT is in the environment. ICDVDT is a versioning date. If
ICDVDT is not found in the environment (not supplied) then TODAY will be used
and the OPERATION/PROCEDURE and INACTIVE FLAG for TODAY will be displayed. If
the variable ICDVDT is found in the environment, and is a date other than
TODAY, then the appropriate OPERATION/PROCEDURE and INACTIVE FLAG will be
displayed for the date.\n
The identifiers will be changed to:\n
^DD(80.1,0,"ID",4)= D EN^DDIOL((" "_$$IDOPS^ICDID(+Y)),"","?0")\n
This will be exported in the combined build CTD UTIL 1.0, containing
ICPT*6.0*19, ICD*18.0*12 and LEX*2.0*30.\n", "", "", ""], ["4406", "ID Nodes in DRG file (#80.2)", "File", "1", "2004/04/22", "APPROVED", "Active", "Private", "80.2", "
The Code Text Descriptors project modifies the
identifier on the INACTIVE (#15) field of the DRG file (80.2).\n
The new identifier makes a function call into $$IDDGS^ICDID to return
versioned data for both the DESCRIPTION and the status in the INACTIVE field.
The function has only one input parameter, the Internal Entry Number for file
#80.2. Routine ICDID will also look to see if the package namespaced variable
ICDVDT is in the environment. ICDVDT is a versioning date. If ICDVDT is not
found in the environment (not supplied) then TODAY will be used and the
DESCRIPTION and INACTIVE fields for TODAY will be displayed. If the variable
ICDVDT is found in the environment, and is a date other than TODAY, then the
appropriate DESCRIPTION and INACTIVE fields will be displayed for the date.\n
The identifiers will be changed to:\n
^DD(80.2,0,"ID",15)= D EN^DDIOL((" "_$$IDDGS^ICDID(+Y)),"","?0")\n
This will be exported in the combined build CTD UTIL 1.0, containing
ICPT*6.0*19, ICD*18.0*12 and LEX*2.0*30.\n", "", "", ""], ["4407", "DBIA4407", "File", "ACCOUNTS RECEIVABLE", "2004/04/19", "", "Withdrawn", "Private", "", "
In order to protect against loosing the set up for the
customization features in the ^DISV global, patch PRCA*4.5*217 requests
approval to create the ^RCCSTM global to store the selections within the CU
Customize option. This will allow the most recently selected parameters and
printers to be recalled by a user when customizing the screen and setting up
the printer options.\n
The information is stored in ^RCCSTM(DUZ,"RCDPRPLM",SCREEN/OPTION). An
example is in routine RCDPRPL2 at line RCDPRPL2+124: S
^RCCSTM(DUZ,"RCDPRPLM","RECEIPT")=TYPE_"^"_DEVICE", "", "", ""], ["4408", "DBIA4408", "Routine", "REGISTRATION", "2004/06/24", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGIBDSP", ""], ["4409", "XUP", "Routine", "KERNEL", "2004/04/23", "APPROVED", "Active", "Supported", "", "
Supported APIs or extrinsic function in routine XUP.", "", "XUP", ""], ["4410", "BPSUTIL", "Routine", "E CLAIMS MGMT ENGINE", "2005/11/10", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains several APIs which are used to
retrieve some specific information from ECME. $$ECMEON is used to verify if
the ECME Application is turned ON or OFF. Other applications, such as
Outpatient Pharmacy, need to verify this switch before submitting a
prescription to be electronically billed. $$CMOPON is used to verify if the
ECME CMOP switch is ON or OFF. $$BPSPLN returns the insurance PLAN NAME field
for a particular BPS TRANSACTION file entry. $$BPSINSCO returns the Insurance
Company (902.33) field from the BPS TRANSACTION file.", "", "BPSUTIL", "2007/02/13"], ["4411", "BPSECMP2", "Routine", "E CLAIMS MGMT ENGINE", "2005/11/10", "APPROVED", "Active", "Private", "", "
This API is used to send billing information from ECME
to IB.", "", "BPSECMP2", ""], ["4412", "BPSOSRX", "Routine", "E CLAIMS MGMT ENGINE", "2004/06/21", "APPROVED", "Active", "Private", "", "
This API is used by external applications to inquire
about the status of a ECME Claim.", "", "BPSOSRX", "2010/08/25"], ["4413", "DBIA4413", "Routine", "E CLAIMS MGMT ENGINE", "2005/11/09", "", "Retired", "Private", "", "
This API is used to format NDC codes: NNNNN-NNNN-NN", "", "BPSECFM", ""], ["4414", "GMV MARK ERROR", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: GMV MARK ERROR
TAG: ERROR
ROUTINE: GMVUTL1
RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
DESCRIPTION:
This remote procedure call marks a selected vitals record in the GMRV
Vital Measurement (#120.5) file as entered-in-error.\n
This remote procedure call is documented in Integration Agreement 4414.
INPUT PARAMETER: GMVDATA
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 60
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
GMVDATA contains the following information:\n
piece1^piece2^piece3\n
where piece1 = FILE 120.5 IEN
piece2 = FILE 200 IEN (i.e., DUZ)
piece3 = A single value to indicate the reason for the error.
1 = INCORRECT DATE/TIME, 2 = INCORRECT READING, 3 =
INCORRECT PATIENT and 4 = INVALID RECORD
RETURN PARAMETER DESCRIPTION:
If the record is marked as entered in error, RESULT is set to "OK".
Otherwise, RESULT is set to "Record Not Found"\n
Example:
> S GMVDATA="1560^547^1"
> D ERROR^GMVUTL1(.RESULT,GMVDATA) ZW RESULT
> RESULT="OK"", "GMV MARK ERROR", "", ""], ["4415", "BPSNCPDP", "Routine", "E CLAIMS MGMT ENGINE", "2004/06/21", "APPROVED", "Active", "Controlled Subscription", "", "
This API is used by external applications to generate
claims in the Electronic Claims Management Engine.\n", "", "BPSNCPDP", "2011/01/04"], ["4416", "GMV EXTRACT REC", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: GMV EXTRACT REC
TAG: GETVM
ROUTINE: GMVGETD
RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
This remote procedure call retrieves vital records from the GMRV Vital
Measurement (#120.5) file for a selected patient within a given date
span.\n
This remote procedure call is documented in Integration Agreement 4416.
INPUT PARAMETER: GMRVDATA
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 30
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
GMRVDATA consists of 4 pieces of information:
piece1^piece2^piece3^piece4\n
where piece1 = Patient (#2) file pointer (i.e., DFN)
piece2 = End date of search (FileMan internal format)
piece3 = single vital type abbreviation (File 120.51, Field 1)
[optional] If not defined, the default is
"T;P;R;BP;HT;WT;PN;PO2;CG;CVP"
piece4 = Start date of search (FileMan internal format)
RETURN PARAMETER DESCRIPTION:
Returns the name of the global array (i.e., ^TMP($J,"GRPC")) containing a
list of vital records for the selected patient within the defined date
range.\n
The TMP global contains:
^TMP($J,"GRPC",n)=piece1^piece2\n
where piece1 = File 120.5 IEN
piece2 = a string of text in the following format:
Date/time taken (external) Vital Type Abbreviation:
Rate U.S. units (Metric value) (Qualifiers)
n = sequential number starting at 1.\n\n
Example:
> S GMRVDATA="134^3051028^BP^3051001"
> D GETVM^GMVGETD(.RESULT,GMRVDATA) ZW RESULT
> RESULT="^TMP(538999278,"GRPC")"
> D ^%G
> Global ^TMP($J,"GRPC"
> ^TMP(538999278,"GRPC",1)=8858^10/11/05@16:35 B/P: 120/80* (L
ARM,
SITTING, CAROTID, CALF) _VITPROVIDER,ONE
> 2)=8961^10/20/05@14:47 B/P: 128/81* (L ARM,
SITTING, PALPATED) _VITPROVIDER,TWO\n
If there is no data, then the following is returned:\n
^TMP($J,"GRPC",1)=0^NO VITALS/MEASUREMENTS ENTERED WITHIN THIS PERIOD", "GMV EXTRACT REC", "", ""], ["4417", "REMINDER DIALOG DETAILS FOR TIU TEMPLATES IN CPRS", "Routine", "CLINICAL REMINDERS", "2005/11/09", "APPROVED", "Active", "Controlled Subscription", "", "
This API will accept a Reminder Dialog IEN from file#
801.41 and a patient DFN. This API will return the format of a reminder
dialog.\n", "", "PXRMRPCD", ""], ["4418", "ADT HL7 MSG", "Other", "REGISTRATION", "2004/04/28", "APPROVED", "Active", "Supported", "", "
The following Protocols are Supported for packages to
hang their protocols on:\n
VAFC ADT-A01 SERVER
VAFC ADT-A02 SERVER
VAFC ADT-A03 SERVER
VAFC ADT-A04 SERVER
VAFC ADT-A08 SERVER
VAFC ADT-A08-SDAM SERVER
VAFC ADT-A08-TSP SERVER
VAFC ADT-A11 SERVER
VAFC ADT-A12 SERVER
VAFC ADT-A13 SERVER
VAFC ADT-A19 SERVER", "", "", ""], ["4419", "DBIA4419", "Routine", "INTEGRATED BILLING", "2004/05/07", "APPROVED", "Active", "Supported", "", "
IBBAPI is a new routine to return insurance data to
calling VistA applications.", "", "IBBAPI", "2023/01/25"], ["4420", "GMV DLL VERSION", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV DLL VERSION
TAG: DLL
ROUTINE: GMVUTL8
RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
DESCRIPTION:
Returns a YES or NO response to indicate if the Dynamic Link Library
(DLL) file should be used.\n
This remote procedure call is documented in Integration Agreement 4420.
INPUT PARAMETER: GMVX
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 50
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
This value is the name of the file and the date/time associated with it
(e.g., GMV_VITALSVIEWENTER.DLL:v. 07/21/05 10:34).
RETURN PARAMETER DESCRIPTION:
Returns YES if the file can be used. Returns NO, if the file cannot be
used. Returns null if the file was not found.\n
Example:
> S GMVX="GMV_VITALSVIEWENTER.DLL:v. 07/21/05 10:34"
> D DLL^GMVUTL8(.RESULT,GMVX) ZW RESULT
> RESULT="NO"", "GMV DLL VERSION", "", ""], ["4421", "HLO $$RUNNING", "Routine", "HEALTH LEVEL SEVEN", "2005/11/14", "", "Pending", "Private", "", "
This is a private agreement that is being provided to
Pharmacy Benefit Mangement as a special consideration due to their partnering
with HLO to test and release HLO in conjunction with Pharmacy Benefit
Managment Phase III.\n", "", "HLOUSR", ""], ["4422", "READ OF AE CROSS REFERENCE", "File", "SCHEDULING", "2005/11/17", "APPROVED", "Active", "Controlled Subscription", "44", "
OR request permission to do a read on file #44 "AE"
cross reference. This cross reference allows for a quick way to find all
hospital locations that have the same value for the "ADMINISTER INPATIENT
MEDS?" field.\n", "", "", ""], ["4423", "BPS NCPDP FORMATS", "File", "E CLAIMS MGMT ENGINE", "2005/11/10", "APPROVED", "Active", "Private", "9002313.92", "
Allowing subscribers read access to BPS NCPDP FORMATS
file.", "", "", "2011/01/03"], ["4424", "PCE Patient Immunization Data", "Routine", "PCE PATIENT CARE ENCOUNTER", "2005/11/29", "APPROVED", "Active", "Supported", "", "
The API was created to support a requirement for
MyhealtheVet project regarding a specific patient's immunization data.", "", "PXIMMAPI", ""], ["4425", "DBIA4425", "File", "REGISTRATION", "2004/05/07", "APPROVED", "Active", "Controlled Subscription", "41.41", "
Integrated Billing needs to reference ADC cross
reference to the PRE-REGISTRATION AUDIT (#41.41) file to determine if/when a
patient was pre-registered prior to treatment.", "", "", ""], ["4426", "TIU CHECK FOR EMPTY DOCUMENT", "Routine", "TEXT INTEGRATION UTILITIES", "2004/05/18", "APPROVED", "Active", "Controlled Subscription", "", "
This M function takes as input a TIU Document IEN and
returns 1 if there is no text in the document and 0 if there is text.", "", "TIULF", ""], ["4427", "DBIA4427", "Routine", "SURGERY", "2004/05/13", "APPROVED", "Active", "Private", "", "
This function will return an array containing case
level anesthesia times, service connector, and clinical indicators for
surgical cases that fall within the from and through dates based on the date
of operation.", "", "SROANEST", ""], ["4428", "ORWRP TIME/OCC LIMITS ALL", "Other", "ORDER ENTRY/RESULTS REPORTING", "2004/05/19", "APPROVED", "Active", "Private", "", "
This DBIA document the usage of the CPRS parameter
ORWRP TIME/OCC LIMITS ALL. CP uses the
$$GET^XPAR("USR.`"_DUZ_"^DIV^SYS^PKG","ORWRP TIME/OCC LIMITS ALL",1,"I") call
to get the default date/time and occurence limit for all reports. CP will use
this call to get the occurence limit so CP can return the accurate number of
CP data to CPRS for display in the CPRS Reports tab.", "", "", ""], ["4429", "CSL UTILITY LOOKUP INTO HL7 MESSAGE", "File", "ORDER ENTRY/RESULTS REPORTING", "2004/06/10", "", "Withdrawn", "Private", "101", "
Accessing routine name ^CSLUTPR1, and can only be
accessed from Programmer mode. There is another related IA (4430), connected
with this routine for accessing file 773 (^HLMA), 772 (^HL(772,)) and 779
(^HL(779.001,))\n
This agreement will permit the direct read of ^ORD(101,"B" cross reference to
be able to display all HL7 Protocols related to CSL. Input will be "CSL_"
concatenated with a package name to limit the search. Once a complete
protocol is selected, the software will extract the Event Message and the
Event Type by directly accessing ^ORD(101,"B", Protocol Name, Protocol
pointer). The Protocol pointer looks at ^ORD(101, Protocaol Pointer, 770),
$Piece 1. If the $P1 is null, then the Message Type pointer is found in
$Piece 11, and the Event Type pointer is found in $Piece 4. If $P1 is not
null, then Message Type pointer is found in $Piece 3, and Event Type pointer
is found in $Piece 4. The name of the Message Type is then found in
^HL(771.2,message pointer,0), $Piece 1, and the Event Type is found in
^HL(779.001,event pointer,0),$Piece 1.", "", "CSLUTPR1", ""], ["4430", "DBIA4430", "Other", "REGISTRATION", "2004/05/24", "APPROVED", "Active", "Private", "", "
Integrated billing has attached the IB option, IBJD
PERCENT PREREGISTERED, to the Registration menu Outputs for Preregistration
menu, [DGPRE PRE-REGISTER OUTPUTS].\n", "", "", ""], ["4431", "HL7 UTILITY TO VIEW MESSAGES BY PROTOCOL", "File", "HEALTH LEVEL SEVEN", "2004/06/10", "", "Withdrawn", "Private", "773", "
This agreement will permit the direct read of
^HLMA(EIN, and ^HL(772 to extract message text for display on a CRT. Input is
based on the user selecting the Interface Protocol from ^ORD(101 (see IA
4429), which derives the Message Type and Event Type. The routine will search
for HL7 messages based on the Message and Event Type. The user is also
prompted for filters on Segments and text string within the segment. These
Segments are found in ^HL(772,EIN. The system will also report the EIN of any
^HLMA record that is encountered that does not have a ^HLMA(EIN,0) node or an
^HLMA(EIN,'MSH',1,0).", "", "CSLUTPR1", ""], ["4432", "Return Latest Fee Basis Calendar Year", "Routine", "FEE BASIS", "2007/04/03", "APPROVED", "Active", "Controlled Subscription", "", "
The Radiology package has a need to determine the
latest Calendar Year of the 162.99 FEE BASIS HCFA CONVERSION File.", "", "FBAAFSR", "2007/05/16"], ["4433", "DBIA4433", "Routine", "SCHEDULING", "2004/05/25", "APPROVED", "Active", "Supported", "", "", "", "SDAMA301", ""], ["4434", "DBIA4434", "File", "INTEGRATED BILLING", "2004/05/26", "APPROVED", "Active", "Private", "350", "", "", "", ""], ["4435", "DBIA4435", "Routine", "INTEGRATED BILLING", "2004/05/27", "APPROVED", "Active", "Private", "", "
IB functions are to serve AR in matching the ECME
number to the respective IB bill ($$RXBIL component) and to check the status
of a claim in Claims Tracking ($$REJECT component).", "", "IBNCPDPU", "2010/12/13"], ["4436", "DBIA4436", "Routine", "REGISTRATION", "2004/06/03", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement will allow the Subscribing Packages the
ability to create and delete a Fee PTF entry using the following Registration
API call points.", "", "DGPTFEE", ""], ["4437", "SUBSCRIBER cleanup: PROTOCOL (101) file", "Other", "KERNEL", "2004/06/10", "", "Withdrawn", "Private", "", "
Radiology/Nuclear Medicine has found the need in
developing RA*5.0*47 to remove the 'MAGD SEND ORM' protocol from the
SUBSCRIBER (775) multiple on the PROTOCOL (101) file. The event driver
protocols impacted are: RA REG RA REG 2.3 RA CANCEL RA CANCEL 2.3 RA EXAMINED
RA EXAMINED 2.3\n
These event driver protocols generate v2.1 & v2.3 ORM Health Level Seven (HL7)
messages. Imaging, through the use of 'MAGD SEND ORM', received ORM messages
in this manner.\n
Imaging now needs to receive v2.4 HL7 messages. In an effort to prevent
needless use of disk space, I'd like to eliminate the creation of these
non-v2.4 HL7 Imaging related ORM messages.\n
A direct global read of the whole file cross-reference "AB" on the SUBSCRIBER", "", "", ""], ["4438", "DBIA4438", "Routine", "REGISTRATION", "2004/07/30", "", "Retired", "Controlled Subscription", "", "", "", "DGENEGT1", ""], ["4439", "MAIL GROUP REMOTE MEMBER", "File", "MAILMAN", "2004/06/30", "APPROVED", "Active", "Private", "3.8", "
Integrated Billing needs a ONE-TIME ONLY Integration
Agreement to allow manipulation of the data in a mail group entry set up with
a server option as a remote member. Since no utility exists to delete a remote
member from the mail group file, the following access is requested:\n
1. The ability to read the remote members from one mail group, add them to
another mail group, and delete them from the original mail group. This would
be done once, in the Post-install routine IBY232PO. The following code would
be used:\n
N IBMCR,IBMCH,DLAYGO,DIC,DIK,DA,D0,DD,Z,Z0 S
IBMCR=+$O(^XMB(3.8,"B","MCR",0)),IBMCH=+$O(^XMB(3.8,"B","MCH",0)) S Z=0 F S
Z=$O(^XMB(3.8,IBMCR,6,Z)) Q:'Z S Z0=$P($G(^XMB(3.8,IBMCR,6,Z,0)),U) I Z0'=""
D
. I '$D(^XMB(3.8,IBMCH,6,"B",Z0)) D
.. S DLAYGO=3.812,DIC(0)="L",X=Z0,DA(1)=IBMCH,DIC="^XMB(3.8,"_DA(1)_",6," D
FILE^DICN K DO,DD,DA,DLAYGO,DIC
.. I Y>0 S DA(1)=IBMCR,DA=Z,DIK="^XMB(3.8,"_DA(1)_",6," D ^DIK", "", "", ""], ["4440", "DBIA4440", "Routine", "KERNEL", "2004/06/17", "APPROVED", "Active", "Supported", "", "
This API is used to tell if the current account is the
main production or a clone or test account.", "", "XUPROD", ""], ["4441", "Direct set DD node", "File", "1", "2004/06/29", "APPROVED", "Active", "Private", "", "
Kernel requests permission to directly set
^DD(file,field) from a post-installation routine. The routine will modify the
data dictionary definition of the NEW PERSON file (#200). Direct setting of
the ^DD global will allow updating the data dictionary definition wihout
exporting the field.\n
Directly set $P(^DD(200,.01,0),U,5,99), to call a differnt API to process the
input of the Name field.\n
Directly set $P(^DD(200,20.2,0),U,5,99) to update the input transform.\n
Directly set ^DD(200,.01,21, to update the help text of the Name field.", "", "", ""], ["4442", "DBIA4442", "Routine", "MENTAL HEALTH", "2005/01/26", "APPROVED", "Active", "Controlled Subscription", "", "
API to return the scoring for a psychological test.", "", "YTAPI10", ""], ["4443", "POINTER TO THE ORDER DIALOG FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2004/07/02", "APPROVED", "Active", "Private", "101.41", "
This DBIA allow for subscribing package to point to
file 101.41.", "", "", ""], ["4444", "DRUG WARNING TEXT", "Routine", "PHARMACY DATA MANAGEMENT", "2004/07/02", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this call is to return the freetext
warning label text for a given warning number.", "", "PSSWRNA", ""], ["4445", "ACCESS TO FILE 50.625", "File", "NATIONAL DRUG FILE", "2004/07/02", "APPROVED", "Active", "Private", "50.625", "
PDM requests permission to use direct global reads to
look at all fields of the WARNING LABEL-ENGLISH file (#50.625) to retrieve
drug warning information from the new commercial data source. These warnings
will be used by the laser labels routines to print the warning labels in the
patient's language preference for the patient's prescription bottle.\n
Note: there is a one-to-one correspondence for entries in the WARNING
LABEL-ENGLISH file (#50.625) and the WARNING LABEL-SPANISH file (#50.626).", "", "", ""], ["4446", "ACCESS TO FILE 50.626", "File", "NATIONAL DRUG FILE", "2004/07/06", "APPROVED", "Active", "Private", "50.626", "
PDM requests permission to use direct global reads to
look at all fields of the WARNING LABEL-SPANISH file (#50.626) to retrieve
drug warning information from the new commercial data source. These warnings
will be used by the laser labels routines to print the warning labels in the
patient's language preference for the patient's prescription bottle.\n
Note: there is a one-to-one correspondence for entries in the WARNING
LABEL-ENGLISH file (#50.625) and the WARNING LABEL-SPANISH file (#50.626).", "", "", ""], ["4447", "ADDING ENTRIES TO VDEF FILES", "Routine", "VISTA DATA EXTRACTION FRAMEWORK", "2004/08/31", "APPROVED", "Active", "Controlled Subscription", "", "
This Integration Agreement allows the POSTKID^VDEFVU()
API to be used in a post-init to add an entry to the VDEF Event Description
file (#577) and, if necessary, to the VDEF Event Subtype (#577.4) and VDEF
Custodial Package (#579.6) files. An individual call contains information for
a single entry in the VDEF Event Description file. If necessary, an EVENT
DESCRIPTION is added for a new entry in the VDEF Event Subtype file.", "", "VDEFVU", ""], ["4448", "ACCESS TO FILE 50.627", "File", "NATIONAL DRUG FILE", "2004/07/06", "APPROVED", "Active", "Private", "50.627", "
PDM requests permission to use direct global reads to
look at the cross-reference and fields of the WARNING LABEL MAP file (#50.627)
to retrieve the entry numbers for the WARNING LABEL-ENGLISH file (#50.625) or
the WARNING LABEL-SPANISH file (#50.626). These files contain the drug warning
information from the new commercial data source. These warnings will be used
by the laser labels routines to print the warning labels in the patient's
language preference for the patient's prescription bottle.", "", "", ""], ["4449", "WARNING LABEL LIST", "Routine", "PHARMACY DATA MANAGEMENT", "2004/07/06", "APPROVED", "Active", "Controlled Subscription", "", "
This call will return the warning label list associated
with a drug. The list will consist of numbers or numbers followed by the
letter "N", separated by commas. Entries without the "N" are from the old RX
CONSULT file (#54) and entries with the "N" are from the new commercial data
source's WARNING LABEL-ENGLISH file (#50.625) or WARNING LABEL-SPANISH file
(#50.626).", "", "PSSWRNA", ""], ["4450", "DENTAL READ OF FILE 409.68", "File", "SCHEDULING", "2004/07/06", "APPROVED", "Active", "Private", "409.68", "
Dental transmits its dental specific data to the AAC
once a week. The Decision Support staff requested that Dental include all
data elements it needed in the HL7 extracts of VistA that are transmited to
the AAC. One of the VistA fields requested by the VA-DSS is the OUTPATIENT
ENCOUNTER (#409.68) date and time as well as the internal entry number. The
dental encounter file (#228.1) has a pointer to the VISIT (#900010) file. PCE
developers have said that for each entry in file 409.68 there should be a
1-to-1 relationship with the VISIT file. Thus the DENTAL package is
requesting to be allowed to do direct global reads of the "AVSIT" cross
reference on file 409.68 to get the 409.68 record number corresponding to a
VISIT file record number. Then using the 409.68 record number, a direct
global read will be done for the .01 field of that record to get the encounter
date and time.", "", "", ""], ["4451", "GMVVISN", "Routine", "GEN. MED. REC. - VITALS", "2004/09/15", "", "Retired", "Supported", "", "
This IA supports the VISN Support Service Center's
request to extract data for the Financial and Clinical Data Mart.", "", "GMVVISN", ""], ["4452", "OR PARAMETERS FOR CLINICAL REMINDERS", "Other", "ORDER ENTRY/RESULTS REPORTING", "2004/07/13", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Reminders request permission to use the
following OR parameters:\n
ORQQPX DEFAULT LOCATIONS ORQQPX NEW REMINDER PARAMS ORQQPX REMINDER TEXT AT
CURSOR\n
All three of these parameters are used in CPRS to determine Clinical Reminder
set-up for an user.", "", "", ""], ["4453", "Edit COUNTY(#.117) field of the PATIENT(#2) file", "Routine", "REGISTRATION", "2004/07/13", "APPROVED", "Active", "Private", "", "
Patch XU*8*328 is updating the COUNTY multiple of the
STATE file. The Read data is obtained using the following code:
. S FLDS=".01;.0905;.114;.115;.116;.117"
. ; .01=NAME
. ; .0905=1U4N
. ; .114=CITY
. ; .115=STATE FILE POINTER
. ; .116=ZIP CODE
. ; .117=COUNTY MULTIPLE IEN
. ;
. D GETS^DIQ(2,DFN_",",FLDS,"I","PDATA","ZER")\n
Any County(s) who are found to be in error are having their names changed to
"ZZ"_<current name> and VA COUNTY CODE changed to a 900 number. As part of
the post install a manual entry point has been created to attempt to change
any patient who's County begins with "ZZ"_<smoething> to the proper county,
After getting the Patient's current ZIP Code an API call is made to the POSTAL
CODE(#5.12) file, editing of the COUNTY(.117) field will take place If And
Only If the following three things are true: 1. The Patient's City matches the
POSTAL CODE(#5.12) file City. 2. The Patient's State matches the POSTAL
CODE(#5.12) State. 3. The Patient's ZIP code matches the POSTAL CODE(#5.12)
ZIP code.\n
The following is the code that does the matching and the message:
... I ZDATA(III,"CITY")=CITY,ZDATA(III,"STATE
POINTER")=SIEN,ZDATA(III," POSTAL CODE")=ZIP D Q
.... S FLAG=1
.... N DIERR,ZERR,FDA
.... S FDA(2,DFN_",",.117)=ZDATA(III,"COUNTY")
.... D FILE^DIE("E","FDA","ZERR")
.... I $D(DIERR) D NAME,MES^XPDUTL(" **Unable to file Patient's
COUNTY.") Q
.... Q
... Q
.. I 'FLAG D NAME,MES^XPDUTL(" ** City and State do not match ZIP
code.")", "", "XU8P328D", ""], ["4454", "Direct read of global DD('KWIC'", "File", "1", "2004/07/12", "APPROVED", "Active", "Supported", "", "
This IA covers the ability to read the global node
^DD("KWIC". There is currently no other way to access the string located in
this node other than a direct global read.", "", "", ""], ["4455", "API FOR MYHEALTHEVET PATIENT WELLNESS REMINDERS", "Routine", "CLINICAL REMINDERS", "2005/01/03", "APPROVED", "Active", "Private", "", "
This DBIA allowed Health Summary and the MyHealtheVet
application access the to patient Wellness Reminders.", "", "PXRMHVET", ""], ["4456", "POINTER TO THE FILE# 409.67", "File", "SCHEDULING", "2004/08/03", "APPROVED", "Active", "Controlled Subscription", "409.67", "
This DBIA will allowed Clinical Reminders to point to
file# 409.67", "", "", ""], ["4457", "ACCESS TO PTF API FOR CLINICAL REMINDER INDEX", "Routine", "REGISTRATION", "2004/08/04", "APPROVED", "Active", "Controlled Subscription", "", "
This API will allowed access to the PTF^DGPTPXRM API.", "", "DGPTPXRM", ""], ["4458", "YTAPI10A", "Routine", "MENTAL HEALTH", "2006/08/03", "APPROVED", "Active", "Private", "", "", "", "YTAPI10A", ""], ["4459", "MyHealtheVets Demographics", "File", "REGISTRATION", "2005/12/02", "APPROVED", "Active", "Private", "2", "
This DBIA allows the MyHealtheVet Demographics
application access to fields in the PATIENT file.\n", "", "", ""], ["4460", "DBIA4460", "Routine", "EVENT CAPTURE", "2005/12/05", "APPROVED", "Active", "Supported", "", "
Provides a set of APIs to store and retrieve data for
field #42 (PROVIDER MULTIPLE) in EVENT CAPTURE PATIENT file (#721).\n\n\n", "", "ECPRVMUT", ""], ["4461", "GMV LOCATION SELECT", "Remote Procedure", "GEN. MED. REC. - VITALS", "2006/01/03", "APPROVED", "Active", "Private", "", "\n
NAME: GMV LOCATION SELECT
TAG: RPC
ROUTINE: GMVRPCHL
RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION: Select a hospital location by name, from a patient appointment
or from a patient admission.\n
INPUT PARAMETER: OPTION
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 10
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Routine tag line in GMVRPCHL to call.
INPUT PARAMETER: DATA
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 100
REQUIRED: YES
SEQUENCE NUMBER: 2
DESCRIPTION:
Other data as required for the call.
RETURN PARAMETER DESCRIPTION:
This remote procedure call allows the user to select a hospital
location.\n
The entry point is RPC^GMVRPCHL. It has input parameters of RESULTS,
OPTION and DATA (ex. RPC^GMVRPCHL(.RESULTS,OPTION,DATA).\n
The RESULTS variable will contain the ^TMP("GMVHLOC",$J) global array
reference. The ^TMP("GMVHLOC",$J) global array contains the results.\n
The OPTION variable identifies a line label in the GMVRPCHL routine that
will be invoked to process the call.\n
The DATA variable contains any additional values needed by the OPTION
variable to process the call.\n
1) When the OPTION value is NAME, this RPC will do a file lookup.\n
The DATA value is a three part value separated by carets(^). The first
part is a file number. The second part is a value to look up. The third
part is the field or fields to do the look up on. If the third piece is
not defined, the lookup is done on the .01 field of the file.\n
The TMP global contains:
^TMP("GMVHLOC",$J,0)=piece1
^TMP("GMVHLOC",$J,n)=piece2^piece3\n
where piece1 = number of entries found
piece2 = file number, a semi-colon and record IEN
piece3 = field value\n
Example:
>S OPTION="NAME",DATA="44^OUTPATIENT^.01"
>D RPC^GMVRPCHL(.RESULT,OPTION,DATA) ZW RESULT
>RESULT="^TMP("GMVHLOC",539052767)"
>D ^%G
>Global ^TMP("GMVHLOC",$J
>^TMP("GMVHLOC",539052767,0)=3
1)=44;75^OUTPATIENT NUC MED
2)=44;74^OUTPATIENT RADIOLOGY
3)=44;80^OUTPATIENT ULTRASOUND\n\n
2) When the OPTION value is APPT, this RPC will return a list of clinic
appointments for the patient.\n
The DATA value is a four part value separated by carets(^). The first
piece is DFN. The second piece is the start date of the search. If
not defined, this value defaults to 365 days prior to today. The third
piece is the end date of the search. If not defined, the value defaults
to today. Both dates are in FileMan internal format. The fourth piece is
a string of numbers to indicate what types of appointments to return. If
not defined, the value defaults to "123456789" (i.e., all appointment
types) where:\n
1 - Active/Kept
2 - Inpatient appts. only
3 - No-shows
4 - No-shows, auto-rebook
5 - Cancelled by clinic
6 - Cancelled by clinic, auto rebook
7 - Cancelled by patient
8 - Cancelled by patient, auto rebook
9 - No action taken\n
The TMP global contains:
^TMP("GMVHLOC",$J,0)=piece1
^TMP("GMVHLOC",$J,n)=piece2^piece3^piece4^piece5^piece6^piece7
^piece8^piece9^\n
where piece1 = number of entries found
piece2 = date/time of appt (FM internal)
piece3 = date/time of appt (external)
piece4 = hospital location IEN (FILE 44)
piece5 = hospital location name (FILE 44, Field .01)
piece6 = appt status (internal)
piece7 = appt status (external)
piece8 = appt type (internal)
piece9 = appt type (external)\n
Example:
> S OPTION="APPT",DATA="78^3051201^3051206^"
> D RPC^GMVRPCHL(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVHLOC",539052767)"
> D ^%G
> Global ^TMP("GMVHLOC",$J
> ^TMP("GMVHLOC",539052767,0)=1
1)=3051206.1^DEC 6,2005@10:00^88^WEIGHT
CLINIC^^^9^REGULAR\n
3) When the OPTION value is ADMIT, this RPC will return a list of
hospital admissions for the patient specified.\n
The DATA value is the patient's DFN.\n
The TMP global contains:
^TMP("GMVHLOC",$J,0)=piece1
^TMP("GMVHLOC",$J,n)=piece2^piece3^piece4^piece5^piece6\n
where piece1 = number of entries found
piece2 = date/time of admission (external)
piece3 = hospital location IEN (FILE 44)
piece4 = hospital location name (FILE 44, Field .01)
piece5 = type of movement (FILE 405.1, Field .01)
piece6 = movement IEN (FILE 405)\n
Example:
> S OPTION="ADMIT",DATA=134
> D RPC^GMVRPCHL(.RESULT,OPTION,DATA) ZW RESULT
> RESULT="^TMP("GMVHLOC",539052767)"
> D ^%G
> Global ^TMP("GMVHLOC",$J
> ^TMP("GMVHLOC",539052767,0)=1
1)=Apr 09, 2001 1:48:43 pm^67^
2-ASM^DIRECT^1712\n\n
If an error is encountered for NAME, ADMIT or APPT, a "-1" followed by a
caret and the error message text (i.e., -1^error message) is returned in
RESULT(0).", "GMV LOCATION SELECT", "", ""], ["4462", "SHAD STATUS INDICATOR", "Routine", "REGISTRATION", "2005/12/13", "APPROVED", "Active", "Supported", "", "
This supported DBIA covers an API that will return a
value that indicates whether the patient has Project 112/SHAD exposure.", "", "DGUTL3", ""], ["4463", "CHECK TO SEE IF A MH TEST IS COMPLETE", "Routine", "MENTAL HEALTH", "2005/12/20", "APPROVED", "Active", "Controlled Subscription", "", "
CPRS, needs a way to determine if a Mental Health test
is complete, when the test contains skip questions.\n", "", "YTQPXRM4", ""], ["4464", "POT MPIFDUP", "Routine", "MASTER PATIENT INDEX VISTA", "2005/12/20", "APPROVED", "Active", "Private", "", "
This entry point is used by the MPI/PD EXCEPTION
HANDLING option when the POTENTIAL MATCH REVIEW action is utilized.", "", "MPIFDUP", ""], ["4465", "VBECS data conversion from LR name spaced data globals", "File", "LAB SERVICE", "2004/07/21", "", "Withdrawn", "Private", "", "
VBECS would like permission to obtain data from LR data
files for the purpose of converting that data to the new VBECS (Blood Bank)
application.", "", "", ""], ["4466", "INIT RGADTP", "Routine", "CLINICAL INFO RESOURCE NETWORK", "2004/07/22", "APPROVED", "Active", "Private", "", "
The protocol MPIF ADT-A31 CLIENT is utilizing
PROCESSING ROUTINE - INIT^RGADTP to process the inbound A31 message.", "", "RGADTP", ""], ["4467", "XUSCNT", "Routine", "KERNEL", "2004/07/26", "APPROVED", "Active", "Controlled Subscription", "", "
The routine XUSCNT is just for GT.M system to keep
track of the number of active jobs. It is called from ZU for normal users.
ZTMS calls it for taskman jobs. Broker calls it as will other applications
that get started outside of Kernel. Mailman HL7", "", "XUSCNT", ""], ["4468", "VBECS set field level write access file 62.55", "File", "1", "2004/07/23", "APPROVED", "Active", "Private", "", "
The VistA Blood Establishment Computer Software (VBECS)
data conversion application would like to change the write access for specific
fields in the AGGLUTINATION STRENGTH FILE (62.55). The fields in question are:
.01 - NAME & 1 - WILL STAND FOR.\n
The method to accomplish this task will be to set the write access node for
the targeted field to the caret.\n
Example:
--------
S ^DD(62.55,.01,9)="^" S ^DD(62.55,1,9)="^"\n
After the VBECS data conversion is run, these fields should not be edited or
deleted through the use of VistA Blood Bank application. The hard set of the
write access node ('9') will accomplish this goal.", "", "", ""], ["4469", "VBECS set field level write access for file 63", "File", "1", "2004/07/23", "", "Withdrawn", "Private", "", "
The VistA Blood Establishment Computer Software (VBECS)
data conversion application would like to change the write access for specific
fields in the LAB DATA file (63).\n
The following sub-files and fields will be targeted:
----------------------------------------------------
BLOOD BANK (Multiple-63.01), [BB;0]
.01 DATE/TIME SPECIMEN TAKEN (RDX), [0;1]
.03 DATE REPORT COMPLETED (RD), [0;3]
.04 ENTERING PERSON (P200'), [0;4]
.05 SPECIMEN (P61'), [0;5]
.055 COLLECTION SAMPLE (RP62'), [0;11]
.06 ACCESSION NUMBER (F), [0;6]
.07 PHYSICIAN (*P200'X), [0;7]
.08 WARD (F), [0;8]
.09 PHLEBOTOMIST (P200'), [0;9]
.1 DATE/TIME RECEIVED (RDX), [0;10]
.12 ACCESSION LINK (FI), [0;12]
.99 SPECIMEN COMMENT (Multiple-63.199), [99;0]
.01 SPECIMEN COMMENT (MF), [0;1]
2.1 DIRECT AHG(POLYSPECIFIC) (FX), [2;1]
2.2 DIRECT AHG(5 min incub) (FX), [2;2]
2.3 DIRECT AHG CC (FX), [2;3]
2.4 ANTI-IgG (FX), [2;4]
2.5 ANTI-IgG CC (FX), [2;5]
2.6 ANTI-COMPLEMENT (FX), [2;6]
2.7 ANTI-COMPLEMENT (5 min incub) (FX), [2;7]
2.8 ANTI-COMPLEMENT CC (FX), [2;8]
2.9 DIRECT AHG INTERPRETATION (S), [2;9]
2.91 DIRECT AHG TEST COMMENT (FX), [2;10]
3 ELUATE ANTIBODY (Multiple-63.012), [EA;0]
.01 ELUATE ANTIBODY (M*P61.3'X), [0;1]
4 SCREEN CELL METHOD (Multiple-63.014), [3;0]
.01 SCREEN CELL METHOD (MS), [0;1]
.02 TECHNIQUE (S), [0;2]
1 SCREEN CELL (Multiple-63.015), [1;0]
.01 SCREEN CELL (MSX), [0;1]
.02 SOURCE (P66'), [0;2]
.03 INTERPRETATION (S), [0;3]
.04 IS (FX), [0;4]
.05 37 C (FX), [0;5]
.06 AHG (FX), [0;6]
.07 CONTROL CELL (FX), [0;7]
.08 ROOM TEMP (FX), [0;8]
.09 12-18 C (FX), [0;9]
.1 4 C (FX), [0;10]
6 ANTIBODY SCREEN INTERPRETATION (S), [6;1]
6.1 RBC ANTIGEN PRESENT (Multiple-63.011), [1.1;0]
.01 RBC ANTIGEN PRESENT (M*P61.3'X), [0;1]
.02 COMMENT (F), [0;2]
6.2 RBC ANTIGEN ABSENT (Multiple-63.0112), [1.2;0]
.01 RBC ANTIGEN ABSENT (M*P61.3'X), [0;1]
.02 COMMENT (F), [0;2]
6.3 HLA ANTIGEN PRESENT (Multiple-63.013), [1.3;0]
.01 HLA ANTIGEN PRESENT (M*P61.3'X), [0;1]
.02 COMMENT (F), [0;2]
6.4 HLA ANTIGEN ABSENT (Multiple-63.0114), [1.4;0]
.01 HLA ANTIGEN ABSENT (M*P61.3'X), [0;1]
.02 COMMENT (F), [0;2]
7 SERUM ANTIBODY (Multiple-63.46), [5;0]
.01 SERUM ANTIBODY (M*P61.3'X), [0;1]
.02 ANTIBODY COMMENT (F), [0;2]
8 ANTIBODY SCREEN COMMENT (Multiple-63.48), [4;0]
.01 ANTIBODY SCREEN COMMENT (MFX), [0;1]
9 RBC TYPING METHOD (Multiple-63.018), [1;0]
.01 RBC TYPING METHOD (S), [0;1]
.02 TECHNIQUE (S), [0;2]
1 ANTISERUM (Multiple-63.019), [1;0]
.01 ANTISERUM (M*P66'), [0;1]
.02 LOT # (F), [0;2]
.03 INTERPRETATION (RS), [0;3]
.04 IS (FX), [0;4]
.05 37 C (FX), [0;5]
.06 AHG (FX), [0;6]
.07 CONTROL CELL (FX), [0;7]
.08 ROOM TEMP (FX), [0;8]
.09 12-18 C (FX), [0;9]
.1 4 C (FX), [0;10]
121 PT CELLS+ANTI D (sal) (FX), [12;1]
122 PT CELLS+RH CTRL (sal) (FX), [12;2]
123 PT CELLS(sal)+ANTI D(hp IS) (FX), [12;3]
124 PT CELLS(ser)+ANTI D(hp IS) (RFX), [12;4]
125 PT CELLS+ANTI D (hp 37) (FX), [12;5]
126 PT CELLS+ANTI D (hp AHG) (FX), [12;6]
127 PT CELLS+ANTI D SLIDE (hp) (S), [12;7]
128 PT CELLS(sal)+RH CTRL (hp IS) (FX), [12;8]
129 PT CELLS(ser)+RH CTRL(hp IS) (RFX), [12;9]
129.1PT CELLS+RH CTRL (hp 37) (FX), [12;10]
129.11PT CELLS+RH CTRL (hp AHG) (FX), [12;11]
129.12PT CELLS+RH CTRL SLIDE (hp) (S), [12;12]
131 INTERPRETATION OF RH TESTING (RS), [13;1]
132 RH TEST COMMENT (F), [13;2]", "", "", ""], ["4470", "DBIA4470", "Routine", "OUTPATIENT PHARMACY", "2005/12/29", "", "Withdrawn", "Private", "", "
This DBIA will provide NON-VA Medication information
from the NON-VA MEDS sub-file (#55.05) of the PHARMACY PATIENT File (#55) to
the subscribing package.", "", "PSOMHV2", ""], ["4471", "CREATE NEW CROSS REFERENCE", "Other", "PAID", "2006/01/10", "", "Expired", "Private", "450", "
Kernel patch XU*8*384 requests to create the new AXUSEC
Cross-reference for field SEPARATION IND(#80) of the file PAID EMPLOYEE(#450)
to send a bulletin message to the mail group XUSEC/PRC PAID SEPARATION when
the field SEPARATION IND(#80) is set 'Y' for an employee.\n\n\n
hard codes set for the cross-ref:\n
S ^DD(450,80,1,160001,0)="450^AXUSEC^MUMPS"
S ^DD(450,80,1,160001,1)="D:$T(^XUSECBUL)'="""" ^XUSECBUL"
S ^DD(450,80,1,160001,2)="Q"
S ^DD(450,80,1,160001,"%D",0)="^^3^3^3060110^"
S ^DD(450,80,1,160001,"%D",1,0)="This cross reference is used to
send a message when an employee's:"
S ^DD(450,80,1,160001,"%D",2,0)="File: PAID EMPLOYEE(#450)"
S ^DD(450,80,1,160001,"%D",3,0)="Field: SEPARATION IND(#80) is set
to 'Y '"
S ^DD(450,80,1,160001,"DT")=3060110
S ^DD(450,80,"DT")=3060110
Q\n
=========================================\n
CROSS-REFERENCE: 450^AXUSEC^MUMPS
1)= D:$T(^XUSECBUL)'="" ^XUSECBUL
2)= Q
This cross reference is used to send a
message when an employee's: File: PAID
EMPLOYEE(#450) Field: SEPARATION IND(#80)
is set to 'Y'", "", "", ""], ["4472", "CS DESTRUCTION FILE", "File", "CONTROLLED SUBSTANCES", "2006/01/11", "APPROVED", "Active", "Private", "58.86", "
This is an open agreement between Controlled Substances
and Drug Accountability. This agreement allows Drug Accountability access to
the CS Destruction (#58.86) file. Controlled Substances permits Drug
Accountability access to add/alter/delete data from this file.", "", "", ""], ["4473", "REMINDER TAXONOMIES", "File", "CLINICAL REMINDERS", "2006/01/17", "APPROVED", "Active", "Private", "811.2", "
This IA allows for a global read of the .01 and 1.6
fields of file 811.2.", "", "", ""], ["4474", "EXPANDED REMINDER TAXONOMIES", "File", "CLINICAL REMINDERS", "2006/01/17", "APPROVED", "Active", "Private", "811.3", "
This IA allows for a global read of the .01 fields of
the 80, 80.1, 81 subnodes of file 811.3.", "", "", ""], ["4475", "Code Set DD Fixes", "File", "1", "2006/01/25", "APPROVED", "Active", "Private", "", "
During the SQA of patch LEX*2.0*39, several anomalies
were discovered with the Lexicon, CPT and ICD data files stemming from the
Code Set Versioning and Code Text Descriptors projects. There were several
identical fields identified by the cross-references, and a field that points
to a non-existing file.\n
Rather than delete the DD and refresh it, potentially wiping out local mods,
the Lexicon team is requesting a one-time permission to write and delete
directly from the Data Dictionary.\n
The code is as follows:\n\n
1 File #757.28, Index "ACT" has duplicate Fields
Field .01 ACTIVATION EFFECTIVE DATE
Field 1 ACTIVATION STATUS\n
S ^DD(757.02,1,1,2,0)="757.02^ACT1^MUMPS"
S ^DD(757.28,.01,1,2,0)="757.02^ACT2^MUMPS"
S ^DD(757.28,1,1,1,0)="757.02^ACT3^MUMPS"
K ^DD(757.02,0,"IX","ACT",757.02,1)
K ^DD(757.02,0,"IX","ACT",757.28,.01)
K ^DD(757.02,0,"IX","ACT",757.28,1)
S ^DD(757.02,0,"IX","ACT1",757.02,1)=""
S ^DD(757.02,0,"IX","ACT2",757.28,.01)=""
S ^DD(757.02,0,"IX","ACT3",757.28,1)=""\n
2 File #757.02, Index "APCODE" has duplicate Fields
Field 1 EXPRESSION
Field 4 PREFERENCE FLAG\n
S ^DD(757.02,1,1,4,0)="757.02^APCODE1^MUMPS"
S ^DD(757.02,4,1,1,0)="757.02^APCODE2^MUMPS"
K ^DD(757.02,0,"IX","APCODE",757.02,1)
K ^DD(757.02,0,"IX","APCODE",757.02,4)
S ^DD(757.02,0,"IX","APCODE1",757.02,1)=""
S ^DD(757.02,0,"IX","APCODE2",757.02,4)=""\n
3 File #81.02, Index "ACT" has duplicate Fields
Field .01 EFFECTIVE DATE
Field .02 STATUS\n
S ^DD(81,.01,1,5,0)="81^ACT1^MUMPS"
S ^DD(81.02,.01,1,2,0)="81^ACT2^MUMPS"
S ^DD(81.02,.02,1,1,0)="81^ACT3^MUMPS"
K ^DD(81,0,"IX","ACT",81,.01)
K ^DD(81,0,"IX","ACT",81.02,.01)
K ^DD(81,0,"IX","ACT",81.02,.02)
S ^DD(81,0,"IX","ACT1",81,.01)=""
S ^DD(81,0,"IX","ACT2",81.02,.01)=""
S ^DD(81,0,"IX","ACT3",81.02,.02)=""\n
4 File #81.33, Index "ACT" has duplicate Fields
Field .01 EFFECTIVE DATE
Field .02 STATUS\n
S ^DD(81.3,.01,1,3,0)="81.3^ACT1^MUMPS"
S ^DD(81.33,.01,1,2,0)="81.3^ACT2^MUMPS"
S ^DD(81.33,.02,1,1,0)="81.3^ACT3^MUMPS"
K ^DD(81.3,0,"IX","ACT",81.3,.01)
K ^DD(81.3,0,"IX","ACT",81.33,.01)
K ^DD(81.3,0,"IX","ACT",81.33,.02)
S ^DD(81.3,0,"IX","ACT1",81.3,.01)=""
S ^DD(81.3,0,"IX","ACT2",81.33,.01)=""
S ^DD(81.3,0,"IX","ACT3",81.33,.02)=""\n
5 File #80.066, Index "ACT" has duplicate Fields
Field .01 EFFECTIVE DATE
Field .02 STATUS\n
S ^DD(80,.01,1,4,0)="80^ACT1^MUMPS"
S ^DD(80.066,.01,1,2,0)="80^ACT2^MUMPS"
S ^DD(80.066,.02,1,1,0)="80^ACT3^MUMPS"
K ^DD(80,0,"IX","ACT",80,.01)
K ^DD(80,0,"IX","ACT",80.066,.01)
K ^DD(80,0,"IX","ACT",80.066,.02)
S ^DD(80,0,"IX","ACT1",80,.01)=""
S ^DD(80,0,"IX","ACT2",80.066,.01)=""
S ^DD(80,0,"IX","ACT3",80.066,.02)=""\n\n", "", "", ""], ["4476", "DBIA4476", "File", "TEXT INTEGRATION UTILITIES", "2006/01/25", "APPROVED", "Active", "Private", "8925.1", "
Provides FileMan read of .01, .02, and .07 fields in
8925.1 for CPRS", "", "", "2020/06/04"], ["4477", "DBIA4477", "File", "TEXT INTEGRATION UTILITIES", "2006/01/25", "APPROVED", "Active", "Private", "8925", "
Provides CPRS access to C xref of file 8925 until TIU
provides an API.", "", "", ""], ["4478", "DBIA4478", "File", "TEXT INTEGRATION UTILITIES", "2006/01/25", "APPROVED", "Active", "Private", "8925.1", "
Provides CPRS access to order through 8925.1, using the
4th piece as a screen.", "", "", ""], ["4479", "DBIA4479", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2006/01/26", "APPROVED", "Active", "Private", "", "
IA for PFSS to route a message from the DG package to
the EAS package.", "", "EASPFSS", ""], ["4480", "DBIA4480", "Routine", "PHARMACY DATA MANAGEMENT", "2006/02/06", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the PHARMACY PATIENT file (#55). This API is to used in the
future by all packages accessing this file as all the Pharmacy packages are
being re-engineered.", "", "PSS781", ""], ["4481", "HLFNC3", "Routine", "HEALTH LEVEL SEVEN", "2006/02/14", "APPROVED", "Active", "Private", "", "
BHS segments are not stored in the ^TMP("HLS",$J)
global when batch HL7 messages are generated. They are added by the VistA HL7
engine when the messages are sent. As the result, the application has no
access to the content of these segments.\n
This IA allows the subscribing package to generate the BHS segment in those
cases when access to the content of the segment is required (e.g. if the
segment should be written to a host file).", "", "HLFNC3", ""], ["4482", "READ OF FILE 44 'AST' AND 'ACST' CROSS-REFERENCES", "File", "SCHEDULING", "2004/07/28", "APPROVED", "Active", "Controlled Subscription", "44", "
Clinical Reminders request permission to do a global
read on file 44 "AST" and "ACST" cross-references. This gives permission to
access the CREDIT STOP CODE information in field 2503.", "", "", ""], ["4483", "DBIA4483", "Routine", "PHARMACY DATA MANAGEMENT", "2005/09/15", "", "Retired", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the DRUG file (#50). This API is to used in the future by all
packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSS50", ""], ["4484", "READ OF STATUS FIELD FOR NON-VA MEDS", "File", "PHARMACY DATA MANAGEMENT", "2004/08/26", "", "Retired", "Controlled Subscription", "55", "
This agreement will be retired on 12/31/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*101. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n\n
All fields and x-refs in file 55 have global read access by the subscribing
packages.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 31, 2006.\n
Clinical Reminders is requesting permission to do a FileMan read on the Non-VA
meds status field. This read is to allow the user to define what the Non-VA
meds status must for Clinical Reminders to consider the Non-VA meds finding
item as true.\n
Clinical Reminders will use the NVA^PSOPXRM1 API to retrieve the data related
to a Non-VA med. This API is documented in DBIA #3793.", "", "", ""], ["4485", "ICD DIAGNOSIS", "File", "DRG GROUPER", "2004/07/28", "APPROVED", "Active", "Private", "80", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4486", "ICD OPERATION/PROCEDURE", "File", "DRG GROUPER", "2004/07/28", "APPROVED", "Active", "Private", "80.1", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4487", "DRG", "File", "DRG GROUPER", "2004/07/28", "APPROVED", "Active", "Private", "80.2", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4488", "MAJOR DIAGNOSTIC CATEGORY", "File", "DRG GROUPER", "2004/07/28", "APPROVED", "Active", "Private", "80.3", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4489", "CPT", "File", "CPT/HCPCS CODES", "2004/07/28", "APPROVED", "Active", "Private", "81", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4490", "CPT CATEGORY", "File", "CPT/HCPCS CODES", "2004/07/28", "APPROVED", "Active", "Private", "81.1", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4491", "CPT COPYRIGHT", "File", "CPT/HCPCS CODES", "2004/07/28", "APPROVED", "Active", "Private", "81.2", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4492", "CPT MODIFIER", "File", "CPT/HCPCS CODES", "2004/07/28", "APPROVED", "Active", "Private", "81.3", "
Lexicon Utility has all privileges as though it were
the custodial package.", "", "", ""], ["4493", "HL7 ERROR MESSAGE FILE", "File", "HEALTH LEVEL SEVEN", "2006/02/14", "APPROVED", "Active", "Private", "771.7", "
The $$MSGSTAT^HLUTIL function returns only a code (IEN)
of the HL7 error in the 4th component. This IA allows the subscribing package
to get the corresponding error message.", "", "", ""], ["4494", "MODIFY 'B' XREF OF 757.01", "File", "1", "2007/04/03", "APPROVED", "Active", "Private", "757.01", "
The FM team grants the request of the Clinical Lexicon
package to modify the "B" index of file 757.01 as follows:\n
S ^LEX(757.01,"B",$E($$UP^XLFSTR(X),1,63),DA)="" K
^LEX(757.01,"B",$E($$UP^XLFSTR(X),1,63),DA)\n
It is further agreed that the following tools will not be used with this file:
DIFROM, COMPARE/MERGE and TRANSFER. These tools rely on an unmodified 'B'
index to function properly. Using the modified 'B' index of file 757.01 along
with any of the named tools may produce unexpected results.\n", "", "", "2007/04/03"], ["4495", "DBIA4141-D", "Routine", "REGISTRATION", "2004/08/04", "APPROVED", "Active", "Private", "", "
Supported call for building of HL7 ZMH segment (VA
Specific Military History Segment).\n", "", "VAFHLZMH", ""], ["4496", "DBIA4496", "File", "BAR CODE MED ADMIN", "2004/08/06", "", "Pending", "Private", "53.79", "
Inpatient Medications requests fileman read access to
the BCMA MEDICATION LOG file (#53.79) in BAR CODE MEDICATION ADMINISTRATION V.
3.0.\n
BCMA V. 3.0 records administration actions for medication orders that may also
be acted upon in INPATIENT MEDICATIONS V. 5.0. There is a need for the BCMA V.
3.0 last action to be seen by users in INPATIENT MEDICATIONS V. 5.0.", "", "", ""], ["4497", "DENTAL EDIT/DELETE OF OPTIONS", "File", "KERNEL", "2004/08/17", "APPROVED", "Active", "Controlled Subscription", "19", "
Dental Package would like an agreement with the owner
of the OPTION file (#19) to Fileman edit and delete of entries in these files,
due to the plan to retire the old Dental Activity System (DAS) in FY2005. As
such the first step of this phase out is to place many DENT* options by
placing thme OUT OF ORDER. There will be more than one dental patch to
accomplish this. Phase I involves disabling most of the old edit type options
but leaving some of the reporting options available. There may or may not be
a second patch to disable the remaining old Dental options. Definitely, when
DENT 2.0 is released, all of the old DAS options and functionality will be
removed. In DENT 2.0, we will include the Dental Options in the KIDS build
definition with a status of DELETE AT SITE.\n
Dental is planning on a patch that would queue up Taskman job to run late in
the evening on Oct 31, 2004. That tasked job will place options out of order.
The patch will do nothing except scheduled that Taskman job to run at the
designated time. This is why we cannot export the OPTIONs with the OUT OF
ORDER field set. The local VAMCs are allowed to run those options up until
Oct 31.\n
Dental is requesting: 1. Fileman read to do a lookup on file 19 given an
option name using either $$FIND1^DIC or FIND^DIC or LIST^DIC\n
2. Fileman write access to the OPTION file for fields:
2 OUT OF ORDER MESSAGE (F), [0;3]
209 SCHEDULING RECOMMENDED (S), [200.9;1]\n
S DENT(19,IENS,2) = some appropriate text
S DENT(19,IENS,209)="@"
D FILE^DIE", "", "", ""], ["4498", "4498", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2004/11/09", "APPROVED", "Active", "Controlled Subscription", "", "
This routine allows one use obtain information on
orders from the orders file. It also build the Clinical Reminders Index.", "", "ORPXRM", ""], ["4499", "4499", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2004/08/17", "APPROVED", "Active", "Controlled Subscription", "", "
Allow a package to call this routine to return the LTC
copay status of a patient without requiring a means test.", "", "EASECU", ""], ["4500", "DBIA4500", "Routine", "E CLAIMS MGMT ENGINE", "2005/11/09", "", "Retired", "Private", "", "
To allow pharmacy routines to log messages for ECME to
track performance statistics.", "", "BPSOSL", ""], ["4501", "READ OF THE WV PROCEDURE TYPE FILE", "File", "WOMEN'S HEALTH", "2004/08/23", "APPROVED", "Active", "Controlled Subscription", "790.2", "
Clinical Reminders is requesting permission to a direct
read on the WV PROCEDURE TYPE FILE File #790.2", "", "", ""], ["4502", "Find Surgical Case # for TIU", "File", "SURGERY", "2004/09/10", "APPROVED", "Active", "Private", "130", "
During the upload of TIU documents specific to the
SURGICAL REPORTS document class, TIU needs to associate the newly uploaded TIU
data to the correct TIU document stub created by the surgery package. Surgery
maintains the link between the surgical case # and the TIU document in the
^SRF(Case#,"TIU" global which TIU needs to read to ensure the correct linkage.\n", "", "", ""], ["4503", "4503", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2004/08/26", "APPROVED", "Active", "Controlled Subscription", "", "
Allow packages to get the LTC copay status without
requiring the patient to have had a Means test.", "", "EASECU", ""], ["4504", "4504", "File", "GEN. MED. REC. - VITALS", "2004/09/08", "APPROVED", "Active", "Controlled Subscription", "120.52", "
This IA will allow package to directly look at the .01
field in order to get the text of the Vital Qualifier. This also gives the
packages permission to reference all of the crossreference in the file in
order to find the entry that is being sought after.", "", "", ""], ["4505", "DSIV CALL TO IBCNBLA1", "Routine", "INTEGRATED BILLING", "2010/12/14", "", "Pending", "Private", "", "
The Insurance Capture Buffer (ICB) application uses the
ICB API in IBCNBLA1 to update the buffer symbol when retrieving or refreshing
buffer entries.", "", "IBCNBLA1", ""], ["4506", "IIV STATUS TABLE ACCESS", "File", "INTEGRATED BILLING", "2010/12/14", "APPROVED", "Active", "Private", "365.15", "
DSIV requests access to file 365.15 IIV STATUS TABLE to
display the entire eIV error message for the Insurance Capture Buffer (ICB)
application. This file is only read when there is an error condition.", "", "", "2023/01/12"], ["4507", "DBIA4507", "File", "1", "2004/09/24", "APPROVED", "Active", "Private", "1", "
This IA documents that the CP Conversion file (#703.9)
has a multiple field, MEDICINE FILE PARAMETERS (#703.91). The MEDICINE FILE
PARAMETERS field (#.01) points to the FILE file (#1). This multiple field is
used to store the pointer to the Medicine files so CP can store parameters for
each Medicine files used for the medicine report conversion. The CP
Conversion file (#703.9) will be added with patch MD*1*5. The files that will
be used belong to the CP namespace. CP will screen for CP namespace files and
populate this multiple. LAYGO will not be allowed. The following are files
that will be used: 691 ECHO
691.1 CARDIAC CATHETERIZATION
691.5 ELECTROCARDIOGRAM (EKG)
691.6 HOLTER
691.7 EXERCISE TOLERANCE TEST
691.8 ELECTROPHYSIOLOGY (EP)
694 HEMATOLOGY
694.5 CARDIAC SURGERY RISK ASSESSMENT 698
GENERATOR IMPLANT 698.1 V
LEAD IMPLANT 698.2 A LEAD
IMPLANT 698.3 PACEMAKER
SURVEILLANCE 699
ENDOSCOPY/CONSULT 699.5
GENERALIZED PROCEDURE/CONSULT 700
PULMONARY FUNCTION TESTS 701
RHEUMATOLOGY", "", "", ""], ["4508", "DBIA4508", "Routine", "TEXT INTEGRATION UTILITIES", "2005/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
Set Methods/Administrative Closure for TIU documents
(#8925).", "", "TIUSRVPT", "2007/01/25"], ["4509", "DBIA4509", "Routine", "REGISTRATION", "2004/09/23", "APPROVED", "Active", "Controlled Subscription", "", "
Insurance display.", "", "DGRPDB", ""], ["4510", "DBIA4510", "File", "LAB SERVICE", "2004/09/23", "APPROVED", "Active", "Private", "66", "
READ BLOOD PRODUCT.", "", "", ""], ["4511", "XUSERP", "Routine", "KERNEL", "2006/01/26", "APPROVED", "Active", "Private", "", "", "", "XUSERP", ""], ["4512", "VAFHAPV1", "Routine", "REGISTRATION", "2006/01/26", "", "Expired", "Private", "", "", "", "VAFHAPV1", ""], ["4513", "DBIA4513", "Routine", "MENTAL HEALTH", "2006/01/27", "APPROVED", "Active", "Controlled Subscription", "", "
This API is called to return data associated with the
administration of all a patient's Mental Health interviews, surveys and tests
(instruments). The input is an array that includes the patients DFN and a
completion indicator ("Y" for the completed administrations or "N" for the
non-completed administrations). Output is returned in an array that includes
the administration number, instrument name, date the instrument was given,
date the instrument was saved, who ordered the instrument, who administered
the instrument, was the administration signed, number of questions answered by
the patient, did the user have the specified key to view the instrument's
report, is the instrument legacy (contained in the MH INSTRUMENT file (#601)),
the instrument IEN from the MH TESTS AND SURVEYS file (#601.71), the
instrument IEN from the MH INSTRUMENT file (#601), is the instrument
copyrighted and the IEN of the HOPSITAL LOCATION file (#44).\n", "", "YTQAPI5", "2023/09/19"], ["4514", "DBIA4514", "Routine", "MENTAL HEALTH", "2006/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
This API is called to return the Mental Health scales,
raw scores and transformed scores associated with a specified entry from the
MH ADMINISTRATIONS file (#601.84) and the associated entry from the MH TESTS
AND SURVEYS file (#601.71) that was administered to the patient.\n", "", "YTQAPI8", ""], ["4515", "DBIA4515", "File", "BAR CODE MED ADMIN", "2006/02/13", "APPROVED", "Active", "Private", "53.79", "
CPRS read access to file 53.79.", "", "", ""], ["4516", "4516", "Routine", "PROBLEM LIST", "2004/11/09", "APPROVED", "Active", "Private", "", "
This entry point is called to build the Clinical
reminders Index for the PROBLEM file, #9000011. There are no required
variables.", "", "GMPLPXRM", ""], ["4517", "OR PARAM COORDINATOR MENU", "Other", "ORDER ENTRY/RESULTS REPORTING", "2006/02/06", "APPROVED", "Active", "Private", "", "
This DBIA is meant to allow Care Management to place a
new option under the menu option OR PARAM COORDINATOR MENU.\n", "", "", ""], ["4518", "DBIA4518", "Routine", "SCHEDULING", "2007/04/05", "APPROVED", "Active", "Private", "", "
This DBIA provides an interface to retrieve the PCE
CHECK OUT (Field #11) and the CONSULT LINK (Field #33) for a specific RSA
appointment, which is identified by its appointment ID, from the RSA
APPOINTMENT LIST File #44.44. This file is currently the authoritative source
for these appointment related fields for RSA appointments.", "", "SDAMUTIL", "2007/09/27"], ["4519", "4519", "Routine", "PCE PATIENT CARE ENCOUNTER", "2004/11/17", "APPROVED", "Active", "Private", "", "
Clinical Reminders calls these entry points to build
the Clinical Reminders Index for the V CPT file, #9000010.18, V HEALTH FACTORS
file, #9000010.23, V IMMUNIZATION file, #9000010.11, and the V IMM
CONTRA/REFUSAL EVENTS file, #9000010.707. There are no required variables.", "", "PXPXRMI1", "2016/09/19"], ["4520", "BUILD PCE CLINICAL REMINDERS INDEXES", "Routine", "PCE PATIENT CARE ENCOUNTER", "2004/11/20", "APPROVED", "Active", "Private", "", "
Clinical Reminders calls these entry points to build
the Clinical Reminders Indexes for the V PATIENT ED file, #9000010.16, V POV
file, #9000010.07, V SKIN TEST file, #9000010.12, V EXAM file, #9000010.13,
and the V STANDARD CODES file, #9000010.71. There are no required variables.\n", "", "PXPXRMI2", "2018/07/12"], ["4521", "4521", "Routine", "REGISTRATION", "2004/10/29", "APPROVED", "Active", "Private", "", "
This routine and entry point is used for building the
PXRMINDX( crossreference with data from the PTF file. There are no required
variables.", "", "DGPTDDCR", ""], ["4522", "4522", "Routine", "OUTPATIENT PHARMACY", "2004/11/02", "APPROVED", "Active", "Private", "", "
This routine and entry point is used for building the
Clinical Reminders Index for the PRESCRIPTION file, #52. There are no required
variables.", "", "PSOPXRMI", ""], ["4523", "4523", "Routine", "MENTAL HEALTH", "2004/11/12", "APPROVED", "Active", "Private", "", "
This routine and entry point is used for building the
Clinical Reminders Index for the PSYCH INSTRUMENT PATIENT file, #601.2. There
are no required variables.", "", "YTPXRM", ""], ["4524", "DBIA4524", "Routine", "INTEGRATED BILLING", "2004/10/14", "APPROVED", "Active", "Private", "", "
The REGAUTO^IBARXEU5 API updates the Billing Patient
file (#354) with a patient's copay status and exemption reason. Registration
queues this API as a background task from routine DGMTCOR.", "", "IBARXEU5", ""], ["4525", "WVLABCHK", "Routine", "WOMEN'S HEALTH", "2004/10/26", "APPROVED", "Active", "Private", "", "
The Women's Health (WH) package requests that the Lab
package will notify the WH package whenever SNOMED codes are changed for a
verified cytology or surgical pathology test.", "", "WVLABCHK", ""], ["4526", "MAG4 REMOTE IMPORT", "Remote Procedure", "IMAGING", "2004/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
MAG4 REMOTE IMPORT This RPC is used to QUEUE an image
for storage by the VistA Imaging Import API.", "MAG4 REMOTE IMPORT", "", ""], ["4527", "4527", "Routine", "CLINICAL REMINDERS", "2004/10/26", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA is established to permission to call the
routine PXRMOBJ to return information to be displayed in TIU OBJECTS.", "", "PXRMOBJ", ""], ["4528", "MAG IMPORT CHECK STATUS", "Remote Procedure", "IMAGING", "2004/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
MAG IMPORT CHECK STATUS This RPC is called to get a
status record from the IMPORT STATUS file (2006.037)", "MAG IMPORT CHECK STATUS", "", ""], ["4529", "IMAGING RPC", "Remote Procedure", "IMAGING", "2004/10/26", "APPROVED", "Active", "Controlled Subscription", "", "
MAG IMPORT CLEAR STATUS This RPC call will remove a
status record in the IMPORT STATUS file (2006.037).\n", "", "", ""], ["4530", "MAG IMPORT CLEAR STATUS", "Remote Procedure", "IMAGING", "2004/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
MAG IMPORT CLEAR STATUS This RPC will be used to clear
a status record from the IMPORT STATUS file (2006.037).", "MAG IMPORT CLEAR STATUS", "", ""], ["4531", "DBIA4531", "Routine", "NATIONAL DRUG FILE", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by NDF (National Drug File) as an
API to the DRUG INGREDIENTS file (#50.416). This API is to used in the future
by all packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSN50P41", ""], ["4532", "NPI UTILITIES", "Routine", "KERNEL", "2006/03/22", "APPROVED", "Active", "Controlled Subscription", "", "
An API to facilitate retrieval of the National Provider
Identifier (NPI) information and related utilities.", "", "XUSNPI", "2018/03/14"], ["4533", "DBIA4533", "Routine", "PHARMACY DATA MANAGEMENT", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the DRUG file (#50). This API is to used in the future by all
packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSS50", ""], ["4534", "ACCESS TO PTF CLOSE OUT (#45.84) FILE", "File", "REGISTRATION", "2006/02/13", "APPROVED", "Active", "Controlled Subscription", "45.84", "\n\n
Used to check and make sure the PTF record has not been closed out.\n
3/26/18-The references to file 45.83 in the Global Reference and Global Root
fields were changed to 45.84. Integrated Billing was the only subscribing
package referencing the PTF Release (#45.83) file and ICR #2819 provides IB
access to fields in the PTF Release file.", "", "", "2018/03/26"], ["4535", "VAFHLZRD", "Routine", "REGISTRATION", "2006/02/14", "APPROVED", "Active", "Private", "", "", "", "VAFHLZRD", ""], ["4536", "VAFHLZSP", "Routine", "REGISTRATION", "2006/02/14", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VAFHLZSP", "2010/06/19"], ["4537", "PSJ53P1", "Routine", "INPATIENT MEDICATIONS", "2006/09/21", "APPROVED", "Active", "Supported", "", "
This API shall be provided to return the ORDER NUMBER
field (#.01), PROVIDER field (#1), MED ROUTE field (#3), SCHEDULE TYPE field
(#7), START DATE/TIME field (#10), STOP DATE/TIME field (#25), SCHEDULE field
(#26), STATUS field (#28), ORDERABLE ITEM field (#108), DOSAGE ORDERED field
(#109) and all the Dispensed Drugs from the DISPENSED DRUG field (#2), for an
entry from the NON-VERIFIED ORDERS (#53.1) File.", "", "PSJ53P1", ""], ["4538", "AR ACCESS TO FILE 350.1", "File", "INTEGRATED BILLING", "2006/02/28", "APPROVED", "Active", "Private", "350.1", "
As part of the Vista IB/AR Data Extract to the ARC, AR
needs to access file 350.1 (IB ACTION TYPE). AR would like direct global
access to the following:\n
Direct global read access is requested for the following fields:\n
.01 NAME
.11 BILLING GROUP\n
Direct global read access for record lookup by name to the following cross
reference:\n
^IBE(350.1,"B"", "", "", "2010/03/03"], ["4539", "DBIA4539", "Routine", "KERNEL", "2006/02/28", "APPROVED", "Active", "Private", "", "
checks whether user is active and a proxy user", "", "XUSAP", ""], ["4540", "DBIA4540", "Routine", "NATIONAL DRUG FILE", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by NDF (National Drug File) as an
API to the VA GENERIC file (#50.6). This API is to used in the future by all
packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSN50P6", ""], ["4541", "AR access to INTEGRATED BILLING ACTION file 350", "File", "INTEGRATED BILLING", "2006/03/02", "APPROVED", "Active", "Private", "350", "
As part of the Vista IB/AR date extract to the ARC, AR
needs to access file 350 (INTEGRATED BILLING ACTION). AR would like direct
global access to the following:\n
Access to "ABIL" cross-reference (AR BILL NUMBER)\n
Access to "C" cross-reference (PATIENT)\n
Direct global access to ^IB(DO,0) to place data in the AR DATA QUEUE (348.4)\n
Fileman access to the .05 STATUS field of file 350", "", "", "2020/11/17"], ["4542", "DD Nodes in Patient (#2) file", "File", "1", "2006/04/13", "APPROVED", "Active", "Private", "2", "
DG*5.3*705, FIX PATIENT FILE DATA DICTIONARY, deletes
Fileman DD entries for fields on the PATIENT file (#2).\n
The pre-init routine, DG53705I, will be run only once and it will delete the
following nodes:\n
D BMES^XPDUTL(">>> Deleting bad write access, help, audit, other miscel
laneous nodes")
K ^DD(2,.12113,9),^DD(2,.14112,9)
K ^DD(2,.108,3)
K ^DD(2,.391,4)
F Z=.01,.2924,.3111,.3192,991.07 K ^DD(2,Z,"AUDIT")
K ^DD(2.312,.18,"AUDIT")
K ^DIC(2,0,"AUDIT")
K ^DD(2,0,"VR")
K ^DD(2,0,"VRPK")
K ^DIC(2,"%",7,0)
K ^DIC(2,"%","B","QAM",7)\n
D PT^DDUCHK1 (">>> Deleting bad pointer nodes") (this deletes any "PT"
reference node whose file and field either don't exist or don't point to file
2)\n
D BMES^XPDUTL(">>> Deleting bad identifier nodes")
F Z=.2924,.302,.351,"GARB","WARD","WR","ZREW" K ^DD(2,0,"ID",Z)\n
D BMES^XPDUTL(">>> Deleting bad field description nodes")
S Z=1 F S Z=$O(^DD(2,.107,21,Z)) Q:'Z K ^DD(2,.107,21,Z,0)\n
D BMES^XPDUTL(">>> Deleting bad cross reference nodes")
^DD(2,0,"IX","AHL",.01)
^DD(2,0,"IX",AHL2",.02)
^DD(2,0,"IX","AHL3",.03)
^DD(2,0,"IX","AHL5",.06)
^DD(2,0,"IX","AHL4",.09)
^DD(2,0,"IX","A4EC",.102)
^DD(2,0,"IX","ACP",.302)
^DD(2,0,"IX","AP",.302)
^DD(2,0,"IX","CHK4",.3025)
^DD(2,0,"IX","AEMP",.31115)
^DD(2,0,"IX","MAC",.31115)
^DD (2,0,"IX","AI",.32102)
^DD(2,0,"IX","AK",.32103)
^DD(2,0,"IX","AEXP",.351)
^DD(2,0,"IX","AHL6",.351)
^DD(2,0,"IX","AT",.351)
^DD(2,0,"IX","AR",.361)
^DD(2,0,"IX","BEN",.36205)
^DD(2,0,"IX","CHK1",.36205)
^DD(2,0,"IX","CHK2,".36215)
^DD(2,0,"IX","CHK3",.36235)
^DD(2,0,"IX","AT",.381)", "", "", ""], ["4543", "DBIA4543", "Routine", "NATIONAL DRUG FILE", "2004/12/27", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by NDF (National Drug File) as an
API to the VA DRUG CLASS file (#50.605). This API is to used in the future by
all packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSN50P65", "2019/05/22"], ["4544", "PSX550", "Routine", "CMOP", "2006/03/08", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by CMOP as an API to the CMOP
SYSTEM file (#550). The API returns the STATUS field (#1) for the System name
passed to the API.\n
This API is to used in the future by all packages accessing this file as all
the Pharmacy packages are being re-engineered.", "", "PSX550", ""], ["4545", "DBIA4545", "Routine", "NATIONAL DRUG FILE", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by NDF (National Drug File) as an
API to the VA PRODUCT file (#50.68). This API is to used in the future by all
packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSN50P68", "2025/03/28"], ["4546", "ADMINISTRATION SCHEDULE", "Routine", "PHARMACY DATA MANAGEMENT", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the ADMINISTRATION SCHEDULE file (#51.1). This API must be used
by all packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSS51P1", "2008/07/28"], ["4547", "BPSC(", "File", "E CLAIMS MGMT ENGINE", "2006/03/08", "APPROVED", "Active", "Private", "9002313.02", "
Integrated Billing needs read/write access to the
following fields of the BPS CLAIMS file (#9002313.02).\n
Field Name Loc Access\n
.07 AUTO REVERSE FLAG 0;7 Direct Read/Write\n
904 CLOSED REASON 900;4 Direct Read/Write\n", "", "", ""], ["4548", "MEDICATION ROUTES APIs", "Routine", "PHARMACY DATA MANAGEMENT", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the MEDICATION ROUTES file (#51.2). This API is to used in the
future by all packages accessing this file as all the Pharmacy packages are
being re-engineered.", "", "PSS51P2", ""], ["4549", "DBIA4549", "Routine", "PHARMACY DATA MANAGEMENT", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the IV ADDITIVES file (#52.6). This API is to used in the future
by all packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSS52P6", ""], ["4550", "DBIA4550", "Routine", "PHARMACY DATA MANAGEMENT", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the IV SOLUTIONS file (#52.7). This API is to use in the future
by all packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSS52P7", "2017/11/29"], ["4551", "DBIA4551", "Routine", "PHARMACY DATA MANAGEMENT", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to do simulated VA FileMan calls. This API is to be used in the
future by all packages needing to use FileMan to look at PDM files as all the
Pharmacy packages are being re-engineered.", "", "PSSDI", ""], ["4552", "DBIA4552", "Routine", "INTEGRATED BILLING", "2006/03/10", "APPROVED", "Active", "Private", "", "
Integrated Billing is releasing the new routine IBAKAT,
which contains an entry point that will be invoked by the patch PRCA*4.5*241
post initialization process. IBAKAT will identify all co-payment charges, for
veterans affected by Hurricane Katrina, for care provided from 8/29/05 through
2/28/06. This routine will in turn invoke various APIs within Accounts
Receivable to credit veterans' accounts.", "", "IBAKAT", ""], ["4553", "DBIA4553", "Routine", "ACCOUNTS RECEIVABLE", "2006/03/10", "APPROVED", "Active", "Private", "", "
Accounts Receivable will release the routine RCKATP
with patch PRCA*4.5*241. The patch post initialization process will queue a
task that invokes this routine to make adjustments to the financial accounts
of veterans affected by Hurricane Katrina. DBIA4552 has been developed to
allow this routine to invoke the Integrated Billing routine IBAKAT to identify
co-payment charges that should be cancelled. IBAKAT, in turn, will invoke
several APIs in routine RCKATP to adjust the veteran's account in Accounts
Receivable. This DBIA defines the APIs that IBAKAT may call back into to
credit the veteran's account.", "", "RCKATP", ""], ["4554", "DBIA4554", "Routine", "NATIONAL DRUG FILE", "2004/12/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by NDF (National Drug File) as an
API to do simulated VA FileMan calls. This API is to be used in the future by
all packages needing to use FileMan to look at NDF files as all the Pharmacy
packages are being re-engineered.", "", "PSNDI", ""], ["4555", "FIND STATUS OF PHARMACY ORDERS", "Routine", "PHARMACY DATA MANAGEMENT", "2006/03/15", "", "Other", "Private", "", "
The purpose of this call is to provide the status of
any Pharmacy order. The order could be Inpatient Medications, Outpatient
Pharmacy or Non-VA Medications. Additionally, the $$DOSE API will be used to
reformat dosages and units as described below.", "", "PSSORUTE", ""], ["4556", "DBIA4556", "Routine", "MENTAL HEALTH", "2006/03/17", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement provides the calling program, the WBC
and the ANC results needed for dispensing Clozapine medications.", "", "YSCLTST2", ""], ["4557", "DBIA4557", "File", "CONSULT/REQUEST TRACKING", "2006/03/22", "APPROVED", "Active", "Private", "123.5", "", "", "", ""], ["4558", "LIBRARY FUNCTIONS", "Routine", "KERNEL", "2004/11/03", "APPROVED", "Active", "Supported", "", "", "", "XLFDT3", ""], ["4559", "DBIA4141-C", "Routine", "REGISTRATION", "2004/11/09", "APPROVED", "Active", "Private", "", "
Supported call for building of HL7 ZCL repeated
segment: ZCL - VA - Specific Outpatient Classification Segment for all
existing Outpatient Classification Types.\n
HL7 ZCL repeated segment is built for all Outpatient Classification Types in
an order of Table SD008 - Outpatient Classification Type.\n
ZCL - VA-Specific Outpatient Classification Segment\n
SEQ LEN DT R/O TBL# VISTA ELEMENT NAME
------------------------------------------
1 4 SI R SET ID
2 2 ID R SD008 OUTPATIENT CLASSIFICATION TYPE
3 50 ST VALUE\n
SD008 - Outpatient Classification Type
----------------------------------------
Outpatient Classification Type Description
---------------------------------------------------------
1 AGENT ORANGE
2 IONIZING RADIATION
3 SERVICE CONNECTED
4 ENVIRONMENTAL CONTAMINANTS
5 MILITARY SEXUAL TRAUMA
6 HEAD AND/OR NECK CANCER
7 COMBAT VETERAN
8 PROJ 112/SHAD", "", "VAFHLZCL", "2018/08/08"], ["4560", "BPSNCPD3", "Routine", "E CLAIMS MGMT ENGINE", "2005/02/28", "APPROVED", "Active", "Private", "", "
This API is used by external applications to inquire
about DUR information for a prescription.", "", "BPSNCPD3", "2011/08/11"], ["4561", "4561", "File", "ORDER ENTRY/RESULTS REPORTING", "2004/11/20", "APPROVED", "Active", "Controlled Subscription", "100.21", "
This agreement allows the subscribers to maintain a
pointer to the OE/RR LIST file, #100.21, and to add and edit information in
the listed fields.\n\n\n", "", "", "2012/04/12"], ["4562", "Use of V cross-reference in 120.8", "File", "ADVERSE REACTION TRACKING", "2004/11/17", "APPROVED", "Active", "Private", "120.8", "
The pharmacy benefits management software needs the
ability to have direct global access to the V cross-reference of file 120.8.
The project needs to be able to quickly find all verified reactions over a
given time frame, which the V cross-reference will supply.", "", "", ""], ["4563", "DGPF DISPLAY PATIENT RECORD FLAG", "Routine", "REGISTRATION", "2004/11/20", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this API is to perform a lookup for
active patient record flag assignments for a given patient and format the
output data for roll-and-scroll display. The following Patient Record Flag
files are used: (#26.15) PRF NATIONAL FLAG (#26.11) PRF LOCAL FLAG (#26.13)
PRF ASSIGNMENT (#26.14) PRF ASSIGNMENT HISTORY (#26.16) PRF TYPE The primary
mechanism is from within the Registration package.", "", "DGPFAPI", ""], ["4564", "4564", "File", "HEALTH LEVEL SEVEN", "2005/01/08", "APPROVED", "Active", "Controlled Subscription", "772", "
This IA allows the subscribing package to search the
"C" crossreference of file HL7 MESSAGE TEXT, #772 and then get the status of
the message using VA FILEMAN.", "", "", ""], ["4565", "DBIA4565", "Routine", "SCHEDULING", "2007/04/05", "APPROVED", "Active", "Private", "", "
This DBIA provides an interface to delete the CONSULT
LINK (Field #33) in the RSA APPOINTMENT LIST File (#44.44) for a specific RSA
appointment, which is identified by its appointment ID.", "", "SDAMUTIL", "2007/09/27"], ["4566", "GMRV VITAL QUALIFIER", "File", "GEN. MED. REC. - VITALS", "2004/11/30", "APPROVED", "Active", "Private", "120.51", "
PBM needs to be able to access VITAL QUALIFIERS for
direct global reads.", "", "", ""], ["4567", "DIRECT GLOBAL READS OF IMMUNIZATIONS, TIMES & DATES", "File", "PCE PATIENT CARE ENCOUNTER", "2004/12/07", "APPROVED", "Active", "Private", "9000010.11", "
The pharmacy benefits management extracts needs to
perform direct global reads to extract the date, time and immunization from
this file.", "", "", ""], ["4568", "XLFNAME7", "Routine", "KERNEL", "2004/12/14", "APPROVED", "Active", "Private", "", "
Name standardization and name processing APIs.", "", "XLFNAME7", ""], ["4569", "DBIA4569", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2004/12/02", "APPROVED", "Active", "Controlled Subscription", "", "
IA to allow other applications to determine if a given
user holds the ORES security key. This will allow them to verify the user
will be able to electronically sign an order in the CPRS application.", "", "ORWDBA1", ""], ["4570", "CVALID XLFNAME8", "Routine", "KERNEL", "2004/12/16", "APPROVED", "Active", "Private", "", "
The API validates name components.", "", "XLFNAME8", ""], ["4571", "VDEF ERROR RECORDING", "Routine", "VISTA DATA EXTRACTION FRAMEWORK", "2004/12/16", "APPROVED", "Active", "Controlled Subscription", "", "
This IA describes the API used to record an error
encountered during message building being done as the result of a request
passed to the VDEF queue. Use this API only inside of a message building
routine that is invoked by VDEF. The string passed to the API will be filed
with the queued request that encounters the error in file 579.3.", "", "VDEFREQ", ""], ["4572", "E-SIG LOOKUP", "File", "KERNEL", "2005/01/03", "APPROVED", "Active", "Controlled Subscription", "200", "
This INTEGRATION AGREEMENT describes the ability to
read the hash of the user's electronic signature from file #200.", "", "", ""], ["4573", "READ AND WRITE OF TMP(XM-MESS", "Other", "KERNEL", "2004/12/07", "APPROVED", "Active", "Controlled Subscription", "", "", "", "", ""], ["4574", "XUPS APIs", "Routine", "KERNEL", "2006/04/18", "APPROVED", "Active", "Supported", "", "
Two APIs are contained in routine XUPS to identify the
VPID (VA Person ID) for a selected user or identify the DUZ for an entry in
the New Person (#200) file from a VPID.", "", "XUPS", "2007/05/26"], ["4575", "XUPSQRY API", "Routine", "KERNEL", "2006/04/18", "APPROVED", "Active", "Controlled Subscription", "", "
This API provides the functionality to query the New
Person (#200) file. The calling application may query the New Person (#200)
file by using either the VPID of the requested entry or part or all of a last
name. Other optional parameters may be passed to the call as additional
filters.", "", "XUPSQRY", ""], ["4576", "FIM REQUESTING USER CONSULT PERMISSIONS", "Routine", "CONSULT/REQUEST TRACKING", "2004/12/22", "APPROVED", "Active", "Supported", "", "", "", "GMRCAU", ""], ["4577", "DIC(0)", "Other", "1", "2004/12/14", "APPROVED", "Active", "Controlled Subscription", "", "
FileMan determines if it can "talk" to the user if the
variable DIC(0) contains the letter "E".", "", "", ""], ["4578", "DINDEX", "Other", "1", "2004/12/14", "APPROVED", "Active", "Controlled Subscription", "", "
When DIC is being used to search the indexes for user
matches, the local variable DINDEX reflects the current index that is being
searched.", "", "", ""], ["4579", "DD(200,0,'SCR')", "File", "1", "2004/12/15", "APPROVED", "Active", "Private", "200", "
This is a one time IA for patch XU*8*373 to set the
whole file screen code. The patch code is as follows:\n
XU8P373 ;SFISC/SO- Add Whole File Screen to file 200 ;5:50 AM 13 Dec
2004
;;8.0;KERNEL;**373**;Jul 10, 1995
; IA # 4579
; Test for file header node
I '$D(^VA(200,0))#2 D MES^XPDUTL("NEW PERSON(#200) file is mis
sing it's File Header node.") Q
; Test header node $P#2 for proper construction
I +$P(^VA(200,0),U,2)'=200 D MES^XPDUTL("The second piece of N
EW PERSON(#200) file is not correct.") Q
; Add the Whole File Screen
S ^DD(200,0,"SCR")="I $$SCR200^XUSER"
; Add Screen flag to file header if not already there
I $P(^VA(200,0),U,2)'["s" S $P(^VA(200,0),U,2)=$P(^VA(200,0),U
,2)_"s"
;
D MES^XPDUTL("Added Screen to NEW PERSON(#200) file.")
Q", "", "", ""], ["4580", "VALIDATE DOW SCHEDULES", "Routine", "INPATIENT MEDICATIONS", "2007/04/13", "APPROVED", "Active", "Private", "", "
The purpose of this agreement is to grant access to the
Inpatient Medications V. 5.0 day-of-week schedule validator.", "", "PSIVUTL", "2007/07/10"], ["4581", "MAS/X-RAY RECORDS REQUEST FILE", "File", "RECORD TRACKING", "2004/12/30", "APPROVED", "Active", "Controlled Subscription", "192.1", "
This file holds the patient records requested for the
scheduling appointment.\n
This file replaces the Record Tracking fields found in the PATIENT (#44.003)
sub-file of the HOSPITAL LOCATION (#44) file.", "", "", ""], ["4582", "TIUSRVT2 GETTMPLT RPC", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2005/01/06", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC is invoked from the CPRS Delphi template code.
That CPRS templating code is being encapsulated in v25 of CPRS. The
encapsulated code is made available to other applications. This RPC is
invoked from within that templating Delphi code.", "", "", ""], ["4583", "GMVHDR", "Routine", "GEN. MED. REC. - VITALS", "2005/02/16", "", "Retired", "Private", "", "
This Integration Agreement supports the VistA Data
Extraction Framework (VDEF) package.", "", "GMVHDR", ""], ["4584", "PXRHM used in TMP global", "File", "PCE PATIENT CARE ENCOUNTER", "2004/12/28", "APPROVED", "Active", "Controlled Subscription", "", "
The ^TMP("PXRHM",$J, global has been historically used
in PCE and is also used by other packages now for the same purpose.", "", "", ""], ["4585", "XM-MESS", "Other", "MAILMAN", "2004/12/29", "APPROVED", "Active", "Private", "", "
Because two jobs are being tasked off, the info in
^TMP("XM-MESS" is being saved so that after the first job is queued and ZTLOAD
cleans-up ^TMP("XM-MESS",$J), it can be recreated for the second task job.\n
Any output from both jobs ends up as separate messages. If the output from
the SORT is not needed the print job could be tasked first but not scheduled
and then the sort could be scheduled.", "", "", ""], ["4586", "READ OF REMINDER EXCHANGE FILE", "File", "CLINICAL REMINDERS", "2005/01/03", "APPROVED", "Active", "Private", "811.8", "
This IA will allow HS to do a FileMan read on the
Reminder Exchange file, #811.8.", "", "", ""], ["4587", "4587", "Routine", "CLINICAL REMINDERS", "2005/01/06", "APPROVED", "Active", "Controlled Subscription", "", "
This is an API call used to return Health Factor
Information in a TMP array about a patient for a given dated range.", "", "PXRMGECV", ""], ["4588", "Imaging's API for CP", "Routine", "IMAGING", "2005/01/11", "APPROVED", "Active", "Private", "", "
Imaging grants Clinical Procedures permission to call
routine MAGMC2CP.", "", "MAGMC2CP", ""], ["4589", "DBIA4589-A", "Other", "KERNEL", "2005/02/03", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Revenue Center (HRC) will be using a special
telnet feature in CAPRI-Remote to view patient data across all Vista Systems.
They need access to the menu options listed in this IA in order to review
various records for any given patient.", "", "", ""], ["4590", "DBIA4589-B", "Other", "ACCOUNTS RECEIVABLE", "2005/02/03", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Revenue Center (HRC) will be using a special
telnet feature in CAPRI-Remote to view patient data across all Vista Systems.
They need access to the menu options listed in this IA in order to review
various records for any given patient.", "", "", "2010/06/08"], ["4591", "DBIA4589-C", "Other", "PCE PATIENT CARE ENCOUNTER", "2005/02/04", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Revenue Center (HRC) will be using a special
telnet feature in CAPRI-Remote to view patient data across all Vista Systems.
They need access to the menu options listed in this IA in order to review
various records for any given patient.", "", "", ""], ["4592", "DBIA4589-D", "Other", "REGISTRATION", "2005/02/03", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Revenue Center (HRC) will be using a special
telnet feature in CAPRI-Remote to view patient data across all Vista Systems.
They need access to the menu options listed in this IA in order to review
various records for any given patient.", "", "", "2010/06/08"], ["4593", "DBIA4589-E", "Other", "ENROLLMENT APPLICATION SYSTEM", "2005/01/25", "", "Pending", "Controlled Subscription", "", "
The Health Revenue Center (HRC) will be using a special
telnet feature in CAPRI-Remote to view patient data across all Vista Systems.
They need access to the menu options listed in this IA in order to review
various records for any given patient.", "", "", ""], ["4594", "DBIA4589-F", "Other", "INTEGRATED BILLING", "2005/01/25", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Revenue Center (HRC) will be using a special
telnet feature in CAPRI-Remote to view patient data across all Vista Systems.
They need access to the menu options listed in this IA in order to review
various records for any given patient.", "", "", "2005/02/15"], ["4595", "DBIA4589-G", "Other", "OUTPATIENT PHARMACY", "2005/02/10", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Revenue Center (HRC) will be using a special
telnet feature in CAPRI-Remote. This allows a user to be automatically logged
into the local VistA system and provides access to the site's regular VistA
functionality. The HRC requires access to the menu options listed in this
Integration Agreement in order to access various records for a given patient.\n
HRC First Party Call Center contact representatives will use the HRC Pharmacy
Menu [DVBA HRC MENU PHARMACY] option to handle calls from veterans related to
the Consolidated Co-payment Processing Center (CCPC) billing statements. The
menu option will be available through the CAPRI application, which provides
local common service to VistA for HRC CAPRI remote users. Users of the HRC
Pharmacy Menu [DVBA HRC MENU PHARMACY] option will typically be licensed and
registered personnel (i.e. pharmacists and pharmacy technicians).\n
NOTES
======================================================================
* The Reset Copay Status/Cancel Charges [PSOCP RESET COPAY STATUS]
and Reset Copay Status List Manager [PSOCP RESET COPAY STATUS LM]
options may be used to change the patients Copay.\n
* Pharmacy Benefits Management endorses the addition of the Patient
Prescription Processing [PSO LM BACKDOOR ORDERS] to the HRC Pharmacy
Menu [DVBA HRC MENU PHARMACY] menu option, with the understanding
that HRC users will not use the option to alter existing Outpatient
Pharmacy records.", "", "", "2010/07/27"], ["4596", "Envoke ASKDUZ - Routine XUP", "Routine", "KERNEL", "2005/01/26", "APPROVED", "Active", "Private", "", "
Envoke ASKDUZ^XUP in routine DII if DUZ is undefined.", "", "XUP", ""], ["4597", "DBIA4597", "File", "REGISTRATION", "2005/02/04", "APPROVED", "Active", "Private", "42.6", "", "", "", ""], ["4598", "DBIA4598", "File", "REGISTRATION", "2005/02/07", "APPROVED", "Active", "Private", "42.7", "", "", "", ""], ["4599", "VENDOR FILE READ", "File", "IFCAP", "2005/02/07", "APPROVED", "Active", "Private", "440", "", "", "", ""], ["4600", "1010EZ/EZR PRINT", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2005/02/08", "APPROVED", "Active", "Private", "", "
Allow registration routines to call entry points to
print 1010EZ or 1010EZR.", "", "EASEZPDG", ""], ["4601", "PXXDPT - File 9000001", "Routine", "PCE PATIENT CARE ENCOUNTER", "2005/07/19", "", "Retired", "Private", "", "
My patch originated because user's were unable to
perform the check out process on certain encounters. We couldn't find the
source of the problem but we found out how to fix the encounters so that the
check out could be done. (The main problem was that you had Appt's pointing to
an encounter that did not have a pointer to a visit. Somehow the visit entry
did not get created along with the encounter as it should have.)\n
Now, during site testing we found some that still couldn't be checked out.
This was because of bad pointers in the IHS/Patient file (9000001).\n
After fixing this file, everything checked out properly. When we found that,
after looking into further we found that this patient file was also causing
the initial problem of the visit not being created when the encounter is
created. I then found some existing routine (PXXDPT) that builds/re-build
this patient file.\n
So, I've changed my fix utility (PXDELENC/PXDELFIX) to repair or build the
entries in the IHS/Patient file (9000001) also. And, here's where to
agreement comes into play. I want to put a check in the SD routine SDCO1 to
check this IHS/Patient file (9000001) file and if it needs repaired go ahead
and repair just before the check out process so that the check out would then
run with out issues.\n
May agreement will be between SD and PCE. My routine is PXDELFIX and there is
a FIXIHS line tag that does a couple calls to the PXXDPT routine.", "", "PXXDPT", ""], ["4602", "GET CURRENT INSURANCE", "Routine", "INTEGRATED BILLING", "2005/02/07", "APPROVED", "Active", "Private", "", "
As part of the IB/AR data extract, AR must pull the
current insurance IEN for a bill in order to determine the Payer. Routine
RCXVDC3 uses the IB function $$CURR^IBCEF2(RCXVD0), where RCXVD0 is the
internal number of the bill to get the internal number of the insurance file.
This is then used to extract the payer from the insurance file.", "", "IBCEF2", ""], ["4603", "FILE 361", "File", "INTEGRATED BILLING", "2005/02/07", "APPROVED", "Active", "Private", "361", "
As part of the AR/IB data extract, AR needs to
determine whether a claim has had any MRA rejection messages. These messages
are stored in file 361. Routine RCXVDC3 uses the "B" X-Ref of that file in
order to determine all messages for a particular bill. It then checks piece 3
of the '0' node to determine if the message had a 'rejected' status and adds
one to the count if it is rejected.", "", "", ""], ["4604", "FILE 365.12", "File", "INTEGRATED BILLING", "2005/02/07", "APPROVED", "Active", "Private", "365.12", "
As part of the AR/IB data extract, the PAYER NAME and
the VA NATIONAL ID needs to be extracted from file 365.12 for transmission to
the ARC. RCXVDC3 uses a direct global read to extract this information.", "", "", ""], ["4605", "GLOBAL READ OF DD(123", "File", "1", "2005/02/08", "APPROVED", "Active", "Private", "", "
GMRC*3*41 proposes to delete 3 MUMPS style
cross-references and replace them with a NEW-STYLE compound index. This
approach should increase the efficiency and reliability of the
cross-reference.\n
To insure the deletion of the proper cross-references "AE", "AE1" and "AE2",
Consult/Request Tracking will loop through:\n
^DD(123,1,1, ^DD(123,3,1, ^DD(123,8,1,\n
in order to locate the number of the cross reference to delete via
DELIX^DDMOD.", "", "", ""], ["4606", "REINDEX APC CROSS REFERENCE IN FILE 120.8", "Routine", "ADVERSE REACTION TRACKING", "2005/02/09", "APPROVED", "Active", "Private", "", "
During the course of data updates for the National Drug
file, the names some VA drug classes (entries in the VA DRUG CLASS file
(#50.605)) are changed. This causes the APC cross reference in file 120.8 to
be incorrect. To remedy this problem, we request permission to reindex this
cross reference as part of data updates. Specifically, we ask to insert the
following code at the end of the post-install routine\n
;
REINDEX ;Make sure APC xref is correct
Q:$T(EN2^GMRAUIX0)']""
N SUB,DA,DIK,GMRAIEN,CLASS
S SUB=0 F S SUB=$O(^GMR(120.8,SUB)) Q:'+SUB I $D(^GMR(120.8,SUB,3)) D
.S GMRAIEN=+$P($G(^GMR(120.8,SUB,0)),U) Q:'GMRAIEN
.S CLASS="" F S CLASS=$O(^GMR(120.8,"APC",GMRAIEN,CLASS)) Q:CLASS=""
K
^GMR(120.8,"APC",GMRAIEN,CLASS,SUB)
.S DA(1)=SUB
.S DIK="^GMR(120.8,DA(1),3,"
.S DIK(1)=".01^ADRG3"
.D ENALL^DIK ;Reset the drug class xref
Q", "", "", ""], ["4607", "VBECS ACCESSION AREA LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a list of VistA Lab Blood Bank accession areas to be associated with a
division in VBECS. The association is used by the Lab Workload reporting
process for VBECS.\n
RPC Details:", "VBECS ACCESSION AREA LOOKUP", "", ""], ["4608", "VBECS BLOOD BANK USER LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a list of VistA Blood Bank users to the gov.va.med.vbecs rehosted Blood Bank
application.\n
RPC Details:", "VBECS BLOOD BANK USER LOOKUP", "", ""], ["4609", "VBECS DIVISION LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a list of all VistA Divisions (Institutions) associated with a Medical Center.\n", "VBECS DIVISION LOOKUP", "", ""], ["4610", "VBECS HCPCS CODES LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a list of Healthcare Common Procedure Code System (HCPCS) codes from the VistA
CPT file (#81) with a CPT CATEGORY of PATHOLOGY AND LABORATORY SERVICES for
use in the rehosted VBECS software.", "VBECS HCPCS CODES LOOKUP", "", ""], ["4611", "VBECS LABORATORY TEST LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
the rehosted VBECS application with a Laboratory Test lookup from the VistA
Laboratory Test file (#60) for the purpose of associating Lab tests with
components in the VBECS database.", "VBECS LABORATORY TEST LOOKUP", "", ""], ["4612", "VBECS LAB TEST RESULTS LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a list of Laboratory test results for a specific patient during a specific
date range for the rehosted VBECS application.", "VBECS LAB TEST RESULTS LOOKUP", "", ""], ["4613", "VBECS MED PROFILE LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a list of all medications for a patient from the VistA Pharmacy package based
on a beginning and ending search date.", "VBECS MED PROFILE LOOKUP", "", ""], ["4614", "VBECS LAB ACCESSION UID LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VBECS with a lookup into the Accession file (#68) for the purpose of
identifying an existing Specimen UID and Accession number associated with a
Lab Order Number. This will facilitate the ability of VBECS to identify
existing VBECS orders by scanning a barcoded specimen UID, or entering the UID
manually, from a specimen received in the Blood Bank.", "VBECS LAB ACCESSION UID LOOKUP", "", ""], ["4615", "VBECS WORKLOAD CODES LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a list of workload codes from the WORKOAD CODE file (#64) for use in the
rehosted VBECS application.", "VBECS WORKLOAD CODES LOOKUP", "", ""], ["4616", "VBECS PATIENT LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
the rehosted VBECS application with a list of specific VistA patient data.", "VBECS PATIENT LOOKUP", "", ""], ["4617", "VBECS PROVIDER LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
the rehosted VBECS application with a list of physicians (providers) in VistA.\n", "VBECS PROVIDER LOOKUP", "", ""], ["4618", "VBECS HOSPITAL LOCATION LOOKUP", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
the rehosted VBECS application with a list of Hospital Locations for the
purpose of issuing units to specific locations.", "VBECS HOSPITAL LOCATION LOOKUP", "", ""], ["4619", "DBIA4619", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
patient specific and common order entry data to VistA for the purpose of
creating VBECS orders for blood products and diagnostic tests performed in the
Blood Bank.\n
XML Mapping:\n
XML Element.Attribute VBECS SQL Table.Column or Function
_____________________ __________________________________
Patient.dfn Patient.VistaPatientId
Patient.firstName Patient.PatientFirstName
Patient.lastName Patient.PatientLastName
Patient.abo fnGetAbo(Patient.PatientGuid)
Patient.rh fnGetRh(Patient.PatientGuid)
TransfusionReaction.type TransfusionReactionType.TransfusionReactionTypeText
TransfusionReaction.date
fnDateTimeConversionToHL7DateTime(PatientTransfusionReaction.NotedDateTim e
)
TransfusionRequirement.modifier
PatientTransfusionRequirement.TransfusionRequirementText
Antibody.name AntibodyType.AntibodyTypeName
Unit.status UnitStatus.UnitStatusCode OR
DonationType.RestrictionTypeCode
Unit.id BloodUnit.EyeReadableUnitId
Unit.product ProductType.ProductTypePrintName
Unit.location VamcDivision.DivisionName
Unit.expDate
fnDateTimeConversionToHL7DateTime(BloodUnitMedia.UnitExpirationDate)
Specimen.expDate
fnDateTimeConversionToHL7DateTime(PatientSpecimen.SpecimenExpirationDate)
Specimen.uid PatientSpecimen.SpecimenUid
Component.name ComponentClass.ComponentClassShortName
Component.id ComponentClass.CprsOrderableItemId
Component.specimen ComponentClassParameter.SpecimenRequiredIndicator
LabTest.id SpecimenTestThreshold.LabTestId
LabTest.name SpecimenTestThreshold.VistALaboratoryTestName
Msbos.name Msbos.SurgeryName
Msbos.threshold MsbosComponentClass.MaximumSetupUnitQuantity
Surgery.name Msbos.SurgeryName\n
Function Description:\n
fnGetAbo - This function returns the patient's current ABO Group.
fnGetRh - This function returns the patient's current Rh Type.
fnDateTimeConversionToHL7DateTime - This function converts a SQL DateTime
data type to HL7 format.\n\n
XML Example:
<?xml version="1.0" encoding="utf-8" ?>
<BloodBank>
<Patient dfn="5000" firstName="One" lastName="VBECSpatient"
ssn="000000000" abo=A"" rh="P">
<TransfusionReactions>
<TransfusionReaction type="Acute Hemolytic"
date="20010101120035-0600" />
</TransfusionReactions>
<TransfutionRequirements>
<TransfusionRequirement modifier="Washed RBC products">
<Antibodies>
<Antibody name="Anti-E" />
</Antibodies>
<Units>
<Unit status="C" id="04215" product="RBC" location="4E"
expDate="20010103115535-0600" />
</Units>
<Specimen expDate="20010115115535-0600" uid="1234567890" />
</Patient>
<Components>
<Component name="RED BLOOD CELLS" id="2" specimen="R">
<LabTests>
<LabTest id="320" name="HGB" />
</LabTests>
<MsbosList>
<Msbos name="Esophogectomy" threshold="5" />
</MsbosList>
</Component>
</Components>
<Surgeries>
<Surgery name="Esophogectomy" />
</Surgeries>
</BloodBank>", "", "", ""], ["4620", "DBIA4620", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VistA applications with a list of Blood Units associated with a patient.\n
XML Mapping:\n
XML Element.Attribute VBECS SQL Table.Column or Function
_____________________ __________________________________\n
Patient.dfn Patient.VistaPatientId
Patient.firstName Patient.PatientFirstName
Patient.lastName Patient.PatientLastName
Patient.dob
fnPatientDobConversionToFileManDateTime(Patient.PatientGuid)
Patient.ssn Patient.PatientSsn
Patient.abo fnGetAbo(Patient.PatientGuid)
Patient.rh fnGetRh(Patient.PatientGuid)
Unit.status DonationType.RestrictionTypeCode
Unit.id BloodUnit.EyeReadableUnitId
Unit.product ProductType.ProductTypeName
Unit.productCode BloodProduct.ProductCode
Unit.abo BloodUnitMedia.BloodTypeCode
Unit.rh BloodUnitMedia.RhFactorCode
Unit.volume BloodUnit.OriginalVolume
Unit.dateAssigned
fnDateTimeConversionToFileManDateTime(OrderedUnit.SelectedDate)
Unit.divisionCode VamcDivision.DivisionCode
Unit.location IssuedUnit.IssueToLocation
Unit.expDate
fnDateTimeConversionToFileManDateTime(BloodUnitMedia.UnitExpirationDate)\n
fnPatientDobConversionToFileManDateTime - This function returns the patient's
date of birth in FileMan format based on the patient unique identifier in the
VBECS database.
fnGetAbo - This function returns the patient's current ABO Group.
fnGetRh - This function returns the patient's current Rh Type.
fnDateTimeConversionToFileManDateTime - This function converts a SQL DateTime
data type to FileMan format.\n
XML Example:
<?xml version="1.0" encoding="utf-8" ?>
<BloodBank>
<Patient dfn="5000" firstName="One" lastName="VBECSpatient" dob="19500101"
ssn="000000000" abo="A" rh="P" />
<Units>
<Unit status="C" id="04215" product="RBC" productCode="E0335" abo="A"
rh="P" volumn="250" dateAssigned="20010430115535-0600" divisionCode="589"
location="4E" expDate="20010430115535-0600" />
</Units>
</BloodBank>", "", "", ""], ["4621", "DBIA4621", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VistA application with a list of Transfusions given to a patient.\n\n
XML Mapping:\n
XML Element.Attribute VBECS SQL Table.Column or Function
_____________________ __________________________________
Patient.dfn Patient.VistaPatientId
Patient.firstName Patient.PatientFirstName
Patient.lastName Patient.PatientLastName
Patient.dob
fnPatientDobConversionToFileManDateTime(Patient.PatientGuid)
Patient.ssn Patient.PatientSsn
Patient.abo fnGetAbo(Patient.PatientGuid)
Patient.rh fnGetRh(Patient.PatientGuid)
Transfusion.date
fnDateTimeConversionToFileManDateTime(PatientTransfusion.TransfusinoEndDat
eTime)
Transfusion.unitsPooled BloodUnit.PooledUnitsCount
Transfusion.productTypeName ProductType.ProductTypeName
Transfusion.productTypePrintName ProductType.ProductTypePrintName\n\n
Function Description:\n
fnPatientDobConversionToFileManDateTime - This function returns the patient's
date of birth in FileMan format based on the patient unique identifier in the
VBECS database.
fnGetAbo - This function returns the patient's current ABO Group.
fnGetRh - This function returns the patient's current Rh Type.
fnDateTimeConversionToFileManDateTime - This function converts a SQL DateTime
data type to FileMan format.\n\n
XML Example:\n
<Bloodbank>
<Patient dfn="5000" firstName="One" lastName="VBECSpatient"
dob="19500101" ssn="000000000" abo="A" rh="P">
<Transfusions>
<Transfusion date="20000101115535-0600" unitsPooled="3"
productTypeName="RED BLOOD CELLS" productTypePrintName="RBC" />
</Transfusions>
</Patient>
</Bloodbank>", "", "", ""], ["4622", "DBIA4622", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VistA applications with a list of Blood Products, or Component Classes, that
can be ordered for a patient.\n\n
XML Mapping:\n
XML Element.Attribute VBECS SQL Table.Column or Function
_____________________ __________________________________
ComponentClass.name ComponentClass.ComponentClassName
ComponentClass.shortName ComponentClass.ComponentClassShortName\n\n
XML Example:\n
<ComponentClasses>
<ComponentClass name="RED BLOOD CELLS" shortName="RBC" />
<ComponentClass name="FRESH FROZEN PLASMA" shortName ="FFP" />
<ComponentClass name="CRYOPRECIPITATE" shortName ="CRYO" />
<ComponentClass name="PLATELETS" shortName ="PLT" />
<ComponentClass name="OTHER" shortName ="OTHER" />
<ComponentClass name="WHOLE BLOOD" shortName ="WB" />
</ComponentClasses>", "", "", ""], ["4623", "DBIA4623", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VistA applications with a list of Blood Bank patient diagnostic testing
results, blood products requested, and blood units associated with a patient.\n\n
XML Mapping:
____________\n
XML Element.Attribute / VBECS SQL Table.Column or Function\n
Patient.dfn / Patient.VistaPatientId
Patient.firstName / Patient.PatientFirstName
Patient.lastName / Patient.PatientLastName
Patient.dob / fnPatientDobConversionToFileManDateTime(Patient.PatientGuid)
Patient.ssn / Patient.PatientSsn
Patient.abo / fnGetAbo(Patient.PatientGuid)
Patient.rh / fnGetRh(Patient.PatientGuid)
SpecimenTest.printTestName / BloodTestType.BloodTestName
SpecimenTest.orderableTestName / OrderableTest.OrderableTestName
SpecimenTest.result / TestResult.TestResultText
SpecimenTest.testDate /
fnDateTimeConversionToFileManeDateTime(SpecimenTest.TestDate)
SpecimenTest.cprsOrderId / PatientOrder.OrderGroupNumber
SpecimenTest.divisionCode / SpecimenTest.DivisionCode
SpecimenTest.enteringTechId / VbecsUser.UserDuz
SpecimenTest.requestorId / PatientOrder.OrderingProviderId
SpecimenTestComments / InformationMessage.InformationMessageText
ComponentRequest.dateRequested /
fnDateTimeConversionToFileManDateTime(PatientOrder.orderPlacedDatetime)
ComponentRequest.dateWanted /
fnDateTimeConversionToFileManDateTime(OrderedComponent.RequiredDatetime)
ComponentRequest.unitsRequested / OrderedComponent.RequiredUnitQuantity
ComponentRequest.cprsOrderId / PatientOrder.OrderGroupNumber
ComponentRequest.componentClassName / ComponentClass.ComponentClassName
ComponentRequest.componentClassShortName /
ComponentClass.ComponentClassShortName
ComponentRequest.requestorId / PatientOrder.OrderingProviderId
ComponentRequest.enteredById / PatientOrder.OrderEnteredById
Unit.status / UnitStatus.UnitStatusCode
Unit.id / BloodUnit.EyeReadableUnitId
Unit.product / ProductType.ProductTypePrintName
Unit.abo / BloodUnitMedia.BloodTypeCode
Unit.rh / BloodUnitMedia.RhFactorCode
Unit.divisionCode / BloodUnit.DivisionCode
Unit.location / IssuedUnit.LocationIen
Unit.expDate /
fnDateTimeConversionToFileManDateTime(BloodUnitMedia.UnitExpirationDate)\n\n
Function Description:
_____________________\n
fnPatientDobConversionToFileManDateTime - This function returns the patient's
date of birth in FileMan format based on the patient unique identifier in the
VBECS database.
fnGetAbo - This function returns the patient's current ABO Group.
fnGetRh - This function returns the patient's current Rh Type.
fnDateTimeConversionToFileManDateTime - This function converts a SQL DateTime
data type to FileMan format.\n\n
XML Example:
____________\n
<BloodBank>
<Patient dfn="5000" firstName="One" lastName="VBECSpatient"
dob="19500101" ssn="000000000" abo="A" rh="P">
<SpecimenTests>
<SpecimenTest printTestName="ABO Interp"
orderableTestName="ABO/Rh" result="A" testDate="20030101115535-0600"
cprsOrderId="12345" divisionCode="589" enteringTechId="5335"
requestorId="3553">
<SpecimenTestComments></SpecimenTestComments>
</SpecimenTest>
</SpecimenTests>
<ComponentRequests>
<ComponentRequest dateRequested="20030101115535-0600"
dateWanted="20030102" cprsOrderId="12346" componentClassName="RED BLOOD CELLS"
componentClassShortName="RBC" requestorId="3553" enteredById="3553"
/>
</ComponentRequests>
<Units>
<Unit status="C" id="04215" product="RBC" abo="A" rh="P"
divisionCode="589" location="4E" expDate="20030103115535-0600" />
</Units>
</Patient>
</BloodBank>", "", "", ""], ["4624", "DBIA4624", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VistA applications with a patient's current ABO Blood Group and Rh Type.\n\n
XML Mapping:\n
XML Element.Attribute VBECS SQL Table.Column or Function
_____________________ __________________________________
Patient.dfn Patient.VistaPatientId
Patient.firstName Patient.PatientFirstName
Patient.lastName Patient.PatientLastName
Patient.dob
fnPatientDobConversionToFileManDateTime(Patient.PatientGuid)
Patient.ssn Patient.PatientSsn
Patient.abo fnGetAbo(Patient.PatientGuid)
Patient.rh fnGetRh(Patient.PatientGuid)\n\n
Function Description:\n
fnPatientDobConversionToFileManDateTime - This function returns the patient's
date of birth in FileMan format based on the patient unique identifier in the
VBECS database.
fnGetAbo - This function returns the patient's current ABO Group.
fnGetRh - This function returns the patient's current Rh Type.\n\n
XML Example:\n
<BloodBank>
<Patient dfn="5000" firstName="One" lastName="VBECSpatient"
dob="19500101" ssn="000000000" abo="A" rh="P" />
</BloodBank>", "", "", ""], ["4625", "DBIA4625", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VistA applications with a list of antibodies identified for a patient.\n\n
XML Mapping:\n
XML Element.Attribute VBECS SQL Table.Column or Function
_____________________ __________________________________
Patient.dfn Patient.VistaPatientId
Patient.firstName Patient.PatientFirstName
Patient.lastName Patient.PatientLastName
Patient.ssn Patient.PatientSsn
Patient.abo fnGetAbo(Patient.PatientGuid)
Patient.rh fnGetRh(Patient.PatientGuid)
Antibody.name AntibodyType.AntibodyTypeName
Antibody.comment InformationMessage.InformationMessageText\n\n
Function Description:\n
fnGetAbo - This function returns the patient's current ABO Group.
fnGetRh - This function returns the patient's current Rh Type.\n\n
XML Example:\n
<BloodBank>
<Patient dfn="5000" firstName="One" lastName="VBECSpatient"
dob="19500101" ssn="000000000" abo="A" rh="P" >
<Antibodies>
<Antibody name="Anti-E" comment="Unexpected Antibody Detected:
Preparation of red cell components for transfusion may be delayed due to the
presence of serum red cell specific antibody(ies), which may require antigen
negative red cell components. Contact transfusion service for information on
potential clinical significance and availability of red cell components." />
</Antibodies>
</Patient>
</BloodBank>", "", "", ""], ["4626", "DBIA4626", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
VistA applications with a list of Transfusion Reactions associated with a
patient.\n\n
XML Mapping:
____________\n
XML Element.Attribute / VBECS SQL Table.Column or Function\n
Patient.dfn / Patient.VistaPatientId
Patient.firstName / Patient.PatientFirstName
Patient.lastName / Patient.PatientLastName
Patient.dob / fnPatientDobConversionToFileManDateTime(Patient.PatientGuid)
Patient.ssn / Patient.PatientSsn
Patient.abo / fnGetAbo(Patient.PatientGuid)
Patient.rh /fnGetRh(Patient.PatientGuid)
TransfusionReaction.type /
TransfusionReactionType.TransfusionReactionTypeText
TransfusionReaction.date /
fnDateTimeConversionToFileManDateTime(PatientTransfusionReaction.NotedDate
Time)
TransfusionReaction.unitId / BloodProduct.EyeReadableUnitId
TransfusionReaction.productTypeName / ProductType.ProductTypeName
TransfusionReaction.productTypePrintName / ProductType.ProductTypePrintName
TransfusionReaction.comment /
PatientTransfusionComment.PatientTransfusionCommentText\n\n
Function Description:
_____________________\n
fnGetAbo - This function returns the patient's current ABO Group.
fnGetRh - This function returns the patient's current Rh Type.
fnDateTimeConversionToFileManDateTime - This function converts a SQL DateTime
data type to FileMan format.\n\n
XML Example:
____________\n
<BloodBank>
<Patient dfn="5000" firstName="One" lastName="VBECSpatient"
dob="19500101" ssn="000000000" abo="A" rh="P" >
<TransfusionReactions>
<TransfusionReaction type="Acute Hemolytic"
date="20000101113555-0600" unitId="04215" productTypeName="RED BLOOD CELLS"
productTypePrintName="RBC" comment="The patient is also experiencing severe
headaches.">
</TransfusionReactions>
</Patient>
</BloodBank>", "", "", ""], ["4627", "DBIA4627", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
Blood Bank related workload data to VistA for workload reporting.\n\n
XML Mapping:\n
XML Element.Attribute VBECS SQL Table.Column or Function
_____________________ __________________________________
Transaction.id WorkloadEvent.WorkloadEventGuid
Transaction.type VbecsProcess.TransactionType
Transaction.division WorkloadEvent.DivisionCode
Transaction.accessionArea VamcDivision.AccessionAreaId
Transaction.dateTime
fnDateTimeConversionToFileManDateTime(WorkloadEvent.WorkloadEventDate)
Transaction.status WorkloadEvent.WorkloadEventStatusCode
Workload.code WorkloadProcess.WorkloadCode
Workload.multiplyFactor WorkloadEvent.WeightMultiplier
Patient.dfn Patient.VistaPatientId
VbecsUser.duz VbecsUser.UserDuz
Lab.accessionNumber OrderedTest.SpecimenWorkloadUid OR
OrderedComponent.SpecimenWorkloadUid
Lab.testPerformed OrderedTest.LabTestId OR
OrderedComponent.LabTestId
Unit.id BloodUnit.UnitProductCode\n
Note:
Transaction.type is a conditional code where the values can be
one of the following depending on the type of workload event being
returned.
U = Unit
P = Patient
M = Miscellaneous
The WorkloadEventStatusCode is always P for 'Pending Processing'.\n\n
Function Description:\n
fnDateTimeConversionToFileManDateTime - This function converts a SQL DateTime
data type to FileMan format.\n\n
XML Example:\n
<WorkloadTransactions>
<Transaction id="28711464-EFB3-453E-8B8A-025BA85CCD10" type="U"
division="589" accessionArea="29" dateTime="20030101113555-0600" status="P">
<Workload code="86832.0000" multiplyFactor="1" />
<VbecsUser duz="53555" />
<Lab accessionNumber="2930160023" testPerformed="6478" />
</Transaction> </WorkloadTransactions>", "", "", ""], ["4628", "DBIA4628", "Other", "769", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
a bi-directional data exchange between the rehosted gov.va.med.vbecs Blood
Bank software application and the VistA Laboratory VBECS application to update
workload event data in the rehosted SQL Server database as well as the VistA
VBECS WORKLOAD CAPTURE file (#6002.01). The VistA Laboratory VBECS application
will initiate the data exchange.\n\n
XML Mapping of input XML Message:
_________________________________\n
{XML Element.Attribute / VBECS SQL Table.Column or Function / Field in file
#6002.01}\n
WorkloadEvent.WorkloadEventGuid / WorkloadEvent.WorkloadEventGuid /
TRANSACTION ID (#.01)
WorkloadEvent.WorkloadEventStatusCode / WorkloadEvent.WorkloadEventStatusCode
/ STATUS (#5)
WorkloadEvent.ProcessedDate /
fnFileManDateTimeConversionToDateTime(WorkloadEvent.ProcessedDate) / PROCESSED
DATE (#4)
WorkloadEvent.ErrorText / WorkloadEvent.ErrorText / ERROR TEXT (#20)
WorkloadEvent.PceEncounterNumber / WorkloadEvent.PceEncounterNumber / PCE
ENCOUNTER (#99)\n
Function Description:
_____________________\n
fnFileManDateTimeConversionToDateTime - This function converts a FileMan
datetime type to a SQL datetime type.\n\n
Input XML Example:
__________________\n
This XML message is sent from the VistA Laboratory VBECS software when VBECS
workload data has been\n
updated by the Lab package.
<WorkloadEvents>
<WorkloadEvent>\n
<WorkloadEventGuid>28711464-EFB3-453E-8B8A-025BA85CCD10 </WorkloadEventGuid>
<WorkloadEventStatusCode>S</WorkloadEventStatusCode>
<ProcessedDate>3020101</ProcessedDate>
<ErrorText></ErrorText>
<PceEncounterNumber>55566666</PceEncounterNumber>
</WorkloadEvent>
</WorkloadEvents>\n\n\n
XML Mapping of Output XML Message:
__________________________________\n
{XML Element.Attribute / VBECS SQL Table.Column or Function / Field in file
#6002.01}\n
WorkloadEvent.id / WorkloadEvent.WorkloadEventGuid / TRANSACTION ID (#.01)
WorkloadEvent.successfullyUpdate /
WorkloadEvent.WorkloadEvent.WorkloadEventStatusCode / STATUS (#5)
WorkloadEvent.ErrorText / WorkloadEvent.ErrorText / ERROR TEXT (#20)\n\n
Output XML Example:
___________________\n
This XML message is returned from the rehosted gov.va.med.vbecs software to
update the VBECS WORKLOAD\n
CAPTURE file (#6002.01).\n
<WorkloadEvents>
<WorkloadEvent id="28711464-EFB3-453E-8B8A-025BA85CCD10"
successfullyUpdated="S" >
<ErrorText></ErrorText>
</ WorkloadEvent >
</WorkloadEvents>", "", "", ""], ["4629", "VBECS PATIENT AVAILABLE UNITS", "Routine", "VBECS", "2005/08/10", "APPROVED", "Active", "Private", "", "
The purpose of this integration agreement is to provide
the Surgery package access to units that are available for a patient. Surgery
will use the data returned from the AVUNIT^VBECA1B API to validate units for a
patient.", "", "VBECA1B", ""], ["4630", "Medicine Report Conversion", "Routine", "CONSULT/REQUEST TRACKING", "2005/02/28", "APPROVED", "Active", "Private", "", "
This integration agreement documents the private usage
of a Consult/Request Tracking entry point to allow the one-time replacement of
Medicine package results with TIU documents.", "", "GMRCCP", ""], ["4631", "VHA UNIQUE ID (VUID) API", "Routine", "TOOLKIT", "2005/05/06", "APPROVED", "Active", "Supported", "", "
API to handle the storage and retrieval of
VUID-assigned data for terms/concepts.\n
Please consult the VistA document library online to browse examples of its
use.", "", "XTID", "2009/06/17"], ["4632", "DBIA4632", "File", "KERNEL", "2005/03/31", "APPROVED", "Active", "Private", "8992.1", "
Registration utilizes the alert tracking file to
obtain/update information from existing alerts. Information updated will be
added to the DATA FOR PROCESSING (#2) Field.", "", "", ""], ["4633", "VBECS LAB ORDER LOOKUP BY UID", "Remote Procedure", "VBECS", "2005/05/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to provide
the rehosted VBECS application with a lookup into the ACCESSION file (#68) for
the purpose of identifying an existing Lab Order based on a specimen UID.", "VBECS LAB ORDER LOOKUP BY UID", "", ""], ["4634", "Data Dictionary global access", "File", "1", "2005/03/07", "APPROVED", "Active", "Private", "", "
to request the reading of the ^DD global to quickly
search for files that are "VUID-enhanced."\n
Users of the new VUID Kernel-Toolkin api have a subroutine to search for
terms/concepts when given the VUID # and some filter parameters.\n
When the "file" filter is not defined, the search must quickly look into every
VistA file to look for the term.", "", "", ""], ["4635", "ROUTINE IBRFN4", "Routine", "INTEGRATED BILLING", "2005/08/15", "APPROVED", "Active", "Private", "", "
Accounts Receivable is seeking an integration agreement
to call routine IBRFN4 to gather information from various integrated billing
files. This information is then used as data elements in the IB AR Data
Extract, which is sent via FTP to the ARC.", "", "IBRFN4", ""], ["4636", "VALIDATE UID API", "Routine", "LAB SERVICE", "2005/03/17", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Agreement is to allow
VBECS to use the Lab Services v5.2 API CHECKUID^LRWU4 for the purpose of
validating a Laboratory accession's UID (unique identifer) and identifying the
accession associated with it.", "", "LRWU4", ""], ["4637", "CHANGE VA CLASSIFICATION POINTERS", "File", "DIETETICS", "2005/03/22", "APPROVED", "Active", "Private", "119.9", "
The FH SITE PARAMETERS file (#119.9) has a multiiple
field that points to the VA DRUG CLASS file (#50.605). Some entries in file
50.605 have been renamed and moved to new IENs. To make sure that the
dietetics pointers are correct after this change, NDF requests permission to
do direct global reads and writes to entries in this multiple.", "", "", ""], ["4638", "DBIA4638-A", "Routine", "HEALTH DATA & INFORMATICS", "2005/04/05", "APPROVED", "Active", "Supported", "", "
The NTRTMSG^HDISVAP API is used to direct the user on
how to enter a new term using the New Term Rapid Turnaround Process (NTRT)
being provided by Enterprise Terminology Services (ETS).", "", "HDISVAP", ""], ["4639", "DBIA4638-B", "Routine", "HEALTH DATA & INFORMATICS", "2005/04/06", "APPROVED", "Active", "Supported", "", "
The EN^HDISVCMR API is used to invoke the VUID Seeding
Process for a specified HDIS Domain.\n
Packages may invoke this API without registering another IA only if the domain
and files being referenced are in the calling package's numberspace.", "", "HDISVCMR", ""], ["4640", "DBIA4638-C", "Routine", "HEALTH DATA & INFORMATICS", "2005/04/06", "APPROVED", "Active", "Supported", "", "
API(s) for retrieval and screening of the file/field
implementation status.", "", "HDISVF01", ""], ["4641", "DBIA4638-D", "File", "HEALTH DATA & INFORMATICS", "2005/04/06", "APPROVED", "Active", "Controlled Subscription", "", "
The Data Standardization (DS) Domain Action Team (DAT),
which includes the application developer, identifies which reference files
should be standardized for the Domain. Each entry in the file is then
assigned a VHA Unique Identifier (VUID) by the Enterprise Reference
Terminology (ERT) Group. DS then assists in the seeding of the VUIDs at the
Facilities. There are two approaches to the VUID Seeding. The first is
Facility by Facility and the second is Global Distribution. Additional
information about the approaches can be found in the VUID Implementation
Application Patch Requirements Document for the Domain being Standardized.
Each Domain is given a document which identifies the changes needed in Current
VistA for the DS effort. One of the requirements is to release a VistA patch
via the National Patch Module (NPM) which contains the changes identified in
the Patch Requirements Document.\n
For the Facility by Facility Approach the HDIS Domain file is used during the
VUID Seeding Process. It contains a list of the files being standardized for
the Domain. The VUID Seeding Process itself is invoked in the application
post-initialization routine by calling EN^HDISVCMR (IA #4639). As part of
this process DS will look through the entries for each of the files being
standardized for the Domain and extract the .01 field to be bundled into an
XML message.\n
The subscriber agrees to give DS permission to directly access the Global in
the routine FILE^HDISVCFX for the .01 field of the file being standardized.\n
GLOBAL REFERENCE:
^Global(file#,D0,0)=.01 field read only", "", "HDISVCFX", ""], ["4642", "RESET VA CLASS POINTERS", "File", "CLINICAL REMINDERS", "2005/03/25", "APPROVED", "Active", "Private", "810.3", "
Certain VA Classes have changed. NDF requests
permission to reset the pointers to the VA DRUG CLASS file (#50.605) in the
REMINDER EXTRACT SUMMARY file (#810.3).", "", "", ""], ["4643", "RESET VA DRUG CLASSES", "File", "CLINICAL REMINDERS", "2005/03/25", "APPROVED", "Active", "Private", "811.5", "
Some entries in the VA DRUG CLASS file (#50.605) have
changed. NDF requests premission to reset entries in the FINDING ITEM field
of the FINDINGS sub-file in the REMINDER TERM file (#811.5) as needed.", "", "", ""], ["4644", "RESET VA DRUG CLASS", "File", "CLINICAL REMINDERS", "2005/03/25", "APPROVED", "Active", "Private", "811.9", "
Certain VA drug classes have changed. NDF requests
permission to reset pointers in the FINDINGS sub-file of the REMINDER
DEFINITION file (#811.9) as needed.", "", "", ""], ["4645", "START/STOP XWBTCP LISTENER", "Routine", "RPC BROKER", "2005/03/24", "APPROVED", "Active", "Private", "", "
This is a IA for KIDS new auto patch utility to start
and stop the RPC Broker (XWBTCP) listener. In the code KIDS will make
reference to STOPALL^XWBTCP and RESTART^XWBTCP. Some patches require that the
Broker listener be stopped.", "", "XWBTCP", ""], ["4646", "DSIV CALL TO IBCNEUT3", "Routine", "INTEGRATED BILLING", "2010/12/14", "", "Pending", "Private", "", "
The Insurance Capture Buffer (ICB) application uses the
$$INSERROR API in IBCNEUT3 to retrieve a single line, user friendly eIV error
message. This call is only made when there is a buffer error condition.", "", "IBCNEUT3", ""], ["4647", "STOP/RESTART HL7", "Routine", "HEALTH LEVEL SEVEN", "2005/03/31", "APPROVED", "Active", "Private", "", "
This is a IA for KIDS new auto patch utility to start
and stop HL7 background processes. In the code KIDS will make reference to
CLEAR^HLCS2, LLP^HLCS2, STARTF^HLCS2, and STRT^HLCS2. Some patches require
that HL7 processes to be stopped.\n
Only patches that have installation instructions to stop and re-start the HL7
processes will be set up to automatically execute (non-interactively) the
equivalent of the current options\n
- Stop All Messaging Background Processes [HL STOP ALL] menu option. and -
Restart/Start All Links and Filers [HL TASK RESTART]' menu option.\n
The new functionality provided in patch HL*1.6*126 is not included in the
automation process.", "", "HLCS2", ""], ["4648", "VAFC LOCAL GETCORRESPONDINGIDS", "Remote Procedure", "REGISTRATION", "2010/12/15", "APPROVED", "Active", "Controlled Subscription", "", "\n
Given a patient DFN, ICN, or EDIPI, this API returns a list
of Treating Facilities, including SOURCE ID, station number,
and IDENTIFIER STATUS. This API will be called by North
Chicago via the VAFC LOCAL GETCORRESPONDINGIDS remote procedure.
TAG: TFL ROUTINE: VAFCTFU2\n
The patient identifier will either be the PATIENT file (#2)
IEN (aka DFN), Integration Control Number (aka ICN) or the
DOD Identifier (aka EDIPI). Following this format:\n
ID^IDTYPE^AssigningAuthority^AssigningFacility\n
Examples:
ICN example: 1008520438V882204^NI^USVHA^200M
DFN example: 100000511^PI^USVHA^500
EDIPI example: 852043888^NI^USDOD^200DOD\n
This will return a list of Treating Facilities in this format:\n
ID^IDTYPE^AssigningAuthority^AssigningFacility^IDStatus\n
Examples:
RETURN(1)="27^PI^USVHA^500^H"
RETURN(2)="7169806^PI^USVHA^500^A"
RETURN(3)="^PI^USVHA^200PS"
RETURN(4)="1^NI^USDOD^200DOD^A"
RETURN(5)="2^NI^USDOD^200DOD^H"", "VAFC LOCAL GETCORRESPONDINGIDS", "VAFCTFU2", "2011/01/14"], ["4649", "STOP/START MAILMAIL BY FILE", "File", "MAILMAN", "2005/03/24", "APPROVED", "Active", "Private", "4.3", "
This is a IA for KIDS new auto patch utility to start
and stop MailMan. In the code KIDS will make set the "BACKGROUND FILER RUN
FLAG" and the "TCP/IP POLLER RUN FLAG" to 1=stop running or 0=okay to run.
Some patches require that MailMan be stopped. This will work in conjunction
with IA #4650.", "", "", ""], ["4650", "START MAILMAN BY ROUTINES", "Routine", "MAILMAN", "2005/03/24", "APPROVED", "Active", "Private", "", "
This is a IA for KIDS new auto patch utility to start
and stop MailMan. In the code KIDS will make reference to START^XMKPL. Some
patches require that MailMan be stopped. This will work in conjunction with
IA #4649.", "", "XMKPL", ""], ["4651", "DBIA4638-E", "Routine", "HEALTH DATA & INFORMATICS", "2005/04/11", "APPROVED", "Active", "Supported", "", "
The $$GETIEN^HDISVF09 API is used to get the HDIS
Domain file IEN by the Domain.\n
The MFSUP^HDISVF09 API is used in the Master File Server Parameters to update
the status of the file to Complete and send out the HDR Activation bulletin.", "", "HDISVF09", ""], ["4652", "CLNCHK - SDUTL2 (RESTRICTING STOP CODE)", "Routine", "SCHEDULING", "2005/04/01", "APPROVED", "Active", "Supported", "", "
The purpose of API CLNCK^SDUTL2 is to determine whether
a Clinic entry in the HOSPITAL LOCATION File #44 has conforming stop codes.
Stop codes are stored in the CLINIC STOP File #40.7 and are used in accordance
to their assigned restriction types. Stops codes with restriction type 'P'
can only be used in the primary stop code position. Stop codes with
restriction type 'S' can only be used in the secondary stop code position.
Stop codes with restriction type 'E' can be used in either the primary or
secondary stop code position", "", "SDUTL2", ""], ["4653", "GMVUTL8", "Routine", "GEN. MED. REC. - VITALS", "2005/04/06", "APPROVED", "Active", "Private", "", "
This agreement supports the GMVUTL8 routine entry
points listed below.", "", "GMVUTL8", ""], ["4654", "GMV V/M ALLDATA", "Remote Procedure", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "\n
NAME: GMV V/M ALLDATA
TAG: VMDATA
ROUTINE: GMVGGR1
RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION
INACTIVE: ACTIVE
WORD WRAP ON: TRUE
DESCRIPTION:
This remote procedure call lists all vitals/measurements data for a given
date/time span.\n
This remote procedure call is documented in Integration Agreement 4654.
INPUT PARAMETER: GMVDATA
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 60
REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
GMVDATA consists of 4 pieces of data:\n
piece1^piece2^piece3^piece4\n
where piece1 = File 2 IEN (i.e., DFN)
piece2 = Start date/time for search (FileMan internal format)
piece3 = End date/time for search (FileMan internal format)
piece4 = 0 (zero)\n
RETURN PARAMETER DESCRIPTION:
RESULT array returns the data or a "NO DATA" message.\n
Case A: The NO DATA message is returned.\n
The TMP global returns:
^TMP($J,1)=lastname,first social security number date of birth age
"(Yrs)" gender
^TMP($J,2)="Unit:" unit "Room:" room
^TMP($J,3)="Division:" division
^TMP($J,4)= search date range
^TMP($J,5)="NO DATA"\n
Example:
> S GMVDATA="90^3051012^3051012^0"
> D VMDATA^GMVGGR1(.RESULT,GMVDATA) ZW RESULT
> RESULT="^TMP(539349605)"
> D ^%G
> Global ^TMP($J
> ^TMP(539349605,1)=VITPATIENT,ONE 000-11-1234 JAN 2,1934 71 (Yrs)
MALE
2)=Unit: Room:
3)=Division:
4)=OCT 11,2005 - OCT 11,2005
5)=NO DATA\n\n
Casee B: Fourth piece of GMVDATA (Flag) is 0\n
The TMP global returns:
^TMP($J,1)=lastname,first social security number date of birth age
"(Yrs)" sex
^TMP($J,2)="Unit:" unit "Room:" room
^TMP($J,3)="Division:" division
^TMP($J,4)= search date range
^TMP($J,n)=piece1 through piece23\n
where piece1 = date of reading in mm-dd-yy format
piece2 = time of reading in hh:mm:ss format
piece3 = Temperature value and qualifier abbreviations
piece4 = Pulse value and qualifier abbreviations
piece5 = Respiration and qualifier abbreviations
piece6 = Pulse Oximetry value, qualifier abbreviations, flow rate
and percentage value
piece7 = Blood Pressure value and qualifier abbreviations
piece8 = Weight value (pounds) and qualifier abbreviations
piece9 = Weight value (kilos)
piece10 = Body Mass Index calculation
piece11 = Height value (inches) and qualifier abbreviations
piece12 = Height value (centimeters)
piece13 = Circumference Girth value (inches) and qualifier
abbreviations
piece14 = Circumference Girth value (centimeters)
piece15 = Central Venous Pressure value (cmH2O)
piece16 = Central Venous Pressure value (mmHg)
piece17 = Input value (from Intake & Output package)
piece18 = Output value (from Intake & Output package)
piece19 = Pain value
piece20 = always null
piece21 = always null
piece22 = hospital location (FILE 44, Field .01)
piece23 = name of person who entered the data (FILE 200, Field
.01)\n
Example:
> S GMVDATA="134^3050901^3050930^0"
> D VMDATA^GMVGGR1(.RESULT,GMVDATA) ZW RESULT
> RESULT="^TMP(539349605)"
> D ^%G
> Global ^TMP($J
> ^TMP(539349605,1)=VITPATIENT,TWO 000-11-1234 JUN 1,1957 48 (Yrs)
FEMALE
2)=Unit: 2-ASM Room:
3)=Division: TEST HINES
4)=SEP 1,2005 - SEP 30,2005
5)=09-14-05^17:18:00^^^^^^135- A St^61.36^22^66-
A^167.64^^^^^^^^ ^^2-ASM^VITPROVIDER,ONE
6)=09-26-05^11:30:57^^^^^120/80*- La Si Car
Clf^^^^^^^^^^^^^^^2-A SM^VITPROVIDER,TWO", "GMV V/M ALLDATA", "", ""], ["4655", "PSB MOB DRUG LIST", "Remote Procedure", "BAR CODE MED ADMIN", "2005/05/02", "APPROVED", "Active", "Controlled Subscription", "", "
Used by the BCMA/CPRS Med Order Button to return an
array of drug.\n
Results[0] = the number of items passed in the array Results[1] = ^1 either
DD, SOL, ADD
^2 IEN from drug file 50
^3 Drug Name
^4 Pharmacy Orderable Item IEN
^5 Pharmacy Orderable Item Name
^6 CPRS Orderable Item IEN
^7 CPRS Orderable Item Name", "PSB MOB DRUG LIST", "", ""], ["4656", "PSB TRANSACTION", "Remote Procedure", "BAR CODE MED ADMIN", "2005/05/02", "APPROVED", "Active", "Controlled Subscription", "", "
This is the filing RPC for all data returning from the
client regarding the medication log. Filing is handled by business rules on
the server and this RPC will return either '1^Data Filed' or '-1^reason for
not filing data' to the client. Results of the processed transaction is
communicated via the RESULTS array. The number of RESULTS subscripts used (n)
will be presented in RESULTS[0]. RESULTS [1..n] will contain the RESULTS
message.\n
Business rules are conducted via the [0] node data. If a '+1^MEDPASS' is
encountered it is a complete new med pass and is validated as such.
Transaction type MEDPASS is the only type that requires a +1 in the first
piece of the header, all other transactions MUST supply a valid medication log
entry in the IENS.", "PSB TRANSACTION", "", ""], ["4657", "PSB MED LOG LOOKUP", "Remote Procedure", "BAR CODE MED ADMIN", "2005/05/02", "APPROVED", "Active", "Controlled Subscription", "", "
BCMA Medication Log Look Up Remote Procedures.\n
This routine is a conglomerate of Medication Log lookup functionality per the
BCMA Graphical User Interface software.\n
Input: PSBREC (array)
PSBREC (0) determine "lookup" function
"PTLKUP" (patient file (#2) lookup)
"ADMLKUP" (MedLog administration lookup)
"SELECTAD" (selected admin.)
(1) values to use per lookup. (DFN per ADMLKUP)
value of selected item. (PSB IEN per SELECTAD)
(2) search date per ADMLKUP\n
Output: RESULTS (array)
RESULTS(0) number of lookup matches
(1) error message or data per match/selection
(n) data per subsequent match/selection.\n
"PTLKUP" results data format: RPC Call: PSB MED LOG LOOKUP RESULTS(0) = 1
RESULTS(1) = piece 1 Patient's DFN ("-1" if
error/message) piece 2 Patient's Name piece 3 Sex piece 4
Date of Birth (FM format) piece 5 Social Security Number piece 6
"" piece 7 "" piece 8 "" piece 9 "" piece 10
Date Of Birth (displayable format) piece 11 Social Security Number
(displayable format)\n\n
"ADMLKUP" results data format: RESULTS(0)=Number of lines returned.\n
RESULTS(1)= piece 1 DFN of Patient piece 2 DATE of Activity
piece 3 Orderable Item_" "_Dosage Form piece 4 IV Unique ID
piece 5 Action Status piece 6 Schedule Type piece 7
Action Date/Time (FileMan) piece 8 Action By Initials piece 9
PRN Reason piece 10 PRN Effectiveness\n\n
"SELECTAD" results data format: RESULTS(0)=Number of lines returned.\n
RESULTS(1)= piece 1 PSBIEN of the administration selected for edit.
("-1" if error/m piece 2 DFN of Patient
piece 3 Patient Name piece 4 SSN piece 5 Medication
piece 6 BagID piece 7 AdminStat piece 8 "for possible
later use" piece 9 AdminD/T piece 10 InjctSt piece 11
"IV"/"PB"/"UD" piece 12 "for possible later use" piece 13 Order
Status piece 14 Schedul. Type piece 15 Order Number_U/V piece 16
Order has given patch or infusing IVbag - Flag\n
RESULTS(2)= piece 1 PRN Reason piece 2 PRN Effectiveness\n
RESULTS(3..n) [for each dd/add/sol] = piece 1 "DD"/"ADD"/"SOL" piece 2
drug IEN piece 3 drug Name piece 4 Units Ordered piece
5 Units Given piece 6 Units of Administration", "", "", ""], ["4658", "DBIA4658", "Routine", "LAB SERVICE", "2005/10/11", "APPROVED", "Active", "Controlled Subscription", "", "
Laboratory API to retrieve from LAB DATA file #63
laboratory test results associated with the "CH" subscript. In addition to the
actual test result, it also returns those values associated with the test
result such as normality, units, normals, performing laboratory and associated
order and result codes.", "", "LRRPU", ""], ["4659", "RDI DOMAIN CALL", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2006/05/30", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows packages to use the
Remote Data Interoperability (RDI) functionality.", "", "ORRDI1", "2014/06/03"], ["4660", "RDI DOMAIN GLOBAL", "File", "ORDER ENTRY/RESULTS REPORTING", "2005/04/11", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this DBIA is to provide subscribing
applications the ability to read the return data from API call GET^ORRDI1
(DBIA 4659.) This data is stored in the following temp global:\n
Pharmacy format:
^XTMP("ORRDI","PSOO",DFN,D0,1,0)=Facility Name
^XTMP("ORRDI","PSOO",DFN,D0,2,0)=DN
^XTMP("ORRDI","PSOO",DFN,D0,3,0)=Drug VUID
^XTMP("ORRDI","PSOO",DFN,D0,4,0)=RX
^XTMP("ORRDI","PSOO",DFN,D0,5,0)=ST
^XTMP("ORRDI","PSOO",DFN,D0,6,0)=QT;DS
^XTMP("ORRDI","PSOO",DFN,D0,7,0)=EX
^XTMP("ORRDI","PSOO",DFN,D0,8,0)=ID
^XTMP("ORRDI","PSOO",DFN,D0,9,0)=FD
^XTMP("ORRDI","PSOO",DFN,D0,10,0)=RF
^XTMP("ORRDI","PSOO",DFN,D0,11,0)=PR
^XTMP("ORRDI","PSOO",DFN,D0,12,0)=CF
^XTMP("ORRDI","PSOO",DFN,D0,14,D1)=SIG Allergies format:
^XTMP("ORRDI","ART",DFN,D0,"REACTANT",0)= Allergy Reactant
^XTMP("ORRDI","ART",DFN,D0,"DRUG CLASSES",1)=Drug Class 1
......
^XTMP("ORRDI","ART",DFN,D0,"DRUG CLASSES",n)=Drug Class n
^XTMP("ORRDI","ART",DFN,D0,"DRUG INGREDIENTS",0)=Drug Ing. 1
......
^XTMP("ORRDI","ART",DFN,D0,"DRUG INGREDIENTS",n)=Drug Ing. n\n\n\n", "", "", "2007/07/10"], ["4661", "API FOR PROCESSING PROSTHETIC IFC", "Routine", "PROSTHETICS", "2005/04/12", "APPROVED", "Active", "Private", "", "
The API called at EN^RMPRFC3 is used to process
Prosthetics Interfacility Consults' data and file the data into the
Prosthetics package's suspense system.\n", "", "RMPRFC3", "2009/06/12"], ["4662", "DBIA4662", "Routine", "PHARMACY DATA MANAGEMENT", "2005/04/26", "APPROVED", "Active", "Supported", "", "
This API will return information from the PHARMACY
ORDERABLE ITEM file (#50.7).", "", "PSS50P7", "2019/05/22"], ["4663", "PFSS ON/OFF SWITCH", "Routine", "INTEGRATED BILLING", "2005/05/23", "APPROVED", "Active", "Supported", "", "
The function $$SWSTAT^IBBAPI provides the calling
application with the status of the PFSS On/Off Switch. When the switch is
"ON", the calling application should proceed with processing required to
conform with PFSS functionality.", "", "IBBAPI", ""], ["4664", "PFSS ACCOUNT", "Routine", "INTEGRATED BILLING", "2005/05/23", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point is added to routine IBBAPI in order to
accommodate Patient Financial Services System (PFSS) functionality
requirements for establishing patient accounts in the commercial medical
billing system. This entry point is called by a number of VistA applications
involved in PFSS.", "", "IBBAPI", ""], ["4665", "PFSS CHARGE", "Routine", "INTEGRATED BILLING", "2005/05/23", "APPROVED", "Active", "Controlled Subscription", "", "
Two entry points are added to routine IBBAPI in order
to accommodate Patient Financial Services System (PFSS) functionality
requirements to provide charge data to the commercial medical billing system.
These entry points are called by several VistA applications involved in PFSS.", "", "IBBAPI", ""], ["4666", "DBIA4666", "Routine", "OUTPATIENT PHARMACY", "2005/05/05", "APPROVED", "Active", "Private", "", "
CPRS requests permission to use the EN^PSOHLNE3 API to
pass updated SC, EI, and ICD-9 Diagnosis information to Outpatient Pharmacy.
When a verbal or telephone order is place and it requires electronic
signature, the provider may update the SC, EI's, or ICD Diagnosis information.
This API updates this information in Prescription file (#52).", "", "PSOHLNE3", "2019/11/19"], ["4667", "Update to entries in file 120.8", "Routine", "ADVERSE REACTION TRACKING", "2005/05/10", "APPROVED", "Active", "Controlled Subscription", "", "
Automatically updates entries in the PATIENT ALLERGIES
file (120.8) when changes to the ingredients and/or drug classes of reactants
found in file 120.82 or in pharmacy related files are made. Changes to
ingredients and/or drug classes for those reactants will then be made to
existing entries in file 120.8 so that existing allergies have the updated
information.", "", "GMRAUTL2", ""], ["4668", "PFSS ACCOUNT NUMBER REFERENCE", "Routine", "SCHEDULING", "2006/09/20", "APPROVED", "Active", "Controlled Subscription", "", "
This API will return the PFSS Account Number Reference
stored in the Scheduling APPOINTMENT ACCOUNT NUMBER REFERENCE File (#409.55).
This reference number is provided by the IBB PFSS ACCOUNT API when a new
appointment is made.", "", "SDPFSS2", ""], ["4669", "HL7 MESSAGE ID ACCESS", "File", "HEALTH LEVEL SEVEN", "2005/05/16", "APPROVED", "Active", "Private", "773", "
This IA allows the subscribing package to search the
"B" index of the HL7 MESSAGE ADMINISTRATION (#773) file and get the message ID
of the message using VA FileMan.", "", "", ""], ["4670", "BLOOD BANK", "File", "VBECS", "2005/05/16", "APPROVED", "Active", "Private", "65", "
The DSS Extracts BLOOD BANK EXTRACT file (#727.829)
does direct reads to the 0 node to LAB DATA file (#63). File (#63) has a
multiple field (#1) 'UNITS SELECTED FOR XMATCH' which has field (#.01) 'UNIT
SELECTED FOR XMATCH'. This field is a pointer to the BLOOD INVENTORY file
(#65). DSS Extracts needs permission to execute direct global read to retrieve
'PHYSICIAN' field (#6.2) from BLOOD INVENTORY file (#65).", "", "", ""], ["4671", "DBIA4671", "File", "SCHEDULING", "2005/05/31", "APPROVED", "Active", "Controlled Subscription", "409.1", "
For Patient Financial Services System (PFSS), the IBB
module of INTEGRATED BILLING requires direct global read of the SYNONYM field
(#4) in the APPOINTMENT TYPE file (#409.1).", "", "", ""], ["4672", "DBIA4672", "File", "SCHEDULING", "2005/05/31", "APPROVED", "Active", "Controlled Subscription", "44", "
For Patient Financial Services System (PFSS), the IBB
module of INTEGRATED BILLING requires direct global read of the DIVISION field
(#3.5) in the HOSPITAL LOCATION file (#44).", "", "", ""], ["4673", "RETURN PFSS ACCOUNT REFERENCE", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2005/08/09", "APPROVED", "Active", "Controlled Subscription", "100", "
Via functionality and constraints subsumed within the
PFSS project, the PFSS Account Reference Number pointer is stored for
specified orders in the Order file (#100) as field 97. This IA covers the
return of a previously stored PFSS Account Reference Number pointer from the
Order file (#100).\n
The OE/RR API is accessed as D ORACTREF^ORWPFSS(.ORACTREF,ORIEN).", "", "ORWPFSS", ""], ["4674", "ACCESS TO AK.PROVIDER CROSS REFERENCE", "File", "KERNEL", "2005/06/02", "APPROVED", "Active", "Private", "200", "
This integration agreement allows access to the
AK.PROVIDER cross reference in the New Person file.", "", "", ""], ["4675", "DBIA4675", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2005/06/03", "APPROVED", "Active", "Private", "75.1", "
A private agreement with INTEGRATED BILLING to allow
direct global read of the CLINICAL HISTORY FOR EXAM field (#400) of the
RAD/NUC MED ORDERS file (#75.1) in the context of the Patient Financial
Services System (PFSS) project.", "", "", ""], ["4676", "DBIA4676", "File", "IFCAP", "2005/06/08", "APPROVED", "Active", "Controlled Subscription", "440", "
Allow FileMan read of the VENDOR file (#440), NAME
field (#.01).", "", "", ""], ["4677", "Application Proxy", "Routine", "KERNEL", "2005/06/08", "APPROVED", "Active", "Controlled Subscription", "", "
To support the J2EE middle tier the concept of a
APPLICATION PROXY user was created. This is a user name that an application
sets that has an user class of Application Proxy. It will not have Access or
Verify codes, no Primary Menu. It will have one or more Secondary Menu items.
The RPC's that the menu items point to must have the APP PROXY ALLOWED field
set to Yes.\n
APPLICATION PROXY names used by Class I software must be approved by the DBA.", "", "XUSAP", "2009/03/16"], ["4678", "VAFCTFU GET TREATING LIST", "Remote Procedure", "REGISTRATION", "2005/06/08", "APPROVED", "Active", "Supported", "", "", "VAFCTFU GET TREATING LIST", "", ""], ["4679", "VAFCTFU CONVERT ICN TO DFN", "Remote Procedure", "REGISTRATION", "2005/12/20", "APPROVED", "Active", "Supported", "", "", "VAFCTFU CONVERT ICN TO DFN", "", ""], ["4680", "VAFCTFU CONVERT DFN TO ICN", "Remote Procedure", "REGISTRATION", "2005/12/20", "APPROVED", "Active", "Supported", "", "", "VAFCTFU CONVERT DFN TO ICN", "", ""], ["4681", "Direct read of order check multiple", "File", "ORDER ENTRY/RESULTS REPORTING", "2005/06/09", "APPROVED", "Active", "Private", "100", "
Package may directly access the ^OR(100,DA,9 node to
determine what, if any, order checks currently exist for an order.", "", "", ""], ["4682", "Allergy CPRS GUI interaction", "Routine", "ADVERSE REACTION TRACKING", "2005/06/13", "APPROVED", "Active", "Private", "", "
A change was made so that allergies were no longer
handled as orders. As a result, direct interaction between CPRS GUI and the
Allergy package is required in order to save allergy information entered from
within CPRS GUI. This agreement gives access to existing APIs within the
allergy package so that CPRS GUI can send allergy data directly to the allergy
system.", "", "GMRAGUI1", ""], ["4683", "Retrieve allergy data", "Routine", "ADVERSE REACTION TRACKING", "2005/06/13", "APPROVED", "Active", "Private", "", "
Now that allergies are no longer orders CPRS GUI needs
to have direct access to the allergy package in order to display and save the
allergy data.", "", "GMRAGUI", ""], ["4684", "Obtain site parameter entry", "Routine", "ADVERSE REACTION TRACKING", "2005/06/13", "APPROVED", "Active", "Private", "", "
This call will determine which allergy parameter entry
is the correct one for the user.", "", "GMRAUTL", ""], ["4685", "PROTOCOL", "File", "KERNEL", "2005/06/20", "APPROVED", "Active", "Supported", "101", "
Direct access to the Protocol file (#101) to mark
protocols out of order and remove the out of order message.", "", "", ""], ["4686", "PATIENT SERVICE B-TYPE OPTIONS", "Remote Procedure", "REGISTRATION", "2005/09/09", "APPROVED", "Active", "Private", "", "
Person Services owns Broker Type Options in the DGRR
namespace. In order to make use of the services such as Patient Service Lookup
(PSL) and Patient Service Construct (PSC), the Broker Type Options must be
assigned to users of any application that uses the Person Services.\n
In order to make things easier for the sites, Person Service developers have
suggested that their DGRR broker type options be attached as items in the MENU
multiple of the broker type options belonging to the application that will use
the service. This will make the Person Service RPCs available to the
application, and will reduce work for IRM because they will not have to assign
the DGRR options to each user of the application, in addition to the
application's own options.\n
The Interation Agreement allows an application to attach the Person Service
Broker Type options as MENU items in the applications own Broker type option.", "", "", ""], ["4687", "DBIA4687", "Routine", "OUTPATIENT PHARMACY", "2005/06/22", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement provides the calling program, details of
all (active, verified, on hold, suspended, discontinued, pending and expired),
prescriptions within a given date for a patient.\n
It provides complete details of Rx(s) in a sorted order in a TMP global
depending on the entry point being called EN, EN2 or EN3.\n
The EN call sorts data by the Rx Status (TR) and the dispensed drug (TD).
The EN2 call returns data for a specified Rx or list of Rxs sorted by the
Rx Status (TR) and the dispensed drug (TD).
The EN3 call sorts data by the Rx Status (TR) and the Rx IEN# (TD).\n
Please see at the component level for more details.\n
For all Rx except PENDING orders, the following details are included in
the TMP global:\n
^TMP("PSO",$J,TR,TD,0)=DISPENSED DRUG^^RX EXPIRATION DATE^REFILLS
REMAINING^ISSUE DATE^RX STATUS^DAYS SUPPLY^QUANTITY^^^PLACER ORDER #^LAST
FILLED DATE^^\n
^TMP("PSO",$J,TR,TD,"RXN",0)=EXTERNAL Rx NUMBER^LAST RELEASE
DATE^ORIGINAL FILL ROUTING (W or M)^Remarks^FINISHED BY^ORIGINAL FILL
DATE^ORIGINAL RELEASE DATE^^RX IEN#
^TMP("PSO",$J,TR,TD,"DIV",0)=DIVISION^OP DIVISION DETAILS
^TMP("PSO",$J,TR,TD,"P",0)=PROVIDER IEN^PROVIDER NAME
^TMP("PSO",$J,TR,TD,"REF",0)=# of refill dispensed
^TMP("PSO",$J,TR,TD,"REF",REF IEN#,0)=REFILL DATE^DAYS
SUPPLY^QUANTITY^RELEASED DATE^ROUTING (M/W)^REMARKS
^TMP("PSO",$J,TR,TD,"PAR",0)=# of partials dispensed
^TMP("PSO",$J,TR,TD,"PAR",PAR IEN#,0)=PARTIAL DATE^DAYS
SUPPLY^QUANTITY^RELEASED DATE^ROUTING (M/W)^REMARKS
^TMP("PSO",$J,TR,TD,"MDR",0)=# of MEDICATION ROUTES
^TMP("PSO",$J,TR,TD,"MDR",D1,0)=MEDICATION ROUTES ABBR.
^TMP("PSO",$J,TR,TD,"SCH",0)=# of schedule entries
^TMP("PSO",$J,TR,TD,"SCH",D1,0)=SCHEDULES
^TMP("PSO",$J,TR,TD,"SIG",0)=# of Sig entries
^TMP("PSO",$J,TR,TD,"SIG",D1,0)=SIG
^TMP("PSO",$J,TR,TD,"PC",0)=# of provider comment entries
^TMP("PSO",$J,TR,TD,"PC",D1,0)=PROVIDER COMMENTS
^TMP("PSO",$J,TR,TD,"DD",0)=1
^TMP("PSO",$J,TR,TD,"DD",1,0)=DISPENSED DRUG IEN#^^\n
For Pending orders, the data is sorted by the DISPENSED DRUG (name)/PHARMACY
ORDERABLE ITEM (name) (TD) and returns the following:\n
^TMP("PSO",$J,"PND",TD,0)=DISPENSED DRUG (if entered in CPRS)/NAME of
the PHARMACY ORDERABLE ITEM concatenated with the NAME OF THE DOSAGE
FORM^^MEDICATION ROUTE ABBR.^^# OF REFILLS^EFFECTIVE DATE^ORDER TYPE
(PENDING/ONHOLD)^^QUANTITY^^PLACER NUMBER\n\n
^TMP("PSO",$J,"PND",TD,"SCH",0)= # of SCHEDULE
^TMP("PSO",$J,"PND",TD,"SCH",D1,0)=SCHEDULE
^TMP("PSO",$J,"PND",TD,"SIG",0)= # of SIG
^TMP("PSO",$J,"PND",TD,"SIG",D1,0)=SIG
^TMP("PSO",$J,"PND",TD,"SIO",0)= # of Lines
^TMP("PSO",$J,"PND",TD,"SIO",D1,0)=PROVIDER COMMENTS (packed to 80
characaters)
^TMP("PSO",$J,"PND",TD,"DD",0) = 1
^TMP("PSO",$J,"PND",TD,"DD",1,0)=DISPENSED DRUG IEN# (if entered in
CPRS)^^", "", "PSOMHV1", ""], ["4688", "STANDARD RULES FOR REQUIRING A MEANS TEST", "Routine", "REGISTRATION", "2005/06/28", "APPROVED", "Active", "Controlled Subscription", "", "
The Means Test Expiration by Appointment Date report
(EASMTRP3) currently lists some patients who do not require a means test.
This is because the rules for determining if a patient requires a means test
are periodically updated. In order to correct the situation without having to
recode the report every time the rules change, the report now calls a central
routine to determine if a means test is required. The central routine (DGMTR)
is the definitive routine that standardizes and compartmentalizes the rules
for requiring a means test with entry point (EN).", "", "DGMTR", ""], ["4689", "DIC(59", "File", "OUTPATIENT PHARMACY", "2007/04/20", "APPROVED", "Active", "Private", "59", "
This DBIA allows the DSS EXTRACTS PACKAGE to do a
direct read to a old global location to retrieve Outpatient Sites. This read
is exempt from the Pharmacy encapsulation effort, since the current global
location is different, and we are not encapsulating pre-V7.0 Outpatient
Pharmacy direct reads.", "", "", "2007/04/22"], ["4690", "XDRDVALF variable", "Other", "TOOLKIT", "2005/06/21", "APPROVED", "Active", "Controlled Subscription", "", "
The XDRDVALF variable is defined during the MERGE
process, and can be used to determine whether changes which are being seen are
the result of a merge process.", "", "", ""], ["4691", "DELETE AFFECTS RECORD MERGE", "File", "KERNEL", "2005/06/17", "APPROVED", "Active", "Private", "9.4", "
Remove all entries in the AFFECTS RECORD MERGE field in
the Package file for Prosthetics.", "", "", ""], ["4692", "DBIA4692", "Routine", "INTEGRATED BILLING", "2005/06/22", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to call the Third
Party Joint Inquiry List Template (Integated Billing) from an Accounts
Receivable List Template option. This is needed to prevent users from having
to exit one menu option and access another option.", "", "IBNCPDPI", ""], ["4693", "DBIA4693", "Routine", "INTEGRATED BILLING", "2005/06/22", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to call the IB CLAIM
TRACKING / VIEW /EDIT EPISODE functionality. This is needed to prevent users
from having to exit one menu option and access another option.", "", "IBNCPDPC", "2010/12/10"], ["4694", "DBIA4694", "Routine", "INTEGRATED BILLING", "2005/06/22", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to call the IB
Patient Insurance Info View/Edit functionality. This is needed to prevent
users from having to exit one menu option and access another option.", "", "IBNCPDPI", ""], ["4695", "DBIA4695", "Routine", "INTEGRATED BILLING", "2005/06/22", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to call the IB
Patient Eligibility functionality. This is needed to prevent users from having
to exit one menu option and access another option.", "", "IBNCPDPL", ""], ["4696", "DBIA4696", "Routine", "INTEGRATED BILLING", "2005/06/22", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to call the IB List
Current/Past Held Charges by Pt functionality. This is needed to prevent users
from having to exit one menu option and access another option.", "", "IBNCPDPH", ""], ["4697", "DBIA4697", "Routine", "INTEGRATED BILLING", "2005/06/22", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to release Held
Charges. This is needed to prevent users from having to exit one menu option
and access another option.", "", "IBNCPDPR", ""], ["4698", "DBIA4698", "Routine", "INTEGRATED BILLING", "2005/06/22", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to invoke ECME
Billing Events Report.", "", "IBNCPDPE", ""], ["4699", "DBIA4699", "File", "INTEGRATED BILLING", "2005/07/14", "", "Retired", "Private", "363.21", "
ECME is storing the pointer to #363.21 BILLING ITEMS
file in its #9002313.57 BPS LOG OF TRANSACTIONS file.", "", "", ""], ["4700", "DBIA4700", "File", "INTEGRATED BILLING", "2005/07/14", "", "Retired", "Private", "363.2", "
ECME is storing the pointer to #363.2 -- CHARGE ITEM
FILE in its #9002313.51 -- BPS DATA INPUT FILE, field (#1.08) CPTIEN
[8P:363.2]", "", "", ""], ["4701", "PSOBPSUT", "Routine", "OUTPATIENT PHARMACY", "2005/06/27", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains apis used mainly by ePharmacy
(Electronic Third Party Billing).", "", "PSOBPSUT", ""], ["4702", "PSOBPSU1", "Routine", "OUTPATIENT PHARMACY", "2005/06/27", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains apis used mainly by ePharmacy
(Electronic Third Party Billing).", "", "PSOBPSU1", ""], ["4703", "DBIA4703", "File", "OUTPATIENT PHARMACY", "2005/12/02", "", "Retired", "Private", "52.5", "
The ECME routines are accessing "B" x-ref and reading
(#3) CMOP INDICATOR field to determine the Window/Mail/CMOP status of the RX.\n
This agreement will be retired on 12/1/2006. Please do not add any additional
code that utilizes this Integration Agreement. APIs have been created that
can be used in place of any code needing to make use of this agreement. These
APIs were released with patch PSO*7*213. Documentation information can be
found in the patch description. In addition, any code that currently utilizes
this Integration Agreement must be converted to use the new API's. If any part
of this Integration Agreement cannot be satisfied with the APIs, please
contact the PRE development team mail group at EMAIL GROUP DEV using Microsoft
Outlook.\n\n\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of
December 1, 2006.", "", "", ""], ["4704", "DBIA4704", "File", "IFCAP", "2005/06/27", "APPROVED", "Active", "Private", "442.6", "", "", "", ""], ["4705", "PSONDCUT", "Routine", "OUTPATIENT PHARMACY", "2005/06/27", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains apis for retrieving, editing and
saving NDC in the PRESCRIPTION file (#52).", "", "PSONDCUT", ""], ["4706", "PSOREJUT", "Routine", "OUTPATIENT PHARMACY", "2005/06/27", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains APIs used for handling rejects
from Third Party Payers that have clinical significance, such as DUR and
REFILL TOO SOON rejects. These rejects are part of the ePharmacy project.\n
Amendment: Effective 5/15/23, added Component CLSALL", "", "PSOREJUT", "2023/05/15"], ["4707", "PSSNDCUT", "Routine", "PHARMACY DATA MANAGEMENT", "2005/06/27", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains apis for retrieving and saving
NDC in the DRUG file (#50).", "", "PSSNDCUT", ""], ["4708", "PSSDAWUT", "Routine", "PHARMACY DATA MANAGEMENT", "2005/06/27", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains apis related to DAW (Dispensed As
Written) code for ePharmacy.", "", "PSSDAWUT", ""], ["4709", "PFSS PROCESS INSURANCE FROM DG REGISTRATION", "Routine", "INTEGRATED BILLING", "2005/06/27", "APPROVED", "Active", "Private", "", "
The Registration application (DG) will receive messages
sent from the COTS Billing package and then pass these messages off to the
Integrated Billing (IB) package for insurance processing. This IA will insure
that Registration accesses the API used to pass the HL7 message off to IB for
processing in the correct way. The routine IBBFINA will be called at the
entry point EN, passing the parameter for the internal entry number of the HL7
message from file 772. The API will parse the HL7 message and store insurance
data values pertinent to the patient inside the new file structures defined
for PFSS Insurance.", "", "IBBFINA", ""], ["4710", "DBIA4710", "File", "INTEGRATED BILLING", "2005/06/28", "APPROVED", "Active", "Private", "356.8", "", "", "", ""], ["4711", "DBIA4711", "Routine", "OUTPATIENT PHARMACY", "2005/06/27", "APPROVED", "Active", "Private", "", "
This call is needed to allow ECME to invoke View
Prescription functionality provided by Outpatient Pharmacy package. This is
needed to prevent users from having to exit one menu option and access
another option.", "", "PSORXVW", ""], ["4712", "LOOKUP/READ ACCESS TO FILE #9002313.21", "File", "E CLAIMS MGMT ENGINE", "2005/07/05", "APPROVED", "Active", "Controlled Subscription", "9002313.21", "
Permission to subscriber packages to make reference to
this file to perform lookups or read its fields. No write access.\n
Amendment: Effective 5/15/23, added field 2", "", "", "2023/05/15"], ["4713", "LOOKUP/READ ACCESS TO FILE #9002313.22", "File", "E CLAIMS MGMT ENGINE", "2005/07/05", "APPROVED", "Active", "Controlled Subscription", "9002313.22", "
Permission to subscriber packages to make reference to
this file to perform lookups or read its fields. No write access.\n
Amendment: Effective 5/15/23, added field 2", "", "", "2023/05/16"], ["4714", "LOOKUP/READ ACCESS TO FILE #9002313.23", "File", "E CLAIMS MGMT ENGINE", "2005/07/05", "APPROVED", "Active", "Controlled Subscription", "9002313.23", "
Permission to subscriber packages to make reference to
this file to perform lookups or read its fields. No write access.\n
Amendment: Effective 5/15/23, added field 2", "", "", "2023/05/16"], ["4715", "LOOKUP/READ ACCESS TO FILE #9002313.24", "File", "E CLAIMS MGMT ENGINE", "2005/07/05", "APPROVED", "Active", "Controlled Subscription", "9002313.24", "
Permission to subscriber packages to make reference to
this file to perform lookups or read its fields. No write access.\n
Amendment: Effective 5/15/23, added field 2", "", "", "2023/05/15"], ["4716", "HLO BUILD MESSAGE APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These APIs are used to build HLO messages.", "", "HLOAPI", "2012/12/26"], ["4717", "HLO SEND MESSAGE APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These APIs provide the ability to address a message
that has already been built and put it on an out-going queue for transmission.\n", "", "HLOAPI1", ""], ["4718", "HLO PARSING APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These APIs are to be used by applications that receive
HL7 messages via HLO. They provide the means of stepping through batches of
messages, the message segments, and fetching data values from within segments.\n", "", "HLOPRS", ""], ["4719", "BPSBUTL", "Routine", "E CLAIMS MGMT ENGINE", "2005/08/16", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains apis that are being used by
outside applications to retrieve/file information relevant to 3rd Party
Electronic Billing (ePharmacy).\n", "", "BPSBUTL", "2013/07/23"], ["4720", "LOOKUP/READ ACCESS TO FILE #9002313.93", "File", "E CLAIMS MGMT ENGINE", "2005/07/07", "APPROVED", "Active", "Controlled Subscription", "9002313.93", "
Permission to subscriber packages to make reference to
this file to perform lookups or read its fields. No write access.", "", "", "2010/08/25"], ["4721", "DBIA4721", "Routine", "INTEGRATED BILLING", "2005/07/07", "", "Other", "Private", "", "
This agreement includes various INTEGRATED BILLING APIs
for use by the E CLAIMS MGMT ENGINE to provide data necessary for processing
electronic claims.", "", "IBNCPDPI", ""], ["4722", "HLO APPLICATION ACKNOWLEDGEMENT APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These APIs are used by applications to return
application acknowledgments to messages received via HLO.", "", "HLOAPI2", ""], ["4723", "HLO APPLICATION ACKNOWLEDGEMENT APIS (CONTINUED)", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These APIs are part of the set of tools that an
application uses to return an application acknowledgement to a message that
was received via HLO. See integration agreement # 4722 for the related APIs.", "", "HLOAPI3", ""], ["4724", "HLO MISCELANEOUS APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These are APIs provided by HLO that don't fit into any
of the other categories.", "", "HLOAPI3", ""], ["4725", "HLO SUBSCRIPTION REGISTRY APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These APIs allow applications to create and manage
entries in the HLO Subscription Registry. Each entry is basically a list of
recipients that can be used and reused to address HL7 messages. Its similar
to a mailing list. See also IA# 4726.", "", "HLOASUB", ""], ["4726", "HLO SUBSCRIPTION REGISTRY APIS (CONTINUED)", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
This continues the APIs for HLO subscription lists.
See IA# 4725.", "", "HLOASUB1", ""], ["4727", "HLO CONVERSION APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These utilities provide help to applications that were
developed before HLO convert to HLO. See also IA# 4728 and IA#4731.", "", "HLOCNRT", ""], ["4728", "HLO CONVERSION APIS (2)", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These utilities provide help to applications that were
developed before HLO convert to HLO. See also IA# 4727 and IA#4731.", "", "HLOCVU", ""], ["4729", "API FOR RX BILLING INFO", "Routine", "INTEGRATED BILLING", "2005/07/11", "APPROVED", "Active", "Controlled Subscription", "", "
The API returns billing information for specified
prescription/refill.", "", "IBNCPDPI", "2010/08/25"], ["4730", "HLO QUEUE MANAGEMENT APIS", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These APIs are for applications to use in KIDS
distributions of messaging applications. They allow the application to turn
on and off individual queues during the instalation of a patch.", "", "HLOQUE", ""], ["4731", "HLO CONVERSOIN APIS (3)", "Routine", "HEALTH LEVEL SEVEN", "2005/08/19", "APPROVED", "Active", "Supported", "", "
These utilities provide help to applications that were
developed before HLO convert to HLO. See also IA# 4727 and IA#4728.", "", "HLOMSG", ""], ["4732", "DBIA4732", "Routine", "OUTPATIENT PHARMACY", "2005/07/15", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement provides the Integration Billing (IB)
package the following IENs for a given Prescription and Refill number that was
released:\n
1. Pharmacist who released the prescription.\n
2. Initiator of Activity - last entry in the activity log with an INITIATOR
OF ACTIVITY field (#.03) value defined. If none are found, default to the
releasing pharmacist. Null values are not to be passed.\n
3. IB Service Section of the dispensing division from the OUTPATIENT SITE
file (#59).\n
The format is Pharmacist IEN^Last Activity Initiator IEN^IB Service Section
IEN.\n
If this API is called for unreleased prescriptions, null values will be
returned for all fields.", "", "PSOPFSU0", ""], ["4733", "Calls to TIUPXAPI", "Routine", "TEXT INTEGRATION UTILITIES", "2005/07/19", "APPROVED", "Active", "Private", "", "
This agreement documents calls from Care Management to
TIUPXAPI.", "", "TIUPXAPI", ""], ["4734", "ORPRF HASFLG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2005/07/18", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement documents use of the ORPRF HASFLG remote
procedure call.\n
TAG^ROUTINE: HASFLG^ORPRF\n
This RPC returns an array of Patient Record Flags on file for the patient in
the format:\n
ARR=number of flags ARR(1)=flag number^text of flag narrative ARR(2)=flag
number^text of flag narrative etc.", "ORPRF HASFLG", "", ""], ["4735", "ORPRF GETFLG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2005/07/18", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement documents calls to the ORPRF GETFLG
remote procedure call.\n
TAG^ROUTINE: GETFLG^ORPRF\n
This RPC is used to return the detailed text of a patient record flag in an
array.", "", "", ""], ["4736", "TERM SETUP", "Routine", "LIST MANAGER", "2005/07/20", "APPROVED", "Active", "Private", "", "
HIPAA Electronic Claims requests an integration
agreement with List Manger to call TERM^VALM0. Call will set up variables
needed by the Claims Data Entry Screen.", "", "VALM0", ""], ["4737", "PFSS PID SEGEMENT BUILDER", "Routine", "REGISTRATION", "2005/07/20", "APPROVED", "Active", "Controlled Subscription", "", "
The PFSS 1B Prototype project requires HL7 messages to
be sent from VistA to a commercial Billing System. The HL7 messages contain a
PID segment. Some elements are needed in that segment that are not supported
by existing PID segment builders. The EN^VAFPFSPD API builds a PID segment
for PFSS use. To the extent possible, EN^VAFPFSPD uses existing, supported
PID utilities to build the customized segment.", "", "VAFPFSPD", ""], ["4738", "OBTAINING FILE 772 POINTER VALUEFROM FILE 773", "File", "HEALTH LEVEL SEVEN", "2005/07/20", "APPROVED", "Active", "Private", "773", "
The PFSS project needs to store the pointer to the File
#772 (HL7 Message Text) record that contains the body of the HL7 message
triggered by an entry in File #375 (PFSS Account). This pointer will be used
for troubleshooting and ad hoc auditing.\n
In order to obtain the pointer value from the Message Id returned by the HL7
GENERATE^HLMA() API, a lookup is done on the "C" cross-reference of File #773.
The "C" cross-reference is built on Field #2, the Message Id. Using the IEN
obtained, the .01 value of the File #773 entry is retrieved. That value is
the desired pointer to the File #772 entry containing the Message Text.", "", "", ""], ["4739", "POINTING TO FILE 772", "File", "HEALTH LEVEL SEVEN", "2005/07/21", "APPROVED", "Active", "Private", "772", "", "", "", ""], ["4740", "My HealtheVet Radiology View extract", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2005/11/04", "", "Pending", "Private", "", "
The 'My HealtheVet' team in preparation for the My
HealtheVet V. 1.0 package requested an additional Radiology/Nuclear Medicine
V5.0 Application Program Interface to provide details of patient records
provided that the patient exam is currently associated with a verified report
or had ever been associated with an verified report (report subsequently was
backed out of the verified status):\n
Format: field #, field name, piece_datatype;file (if pointer) Internal code:
no=external FileMan format, yes=internal FileMan format\n
EXAMINATIONS SUB-FILE #70.03 field field name
node;piece_datatype;file internal
-----------------------------------------------------------------------
2 PROCEDURE 0;2P;71 no\n\n
RAD/NUC MED REPORTS #74 field field name
node;piece_datatype;file internal
------------------------------------------------------------------------
.01 DAY-CASE# 0;1F yes 2
PATIENT NAME 0;2P;2 yes 3 EXAM
DATE/TIME 0;3D yes 4 CASE NUMBER
0;4N yes 5 REPORT STATUS
0;5S no 6 DATE REPORT ENTERED 0;6N
yes 7 VERIFIED DATE 0;7D
yes 8 REPORTED DATE 0;8D yes 9
VERIFYING PHYSICIAN 0;9P;200 yes 14
PRE-VERIFICATION DATE/TIME 0;12D yes 15
PRE-VERIFICATION USER 0;13P;200 yes 17 STATUS
CHANGED TO VERIFIED BY 0;17P;200 yes\n\n
ERROR REPORTS SUB-FILE #74.06 field field name
node;piece_datatype;file internal
------------------------------------------------------------------------
.01 DATE/TIME OF RPT SAVE 0;1D yes\n\n
ADDITIONAL CLINICAL HISTORY SUB-FILE #74.04 field field name
node;piece_datatype;file internal
------------------------------------------------------------------------
.01 ADDITIONAL CLINICAL HISTORY 0;1W yes\n\n
IMPRESSION TEXT SUB-FILE #74.03 field field name
node;piece_datatype;file internal
------------------------------------------------------------------------
.01 IMPRESSION TEXT 0;1W yes\n\n
REPORT TEXT SUB-FILE #74.02 field field name
node;piece_datatype;file internal
------------------------------------------------------------------------
.01 REPORT TEXT 0;1W yes\n\n
RAD/NUC MED ORDERS FILE #75.1 field field name
node;piece_datatype;file internal
------------------------------------------------------------------------
1.1 REASON FOR STUDY .1;1F yes", "", "RAO7PC5", ""], ["4741", "PFSS ACCOUNT REFERENCE", "File", "INTEGRATED BILLING", "2005/07/27", "APPROVED", "Active", "Controlled Subscription", "375", "
Allows VistA applications participating in Patient
Financial Services System (PFSS) to store the PFSS Account Reference within
their respective file structures. The PFSS Account Reference is a pointer to
the PFSS ACCOUNT file (#375).", "", "", ""], ["4742", "HL7 MESSAGE PARSING APIs (PRE-HLO)", "Routine", "HEALTH LEVEL SEVEN", "2005/08/29", "APPROVED", "Active", "Controlled Subscription", "", "
These API's are to be used by applications that were
developed with the HL7 messaging engine that preceded the newer HL7 Optimized
messaging engine that was released in patch HL*1.6*126.\n
The API's provide support for applications in parsing messages. HL7 escape
sequences are decoded.\n", "", "HLPRS", ""], ["4743", "Problem Comment calls in GMPLWP", "Routine", "PROBLEM LIST", "2005/08/01", "APPROVED", "Active", "Controlled Subscription", "", "
This documents available calls to enter or return
Problem Comments.", "", "GMPLWP", ""], ["4744", "HL7 MESSAGE PARSING APIs (PRE-HLO) (continued)", "Routine", "HEALTH LEVEL SEVEN", "2005/08/29", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement completes the description of
the HL7 message parsing APIs that begins with DBIA #4742.\n", "", "HLOPRS", ""], ["4745", "RMIMRP calls", "Routine", "FUNCTIONAL INDEPENDENCE", "2015/04/30", "APPROVED", "Active", "Private", "", "
This documents the calls used by the Virtual Patient
Record (VPR) to extract Functional Independence Measurement data.", "", "RMIMRP", "2015/07/21"], ["4746", "VPR GET PATIENT DATA JSON", "Remote Procedure", "VIRTUAL PATIENT RECORD", "2015/05/21", "APPROVED", "Active", "Controlled Subscription", "", "
VPR GET PATIENT DATA JSON is an rpc that pulls patient
data from VistA and returns it in an array formatted as JSON. Please see the
VPR Technical Manual for details about input parameters and output data
elements.", "", "", "2015/07/06"], ["4747", "VPR updates from OR", "Routine", "VIRTUAL PATIENT RECORD", "2005/08/01", "APPROVED", "Active", "Private", "", "
This documents the calls used by Order Entry/Results
Reporting to update a patient data cache in the Virtual Patient Record (VPR).", "", "VPROR", ""], ["4748", "VPR updates from OR", "Routine", "VIRTUAL PATIENT RECORD", "2005/08/01", "APPROVED", "Active", "Private", "", "
This documents the calls used by Order Entry/Results
Reporting to update a patient data cache in the Virtual Patient Record (VPR).", "", "VPROR1", ""], ["4749", "VPR updates from MCAR/MD", "Routine", "VIRTUAL PATIENT RECORD", "2005/08/01", "APPROVED", "Active", "Private", "", "
This documents the calls used by Clinical Procedures to
update a patient data cache in the Virtual Patient Record (VPR).", "", "VPRPROC", ""], ["4750", "VPR updates from SR", "Routine", "VIRTUAL PATIENT RECORD", "2005/08/02", "APPROVED", "Active", "Private", "", "
This documents the calls used by Surgery to update a
patient data cache in the Virtual Patient Record (VPR).", "", "VPRSR", ""], ["4751", "Calls to TIUSRVLO", "Routine", "TEXT INTEGRATION UTILITIES", "2014/10/31", "APPROVED", "Active", "Private", "", "
The Virtual Patient Record (VPR) would like to call
$$IMGCNT^TIUSRVLO to retrieve the number of images tied to a given document.", "", "TIUSRVLO", ""], ["4752", "VPR utilities for XHTML", "Routine", "VIRTUAL PATIENT RECORD", "2005/08/01", "APPROVED", "Active", "Controlled Subscription", "", "
This documents the calls available to manage
XHTML-formatted text in M.", "", "VPRXHTML", ""], ["4753", "AVPR index", "File", "GEN. MED. REC. - VITALS", "2014/12/12", "APPROVED", "Active", "Private", "120.5", "
The Virtual Patient Record (VPR) would like to create
an action index on the GMRV Vital Measurement file #120.5, that would call a
VPR API in routine VPREVNT when data in the file is entered or modified. The
FileMan utility CREIXN^DDMOD would be used in a post-init for patch VPR*1*3 to
create the AVPR index, instead of exporting the data dictionary. The three
fields listed here are the ones included in the index.", "", "", "2015/02/23"], ["4754", "SETTING DD('IX')", "File", "1", "2014/10/02", "APPROVED", "Active", "Private", "8925", "
Text Integration Utilities (TIU) requests permission to
directly set the ^DD("IX",DA,"NOREINDEX") node in a post-init. DIKCBLD is used
to create the post-init routine that will install the new index, but the new
NOREINDEX flag is not being picked up yet by this utility, and CREIXN^DDMOD
does not currently accept the NOREINDEX designator as part of its input array.
This is a one-time request for patch TIU*1*106.", "", "VPRVIT", "2014/11/04"], ["4755", "ADD B-OPTIONS TO MENU OF B-OPTION", "File", "KERNEL", "2005/09/09", "", "Withdrawn", "Private", "19", "
Kernel's KIDS package currently supports adding an
option from another package to the MENU multiple of either a MENU type option,
or an EXTENDED ACTION type option as part of a packages KIDS installation.
However it doesn't support adding an option to the MENU multiple of a BROKER
type option.\n
Request is to use FileMan call UPDATE^DIE to add BROKER type options to the
MENU multiple of an existing BROKER type option.", "", "", ""], ["4756", "DBIA4756", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUS1 to perform user validation during the VistaLink reauthentication
process, which includes support for the login capabilities of FatKAAT and
KAAJEE.", "", "XUS1", ""], ["4757", "DBIA4757", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUS1A to perform user validation during the VistaLink reauthentication
process, which includes support for the login capabilities of FatKAAT and
KAAJEE.", "", "XUS1A", ""], ["4758", "DBIA4758", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUSHSH to encrypt Kernel access and verify codes to their hashed
versions during the VistaLink reauthentication process, to support the login
capabilities of FatKAAT and KAAJEE.", "", "XUSHSH", ""], ["4759", "DBIA4759", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUSRB4 to perform validation checks on the Kernel CCOW user sign-on
token during the VistaLink reauthentication process. This is used for the
purpose of integrating with the Single Sign-On/User Context (SSO/UC) project
(part of Infrastructure & Security Services).", "", "XUSRB4", ""], ["4760", "DBIA4760", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUSTZ to perform Kernel IP address locking during the VistaLink
reauthentication process, which includes support for the login capabilities of
FatKAAT and KAAJEE.\n
For more information on IP address locking, please see patch XU*8*265,
Subject: 3 Strikes and You Are Out.", "", "XUSTZ", ""], ["4761", "DBIA4761", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUSTZIP to perform checks on Kernel IP/device locking during the
VistaLink reauthentication process, which includes support for the login
capabilities of FatKAAT and KAAJEE.\n
For related information on IP address locking, see integration agreement
#4760.", "", "XUSTZIP", ""], ["4762", "DBIA4762", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUS to check initial sign-on parameters and environment/volume set
information in the KERNEL SYSTEM PARAMETERS file (#8989.3) during the
VistaLink reauthentication process, which includes support for the login
capabilities of FatKAAT and KAAJEE.", "", "XUS", ""], ["4763", "OUTPATIENT MEALS DATA", "Routine", "DIETETICS", "2005/08/16", "APPROVED", "Active", "Private", "", "
This IA allows OE/RR to call functions that will return
3 pieces of data for Outpatient Meals.\n
$$AUTH^FHOMAPI(DUZ) - The user's DUZ is passed into this function and the
function returns a '1' (user holds the FHAUTH key) or a '0' (user does not
hold the FHAUTH key).\n
DIETLST^FHOMAPI - No variables are passed into this API, which simply returns
the array FHDIET containing the list of allowable outpatient diets from the FH
Site Parameters (#119.9) file.\n
$$MAXDAYS^FHOMAPI(FHLOC) - A hospital location pointer is passed into this
function and the function returns the numeric "Max Number of Days" for which
recurring meals can be ordered for this location.\n
$$NFSLOC^FHOMAPI(FHLOC) - A hospital location pointer is passed into this
function and the function returns the NFS location name corresponding to that
hospital location.\n\n\n", "", "FHOMAPI", ""], ["4764", "DBIA4764", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows the VistaLink package to use
routine XUS3 to check, clear, and set the failed access count in the FAILED
SIGNON ATTEMPTS file (#3.084). This will track the count of sign-on attempts
from an IP address or domain. It is used during the VistaLink
reauthentication process, which includes support for the login capabilities of
FatKAAT and KAAJEE.\n
See patch XU*8*265 for more information on the FAILED SIGNON ATTEMPTS file
(#3.084).", "", "XUS3", ""], ["4765", "DBIA4765", "Routine", "KERNEL", "2005/10/06", "APPROVED", "Active", "Private", "", "
This agreement allows the VistaLink package to use
routine XUSAP to implement the Kernel Connector Proxy/Application Proxy APIs.
These APIs are used in both VistaLink initial authentication and
reauthentication processes. These methods have been approved by the Single
Sign-On/User Context (SSO/UC) project (part of Infrastructure & Security
Services).\n
See Kernel supported reference #4677 for more information.", "", "XUSAP", ""], ["4766", "BLOOD BANK ORDER ENTRY API", "Routine", "VBECS", "2005/08/04", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VBECA3", ""], ["4767", "VBECS WORKLOAD CAPTURE", "Routine", "VBECS", "2005/08/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VBECA7", ""], ["4768", "DIRECT DD ACCESS TO SUBFILE 'NM' node", "File", "1", "2010/12/15", "APPROVED", "Active", "Controlled Subscription", "", "
The LAB SERVICE package (LSRP project) needs to access
the name of the sub-file, given its subfile number. We would like to access
this via direct ^DD global read of the 'NM' node:\n
S NAME=$O(^DD(subfile#,0,"NM",""))", "", "", "2010/12/15"], ["4769", "TIU MyHealthEVet APIs", "Routine", "TEXT INTEGRATION UTILITIES", "2005/08/05", "APPROVED", "Active", "Controlled Subscription", "", "
APIs to TIU calls to support Dischare Summary and
Progress Notes lookup for MyHealthEVet.\n\n", "", "TIUMHEV", ""], ["4770", "unique handle into XTMP global.", "Routine", "KERNEL", "2005/08/08", "APPROVED", "Active", "Supported", "", "
Create and return a unique handle (subscript) for the
^XTMP global and create the required zero node.", "", "XUSRB4", ""], ["4771", "DBIA4771", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2005/08/09", "APPROVED", "Active", "Private", "", "
This extrinsic function will be used by CPRS to
transmit changes made to certain Radiology orders that were originally placed
via the Radiology application, not via the CPRS application. These "backdoor"
orders, if they are telephoned or verbal orders, require an electronic
signature in CPRS. Before the e-sig is entered, the provider may add/edit
certain data: ICD Diagnoses and their associated clinical indicators.\n
This API will be used to store the updated data in the RAD/NUC MED ORDERS file
(#75.1). Previous data for ordering ICD diagnoses and their associated
clinical indicators will be removed from the order before storing the updated
data. If the order had already been completed in Radiology and sent to PCE,
then Radiology will re-complete the order and re-send it to PCE.", "", "RABWORD1", ""], ["4772", "INSURANCE PROCESSING", "Routine", "INTEGRATED BILLING", "2005/08/22", "", "Retired", "Private", "", "
This integration agrement between Integrated Billing
and Registration is to allow the processing of Insurance Buffer entries before
subsequent send to the COTS Billing package. Regsitration will call the IB
routine IBBFINS in order to assign Financial Status Classifications (FSC) to
insurance buffers entries that currently do not have a FSC assigned in order
to interface them to the COTS Billing package along with
Registration/Demographic changes.\n
The call will be constructed as EN^IBBFINS(DFN) where DFN is the Internal
Entry Number of the patient in the PATIENT (#2) file. IB will process the
Insurance Buffer (#355.33) file entries and pass operations back to DG
Registration for sending the message to COTS Billing. There is currently NO
value passed back from IBBFINS to indicate completion. Once completed,
Registration is able to send the message on to the COTS Billing package.", "", "IBBFINS", ""], ["4773", "DBIA4773", "File", "LAB SERVICE", "2005/08/10", "APPROVED", "Active", "Controlled Subscription", "68", "
The purpose of this request is to provide the VBECS
package access to read the Laboratory Accession file for the purpose of
validating Blood Bank accession related information.", "", "", ""], ["4774", "DBIA4774", "File", "LAB SERVICE", "2005/08/10", "APPROVED", "Active", "Controlled Subscription", "69", "
The purpose of this request is to provide the VBECS
package access to read the Lab Order Entry file to obtain Blood Bank related
Lab order information.", "", "", ""], ["4775", "DBIA4775", "Routine", "LAB SERVICE", "2005/08/10", "APPROVED", "Active", "Private", "", "
This DBIA has been initiated to authorize the CPRS
application to call API UPDOR^LRBEBA4. This API is used to store data as a
part of the Clinical Indicator Data Capture (CIDC) project. The laboratory
portion of this project is being released with patch LR*5.2*291. This API
call stores data received from the order process in CPRS. The data includes
service connection indicators, environmental indicators and ICD-9 diagnosis
codes entered by the provider in CPRS for ordered lab tests. The data is
stored in the LAB ORDER ENTRY (#69) file and is transmitted to PCE at the time
the ordered test is resulted.\n\n", "", "LRBEBA4", ""], ["4776", "DBIA4776", "File", "CPT/HCPCS CODES", "2005/08/15", "", "Retired", "Controlled Subscription", "81", "", "", "", ""], ["4777", "AR access to IB Patient Copay account data", "File", "INTEGRATED BILLING", "2005/08/17", "APPROVED", "Active", "Private", "354.7", "", "", "", ""], ["4778", "DICRW", "Routine", "1", "2005/08/16", "APPROVED", "Active", "Controlled Subscription", "", "
Make sure DT and other VA FileMan variables are set
without the need to set DIQUIET.", "", "DICRW", ""], ["4779", "DBIA4779", "File", "LAB SERVICE", "2005/08/16", "APPROVED", "Active", "Controlled Subscription", "64", "", "", "", ""], ["4780", "DBIA4780", "Routine", "REGISTRATION", "2005/08/16", "", "Pending", "Private", "", "
This API will be used by DG Registration to generate
ADT^A28 (Add Person) and ADT^A31 (Update Person) messages to a Commercial
Off-the-Shelf Billing system for Registration/Demographic Add/Edits to patient
information. This API will be provided with the patient's DFN and a flag
value to indicate whether this is a new person or a person update event.", "", "DGPFSS1", ""], ["4781", "BUILD A28/A31 MESSAGE FOR PFSS", "Routine", "REGISTRATION", "2005/08/17", "APPROVED", "Active", "Private", "", "
The PFSS 1B Prototype project requires messages to be
sent from VistA to a Commercial Billing System. An ADT,A31 (Update Person
Information) message that is triggered in the Integrated Billing package must
be sent. The $$BUILD^VAFPFSM1 function builds that message based on
information in the VDEF environment.", "", "VAFPFSM1", ""], ["4782", "CLINIC PHONE", "File", "SCHEDULING", "2005/08/31", "APPROVED", "Active", "Controlled Subscription", "44", "\n
The purpose of this agreement is to allow access to TELEPHONE field #99, of
the HOSPITAL LOCATION file #44.", "", "", ""], ["4783", "ADD COMMENT", "Routine", "ADVERSE REACTION TRACKING", "2005/08/18", "APPROVED", "Active", "Private", "", "
The NDF application is forced to clean up some entries
in ART files because of a problem with locally added entries to the DRUG
INGREDIENTS file (#50.416). ART developers asked that we call and entry in
their package to make a note that changes werew made by an NDF patch. To that
end we request permission to call ADCOM^GMRAFX.\n", "", "GMRAFX", ""], ["4784", "GMVMHV", "Routine", "GEN. MED. REC. - VITALS", "2005/08/18", "APPROVED", "Active", "Private", "", "
The MyHealtheVet package requests permission to
retrieve patient vitals/measurements data.", "", "GMVMHV", ""], ["4785", "INSURANCE BUFFER FILE ACCESS", "File", "INTEGRATED BILLING", "2005/08/25", "APPROVED", "Active", "Private", "355.33", "
Access to the Insurance Buffer file (#355.33) is
granted solely for the purpose of creating HL7 messages for the PFSS project.\n
Update: IB*2*497 increased the length of the SUBSCRIBER ID field, NAME OF
INSURED field, GROUP NAME, and GROUP NUMBER field to support the EDI New
Standards and Operating Rules for VHA providers. This required length increase
made it necessary to move the location of these 4 fields to new Data
Dictionary nodes. To support this implementation, all subscribers to this ICR
will need to make the necessary changes in their applications to reference the
new fields and remove the references to the old fields. When all subscribers
have implemented the use of the new fields, the old fields will be deleted
with IB*2*518. Old and new fields are noted in the field list detail of this
ICR.", "", "", "2014/02/21"], ["4786", "PATIENT FSC FILE ACCESS", "File", "INTEGRATED BILLING", "2005/08/25", "APPROVED", "Active", "Private", "370", "
Access to the Patient FSC File (#370) is granted solely
for the purpose of creating an HL7 message for the PFSS project.", "", "", ""], ["4787", "VISTA FSC FILE ACCESS", "File", "INTEGRATED BILLING", "2005/08/25", "APPROVED", "Active", "Private", "370.1", "
Access to the VISTA FSC File (#370.1) is granted solely
for the purpose of building HL7 messages for the PFSS project.", "", "", ""], ["4788", "COMMERCIAL INSURANCE FILE ACCESS", "File", "INTEGRATED BILLING", "2005/08/25", "APPROVED", "Active", "Private", "370.2", "
Access to the Commercial Insurance File (#370.2) is
granted for the sole purpose of building HL7 messages for the PFSS project.", "", "", ""], ["4789", "PFSS PLAN FILE ACCESS", "File", "INTEGRATED BILLING", "2005/08/25", "APPROVED", "Active", "Private", "370.3", "
Access is granted to the PFSS Plan File (#370.3) for
the sole purpose of building HL7 messages for the PFSS project.", "", "", ""], ["4790", "PFSS INSURANCE STATUS UPDATE", "Routine", "INTEGRATED BILLING", "2005/08/25", "APPROVED", "Active", "Private", "370.4", "", "", "IBBFINS", ""], ["4791", "GMVHS", "Routine", "GEN. MED. REC. - VITALS", "2005/12/20", "APPROVED", "Active", "Controlled Subscription", "", "
This routine will return vital/measurement data for a
patient over a given date/time range.", "", "GMVHS", ""], ["4792", "DBIA4792", "Routine", "TEXT INTEGRATION UTILITIES", "2005/08/31", "APPROVED", "Active", "Private", "", "
This IA is used to document the usage of entry point
CANDO^TIUSRVA by Clinical Procedures. Clinical Procedures uses this entry
point to evaluate the prilvilege of a user before allowing the text of the CP
document be viewed.", "", "TIUSRVA", ""], ["4793", "WVRALINK", "Routine", "WOMEN'S HEALTH", "2005/09/12", "APPROVED", "Active", "Private", "", "
The Radiology/NM package will call the Women's Health
package whenever a Radiology report is verified or deleted.", "", "WVRALINK", ""], ["4794", "RA PROCEDURES FILE TEMPORARY READ", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2005/10/12", "APPROVED", "Active", "Controlled Subscription", "71", "
This integration agreement is meant to allow the post
install of OR*3.0*240 to read the RAD/NUC MED PROCEDURES File in order to
update the ORDERABLE ITEMS File with the correct CONTRAST MEDIA codes.\n", "", "", ""], ["4795", "DBIA4795", "Routine", "TEXT INTEGRATION UTILITIES", "2005/09/22", "APPROVED", "Active", "Controlled Subscription", "", "
Entry points in this routine (TIUSRVP2) are used for
signing and addending TIU documents. This agreement overlaps with IA 3535,
for routine TIUSRVP. Routine TIUSRVP was split in patch TIU*1*184, with
components MAKEADD and SIGN moved to TIUSRVP2. Variables and code have not
changed, just the routine. As of TIU*1*184, MAKEADD^TIUSRVP and SIGN^TIUSRVP
call their counterparts in TIUSRVP2. This means it will be more efficient to
call MAKEADD and SIGN directly from TIUSRVP2 when TIU*1*184 is released. This
agreement grants that permission.", "", "TIUSRVP2", ""], ["4796", "DBIA4796", "File", "TEXT INTEGRATION UTILITIES", "2005/09/21", "APPROVED", "Active", "Private", "8925", "
This integration agreement documents the fact that
Clinical Procedures has a field called NEW TIU DOCUMENT IEN (#.03) in
sub-file, CONVERSION LOG (#703.92), in the CP CONVERSION file (#703.9) stores
the internal entry nuumber of the Medicine Report converted note in the TIU
DOCUMENT file (#8925).\n", "", "", ""], ["4797", "MTLU Setup for Code Sets", "File", "TOOLKIT", "2005/09/21", "", "Pending", "Controlled Subscription", "8984.4", "
The Lexicon Utility needs to write to the Kernel
Toolkit Multi-Term Look-up Utility's (MTLU) files during a KIDS
install/post-init.\n", "", "", ""], ["4798", "VAFC NEW NC TREATING FACILITY", "Remote Procedure", "REGISTRATION", "2010/12/15", "APPROVED", "Active", "Private", "", "\n
This Remote Procedure Call will be used by the North Chicago
Common Registration User Interface (UI). Given a patient DFN
and DOD EDIPI, the RPC adds an active Department of Defense
correlation to the VistA TREATING FACILITY LIST (#391.91)
file if it does not exist.\n
It returns a list of Treating Facilities, including Source
Identifier, Identifier Type, Assigning Authority, Assigning
Facility, Identifier Status, and an indicator if the entry
was entered into File 391.91.
TAG: NEWTF ROUTINE: VAFCTFU2\n
INPUT PARAMETER: Vista Patient Identifier
Vista Patient Identifier will be the PATIENT (#2) file
IEN (aka DFN). Example: DFN="7168937"\n
INPUT PARAMETER: DOD Identifier
The DOD Identifier will be EDIPI data in this format:\n
Id^IdType^AssigningAuthority^AssigningFacility\n
Example: EDIPI="852043888^NI^USDOD^200DOD"\n\n
This API returns a list of Treating Facilities in this
format:\n
Id^IdType^AssigningAuthority^AssigningFacility^IdStatus[^NEW]\n
Examples:
RESULT(1)="7168937^PI^USVHA^500^A"
RESULT(2)="1^NI^USDOD^200DOD^A^NEW"\n
Note: If there is data in the 6th piece of the RESULT(<number>),
with data value as "NEW", then it means that the entry
was newly created in the TREATING FACILITY LIST (#391.91)
file by this RPC call.", "", "", "2011/01/14"], ["4799", "IA4799", "Routine", "FEE BASIS", "2005/09/23", "APPROVED", "Active", "Private", "", "", "", "FBRVU", "2007/05/16"], ["4800", "EMERGENCY RESPONSE INDICATOR", "Routine", "REGISTRATION", "2005/09/23", "APPROVED", "Active", "Supported", "", "", "", "DGUTL", "2020/04/08"], ["4801", "DBIA4801", "Routine", "HEALTH DATA & INFORMATICS", "2005/10/05", "APPROVED", "Active", "Private", "", "
Within the Lab Data file (#63), is the Microbiology
multiple (field #5, subfile #63.05), and within that is the Organism multiple
(field #12, subfile #63.3) for microbiology organisms. This in turn contains
site specific fields (created by the option LRWU7 - Add a new internal name
for an antibiotic) for antibiotics associated with the organism. There are
values associated with the antibiotic that meet the criteria for being
described as a set of codes:\n
Value Description
---------------- -------------------------------------------------------
ALWAYS DISPLAY Always display the result.\n
NEVER DISPLAY Never display the result unless the user has the LRLAB
key that indicates user is laboratory personnel.\n
RESTRICT DISPLAY Result is only displayed if the interpretation of
all antibiotics that are always displayed is resistant.\n
Although the set of codes has been assigned VHA Unique Identifier (VUID), new
antibiotics can be entered into VistA by a facility. The new antibiotics are
dynamically assigned field numbers and would not automatically find
translation to a VUID.\n
Since this is a rare exception and one not felt to jeopardize the integrity of
the VUID model, DS proposes to handle the translation of these site specific
fields and provide APIs for the Lab application to use when converting to/from
a VUID. This will allow for more expediency if changes are needed and ensure
that new entries are assigned VUIDs that are interpretable by the HDR. This
DBIA contains the APIs.", "", "HDISVAP", ""], ["4802", "HL7 LOGICAL LINK UPDATE", "File", "HEALTH LEVEL SEVEN", "2006/03/31", "APPROVED", "Active", "Controlled Subscription", "870", "
This DBIA is used to authorize the Order Entry Package
to directly set the fields of a HL7 Logical Link in file 870. The need for
this arrises from the finding that KIDS does not update these fields when a
Logical Link is sent as a component.\n", "", "", ""], ["4803", "PSUHL USAGE", "Routine", "PHARMACY BENEFITS MANAGEMENT", "2005/09/29", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this integration agreement is to record
usage of the routine PSUHL. PSUHL is used to make entries in a retransmission
queue to allow Pharmacy Benefits Management (PBM) extracts to retransmit only
those patient demographics for patients who have had data updated.", "", "PSUHL", ""], ["4804", "PSU SEND", "File", "HEALTH LEVEL SEVEN", "2005/10/05", "APPROVED", "Active", "Private", "870", "
Pharmacy Benefit Management is permitted to distribute
via KIDS the PSU SEND entry in the HL Logical Link file (#870). To do so, it
may:\n
1) Use the "B" cross-reference to find the "PSU SEND" entry's ien.
2) Read existing entries in the file, all fields.
3) Create a new entry whose .01 field is "PSU SEND", on condition that it
does not already exist.
4) Overwrite an existing entry whose .01 field is "PSU SEND".
5) The record must be updated or created via Fileman.\n\n\n\n", "", "", ""], ["4805", "HLO APPLICATION REGISTRY", "File", "HEALTH LEVEL SEVEN", "2005/10/05", "APPROVED", "Active", "Supported", "779.2", "
Permission is given for any application to create new
entries in the HLO Application Registry file and distribute those entries via
KIDS, under these conditions:\n
1) The .01 field must be namespaced by the application. It is the
application's responsibility to insure that their entry is uniquely named.\n
2) The entry must be distributed via KIDS by selecting HLO APPLICATION
REGISTRY from the Build Components screen of the Edit a Build option.\n
3) Select the entry you want to distribute and select an action: SEND TO SITE
or DELETE AT SITE.", "", "", "2005/10/05"], ["4806", "ADD TEMPLATES TO AUDIT FILE", "File", "1", "2010/12/20", "APPROVED", "Active", "Controlled Subscription", "1.1", "
LAB SERVICE has been approved to add a sort and two
print templates to the AUDIT file (#1.1) to print/display audited entries.\n
The templates are:
Sort template: LRJ SYS DISPLAY FILE 60 CHANGE
Print template: LRJ SYS DISPLAY FILE 60 CHANGE
Print Template: LRJ SYS GET INDIRECT AUDIT\n
They both run off the LABORATORY TEST file (#60)", "", "", "2013/06/04"], ["4807", "API FOR RATED DISABILITIES", "Routine", "REGISTRATION", "2005/10/05", "APPROVED", "Active", "Supported", "", "
This agreement covers an API which will return, in an
array, the six fields of the Rated Disabilities multiple from the Patient
file. The multiple is 2.04, field number .372. The array will also return
the disabilities in descending Service Connected percent.", "", "DGRPDB", ""], ["4808", "DG SECURITY LOG SECURITY LEVEL", "File", "REGISTRATION", "2010/12/28", "APPROVED", "Active", "Private", "38.1", "
The Alias Comparison Tool (ACT) in the Laboratory
System Re-Engineering Project (LSRP) uses FileMan Database Server (DBS) API
calls to read the Security Level field (#2) in the DG Security Log (#38.1)
file.\n
1) The following FileMan DBS API is used to determine if the value, LRCVAL,
being passed in from a COTS Lab Information Management System (LIMS) is a
valid value for the Security Level Field (#2):\n
D CHK^DIE(38.1,2,"E",LRCVAL,.LRVAL) where LRCVAL is 0 or 1\n
Example:\n
>S LRCVAL=1\n
> D CHK^DIE(38.1,2,"E",LRCVAL,.LRVAL)\n
>W LRVAL
1\n
2) The following FileMan DBS API is used to get the Security Level Field (#2)
definition:\n
$$GET1^DID(38.1,2,"","POINTER")\n
Example:\n
>S LRFLDEF=$$GET1^DID(38.1,2,"","POINTER")\n
>W LRFLDEF
0:NON-SENSITIVE;1:SENSITIVE;", "", "", "2011/01/05"], ["4809", "DBIA4809", "File", "TOOLKIT", "2005/10/12", "APPROVED", "Active", "Private", "8985.1", "
This DBIA is a one time request to permit the HDI
application to scan the EFFECTIVE DATE/TIME Multiple (subfile #8985.11) of the
XTID VUID FOR SET OF CODES file (#8985.1) for consecutive storage of the same
status using a Direct Global Read. The M code is in the routine HDI1002A
which is being invoked in the post-installation of patch HDI*1.0*2. If a
duplicate status entry is found, the FileMan M routine ^DIK is used to delete
the EFFECTIVE DATE/TIME multiple entry. The HDI1002A routine can be deleted
after the patch is successfully installed. This is a one time request since
future updates to the file will not result in redundant status entries being
created.", "", "", ""], ["4810", "MPIF OPTIONS/MENUS ON CIRN MENUS", "Other", "CLINICAL INFO RESOURCE NETWORK", "2005/10/11", "APPROVED", "Active", "Private", "", "\n
MPI is requesting to place some options/menus on CIRN namespaced Menus.
This request replaces IA #2717 which is out-of-date.\n
MPIF CMOR MGR on the RG ADMIN USER MENU
MPIF SITE PARAMETER on the RG ADMIN COORD MENU
MPIF DISPLAY ONLY QUERY TO MPI on the RG EXCEPTION MENU", "", "", ""], ["4811", "DBIA 4811", "Routine", "CLINICAL REMINDERS", "2005/10/26", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement describes the Clinical
Reminders APIs developed for use by My HealtheVet.\n\n", "", "PXRMMHV", ""], ["4812", "DBIA4812", "File", "E CLAIMS MGMT ENGINE", "2005/10/12", "APPROVED", "Active", "Private", "9002313.02", "\n
The IB package required direct Read access to the following fields
of the BPS CLAIMS file (#9002313.02)\n
Field Name Loc Access
1.04 VA PLAN IEN 1;4 Direct Global Read", "", "", ""], ["4813", "DBIA4813", "File", "E CLAIMS MGMT ENGINE", "2005/10/12", "APPROVED", "Active", "Private", "9002313.03", "
The IB package requires Read-only access (both direct
global reads and through FileMan) to all fields, nodes, and pieces of the BPS
RESPONSES file (#9002313.03) and to all subfiles.", "", "", "2010/11/12"], ["4814", "HEALTH RECORD NUMBER LOOKUP", "File", "PCE PATIENT CARE ENCOUNTER", "2005/10/12", "APPROVED", "Active", "Private", "9000001", "", "", "", ""], ["4815", "GMVDCSAV", "Routine", "GEN. MED. REC. - VITALS", "2005/10/19", "APPROVED", "Active", "Controlled Subscription", "", "
Allows the subscriber to file patient vitals data in
the GMRV VITAL MEASUREMENT (#120.5) file.", "", "GMVDCSAV", ""], ["4816", "DD Nodes for files 5, SUB-FILE 5.01, 5.12, & 5.13", "File", "1", "2005/10/24", "APPROVED", "Active", "Private", "", "
This will be a one time agrement for patch XU*8*378 to
se the following nodes:\n
Routine: XU8P378
; Set current C xrefs in 5 to Q
S ^DD(5,1,1,1,1)="Q"
S ^DD(5,1,1,1,2)="Q"
S ^DD(5,1,1,1,3)="Used in conjunction with the 'ADUALC' xref."
S ^DD(5,1,"DT")=$G(DT)
S ^DD(5,2,1,1,1)="Q"
S ^DD(5,2,1,1,2)="Q"
S ^DD(5,2,1,1,3)="Used in conjunction with the 'ADUALC' xref."
S ^DD(5,2,"DT")=$G(DT)\n
Routine: XU8P378C
; Set DEL & LAYGO nodes for file 5
S ^DD(5,.01,"DEL",1,0)="D EN^DDIOL(""Deletions are not
allowed."","""", ""!?5,$C(7)"") I 1"
S ^DD(5,.01,"LAYGO",1,0)="D EN^DDIOL(""New State additions are not
allowed."","""",""!?5,$C(7)"") I 0"
S ^DD(5,.01,"DT")=$G(DT)
;
; Set DEL & LAYGO nodes for sub-file 5.01
S ^DD(5.01,.01,"DEL",1,0)="D EN^DDIOL(""Entries can only be
Inactivated."","""",""!?5,$C(7)"") I 1"
S ^DD(5.01,.01,"LAYGO",1,0)="D EN^DDIOL(""New County additions are
not allowed."","""",""!?5,$C(7)"") I 0"
S ^DD(5,.01,"DT")=$G(DT)
;
; Set DEL node for file 5.12
S ^DD(5.12,.01,"DEL",1,0)="D EN^DDIOL(""Entries can only be
Inactivated."","""",""!?5,$C(7)"") I 1"
S ^DD(5.12,.01,"DT")=$G(DT)
;
; Set Del & LAYGO nodes for file 5.13
S ^DD(5.13,.01,"DEL",1,0)="D EN^DDIOL(""Entries can only be
Inactivated."","""",""!?5,$C(7)"") I 1"
S ^DD(5.13,.01,"LAYGO",1,0)="D EN^DDIOL(""New County Code additions
are not allowed."","""",""!?5,$C(7)"") I 0"
S ^DD(5.13,.01,"DT")=$G(DT)", "", "", ""], ["4817", "PFSS EVN SEGMENT BUILDER", "Routine", "REGISTRATION", "2005/10/24", "APPROVED", "Active", "Controlled Subscription", "", "
The PFSS 1B Prototype requries HL7 messages to be sent
from VistA to a Commercial Billing System. The messages contain an EVN
segment with contents not supported by existing EVN-building utilities. The
EN^VAFPFSEV API returns a complete EVN segment.", "", "VAFPFSEV", ""], ["4818", "MHV use of ORQQPL3", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2005/10/25", "APPROVED", "Active", "Private", "", "
This documents usage of calls in ORQQPL3 to obtain a
patient's problems.", "", "ORQQPL3", ""], ["4819", "PSJ59P5", "Routine", "INPATIENT MEDICATIONS", "2005/10/31", "APPROVED", "Active", "Supported", "59.5", "
This API shall be provided to return the NAME field
(#.01), DIVISION field (#.02) and INACTIVATION DATE field (#19) from the IV
ROOM file (#59.5) for the IEN or free text entry received.", "", "PSJ59P5", ""], ["4820", "PRESCRIPTION FILE (#52) DATA ELEMENTS", "Routine", "OUTPATIENT PHARMACY", "2005/12/07", "APPROVED", "Active", "Supported", "", "
The PSO52API routine shall be used to return requested
data elements for the PRESCRIPTION file (#52).", "", "PSO52API", "2007/03/04"], ["4821", "DBIA4821", "Routine", "OUTPATIENT PHARMACY", "2005/12/07", "APPROVED", "Active", "Supported", "", "
The 'PEN' component returns data from the PENDING
OUTPATIENT ORDERS (#52.41) File. The 'NONVA' component returns data from the
NON-VA MEDS (#55.05) Subfile of the PHARMACY PATIENT (#55) File.", "", "PSO5241", "2020/06/01"], ["4822", "DBIA4822", "Routine", "OUTPATIENT PHARMACY", "2005/12/07", "APPROVED", "Active", "Supported", "", "
The routine PSO525AP shall be used to return requested
data elements for the RX SUSPENSE file (#52.5). Various data elements shall be
returned by parameter passing. The following requirements shall describe what
is passed in and what is returned.", "", "PSO525AP", ""], ["4823", "DBIA4823", "Routine", "OUTPATIENT PHARMACY", "2005/12/07", "APPROVED", "Active", "Supported", "", "
This API shall return the following fields from the
CLOZAPINE PRESCRIPTION OVERRIDES file (#52.52) for the IEN or free text entry
received: DATE/TIME, PRESCRIPTION NUMBER, USER ENTERING, APPROVING TEAM
MEMBER, REASON FOR LOCKOUT, and COMMENTS.", "", "PSO5252", ""], ["4824", "DBIA4824", "Routine", "OUTPATIENT PHARMACY", "2005/12/07", "APPROVED", "Active", "Supported", "", "
This API shall return the following fields from the TPB
ELIGIBILITY file (#52.91) for the IEN or free text entry received: PATIENT,
DATE PHARMACY BENEFITS BEGAN, INACTIVATION OF BENEFITS DATE, INACTIVATION
REASON CODE, DESIRED APPOINTMENT DATE, WAIT TYPE, STATION NUMBER, INSTITUTION,
EXCLUSION REASON, PRIMARY CARE SCHEDULED APPT DATE, RX#, and DATE LETTER
PRINTED.", "", "PSO5291", ""], ["4825", "DBIA4825", "Routine", "OUTPATIENT PHARMACY", "2005/12/07", "APPROVED", "Active", "Supported", "", "
This API shall be provided to scan the NAME field
(#.01) of RX PATIENT STATUS file (#53) utilizing the "B" cross-reference and
return a listing of records for a specific value based on logical criteria
received for the patient status. The following fields shall be included: NAME,
ABBR, DAYS SUPPLY, REFILLS, RENEWABLE, SC/A&A/OTHER/INPATIENT/NVA, EXEMPT FROM
COPAYMENT, and EXEMPT FROM CHAMPUS BILLING.", "", "PSO53", ""], ["4826", "DBIA4826", "Routine", "PHARMACY DATA MANAGEMENT", "2005/11/15", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the PHARMACY PATIENT file (#55). This API is to used in the
future by all packages accessing this file as all the Pharmacy packages are
being re-engineered.", "", "PSS55", ""], ["4827", "OUTPATIENT SITE FILE", "Routine", "OUTPATIENT PHARMACY", "2005/12/07", "APPROVED", "Active", "Supported", "", "
This API shall return the following fields from the
OUTPATIENT SITE file (#59) for the IEN or free text entry received: NAME,
MAILING FRANK STREET ADDRESS, AREA CODE, PHONE NUMBER, MAILING FRANK ZIP+4
CODE, SITE NUMBER, MAILING FRANK CITY, MAILING FRANK STATE, SITE DEA NUMBER,
RELATED INSTITUTION, NPI INSTITUTION, IB SERVICE/SECTION and NCPDP NUMBER.", "", "PSO59", "2011/02/16"], ["4828", "DBIA4828", "Routine", "PHARMACY DATA MANAGEMENT", "2005/11/15", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to the PHARMACY SYSTEM file (#59.7). This API is to used in the
future by all packages accessing this file as all the Pharmacy packages are
being re-engineered.", "", "PSS59P7", ""], ["4829", "DBIA4829", "Routine", "NATIONAL DRUG FILE", "2006/02/14", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by NDF (National Drug File) as an
API to the NDC/UPN file (#50.67). This API is to used in the future by all
packages accessing this file as all the Pharmacy packages are being
re-engineered.", "", "PSN5067", ""], ["4830", "MPI HEC Enumeration Project/NDBI Global", "File", "NDBI", "2005/11/03", "APPROVED", "Active", "Private", "", "\n
This IA is for the Master Patient Index (MPI) Health Eligibility
Center (HEC) Enumeration project.\n
There are approximately 29,000 patient entries, identified at the HEC
from legacy systems, for which the primary site is not known on the HEC.
These patients need to be identified on the primary VistA system so
they can be added to the 1.6 million HEC patients to be assigned ICNs.
This needs to be done prior to the beginning of the HEC enumeration.
Information for these patients may be available in the NDBI POINTER
CONVERSION file (#17002.2) on the primary VistA system.\n
From the Master Patient Index (MPI), a remote request can be sent to
an integrated facility for the identified HEC legacy patient entries.
A Remote Procedure Call (RPC) on the local VistA system will search
the NDBI POINTER CONVERSION file (#17002.2) and return to the MPI the
DFN for that entry in the primary site if it is available. This RPC
will only be used at selected integrated sites.\n
The Master Patient Index VistA package references a National Database
Integration global: ^A7RCP.\n", "", "", ""], ["4831", "GMV_VitalsViewEnter.dll", "Other", "GEN. MED. REC. - VITALS", "2005/11/30", "APPROVED", "Active", "Private", "", "
This integration agreement allows the subscribing
package to call the Dynamic Link Library (DLL) file named
GMV_VitalsViewEnter.dll. This DLL is a Graphical User Interface (GUI) for
entering and displaying patient vitals information.\n
This DLL is written in Delphi. It is called from another Delphi application.
The entry points and input variables are Delphi, not M.\n
The following GMV-namespaced Remote Procedure Calls must be in the RPC (#320)
field of the OPTION (#19) file entry used to create the Broker context. They
are:\n
GMV ADD VM
GMV CONVERT DATE
GMV GET CATEGORY IEN
GMV GET CURRENT TIME
GMV GET VITAL TYPE IEN
GMV LATEST VM
GMV MANAGER
GMV PARAMETER
GMV USER
GMV VITALS/CAT/QUAL
GMV V/M ALLDATA
GMV EXTRACT REC
GMV MARK ERROR
GMV ALLERGY
GMV DLL VERSION
GMV LOCATION SELECT
GMV CLOSEST READING [added to the list on 6/23/09]\n
These additional Remote Procedure Calls must be in the RPC (#320) field of the
OPTION (#19) file entry used to create the Broker context. They are:\n
ORWPT PTINQ
VAFCTFU CONVERT DFN TO ICN
VAFCTFU CONVERT ICN TO DFN", "", "", "2009/06/23"], ["4832", "COMMON FILES", "Other", "KERNEL", "2006/01/05", "APPROVED", "Active", "Controlled Subscription", "", "
Packages may place their common files under
Program Files\\VistA\\Common Files\\", "", "", ""], ["4833", "ADDRPCS FOR GUI 26", "Routine", "GEN. MED. REC. - VITALS", "2005/11/02", "APPROVED", "Active", "Private", "", "
This Integration Agreement is for the sole purpose of
allowing the CPRS GUI 26 post-install routine to add the GMRV RPCs to the CPRS
option.\n", "", "GMV3PST", ""], ["4834", "USER ALERTS", "Routine", "KERNEL", "2005/11/03", "APPROVED", "Active", "Controlled Subscription", "", "
This Integration Agreement is to document the calls
GETUSER1^XQALDATA and GETUSER2^XQALDATA. The Order Entry package uses these
calls to retrieve the alerts that a user needs to see.\n
Amendments: 10/20/22 Component GETPAT2 was added in XU*8.0*653, as a part of
the CPRS v31b release which included an enhancement to show all the alerts
related to a patient, rather than only those alerts specific to the provider.\n
10/20/22 Component GETUSER2 was added in XU*8.0*662 as part of the
enhancements for the display of processed alerts in CPRS v32b.\n
08/18/23 Components DEFALERT and GETPAT3 were added in XU*8*653 and used by
CPRS v31b release, in addition to the GETPAT2 documented on 10/20/22.", "", "XQALDATA", "2023/08/22"], ["4835", "ADD GMV RPCS TO OR CPRS GUI CHART", "Other", "ORDER ENTRY/RESULTS REPORTING", "2005/12/01", "APPROVED", "Active", "Private", "", "
CPRS grants permission to the GMRV GEN. MED. REC. -
VITALS package to add GMV-namespaced Remote Procedure Calls (RPCs) to the RPC
(Field #320) multiple of the OR CPRS GUI CHART option (File #19).", "", "", ""], ["4836", "DBIA4836", "File", "SCHEDULING", "2006/03/22", "APPROVED", "Active", "Private", "40.7", "", "", "", ""], ["4837", "LOOK UP REQUEST/CONSULTATION ENTRY", "File", "CONSULT/REQUEST TRACKING", "2006/03/24", "APPROVED", "Active", "Private", "123", "", "", "", "2007/03/04"], ["4838", "4838 MAGDTR01", "Routine", "IMAGING", "2006/03/31", "APPROVED", "Active", "Controlled Subscription", "", "
Imaging has requested Consults to add a call,
ORRIN^MAGDTR01 to the routine GMRCIMSG for use with patch MAG*3.0*46. This
will allow Imaging to process Consult HL7 messages.", "", "MAGDTR01", ""], ["4839", "Is This a PRF Title", "Routine", "TEXT INTEGRATION UTILITIES", "2006/04/07", "APPROVED", "Active", "Private", "", "
This agreement permits subscribers to call
ISPFTTL^TIUPRFL to determine whether a given TIU Title (file 8925.1) is a
Patient Record Flag Title.", "", "TIUPRFL", ""], ["4840", "PROCESS INBOUND BATCH HEC ORU MESSAGES TO A31", "Routine", "REGISTRATION", "2006/04/11", "APPROVED", "Active", "Controlled Subscription", "", "
This call is to process an inbound batch ORU message
from the HEC to extract information to generate outbound A31 messages to
external PFSS system.", "", "DGPFSS2", ""], ["4841", "CONSULT LINK", "File", "SCHEDULING", "2006/04/10", "APPROVED", "Active", "Private", "44", "", "", "", "2009/07/14"], ["4842", "DBIA4842", "File", "SCHEDULING", "2006/04/10", "APPROVED", "Active", "Private", "409.3", "", "", "", ""], ["4843", "DBIA4843", "File", "SCHEDULING", "2006/04/10", "APPROVED", "Active", "Private", "409.31", "", "", "", ""], ["4844", "DBIA4844", "File", "SCHEDULING", "2006/04/10", "APPROVED", "Active", "Private", "409.32", "", "", "", ""], ["4845", "Return NEW PERSON file phone number(s)", "Routine", "IMAGING", "2006/04/12", "APPROVED", "Active", "Private", "", "
The Vista Radiology/Nuclear Medicine application would
like to utilize the existing VistA Imaging utility (NPFON^MAG7UFO) to return
all phone number related information for a specific record in the NEW PERSON
(#200) file.", "", "MAG7UFO", ""], ["4846", "DBIA4846", "File", "PHARMACY DATA MANAGEMENT", "2006/04/13", "APPROVED", "Active", "Supported", "50", "
This DBIA allows for subscribing packages to store a
pointer to the Vista DRUG (#50) file. This number can be used as an
Identification Number to retrieve data.", "", "", ""], ["4847", "GET ALLERGY DATA INCLUDING REMOTE", "Routine", "ADVERSE REACTION TRACKING", "2006/04/18", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA is to allow subscribing packages to get the
aggregate sum of a patients allergy information reduced into the drug classes
and drug ingredients that the patient has allergies to.\n", "", "GMRAOR", "2016/07/28"], ["4848", "GMRAOC TMP GLOBAL READ", "File", "ADVERSE REACTION TRACKING", "2006/04/18", "APPROVED", "Active", "Controlled Subscription", "", "
This dbia is a followup to DBIA #4847. This allows the
calling package of GETDATA^GMRAOR to read the results of the call from the
^TMP("GMRAOR",$J global.\n", "", "", "2014/05/30"], ["4849", "DBIA #4849", "Other", "REGISTRATION", "2006/04/20", "APPROVED", "Active", "Private", "771", "
For the PFSS project, which includes a number of VistA
application packages, structures are setup for HL7 communication between VistA
and an external COTS system for patient billing.\n
Most inbound HL7 messages are being received for processing by the
REGISTRATION package (DG), but two specific messages (ADT-A05 and ADT-A04)
must be processed only by the INTEGRATED BILLING package within the new IBB
module for PFSS.\n
The IBB receivers use four PROTOCOLS (file #101) in order to route the ADT-A05
and ADT-A04 to the processing routine. Since the COTS system will only use
the HL7 APPLICATION PARAMETER (file #771) names setup for the DG application
in their MSH segments, the IBB Protocols must be pointed to these file #771
entries.\n
This IA allows the four IBB Protocols to utilize the DG Application Parameters
DGPFSS ADT RECV and DGPFSS ADT SENDING as follows:\n
NAME: IBB PFSS ADT-A04 CLIENT TYPE: subscriber
RECEIVING APPLICATION: DGPFSS ADT RECV
EVENT TYPE: A04 RESPONSE MESSAGE TYPE: ADT
PROCESSING ROUTINE: D A04^IBBAADTI SENDING FACILITY REQUIRED?: NO
RECEIVING FACILITY REQUIRED?: NO\n
NAME: IBB PFSS ADT-A04 SERVER ITEM TEXT: PFSS/IBB ADT-A04 Receiver
TYPE: event driver
SENDING APPLICATION: DGPFSS ADT SENDING
TRANSACTION MESSAGE TYPE: ADT EVENT TYPE: A04
MESSAGE STRUCTURE: ACK ACCEPT ACK CODE: AL
APPLICATION ACK TYPE: AL VERSION ID: 2.4 SUBSCRIBERS: IBB PFSS
ADT-A04 CLIENT\n
NAME: IBB PFSS ADT-A05 CLIENT TYPE: subscriber
RECEIVING APPLICATION: DGPFSS ADT RECV
EVENT TYPE: A05 RESPONSE MESSAGE TYPE: ADT
PROCESSING ROUTINE: D A05^IBBAADTI SENDING FACILITY REQUIRED?: NO
RECEIVING FACILITY REQUIRED?: NO\n
NAME: IBB PFSS ADT-A05 SERVER ITEM TEXT: PFSS/IBB ADT-A05 Receiver
TYPE: event driver
SENDING APPLICATION: DGPFSS ADT SENDING
TRANSACTION MESSAGE TYPE: ADT EVENT TYPE: A05
ACCEPT ACK CODE: AL APPLICATION ACK TYPE: AL
VERSION ID: 2.4\n", "", "", ""], ["4850", "CALL TO GET ENCOUNTER STATUS", "Routine", "SCHEDULING", "2006/04/27", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA will permit Clinical Reminders to use an
existing Scheduling function call to get the Status of an encounter.\n", "", "SDPCE", ""], ["4851", "KAAJEE", "Other", "KERNEL", "2006/04/21", "APPROVED", "Active", "Supported", "", "\n\n
KAAJEE addresses the Authentication and Authorization (AA) needs of
HealtheVet-VistA Web-based applications in the J2EE environment.\n
Most major J2EE application servers (e.g., BEA WebLogic V. 8.1 [SP4 or higher]
and Oracle's 9iAS) allow enterprises to override the default source of AA and
replace it with custom, enterprise-specific sources for AA. In order to
rapidly develop an AA solution for HealtheVet-VistA web-based applications
without creating a new enterprise user store, KAAJEE takes full advantage of
this feature of creating a custom solution. This enables KAAJEE to provide a
solution that has a similar look-and-feel of what VistA users are currently
accustomed to.\n
KAAJEE authenticates against a VistA M Server first with Access and Verify
codes via VistALink's AV connection spec (i.e.,
KaajeeVistaLinkConnectionSpec). After the user has been properly authenticated
against a VistA M Server, KAAJEE dynamically creates a temporary username and
password and populates this into a Structured Query Language (SQL) database
via custom Security Service Provider Interfaces (SSPIs). This username and
password is needed for the second level/phase/pass authentication for the J2EE
container.\n
Currently, Kernel maintains the primary HealtheVet-VistA user store (i.e., NEW
PERSON file [#200]), and provides both Authentication and Authorization (AA)
services for all HealtheVet-VistA applications. By leveraging Kernel, KAAJEE
aims to authenticate and authorize J2EE Web users to their applications using
Kernel's AA capabilities.\n", "", "", ""], ["4852", "HLO DATA TYPE PARSERS", "Routine", "HEALTH LEVEL SEVEN", "2006/06/05", "APPROVED", "Active", "Supported", "", "
This provides specialized APIs for parsing HL7 data
types from a segment. It applies only to HL7 messages received via the HLO
software that was released in patch HL*1.6*126.\n", "", "HLOPRS2", ""], ["4853", "HLO BUILDING MESSAGES WITH DATA TYPES", "Routine", "HEALTH LEVEL SEVEN", "2006/06/05", "APPROVED", "Active", "Supported", "", "
This provides specialized APIs for buiding messages
with HL7 data types. It applies only to HL7 messages received via the HLO
software that was released in patch HL*1.6*126.\n", "", "HLOAPI4", "2015/01/22"], ["4854", "DBIA4854", "Routine", "CONSULT/REQUEST TRACKING", "2006/05/08", "APPROVED", "Active", "Private", "", "
This DBIA documents call made to routine GMRCGUIS.", "", "GMRCGUIS", ""], ["4855", "NPI field for #200", "File", "KERNEL", "2006/05/09", "APPROVED", "Active", "Private", "200", "
Set ^DD for NPI fields in files #200 and #4:\n
; Set un-editable for STATUS field (#.02) in EFFECTIVE DATE/TIME subfile
(#200.042) I $P(^DD(200.042,.02,0),"^",2)'["I" D . S
$P(^DD(200.042,.02,0),"^",2)=$P(^DD(200.042,.02,0),"^",2)_"I" ; Set
un-editable for STATUS field (#.02) in EFFECTIVE DATE/TIEM subfile (#4.042) I
$P(^DD(4.042,.02,0),"^",2)'["I" D . S
$P(^DD(4.042,.02,0),"^",2)=$P(^DD(4.042,.02,0),"^",2)_"I" ; Set DEL-LAYGO for
NPI field (#41.99) in INSTITUTION file (#4) S
^DD(4,41.99,"DEL",11,0)="D:'$D(XUMF) EN^DDIOL(""Entries must be inactivated
via the Master File Server(MFS)."","""",""!?5,$C(7)"") I $D(XUMF", "", "", ""], ["4856", "DBIA4856", "Routine", "HEALTH DATA & INFORMATICS", "2006/09/08", "APPROVED", "Active", "Supported", "", "
API will be used by HSITES as part of their software to
insure that mirrored test accounts are setup properly.", "", "HDISVCUT", ""], ["4857", "DBIA4857", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/05/11", "", "Pending", "Private", "", "
General Description goes here", "", "", ""], ["4858", "DBIA 4858", "Routine", "OUTPATIENT PHARMACY", "2006/05/15", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by PSO (Outpatient Pharmacy) as
an API to do simulated VA FileMan calls. This API is to be used in the future
by all packages needing to use FileMan to look at the PRESCRIPTION file (#52)
and the OUTPATIENT SITE file (#59) as all the Pharmacy packages are being
re-engineered.", "", "PSODI", "2007/07/10"], ["4859", "ORDER CHECK API", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2006/05/22", "APPROVED", "Active", "Supported", "", "
This Integration Aggreement will permit ancilliary
packages to obtain the order check information for a specific order.\n", "", "ORCHECK", "2006/05/30"], ["4860", "HDI", "Routine", "HEALTH DATA & INFORMATICS", "2006/05/23", "APPROVED", "Active", "Supported", "", "
API for storage of the file/field implementation
status.\n
Packages may invoke this API without registering another IA only if the domain
and files being referenced are in the calling package's numberspace.", "", "HDISVF01", ""], ["4861", "DBIA4861", "File", "HEALTH LEVEL SEVEN", "2006/05/31", "APPROVED", "Active", "Private", "771", "
A one time update to set the site number in HL7's table
for the Application entry in file 771 during post install.", "", "", ""], ["4862", "DBIA4862", "Other", "INTEGRATED BILLING", "2006/06/14", "APPROVED", "Active", "Private", "", "
The HL LOGICAL LINK file entry IBBPFSS1 may be
referenced from the LOGICAL LINK field as packages export PROTOCOL file
entries using that link.", "", "", ""], ["4863", "USING OR RDI CACHE TIME AS PARAMETER", "Other", "ORDER ENTRY/RESULTS REPORTING", "2006/06/05", "APPROVED", "Active", "Private", "", "
This IA is to allow the ART package to use the
parameter "OR RDI CACHE TIME" parameter in a call to GET^XPAR.", "", "", ""], ["4864", "LR7OR4", "Routine", "LAB SERVICE", "2006/06/13", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA formalizes the documentation for calls to
OR7OR4 as documented in the OE/RR Interface Specification document.\n", "", "LR7OR4", ""], ["4865", "DBIA4865", "File", "REGISTRATION", "2006/06/14", "APPROVED", "Active", "Private", "2", "
Clinical Reminders will use VA FileMan to get the
Division that a patient belongs to by getting the data from field .19 DIVISION
in the PATIENT file #2.\n", "", "", ""], ["4866", "DBIA4866", "File", "GEN. MED. REC. - VITALS", "2006/07/10", "APPROVED", "Active", "Private", "120.51", "
Clinical Procedures is using a Fileman call $$FIND1^DIC
to find the internal entry number of the Vital type in GMRV Vital Type file
(#120.51).\n\n", "", "", ""], ["4867", "DBIA4867", "File", "GEN. MED. REC. - VITALS", "2006/07/26", "APPROVED", "Active", "Private", "120.5", "
This IA will be used in conjunction with IA 4815. IA
4815 allows Clinical Procedures (CP) to add vital measuements. IA 4867 gives
CP the permission to lock the ^GMR(120.5,0) global root before adding the
vital measurements and let CP use a reverse $O command ^GMR(120.5,"A") to get
the internal entry number of the last entry of vital measurement that was
added.\n", "", "", ""], ["4868", "DBIA4868", "File", "KERNEL", "2006/07/31", "APPROVED", "Active", "Private", "200", "
Subscribers have permission to $O through the "AUSER"
index of the NEW PERSON file (#200) to get a list of available provider names.\n\n", "", "", ""], ["4869", "DBIA4869", "File", "REGISTRATION", "2006/08/03", "APPROVED", "Active", "Private", "45.7", "
The CP Definition file (#702.01) points to the Facility
Treating Specialty file (#45.7). In order to print/display a CP Studies List
by Treating Specialty, Clinical Procedures will use the following DIC call to
query for a Facility Treating Specialty:\n
S DIC="^DIC(45.7,",DIC(0)="EMQ" D ^DIC\n", "", "", ""], ["4870", "FILE 442 AND 443.6 FCPFIELD FIX FILE DD", "File", "1", "2011/01/04", "APPROVED", "Active", "Private", "443.6", "
This is a one time aggreement via patch PRC*5.1*128.\n
Kill node 9 from following field DD definition:\n
^DD(443.61,8,0)=FEDERAL SUPPLY CLASSIFICATION^RP441.2'X^PRC(441.2,^2;3^D
EN100^PRCHNPO7
.1)=FSC/PSC ^DD(443.61,8,1,0)=^.1
^DD(443.61,8,1,1,0)=443.61^AU^MUMPS
1)=I $G(PRCHNORE)=1 D:PRCHAMDA=21 EN1^PRCHAMXG Q:PRCHAMDA=21
D FLAG^PRCHMA Q:$T I PRCHAMDA=23 S PRCHX=X,X=0 D EN1^PRCHAMXD S X=PRCHX K
PRCHX
2)=I $G(PRCHNORE)=1,PRCHAMDA=23 S FLAG=1 D EN1^PRCHAMXD
^DD(443.61,8,1,1,"%D",0)=^^5^5^2970416^^^^ ^DD(443.61,8,1,1,"%D",1,0)=This
x-ref will update the CHANGES multiple whenever a 'Line Item Add' or a
^DD(443.61,8,1,1,"%D",2,0)='Line Item Edit' amendment changes this field.
^DD(443.61,8,1,1,"%D",3,0)=
^DD(443.61,8,1,1,"%D",4,0)=****NOTE-See routine PRCHAMXA for information on
variable PRCHNORE and ^DD(443.61,8,1,1,"%D",5,0)=incidence of undefined DIK
variable errors. ^DD(443.61,8,1,1,"DT")=2950321 ^DD(443.61,8,3)=
9)=^ <<<=========== kill this field
^DD(443.61,8,21,0)=^.001^2^2^3050909^^^^ ^DD(443.61,8,21,1,0)=This is the
Federal Supply Classification for an item, or the Product
^DD(443.61,8,21,2,0)=Service Code for a service. ^DD(443.61,8,"DT")=3050909\n\n
Global ^DD(442.01,8 -- NOTE: translation in effect ^DD(442.01,8,0)=FEDERAL
SUPPLY CLASSIFICATION^RP441.2'X^PRC(441.2,^2;3^D EN10^PRCHNPO7
.1)=FSC/PSC
3)=ANSWER MUST BE 1-24 CHARACTERS IN LENGTH
9)=^ <<<=========== kill this field
^DD(442.01,8,21,0)=^^2^2^3050809^ ^DD(442.01,8,21,1,0)=This is the Federal
Supply Classification for an item, or the Product ^DD(442.01,8,21,2,0)=Service
Code for a service. ^DD(442.01,8,"DT")=3050809", "", "", "2011/01/10"], ["4871", "REMOTE DATA HL7 REQUEST/RESPONSE", "Other", "804", "2006/07/26", "APPROVED", "Active", "Private", "", "
This DBIA is intended to document the transmission of
data from CDS (Clinical Data Service) located on a server in the AAC (Austin
Automation Center) to the OE/RR package running on servers located at each VA
Medical Center.\n
The OE/RR package uses the direct connect API of the MESSAGING package to send
a request HL7 message to CDS. This message sends as parameters the patient
ICN, a domain specific "What Code", a date range that specifies what dates are
acceptable for the data that will be returned by CDS. The request HL7 SPR
segment is in the following format: (variables surrounded in _"VARIABLE"_)\n
SPR^XWBDRPC845-569716_0^T^ZREMOTE RPC^@SPR.4.2~003RPC017ORWRP REPORT
TEXT&006RPCVER0010&007XWBPCNT0017&007XWBESSO066321214321\\F\\
\\F\\\\F\\657\\F\\48102&007XWBDVER0011&006XWBSEC0043.14&002P10187369543;
_"ICN"_&002P2055_"WHAT CODE"_;1\\S\\RXOP;ORDV06;28;200&002P3000&002P4
000&002P5000&002P6007_"START DATE"_&002P7000_"END DATE"_\n\n
CDS then returns the requested data by sending a response HL7 message that is
handed to OE/RR by the MESSAGING package API. The definition of how the
return data is formated is specified by the following RDF segment for each
domain:\n
ALLERGIES
=========
RDF^12^Standardized~ST~1|Facility Name~ST~30|Entered in Error~ST~2 |Allergy
Type~CE~45|GMR Allergy~CE~450|Agent~ST~30|Reaction~CE~430 |Drug
Classes~CE~190|Drug Ingredients~CE~190|Verification Date~TS~ 26
|Observed/Historical Flag~CE~150|Comments~ST~255\n
OUTPATIENT PHARMACY
===================
RDF^17^Standardized~ST~1|Pharmacy Division~ST~30|Drug~CE~370|NDC Drug~CE~65|Rx
Number~ST~20|Order Status Modifiers~CWE~180|Quantity in Rx~NM~10|Days
Supply~NM~10|Expire/Cancel Date~TS~26|Issue Date~ TS~26|Last Fill Date~TS~26|
Refills Remaining~NM~10|Provider~ST~80| Cost to Fill Rx~MO~10|SIG~ST~250|
Station Number~IS~3|Primary Facility~ST~30", "", "", ""], ["4872", "SURGERY PROCEDURE/DIAGNOSIS CODES", "File", "SURGERY", "2006/08/02", "APPROVED", "Active", "Controlled Subscription", "136", "
This integration agreement grants read access to
Surgery case coding information from the SURGERY PROCEDURE/DIAGNOSIS CODES
file (#136).", "", "", "2012/05/24"], ["4873", "Blood Bank", "File", "VBECS", "2006/08/22", "APPROVED", "Active", "Private", "63", "
Accessing the "BB" node of the Lab Data file (#63).", "", "", ""], ["4874", "BLOOD PRODUCT", "File", "VBECS", "2006/08/22", "APPROVED", "Active", "Private", "66", "", "", "", ""], ["4875", "Return exam date/time for interpreted non-cancelled case.", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2006/08/16", "APPROVED", "Active", "Private", "", "
This patient specific VistA Radiology/Nuclear Medicine
function will return to VistA MPI the exam date/time (in FileMan internal
format) of the most recent non-cancelled and interpreted case.\n
Please note that an interpreted case usually implies that a provider has
transcribed the report. This IA will also consider a "stub" report to be
interpreted for the purposes of this IA.\n
A "stub" report has the following characteristics:
--------------------------------------------------
1) The ACTIVITY LOG (#100) indicates that images were collected via VistA
Imaging 2) The REPORT STATUS (#5) field of the report record is
null 3) The report record points to an image record in
the IMAGE (#2005)
file 4) No IMPRESSION TEXT (#300) exists for the report
record 5) No PROBLEM STATEMENT (#25) exists for the
report
record 6) No REPORT TEXT (#200) exists for the report
record", "", "RAO7UTL1", ""], ["4876", "PRODUCTION DIET file (#116.2)", "File", "DIETETICS", "2006/08/22", "APPROVED", "Active", "Private", "116.2", "
Production Diet File (#116.2) is pointed to via a
variable pointer field from DSS file (#728.45).", "", "", ""], ["4877", "SUPPLEMENTAL FEEDINGS FILE (#118)", "File", "DIETETICS", "2006/08/22", "APPROVED", "Active", "Private", "118", "
Supplemental Feedings file (#118) is pointed to via a
variiable pointer field in DSS file (#728.45).", "", "", ""], ["4878", "TUBEFEEDING FILE (#118.2)", "File", "DIETETICS", "2006/08/22", "APPROVED", "Active", "Private", "118.2", "
Tuebefeeding file (#118.2) is pointed via a variable
pointer field in DSS file (#728.45).", "", "", ""], ["4879", "IA for IFCAP patch PRC*5.1*103 to read Prosthetic File 664", "Routine", "PROSTHETICS", "2006/08/09", "APPROVED", "Active", "Private", "", "
This integration agreement will allow IFCAP to read
Prosthetics File 664 as part of IFCAP patch PRC*5.1*103.", "", "PRCHL6", ""], ["4880", "STANDING ORDERS FILE (#118.3)", "File", "DIETETICS", "2006/08/22", "APPROVED", "Active", "Private", "118.3", "
Standing Orders file (#118.3) is pointed via a variable
pointer field in DSS file (#728.45).", "", "", ""], ["4881", "PRODUCTION FACILITY FILE (#119.71)", "File", "DIETETICS", "2006/08/22", "APPROVED", "Active", "Private", "119.71", "
Production Facility file (#119.71) is pointd via a
variable pointer field in DSS file (#728.46).", "", "", ""], ["4882", "SERVICE POINT FILE (#119.72)", "File", "DIETETICS", "2006/08/09", "APPROVED", "Active", "Private", "119.72", "
Service Point file (#119.72) ia pointed to via a
variable pointer field in DSS file (#728.46).", "", "", ""], ["4883", "FHDSSAPI", "Routine", "DIETETICS", "2006/09/06", "APPROVED", "Active", "Private", "", "
DATA^FHDSSAPI was created to extract N&FS data.", "", "FHDSSAPI", ""], ["4884", "NUTRITION LOCATION FILE (#119.6)", "File", "DIETETICS", "2006/08/09", "APPROVED", "Active", "Private", "119.6", "
Nutrition Location file (#119.6) is referenced via DSS
routine ECXUTL6.", "", "", ""], ["4885", "SERVICE POINT", "File", "DIETETICS", "2006/08/22", "APPROVED", "Active", "Private", "119.72", "
Serivce Point file (#119.72) is referenced via
Filemadn GET1^DIQ calls in ECXUTL6 DSS routine.", "", "", ""], ["4886", "UPDATE PATIENT ADDRESSES", "Routine", "REGISTRATION", "2006/08/28", "APPROVED", "Active", "Controlled Subscription", "", "
This API allows the user to update a patient's mailing
or temporary address.", "", "DGADDUTL", ""], ["4887", "Use of STD_INSTITUTION table in PATS application", "SQL Table", "807", "2006/08/21", "APPROVED", "Active", "Private", "", "
This integration agreement describes the use of the
std_institution table and fields within the PATS application's Oracle
database.\n
When the first test site goes to production with PATS, the EMC will be using
version 11 of the SDS database.", "", "", "2006/09/23"], ["4888", "Use of STD_INSTITUTION table in PATS Data Migration", "SQL Table", "807", "2006/08/22", "APPROVED", "Active", "Private", "", "
This integration agreement describes the use of the
Standard Data Services std_institution table and fields within the PATS data
migration application. This agreement is in force only until the PATS
application has been rolled out nationally to all sites.\n
When the first test site goes to production with PATS, the EMC will be using
version 11 of the SDS database.", "", "", "2006/09/23"], ["4889", "Use of STD_RACE table in PATS Application", "SQL Table", "807", "2006/08/22", "APPROVED", "Active", "Private", "", "
This integration agreement describes the use of the
Patient Services std_race table and fields within the PATS application's
Oracle database (distributed by Standard Data Services)\n
When the first test site goes to production with PATS, the EMC will be using
version 11 of the SDS database.", "", "", "2006/09/23"], ["4890", "Use of STD_ETHNICITY table in PATS Application", "SQL Table", "807", "2006/08/22", "APPROVED", "Active", "Private", "", "
This integration agreement describes the use of the
Patient Services std_ethnicity table and fields within the PATS application's
Oracle database. (distributed by Standard Data Services)\n
When the first test site goes to production with PATS, the EMC will be using
version 11 of the SDS database.", "", "", "2006/09/23"], ["4891", "Use of STD_RACE table in PATS Data Migration", "SQL Table", "807", "2006/08/22", "APPROVED", "Active", "Private", "", "
This integration agreement describes the use of the
Patient Services std_race table and fields within the PATS data migration
application. This agreement is in force only until the PATS application has
been rolled out nationally to all sites. (distributed by Standard Data
Services)\n
When the first test site goes to production with PATS, the EMC will be using
version 11 of the SDS database.", "", "", "2006/09/26"], ["4892", "Use of STD_ETHNICITY table in PATS Data Migration", "SQL Table", "807", "2006/08/22", "APPROVED", "Active", "Private", "", "
This integration agreement describes the use of the
Patient Services std_ethnicity table and fields within the PATS data migration
application. This agreement is in force only until the PATS application has
been rolled out nationally to all sites. (distributed by Standard Data
Services)\n
When the first test site goes to production with PATS, the EMC will be using
version 11 of the SDS database.", "", "", "2006/09/25"], ["4893", "ORQQVI1 GRID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/07", "APPROVED", "Active", "Controlled Subscription", "", "
Returns vitals data for a patient to the cover sheet.", "ORQQVI1 GRID", "", ""], ["4894", "FATKAAT TEST ENTRY", "Other", "KERNEL", "2006/08/25", "APPROVED", "Active", "Supported", "", "
Integration agreement to list the components in FATKAAT
that will be exposed for integration.", "", "", ""], ["4895", "ADD PATIENT RELATION INFO FROM HEC", "File", "REGISTRATION", "2006/08/29", "APPROVED", "Active", "Private", "408.12", "\n\n
The following Integration Agreement is granted to allow the Write access IVM
makes into the Patient Relation file (408.12).\n
FIELD FIELD NUMBER NAME\n
.01 PATIENT (RP2'X), [0;1] Fileman and Direct
global Writes\n
.02 RELATIONSHIP (R*P408.11'), [0;2] Fileman and Direct
global Writes\n
.03 PERSON (RVX), [0;3] Direct global Write\n
75 EFFECTIVE DATE (Multiple-408.1275), [E;0]
.01 EFFECTIVE DATE (RDX), [0;1] Fileman and Direct
global Writes
.02 ACTIVE (RS), [0;2] Direct global Write
.03 FILED BY IVM (S), [0;3] Direct global Write
.04 IVM TEST (P408.31'), [0;4] Direct global Write\n\n\n\n
IVM is granted the following Read access into the Patient Relation file
(408.12):\n
Read access to the "B" cross reference.\n\n
FIELD FIELD NUMBER NAME\n
75 EFFECTIVE DATE (Multiple-408.1275), [E;0]
.03 FILED BY IVM (S), [0;3] Direct global Read
.04 IVM TEST (P408.31'), [0;4] Direct global Read", "", "", "2006/11/29"], ["4896", "CPT CATEGORY FILE 81.1 'B' CROSS REFERENCE", "File", "1", "2007/04/04", "APPROVED", "Active", "Private", "81.1", "
The "B" cross-reference for the CPT Modifier file 81.1
needs to be extended to the maximum 63 characters to ensure uniqueness in the
index. This file is pointed to only by the CPT file 81 and itself.\n
New Set/Kill logic:\n
S ^DIC(81.1,"B",$E(X,1,63),DA)=""
K ^DIC(81.1,"B",$E(X,1,63),DA)\n", "", "", "2007/04/04"], ["4897", "MAG access top-level and BUILD COMPONENTS data", "File", "KERNEL", "2006/09/05", "APPROVED", "Active", "Controlled Subscription", "9.6", "
Imaging is reading the ALPHA/BETA TESTING field #20 to
utilize a Version Control function that will not allow versions of Imaging
client software to connect to the DataBase if they are no longer supported.\n
- If the Server Version (that will not support Client X) is in Alpha/Beta
status, Client X will be shown a warning message. - If the Server Version
(that will not support Client X) is Released, Client X will be forced to
abort.\n
Update June 23rd 2022:
----------------------
This Integration Agreement (IA) has been updated to access the BUILD
COMPONENTS sub-file for routine components. The VistA Imaging (VI) application
will use the $$FIND1^DIC to lookup the VI build.\n
VI will use the GETS^DIQ VA FileMan utility to return data specific to the
routine BUILD COMPONENTS (#9.67).", "", "", "2022/07/06"], ["4898", "ORQQPX REMINDERS LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/07", "APPROVED", "Active", "Controlled Subscription", "", "
In support of the BCE project, Care Fusion's wCareView
software is using ORQQPX REMINDERS LIST to obtain a list of reminders for a
patient.", "ORQQPX REMINDERS LIST", "", ""], ["4899", "ORQQPXRM REMINDER DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/07", "APPROVED", "Active", "Controlled Subscription", "", "
In support of the BCE project, CareFusion's wCareView
software (MJCF) will be using the ORQQPXRM REMINDER DETAIL rpc to obtain
details about clinical reminders. This integration agreement with OR
represents an interim solution to meet MJCF's need for reminder detail. At
some point in the future, Clinical Reminders will create a dedicated RPC for
this purpose. At that time, this agreement will be replaced with a new
agreement for the deciated RPC.", "ORQQPXRM REMINDER DETAIL", "", ""], ["4900", "ORWCV DTLVST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/11", "APPROVED", "Active", "Controlled Subscription", "", "
MJCF will dislpay progress note and discharge summary
data returned by this RPC call.", "ORWCV DTLVST", "", ""], ["4901", "ORWLRR GRID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/11", "APPROVED", "Active", "Controlled Subscription", "", "
Returns data for display of labs on grid controls", "ORWLRR GRID", "", ""], ["4902", "OBTAIN FILLS, REFILLS, PARTIAL FILLS FROM PRESCRIPTION FILE", "Routine", "OUTPATIENT PHARMACY", "2006/09/13", "APPROVED", "Active", "Supported", "", "
This ICR is provided by Outpatient Pharmacy as an API
to extract information related to original prescription fills, refills, and
partial fills. This API is to be used by all packages needing to retrieve
data from the "AD", "AL", and "AM" cross references and the "STA" and "PARK"
nodes in the PRESCRIPTION file (#52).", "", "PSO52EX", "2021/11/15"], ["4903", "PATIENT RECORD FLAG DATA RETRIEVAL", "Routine", "REGISTRATION", "2011/01/06", "APPROVED", "Active", "Controlled Subscription", "", "
These API's provide a means to retrieve detailed
Patient Record Flag information by patient and patient record flag, and, to
retrieve a list of patients with a specific assigned patient record flag
during a specified date range.", "", "DGPFAPIH", "2011/06/07"], ["4904", "ORWPT BYWARD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/27", "APPROVED", "Active", "Controlled Subscription", "", "
MJCF will use this RPC in the wCareView application in
support of the BCE project.", "ORWPT BYWARD", "", ""], ["4905", "ORWPT DIEDON", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/27", "APPROVED", "Active", "Controlled Subscription", "", "
MJCF will use this RPC in the wCareView application in
support of the BCE project.", "ORWPT DIEDON", "", ""], ["4906", "ORWPT FULLSSN", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/27", "APPROVED", "Active", "Controlled Subscription", "", "
MJCF will use this RPC in the wCareView application in
support of the BCE project.", "ORWPT FULLSSN", "", ""], ["4907", "ORWPT SELECT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/27", "APPROVED", "Active", "Controlled Subscription", "", "
MJCF will use this RPC in the wCareView application in
support of the BCE project.\n
The following is the current production return array for this RPC\n
SELECT(REC,DFN) ; Selects patient & returns key information
1 2 3 4 5 6 7 8 9 10 11 12
NAME^SEX^DOB^SSN^LOCIEN^LOCNM^RMBD^CWAD^SENSITIVE^ADMITTED^CONV^SC^\n
13 14 15 16 17
SC%^ICN^AGE^TS^TSSVC\n
The RPC will be updated when CPRS GUI v33SWD, OR*3.0*608 is released in early
2024.\n
1 2 3 4 5 6 7 8 9 10 11 12
NAME^SEX^DOB^SSN^LOCIEN^LOCNM^RMBD^CWAD^SENSITIVE^ADMITTED^CONV^SC^\n
13 14 15 16 17 18 19
SC%^ ICN^AGE^TS^TSSVC^SIGI^PRONOUN", "ORWPT SELECT", "", ""], ["4908", "ORWU PATCH", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/09/27", "APPROVED", "Active", "Controlled Subscription", "", "
MJCF will use this RPC in the wCareView application in
support of the BCE project.", "ORWU PATCH", "", ""], ["4909", "DILOCKTM", "Other", "1", "2006/09/27", "APPROVED", "Active", "Controlled Subscription", "", "
Access to the ^DD("DILOCKTM") global and the setting of
the DILOCKTM variable.", "", "", ""], ["4910", "DBIA4910", "Routine", "OUTPATIENT PHARMACY", "2006/09/29", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement provides CMOP an entry point to
determine if the patient has a known bad address and no active temporary
address.", "", "PSOBAI", ""], ["4911", "TAXONOMY UTILITIES", "Routine", "KERNEL", "2006/09/29", "APPROVED", "Active", "Controlled Subscription", "", "
APIs to facilitate retrieval of Taxonomy Code
information from VistA NEW PERSON file (#200) and the INSTITUTION file (#4).\n", "", "XUSTAX", ""], ["4912", "LEXICON CONCEPT DATA FOR CODE", "Routine", "LEXICON UTILITY", "2006/10/05", "APPROVED", "Active", "Supported", "", "
This API will return an array of data for a given code,
code source, optional date, and optional return array name. The data returned
will include:
code
hierarchy or subset (if available)
version (if available)
legacy code (if available)
code status
fully specified name (if available)
preferred term
any applicable synonyms\n
If any of the data in the passed parameters data is incorrect or
unrecognizable, the API will return an error message indicating the nature of
the error. If no date is specified, then the date will default to the current
system date. This API was developed specifically for the SNOMED CT code
system in support of the LDSI project, but is applicable to any code system.\n", "", "LEXTRAN", ""], ["4913", "LEXICON CONCEPT DATA FOR TEXT", "Routine", "LEXICON UTILITY", "2006/10/05", "APPROVED", "Active", "Supported", "", "
This API will return an array of data for a given text,
optional code source, optional date, optional subset, and optional return
array name. The API will display a pick list based on the parameters passed
and allow a user to select an item from the list. The API will then return the
array for the item selected. The data returned will include:
code
hierarchy or subset (if available)
version (if available)
legacy code (if available)
code status
fully specified name (if available)
preferred term
any applicable synonyms\n
If any of the data in the passed parameters data is incorrect or
unrecognizable, the API will return an error message indicating the nature of
the error. If no date is specified, then the date will default to the current
system date. This API was developed specifically for the SNOMED CT code
system in support of the LDSI project, but is applicable to any code system.", "", "LEXTRAN", ""], ["4914", "LEXICON VALIDATE CODE FOR SOURCE", "Routine", "LEXICON UTILITY", "2006/10/05", "APPROVED", "Active", "Supported", "", "
This API will return an array for a given text and code
system indicating whether the text is valid for the specified code system. The
data array returned will include the following:
An indicator of whether the text is valid for the code system
The code in the code system to which the text,if valid for code system,
belongs. If any of the passed parameters are incorrect or
unrecognizable, the API will return an error message indicating the nature of
the error.\n", "", "LEXTRAN", ""], ["4915", "Access to HL Logical Link (#870) file", "File", "HEALTH LEVEL SEVEN", "2006/10/11", "APPROVED", "Active", "Private", "870", "", "", "", ""], ["4916", "HL7 Message Administration (#773) file access", "File", "HEALTH LEVEL SEVEN", "2006/10/11", "APPROVED", "Active", "Private", "773", "", "", "", ""], ["4917", "HL MESSAGE TEXT (#772) file access", "File", "HEALTH LEVEL SEVEN", "2006/10/11", "APPROVED", "Active", "Private", "772", "", "", "", ""], ["4918", "HL7 Application Parameter (#771) file access", "File", "HEALTH LEVEL SEVEN", "2006/10/11", "APPROVED", "Active", "Private", "771", "", "", "", ""], ["4919", "Communication Server Parameter (#869.3) file access", "File", "HEALTH LEVEL SEVEN", "2006/10/11", "APPROVED", "Active", "Private", "869.3", "", "", "", ""], ["4920", "NUTRITION PERSON file", "File", "DIETETICS", "2006/10/11", "", "Other", "Controlled Subscription", "115.01", "
The Spinal Cord package would like to request direct
access to the following fields of the NUTRITION PERSON file (#115) for
reporting purposes:\n
^FHPT(D0,"A",D1,0)\n
9 ISOLATION/PRECAUTION 0;10 Direct Global Read\n
10 OE/RR ISOLATION ORDER 0;13 Direct Global Read\n
^FHPT(D0,"A",D1,"TF",D2,0)\n
.01 TUBEFEEDING 0;1 Direct Global Read & w/Fileman\n
^FHPT(D0,"A",D1,"TF",D2,"P",D3,0)\n
.01 TF PRODUCT 0;1 Direct Global Read & w/Fileman\n
^FHPT(D0,"S",D1,0)\n
1 STATUS 0;2 Direct Global Read & w/Fileman\n
11/23/21 - VO ICR Team modified to AIS and B x-ref, and COMPREHENSIVE CARE
COORDINATION (C3) as a subscriber", "", "", ""], ["4921", "VAFCSB APIS", "Routine", "REGISTRATION", "2006/10/11", "APPROVED", "Active", "Controlled Subscription", "", "
These APIs are used to include the Primary View
Criteria to the MPI for use in scoring the validity of the update.", "", "VAFCSB", ""], ["4922", "ORDER HL7 MESSAGE ESCAPE API", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2006/10/23", "APPROVED", "Active", "Supported", "", "
This DBIA describes the API that OE/RR has created to
escape and unescape HL7 messages that are sent back and forth between CPRS and
it's ancillary packages.", "", "ORHLESC", ""], ["4923", "Global DD sets to New Person (#200) file", "File", "1", "2006/10/23", "APPROVED", "Active", "Private", "200", "
Person Services is setting the following DD nodes for
the VPID (#9000) field in the New Person (#200) file in a post init routine:\n
^DD(200,9000,0)="VPID^F^^VPID;1^K:$L(X)>29!($L(X)<23) X"
^DD(200,9000,3)="Answer must be 23-29 characters in length."
^DD(200,9000,"DT")=DT", "", "", ""], ["4924", "Calls to routine TIULC1", "Routine", "TEXT INTEGRATION UTILITIES", "2006/10/24", "APPROVED", "Active", "Private", "", "
Administratively closure of a consult", "", "TIULC1", ""], ["4925", "DIRECT READ TO KMPTMP(", "File", "CAPACITY MANAGEMENT TOOLS", "2006/11/28", "APPROVED", "Active", "Controlled Subscription", "", "
The value of ^KMPTMP("KMPD-CPRS") indicates whether the
coversheet collection is currently running (value=1) or stopped (value=0).\n
The value of ^KMPTMP("KMPD-CPRS") is set in SST+11^KMPDSS.\n
The subscribing package is allowed a direct read of the global
^KMPTMP("KMPD-CPRS") in order to determine the state of coversheet collection.\n", "", "", ""], ["4926", "ORWPS COVER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/12/04", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWPS COVER", "", "2015/04/30"], ["4927", "ORWPS DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2006/12/04", "APPROVED", "Active", "Controlled Subscription", "", "
MJCF will use this RPC in the wCareView application in
support of the BCE project.", "ORWPS DETAIL", "", ""], ["4928", "DATA RETRIEVAL FROM FILE 55", "Routine", "PHARMACY DATA MANAGEMENT", "2006/11/24", "APPROVED", "Active", "Supported", "", "
This DBIA is provided by Pharmacy Data Management (PSS)
as an API to do data retrieval from File 55 using various methods.", "", "PSS55MIS", ""], ["4929", "CLINIC STOP file", "File", "SCHEDULING", "2006/11/07", "APPROVED", "Active", "Controlled Subscription", "40.7", "
The Spinal Cord package would like to request direct
global access to the B cross-reference of the CLINIC STOP file (#40.7) for
reporting purposes", "", "", ""], ["4930", "OUTPATIENT DIAGNOSIS file", "File", "SCHEDULING", "2006/11/28", "APPROVED", "Active", "Controlled Subscription", "409.43", "
The Spinal Cord package would like to request direct
global access to the following field of the OUTPATIENT DIAGNOSIS file
(#409.43) for reporting purposes:\n
^SDD(409.43,"AO",D0,D1)\n
.01 DIAGNOSIS 0;1 direct global read", "", "", ""], ["4931", "NATURE OF ORDER", "File", "ORDER ENTRY/RESULTS REPORTING", "2006/11/28", "APPROVED", "Active", "Private", "100", "
Subscribing package has a permission to access the
(#100) file as described in this DBIA.", "", "", ""], ["4932", "ANNUAL MEANS TEST FILE", "File", "REGISTRATION", "2006/11/29", "APPROVED", "Active", "Private", "408.31", "\n\n
The following Integration Agreement is granted to allow the access IVM makes
into the Annual Means Test file (408.31).\n\n
FIELD FIELD NUMBER NAME\n
.23 SOURCE OF INCOME TEST (RP408.34'), [0;23] Direct global Read\n\n\n
IVM is granted the following access to the Annual Means Test file (408.31):\n\n
FIELD FIELD NUMBER NAME\n
.01 DATE OF TEST (RDX), [0;1] Direct global Read\n", "", "", "2006/11/29"], ["4933", "ACCESS REGISTRATION MEANS TEST CODE", "Routine", "REGISTRATION", "2006/11/29", "APPROVED", "Active", "Private", "", "\n\n
The following Integration Agreement is granted to allow the access IVM makes
to Registration Means Test code.\n
SET^DGMTAUD is invoked by IVM when a relationship entry is made in the Patient
Relation file (408.12). SET^DGMTAUD makes an entry in the Means Test Changes
file (408.41) to record the change to the Patient Relation file.", "", "DGMTAUD", "2006/11/29"], ["4934", "SOURCE OF INCOME TEST FILE", "File", "REGISTRATION", "2006/11/29", "APPROVED", "Active", "Private", "408.34", "\n\n
IVM is granted the following access to the Source Of Income Test file
(408.34):\n\n
FIELD FIELD NUMBER NAME\n
.01 NAME (RF), [0;1] Direct global Read", "", "", "2006/11/29"], ["4935", "Use of AD xref in file 8930", "File", "AUTHORIZATION/SUBSCRIPTION", "2006/12/04", "", "Expired", "Private", "8930", "
CPRS requests the ability to do a direct global read of
the AD cross-reference of file 8930. The OR ALLERGY ENTERED IN ERROR
parameter has identified CLASS as one of the entity levels that can be set for
this parameter.\n
Because a user can belong to multiple classes and multiple classes can have
values in this parameter, the AD cross-reference is used to determine the
"parent" class of the class that is set in the parameter. The child class is
used to identify whether a user can or cannot mark an allergy as entered in
error. As a result, all higher level (parent) classes are removed from
consideration when determining if the user can take the action. If more than
one child class has a value then those will be compared against each other and
any "yes" value will allow the user to mark an allergy as entered in error.\n
This is a temporary agreement until The Authorization/Subsciption utility is
able to write an API to provide the above funtionality in a standardized way.", "", "", ""], ["4936", "UPDATE ORDERABLE ITEM FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2006/12/14", "APPROVED", "Active", "Private", "101.43", "
This is a one-time usage only to enable Pharmacy Data
Management to update the CPRS Orderable Item file with the default medication
route information.", "", "", ""], ["4937", "DBIA4937", "File", "REGISTRATION", "2011/01/10", "APPROVED", "Active", "Private", "10", "
Read access of the Race file using the 'B'
cross-reference.", "", "", "2011/08/02"], ["4938", "PATIENT file", "File", "REGISTRATION", "", "APPROVED", "Active", "Private", "2", "
The Spinal Cord package would like to request direct
global access to the following fields of the PATIENT file (#2) for reporting
purposes:\n
^DPT(D0,57)\n
57.4 SPINAL CORD INJURY 57;4\n
^DPT(D0,"MPI")\n
991.01 INTEGRATION CONTROL NUMBER MPI;1\n
^DPT("AICN",D0,D1) - Cross-reference to lookup DFN based on ICN", "", "", "2007/02/01"], ["4939", "AVOID NPI DUPLICATES", "File", "INTEGRATED BILLING", "2008/03/18", "", "Other", "Private", "355.93", "
When entering/editing an NPI to an entry in the NEW
PERSON file (#200), the INSTITUTION file (#4) or the IB NON/OTHER VA BILLING
PROVIDER file (#355.93), Kernel needs to check if the NPI is already used by
an entry in any of the three files. If the NPI is already used, Kernel will
issue either an error or a warning message, depending on which file is
currently being edited.\n
An NPI used by an entry in file 4 cannot be used in an entry in either of the
other files regardless of whether the NPI is 'active' or 'inactive'. An NPI
can be used in a single entry in both file 200 and file 355.93 at the same
time, but a warning is issued in that case.", "", "", "2007/02/01"], ["4940", "DBIA4940", "File", "REGISTRATION", "2011/01/10", "APPROVED", "Active", "Private", "10.2", "
Read access of the Ethnicity file using the "B"
cross-reference.", "", "", "2011/08/02"], ["4941", "MEANS TEST STATUS file", "File", "REGISTRATION", "2006/12/11", "APPROVED", "Active", "Controlled Subscription", "408.32", "
The Spinal Cord package would like to request direct
global access to the following field of the MEANS TEST STATUS File for
reporting purposes:\n
^DG(408.32,D0,0)\n
.01 NAME 0;1 Direct global read", "", "", "2007/03/05"], ["4942", "PATIENT MOVEMENT file", "File", "REGISTRATION", "2006/12/11", "APPROVED", "Active", "Private", "405", "
The Spinal Cord package would like to request Direct
Global access to the following fields of the Patient Movement file (#405) for
reporting purposes:\n
^DGPM("APRD",D0) - APRD Cross-reference\n
^DGPM("B",D0,D1) - B Cross-reference\n
^DGPM(D0,0)\n
.01 DATE/TIME 0;1 Direct global read .02 TRANSACTION
0;2 Direct global read .03 PATIENT
0;3 Direct global read .05 TRANSFER FACILITY 0;5 Direct
global read .06 WARD LOCATION 0;6 Direct global read .07
ROOM-BED 0;7 Direct global read .08 PRIMARY PHYSICIAN
0;8 Direct global read .09 FACILITY TREATING SPECIALTY 0;9
Direct global read .14 ADMISSION/CHECK-IN MOVEMENT 0;14 Direct global
read .19 ATTENDING PHYSICIAN 0;19 Direct global read .24
RELATED PHYSICAL MOVEMENT 0;24 Direct global read", "", "", "2007/03/04"], ["4943", "TREATING FACILITY LIST", "File", "REGISTRATION", "2006/12/11", "APPROVED", "Active", "Private", "391.91", "
The Spinal Cord Package would like to request direct
global access to the following fields of the Treating Facility List file
(#391.91) for reporting purposes:\n
^DGCN(391.91,"B",D0,D1) - B Cross-reference\n
^DGCN(391.91,D0,0)\n
.02 INSTITUTION 0;2 Direct global read .03 DATE LAST
TREATED 0;3 Direct global read", "", "", "2007/03/04"], ["4944", "SOURCE OF ADMISSION", "File", "REGISTRATION", "2006/12/11", "APPROVED", "Active", "Private", "45.1", "
The Spinal Cord package would like to request direct
global access to the following fields of the Source Of Admission file (#45.1)
for reporting purposes:\n
^DIC(45.1,D0,0)\n
.01 PTF CODE 0;1 Direct global read 2 NAME 0;2
Direct global read", "", "", "2007/03/04"], ["4945", "PTF file", "File", "REGISTRATION", "2006/12/11", "APPROVED", "Active", "Private", "45", "
The Spinal Cord package would like to request direct
global access to the following fields of the PTF file (#45) for reporting
purposes:\n
^DGPT("AF",D0,D1) - AF Cross-reference\n
^DGPT(D0,0)\n
.01 PATIENT 0;1 Direct global access 3 FACILITY
0;3 Direct global access 4 FEE BASIS 0;4 Direct global
access\n
^DGPT(D0,70)\n
75 PLACE OF DISPOSITION 70;6 Direct global access 76.1 RECEIVING
FACILITY 70;12 Direct global access\n
^DGPT(D0,101)\n
20 SOURCE OF ADMISSION 101;1 Direct global access\n
^DGPT(D0,"AP",D1)\n
.01 PROCEDURE 1 401P;1 Direct global access .02 PROCEDURE 2
401P;2 Direct global access .03 PROCEDURE 3 401P;3 Direct global
access .04 PROCEDURE 4 401P;4 Direct global access .05 PROCEDURE
5 401P;5 Direct global access", "", "", "2007/03/04"], ["4946", "SPECIALTY file", "File", "REGISTRATION", "2006/12/12", "APPROVED", "Active", "Private", "42.4", "
The Spinal Cord package would like to request direct
access to the B cross-reference of the Specialty file (#42.4) for reporting
purposes.\n
^DIC(42.4,"B",D0) - B Cross-reference", "", "", "2007/03/04"], ["4947", "PATIENT ENROLLMENT", "File", "REGISTRATION", "2006/12/12", "APPROVED", "Active", "Private", "27.11", "
The Spinal Cord package would like to request direct
global access to the following fields of the Patient Enrollment file (#27.11)
for reporting purposes:\n
^DGEN(27.11,"C",D0,D1) - C Cross-reference\n
^DGEN(27.11,D0,0)\n
.07 ENROLLMENT PRIORITY 0;7 Direct global read .12 ENROLLMENT
SUBGROUP 0;12 Direct global read\n
^DGEN(27.11,D0,"E")\n
50.14 MEANS TEST STATUS E;14 Direct global read", "", "", "2007/03/05"], ["4948", "Person Service enumeration", "File", "KERNEL", "2007/04/23", "APPROVED", "Withdrawn", "Private", "200", "\n
XU*8.0*331 is being deployed in conjunction with the ongoing transition
to HealtheVet VistA. Interdependencies include current and future
HealtheVet applications and services.\n
Health Systems Design & Development Common Services Person Service
has been tasked with standing up an Administrative Data Repository
(ADR) that will store identification data. Each person will be
enumerated with a unique identifier called a VPID (VA Person ID). The
first person data to be enumerated - prior to migrating the data to
the ADR will be entries in the NEW PERSON file (#200).", "", "", ""], ["4949", "ACCESS TO STANDARDIZED INSTITUTION FILE", "SQL Table", "807", "2007/01/25", "", "Pending", "Private", "", "
The VPFS package accesses the SDS tables in a View.", "", "", ""], ["4950", "DBIA4950", "SQL Table", "807", "", "", "Pending", "Private", "", "", "", "", ""], ["4951", "VPFS consumption of PSL API", "Other", "INTEGRATED PATIENT FUNDS", "2006/12/14", "APPROVED", "Active", "Private", "", "
The VPFS package consumes the Common Service PSL.", "", "", ""], ["4952", "VPFS consumption of PSC API", "Other", "INTEGRATED PATIENT FUNDS", "2006/12/14", "APPROVED", "Active", "Private", "", "
The VPFS package consumes the Common Service PSC.", "", "", ""], ["4953", "DBIA4953", "File", "VBECS", "", "APPROVED", "Active", "Private", "6002.03", "
This integration agreement allows the DSS EXTRACTS
package access to the VBECS DSS EXTRACT file (#6002.03).", "", "", "2007/03/04"], ["4954", "ORWPS ACTIVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2008/03/12", "APPROVED", "Active", "Controlled Subscription", "", "
IA to allow usage of the ORWPS ACTIVE rpc by Care
Fusion's wCareView COTS product. wCareView is part of the Bar Code
Enhancements project...more info available at:
http://vaww1.REDACTED/pcs/page.cfm?pg=64", "ORWPS ACTIVE", "ORWPS", "2008/03/25"], ["4955", "ELECTRONIC SIGNATURE", "Other", "ELECTRONIC SIGNATURE", "", "APPROVED", "Active", "Supported", "", "
As HealtheVet-VistA developers migrate VistA
applications to modern technologies, interim solutions may be required until
enterprise solutions are mature and stable. The Electronic Signature (ESig)
service provides an interim solution for the use of electronic codes in place
of wet signatures while HealtheVet-VistA s security infrastructure and
architecture are being defined. The service duplicates for Java applications
(J2EE or J2SE) the Kernel 8.0 electronic signature functionality currently
used by VistA/M applications.\n
ESig furnishes a standard, consistent set of APIs that HealtheVet-VistA
developers can implement to provide users access to electronic signature data
stored on VistA/M systems. ESig APIs make calls from Java applications to
VistA/M systems to retrieve, validate, and store office phone, etc.).
Additional Java APIs provide encoding/decoding, hash, and checksum calculation
utilities, but do not interact with the VistA/M system.\n
This integration agreement describes the supported ESig Java APIs that are
contained in the esig-x.x.x.xxx.jar file. This JAR file can be included in a
HealtheVet package distribution.\n
SUMMARY\n
JAR: esig-x.x.x.xxx.jar
Package: gov.va.med.esig.utilities\n
Class: ESigDataAccess
Methods: isDefined
getESigCode
saveESigCode
getESigData
saveESigData\n
Class: ESigEncryption
Methods: checksum
encrypt
decrypt
hash\n
Class: ESigValidation
Methods: isValid
isValidFormat", "", "", ""], ["4956", "VBECS DSS EXTRACT", "Remote Procedure", "VBECS", "2007/01/09", "APPROVED", "Active", "Private", "", "
This RPC inserts or updates post transfusion related
data in the VBECS DSS EXTRACT file (#6002.03). The data is passed into the
VBECDSS routine through the input parameters and a success indicator is
returned to the Blood Bank medical device.\n
INPUT PARAMETER DESCRIPTION:
PARAMS("TRANSACTION ID") = Unique record identifier
PARAMS("DFN") = Patient identifier
PARAMS("FACILITY") = Institution identifier
PARAMS("PHYSICIAN") = Provider requesting blood product for transfusion
PARAMS("ORDERING PROVIDER") = Provider who ordered Type and Crossmatch
PARAMS("PRODUCT NAME") = Short blood product name
PARAMS("COMPONENT ABBREVIATION") = Abbreviation of blood component
PARAMS("NUMBER OF UNITS") = Number of pooled units transfused
PARAMS("TRANSFUSION DATE") = Date/time of transfusion
PARAMS("VOLUME") = Total volume of units transfused
PARAMS("REACTION TYPE") = Type of reaction indicated
PARAMS("UNIT MODIFICATION") = String of codes representing modifications
done on units transfused. String cannot exceed 6 character.
D = Deglycerolize
F = Freeze
I = Irradiate
L = Leukoreduce
P = Pool
R = Rejuvenate
S = Split/Divide
T = Thaw
U = Thaw/Pool Cryo
V = Volume Reduce
W = Wash
PARAMS("REACTION") = Yes or No value if a reaction was indicated.\n
RETURN PARAMETER DESCRIPTION: This RPC returns and XML document containing a
SuccessIndicator element represented by either a 1 for a successful insert or
update or a 0 for an unsuccessful insert or update in the VBECS DSS EXTRACT
file (#6002.03).\n
Example of successful transaction:
<ReturnValue><SuccessIndicator>1</SuccessIndicator></ReturnValue>\n
Example of unsuccessful transaction:
<ReturnValue><SuccessIndicator>0</SuccessIndicator></ReturnValue>", "VBECS DSS EXTRACT", "", ""], ["4957", "DBIA4957", "File", "INTEGRATED BILLING", "", "APPROVED", "Active", "Private", "355.93", "
The CBO Extract needs to extract the National Provider
Identifier (NPI) from the NON/OTHER VA BILLING PROVIDER file (#355.93) for
both individual and organizational providers. This is a read-only action and
does not modify any fields in the file.", "", "", "2007/03/04"], ["4958", "DIRECT FILE READ OF FILE 4", "File", "KERNEL", "", "", "Retired", "Private", "4", "
The CBO Extract needs to extract the National Provider
Identifier (NPI) from the INSTITUTION file (#4) for the organizational
providers found in the extract under the data stream fields named DEFAULT
FACILITY and FACILITY WHERE CARE RENDERED. This is a read-only action and
does not modify any data in any fields in the file.", "", "", "2007/03/04"], ["4959", "DIRECT READ OF FILE 200", "File", "KERNEL", "2007/02/18", "", "Retired", "Private", "200", "
The CBO Extract needs to extract the National Provider
Identifier (NPI) from the NEW PERSON file (#200) for the individual providers
found in the extract under the data stream field named PROVIDER. This is a
read-only action and does not modify any data in any fields in the file.", "", "", "2007/03/04"], ["4960", "INSURANCE CO AND PROVIDER ID", "File", "INTEGRATED BILLING", "", "APPROVED", "Active", "Private", "355.9", "
The NPI Extract needs to extract the INSURANCE CO and
PROVIDER ID from the IB BILLING PRACTITIONER ID file (#355.9). This is a
read-only action and does not modify any fields in the file.", "", "", "2007/02/01"], ["4961", "GET PROVIDER ID FROM INSURANCE DATA", "File", "INTEGRATED BILLING", "", "APPROVED", "Active", "Private", "355.91", "
The NPI Extract needs to extract the PROVIDER ID from
the IB INSURANCE CO LEVEL BILLING PROV ID file (#355.91). This is a read-only
action and does not modify any fields in the file.", "", "", "2007/02/01"], ["4962", "GET PROVIDER ID FROM FACILITY BILLING ID", "File", "INTEGRATED BILLING", "", "APPROVED", "Active", "Private", "355.92", "
The NPI Extract needs to extract the PROVIDER ID from
the FACILITY BILLING ID file (#355.92). This is a read-only action and does
not modify any fields in the file.", "", "", "2007/02/01"], ["4963", "DBIA4963", "File", "OUTPATIENT PHARMACY", "", "APPROVED", "Active", "Private", "59", "
The NPI Extract needs to extract the NCPDP number from
the OUTPATIENT SITE file (#59). This is a read-only action and does not
modify any fields in the file. The NPI Extract also needs to use the NPI
INSTITUTION field to get the correct NPI entry from file #4.", "", "", "2007/03/04"], ["4964", "GET FACILITY NAME & FED TAX NUMBER FROM IB SITE PARAMS", "File", "INTEGRATED BILLING", "2010/08/26", "APPROVED", "Active", "Private", "350.9", "
The NPI Extract needs to extract the FACILITY NAME, the
FEDERAL TAX NUMBER and the PAY-TO PROVIDER data from the IB SITE PARAMETER
FILE (#350.9). This is a read-only action and does not modify any fields in
the file.", "", "", "2010/08/26"], ["4965", "GET ZERO NODE INFO FROM IB NON/OTHER VA BILLING PROVIDER", "File", "INTEGRATED BILLING", "", "APPROVED", "Active", "Private", "355.93", "
The NPI Extract needs to extract several fields from
the IB NON/OTHER VA BILLING PROVIDER file (#355.93). This is a read-only
action and does not modify any fields in the file.", "", "", "2007/02/01"], ["4966", "DETERMINE MESSAGE ID AND DATE/TIME", "File", "HEALTH LEVEL SEVEN", "2017/05/26", "APPROVED", "Active", "Controlled Subscription", "773", "
This integration agreement will be used for references
to the HL7 MESSAGE ADMINISTRATION (#773) file. Each reference by package is
included in the SUBSCRIBING DETAILS for each subscribing package.\n
As new requests to this file are received and approved, this integration
agreement will be updated.", "", "", "2007/02/01"], ["4967", "DBIA4967", "File", "KERNEL", "2007/02/15", "", "Withdrawn", "Controlled Subscription", "200", "
The ECME package needs to pull contact information for
specific users so that information regarding the ePharmacy interface may be
reported to the appropriate individual.\n", "", "", ""], ["4968", "PSXBPSRP", "Routine", "CMOP", "", "APPROVED", "Active", "Controlled Subscription", "", "
This Integration Agreement grants permission for the
ECME application to call the routine PSXBPSRP that provides the CMOP/ECME
Activity Report.", "", "PSXBPSRP", "2007/03/04"], ["4969", "DGENCDA - Catastrophic Disability API", "Routine", "REGISTRATION", "2007/01/22", "APPROVED", "Active", "Private", "", "", "", "DGENCDA", "2011/03/22"], ["4970", "PSOBPSU2", "Routine", "OUTPATIENT PHARMACY", "2007/01/22", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains Outpatient Pharmacy APIs related
to the electronic billing of prescription claims (ePharmacy).", "", "PSOBPSU2", "2007/03/15"], ["4971", "DBIA4971", "File", "INTEGRATED BILLING", "", "APPROVED", "Active", "Private", "36", "
The NPI Extract extracts IB insurance company data
during its run. The extract was developed as part of the HIPAA NPI project.
The NAME and TYPE OF COVERAGE need to be extracted as part of the NPI Extract
process.", "", "", "2007/03/04"], ["4972", "DBIA4972", "File", "INTEGRATED BILLING", "", "APPROVED", "Active", "Private", "355.2", "
The NPI Extract extracts IB insurance coverage data
during its run. The extract was developed as part of the HIPAA NPI project.
The NAME needs to be examined as part of the NPI Extract process.", "", "", "2007/03/04"], ["4973", "Creation of a HL7 PID & PV1 segments (V2.4)", "Routine", "IMAGING", "2007/04/23", "", "Withdrawn", "Private", "", "
The VistA Imaging development team will provide a
function that creates both PID & PV1 segments that are backwards compatible to
version 2.4 of Health Level Seven (HL7). The PID & PV1 segments are fixed
segments; the Imaging development team will determine the fields to be defined
for these segments in accordance with the 'Integrating the Healthcare
Enterprise Radiology Technical Framework' specifications for order (ORM)
transactions.", "", "MAGDHLS", ""], ["4974", "PRIVATE VPFS consumption of VistALink API", "Other", "VISTALINK", "2007/02/06", "", "Expired", "Private", "", "
The VPFS package consumes the VistALink Service. The
objects and methods used by VPFS, are detailed below:\n\n\n
Package gov.va.med.exception:\n
-----------------------------\n
FoundationsException:\n
(catch only)\n\n\n
Package gov.va.med.vistalink.adapter.cci:\n
-----------------------------------------\n
VistaLinkConnection:\n
setTimeout(int)\n
executeRPC(RpcRequest)\n
close()\n\n\n
VistaLinkConnectionFactory:\n
getConnection(VistaLinkDuzConnectionSpec)\n\n\n
VistaLinkDuzConnectionSpec:\n
VistaLinkDuzConnectionSpec(String, String)\n\n\n
Package gov.va.med.vistalink.institution:\n
-----------------------------------------\n
InstitutionMapNotInitializedException:\n
(catch only)\n\n\n
InstitutionMappingDelegate:\n
getJndiConnectorNameForInstitution(String)\n\n\n
InstitutionMappingNotFoundException:\n
(catch only)\n\n\n
Package gov.va.med.vistalink.rpc:\n
---------------------------------\n
RpcFaultException:\n
(catch only)\n\n\n
RpcResponse:\n
getResults()\n\n\n
RpcRequest:
setUseProprietaryMessageFormat(boolean)\n
setRpcContext(String)\n
setRpcClientTimeOut(int)\n
setRpcName(String)\n
getParams()\n\n\n
RpcRequestFactory:\n
getRpcRequest()\n\n\n
RpcRequestParams:\n
setParam(int, String, Object)", "", "", "2007/03/06"], ["4975", "PROSTHETICS FILE 660", "File", "PROSTHETICS", "", "APPROVED", "Active", "Private", "660", "
THE SPINAL CORD PACKAGE NEEDS ACCESS TO DATA FIELDS
FROM THE PROSTHETICS FILE #660 (RECORD OF PROS APPLIANCE/REPAIR) AS WELL AS
USE OF PROSTHETICS API PSASHCPC^RMPOPF. ACCESS WILL BE READ-ONLY FOR
REPORTING PURPOSES.", "", "", "2007/03/06"], ["4976", "Patient Service Construct java components", "Other", "757", "2007/02/23", "", "Pending", "Controlled Subscription", "", "
Patient Service Construct is a Veterans Health
Information Systems and Technology Architecture (VistA) re-engineering project
based on the Java technologies. Patient Service is a composite business
service that provides a broad range of high-level patient administrative data.
The data is based on access to the individual business services such as
Patient Demographics, Eligibility/Enrollment, and Patient Identification,
which serve as authoritative sources for that data. For those applications
that have been re-engineered, all needs to retrieve patient administrative
data through a common business service will be met. The Patient Service
Construct functionality is invisible to existing M VistA applications.\n
PSC provides a CAIP compliant delegate (IPatientServiceDelegate) for
applications to use that has two main API s, retrievePatientData
(IPatientServiceRequest) and retrieveMultiplePatients(IPatientService Request,
String[]) where the array of strings is an array of ICN values. The delegate
accesses the patient data through a session fagade EJB. It is the
responsibility of the calling application to instantiate the EJB in an
application server for its use. The data is retrieved at the specified VistA
location through the session fagade utilizing VistaLink. The
IPatientServiceRequest must contain the necessary information to complete the
task.\n
This integration agreement documents the APIs provided by Patient Service
Construct.", "", "", ""], ["4977", "Creation of a HL7 PID segment (V2.4)", "Routine", "IMAGING", "2007/02/15", "", "Withdrawn", "Private", "", "
The VistA Imaging development team will provide a
function that creates a PID segment that is backwards compatible to version
2.4 of Health Level Seven (HL7). The PID segment is a fixed segment; the
Imaging development team will determine the fields to be defined for this
segment in accordance with the 'Integrating the Healthcare Enterprise
Radiology Technical Framework' specifications for order (ORM) transactions.", "", "MAGDHLS", ""], ["4978", "Add option to XUKERNEL", "File", "KERNEL", "2007/05/01", "", "Pending", "Private", "19", "
This agreement allows the subscribing package access to
the specified fields in the Option (#19) file.", "", "", ""], ["4979", "Default Directory for HFS", "File", "KERNEL", "2007/05/01", "", "Pending", "Private", "8989.3", "
This IA allows the subscriber(s) to reference the
Default Directory for HFS (#320) field in the Kernel Systems Parameter
(#8989.3) file.", "", "", ""], ["4980", "Remote Member (#3.812) multiple", "File", "MAILMAN", "2007/05/01", "", "Pending", "Private", "3.8", "
This IA allows the subscribing package to reference the
Remote Member (#3.812) multiple in the Mail Group (#3.8) file.", "", "", ""], ["4981", "Access to XUMFXHL7 parsing routine", "Routine", "KERNEL", "2007/05/01", "", "Pending", "Private", "", "
This agreement allows the subscribing package access to
routine XUMFXHL7 used to parse HL7 segments.", "", "XUMFXHL7", ""], ["4982", "Lab access to ORMVBEC", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2007/05/01", "APPROVED", "Active", "Private", "", "
The purpose of this integration agreement is to allow
the Lab package to use the EN entry point in the ORMVBEC routine. This would
be called by the LR7OVB routine during the VBECS order completion process.", "", "ORMVBEC", "2014/02/26"], ["4983", "Kernel Hash file (#9.69)", "File", "KERNEL", "2007/05/01", "", "Pending", "Private", "9.69", "", "", "", ""], ["4984", "Person Class (#8932.1)", "File", "KERNEL", "2007/05/01", "", "Under Revision", "Private", "8932.1", "
This agreement provides access to the specified fields
in the Person Class (#8932.1) file.", "", "", "2015/06/17"], ["4985", "XUSEREVN", "Routine", "KERNEL", "2007/05/02", "", "Pending", "Private", "", "
XUSEREVN creates PMU/B04, B05 and B06 HL7 messages
based on the event that has occurred in the New Person (#200) file record.", "", "XUSEREVN", ""], ["4986", "Temporary DBIA for use of TT in %DTC by VistA Imaging", "Routine", "1", "2007/05/04", "", "Pending", "Supported", "", "
The purpose of this DBIA is to allow VistA Imaging to
continue using the entry point TT^%DTC (convert $H-date into FileMan date)
until a patch is released that replaces all subroutine calls in Imaging
software that are currently to entry points in ^%DTC to be references to
function-calls to entry points in XLFDT.\n
It is expected that this patch will be released before the end of 2007.\n", "", "%DTC", ""], ["4987", "IB BILLING DATA API", "Routine", "INTEGRATED BILLING", "2007/05/04", "APPROVED", "Active", "Private", "", "
This set of API's provide billing data related to
Outpatient Encounters and allows the update of an encounters billable status.
These are implemented to support the Automated Service Connected Designation
(ASCD) project. This project may potentially update an encounters Service
Connected designation after the encounter's check-out.", "", "IBRSUTL", "2007/09/19"], ["4988", "EDIT LOCK IN PCMM OPTIONS.", "File", "KERNEL", "2007/05/08", "", "Pending", "Private", "19", "
The EWL/PCMM enhancement team requests permission to
remove and/or delete locks on the following PCMM Options. This requires that
access to the OPTION file (#19), field #3 (LOCK). In addition, the team
request permission to replace the SCMC PCMM EWL MENU option with the standard
scheduling SD WAIT LIST MENU option on the SCMC PCMM MAIN MENU option. These
changes will be executed with standard VA Fileman calls (DIE,DICN and DIK).
The routine will be a post init on patch SD*5.3*498 and will be deleted
following the completion of the installation.\n
The following OPTIONS will have the locks removed.\n
SCMC EXTENDED REPORT
SCMC FLAGGED
SCMC INACTIVATED REPORT
SC PCMM DIRECT PC FTEE
SCMC PRACTITIONER FLAGGED
SCMC PC STAFF AUTO INACTIVATE
SCMC PCMM MAIN MENU\n
The following OPTIONS will have the lock SC PCMM SETUP.\n
SCMC PCMM NIGHTLY TASK
SCMC RETRANSMIT
SCMC PCMM ERR CODE REPORT
SCMC PCMM TRANS ERROR REPORT
SCMC EXTEND A PATIENT\n
The following OPTION will have the lock SCMC PCMM RETRANSMIT.\n
SCMC PCMM TRANS ERROR PROC\n
The following OPTION will be deleted from the SCMC PCMM MAIN MENU.\n
SCMC PCMM EWL MENU\n
The following OPTION will be added the SCMC PCMM MAIN MENU.\n
SD WAIT LIST MENU\n\n", "", "", ""], ["4989", "LR7OSAP4- GET AP RESULTS", "Routine", "LAB SERVICE", "2007/05/10", "APPROVED", "Active", "Supported", "", "
Routine LR7OSAP4 to get Anatomic Path results from
either TIU or lab files.
;
EN(LRX,LRDFN,LRSS,LRI) ;Get Anatomic Path results from either TIU or
Lab files
; LRX is the global where the output is placed. Calling package is
resp onsible for cleaning this up
; LRDFN = Lab Patient ID
; LRSS = Lab Subscript
; LRI = Inverse Date/Time from ^LR(LRDFN,LRSS,LRIDT)\n", "", "LR7OSAP4", "2008/03/14"], ["4990", "SERVICE CONNECTED AUTOMATION", "Routine", "SCHEDULING", "2007/05/10", "APPROVED", "Active", "Supported", "", "
This routine supports the Automated Service Connected
Designation (ASCD) project. It automates the service connected (SC) value for
outpatient encounters. It also determines whether an encounter should be sent
to the ASCD file #409.48 for additional review. The evaluation of the SC
value is based on the mapping of the patient rated disability codes and ICD
codes.", "", "SDSCAPI", "2012/04/10"], ["4991", "PCE PRIMARY PROVIDER", "Routine", "PCE PATIENT CARE ENCOUNTER", "2007/05/11", "APPROVED", "Active", "Private", "", "
Returns the primary provider for a visit, if there is
one.\n", "", "PXUTL1", "2007/09/27"], ["4992", "PSSBPSUT", "Routine", "PHARMACY DATA MANAGEMENT", "2007/05/14", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains APIs used mainly by ePharmacy
(Electronic Third Party Billing).", "", "PSSBPSUT", "2007/09/05"], ["4993", "TIU DOCUMENT DEFINITION FILE 8925.1 'B' CROSS-REFERENCE", "File", "1", "2007/05/23", "APPROVED", "Active", "Private", "", "
The "B" cross-reference for the TIU Document Definition
file (#8925.1) needs to be extended to 60 characters to ensure uniqueness in
the index. This file is pointed to by the TIU Document file (#8925), the
HEALTH SUMMARY Type file (#142), and the FUNCTIONAL INDEPENDENCE Measurement
Parameter file (#783.9).\n
Revised Set/Kill Logic:\n
S ^TIU(8925.1,"B",$E(X,1,60),DA)=""
K ^TIU(8925.1,"B",$E(X,1,60),DA)", "", "", "2007/09/19"], ["4994", "TIU VHA ENTERPRISE STANDARD TITLE file 'B' CROSS REFERENCE", "File", "1", "2007/05/23", "APPROVED", "Active", "Private", "8926.1", "
The "B" cross-reference for the TIU VHA Enterprise
Standard Title file (#8926.1) needs to be extended to 90 characters to ensure
uniqueness in the index. This file is pointed to by the TIU Document
Definition file (#8925.1) only.\n
Revised Set/Kill Logic:\n
S ^TIU(8926.1,"B",$E(X,1,90),DA)=""
K ^TIU(8926.1,"B",$E(X,1,90),DA)", "", "", "2007/09/19"], ["4995", "OR EVSEND GMRC", "Other", "ORDER ENTRY/RESULTS REPORTING", "2007/05/24", "APPROVED", "Active", "Private", "", "
The protocol name OR EVSEND GMRC is exported as USE AS
LINK FOR MENU ITEMS. This linkage will allow Clinical Procedures to link to
the protocol and monitor order activity messages. This IA is used in
conjunction with IA 3135.\n", "", "", "2007/07/09"], ["4996", "EEOB Worklist NPI inclusion", "File", "INTEGRATED BILLING", "2007/05/25", "APPROVED", "Active", "Controlled Subscription", "399", "
This DBIA is for allowing the Accounts Receivable
package to utilize Fileman APIs to retrieve NPIs, provider types and provider
names from the Bill/Claims file (#399). The fileman APIS to be used are
GET1^DIQ and GETS^DIQ.", "", "", "2007/09/19"], ["4997", "Pointing to the VA DRUG CLASS (#50.605) File", "File", "NATIONAL DRUG FILE", "2007/06/05", "APPROVED", "Active", "Supported", "50.605", "
This agreement allows for other applications to store a
pointer to the Vista VA DRUG CLASS (#50.605) file. This number can be used as
an Identification Number to retrieve data.", "", "", "2007/06/20"], ["4998", "Pointing to the DRUG INGREDIENTS (#50.416) File", "File", "NATIONAL DRUG FILE", "2007/06/05", "APPROVED", "Active", "Supported", "50.416", "
This agreement allows for other applications to store a
pointer to the Vista DRUG INGREDIENTS (#50.416) file. This number can be used
as an Identification Number to retrieve data.", "", "", "2007/06/20"], ["4999", "Pointing to the VA GENERIC (#50.6) File", "File", "NATIONAL DRUG FILE", "2007/06/05", "APPROVED", "Active", "Supported", "50.6", "
This agreement allows for other applications to store a
pointer to the Vista VA GENERIC (#50.6) file. This number can be used as an
Identification Number to retrieve data.", "", "", "2007/06/20"], ["5000", "Pointing to the PRESCRIPTION (#52) File", "File", "OUTPATIENT PHARMACY", "2007/06/05", "APPROVED", "Active", "Supported", "52", "
This agreement allows for other applications to store a
pointer to the Vista PRESCRIPTION (#52) file. This number can be used as an
Identification Number to retrieve data.", "", "", "2007/06/20"], ["5001", "Pointing to the PHARMACY QUICK ORDER (#57.1) File", "File", "INPATIENT MEDICATIONS", "2007/06/05", "APPROVED", "Active", "Supported", "57.1", "
This agreement allows for other applications to store a
pointer to the Vista
PHARMACY QUICK ORDER (#57.1) file. This number can be used as an
Identification Number to retrieve data.", "", "", "2007/06/20"], ["5002", "INPUT TEMPLATE FOR A MULTIPLE", "File", "1", "2007/06/13", "APPROVED", "Active", "Controlled Subscription", ".402", "
VA FileMan does not allow you to use an Input Template
exclusively for fields within a multiple. For example, if you know the file
top level IEN and you know the sub-file IEN and you want to only present for
editing to the user the fields within the sub-file, you cannot do this with a
VA FileMan Input Template.", "", "", "2009/07/13"], ["5003", "CAPACITY PLANNING TIMING API", "Routine", "CAPACITY MANAGEMENT TOOLS", "2007/06/14", "", "Pending", "Controlled Subscription", "", "
API to Start and Stop gathering Timing stats for
Capacity Planning.", "", "KMPDTU11", ""], ["5004", "DISTRIBUTION OF XHDXC DESKTOP OPTION", "Other", "HEALTHEVET DESKTOP", "2007/06/19", "APPROVED", "Active", "Private", "", "
This agreement is provided to the CARE MANAGEMENT
package version 1.0 to distribute the XHDXC DESKTOP option.", "", "", "2007/06/20"], ["5005", "DISTRIBUTION OF XHD PRISM DESKTOP THEME", "Other", "HEALTHEVET DESKTOP", "2007/06/19", "APPROVED", "Active", "Private", "", "
This agreement is provided to the CARE MANAGEMENT
package version 1.0 to distribute the XHD PRISM DESKTOP THEME parameter.", "", "", "2007/06/20"], ["5006", "Lexicon Obtain Synonyms for Code", "Routine", "LEXICON UTILITY", "2007/06/28", "APPROVED", "Active", "Supported", "", "
This API will return an array for a given code and
coding system. The array will contain all synonyms for the concept including
the preferred term and the fully specified name. If any of the passed
parameters are incorrect or unrecognizable, the API will return an error
message indicating the nature of the error.", "", "LEXTRAN1", "2007/12/28"], ["5007", "Lexicon Obtain Fully Specified Name", "Routine", "LEXICON UTILITY", "2007/06/28", "APPROVED", "Active", "Supported", "", "
This API returns the fully specified name for a given
coding system and code. If any of the passed parameters are incorrect or
unrecognizable, the API will return an error message indicating the nature of
the error.", "", "LEXTRAN1", "2007/12/28"], ["5008", "Lexicon Obtain Preferred Term", "Routine", "LEXICON UTILITY", "2007/06/28", "APPROVED", "Active", "Supported", "", "
This API returns the preferred term for a given coding
system and code. If any of the passed parameters are incorrect or
unrecognizable, the API will return an error message indicating the nature of
the error.", "", "LEXTRAN1", "2007/12/28"], ["5009", "Lexicon Obtain Designation Code", "Routine", "LEXICON UTILITY", "2007/06/28", "APPROVED", "Active", "Supported", "", "
This API returns the designation code for a given
coding system and text. If any of the passed parameters are incorrect or
unrecognizable, the API will return an error message indicating the nature of
the error.", "", "LEXTRAN1", "2007/12/28"], ["5010", "Lexicon Obtain Mapped Codes", "Routine", "LEXICON UTILITY", "2007/06/28", "APPROVED", "Active", "Supported", "", "
This API returns an array containing the mappings for a
specified code for a specified mapping identifier. If any of the passed
parameters are incorrect or unrecognizable, the API will return an error
message indicating the nature of the error.\n", "", "LEXTRAN1", "2007/12/28"], ["5011", "Lexicon Obtain Version Identifier", "Routine", "LEXICON UTILITY", "2007/06/28", "APPROVED", "Active", "Supported", "", "
This API returns the SDO version identifier for a given
coding system, code, and date. If any of the passed parameters are incorrect
or unrecognizable, the API will return an error message indicating the nature
of the error.", "", "LEXTRAN", "2007/12/28"], ["5012", "DBIA5012", "File", "REGISTRATION", "2007/07/05", "", "Pending", "Private", "38.5", "
The Income Verification Match (IVM) package has a need
to read, write and delete data in the INCONSISTENT DATA file (#38.5) during
the process to build Z07 HL7 messages.\n\n
.01 NAME 0;1 POINTER TO PATIENT FILE (#2)\n
2 INITIALLY IDENTIFIED 0;2 DATE\n
3 IDENTIFIED BY 0;3 POINTER TO NEW PERSON FILE (#200)\n
4 LAST UPDATED 0;4 DATE\n
5 LAST UPDATED BY 0;5 POINTER TO NEW PERSON FILE (#200)\n
6 BULLETIN SENT 0;6 DATE\n
10 INCONSISTENCY I;0 POINTER Multiple #38.51\n
.01 INCONSISTENCY 0;1 POINTER TO INCONSISTENT DATA ELEMENT
S FILE (#38.6) (Multiply asked)", "", "", ""], ["5013", "READ ACCESS TO DD FOR FILE 9002313.58", "File", "1", "2007/07/10", "APPROVED", "Active", "Private", "", "
The ECME application is granted read access to the
DD(9002313.58 global in order to $ORDER through the FIELD subscript of the
^DD(9002313.58,FIELD).", "", "", "2007/07/12"], ["5014", "Pointing to the OUTPATIENT SITE (#59) File", "File", "OUTPATIENT PHARMACY", "2007/07/11", "APPROVED", "Active", "Supported", "59", "
This agreement allows for other applications to store a
pointer to the Vista OUTPATIENT SITE (#59) file. This number can be used as an
Identification Number to retrieve data.", "", "", "2007/07/12"], ["5015", "READ ACCESS TO DD FOR FILE 9002313.59", "File", "1", "2007/07/12", "APPROVED", "Active", "Private", "9002313.59", "
The ECME application is granted read access to the DD
global in order to $ORDER through the FIELD subscript of the
^DD(9002313.59,FIELD) global.", "", "", "2007/07/12"], ["5016", "SCREEN FOR ACTIVE PROVIDER", "Routine", "REGISTRATION", "2007/07/13", "APPROVED", "Active", "Controlled Subscription", "", "
Screen for active provider in NEW PERSON (#200) file.\n", "", "DGPMDD", "2007/07/13"], ["5017", "Change notification for file 42.4", "File", "REGISTRATION", "2007/07/25", "APPROVED", "Active", "Private", "42.4", "
The VBECS (Veterans Blood Establishment Computer
System) TreatingSpecialty table replicates the data in the VistA SPECIALTY
file (#42.4). The VBECS team requests notification of any changes to the data
or data definitions in file 42.4 to ensure that VBECS and VistA are in synch.
We also request a copy of any test patches affecting the data or data
definitions in file 42.4 so we can prepare any necessary VBECS patches.", "", "", "2008/03/04"], ["5018", "DBIA5018", "Routine", "REGISTRATION", "2011/01/10", "", "Pending", "Private", "", "
Create pseudo SSN for John Doe patients or for a
patient that can't provide their SSN at Registration.", "", "DGRPDD1", ""], ["5019", "PHARMACY DATA FROM BPS PHARMACIES file", "File", "E CLAIMS MGMT ENGINE", "2007/07/31", "APPROVED", "Active", "Private", "9002313.56", "
The Kernel Package requests read access using FileMan
to the following fields of the BPS PHARMACIES file (#9002313.56).\n\n", "", "", "2007/09/19"], ["5020", "Rad/Nuc Med accession number/SIUID utilities", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2007/08/01", "APPROVED", "Active", "Private", "", "
$$ACCNUM
--------
The $$ACCNUM function creates and returns a site specific accession number
based on the input of the following case specific identifiers: RADFN (patient
DFN), RADTI (inv. date/time of the exam), & RACNI (the exam record IEN).\n
$$ACCFIND
---------
Based on the input of an accession number or a site specific accession number
and if successful the $$ACCFIND function returns case specific identifiers:
RADFN (patient DFN), RADTI (inv. date/time of the exam), & RACNI (the exam
record IEN) in array 'RAA(Z)'. The variable 'Z' is also returned to indicate
the number of 'RAA' array elements created.\n
If unsuccessful, 'Z' is returned as a string: the first piece is a negative
number indicating the error type and the second piece is the error type text.\n
$$ACCRPT
--------
Based on the input of a pointer to a record in the RAD/NUC MED REPORTS (#74)
file, the $$ACCRPT function returns the accession number(s) in the 'RAA(n)'
array, if successful. If n=1 the single accession number is returned in
RAA(1). If n>1 the 'lead' accession number (for printsets) is returned in
RAA(1) and subsequent ones are returned in RAA(2) thru RAA(n). Accession
numbers are returned in either standard "mmddyy-case#" format or in the site
specific "sss-mmddyy-case#" format.\n
If unsuccessful, a "-1" (invalid file #74 pointer value) is returned.\n
$$GETSIUID
----------
Based on the input of exam data, the RADFN (patient DFN), RADTI (inverse
date/time of registered exam) and RACNI (exam record), the $$GETSIUID function
returns the Study Instance UID field value [^DD(70.03,81)].\n
$$SIUIDFND
----------
Based on the input of a Study Instance UID, if successful the $$SIUIDFND
function returns a '1' and also returns the case specific identifiers: RADFN
(patient DFN), RADTI (inv. date/time of the exam), & RACNI (the exam record
IEN) in array 'RAA(1)'.\n
If unsuccessful, '-1^"no data associated with this study instance UID"^siuid'
is returned as a string: the first piece is a '-1' indicating the lookup was
not successful, the second piece is the error text and the third piece is the
SIUID which was the original input.\n\n", "", "RAAPI", "2009/05/22"], ["5021", "Populate NEW PERSON phone(s) into a local array", "Routine", "IMAGING", "2007/08/01", "", "Active", "Private", "", "
This function return the following NEW PERSON (#200)
file fields into a local array: PHONE (HOME) (#.131), OFFICE PHONE (#.132),
PHONE #3 (#.133), PHONE #4 (#.134), COMMERCIAL PHONE (#.135), FAX NUMBER
(#.136), VOICE PAGER (#.137), and DIGITAL PAGER (#.138).", "", "MAG7UFO", ""], ["5022", "Build the HL7 ZDS segment for Study Instance UID", "Routine", "IMAGING", "2007/08/01", "", "Active", "Private", "", "
This function creates a DICOM Study Instance UID from
three Radiology/Nuclear Medicine package variables: RADTI, RACNI, and RADTE.", "", "MAGDRAHL", ""], ["5023", "Build the HL7 PID and PV1 segments", "Routine", "IMAGING", "2007/08/01", "", "Active", "Private", "", "", "", "MAGDHLS", ""], ["5024", "SURGERY FILE 130 DATA - NURSE INTRAOPERATIVE REPORT", "Routine", "SURGERY", "2007/08/06", "", "Pending", "Private", "", "
TIU will call this tag from a utiity routine for
comparison of the NURSE INTRAOPERATVIE REPORT in TIU (8925) with the Surgery
file (130) NIR data.", "", "SRONRPT", ""], ["5025", "SURGERY FILE 130 DATA - ANESTHESIA REPORT", "Routine", "SURGERY", "2007/08/06", "", "Pending", "Private", "", "
TIU will call this tag from a utiity routine for
comparison of the Anesthesia report in TIU (8925) with the Surgery file (130)
Anesthesia data.", "", "SROANR", ""], ["5026", "TRANSMIT LAB SNOMED CT EXCEPTIONS", "Routine", "HEALTH DATA & INFORMATICS", "2007/08/07", "APPROVED", "Active", "Private", "", "\n
This Integration Agreement permits the Lab package to utilize a Health
Data and Informatics (HDI) application programmer interface (API) to
report SNOMED CT (SCT) exceptions to the Enterprise Reference Terminology
(ERT) team for resolution. There are three exceptions/events that result
in the Lab package using the API. They are:\n
1) Error encountered while loading ERT mapped SCT code into
the target database
2) Loading new/additional terms received from another system
via HL7 messaging
3) New terms are entered locally", "", "HDISVAP1", "2012/09/12"], ["5027", "DBIA5027", "File", "KERNEL", "2007/08/07", "APPROVED", "Active", "Private", "200", "
The Scheduling Replacement Project (SRP) requires a
DBIA with Kernel for the NEW PERSON file (#200).\n
When a site switches over to the new Replacement Scheduling Application (RSA)
from legacy Scheduling, system users in file #200 who are active and have a
VPID will be loaded into the Oracle Internet Directory associated with the
RSAdb. This load is accomplished by means of an RSA utility that uses a flat
text file containing the Name and VPID for each user. SRP must produce the
text file via a routine that loops through the entire NEW PERSON file (#200)
global to obtain the IEN for each record.\n
Note: Data needed from the NEW PERSON record is obtained via supported
functions $$ACTIVE^XUSER, $$VPID^XUPS, and $$NAME^XUSER.", "", "", "2007/09/24"], ["5028", "5028", "File", "DRG GROUPER", "2007/08/21", "", "Retired", "Controlled Subscription", "80", "\n\n
This agreement will allow Problem List to determine if a particular ICD9 code
has a new description change. This agreement is to view the cross reference
"AST" to determine if a new description exits.", "", "", ""], ["5029", "VERIFY SC APPOINTMENT TYPE", "File", "INTEGRATED BILLING", "2007/08/23", "APPROVED", "Active", "Private", "352.1", "
Scheduling requires one time access to the Billable
Appointment Type file to verify that the Service Connected entry is correctly
defined. This entry was created to correspond to the new Service Connected
Appointment Type but may have been incompletely added if there were local
changes to the Billable Appointment Type file.\n
The Scheduling patch SD*5.3*491 post-init will access the SERVICE CONNECTED
(#11) node of the BILLABLE APPOINTMENT TYPE (#352.1) file to verify that it
was correctly created and points to the SERVICE CONNECTED (#11) entry of the
APPOINTMENT TYPE (#409.1) file.\n
This agreement will expire at the end of the SD*5.3*491 compliance date.\n", "", "", "2008/07/28"], ["5030", "GETEPHRM", "Routine", "E CLAIMS MGMT ENGINE", "2007/09/05", "", "Pending", "Private", "", "
This API was designed exclusively to serve IB*2.0*363
post-installation process. Thus usage of this API is limited to the IB*2.0*363
post-install routine IB20P363.", "", "BPS01P5C", ""], ["5031", "DBIA5031", "File", "REGISTRATION", "2007/09/18", "", "Pending", "Private", "2", "
Outpatient Pharmacy has a need to add the PHONE NUMBER
[CELLULAR] field #.134 from the PATIENT file #2 to their patient information
screen. They have permission to display, modify and delete this field using
FileMan.\n
2,.134 PHONE NUMBER [CELLULAR] .13;4 FREE TEXT", "", "", ""], ["5032", "REMOTE APPLICATION REGISTRATION", "File", "KERNEL", "2007/09/24", "APPROVED", "Active", "Controlled Subscription", "8994.5", "
This Integration Control Registration was created to
add an entry in the file 8994.5.\n
The entry in this file will allow the RPC Broker code in the host VistA system
to validate authentication requests for remote user access, and is done in
accordance with instructions on the use of the Broker Security Enhancement as
provided by the VistA Kernel team.\n
The file entry contains the name of the application, the application code
(encrypted), method of authentication, and authentication server IP, port, and
entry point.\n
Revision History:
- 3/5/25: VISS team notes that this ICR will be replaced by a future solution
currently defined in patch XU*8*759 REMOTE APPLICATION ENHANCEMENT. BSE
bypasses and not enhances VistA Kernel Security, as VistA is site-centric,
where sites control security of users and their applications. BSE bypasses
many of the components of VistA Kernel Security and site-level security.", "", "", "2007/10/24"], ["5033", "Allow lookup with FileMan on file #8925.1", "File", "TEXT INTEGRATION UTILITIES", "2007/10/02", "APPROVED", "Active", "Controlled Subscription", "8925.1", "\n
Allow lookup with FileMan on the TIU DOCUMENT DEFINITION file (#8925.1)
to get Title IFN in file 8925.1 to create a TIU document-
Lab Anatomic Pathology Report.\n", "", "", "2008/03/24"], ["5034", "OCCUR-YTQPXRM1", "Routine", "MENTAL HEALTH", "2007/10/04", "APPROVED", "Active", "Private", "", "
Report ocuurances of selected Mental Health instrument
for a specific time frame.", "", "YTQPXRM1", "2007/12/18"], ["5035", "MHA3-CR data for a specified Patient", "Routine", "MENTAL HEALTH", "2007/10/04", "APPROVED", "Active", "Private", "", "
All MHA3/mha data for a selected patient.", "", "YTQPXRM2", "2007/12/18"], ["5036", "ENROLLMENT RATED DISABILITY UPLOAD AUDIT REPORTING", "Routine", "REGISTRATION", "2007/10/23", "APPROVED", "Active", "Private", "", "
This API will provide Rated Disability changes from the
ENROLLMENT RATED DISABILITY UPLOAD AUDIT file (#390) for a single or multiple
Veterans.", "", "DGENRDUA", "2008/02/06"], ["5037", "VISTAWEB/CPRS SURGERY DETAIL ACCESS", "File", "1", "2007/10/24", "", "Pending", "Private", "", "
VISTAWEB/CPRS report routines need access to
^DD(130,.04,0 for a formatted surgery report detail, retrieved using classic
Fileman API Y^DIQ.\n", "", "", ""], ["5038", "LEXICON READ OF DD(D0,0,'IX')", "File", "1", "2007/11/06", "APPROVED", "Active", "Private", "", "", "", "", "2007/11/07"], ["5039", "AR Access to Patient File", "File", "REGISTRATION", "2007/11/07", "APPROVED", "Active", "Private", "2", "
For the Hold Debt to DMC project the Accounts
Receivable (AR) software package is providing some new reports for the AR
clerks to use when evaluating bills for veterans who are Service Connected 50%
to 100% or receiving a VA Pension. For these new reports the Business Office
requested that AR include 2 fields from the Patient (#2) file for which there
currently isn't a Public DBIA and the data elements are not included with the
VADPT API.\n
AR would like direct global access using Fileman to the following fields in
the Patient (#2) file:
CLAIM FOLDER LOCATION (#.314)
EFF. DATE COMBINED SC% EVAL. (#.3014)", "", "", "2007/11/13"], ["5040", "AR Access to the Outpatient Encounter File", "File", "SCHEDULING", "2007/11/07", "APPROVED", "Active", "Private", "409.68", "
For the Hold Debt to DMC project the Accounts
Receivable (AR) software package is providing some new reports for the AR
clerks to use. For these new reports the Business Office requested that AR
include bills that have an episode of care within the previous 365 days and if
appropriate display the date of the most recent Outpatient Encounter. This is
to be done using the RESULTING FROM (#.04) field in the INTEGRATED BILLING
ACTION (#350) file which contains a soft-link back to the entry in any file
that caused this billing transaction to be set. One of these soft-links is to
the OUTPATIENT ENCOUNTER (#409.68) file which relates to DBIA 402 subscribed
to by the Integrated Billing package.\n
The AR package requires access to the DATE (#.01) field of the OUTPATIENT
ENCOUNTER (#409.68) based on its interface with the IB package.", "", "", "2007/12/13"], ["5041", "GET NEW ICN FROM MPI", "Routine", "MASTER PATIENT INDEX VISTA", "2011/01/11", "APPROVED", "Active", "Private", "", "
This is used by Single Patient Registration, whenever
a new patient is created. If an ICN is not passed in, a request is made to to
the National MPI for a new ICN.", "", "MPIFA28", "2011/03/01"], ["5042", "YTQPXRM3", "Routine", "MENTAL HEALTH", "2007/11/08", "APPROVED", "Active", "Controlled Subscription", "", "", "", "YTQPXRM3", "2007/12/18"], ["5043", "YTQPXRM6", "Routine", "MENTAL HEALTH", "2007/11/08", "APPROVED", "Active", "Controlled Subscription", "", "", "", "YTQPXRM6", "2007/12/18"], ["5044", "MH TESTS AND SURVEYS ZERO", "File", "MENTAL HEALTH", "2007/11/08", "APPROVED", "Active", "Private", "601.71", "
Read only ^YTT(601.71,IFN,0) and point to ^YTT(601.71)", "", "", "2017/11/20"], ["5045", "READ ACCESS TO IMAGING TYPE FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2007/11/09", "APPROVED", "Active", "Private", "79.2", "
In preparation for releasing OR*3*243 (GUI v27), a
routine is needed to assist the sites in making corrections to existing
Radiology and Imaging quick orders.\n
In order to do this, access to the IMAGING TYPE file (79.2) is needed in a
slightly different way than currently allowed.\n
The search routine needs access to the B cross-reference and then to the NAME
field (.01).\n
This would be a one-time IA for the installation of OR*3*281.", "", "", "2007/11/20"], ["5046", "GMVUTL", "Routine", "GEN. MED. REC. - VITALS", "2007/11/14", "APPROVED", "Active", "Supported", "", "
The CLIO, F1250 and GETREC entry points return a
patient vitals record in an array.", "", "GMVUTL", "2008/03/19"], ["5047", "GMVGETVT", "Routine", "GEN. MED. REC. - VITALS", "2007/11/14", "APPROVED", "Active", "Supported", "", "
APIs that return values for vital types (FILE 120.51).", "", "GMVGETVT", ""], ["5048", "GMVGETQL", "Routine", "GEN. MED. REC. - VITALS", "2007/11/14", "APPROVED", "Active", "Supported", "", "
APIs that return values for qualifiers (FILE 120.52).", "", "GMVGETQL", "2008/03/19"], ["5049", "ADT-A24 message", "Routine", "MASTER PATIENT INDEX VISTA", "2011/01/11", "APPROVED", "Active", "Private", "", "
This call is used by Single Patient Registration,
whenever a new patient is created. After setting an ICN into the Patient File,
we make this call to create and send an ADT-A24 message to the National MPI.", "", "MPIFA24B", "2011/03/01"], ["5050", "GMVGETC", "Routine", "GEN. MED. REC. - VITALS", "2007/11/14", "APPROVED", "Active", "Supported", "", "
APIs that return values for categories (FILE 120.53).", "", "GMVGETC", "2008/03/19"], ["5051", "RL-YTQPXRM3", "Routine", "MENTAL HEALTH", "2007/11/15", "", "Withdrawn", "Controlled Subscription", "", "
RL(YSCODEN) ;requires license
;input YSCODEN ien OF 601.71
;output Y/N/0", "", "YTQPXRM3", ""], ["5052", "OLDNEW-YTQPXRM3", "Routine", "MENTAL HEALTH", "2007/11/15", "", "Withdrawn", "Controlled Subscription", "", "
OLDNEW(YSCODEN,YSOLDNUM) ;
;input YSCODEN ien OF 601.71
; YSOLDNUM as ien of "S" MULT of 601 (1= DEFAULT)
;output ien OF 601.87, 0=ERROR", "", "YTQPXRM3", ""], ["5053", "SAVECR-YTQPXRM4", "Routine", "MENTAL HEALTH", "2007/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
SAVECR(YSDATA,YS) ;save cr entered instruments
; input: CODE,DFN,^TMP($J,AARAY,sequential)=ITEM#^RESPONSE
;output [DATA] VS [ERROR]", "", "YTQPXRM4", "2007/12/18"], ["5054", "CONVERT-YTQPXRM6", "Routine", "MENTAL HEALTH", "2007/11/15", "", "Withdrawn", "Controlled Subscription", "", "
CONVERT(YSDATA,YS) ;convet 601 ien into 601.71 iens
;input YS601 AS 601 IEN
;output 601.71 ien", "", "YTQPXRM6", ""], ["5055", "INDEX-YTQPXRM", "Routine", "MENTAL HEALTH", "2007/11/20", "", "Retired", "Controlled Subscription", "", "
builds index ^PXRMINDX(601.84,""PI" and
^PXRMINDX(601.84,"IP" as described in the clinical reminders documentation.
DAS is last node.\n
No input or output variables, just a complete re-build of the indexes.", "", "", "2007/12/18"], ["5056", "YTQPXRM5", "Routine", "MENTAL HEALTH", "2007/11/20", "APPROVED", "Active", "Controlled Subscription", "", "", "", "YTQPXRM5", "2007/12/18"], ["5057", "BCMA LAST ACTION", "Routine", "INPATIENT MEDICATIONS", "2007/12/05", "APPROVED", "Active", "Controlled Subscription", "", "
As part of the medication reconciliation portion of the
outpatient pharmacy application, we have need for the BCMA Last Action
information as returned by the call to BCMALG^PSJUTL2. To accomplish this,
outpatient pharmacy requests permission to make this call.\n", "", "PSJUTL2", "2008/02/11"], ["5058", "ALLERGIES ARRAY", "Routine", "INPATIENT MEDICATIONS", "2007/12/05", "APPROVED", "Active", "Private", "", "
As part of the medication reconcilication portion of
the outpatient pharmacy application, we need the arrays of allergies and
adverse reactions returned by a call to ATS^PSJMUTL. To accomplish this,
outpatient pharmacy requests permission to make this call.\n", "", "PSJMUTL", "2008/02/11"], ["5059", "ADD MEDS AND ADD TITLE", "Routine", "TEXT INTEGRATION UTILITIES", "2007/12/06", "APPROVED", "Active", "Private", "", "
As part of the medication reconciliation component of
the outpatient pharmacy application, we need the information provided by
ADDMED^TIULMED1 and ADDTITLE^TIULMED1. To that end, we request permission to
call those entry points.", "", "TIULMED1", "2008/02/11"], ["5060", "CALLS TO TIULMED2", "Routine", "TEXT INTEGRATION UTILITIES", "2007/12/06", "APPROVED", "Active", "Private", "", "
The medication reconciliation portion of the outpatient
pharmacy application has need of the information returned by call to entry
points DEA, DRGCLASS, DRGIEN, and IENNAME in routine TIULMED2. We request
permission to make those calls.", "", "TIULMED2", "2008/02/11"], ["5061", "CALLS TO TIUMED3", "Routine", "TEXT INTEGRATION UTILITIES", "2007/12/06", "APPROVED", "Active", "Private", "", "", "", "TIULMED3", "2008/02/11"], ["5062", "DBIA5062", "File", "CONSULT/REQUEST TRACKING", "2007/12/12", "APPROVED", "Active", "Private", "123", "
This integration agreement documents the usage of the
ACP and AE index in the REQUEST/CONSULTATION file (#123). CLINICAL PROCEDURES
package will be $ORDER through the ^GMR(123,"ACP" by the CP Definition to get
a list of consult requests by CP definition.\n
CLINICAL PROCEDURES package will $ORDER through the ^GMR(123,"AE" by the TO
SERVICE to get a list of consult requests for a service.", "", "", "2008/03/19"], ["5063", "PSOREJU4", "Routine", "OUTPATIENT PHARMACY", "2007/12/14", "APPROVED", "Active", "Private", "", "
This routine contains APIs to be used by ECME package
to pass Third Party Reject information to the Pharmacy Reject Worklist.\n", "", "PSOREJU4", "2013/07/23"], ["5064", "9002313.25", "File", "E CLAIMS MGMT ENGINE", "2007/12/14", "APPROVED", "Active", "Private", "9002313.25", "", "", "", "2007/12/14"], ["5065", "IA 5065", "Routine", "OUTPATIENT PHARMACY", "2007/12/27", "", "Pending", "Private", "", "
API to allow ECME to call the INLIST API to check for
allowable reject codes that are allowed to be passed to the Pharmacy Reject
Worklist manually by the OPECC.", "", "", ""], ["5066", "LOOKUP IP ADDRESS FOR PACKAGE IN 870", "File", "HEALTH LEVEL SEVEN", "2008/01/08", "", "Pending", "Private", "870", "
The Enrollment Application System package (EAS) would
like to lookup an entry in file #870 using a direct read on the "B cross
reference and read data from the entry using Fileman. Here is the code being
used (in routine EAS1071A):\n
IPLIVE() ;Get IP address for production system
;
;Search for DENTVHLAAC logical link
S IENS=$$FIND1^DIC(870,"","X","DENTVHLAAC","","","ERR")
;If not found return null IP address
I 'IENS Q ""
;Otherwise return TCP/IP ADDRESS
Q $$GET1^DIQ(870,IENS_",",400.01)\n
LL16(LLNAME,TCPADDR,TCPPORT,SHUTDOWN) ;Update Logical Link Port and Address
;
N FILE,DATA,RETURN,DEFINED,ERROR,DA,DGENDA
S FILE=870
S IEN870=$O(^HLCS(870,"B",LLNAME,0))
I 'IEN870 D Q RETURN
. S ERROR="IEN OF RECORD TO BE UPDATED NOT FOUND"
. S RETURN=-1_"^"_ERROR
;
S DATA(400.01)=TCPADDR ;TCP/IP ADDRESS
S DATA(400.02)=TCPPORT ;TCP/IP PORT
S DATA(4.5)=1 ;AUTOSTART
S DATA(14)=SHUTDOWN ;SHUTDOWN LLP
;
S RETURN=$$UPD^DGENDBS(FILE,IEN870,.DATA,.ERROR)
S:ERROR'=""!(+RETURN=0) RETURN=-1_"^"_ERROR
;
Q RETURN\n
This is in support of the ESR v3.0 rollout in patch EAS*1*71.\n\n\n", "", "", ""], ["5067", "DD CHECKING AND TRAVERSING", "File", "1", "2008/01/10", "APPROVED", "Active", "Private", "", "
In support of APIs for Data Standardization, Kernel
ToolKit is authorized to check a file's DD as follows:\n
I ('$D(^DD(FILE,0,"PT",NEXTFILE,99.97))) Q\n
and $O through a file's DD as follows:\n
S NEXTFILE=+$O(^DD(FILE,0,"PT",NEXTFILE))\n", "", "", "2008/02/06"], ["5068", "RAMAG EXAM ORDER", "Remote Procedure", "RADIOLOGY/NUCLEAR MEDICINE", "2008/01/16", "APPROVED", "Active", "Private", "", "
The RAMAG EXAM ORDER remote procedure requests a
Radiology exam for the patient and returns the IEN of the new order in the
RAD/NUC MED ORDERS file (#75.1). It also sends all required notifications.\n
Input Parameters
================\n
RADFN Patient IEN (DFN).\n
RAMLC IEN of the imaging location in the IMAGING LOCATIONS
file (#79.1).\n
RAPROC Radiology procedure and optional modifiers
^01: Procedure IEN in the RAD/NUC MED PROCEDURES
file (#71)
^02: Optional procedure modifiers (IENs in
... the PROCEDURE MODIFIERS file (#71.2))
^nn:\n
REQDTE Desired date for the exam in HL7 format (TS): YYYYMMDD.
If a time part is provided, it is ignored. The date
must be exact.\n
RACAT Exam category: internal value of the CATEGORY OF EXAM
field (4) of the RAD/NUC MED ORDERS file (#75.1).\n
REQLOC IEN of the requesting location in the HOSPITAL
LOCATION file (#44).\n
REQPHYS IEN of the requesting physician in the NEW PERSON
file (#200).\n
REASON Reason for study. See the REASON FOR STUDY field (1.1)
of the RAD/NUC MED ORDERS file (#75.1) for details.\n
[RAMSC] Items of this list define miscellaneous/optional
order parameters. Each record has 3 or more pieces
separated by '^':\n
^01: Parameter name
^02: Index (for multiples and word-processing values)
^03: Value1
^04: Value2
...\n
The following parameters are supported by this remote
procedure:\n
CLINHIST^{Seq#}^{Line of clinical history}
Text for the CLINICAL HISTORY FOR EXAM field (400)
of the file #75.1\n
ISOLPROC^^{n|y}
Value for the ISOLATION PROCEDURES field (24)
of the file #75.1\n
PREGNANT^^{n|u|y}
Value for the PREGNANT field (13) of the file #75.1\n
PREOPDT^^{Internal date value}
Date and time for the PRE-OP SCHEDULED DATE/TIME
field (12) of the file #75.1 in HL7 format (TS):
YYYYMMDD[HHMM[+/-ZZZZ]]. If seconds are provided,
they are ignored. The date must be exact.\n
REQNATURE^^{e|i|p|s|v|w}
Value for the NATURE OF (NEW) ORDER ACTIVITY
field (26) of the file #75.1\n
REQURG^^{1|2|9}
Value for the REQUEST URGENCY field (6)
of the file #75.1\n
TRANSPMODE^^{a|p|s|w}
Value for the MODE OF TRANSPORT field (19)
of the file #75.1\n
Records can be added to the list in any order.\n
Example:\n
with RPCBroker.Param[8] do
begin
PType := list;
Mult[1] := 'PREGNANT^^y';
Mult[2] := 'PREOPDT^^200001041400';
Mult[3] := 'CLINHIST^1^Clinical history line #1';
Mult[4] := 'CLINHIST^2^Clinical history line #2';
Mult[5] := 'CLINHIST^3^Clinical history line #3';
end;\n
Results
=======\n
A negative value of the first '^'-piece of the Results[0] indicates that an
error occurred during the execution of the remote procedure. In this case, the
second piece of the Results[0] will contain number of the error descriptors
returned in the subsequent nodes of the Results array.\n
Results[0] Result descriptor
^01: The last error code
^02: Number of error descriptors\n
Results[i] Error descriptor
^01: Error code
^02: Message
^03: Error location (TAG~ROUTINE)
^04: Error type\n
Results[j] Line of the additional info
^01: "" (empty)
^02: Text\n
Error descriptors are returned in reverse chronological order (most recent
first).\n
Otherwise, the Results[0] contains IEN of the new order in the RAD/NUC MED
ORDERS file (#75.1).\n
Notes
=====\n
See comments in the source code of the RAMAG02 routine and description of the
RAMAG EXAM ORDER remote procedure for additional and/or most recent details.", "", "", "2008/10/06"], ["5069", "RAMAG EXAM REGISTER", "Remote Procedure", "RADIOLOGY/NUCLEAR MEDICINE", "2008/01/16", "APPROVED", "Active", "Private", "", "
The RAMAG EXAM REGISTER remote procedure registers the
Radiology exam and returns identifiers of the new case(s) in the RAD/NUC MED
PATIENT file (#70). It also sends all required notifications.\n
Input Parameters
================\n
RAOIFN IEN of the order in the RAD/NUC MED ORDERS file (#75.1).\n
EXMDTE Date and time of the exam in HL7 format (TS):
YYYYMMDDHHMM[+/-ZZZZ]. If seconds are provided,
they are ignored. The date must be exact and the
time is required.\n
[RAMSC] Items of this list define miscellaneous/optional
order parameters. Each record has 3 or more pieces
separated by '^':\n
^01: Parameter name
^02: Index (for multiples and word-processing)
^03: Value1
^04: Value2
...\n
The following parameters are supported by this remote
procedure:\n
BEDSECT^^{IEN #42.4}
Internal value for the BEDSECTION field (19) of
the EXAMINATIONS multiple (sub-file #70.03).\n
EXAMCAT^^{C|E|I|O|R|S}
Value for the CATEGORY OF EXAM field (4) of the
EXAMINATIONS multiple (sub-file #70.03).\n
FLAGS^^{flags}
Flags that control the execution (can be combined):\n
A If this flag is provided, then the registration
entry point adds the new case to the existing
ones with the same date/time instead of
returning the error code -28.\n
If the existing date/time record stores an exam
set and the "D" flag is not provided, then the
error code -54 is returned.\n
D If there is an existing case with the same
date/time, then the time of the new case is
incremented by 1 minute until an unused date/time
is found.\n
If the "A" flag is also provided, then time
increments also stop when a non-examset
date/time record is found.\n
If the date is also changed during the time
modification, then the case is not registered and
the error code -29 is returned.\n
PRINCLIN^^{IEN #44}
Internal value for the PRINCIPAL CLINIC field (8) of
the EXAMINATIONS multiple (sub-file #70.03).\n
RAPROC^{Seq#}^{IEN #71}^{IEN #71.2}^{IEN #71.2}^...
Radiology procedure and optional modifiers.\n
SERVICE^^{IEN #49}
Internal value for the SERVICE field (7) of
the EXAMINATIONS multiple (sub-file #70.03).\n
SINGLERPT^^{0|1}
If this parameter is defined and not 0, then all
cases should be associated with the same order
and they will share the same report. See the
MEMBER OF SET (25) and IMAGING ORDER (11) fields
of the sub-file #70.03 for more details.\n
TECHCOMM^^{text}
Value for the TECHNOLOGIST COMMENT field (4) of
the ACTIVITY LOG multiple (sub-file #70.07).\n
WARD^^{IEN #42}
Internal value for the WARD field (6) of
the EXAMINATIONS multiple (sub-file #70.03).\n
Records can be added to the list in any order.\n
Example:\n
with RPCBroker.Param[2] do
begin
PType := list;
Mult[1] := 'BEDSECT^^12';
Mult[2] := 'SERVICE^^43';
Mult[3] := 'WARD^^456';
Mult[4] := 'EXAMCAT^^I';
end;\n
Results
=======\n
A negative value of the first '^'-piece of the Results[0] indicates that an
error occurred during the execution of the remote procedure. In this case, the
second piece of the Results[0] will contain number of the error descriptors
returned in the subsequent nodes of the Results array.\n
Results[0] Result descriptor
^01: The last error code
^02: Number of error descriptors\n
Results[i] Error descriptor
^01: Error code
^02: Message
^03: Error location
^04: Error type\n
Results[j] Line of the additional info
^01: "" (empty)
^02: Text\n
Error descriptors are returned in reverse chronological order (most recent
first).\n
Otherwise, number of registered examinations is returned in the Results[0] and
identifiers of the examinations are returned in the subsequent elements of the
array.\n
Results[0] Number of registered examinations\n
Results[i] Exam/case identifiers
^01: IEN of the patient in the file #70
^02: IEN in the REGISTERED EXAMS multiple
^03: IEN in the EXAMINATIONS multiple
^04: Case number
^05: Accession number
SSS-MMDDYY-NNNNN if RA*5*47 is installed;
MMDDYY-NNNNN otherwise.
^06: Actual date and time of the case in
HL7 format (TS): YYYYMMDD[HHMM[+/-ZZZZ]]\n
Notes
=====\n
See comments in the source code of the RAMAG03 routine and description of the
RAMAG EXAM REGISTER remote procedure for additional and/or most recent
details.", "", "", "2008/10/06"], ["5070", "Utility to return AUTHORIZE RELEASE OF NPI field", "Routine", "KERNEL", "2008/01/16", "APPROVED", "Active", "Controlled Subscription", "", "
An API that returns the value of the field AUTHORIZE
RELEASE OF NPI (#41.97) from an entry in the NEW PERSON file (#200).", "", "XUSNPI", "2008/01/29"], ["5071", "RAMAG EXAMINED", "Remote Procedure", "RADIOLOGY/NUCLEAR MEDICINE", "2008/01/16", "APPROVED", "Active", "Private", "", "
The RAMAG EXAMINED remote procedure upodates the status
of the case (the procedure has been performed) and creates the stub report. It
also sends required HL7 messages, sends changed order control "XX" to CPRS,
but does not send VistA alerts regarding the exam status change.\n
Input Parameters
================\n
RAEXAM String of exam/case identifiers separated by '^'
^01: IEN of the patient in the RAD/NUC MED
PATIENT file (#70)
^02: IEN in the REGISTERED EXAMS multiple
(sub-file #70.02)
^03: IEN in the EXAMINATIONS multiple
(sub-file #70.03)\n
[RAMSC] Items of this list define miscellaneous/optional
order parameters. Each record has 3 or more pieces
separated by '^':\n
^01: Parameter name
^02: Index (for multiples and word-processing)
^03: Value1
^04: Value2
...\n
The following parameters are supported by this remote
procedure:\n
CMUSED^^{Y|N}
Internal value for the CONTRAST MEDIA USED
field (10) of the sub-file #70.03.\n
COMPLICAT^^{IEN #78.1}^{text}
Internal values for the COMPLICATION (16)
and COMPLICATION TEXT (16.5) fields of the
sub-file #70.03.\n
CONTMEDIA^{Seq#}^{I|N|L|C|G|B|M}
Internal value for the CONTRAST MEDIA field (.01)
of the sub-file #70.3225.\n
CPTMODS^{Seq#}^{IEN #81.3}
Internal value for the CPT MODIFIERS field (.01)
of the sub-file #70.3135: IEN in the CPT MODIFIER
file (#81.3).\n
FILMSIZE^{Seq#}^{IEN #78.4}^{amount}
Internal values for the record of the FILM SIZE
multiple (70) of the sub-file #70.03.\n
FLAGS^^{flags}
Flags that control the execution (can be combined):\n
F Try to enforce the new status even if some
required fields are not populated.\n
S Do not send HL7 message to speech recognition
(dictation) systems\n
PRIMCAM^^{IEN #78.6}
Internal value for the PRIMARY CAMERA/EQUIP/RM
field (18) of the sub-file #70.03: IEN in the
CAMERA/EQUIP/RM file (#78.6).\n
PRIMDXCODE^^{IEN #78.3}
Internal value for the PRIMARY DIAGNOSTIC
CODE field (13) of the sub-file #70.03:
IEN in the DIAGNOSTIC CODES file (#78.3).\n
PRIMINTRES^^{IEN #200}
Internal value for the PRIMARY INTERPRETING
RESIDENT field (12) of the sub-file #70.03:
IEN in the NEW PERSON file (#200).\n
PRIMINTSTF^^{IEN #200}
Internal value for the PRIMARY INTERPRETING
STAFF field (15) of the sub-file #70.03:
IEN in the NEW PERSON file (#200).\n
RAPROC^1^{IEN #71}^{IEN #71.2}^{IEN #71.2}^...
Radiology procedure and optional modifiers.\n
RDPHARMS^{Seq#}
Opening/closing tag of the record of internal
values for the 'RADIOPHARMACEUTICALS' multiple
(100) of the 'NUC MED EXAM DATA' file (#70.2).\n
RDPH-ACDR^^{value}
Internal value for the ACTIVITY DRAWN
field (4).\n
RDPH-DOSE^^{value}
Internal value for the DOSE ADMINISTERED
field (7).\n
RDPH-DRUG^^{IEN #50}
Internal value for the RADIOPHARMACEUTICAL
field (.01).\n
RDPH-DTADM^^{date/time}
Internal value for the DATE/TIME DOSE
ADMINISTERED field (8).\n
RDPH-DTDRW^^{date/time}
Internal value for the DATE/TIME DRAWN
field (5).\n
RDPH-FORM^^{A|G|L|P|S}
Internal value for the FORM field (15).\n
RDPH-LOTN^^{IEN #71.9}
Internal value for the LOT NO field (13).\n
RDPH-PWADM^^{IEN #200}
Internal value for the PERSON WHO ADMINISTERED
DOSE field (9).\n
RDPH-PWMSD^^{IEN #200}
Internal value for the PERSON WHO MEASURED DOSE
field (6).\n
RDPH-ROUTE^^{IEN #71.6}
Internal value for the ROUTE OF ADMINISTRATION
field (11).\n
RDPH-SITE^^{IEN #71.7}
Internal value for the SITE OF ADMINISTRATION
field (12).\n
RDPH-VOL^^{value}
Internal value for the VOLUME field (14).\n
TECH^{Seq#}^{IEN #200}
Internal value for the TECHNOLOGIST field (.01)
of the subfile #70.12: IEN in the NEW PERSON
file (#200).\n
TECHCOMM^^{text}
Value for the TECHNOLOGIST COMMENT field (4) of the
ACTIVITY LOG multiple (sub-file #70.07).\n
The following optional parameters are also supported:
BEDSECT, EXAMCAT, PRINCLIN, SERVICE, and WARD. If any
of them are defined, their values replace the existing
ones assigned by the RAMAG EXAM REGISTER remote
procedure.\n
Records can be added to the list in any order.\n
If you want to clear a multiple that already has a
value, assign "@" or empty string to the parameter
itself and do not set any subscripts. For example,
the following construction will clear the CONTRAST
MEDIA multiple: Mult[i] := 'CONTMEDIA^^@'.\n
Example:\n
with RPCBroker.Param[1] do
begin
PType := list;
Mult[1] := 'CMUSED^^N';
Mult[2] := 'FILMSIZE^1^7^2';
Mult[3] := 'FILMSIZE^2^3^1';
Mult[4] := 'PRIMCAM^^3';
Mult[5] := 'TECH^1^2344';
Mult[6] := 'FLAGS^^F';\n
Mult[7] := 'RDPHARMS^1';
Mult[8] := 'RDPH-DRUG^^23';
Mult[9] := 'RDPH-DOSE^^.002';
Mult[10] := 'RDPH-FORM^^A';\n
Mult[11] := 'RDPHARMS^2';
Mult[12] := 'RDPH-DRUG^^23';
Mult[13] := 'RDPH-DOSE^^.002';
Mult[14] := 'RDPHARMS^2'; // Record closing tag is required
// if something else than another
// record of the same kind follows.
Mult[15] := 'COMPLICAT^^13';
end;\n
Results
=======\n
A negative value of the first '^'-piece of the Results[0] indicates that an
error occurred during the execution of the remote procedure. In this case, the
second piece of the Results[0] will contain number of the error descriptors
returned in the subsequent nodes of the Results array.\n
Results[0] Result descriptor
^01: The last error code
^02: Number of error descriptors\n
Results[i] Error descriptor
^01: Error code
^02: Message
^03: Error location
^04: Error type\n
Results[j] Line of the additional info
^01: "" (empty)
^02: Text\n
Error descriptors are returned in reverse chronological order (most recent
first).\n
Otherwise, 0 is returned in the Results[0].\n
Notes
=====\n
See comments in the source code of the RAMAG07 routine and description of the
RAMAG EXAMINED remote procedure for additional and/or most recent details.", "", "", "2008/10/06"], ["5072", "RAMAG EXAM COMPLETE", "Remote Procedure", "RADIOLOGY/NUCLEAR MEDICINE", "2008/01/16", "APPROVED", "Active", "Private", "", "
The RAMAG EXAM COMPLETE remote procedure completes the
exam. It also sends required HL7 messages, sends changed order control "XX" to
CPRS, but does not send VistA alerts regarding the exam status change.\n
Input Parameters
================\n
RAEXAM String of exam/case identifiers separated by '^'
^01: IEN of the patient in the RAD/NUC MED
PATIENT file (#70)
^02: IEN in the REGISTERED EXAMS multiple
(sub-file #70.02)
^03: IEN in the EXAMINATIONS multiple
(sub-file #70.03)\n
[RAMSC] Items of this list define miscellaneous/optional
order parameters. Each record has 3 or more pieces
separated by '^':\n
^01: Parameter name
^02: Index (for multiples and word-processing)
^03: Value1
^04: Value2
...\n
The following parameters are supported by this remote
procedure:\n
ACLHIST^{Seq#}^{Line of clinical history}
Text for the ADDITIONAL CLINICAL HISTORY field
(400) of the RAD/NUC MED REPORTS file (#74).\n
FLAGS^^{flags}
Flags that control the execution (can be combined):\n
F Try to enforce the new status even if some
required fields are not populated.\n
S Do not send HL7 message to speech recognition
(dictation) systems\n
IMPRESSION^{Seq#}^{Line of impression text}
Text for the IMPRESSION TEXT field (300)
of the file #74.\n
PROBSTAT^^{text}
Value for the PROBLEM STATEMENT field (25)
of the file #74.\n
REPORT^{Seq#}^{Line of report text}
Text for the REPORT TEXT field (200)
of the file #74.\n
RPTDTE^^{date}
Date in HL7 format (TS) for the REPORTED DATE
field (8) of the file #74: YYYYMMDD. The date
must be exact. If a time part is provided, it
is ignored.\n
RPTSTATUS^^{status}
Internal value for the REPORT STATUS field (5)
of the file #74.\n
TRANSCRST^^{IEN #200}
Internal value for the TRANSCRIPTIONIST
field (11) of the file #74: IEN in the NEW
PERSON file (#200).\n
VERDTE^^{date}
Date/time in HL7 format (TS) for the
VERIFIED DATE field (7) of the file #74:
YYYYMMDD[HHMM[+/-ZZZZ]]. The date must be
exact.\n
VERPHYS^^{IEN #200}
Internal value for the VERIFYING PHYSICIAN
field (9) of the file #74: IEN in the NEW
PERSON file (#200).\n
The following optional parameters are also supported:
BEDSECT, CMUSED, COMPLICAT, CONTMEDIA, CPTMODS, EXAMCAT,
FILMSIZE, PRIMCAM, PRIMDXCODE, PRIMINTRES, PRIMINTSTF,
PRINCLIN, RDPHARMS, RDPH-*, SERVICE, TECH, TECHCOMM, and
WARD. If any of them are defined, their values replace the
existing ones assigned by the RAMAG EXAM REGISTER and
RAMAG EXAMINED remote procedures.\n
Records can be added to the list in any order.\n
If you want to clear a multiple that already has a
value, assign "@" or empty string to the parameter
itself and do not set any subscripts. For example,
the following construction will clear the CONTRAST
MEDIA multiple: Mult[i] := 'CONTMEDIA^^@'.\n
Example:\n
with RPCBroker.Param[4] do
begin
PType := list;
Mult[1] := 'PRIMDXCODE^^1';
Mult[2] := 'CONTMEDIA^^N';
Mult[3] := 'REPORT^1^Report line #1';
Mult[4] := 'REPORT^2^Report line #2';
Mult[5] := 'IMPRESSION^1^Impression line #1';
Mult[6] := 'FLAGS^^FS';
Mult[7] := 'RPTDTE^^20071215';
end;\n
Results
=======\n
A negative value of the first '^'-piece of the Results[0] indicates that an
error occurred during the execution of the remote procedure. In this case, the
second piece of the Results[0] will contain number of the error descriptors
returned in the subsequent nodes of the Results array.\n
Results[0] Result descriptor
^01: The last error code
^02: Number of error descriptors\n
Results[i] Error descriptor
^01: Error code
^02: Message
^03: Error location
^04: Error type\n
Results[j] Line of the additional info
^01: "" (empty)
^02: Text\n
Error descriptors are returned in reverse chronological order (most recent
first).\n
Otherwise, 0 is returned in the Results[0].\n
Notes
=====\n
See comments in the source code of the RAMAG06 routine and description of the
RAMAG EXAM COMPLETE remote procedure for additional and/or most recent
details.", "", "", "2008/10/06"], ["5073", "RAMAG EXAM STATUS REQUIREMENTS", "Remote Procedure", "RADIOLOGY/NUCLEAR MEDICINE", "2008/01/16", "APPROVED", "Active", "Private", "", "
The RAMAG EXAM STATUS REQUIREMENTS remote procedure
returns a descriptor that indicates conditions that should be met in order to
successfully perform an action on a Radiology exam/case record.\n
These conditions are defined by the sites and stored in the EXAMINATION STATUS
file (#72). See the .1 and .5 nodes of the data dictionary of the file #74 for
more details.\n
Input Parameters
================\n
RACTION The RACTION parameter defines the action that is going
to be performed on an exam/case record:\n
E Examined (procedure has been performed,
images have been acquired)\n
C Complete\n
RAIMGTYI IEN of the imaging type in the IMAGING TYPE file (#79.2).\n
RAPROC Radiology procedure IEN (file #71). This parameter is
required to determine exact nuclear medicine requirements
(pieces of the Results[0] from 17 to 25).\n
By default (+$G(RAPROC)=0), this remote procedure cannot
examine the SUPPRESS RADIOPHARM PROMPT field (2) of the
RAD/NUC MED PROCEDURES file (#71) and might indicate that
some nuclear medicine data is required even if it is not.\n
Results
=======\n
A negative value of the first '^'-piece of the Results[0] indicates that an
error occurred during the execution of the remote procedure. In this case, the
second piece of the Results[0] will contain number of the error descriptors
returned in the subsequent nodes of the Results array.\n
Results[0] Result descriptor
^01: The last error code
^02: Number of error descriptors\n
Results[i] Error descriptor
^01: Error code
^02: Message
^03: Error location
^04: Error type\n
Results[j] Line of the additional info
^01: "" (empty)
^02: Text\n
Error descriptors are returned in reverse chronological order (most recent
first).\n
Otherwise, exam status requirements are returned in the Results[0].
Descriptor of the exam status is returned in the Results[1].\n
Results[0] Exam status requirements
^01: TECHNOLOGIST REQUIRED? {0|1}
^02: RESIDENT OR STAFF REQUIRED? {0|1}
^03: DETAILED PROCEDURE REQUIRED? {0|1}
^04: FILM ENTRY REQUIRED? {0|1}
^05: DIAGNOSTIC CODE REQUIRED? {0|1}
^06: CAMERA/EQUIP/RM REQUIRED? {0|1}
^07: reserved
^08: reserved
^09: reserved
^10: reserved
^11: REPORT ENTERED REQUIRED? {0|1}
^12: VERIFIED REPORT REQUIRED? {0|1}
^13: PROCEDURE MODIFIERS REQUIRED? {0|1}
^14: CPT MODIFIERS REQUIRED? {0|1}
^15: reserved
^16: IMPRESSION REQUIRED? {0|1}
^17: RADIOPHARMS/DOSAGES REQUIRED? {0|1}
^18: reserved
^19: ACTIVITY DRAWN REQUIRED? {0|1}
^20: DRAWN DT/TIME/PERSON REQUIRED? {0|1}
^21: ADM DT/TIME/PERSON REQUIRED? {0|1}
^22: reserved
^23: ROUTE/SITE REQUIRED? {0|1}
^24: LOT NO. REQUIRED? {0|1}
^25: VOLUME/FORM REQUIRED? {0|1}\n
Results[1] Status descriptor
^01: Status IEN
^02: Status name
^03: Status code (order)
^04: VistARAD category
^05: Generic exam status characteristics\n
Notes
=====\n
See comments in the source code of the RAMAGU06 routine and description of the
RAMAG EXAM STATUS REQUIREMENTS remote procedure for additional and/or most
recent details.", "", "", "2008/10/06"], ["5074", "RAMAG ORDER CANCEL", "Remote Procedure", "RADIOLOGY/NUCLEAR MEDICINE", "2008/01/16", "APPROVED", "Active", "Private", "", "
The RAMAG ORDER CANCEL remote procedure cancels/holds
the Radiology order and sends all required notifications.\n
Input Parameters
================\n
RAOIFN IEN of the order in the RAD/NUC MED ORDERS file (#75.1).\n
RAREASON Cancel/hold reason: either IEN of a record of the
RAD/NUC MED REASON file (#75.2) or a valid synonym
(see SYNONYM field (3) of that file).\n
The referenced record must have the appropriate type
(see TYPE OF REASON field (2) of the file #75.2):\n
* If the reason record has the CANCEL REQUEST (1)
type, then the 'HOLDESC' (see the RAMSC parameter)
is ignored and the order is canceled.\n
* If the reason record is of the HOLD REQUEST (3)
type, then the order is put on hold. If the
'HOLDESC' parameter is defined, the text is stored
into the HOLD DESCRIPTION field.\n
* If the record is of the GENERAL REQUEST type (9),
then the new order status is determined by the
'HOLDESC' parameter. If it is defined, then the
order is put on hold; otherwise, the order is
canceled.\n
[RAMSC] Items of this list define miscellaneous/optional
order parameters. Each record has 3 or more pieces
separated by '^':\n
^01: Parameter name
^02: Index (for multiples and word-processing)
^03: Value1
^04: Value2
...\n
The following records are supported by this remote
procedure:\n
HOLDESC^{Seq#}^{Line of hold description}
Text for the HOLD DESCRIPTION field (25)
of the file #75.1.\n
Records can be added to the list in any order.\n
Examples:\n
with RPCBroker.Param[2] do
begin
PType := list;
Mult[1] := 'HOLDESC^1^Hold description line #1';
Mult[2] := 'HOLDESC^2^Hold description line #2';
end;\n
Results
=======\n
A negative value of the first '^'-piece of the Results[0] indicates that an
error occurred during the execution of the remote procedure. In this case, the
second piece of the Results[0] will contain number of the error descriptors
returned in the subsequent nodes of the Results array.\n
Results[0] Result descriptor
^01: The last error code
^02: Number of error descriptors\n
Results[i] Error descriptor
^01: Error code
^02: Message
^03: Error location
^04: Error type\n
Results[j] Line of the additional info
^01: "" (empty)
^02: Text\n
Error descriptors are returned in reverse chronological order (most recent
first).\n
Otherwise, 0 is returned in the Results[0].\n
Notes
=====\n
If there are active cases in the RAD/NUC MED PATIENT file (#70) associated
with an order, this remote procedure neither cancels nor holds the order and
returns the error code -42.\n
See comments in the source code of the RAMAG04 routine and description of the
RAMAG ORDER CANCEL remote procedure for additional and/or most recent details.\n", "", "", "2008/10/06"], ["5075", "RAMAG EXAM CANCEL", "Remote Procedure", "RADIOLOGY/NUCLEAR MEDICINE", "2008/01/16", "APPROVED", "Active", "Private", "", "
The RAMAG EXAM CANCEL remote procedure cancels the
Radiology exam(s) and sends all required notifications.\n
If all exams that reference the same order/request are canceled, this
function can also cancel/hold the order (if the appropriate parameters are
provided).\n
Input Parameters
================\n
RAEXAM String of exam/case identifiers separated by '^'
^01: IEN of the patient in the RAD/NUC MED
PATIENT file (#70)
^02: IEN in the REGISTERED EXAMS multiple
(sub-file #70.02)
^03: IEN in the EXAMINATIONS multiple
(sub-file #70.03)\n
RAREASON Reason for cancelation: either IEN of a record of
the RAD/NUC MED REASON file (#75.2) or a valid
synonym (see SYNONYM field (3) of the file #75.2).
The referenced record must have the 'CANCEL REQUEST'
or 'GENERAL REQUEST' type (see TYPE OF REASON field
(2) of the file #75.2).\n
[RAFLAGS] Flags that control execution (can be combined):\n
A Cancel all related exams/cases (those that
reference the same order).\n
O Cancel/hold the related order after successful
exam cancelation.\n
The order will be canceled or put on hold only
if there are no more active cases associated
with it.\n
Otherwise, the error code -42 will be returned.
Use the "A" flag to cancel all related exams
and guarantee the order cancelation.\n
[RAMSC] Items of this list define miscellaneous/optional
order parameters. Each record has 3 or more pieces
separated by '^':\n
^01: Parameter name
^02: Index (for multiples and word-processing)
^03: Value1
^04: Value2
...\n
The following records are supported by this remote
procedure:\n
HOLDESC^{Seq#}^{Line of hold description}
Text for the HOLD DESCRIPTION field (25)
of the file #75.1.\n
ORDRSN^^{Cancel/hold reason for related order}
Either IEN of a record of the RAD/NUC MED
REASON file (#75.2) or a valid synonym
(see SYNONYM field (3) of that file).\n
If this parameter is not defined or empty,
the value of the RAREASON parameter is
assumed.\n
Records can be added to the list in any order.\n
If the RAFLAGS parameter contains the 'O' flag,
the 'ORDRSN' and 'HOLDESC' parameters determine
whether the related order is canceled or put on
hold. Otherwise, they are ignored.\n
* If the reason record referenced by the 'ORDRSN'
has the CANCEL REQUEST (1) type, then the 'HOLDESC'
is ignored and the order is canceled.\n
* If the record referenced by the 'ORDRSN' is of
the HOLD REQUEST (3) type, then the order is put
on hold. If the 'HOLDESC' is defined, the text is
stored into the HOLD DESCRIPTION field.\n
* If the record referenced by the 'ORDRSN' is of
the GENERAL REQUEST type (9), then the action
performed on the order is determined by the
'HOLDESC'. If it is defined, then the order is
put hold; otherwise, the order is canceled.\n
Examples:\n
with RPCBroker.Param[2] do
begin
PType := list;
Mult[1] := 'ORDRSN^^OHR';
Mult[2] := 'HOLDESC^1^Hold description line #1';
Mult[3] := 'HOLDESC^2^Hold description line #2';
end;\n
Results
=======\n
A negative value of the first '^'-piece of the Results[0] indicates that an
error occurred during the execution of the remote procedure. In this case, the
second piece of the Results[0] will contain number of the error descriptors
returned in the subsequent nodes of the Results array.\n
Results[0] Result descriptor
^01: The last error code
^02: Number of error descriptors\n
Results[i] Error descriptor
^01: Error code
^02: Message
^03: Error location
^04: Error type\n
Results[j] Line of the additional info
^01: "" (empty)
^02: Text\n
Error descriptors are returned in reverse chronological order (most recent
first).\n
Otherwise, 0 is returned in the Results[0].\n
Notes
=====\n
See comments in the source code of the RAMAG05 routine and description of the
RAMAG EXAM CANCEL remote procedure for additional and/or most recent details.", "", "", "2008/10/06"], ["5076", "MDCLIO1", "Routine", "CLINICAL PROCEDURES", "2008/01/17", "", "Other", "Private", "", "
The MDCLIO1 routine provides Clinical Observations
data.\n
Note: This API is only for the Vitals package and will not be approved for
other packages.", "", "MDCLIO1", "2008/03/19"], ["5077", "Radiology write with FM privilege to the NEW PERSON file", "File", "KERNEL", "2008/01/18", "APPROVED", "Active", "Private", "200", "
VistA Radiology requests the privilege to write to the
NEW PERSON file using approved FileMan utilities. Radiology requests this
privilege because the package specific Application Proxy User (APU)
'RADIOLOGY, OUTSIDE SERVICE' requires two additional data attributes in order
to normalize radiology workflow.\n
VistA Radiology requests that we be able to use FileMan to write to the
following fields in the NEW PERSON file:\n
* RAD/NUC MED CLASSIFICATION (#72) sub-file: 200.072 * PERSON CLASS (#8932.1)
sub-file: 200.05 * Effective Date (case sensitive) sub-file: 200.05, field: 2\n
RAD/NUC MED CLASSIFICATION is required to move a radiology exam through to the
COMPLETE status.\n
PERSON CLASS is required to credit workload. Without a PERSON CLASS attribute
a PERSON CLASS exception for this patient care encounter event.\n
Effective Date is the date that this Person Class became effective for this
individual.\n
Please note that the lifespan of this Integration Agreement is to be short.
Once the patch is released, and the grace period for mandatory patch
installations period has passed, it is my intention that this IA be purged.", "", "", "2008/01/18"], ["5078", "API Set for Data Standardization", "Routine", "TOOLKIT", "2008/01/23", "APPROVED", "Active", "Supported", "", "
High Level Examples\n
Assume the following replacement relationships:\n\n
A --> B --> C --> D A is replaced by B G is replaced by C
^ ^ ^ ^ B is replaced by C H is replaced by C
| \\ | \\ C is replaced by D I is replaced by F
| \\ | \\ D has no replacement J is replaced by F
| \\ | \\ E is replaced by A K is replaced by H
| F | H F is replaced by A L is replaced by H
| ^ ^ | ^ ^
| / \\ | / \\
E I J G K L\n
$$GETRPLC(B) would return C\n
$$RPLCMNT(B) would return D\n
$$RPLCVALS(J) would return the requested field values from entry D\n
$$RPLCTRL(G) in both directions would return D and the output array would be
set as follows:\n
OutArr("BY",A) = B OutArr("FOR",A,E) = ""
OutArr("BY",B) = C OutArr("FOR",A,F) = ""
OutArr("BY",C) = D OutArr("FOR",B,A) = ""
OutArr("BY",D) = "" OutArr("FOR",C,B) = ""
OutArr("BY",E) = A OutArr("FOR",C,G) = ""
OutArr("BY",F) = A OutArr("FOR",C,H) = ""
OutArr("BY",G) = C OutArr("FOR",D,C) = ""
OutArr("BY",H) = C OutArr("FOR",F,I) = ""
OutArr("BY",I) = F OutArr("FOR",F,J) = ""
OutArr("BY",J) = F OutArr("FOR",H,K) = ""
OutArr("BY",K) = H OutArr("FOR",H,L) = ""
OutArr("BY",L) = H\n
$$RPLCTRL(L) in the forward direction would return D and the output array
would be set as follows:\n
OutArr("BY",C) = D OutArr("FOR",C,H) = ""
OutArr("BY",D) = "" OutArr("FOR",D,C) = ""
OutArr("BY",H) = C OutArr("FOR",H,L) = ""
OutArr("BY",L) = H\n
$$RPLCTRL(B) in the backward direction would return D and the output array
would be set as follows:\n
OutArr("BY",A) = B OutArr("FOR",A,E) = ""
OutArr("BY",E) = A OutArr("FOR",A,F) = ""
OutArr("BY",F) = A OutArr("FOR",B,A) = ""
OutArr("BY",I) = F OutArr("FOR",F,I) = ""
OutArr("BY",J) = F OutArr("FOR",F,J) = ""\n
$$RPLCLST(G) in both directions would return D and the output array would be
set as follows:\n
OutArr(1) = G ^ 0 OutArr("INDEX",A) = 8
OutArr(2) = C ^ 0 OutArr("INDEX",B) = 7
OutArr(3) = D ^ 1 OutArr("INDEX",C) = 2
OutArr(4) = H ^ 0 OutArr("INDEX",D) = 3
OutArr(5) = K ^ 0 OutArr("INDEX",E) = 9
OutArr(6) = L ^ 0 OutArr("INDEX",F) = 10
OutArr(7) = B ^ 0 OutArr("INDEX",G) = 1
OutArr(8) = A ^ 0 OutArr("INDEX",H) = 4
OutArr(9) = E ^ 0 OutArr("INDEX",I) = 11
OutArr(10) = F ^ 0 OutArr("INDEX",J) = 12
OutArr(11) = I ^ 0 OutArr("INDEX",K) = 5
OutArr(12) = J ^ 0 OutArr("INDEX",L) = 6\n
$$RPLCLST(L) in the forward direction would return D and the output array
would be set as follows if the status history was also included:\n
OutArr(1) = L ^ 0 OutArr("INDEX",C) = 3
OutArr(1,3080101.0954) = 0 OutArr("INDEX",D) = 4
OutArr(2) = H ^ 0 OutArr("INDEX",H) = 2
OutArr(2,3080101.1308) = 1 OutArr("INDEX",L) = 1
OutArr(2,3080105.09) = 0
OutArr(3) = C ^ 0
OutArr(3,3080105.0859) = 1
OutArr(3,3080112.1722) = 0
OutArr(4) = D ^ 1
OutArr(4,3080112.1723) = 1\n
$$RPLCLST(B) in the backward direction would return D and the output array
would be set as follows:\n
OutArr(1) = A ^ 0 OutArr("INDEX",A) = 1
OutArr(2) = E ^ 0 OutArr("INDEX",E) = 2
OutArr(3) = F ^ 0 OutArr("INDEX",F) = 3
OutArr(4) = I ^ 0 OutArr("INDEX",I) = 4
OutArr(5) = J ^ 0 OutArr("INDEX",J) = 5\n", "", "XTIDTRM", "2015/06/08"], ["5079", "5079 - FBAA79 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Request access to GOT^FBAA79 for FBCS (Fee Basis
Compliance Suite).", "", "FBAA79", "2009/06/11"], ["5080", "5080 - FBAACCB0 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to FBCKT and ENV^FBAACCB0 for FBCS.", "", "FBAACCB0", "2009/06/11"], ["5081", "5081 - FBAACCB2 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to FBAACCB2 requested for support of FBCS", "", "FBAACCB2", "2009/06/11"], ["5082", "5082 - FBAACO For FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
Access to FBAACO for FBCS.\n
SITE^FBAACO (set up site variables)", "", "FBAACO", "2009/06/11"], ["5083", "5083 - FBAADD for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBAADD", "2009/06/11"], ["5084", "5084 - FBAADV for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to CHVEN^FBAADV for FBCS.", "", "FBAADV", "2009/06/11"], ["5085", "5085 - FBAAFA for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
FBCS Access to Subs:
LOADADJ^FBAAFA (Load Adjustments FROM FILE 162.03)
ADJLRA^FBAAFA (Adjustment Reason^Amount List Extrinsic Function)
FILEADJ^FBAAFA (File Adjustments FOR 162.03)", "", "FBAAFA", "2009/06/11"], ["5086", "5086 - FBAAFR for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to FILERR^FBAAFR and RRL^FBAAFR for FBCS.", "", "FBAAFR", "2009/06/11"], ["5087", "5087 - FBAAFS for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to FAC^FBAAFS and GET^FBAAFS for FBCS.", "", "FBAAFS", "2009/06/11"], ["5088", "5088 - FBAARB for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to CNTTOT^FBAARB for FBCS.", "", "FBAARB", "2009/06/11"], ["5089", "5089- FBAARR for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to CKSPLIT^FBAARR for FBCS.", "", "FBAARR", "2009/06/11"], ["5090", "5090 - FBAAUTL for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBAAUTL", "2009/06/11"], ["5091", "5091 - FBAAUTL4 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access requested for several access points to support
FBCS. Access points: $$APS,$$CPT,$$MODL,$$CHKBI,REPMOD and MODDATA", "", "FBAAUTL4", "2009/06/11"], ["5092", "5092 - FBAAUTL5 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to PSA^FBAAUTL5 needed for FBCS.", "", "FBAAUTL5", "2009/06/11"], ["5093", "5093 - FBAAV01 for FBCS(DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to several access points needed to support FBCS.
Access points: ADDRESS,NEWMSG,STORE,XMIT,PADZ,STRING\n
FBCS needs to be able to fire off formatted email messages to Austin.", "", "FBAAV01", "2009/06/11"], ["5094", "5094 - FBAAV6 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Private", "", "", "", "FBAAV6", "2009/06/11"], ["5095", "5095 - FBAAVR0 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBAAVR0", "2009/06/11"], ["5096", "5096 - FBCHFA for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "
Access to ADJLRA^FBCHFA needed to support FBCS. and
FILEADJ^FBCHFA", "", "FBCHFA", "2009/06/11"], ["5097", "5097 - FBCHREQ2 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBCHREQ2", "2009/06/11"], ["5098", "5098 - FBCSV1 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBCSV1", "2009/06/11"], ["5099", "5099 - FBUCUTL for FBCS(DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBUCUTL", "2009/06/11"], ["5100", "5100 - FBUCUTL2 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBUCUTL2", "2009/06/11"], ["5101", "5101 - FBAAUTL1 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Withdrawn", "Controlled Subscription", "", "
Request access to PLUSOB^FBAAUTL1 for FBCS (DSS)", "", "FBAAUTL1", ""], ["5102", "5102 - FBUTL4 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/01/31", "", "Retired", "Controlled Subscription", "", "", "", "FBUTL4", "2009/06/11"], ["5103", "5103 - IBBFAPI for FBCS (DSS)", "Routine", "INTEGRATED BILLING", "2008/01/31", "", "Withdrawn", "Controlled Subscription", "", "", "", "IBBFAPI", ""], ["5104", "FBCS File #162.4 R/W/D", "File", "FEE BASIS", "2008/01/31", "APPROVED", "Active", "Controlled Subscription", "162.4", "
FBCS performs the following accesses against the VA
FORM 10-7078 (#162.4) file.\n
^FB7078(D0,0) Global r ($D)
.01 REFERENCE NUMBER 0;1 Fileman r/w,Global r
1 VENDOR 0;2 Fileman r/w,Global r
2 VETERAN 0;3 Fileman r/w,Global r
3 AUTHORIZATION FROM D 0;4 Fileman r/w,Global r
4 AUTHORIZATION TO DAT 0;5 Fileman r/w,Global r
5 AUTHORITY 0;6 Fileman r/w
6 ESTIMATED AMOUNT 0;7 Fileman r/w
8 USER ENTERING 0;8 Fileman r/w,Global r
9 STATUS 0;9 Fileman r/w,Global r
10 DATE OF ISSUE 0;10 Fileman r/w
.5 FEE PROGRAM 0;11 Fileman r/w,Global r
12 REASON FOR PENDING D 0;12 Fileman r/w
.013 USER WHO CANCELLED 0;13 Fileman r/w
.014 DATE CANCELLED 0;14 Fileman r/w
3.5 DATE OF ADMISSION 0;15 Fileman r/w,Global r
4.5 DATE OF DISCHARGE 0;16 Fileman r/w
15 REFERRING PROVIDER 0;17 Fileman r,Global r
^FB7078(D0,1,0)
7 AUTHORIZED SERVICES
^FB7078(D0,1,D1,0)
.01 AUTHORIZED SERVICES 0;1 Fileman r
^FB7078(D0,LOG1,D1,0)
.01 DATE/TIME EDITED 0;1 Fileman r
1 EDITED BY 0;2 Fileman r
2 COMMENTS 0;3 Fileman r\n
^FB7078("AA") Lookup by Program and Auth From Date
^FB7078("AC") Lookup by Status and Vendor
^FB7078("AD") Lookup by Program and Auth To Date
^FB7078("D") Lookup by patient", "", "", "2016/04/29"], ["5105", "5105 - FBAACCB1 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBAACCB1", "2009/06/11"], ["5106", "5106 - FBAAUTL2 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBAAUTL2", "2009/06/11"], ["5107", "FBCS FILE 162 R/W/D", "File", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "162", "
The Fee Basis Claims system accesses the FEE BASIS
PAYMENT (#162) file in order to look up and display entries and add/edit
payments.\n
^FBAAC(D0,0)
.01 PATIENT 0;1 Global r,Fileman w (laygo)
^FBAAC(D0,1,0) Global r ($D)
6 VENDOR
^FBAAC(D0,1,D1,0)
.01 VENDOR 0;1 Fileman w
^FBAAC(D0,1,D1,1,0) Global r ($D)
1 INITIAL TREATMENT DA
^FBAAC(D0,1,D1,1,D2,0)
.01 INITIAL TREATMENT DA 0;1 Global r, Fileman w
1.5 FEE PROGRAM 0;3 Global r, Fileman w
3 AUTHORIZATION POINTE 0;4 Global r, Fileman w
^FBAAC(D0,1,D1,1,D2,1,D3,0)
.01 SERVICE PROVIDED 0;1 Global r, Fileman w
1 AMOUNT CLAIMED 0;2 Global r, Fileman w
2 AMOUNT PAID 0;3 Global r, Fileman w
3 AMT SUSPENDED 0;4 Global r, Fileman w
4 SUSPEND CODE 0;5 Global r, Fileman w
5 DATE FINALIZED 0;6 Global r,Fileman r/w
6 CLERK 0;7 Global r, Fileman w
7 BATCH NUMBER 0;8 Global r/w, Fileman w
23 FEE PROGRAM 0;9 Global r, Fileman w
8 OBLIGATION NUMBER 0;10 Global r, Fileman w
3.5 DATE SUSPENDED 0;11 Fileman w
26 PRIMARY SERVICE FACI 0;12 Global r, Fileman w
27 ASSOCIATED 7078/583 0;13 Global r, Fileman w
13 DATE CORRECT INVLOIC 0;15 Global r, Fileman w
14 INVOICE NUMBER 0;16 Global r, Fileman w
15 patient type code 0;17 Global r, Fileman w
16 Purpose of visit 0;18 Global r, Fileman w
17 Treatment type code 0;19 Fileman w
18 Payment type code 0;20 Global r, Fileman w
24 Void payment 0;21 Global r
28 Primary diagnosis 0;23 Global r, Fileman w
29 VA type of service 0;24 Global r
30 PLACE OF SERVICE 0;25 Global r, Fileman w
31 HCFA type of service 0;26 Global r, Fileman w
32 Service connected co 0;27 Global r, Fileman w
^FBAAC(D0,1,D1,1,D2,1,D3,1,D4,0)
.01 DESCRIPTION OF SUSPE 0;1 Fileman w
^FBAAC(D0,1,D1,1,D2,1,D3,2)
33 VENDOR INVOICE DATE 2;1 Global r, Fileman w
34 Prompt pay type 2;2 Fileman w
42 SITE OF SERVICE ZIP 2;10 Fileman w
44 Fee schedule amount 2;13 Fileman w
45 Fee Schedule 2;13 Fileman w
47 units paid 2;14 Global r, Fileman w
48 Revenue Code 2;15 Fileman w
49 Patient account numb 2;16 Global r, Fileman w
^FBAAC(D0,1,D1,1,D2,1,D3,3)
50 FPPS claim ID 3;1 Global r, Fileman w
51 FPPS line item 3;2 Global r, Fileman w
15.5 Authorization Ptr 3;9 Globsl r, Fileman w
^FBAAC(D0,1,D1,1,D2,1,D3,7,0) Global r ($D)
52 Adjustment
^FBAAC(D0,1,D1,1,D2,1,D3,7,D4,0)
.01 Adjustment reason 0;1 Fileman r/w
1 Adjustment group 0;2 Fileman r/w
2 Adjustment Amount 0;3 Fileman r/w
^FBAAC(D0,1,D1,1,D2,1,D3,8,0) Global r
53 Remittance remark
^FBAAC(D0,1,D1,1,D2,1,D3,8,D4,0)
.01 Remittance remark 0;1 Fileman r
^FBAAC(D0,1,D1,1,D2,1,D3,FBREJ) Global kill of node
20 Reject reason FBREJ;2 Global r
^FBAAC(D0,1,D1,1,D2,1,D3,M,0) Global r
46 CPT modifier
^FBAAC(D0,1,D1,1,D2,1,D3,M,D4,0)
.01 CPT Modifier 0;1 Fileman r
^FBAAC(D0,3,D1,0)
2 TRAVEL AMOUNT 0;3 Global r
8 DATE PAID 0;6 Global r
9 CHECK NUMBER 0;7 Global r
10 CANCELLATION DATE 0;8 Global r
11 REASON CODE 0;9 Global r
12 CANCELLATION ACTIVITY 0;10 Global r
13 DISBURSED AMOUNT 0;11 Global r
14 INTEREST AMOUNT 0;12 Global r\n
^FBAAC("AB") Check for existence of record by Vendor
Used to lookup by vendor IEN
^FBAAC("AC") Check for existence of record by Batch,
Used for lookup by Batch, global set xref
^FBAAC("AD") Check for existence of record by Travel Batch,
Used for lookup by Travel Batch
^FBAAC("AE") Used to existence of record by CPT modifier
^FBAAC("AJ") Used for lookup by original Batch, global set xref
^FBAAC("AF") Check for existence of Authorization
^FBAAC("AH") Check for existence of Batch, lookup by Batch
global kill of xref for Batch
^FBAAC("AM") Check for existence of FB7078 (anc services)
^FBAAC("AN") Check for existence by Fee Program
^FBAAC("C") Check for existence by Invoice Number
^FBAAC(D2,D1,"AD") Check for existence of prior claims
^FBAAC(D2,"AB") Used to lookup by Treatment date
^FBAAC(D1,3,"AB") Check existence of data,
loop to get entries by Travel Payment Dt", "", "", "2016/04/29"], ["5108", "FBAAV1 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "
Access need to ^FBAAV1 needed for FBCS", "", "FBAAV1", "2009/06/11"], ["5109", "FBAAV3 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBAAV3", "2009/06/11"], ["5110", "FBAAV4 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "
Access to HL7NAME^FBAAV4 and ^FBAAV4 needed for FBCS", "", "FBAAV4", "2009/06/11"], ["5111", "FBAAV5 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "APPROVED", "Retired", "Private", "", "", "", "FBAAV5", "2009/06/11"], ["5112", "FBAASCB for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBAASCB", "2009/06/11"], ["5113", "FBNHEXP for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBNHEXP", "2009/06/11"], ["5114", "FBMRASVR for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBMRASVR", "2009/06/11"], ["5115", "FBPAY2 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBPAY2", "2009/06/11"], ["5116", "FBPAY21 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBPAY21", "2009/06/11"], ["5117", "FBPAY67 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "
These components are part of the fee basis payment
listing reports and were not designed to be called by other applications.
They may leak many variables.", "", "FBPAY67", "2009/06/11"], ["5118", "FBRXFA for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBRXFA", "2009/06/11"], ["5119", "FBRXFR for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBRXFR", "2009/06/11"], ["5120", "FBUTL2 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/02/07", "", "Retired", "Controlled Subscription", "", "", "", "FBUTL2", "2009/06/11"], ["5121", "$$SETICN MPIF001", "Routine", "MASTER PATIENT INDEX VISTA", "2011/01/13", "APPROVED", "Active", "Private", "", "
This function updates the Integration Control Number
(#991.01) and the ICN Checksum (#991.02) fields in the Patient (#2) file on
the MPI node. This is being provided for use by the North Chicago FEDERAL
HEALTH CARE CENTER developers.", "", "MPIF001", "2011/01/14"], ["5122", "Remove Rad/Nuc Med dd Screen of Sub field #70.15", "File", "1", "2008/02/07", "", "Pending", "Private", "70", "
The Radiology/Nuclear Medicine intends to remove the
following Data Dictionary:\n
K ^DD(70.15,.01,12)
K ^DD(70.15,.01,12.1)\n
This correction will eliminate the a DIC("S") screen for a drug. Instead of a
direct global read to the Pharmacy file #50, an API provided by Pharmacy will
be used to check or access a drug.\n
This will be a one-time IA with the installation of patch RA*5.0*65.", "", "", ""], ["5123", "Remove Rad/Nuc Med dd Screen of Sub field #70.21", "File", "1", "2008/02/08", "", "Pending", "Private", "70", "
The Radiology/Nuclear Medicine intends to remove the
following Data Dictionary:\n
K ^DD(70.21,.01,12)
K ^DD(70.21,.01,12.1)\n
This correction will eliminate the a DIC("S") screen for a drug. Instead of a
direct global read to the Pharmacy file #50, an API provided by Pharmacy will
be used to check or access a drug.\n
This will be a one-time IA with the installation of patch RA*5.0*65.", "", "", ""], ["5124", "Remove Rad/Nuc Med dd Screen of Sub field #71.055", "File", "1", "2008/02/08", "", "Pending", "Private", "71", "
The Radiology/Nuclear Medicine intends to remove the
following Data Dictionary:\n\n
K ^DD(71.055,.01,12)
K ^DD(71.055,.01,12.1)\n
This correction will eliminate the a DIC("S") screen for a drug. Instead of a
direct global read to the Pharmacy file #50, an API provided by Pharmacy will
be used to check or access a drug.\n
This will be a one-time IA with the installation of patch RA*5.0*65.", "", "", ""], ["5125", "Remove Rad/Nuc Med dd Screen of Sub field #71.08", "File", "1", "2008/02/08", "", "Pending", "Private", "71", "
The Radiology/Nuclear Medicine intends to remove the
following Data Dictionary:\n
K ^DD(71.08,.01,12)
K ^DD(71.08,.01,12.1)\n
This correction will eliminate the a DIC("S") screen for a drug. Instead of a
direct global read to the Pharmacy file #50, an API provided by Pharmacy will
be used to check or access a drug.\n
This will be a one-time IA with the installation of patch RA*5.0*65.", "", "", ""], ["5126", "Remove Rad/Nuc Med dd Screen of File 71.9 field #5", "File", "1", "2008/02/08", "", "Pending", "Private", "71.9", "
The Radiology/Nuclear Medicine intends to remove the
following Data Dictionary:\n
K ^DD(71.9,5,12)
K ^DD(71.9,5,12.1)\n
This correction will eliminate the a DIC("S") screen for a drug. Instead of a
direct global read to the Pharmacy file #50, an API provided by Pharmacy will
be used to check or access a drug.\n
This will be a one-time IA with the installation of patch RA*5.0*65.", "", "", ""], ["5127", "Set Rad/Nuc Med data dictionary 'ID','WRIT", "File", "1", "2008/02/08", "", "Pending", "Private", "71.9", "
Radiology/Nuclear Medicine intends to modify the
following data dictionary attribute:\n
K ^DD(71.9,0,"ID",5)
S ^DD(71.9,0,"ID","WRITE")="D EN^DDIOL($$EN5^RAPSAPI,"""",""?30"")"\n
Instead of a direct global read to the Pharmacy file #50, an API provided by
Pharmacy will be used to check or access a drug.\n\n
This will be a one-time IA with the installation of patch RA*5.0*65.", "", "", ""], ["5128", "MY PRIVATE", "File", "1", "2008/02/08", "", "Pending", "Private", "70.15", "", "", "", ""], ["5129", "CALL TO ROUTINE TIULMED", "Routine", "TEXT INTEGRATION UTILITIES", "2008/02/11", "APPROVED", "Active", "Private", "", "
Medicaion reconciliation has need for the data returned
by the entry LIST^TIULMED. Outpatiient pharmact requests permission to make
thatcall.", "", "TIULMED", "2008/02/11"], ["5130", "DBIA-5130", "Routine", "REGISTRATION", "2011/01/19", "", "Pending", "Private", "", "
An API is needed that sends a request for Patient Data
from the Last Site Treated.", "", "DGROHLS", ""], ["5131", "IB REMOVE IDENTIFIER DESIGNATION", "File", "1", "2008/02/12", "APPROVED", "Active", "Private", "355.93", "
Integrating Billing (IB) needs to remove the IDENTIFIER
label from the .09 field (FACILITY DEFAULT ID NUMBER) in file 355.93 (IB
NON/OTHER VA BILLING PROVIDER). This field is not an identifier for this file
because this field is only valid for non-VA facilities. The .09 field is not
available for non-VA individual providers.\n
This integration agreement exists so we can KILL ^DD(355.93,0,"ID",.09) with
IB patch IB*2.0*377.", "", "", "2008/03/06"], ["5132", "PATIENT FILE-GUARDIAN DATA", "File", "REGISTRATION", "2008/02/12", "APPROVED", "Active", "Private", "2", "
THE PATIENT FUNDS PACKAGE (PRPF) CONTAINS AN OPTION
THAT ALLOWS EDITING OF GUARDIAN INFORMATION IN THE PATIENT FILE. THESE FIELDS
ARE NOT AVAILABLE FOR EDITING IN ANY REGISTRATION OPTION.", "", "", "2008/03/07"], ["5133", "READ OF THE FINDING ITEM AND ADDITIONAL FINDINGS FIELDS", "File", "CLINICAL REMINDERS", "2008/02/14", "APPROVED", "Active", "Controlled Subscription", "801.41", "
This IA allows a package to do a direct read on the
Finding Items field and the Additional Finding Items multiple in file 801.41.\n", "", "", "2008/02/14"], ["5134", "ORQ12", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "", "", "", "ORQ12", ""], ["5135", "ORQOR2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "", "", "", "ORQOR2", ""], ["5136", "ORQPTQ1", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "", "", "", "ORQPTQ1", ""], ["5137", "ORQPTQ11", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORQPTQ11", "2016/03/23"], ["5138", "ORWLRR", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "", "", "", "ORWLRR", ""], ["5139", "XUSER", "Routine", "KERNEL", "2008/02/19", "", "Pending", "Private", "", "", "", "XUSER", ""], ["5140", "ORB31", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORB31", "2012/04/11"], ["5141", "ORQ20", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "", "", "", "ORQ20", ""], ["5142", "ORWTPT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "", "", "", "ORWTPT", ""], ["5143", "VADPT3", "Routine", "REGISTRATION", "2008/02/19", "", "Pending", "Private", "", "", "", "VADPT3", ""], ["5144", "DIC(45.7,", "File", "KERNEL", "2008/02/19", "", "Pending", "Private", "45.7", "", "", "", ""], ["5145", "OR(100", "File", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "100", "", "", "", ""], ["5146", "OR(100.24", "File", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "100.24", "", "", "", ""], ["5147", "ORD(101.41,", "File", "ORDER ENTRY/RESULTS REPORTING", "2008/02/19", "", "Pending", "Private", "101.41", "", "", "", ""], ["5148", "TIU(8925,", "File", "TEXT INTEGRATION UTILITIES", "2008/02/19", "", "Pending", "Private", "8925", "", "", "", ""], ["5149", "V Nodes in the DD", "File", "1", "2008/02/20", "APPROVED", "Active", "Controlled Subscription", "", "
This grants direct read access to the "V" nodes of a
field's DD. Descendent from the "V" node is information regarding variable
pointers including pointed-to file, message, order, prefix, screen, and LAYGO
status.\n
^DD(File#, Field#, "V", n, 0)\n
Where 'n' is a sequential number representing a different pointed-to file.
The pieces within this 0 node are:\n
^-Piece Contents\n
1 File number of the pointed-to file
2 Message defined for the pointed-to file
3 Order defined for the pointed-to file
4 Prefix defined for the pointed-to file
5 y/n indicating whether a screen is set up for the pointed-to
file
6 y/n indicating whether the user may add new entries to the
pointed-to file\n
^DD(File#, Field#, "V", n, 1) contains the M code defined as a screen on the
pointer to the file defined in the 0 node above. ^DD(File#, Field#, "V", n, 2)
contains a description of the screen.\n
Additionally, the following xrefs exist and may be read and traversed by
direct means, too:\n
^DD(File#, Field#, "V", "B" - xref on ^-Piece 1 of the 0 node.
"M" - 2
"O" - 3
"P" - 4\n", "", "", "2024/03/14"], ["5150", "API TO GET RESULT GROUP TEXT", "Routine", "CLINICAL REMINDERS", "2008/02/20", "APPROVED", "Active", "Controlled Subscription", "", "
This API returns an array of text that is used by the
calling package to display result text and informational text that is
associated with a score(s) for a MH Test.\n", "", "PXRMDRSG", "2025/04/22"], ["5151", "Exit Action for XUMF MFS EVENTS", "Other", "KERNEL", "2008/02/25", "APPROVED", "Active", "Private", "", "
This agreement permits Kernel to export an Exit Action
for the XUMF MFS EVENTS (MFS event driver) Protocol that invokes the following
Health Data & Informatics (HDI) API:\n
EXIT ACTION: I $T(MFSEXIT^HDISVAP)'="" D MFSEXIT^HDISVAP\n
HDI has requested to be invoked in the Exit Action of the XUMF MFS EVENTS
protocol to update the implementation status for standardization of a file in
a domain. This action was previously invoked in the Master File Parameters
Post-Processing Logic field by the applications. We are requesting it be
added to the Exit Action to make sure we are invoked last.", "", "", "2008/05/01"], ["5152", "CHECK FOR ORES KEY", "Other", "ORDER ENTRY/RESULTS REPORTING", "2008/02/26", "APPROVED", "Active", "Private", "", "
This will allow Lab to do a check for the ORES key
using the ^XUSEC global. Even though access to check for security keys is
granted with a Kernel Integration Control Registration, this was produced to
record that Lab would need to know if CPRS needed to modify the key that
indicates a user is a provider. Lab Re-engineering needs this information for
sending user updates to the Cerner lab system.", "", "", "2011/03/22"], ["5153", "DBIA-5153 - County Code", "File", "KERNEL", "2011/01/21", "", "Withdrawn", "Private", "", "", "", "", ""], ["5154", "NAME VAFCPID2", "Routine", "REGISTRATION", "2008/03/04", "APPROVED", "Active", "Private", "", "
Lab application has permission to use the NAME^VAFCPID2
API for standardization of the New Person file (#200) Name (.01) that is
transmitted to the Cerner Lab system from Legacy Vista Lab in the Master File
Notification messages.", "", "VAFCPID2", "2008/03/04"], ["5155", "Remove Rad/Nuc Med dd Screen from Subfield #70.03", "File", "1", "2008/03/07", "", "Pending", "Private", "70", "
The Radiology/Nuclear Medicine application intends to
remove the following Data Dictionary node\n
K ^DD(70.03,26,9.2)\n
This correction will eliminate the display warning message for a data screen
that no longer exists.\n
This will be a one-time IA with the installation of patch RA*5.0*56.", "", "", ""], ["5156", "Remove Rad/Nuc Med dd Screen from File #79.1", "File", "1", "2008/03/07", "", "Pending", "Private", "79.1", "
The Radiology/Nuclear Medicine application intends to
remove the following Data Dictionary node\n
K ^DD(79.1,21,9.2)\n
This correction will eliminate the display warning message for a data screen
that no longer exists.\n
This will be a one-time IA with the installation of patch RA*5.0*56.", "", "", ""], ["5157", "Access to AP SUPPLEMENTARY REPORT globals", "File", "LAB SERVICE", "2008/03/14", "APPROVED", "Active", "Private", "63", "
OE/RR needs to access the AUTOPSY, CYTOPATHOLOGY,
SURGICAL PATHOLOGY, & ELECTRON MICROSCOPY SUPPLEMENTARY REPORT globals to
check for the existence of any Anatomic Pathology supplementary reports on a
patient.\n
^LR(D0,84,0)=^63.324DA^^ (#32.4) AUTOPSY SUPPLEMENTARY REPORT
^LR(D0,CY,D1,1.2,0)=^63.907DA^^ (#1.2) SUPPLEMENTARY REPORT
^LR(D0,EM,D1,1.2,0)=^63.207DA^^ (#1.2) SUPPLEMENTARY REPORT
^LR(D0,SP,D1,1.2,0)=^63.817DA^^ (#1.2) SUPPLEMENTARY REPORT", "", "", "2008/03/17"], ["5158", "PATIENT ENROLLMENT", "File", "REGISTRATION", "2008/03/17", "APPROVED", "Active", "Private", "27.11", "
The Integrated Billing package would like to request
direct global and Fileman access to read the following fields of the Patient
Enrollment file (#27.11) for reporting purposes.", "", "", "2008/04/24"], ["5159", "DBIA5159", "File", "IFCAP", "2008/03/18", "", "Pending", "Private", "441", "
Integrated Billing requires one time access to the
IFCAP Item Master file (#441). Prosthetics changed from using the Item Master
file as the source of the Prosthetics Item description to using the
Prosthetics HCPCS. Integrated Billing is now being updated to correspond to
this change in Prosthetics. However for already billed items the bill must
not change, therefore for historical purposes, the Item Master description
will be pulled and saved with the old/existing billed Prosthetics Items.\n
The Integrated Billing patch IB*2*389 post-init will access the Item Master
file to get then store (#362.5,.05) the Item description for every prosthetic
item billed at the time of the installation, not directly related to a Patient
Item (#660).\n
This agreement will expire at the end of the IB*2*389 compliance date.", "", "", ""], ["5160", "DBIA5160", "File", "PROSTHETICS", "2008/03/18", "", "Pending", "Private", "661.1", "
Integrated Billing requires access to the PROSTHETIC
HCPCS file (#661.1) to select and identify Prosthetics Items to be billed. A
Fileman lookup to file #661.1 will be used for selection and several fields
for identification.\n", "", "", ""], ["5161", "Laboratory Reference Range Uniform Formatting", "Routine", "LAB SERVICE", "2008/03/25", "APPROVED", "Active", "Supported", "", "
In order to insure the uniform formatting of the
display of laboratory results reference ranges a new API has been created.
This new API is EN^LRLRRVF.\n
It is to be used as part of a set statement. For example:\n
S LRDV=$$EN^LRLRRVF(RLV,RHV)\n
It has two input values. RLV - Reference Low Value, RHV - Reference High
value\n
Both input values are required, but either or both can be set to null.\n
It will return the laboratory result refference ranges formatting using the
following guidelines:\n
1. If neither low or high reference value is defined, nothing prints. 2. If
the low only is defined and it is equal to 0 it prints: Ref: >=0 3. If the
low only is defined and the first character is "<" or ">"
it prints: Ref: low_value 4. If the low only is defined and it is numeric
it prints: Ref: >=10 5. If the low only is defined and it is alphanumeric it
prints:
Ref: RVLow 6. If the high only is defined and it is equal to 0 it prints:
Ref: 0 7. If the high only is defined and the first character is "<" or ">"
it prints: Ref: high_value 8. If the high only is defined and it is
numeric it prints: Ref: <=20 9. If the high only is defined and it is
alphanumeric it prints:
Ref: RVHIGH 10. If both low and high are defined it prints: RVLOW - RVHIGH
or 10 - 20.\n
This is a example display. The example results and the ranges are in the same
order as the guidelines.\n
---- MISCELLANEOUS TESTS ----\n
DATE TIME SPECIMEN TEST VALUE Ref ranges
--------------------------------------------------------------------------
-----
10/25/2007 15:49 BLOOD CML-F: 10 10/25/2007
16:06 BLOOD CML-F: 10 Ref: >=0 10/25/2007 16:06
BLOOD CML-F: 10 Ref: >10 10/25/2007 16:10 BLOOD
CML-F: 9 L Ref: >=10 10/25/2007 16:24 BLOOD
CML-F: 10 Ref: RVLOW 10/25/2007 16:29 BLOOD
CML-F: 10 H Ref: 0 10/25/2007 16:29 BLOOD CML-F:
10 H Ref: <20 10/25/2007 16:32 BLOOD CML-F: 22
H Ref: <=20 10/25/2007 17:35 BLOOD CML-F: 10
Ref: RVHIGH 10/25/2007 17:38 BLOOD CML-F: 15
10 - 20
***numeric ranges*** 10/25/2007 17:45 BLOOD CML-F: 17
RVLOW - RVHIGH
***alphanumeric ranges***", "", "LRLRVRF", "2008/03/25"], ["5162", "HDIS STATUS UPDATE EVENTS", "Other", "HEALTH DATA & INFORMATICS", "2008/03/25", "", "Pending", "Supported", "", "
This event point is used to post before/after status
values whenever the implementation status of a file is changed. The values
posted are what would be output by $$GETSTAT^HDISVFO1() before and after the
change is made. The following nodes will be posted:\n
^TMP("HDIS",$J,"STATUS",FileNumber,"BEFORE") =
StatusCode ^ StatusPointer ^ StatusDate\n
^TMP("HDIS",$J,"STATUS",FileNumber,"AFTER") =
StatusCode ^ StatusPointer ^ StatusDate", "", "", ""], ["5163", "USE OF FILEMAN IN ROUTINE DGMTDD", "File", "1", "2008/03/25", "", "Pending", "Private", "", "
Routine ^DGMTDD uses a direct global read with ^DD to
get the cross-references for the Current Means Test Status field - file #2,
field #.14.\n
The code follows: CUR+15 .F S DGIX=$O(^DD(2,.14,1,DGIX)) Q:'DGIX X
^(DGIX,2) S X=DGCS CUR+19 .F S DGIX=$O(^DD(2,.14,1,DGIX)) Q:'DGIX X
^(DGIX,1) S X=DGMTS", "", "", ""], ["5164", "USE OF FILEMAN IN ROUTINE DGPMDDCN", "File", "1", "2008/03/25", "", "Pending", "Private", "", "
Routine ^DGPMDDCN uses a direct global read with ^DD to
set and kill cross-references for Patient file (#2) fields.\n
The code follows SET+3 F DGIX=0:0 S DGIX=$O(^DD(2,DGFLD,1,DGIX)) Q:'DGIX
X ^(DGIX,1) S X=DGPMX KILL+3 F DGIX=0:0 S DGIX=$O(^DD(2,DGFLD,1,DGIX))
Q:'DGIX X ^(DGIX,2) S X=DGPMX\n
Fields included are:
.1 Ward Location
.102 Current Movement
.013 Treating Specialty
.104 Provider
.1041 Attending Physician
.105 Current Admission
.108 Current Room
.109 Exclude From Facility", "", "", ""], ["5165", "WDDE DISPENSING CABINET", "File", "PHARMACY DATA MANAGEMENT", "2008/04/02", "", "Withdrawn", "Controlled Subscription", "59.72", "
This ICR allows access to the automated dispensing
cabinets defined in the AUTOMATED DISPENSING CABINET file.\n", "", "", "2009/02/02"], ["5166", "WDDE DISPENSING SYSTEM", "File", "PHARMACY DATA MANAGEMENT", "2008/04/02", "", "Withdrawn", "Controlled Subscription", "59.71", "
This ICR allows access to the automated dispensing
systems defined in the AUTOMATED DISPENSING SYSTEM file.\n", "", "", "2009/02/02"], ["5167", "BCMA ORDER ACTIVITY", "Routine", "BAR CODE MED ADMIN", "2008/04/04", "", "Withdrawn", "Private", "", "
This API returns a patient's order activity information
from the Bar Code Med Admin (BCMA) package for a specified time period.\n\n", "", "PSBUTL1", "2009/02/02"], ["5168", "DBIA-5168 - Postal Code", "File", "KERNEL", "2011/01/21", "", "Withdrawn", "Private", "", "", "", "", ""], ["5169", "MENTAL HEALTH YTAPI5 TOOLS", "Routine", "MENTAL HEALTH", "2008/04/07", "APPROVED", "Active", "Controlled Subscription", "", "
Tools to produce horizontal GAF reference and to check
the Privleging of legacy instruments.", "", "YTAPI5", "2021/05/27"], ["5170", "gov.va.med.monitor.time.AuditTimer", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class AuditTimer extends java.lang.Object:\n
The AuditTimer class gives an easy way to capture performance statistics and
log them to a log file. Internally System.currentTimeMillis() is used.
Typical steps for using this class:\n
1. Create an instance: auditTimer = new AutitTimer() 2. auditTimer.start() 3.
auditTimer.stop() 4. auditTimer.getTimeElapsedMillis()\n
autitTimer.start() should be called before auditTimer.stop() is called.", "", "", "2008/07/11"], ["5171", "gov.va.med.crypto.VistaKernelHash", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class VistaKernelHash extends java.lang.Object:\n
Implements static methods to provide the encoding algorithms used by the RPC
Broker and Kernel to encode and decode data strings. Using these algorithms
makes it harder to sniff the contents of text sent over the network. This is
not, however, encryption-class encoding, nor does it protect against replay
attacks of un-decoded strings, and therefore use of this algorithm should not
be considered to imply or achieve any particular level of security.\n
For example:\n
String encodedString = VistaKernelHash.encrypt("some text to encode", true);", "", "", "2008/07/11"], ["5172", "gov.va.med.environment.Environment", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class Environment extends java.lang.Object:
Environment settings for J2EE server use.", "", "", "2008/07/11"], ["5173", "gov.va.med.environment.ServerType", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class ServerType extends java.lang.Object:
Enumerated J2EE server types.\n
Example Use:\n
if (Environment.getServerType().equals(ServerType.WEBLOGIC)) {
// weblogic-specific code
}", "", "", "2008/07/11"], ["5174", "gov.va.med.exception.ExceptionUtils", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class ExceptionUtils extends java.lang.Object:
Exposes utility methods for handling exceptions. Note: DEPRECATED CLASS.", "", "", "2008/07/11"], ["5175", "gov.va.med.exception.FoundationsExceptionInterface", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public interface FoundationsExceptionInterface:
Represents the interface that all Foundations exceptions implement.
Implementing this interface allows ExceptionUtils to work with the exception.", "", "", "2008/07/11"], ["5176", "gov.va.med.net.SocketManager", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class SocketManager extends java.lang.Object
implements java.io.Serializable: Represents a socket that can be used to
communicate with IP end points.", "", "", "2008/07/11"], ["5177", "gov.va.med.xml.XmlUtilities", "Other", "FOUNDATIONS", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class XmlUtilities extends java.lang.Object:
Deprecated. Need for XML utilities has been superceded by the many
JRE-built-in and external XML frameworks.\n
This class contains a number of static utility methods to help developers work
with XML documents, nodes, attributes and strings.", "", "", "2008/07/11"], ["5178", "gov.va.med.vistalink.adapter.cci.VistaLinkConnectionFactory", "Other", "VISTALINK", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public class VistaLinkConnectionFactory extends
java.lang.Object implements javax.resource.cci.ConnectionFactory,
java.io.Serializable, javax.resource.Referenceable.\n
This implementation class provides an interface for getting connection to an
EIS instance. It should be retrieved via JNDI lookup from the J2EE container.", "", "", "2008/07/11"], ["5179", "gov.va.med.vistalink.adapter.cci.VistaLinkConnection", "Other", "VISTALINK", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public interface VistaLinkConnection extends
javax.resource.cci.Connection: This interface represents an application level
connection handle that is used by a component to access an EIS instance.", "", "", "2008/07/11"], ["5180", "gov.va.med.vistalink.adapter.cci.VistaLinkConnectionSpec", "Other", "VISTALINK", "2008/04/11", "APPROVED", "Active", "Supported", "", "
public interface VistaLinkConnectionSpec extends
javax.resource.cci.ConnectionSpec\n
This interface defined the common properties needed by any VistALink
connection spec implementation.", "", "", "2008/07/11"], ["5181", "DRUG WASTAGE", "Routine", "CONTROLLED SUBSTANCES", "2008/04/15", "", "Withdrawn", "Private", "", "
This API returns wastage base on the amount of
medication ordered through the Inpatient Medications V. 5.0 application vs.
the amount processed from the automated dispensing cabinet of the Ward Drug
Dispensing Equipment (WDDE) software.\n", "", "PSDHLRFD", "2009/02/02"], ["5182", "ECME WRITE ACCESS TO NEW PERSON FILE", "File", "KERNEL", "2008/04/17", "APPROVED", "Active", "Private", "200", "
ECME (BPS) Requests write access to the New Person
(#200) file for the following fields via Fileman Input Template:\n
OFFICE PHONE (#.132)
EMAIL ADDRESS (#.151)
TITLE (#8)", "", "", ""], ["5183", "PHARMACY DATA MANAGEMENT", "File", "PHARMACY DATA MANAGEMENT", "2008/04/18", "", "Withdrawn", "Private", "55", "
The Ward Drug Dispensing Equipment (WDDE) project is
requesting access to two fields and a cross-reference of the PHARMACY PATIENT
file 55 that are not provided by current APIs.\n", "", "", "2009/02/02"], ["5184", "INPATIENT PHARMACY", "File", "AUTO REPLENISHMENT/WARD STOCK", "2008/04/21", "", "Pending", "Private", "58.2", "
This ICR was not activated as of 9/1/20, but the ICR
and Pharmacy team determined that if it gets activated, the custodial package
needed to change to Auto Replenishment/Ward Stock, instead of Inpatient
Medications.\n
This was the only text before 9/1/20: Controlled substance requires access to
the AOU INVENTORY GROUP file #58.2, the Areas of Use information for reporting
purposes.", "", "", ""], ["5185", "Update IB NDC NON COVERED BY PLAN FILE #366.16", "Routine", "INTEGRATED BILLING", "2008/04/21", "", "Retired", "Private", "", "
The IB API to add/update a record in the file IB NDC
NON COVERED BY PLAN FILE #366.16", "", "IBNCDNC", "2008/04/21"], ["5186", "PSOREJU3", "Routine", "OUTPATIENT PHARMACY", "2008/04/22", "APPROVED", "Active", "Private", "", "
This routine contains an API used by CMOP to validate
ePharmacy third party Tricare insurance response information.", "", "PSOREJU3", "2008/04/25"], ["5187", "CLINICAL REMINDERS API", "Routine", "PHARMACY DATA MANAGEMENT", "2008/04/24", "APPROVED", "Active", "Private", "50", "", "", "PSSCLINR", "2011/03/23"], ["5188", "CLINICAL REMINDERS API", "Routine", "OUTPATIENT PHARMACY", "2008/04/24", "", "Pending", "Private", "", "
This agreement gives the Clinical Reminders package
APIs for extracting data from the Prescription (#52) file.", "", "PSO52CLR", ""], ["5189", "READ 58.81 FOR SELECTING PATN TRANS FOR WDDE", "File", "DRUG ACCOUNTABILITY", "2008/04/24", "", "Withdrawn", "Private", "58.81", "
Inpatient Pharmacy requests read access to the DRUG
ACCOUNTABILITY file #58.81 for selecting records by Patient by Date for
inclusion in WDDE reporting.", "", "", "2009/02/03"], ["5190", "READ 120.85 FOR WDDE TO GET HL7 INFO", "File", "ADVERSE REACTION TRACKING", "2008/04/24", "", "Withdrawn", "Private", "120.85", "
WDDE requests read access to the ADVERSE REACTION
REPORTING file #120.85 for the purpose of collecting key allergy information
to populate the Inpatient Medication Order Request, AL1 HL7 segment, for
transmission to the Ward dispensing equipment.", "", "", "2009/02/03"], ["5191", "Mapping Validation for Immunization Standardization", "File", "PCE PATIENT CARE ENCOUNTER", "2008/04/28", "APPROVED", "Active", "Private", "9999999.14", "
This agreement permits Health Data & Informatics (HDI)
read access, using FileMan, to the Immunization file (#9999999.14).\n
With the standardization of the Immunization file it is necessary for HDI to
monitor the local mapping of the term/concepts in this file.", "", "", "2008/05/01"], ["5192", "Mapping Validation for Skin Test Standardization", "File", "PCE PATIENT CARE ENCOUNTER", "2008/04/28", "APPROVED", "Active", "Private", "9999999.28", "
This agreement permits Health Data & Informatics (HDI)
read access, using FileMan, to the Skin Test file (#9999999.28).\n
With the standardization of the Skin Test file it is necessary for HDI to
monitor the local mapping of the term/concepts in this file.", "", "", "2008/05/01"], ["5193", "Mapping Validation for PCE Code Mapping", "File", "PCE PATIENT CARE ENCOUNTER", "2008/04/28", "APPROVED", "Withdrawn", "Private", "811.1", "
This agreement permits Health Data & Informatics (HDI)
read access, using FileMan, to the PCE Code Mapping file (#811.1).\n
With the standardization of the Immunization and Skin Test files it is
necessary for HDI to monitor the local mapping of the term/concepts in this
file.", "", "", "2008/05/01"], ["5194", "Recall Reminder Change to DGRPD", "Routine", "REGISTRATION", "2008/05/07", "", "Withdrawn", "Private", "", "
I have been asked to rewrite Visn 20 clinic recall
class III application to move to class I application called Recall Reminder
with an namespace of SDRR. One of the changes is a call from routine DGRPD at
RMK+2 - the call is:\n
D ^SDRRSEG3 ;Display Recall Reminder data for patient", "", "DGRPD", ""], ["5195", "Recall Reminder Display", "Routine", "SCHEDULING", "2008/05/07", "APPROVED", "Active", "Controlled Subscription", "", "
These changes are required to show Recall Reminder
information on the Cover sheet for all CPRS users. This is a view only NO
input done.\n
ORWCV.INT VST+22 ;***ADD CHANGES TO CALL COVER^SDRROR VST+23
D COVER^SDRROR DTLVST+14 I $P(APPTINFO,";")="R" D RCDTL^SDRROR\n
making two calls to SDRROR\n
SDRR is a new namespace being used to move a Class III application (Clinic
Recall) to a National Class I application called Reminder Recall (SDRR
NAMESPACE).", "", "SDRROR", "2019/10/02"], ["5196", "DBIA-5196", "File", "ORDER ENTRY/RESULTS REPORTING", "2011/01/21", "", "Pending", "Private", "100", "
This is the file of orders/requisitions made for any
package through the Order Entry Option (OR).", "", "", ""], ["5197", "TIU CALLS TO PSOQ0496", "Routine", "OUTPATIENT PHARMACY", "2008/05/08", "APPROVED", "Active", "Private", "", "
TIU requests approval to make the following call to
PSOQ0496.\n", "", "PSOQ0496", "2008/05/08"], ["5198", "XUS DIVISION GET", "Remote Procedure", "KERNEL", "2008/05/13", "APPROVED", "Active", "Private", "", "
This DBIA authorizes Imaging to access the remote
procedure call XUS DIVISION GET.", "XUS DIVISION GET", "", "2008/05/20"], ["5199", "XUS DIVISION SET", "Remote Procedure", "KERNEL", "2008/05/13", "APPROVED", "Active", "Private", "", "
This DBIA authorizes Imaging to access the remote
procedure call XUS DIVISION SET.", "XUS DIVISION SET", "", "2008/05/20"], ["5200", "REMOVE 'CREATED BY' IDENTIFIER IN FILE 702", "File", "1", "2008/05/14", "APPROVED", "Active", "Private", "702", "
This DBIA documents the removal of an identifier in the
CP Transaction file (#702) for the CREATED BY field (#.03) with a "K
^DD(702,0,ID,.03)" command in a post-init routine.\n", "", "", "2008/07/22"], ["5201", "REBUILD IV EXTRACT FOR DSS", "Routine", "INPATIENT MEDICATIONS", "2008/05/19", "", "Pending", "Private", "", "
This routine will recreate the IV extract for DSS. DSS
wil call this PSJ routine as needed.", "", "PSJDSS", ""], ["5202", "DBIA5202", "Routine", "DSS - DECISION SUPPORT SYSTEM EXTRACTS", "2008/05/19", "", "Pending", "Private", "", "
This API returns the value fields from the DSS LOINC
CODES (#727.29) file. The DSS LOINC CODES (#727.29) file holds the list of
reportable LOINC Codes desired by the Decision Support System.", "", "ECXUTL6", ""], ["5203", "Get HDIS Status Text", "Routine", "HEALTH DATA & INFORMATICS", "2008/05/22", "", "Pending", "Supported", "", "
The $$GETCTXT^HDISVF06 API is used to get the Status
Text for the Status by Status Type and Status Code.\n
The $$GETTEXT^HDISVF06 API is used to get the Status Text for the Status by
IEN.", "", "HDISVF06", ""], ["5204", "DBIA5204", "Routine", "INTEGRATED BILLING", "2008/05/28", "", "Pending", "Private", "", "
IB grants permission to ECME to call the routine
IBCNRE4 to provide access to the Edit PLAN APPLICATION Sub-file option through
the ECME User Screen. This option is locked with the IBCNR E-PHARMACY
SUPERVISOR security key.", "", "IBCNRE4", ""], ["5205", "PLACER ORDER # FOR CPRS", "File", "OUTPATIENT PHARMACY", "2008/05/29", "", "Expired", "Private", "52", "
This agreement gives the Computerized Patient Record
System (CPRS) package access in patch OR*3*281 to directly read the PLACER
ORDER # (#39.3) Field of the PRESCRIPTION (#52) File for a one-time clean-up.
After the patch is released, this Integration Agreement will be retired.", "", "", "2008/06/16"], ["5206", "HLO MESSAGES (#778) file access", "File", "HEALTH LEVEL SEVEN", "2008/06/03", "APPROVED", "Active", "Private", "778", "\n
Master Patient Index Austin is providing a PSIM messaging rate
monitor for the MPI development team on the MPI Austin production
account. We are looping on ^HLB(, the HLO MESSAGES (#778) file,
and getting the following 4 pieces of information:
.04 DIRECTION (RS), [0;4]
.07 APPLICATION ACKNOWLEDGMENT BY (F), [0;7]
.16 TRANSMISSION DATE/TIME (D), [0;16]
.2 COMPLETION STATUS (S), [0;20]\n
We are also looking at the "B" cross-reference to get the IEN
for ACK messages.\n", "", "", "2008/07/25"], ["5207", "DBIA5207", "Routine", "INTEGRATED BILLING", "2008/06/05", "", "Pending", "Private", "", "
IB grants permission to ECME to call the routine
EN^IBCNRPMT to provide access to the Match Group Plan to a Pharmacy Plan
option through the ECME User Screen. This option is locked with the IBCNR
E-PHARMACY SUPERVISOR security key.", "", "IBCNRPMT", ""], ["5208", "DBIA5208", "Routine", "INTEGRATED BILLING", "2008/06/05", "", "Pending", "Private", "", "
IB grants permission to ECME to call the routine
EN^IBCNRPM1 to provide access to the Match Multiple Group Plans to a Pharmacy
Plan option through the ECME User Screen. This option is locked with the IBCNR
E-PHARMACY SUPERVISOR security key.", "", "IBCNRPM1", ""], ["5209", "HDISVLM MAPPING TOOL", "Other", "HEALTH DATA & INFORMATICS", "2008/06/05", "", "Pending", "Supported", "", "
This event point is used to post before/after record
mapping values whenever the STS Generic Mapping Tool changes the mapping of a
record during the release process when implementing a new standardized domain.\n
The following nodes will be posted:\n
^TMP("HDISVLM MAPPING TOOL",$J,<file#>,"BEFORE",<record ien>,"REPLACED
BY")=<value of field 99.97>\n
^TMP("HDISVLM MAPPING TOOL",$J,<file#>,"BEFORE",<record ien>,"INHERITS
FROM")=$$RPLCMNT^XTIDTRM(<file#>,<record ien>)\n\n
^TMP("HDISVLM MAPPING TOOL",$J,<file#>,"AFTER",<record ien>,"REPLACED
BY")=<value of field 99.97>\n
^TMP("HDISVLM MAPPING TOOL",$J,<file#>,"AFTER",<record ien>,"INHERITS
FROM")=$$RPLCMNT^XTIDTRM(<file#>,<record ien>)", "", "", ""], ["5210", "IB DRUGS NON COVERED REPORT", "Other", "INTEGRATED BILLING", "2008/06/06", "APPROVED", "Active", "Private", "", "
Allows the E CLAIMS MGMT ENGINE package to use IB DRUGS
NON COVERED REPORT menu option (Drugs non covered report) in its menu.", "", "", "2008/06/10"], ["5211", "FBUCLET for FBCS (DSS)", "Routine", "FEE BASIS", "2008/06/10", "", "Retired", "Controlled Subscription", "", "", "", "FBUCLET", "2009/06/11"], ["5212", "FBCHFR for FBCS (DSS)", "Routine", "FEE BASIS", "2008/06/10", "", "Retired", "Controlled Subscription", "", "", "", "FBCHFR", "2009/06/11"], ["5213", "FBFHLL for FBCS (DSS)", "Routine", "FEE BASIS", "2008/06/10", "", "Retired", "Controlled Subscription", "", "", "", "FBFHLL", "2009/06/11"], ["5214", "PRCS58 For FBCS (DSS)", "Routine", "IFCAP", "2008/06/10", "", "Withdrawn", "Controlled Subscription", "", "", "", "PRCS58", ""], ["5215", "PRCS58CC for FBCS (DSS)", "Routine", "IFCAP", "2008/06/11", "", "Withdrawn", "Controlled Subscription", "", "", "", "PRCS58CC", ""], ["5216", "FBAAC04 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/06/11", "", "Retired", "Controlled Subscription", "", "", "", "FBAACO4", "2009/06/11"], ["5217", "FBAAV2 for FBCS (DSS)", "Routine", "FEE BASIS", "2008/06/11", "", "Retired", "Controlled Subscription", "", "", "", "FBAAV2", "2009/06/11"], ["5218", "ACCESS REQUEST TO CALL AR ROUTINE", "Routine", "ACCOUNTS RECEIVABLE", "2008/06/11", "APPROVED", "Active", "Private", "", "
The subscriber of this ICR is a Class 3 product in the
"KPA" package namespace for the Consolidated Patient Account Center (CPAC).
The original development effort is an interface between the Stockamp TRAC
application and VistA AR. The TRAC application is a COTS product used for AR
follow-up and management. This interface will file AR comments entered into
the TRAC tool and automatically create AR comment transactions in the AR
transaction file (File# 433).\n
This is a request to be able to call 2 procedures in AR in order to create a
stub AR transaction entry in file 433. These 2 procedure calls are very
common throughout AR and is the normal method to create new entries in file
433.", "", "PRCAUTL", ""], ["5219", "KPA ACCESS TO AR FILE 430", "File", "ACCOUNTS RECEIVABLE", "2008/06/26", "APPROVED", "Active", "Private", "430", "
The subscriber of this ICR is a Class 3 product in the
"KPA" package namespace for the Consolidated Patient Account Center (CPAC).
The original development effort is an interface between the Stockamp TRAC
application and VistA AR. The TRAC application is a COTS product used for AR
follow-up and management. This interface will file AR comments entered into
the TRAC tool and automatically create AR comment transactions in the AR
transaction file (File# 433).\n
This is a request to be able to reference several fields in file 430 in
preparation for being able to file new AR comment transactions in file 433.", "", "", "2008/06/30"], ["5220", "KPA ACCESS TO AR FILE 433", "File", "ACCOUNTS RECEIVABLE", "2008/06/26", "APPROVED", "Active", "Private", "433", "
The subscriber of this ICR is a Class 3 product in the
"KPA" package namespace for the Consolidated Patient Account Center (CPAC).
The original development effort is an interface between the Stockamp TRAC
application and VistA AR. The TRAC application is a COTS product used for AR
follow-up and management. This interface will file AR comments entered into
the TRAC tool and automatically create AR comment transactions in the AR
transaction file (File# 433).\n
This is a request to be able to reference several fields in file 433 and also
to edit (write) several fields in file 433 to be able to add a new AR comment
transaction in file 433 using the FILE^DIE FileMan API.", "", "", "2008/06/30"], ["5221", "gov.va.med.vistalink.security.CallbackHandlerSwing", "Other", "VISTALINK SECURITY", "2008/07/01", "APPROVED", "Active", "Supported", "", "
public class CallbackHandlerSwing extends
java.lang.Object implements javax.security.auth.callback.CallbackHandler.\n
Implements the JAAS CallbackHandler interface. Use with the VistaLoginModule
to invoke a Swing-based interactive logon. Input values (access code, verify
code, division selection, and other "user input") are collected via a set of
GUI dialogs when this callback handler is used. To use:\n
1. Create an instance of CallbackHandlerSwing. No parameters are needed. 2.
Create the JAAS LoginContext instance, passing the instance of the callback
handler as one of the parameters. 3. Invoke the JAAS login context's login
method. The callback handler will invoke Swing dialogs to collect user input
wherever required for login.", "", "", "2008/07/11"], ["5222", "gov.va.med.vistalink.security.CallbackHandlerSwingCCOW", "Other", "VISTALINK SECURITY", "2008/07/01", "APPROVED", "Active", "Supported", "", "
public class CallbackHandlerSwingCCOW extends
gov.va.med.vistalink.security.CallbackHandlerSwing implements
javax.security.auth.callback.CallbackHandler.\n
Implements the CallbackHandler JAAS CallbackHandler interface. Use with the
VistaLoginModule to invoke a Swing-based interactive logon, using the
CCOW-enabled features of the VistaLink login module. If user authentication is
required (if a valid user context does not exist that can be leveraged for
single signon), input values (access code, verify code, division selection,
and other "user input") are collected via a set of Swing GUI dialogs by this
callback handler.\n
To login:\n
1. Create a CCOW context module and broker. Must be securely bound to the
context with a secure application passcode. 2. Create an instance of
CallbackHandlerSwing, passing the Frame window parent, the context module and
broker. 3. Create the JAAS LoginContext instance, passing the instance of the
callback handler as one of the parameters. 4. Invoke the JAAS login context's
login method. The callback handler will invoke Swing dialogs to collect user
input wherever required for login.", "", "", ""], ["5223", "gov.va.med.vistalink.security.CallbackHandlerUnitTest", "Other", "VISTALINK SECURITY", "2008/07/01", "APPROVED", "Active", "Supported", "", "
public final class CallbackHandlerUnitTest extends
java.lang.Object implements javax.security.auth.callback.CallbackHandler.\n
Implements the JAAS CallbackHandler interface. Use with the VistaLoginModule
to invoke a silent signon. Intended for use in unit testing environments where
logins must be called repetitively without user interaction. Not for use in
production environments, where users should be interactively prompted for
signon credentials.\n
To use:\n
1. Pass access code, verify code and division as parameters when you create an
instance of this callback handler.\n
2. Pass the instance of the callback handler to the login context when you
create the login context.\n
3. Then, when VistaLoginModule'slogin method (via the indirection of the
LoginContext) invokes this callback handler to collect user input for (access
code, verify code, select division), these values are already present and are
handed back to the login module without any user interation.", "", "", "2008/07/11"], ["5224", "gov.va.med.vistalink.security.VistaKernelPrincipalImpl", "Other", "VISTALINK SECURITY", "2008/07/01", "APPROVED", "Active", "Supported", "", "
public final class VistaKernelPrincipalImpl extends
java.lang.Object implements java.io.Serializable, VistaKernelPrincipal\n
Implements the gov.va.med.vistalink.security.m.VistaKernelPrincipal interface.
Represents a JAAS principal representing a logged on Kernel user on an M
system.", "", "", "2008/07/11"], ["5225", "gov.va.med.vistalink.security.VistaLoginModule", "Other", "VISTALINK SECURITY", "2008/07/01", "APPROVED", "Active", "Supported", "", "
public final class VistaLoginModule extends
java.lang.Object implements javax.security.auth.spi.LoginModule:\n
VistaLoginModule is a JAAS-compliant LoginModule to log users on to a Vista
system. An application never needs to access the VistaLoginModule class
directly. Rather, as a JAAS login module, its methods are invoked indirectly
by an application through the JAAS login context class
(javax.security.auth.login.LoginContext).\n
Client/server applications using VistALink for logins/connections make use of
VistaLoginModule thru JAAS configuration, by specifying
gov.va.med.vistalink.security.VistaLoginModule as the LoginModule class in a
jaas.config login configuration, and then invoking a JAAS login in application
code.\n
The key classes for invoking a login with this login module are:\n
- a callback handler, either CallbackHandlerSwing, CallbackHandlerSwingCCOW,
or CallbackHandlerUnitTest\n
- the login context (javax.security.auth.login.LoginContext)\n
- the Kernel principal returned after a successful login
(VistaKernelPrincipalImpl)", "", "", "2008/07/11"], ["5226", "gov.va.med.vistalink.security.m.VistaKernelPrincipal", "Other", "VISTALINK", "2008/07/01", "APPROVED", "Active", "Supported", "", "
public interface VistaKernelPrincipal extends
java.security.Principal\n
Provides an interface to marks a principal that represents a logged on Kernel
user on an M system. Upon a successful JAAS login, one or more principals may
be contained in the JAAS subject that is returned from a successful JAAS login
(only one *Kernel* principal should be returned, however. The situation in
which multiple principals could be returned is if some kind of compound logon
has been set up that requires several logons to complete, for example one to
Kernel, and one to a separate health data repository). The
VistaKernelPrincipal interface is a marker you can use to identify a
"VistaKernelPrincipal" as one of those principals. However, an easier approach
is to use the helper method getKernelPrincipal in
gov.va.med.vistalink.security.VistaKernelPrincipalImpl to directly retrieve
the single VistaKernelPrincipal.", "", "", ""], ["5227", "VistaLinkAppProxyConnectionSpec", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public class
gov.va.med.vistalink.adapter.cci.VistaLinkAppProxyConnectionSpec extends
gov.va.med.vistalink.adapter.cci.VistaLinkConnectionSpecImpl implements
gov.va.med.vistalink.adapter.cci.VistaLinkConnectionSpec,
javax.resource.cci.ConnectionSpec.\n
This is the connection spec class for Application Proxy re-authentication.", "", "", "2008/07/11"], ["5228", "gov.va.med.vistalink.adapter.cci.VistaLinkDuzConnectionSpec", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public class
gov.va.med.vistalink.adapter.cci.VistaLinkDuzConnectionSpec extends
gov.va.med.vistalink.adapter.cci.VistaLinkConnectionSpecImpl implements
gov.va.med.vistalink.adapter.cci.VistaLinkConnectionSpec,
javax.resource.cci.ConnectionSpec.\n
This is the connection spec class for Duz re-authentication.", "", "", "2008/07/11"], ["5229", "VistaLinkVpidConnectionSpec", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public class gov.va.med.vistalink.adapter.cci
VistaLinkVpidConnectionSpec extends
gov.va.med.vistalink.adapter.cci.VistaLinkConnectionSpecImpl implements
gov.va.med.vistalink.adapter.cci.VistaLinkConnectionSpec,
javax.resource.cci.ConnectionSpec.\n
This is the connection spec class for VPID re-authentication.", "", "", "2008/07/11"], ["5230", "VistaLinkRequestRetryStrategy", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public interface
gov.va.med.vistalink.adapter.record.VistaLinkRequestRetryStrategy\n
Base strategy interface for determining if request should be re-executed.", "", "", ""], ["5231", "VistaLinkRequestRetryStrategyAllow", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public class
gov.va.med.vistalink.adapter.record.VistaLinkRequestRetryStrategyAllow
implements gov.va.med.vistalink.adapter.record.VistaLinkRequestRetryStrategy.\n
Simple 'Allow' strategy implementation that indicates request should be
re-executed.", "", "", ""], ["5232", "VistaLinkRequestRetryStrategyDeny", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public class
gov.va.med.vistalink.adapter.record.VistaLinkRequestRetryStrategyDeny
implements gov.va.med.vistalink.adapter.record.VistaLinkRequestRetryStrategy.\n
Simple 'Deny' strategy implementation that indicates request should not be
re-executed.", "", "", ""], ["5233", "gov.va.med.vistalink.adapter.record.VistaLinkRequestVO", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public interface VistaLinkRequestVO: Base request
interface.", "", "", "2008/07/11"], ["5234", "gov.va.med.vistalink.adapter.spi.VistaLinkServerInfo", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public class
gov.va.med.vistalink.adapter.spi.VistaLinkServerInfo extends java.lang.Object:\n
Represents M VistA connection information, like address and port.", "", "", "2008/07/11"], ["5235", "gov.va.med.vistalink.institution.IPrimaryStationRules", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public interface IPrimaryStationRules: Interface for
PrimaryStationRules implementations. All implementations must be threadsafe.", "", "", "2008/07/11"], ["5236", "gov.va.med.vistalink.institution.InstitutionMappingDelegate", "Other", "VISTALINK", "2008/07/02", "APPROVED", "Active", "Supported", "", "
public class
gov.va.med.vistalink.institution.InstitutionMappingDelegate extends
java.lang.Object:\n
Provides methods used by applications to query the institution mapping.", "", "", "2008/07/11"], ["5237", "Deletion of entries in XTID VUID FOR SET OF CODES file", "File", "TOOLKIT", "2008/07/03", "APPROVED", "Active", "Private", "8985.1", "
This ICR permits the HDI application to delete entries
from the XTID VUID FOR SET OF CODES file (#8985.1). Entries are found using
the FileMan call FIND^DIC with a screen set to find those entries that match
the file and field numbers being removed. Entries are then deleted using the
FileMan call ^DIK.", "", "", "2012/09/13"], ["5238", "gov.va.med.vistalink.rpc.RpcReferenceType", "Other", "VISTALINK", "2008/07/03", "APPROVED", "Active", "Supported", "", "
public class RpcReferenceType extends java.lang.Object:
Represents a reference type object for an RPC parameter. Used mainly for
RpcRequest.setParams() call to represent a 'reference' type parameter.", "", "", "2008/07/11"], ["5239", "gov.va.med.vistalink.rpc.RpcRequestFactory", "Other", "VISTALINK", "2008/07/03", "APPROVED", "Active", "Supported", "", "
public class RpcRequestFactory extends java.lang.Object
implements gov.va.med.vistalink.adapter.record.VistaLinkRequestFactory:\n
Factory class to creates instances of RpcRequest.", "", "", "2008/07/11"], ["5240", "gov.va.med.vistalink.rpc.RpcRequestParams", "Other", "VISTALINK", "2008/07/03", "APPROVED", "Active", "Supported", "", "
public class RpcRequestParams extends java.lang.Object:
Represents the collection of parameters associated with an RPC.", "", "", "2008/07/11"], ["5241", "gov.va.med.vistalink.rpc.RpcResponse", "Other", "VISTALINK", "2008/07/03", "APPROVED", "Active", "Supported", "", "
public class RpcResponse extends
gov.va.med.vistalink.adapter.record.VistaLinkResponseVOImpl.\n
Represents a data structure which holds the response value(s).", "", "", "2008/07/11"], ["5242", "gov.va.med.vistalink.rpc.RpcRequest", "Other", "VISTALINK", "2008/07/03", "APPROVED", "Active", "Supported", "", "
public class gov.va.med.vistalink.rpc.RpcRequest
extends gov.va.med.vistalink.adapter.record.VistaLinkRequestVOImpl.\n
Represents a RPC request to an M VistA server.\n
This is the principal class for use by developers to create and setup requests
to the host M server.", "", "", "2008/07/11"], ["5243", "vljConnector Exceptions", "Other", "VISTALINK", "2008/07/09", "APPROVED", "Active", "Supported", "", "
Exceptions that can be thrown from public methods of
classes distributed in vljConnector jar.", "", "", ""], ["5244", "vljSecurity Exceptions", "Other", "VISTALINK SECURITY", "2008/07/09", "APPROVED", "Active", "Supported", "", "
Exceptions that can be thrown from public methods of
classes distributed in vljSecurity jar.", "", "", ""], ["5245", "vljFoundationsLib Exceptions", "Other", "FOUNDATIONS", "2008/07/09", "APPROVED", "Active", "Supported", "", "
Exceptions that can be thrown from public methods of
classes distributed in vljFoundationsLib jar.", "", "", ""], ["5246", "READ AND WRITE OF FILE 142.5", "File", "HEALTH SUMMARY", "2008/07/29", "APPROVED", "Active", "Private", "142.5", "
This ICR will allow the Clinical Reminder Package to
read and write from file # 142.5. This is needed to support the functionality
to transport Health Summary Objects in the Reminder Exchange tool.\n
This ICR will allow the Clinical Reminders package to do direct reads on the
fields listed below and to do a write using FileMan to the entire global for
file 142.5.\n", "", "", "2013/10/02"], ["5247", "READ AND WRITE OF FILE 142", "File", "HEALTH SUMMARY", "2008/07/29", "APPROVED", "Active", "Private", "142", "
This ICR will allow the Clinical Reminder Package to
read and write from file # 142. This is needed to support the functionality to
transport Health Summary Types in the Reminder Exchange tool.\n
This ICR will allow the Clinical Reminders package to do direct reads on the
fields listed below and to do a write using FileMan to the entire global for
file 142.\n", "", "", "2013/10/02"], ["5248", "FILEMAN READ FROM THE HEALTH SUMMARY COMPONENT FILE", "File", "HEALTH SUMMARY", "2008/07/29", "APPROVED", "Active", "Private", "142.1", "
This ICR will allow the subscribing packages to do a
FileMan read on file# 142.1.\n", "", "", ""], ["5249", "READ AND WRITE TO FILE 8925.1", "File", "TEXT INTEGRATION UTILITIES", "2008/07/29", "APPROVED", "Active", "Private", "", "
This ICR will allow the Clinical Reminder Package to
read and write from file # 8925.1. This is needed to support the functionality
to transport TIU Objects in the Reminder Exchange tool.\n
This ICR will allow the Clinical Reminders package to do direct reads on the
fields listed below and to do a write using.\n", "", "", "2013/10/30"], ["5250", "PCMM CALLS FOR MYHEALTHEVET - SCAPMC", "Routine", "SCHEDULING", "2008/08/01", "APPROVED", "Active", "Private", "", "
Allows MyHealthEVet to call exisiting API's that are
not supported references.", "", "SCAPMC", "2008/09/15"], ["5251", "Use of Routine MPIHLO2", "Routine", "HEALTH LEVEL SEVEN", "2008/08/05", "APPROVED", "Active", "Private", "", "\n
Master Patient Index (Austin) is requesting permission from the
HL7 developers to establish a private, temporary IA to use routine
MPIHLO2. This HL7 routine was provided by the HL7 developers, to
be installed as MPIHLO2 on the Master Patient Index (Austin).
The routine will be directly removing entries from an existing
sequence queue (^HLB("QUEUE","SEQUEUNCE","MPI LKMV") global and
placing them on an existing out queue (^HLB("QUEUE","OUT") with
the use of the OUTQUE^HLOQUE API (for more details see the routine
below). The code also resets the ^HLC status global as well.\n
The need for this request came from the System-of-System (SoS)
group to help address the critical backlog of messages on the
MPI HLO MPI LKMV sequence queue to PSIM. The ESR project is
scheduled to go live on 8/15/08. In order to accomplish this,
it would require that the MPI HLO queues not have a backlog of
messages. However the current backlog of messages on the MPI
will not be finished at the current rate with the current
software until 9/20/08.\n
The use of routine MPIHLO2 is a temporary measure that will take
all of the ADD events that are currently stacked up on one outbound
queue (Adds/Links/Moves queue) to PSIM and move them directly to the
outbound queue which will allow them to be processed simultaneously
in PSIM rather than one at a time. The implementation will guarantee
that the two databases (MPI and ADR) will stay synchronized by
shutting down the EVENT sequence queue (Add/Link/Move) until all of
the ADD events are sent and successfully processed by PSIM. Then
and only then will we resume normal processing.\n
This routine will only be used a few times (at most for only a few
months). After that we plan to retire it for a more permanent
solution to address the MPI to PSIM synchronization throughput issue.\n
NOTE: Although routine MPIHLO2 was provided/reviewed by the HL7
developers, testing and SQA is the sole responsibility of the
Master Patient Index development team.", "", "MPIHLO2", "2009/03/16"], ["5252", "Lexicon/VBA APIs", "Routine", "LEXICON UTILITY", "2008/08/08", "", "Pending", "Supported", "", "
LEXASCD contains APIs for supporting the Automated
Service Connected Designation (ASCD) project.\n", "", "LEXASCD", ""], ["5253", "DBIA5253", "File", "SCHEDULING", "2008/08/20", "", "Pending", "Private", "44", "
First Draft Request - Need to post developer as to
request questions and variables to determine correctness - LEC 8/20/08", "", "", ""], ["5254", "FILE 4 ACCESS", "File", "KERNEL", "2008/08/25", "", "Pending", "Private", "", "", "", "", ""], ["5255", "PRIVATE ICR FOR CISS TO ACCESS KAAJEE", "Other", "KERNEL", "2008/08/27", "APPROVED", "Active", "Private", "", "\n\n
1. Logins are only to be performed by the CISS framework code. This
IA and supporting IAs are granted to CISS only, not to the application
portlets/plug-ins running in CISS.\n
2. To run user checks and establish user identity for a specific M/VistA
system, CISS should do the following:\n
a. Instantiate a KaajeeVistaLinkConnectionSpec instance, using
user-entered access/verify code and division, and also obtaining the
end-user's IP address, e.g., request.getRemoteAddr().\n
b. Obtain a VistALink connection to the desired M/VistA system from the
appropriate VistaLink connection factory object, using the
KaajeeVistaLinkConnectionSpec instance.\n
c. Using the connection, run the RPC "XUS KAAJEE GET USER INFO" in the
RPC context "XUS SIGNON" to, if successful, get a DUZ back.
This also creates the sign-on log entry on the M/VistA system; the DA
of that entry is also returned. If an exception is thrown, the user
is not authorized to run RPCs on the target VistA system. The exception
will contain the reason for denial.\n
d. If the end-user is authorized to run RPCs by the preceding step,
use the same connection and immediately run the RPC "XUS KAAJEE LOGOUT"
under the RPC context "XUS SIGNON", passing the DA of the sign-on log
entry created. Running the RPC marks the sign-on log entry as closed.\n
e. Close the connection.\n
f. To run application RPCs for the end user, obtain a new connection
from the same VistALink connection factory, but using
VistaLinkDuzConnectionSpec (or, when supported,
VistaLinkVpidConnectionSpec.)\n
3. For the duration of the user session, the DUZ may be used with
DuzConnectionSpec to run RPCs.\n
4. Whether or not CISS caches a user's DUZ, for any new CISS user
sessions requiring access to a VistA system, all steps 2a-2f should be
performed again, as the user's authorization to log onto the VistA system
may have been revoked or otherwise may have changed since the previous
session.\n", "", "", "2008/09/12"], ["5256", "XUS KAAJEE GET USER INFO", "Remote Procedure", "KERNEL", "2008/08/28", "APPROVED", "Active", "Private", "", "\n\n
This is a private ICR/IA for CISS and is in support of ICR/IA # 5255.
Also, this RPC adds a new entry in Kernel's SIGN-ON LOG (File #3.081).\n", "XUS KAAJEE GET USER INFO", "", "2008/09/12"], ["5257", "XUS KAAJEE LOGOUT", "Remote Procedure", "KERNEL", "2008/08/28", "APPROVED", "Active", "Private", "", "\n\n
This is a private ICR/IA for CISS and is in support of ICR/IA # 5255.\n", "XUS KAAJEE LOGOUT", "", "2008/09/12"], ["5258", "ICR FOR CISS TO ACCESS VSS", "SQL Table", "VOLUNTARY SERVICE SYSTEM", "2008/08/29", "APPROVED", "Active", "Private", "", "\n\n\n", "", "", "2008/09/22"], ["5259", "LAB HL7 ORU MESSAGE", "Other", "AUTOMATED LAB INSTRUMENTS", "2008/09/04", "APPROVED", "Active", "Supported", "", "
The following event protocol is supported for packages
to add their subscriber protocol to subscribe to Laboratory results.\n
NAME: LA7 LAB RESULTS AVAILABLE (EVN)
ITEM TEXT: Lab Results Available Event\n
DESCRIPTION: A VistA Laboratory package HL7 ORU result message is created
and sent by the HL package for transmission to any subscribers of event
protocol LA7 LAB RESULTS AVAILABLE (EVN).\n
It provides the capability for the generation of a Laboratory HL7 ORU
message containing patient laboratory results to subscribers of the HL7
event protocol LA7 LAB RESULTS AVAILABLE (EVN) as these results are made
available within the Laboratory package.\n
The following subscripts are supported by the event:
"CH", "MI", "SP", "CY", "EM".", "", "", "2010/07/14"], ["5260", "Private IA for CISS to use VistaLinkSystemInfoVO", "Other", "VISTALINK", "2008/09/09", "APPROVED", "Active", "Private", "", "
This agreement pertains to subscriber use of VistALink
v1.5 only.\n
Permission is granted to use the getIntroText() and getErrorMessage() methods
of the gov.va.med.vistalink.adapter.spi.VistaLinkSystemInfoVO class. These
methods return values populated earlier by a query to an M system.\n
Note: VistaLinkSystemInfoVO objects are the return value of the
getMSystemInfo() method of gov.va.med.vistalink.adapter.spi.ConnectorInfoVO.", "", "", "2009/08/17"], ["5261", "Private IA for CISS to use getMCFInfo()", "Other", "VISTALINK", "2008/09/09", "APPROVED", "Active", "Private", "", "
This agreement pertains to subscriber use of VistALink
v1.5 only.\n
Permission is granted to use the getMCFInfo() method of
gov.va.med.vistalink.adapter.cci.VistaLinkConnectionFactory, under the
following conditions:\n
1. It is to be used by the CISS application only, not by portlets or other
plug-ins to the CISS framework.\n
2. It is to be used prior to obtaining connection(s) from a given
VistaLinkConnectionFactory instance.\n
3. It is to be used only to retrieve the introductory text from the target
M/VistA system for the purposes of supporting login functionality to the
target M/VistA system.\n
4. If an error is encountered, the getErrorMessage() method of one of the
returned objects (gov.va.med.vistalink.adapter.spi.VistaLinkSystemInfoVO) will
return a non-null, non-zero-length string.", "", "", "2009/08/17"], ["5262", "Private IA for CISS to use ConnectorInfoVO", "Other", "VISTALINK", "2008/09/12", "APPROVED", "Active", "Private", "", "
This agreement pertains to subscriber use of VistALink
v1.5 only.\n
Permission is granted to use the getMSystemInfo() method of the
gov.va.med.vistalink.adapter.spi.ConnectorInfoVO class. This method returns a
VistaLinkSystemInfoVO object instance, populated earlier by a query to an M
system.\n
Note: ConnectorInfoVO objects are the return value of the getMCFInfo() method
of gov.va.med.vistalink.adapter.cci.VistaLinkConnectionFactory.", "", "", "2009/08/17"], ["5263", "Call to API UPDEXDT in routine PSOEXDT", "Routine", "OUTPATIENT PHARMACY", "2008/09/23", "APPROVED", "Active", "Private", "", "
Call to API UPDEXDT^PSOEXDT. This API updates the
Expiration Date for the following scenarios: normal release of an Rx, return
to stock or reinstate. Release update only occurs if the last refill is being
released.", "", "PSOEXDT", "2008/10/01"], ["5264", "SERVICE INFORMATION", "File", "ENROLLMENT APPLICATION SYSTEM", "2008/09/23", "APPROVED", "Active", "Private", "2", "
SVC^VADPT will not return the service related
information on nodes 6, 7, and 8 unless the SERVICE BRANCH field, which is not
a required field, has a value. This means that required fields such as SERVICE
SEPARATION DATE LAST will not be returned unless SERVICE BRANCH LAST has a
value. Therefore using SVC^VADPT can lead to the erroneous conclusion that a
patient does not have a SERVICE SEPARATION DATE LAST and this data is key to
determining if a patient needs OEF/OIF and TBI screening. To overcome this
deficiency Clinical Reminders is requesting direct read access to the data
returned on the 6, 7, and 8 nodes by SVC^VADPT.\n", "", "", "2008/09/30"], ["5265", "MyHealtheVet read access to File 40.9 Location Type", "File", "SCHEDULING", "2008/09/25", "APPROVED", "Active", "Private", "40.9", "
Read access to file 40.9 by the MyHealtheVet package
using FILEMAN", "", "", "2008/09/30"], ["5266", "MyHealtheVet access to file 44 Hospital Location", "File", "SCHEDULING", "2008/09/25", "APPROVED", "Active", "Private", "44", "
Myhealthevet access to file 44 Hospital Location to add
"Secure Messaging" as a location.", "", "", "2008/09/30"], ["5267", "Use of NURSF(210", "File", "NURSING SERVICE", "2008/09/25", "APPROVED", "Active", "Private", "210", "
This agreement allows read access to the Nursing Staff
file #210.", "", "", "2008/09/30"], ["5268", "ATTENDING SURGEON/PROVIDER", "File", "SURGERY", "2008/09/30", "", "Pending", "Private", "130", "
This ICR grants permission to read specific fields in
the SURGERY file (#130) using VA FileMan.", "", "", ""], ["5269", "MDTERM", "Routine", "CLINICAL PROCEDURES", "2008/10/02", "APPROVED", "Active", "Private", "", "", "", "MDTERM", "2010/03/04"], ["5270", "CALLRPC MPIFDNL", "Routine", "MASTER PATIENT INDEX VISTA", "2008/10/09", "APPROVED", "Active", "Private", "", "
CALLRPC^MPIFDNL calls Remote Procedure MPIF DNL ADD UPD
to add a record with a pair of patient DFNs to the MPI DO NOT LINK file on the
MPI Server. This file is used to prevent users from attempting to LINK
patients who have been determined to not be duplicates.\n
DNLCHK^MPIFDNL calls Remote Procedure MPI EVENT LIST, which returns (among
other things) a list of DFNs for those patients that are marked as "Do Not
Link" with the passed in DFN. From this list, DNLCHK^MPIFDNL determines
whether to allow the selected pair of patients to be added to the DUPLICATE
RESOLUTION file.", "", "MPIFDNL", "2010/08/04"], ["5271", "ADD XDRDADDS", "Routine", "TOOLKIT", "2008/10/09", "APPROVED", "Active", "Private", "", "
ADD^XDRDADDS adds a patient pair record to the
DUPLICATE RECORD file (#15) at a VistA site. It can be called directly, but
can also be invoked using the Remote Procedure call XDR ADD POTENTIAL PATIENT
DUP.\n
With patch MPI*1.0*62, and accompanying patches MPIF*1.0*52 and XT*7.3*113,
most entries will be made to a local VistA DUPLICATE RECORD file because of an
action taken by the Person Service Identity Management package (PSIM). Either
a pair of patients is determined to be above the Auto Match Threshold by the
commercial search engine Initiate, or a pair of patients has been determined
to be a potential match and verified by the Identity Management Data Quality
group (IMDQ).", "", "XDRDADDS", "2009/03/12"], ["5272", "FBCS FILE 161 R/W/D", "File", "FEE BASIS", "2008/10/12", "", "Retired", "Controlled Subscription", "161", "
FBCS accesses the FEE BASIS PATIENT (#161) file to
read/write. Some deletions will be done on the AUTHORIZATION multiple
(#161.01) after data integrity checks. Applicable Authorized Services (FIELD
7 from file #162.4) are copied to field .021 Authorization Remark.\n
^FBAAA(DA,0) Global r ($D)
.01 NAME 0;1 Fileman r
^FBAAA(D0,1,0) Global r (get count)
1 AUTHORIZATION 0;4
^FBAAA(D0,1,D1,0) Global r ($D)
.01 FROM DATE 0;1 Fileman r/w,Laygo,Global r
.02 TO DATE 0;2 Fileman r/w,Global r
.03 FEE PROGRAM 0;3 Fileman r/w,Global r
.04 VENDOR 0;4 Fileman r/w,Global r/w
101 PRIMARY SERVICE AREA 0;5 Fileman r/w,Global r
.07 PURPOSE OF VISIT CODE 0;7 Fileman r/w,Global r
.08 DX LINE 1 0;8 Fileman r/w
.055 ASSOCIATED 7078/583 0;9 Fileman r,Global r
.095 TREATMENT TYPE CODE 0;13 Fileman r/w,Global r
2 TYPE OF CARE 0;14 Fileman r/w
.06 DISCHARGE TYPE 0;15 Fileman r/w
.065 PATIENT TYPE CODE 0;18 Fileman r/w,Global r
.096 ACCIDENT RELATED (Y/N) 0;19 Fileman r/w
.097 POTENTIAL COST RECOV 0;20 Fileman r/w
104 REFERRING PROVIDER 0;21 Fileman r/w,Global r
^FBAAA(D0,1,D1,1)
3 DATE PRINTED 1;2 Fileman r
^FBAAA(D0,1,D1,2,0)
.021 AUTHORIZATION REMARKS
^FBAAA(D0,1,D1,2,D2,0)
.01 AUTHORIZATION REMARK 0;1 Fileman r/w,Global r/w
^FBAAA(D0,1,D1,3)
.085 DX LINE 2 3;1 Fileman r/w,Global r
.086 DX LINE 3 3;2 Fileman r/w,Global r
^FBAAA(D0,1,D1,100)
100 CLERK 100;1 Fileman r/w
^FBAAA(D0,1,D1,ADEL)
103 DATE DELETE MRA TRAN ADEL;2 Global r
^FBAAA(D0,1,D1,C)
1 PRINT AUTHORIZATION C;1 Fileman r/w
^FBAAA(D0,1,D1,LOG1,D2,0)
.01 DATA/TIME EDITED 0;1 Fileman r
1 EDITED BY 0;2 Fileman r
2 COMMENTS 0;3 Fileman r
^FBAAA(DO,1,D1,LOG2,D2,0)
.01 CHANGED DATE/TIME 0;1 Fileman r
1 FIELD 0;2 Fileman r
2 OLD VALUE 0;3 Fileman r
3 NEW VALUE 0;4 Fileman r
4 CHANGED BY 0;5 Fileman r
^FBAAA(D0,4)
.5 FEE ID CARD NUMBER 4;1 Fileman r,Global r
.6 FEE ID CARD ISSUE DATE 4;2 Fileman r,Global r
^FBAA("AG") Lookup by ASSOCIATED 7078/583
^FBAA("ATST") Lookup by From Date
^FBAAA(DFN,1,"B") Lookup by Authorization From Date", "", "", "2016/04/29"], ["5273", "FBCS FILE #161.7 R/W/D", "File", "FEE BASIS", "2008/10/15", "", "Retired", "Controlled Subscription", "161.7", "
FBCS accesses the FEE BASIS BATCH (#161.7) file to
read/write. Entries can be deleted using ^DIK if it passes criteria (no
rejects pending, etc).\n
^FBAA(161.7,D0,0)
.01 NUMBER 0;1 Fileman r/w,Global r
1 OBLIGATION NUMBER 0;2 Fileman r/w,Global r
2 TYPE 0;3 Fileman r/w,Global r
3 DATE OPENED 0;4 Fileman r/w,Global r
4 CLERK WHO OPENED 0;5 Fileman r/w,Global r
5 DATE SUPERVISOR CLOS 0;6 Fileman r,Global r/w
6 SUPERVISOR WHO CERTI 0;7 Fileman r,Global w
16 STATION NUMBER 0;8 Fileman r/w,Global r
8 TOTAL DOLLARS 0;9 Fileman r/w,Global r/w
9 INVOICE COUNT 0;10 Fileman r/w,Global r/w
10 PAYMENT LINE COUNT 0;11 Fileman r/w,Global r/w
13 DATE FINALIZED 0;12 Fileman r/w,Global r/w
4.5 DATE CLERK CLOSED 0;13 Fileman r/w,Global r/w
12 DATE TRANSMITTED 0;14 Fileman r/w,Global r
17 CONTRACT HOSPITAL BA 0;15 Fileman r/w,Global r
14 PERSON WHO COMPLETED 0;16 Fileman r/w
15 REJECTS PENDING 0;17 Global r/w
18 BATCH EXEMPT 0;18 Fileman r,Global r/w
19 STATISTICAL BATCH 0;19 Global r
^FBAA(161.7,D0,ST)
11 STATUS ST;1 Fileman r/w,Global r/w\n
^FBAA(161.7,"AB") by status without field 5 (date closed)
manually kill xref
^FBAA(161.7,"AC") Lookup by status, check is status exists
manually sets/kills xref
^FBAA(161.7,"B") Lookup by batch", "", "", "2009/06/11"], ["5274", "FBCS FILE 442", "File", "IFCAP", "2008/10/15", "", "Retired", "Controlled Subscription", "442", "
The Fee Basis Claims system accesses the PROCUREMENT &
ACCOUNTING TRANSACTIONS (#442) file in order to return a list of obligations
based upon Control point and number of years past for reports, as well as
lookup obligations by control point.\n
^PRC(442,D0,0)
.01 PURCHASE ORDER NUMBE 0;1 Read w/Fileman
1 FCP 0;3 Fileman r/global r
1.4 APPROPRIATION 0;4 Global r
2 COST CENTER 0;5 Global r
3 SUBACCOUNT1 0;6 Global r
3.4 SUBAMOUNT1 0;7 Global r
4 SUBACCOUNT2 0;8 Global r
4.4 SUBAMOUNT2 0;9 Global r
91 TOTAL AMOUNT 0;15 Read w/Fileman
.07 PRIMARY 2237 0;12 Fileman r/global r
^PRC(442,D0,1)
.1 P.O. DATE 1;15 Read w/Fileman
^PRC(442,D0,7)
.5 SUPPLY STATUS 7;1 Fileman r/global r
^PRC(442,D0,8)
94 ACTUAL 1358 BALANCE 8;1 Fileman r/global r
96 EST 1358 BALANCE 8;3 Fileman r/global r
^PRC(442,D0,23)
31 SUBSTATION 23;7 Global r\n
^PRC(442,"B") Used for IEN lookup
^PRC(442,"C") Used for IEN lookup
^PRC(442,"E") Used for FCP lookups", "", "", "2009/01/06"], ["5275", "FBCS ACCESS TO FILE #161.4 R/O", "File", "FEE BASIS", "2008/10/16", "", "Retired", "Controlled Subscription", "161.4", "
FBCS accesses the FEE BASIS SITE PARAMETERS (#161.4)
file as part of the lookup of existing Fee Basis Site parameters to ensure
parameters are defined and to get batch numbers.\n
^FBAA(161.4,D0,0) Global r ($G),($D)
^FBAA(161.4,D0,1) Global r ($G)
27 PSA DEFAULT INSTITUTION 1;3 Global r
^FBAA(161.4,D0,FBNUM) Lock
10 NEXT BATCH NUMBER FBNUM;1 Global r/w
11 NEXT INVOICE NUMBER FBNUM;2 Global r/w
17 MAX # PAYMENT LINE ITEMS FBNUM;3 Global r
^FBAA(161.4,D0,PURGE)
29 DATE BATCH PURGE LAST RUN PURGE;1 Global r", "", "", "2009/06/11"], ["5276", "FBCS File #161.6 Read only", "File", "FEE BASIS", "2008/10/16", "", "Retired", "Controlled Subscription", "161.6", "
The FBCS application accesses the FEE BASIS SPECIALTY
CODE (#161.6) file to get the name field for display.\n
^FBAA(161.6,D0,0)
.01 NAME 0;1 Global r", "", "", "2009/06/11"], ["5277", "FBCS ACCESS TO FILE #162.5", "File", "FEE BASIS", "2008/10/16", "", "Retired", "Private", "162.5", "
The Fee Basis Claims system accesses the FEE BASIS
INVOICE (#162.5) file to view invoices and perform other claim functions.\n
^FBAAI(D0,0)
.01 NUMBER 0;1 Fileman r/w
1 INVOICE DATE RECEIVE 0;2 Fileman r/w,global r
2 VENDOR 0;3 Fileman r/w,global r
3 VETERAN 0;4 Fileman r,global r
4 ASSOCIATED 7078/583 0;5 Fileman r/w,global r
5 TREATMENT FROM DATE 0;6 Fileman r/w,global r
6 TREATMENT TO DATE 0;7 Fileman r/w,global r
7 AMOUNT CLAIMED 0;8 Fileman r/w,global r
8 AMOUNT PAID 0;9 Fileman r/w,global r
9 AMOUNT SUSPENDED 0;10 Fileman r,global r
10 SUSPEND CODE 0;11 Fileman r,global r
11 FEE PROGRAM 0;12 Fileman r/w,global r
12 PAYMENT TYPE CODE 0;13 Fileman r,global r
16 VOID PAYMENT 0;14 Fileman r,global r
17 SUPERVISOR WHO VOIDE 0;15 Read w/Fileman
19 DATE FINALIZED 0;16 Read w/Fileman
20 BATCH NUMBER 0;17 Fileman r/w, global r
21 PURPOSE OF VISIT 0;18 Read w/Fileman
22 PT TYPE CODE 0;19 Fileman r,global r
23 PRIMARY SERVICE FACI 0;20 Read w/Fileman
6.5 DISCHARGE TYPE CODE 0;21 Fileman r/w
6.6 BILLED CHARGES 0;22 Fileman r/w
6.7 PAYMENT BY MEDICARE/FED 0;23 Fileman r/w
24 DISCHARGE DRG 0;24 Fileman r/w,global r
25 RESUBMISSION 0;25 Fileman r/w
26 NVH PRICER AMOUNT 0;26 Fileman r/w
^FBAAI(D0,1,D1,0)
.01 DESCRIPTION OF SUSPENSE 0;1 Read w/Fileman ok
^FBAAI(D0,2)
45 DATE PAID 2;1 Fileman r,global r
46 VENDOR INVOICE DATE 2;2 Fileman r/w
47 PROMPT PAY TYPE 2;3 Fileman r/w
48 CHECK NUMBER 2;4 Fileman r,global r
49 CANCELLATION DATE 2;5 Fileman r,global r
50 REASON CODE 2;6 Fileman r,global r
51 CANCELLATION ACTIVIT 2;7 Fileman r,global r
52 DISBURSED AMOUNT 2;8 Fileman r,global r
53 INTEREST AMOUNT 2;9 Fileman r/global r
54 COVERED DAYS 2;10 Fileman r/w,global r
55 PATIENT CONTROL NUMB 2;11 Fileman r/w,global r
24.5 DRG WEIGHT 2;12 Fileman r/w
^FBAAI(D0,3)
56 FPPS CLAIM ID 3;1 Fileman r,global r
57 FPPS LINE ITEM 3;2 Fileman r,global r
^FBAAI(D0,8,0)
58 ADJUSTMENT Fileman r
^FBAAI(D0,8,D1,0)
.01 ADJSUTMENT REASON 0;1 Fileman r/w
1 ADJUSTMENT GROU 0;2 Fileman r/w
2 ADJUSTMENT AMOUNT 0;3 Fileman r/w
^FBAAI(D0,9,D1,0)
.01 REMITTANCE REMARK 0;1 Fileman r/w
^FBAAI(D0,DX)
30 ICD1 DX;1 Fileman r/w,global r
31 ICD2 DX;2 Fileman r/w,global r
32 ICD3 DX,3 Fileman r/w,global r
33 ICD4 DX;4 Fileman r/w,global r
34 ICD5 DX;5 Fileman r/w,global r
^FBAAI(D0,FBREJ)
13 REJECT STATUS FBREJ;1 Fileman r/w
14 REJECT REASON FBREJ;2 Fileman r/w
15 OLD BATCH NUMBER FBREJ;3 Fileman r/w
^FBAAI(D0,PROC)
40 PROC1 PROC;1 Fileman r/w,global r
41 PROC2 PROC;2 Fileman r/w,global r
42 PROC3 PROC;3 Fileman r/w,global r
43 PROC4 PROC;4 Fileman r/w,global r
44 PROC5 PROC;5 Fileman r/w,global r
^FBAAI(D0,R)
16.5 REASON FOR VOIDED PA R;1 Read w/Fileman\n
^FBAAI("AC") Used to lookup by Batch Number
^FBAAI("AD") Used to lookup by Date Finalized
^FBAAI("AE") Used to lookup by Batch and Veteran
^FBAAI("AH") Used to lookup by Old Batch number
^FBAAI("E") Used to lookup by Associated 7078/583", "", "", "2009/06/11"], ["5278", "FBCS File #161.2 Read only", "File", "FEE BASIS", "2008/10/16", "", "Retired", "Private", "161.2", "
The Fee Basis Claims system accesses the FEE BASIS
VENDOR (#161.2) file to get vendor details and to get the vendor for fee
batches.\n
^FBAAV(D0,0)
.01 NAME 0;1 Fileman r/global r
1 ID NUMBER 0;2 Fileman r/global r
2 STREET ADDRESS 0;3 Fileman r/global r
3 CITY 0;4 Fileman r/global r
4 STATE 0;5 Fileman r/global r
5 ZIP CODE 0;6 Fileman r/global r
6 TYPE OF VENDOR 0;7 Fileman r/global r
global r of DD for codeset
.05 SPECIALTY CODE 0;8 Fileman r/global r
7 PART CODE 0;9 Fileman r/global r
8 CHAIN 0;10 Fileman r/global r
5.5 COUNTY 0;13 Fileman r/global r
2.5 STREET ADDRESS 2 0;14 Fileman r/global r
22 MEDICARE ID NUMBER 0;17 Fileman r/global r
^FBAAV(D0,1)
14 PHONE NUMBER 1;1 Fileman r/global r
19 CERTIFIED MEDICARE/MEDICAID 1;5 Read w/Fileman
23 FAX NUMBER 1;9 Fileman r/global r
24 BUSINESS TYPE 1;10 Fileman r/global r
^FBAAV(D0,2,D1,0)
.01 SOCIOECONOMIC GROUP 0;1 Global r
^FBAAV(D0,ADEL)
9 AUSTIN DELETED ADEL;1 Fileman r/global r
12 DATE LAST CORRECTION TO AUSTIN ADEL;2 Fileman r/global r
12.1 DATE LAST UPDATE FROM AUSTIN ADEL;4 Fileman r/global r
13.1 STATION AFFECTING LAST CHANGE ADEL;5 Global r
^FBAAV(D0,AMS)
30.01 AUSTIN NAME FIELD AMS;1 Fileman r/global r
30.02 PRICER EXEMPT AMS;2 Global r\n
^FBAAV("C") Used for lookup by ID Number
^FBAAV("ADEL") Used to see if marked for deletion", "", "", "2009/06/11"], ["5279", "FBCS File #162.2 R/W", "File", "FEE BASIS", "2008/10/22", "", "Retired", "Controlled Subscription", "162.2", "", "", "", ""], ["5280", "FBCS File #162.6 Read only", "File", "FEE BASIS", "2008/10/23", "", "Withdrawn", "Controlled Subscription", "162.6", "", "", "", ""], ["5281", "FBCS File #353.1 Read only", "File", "INTEGRATED BILLING", "2008/10/23", "", "Retired", "Controlled Subscription", "353.1", "
Using cross references: ^IBE(353.1,"B" to verify .01
field (external entries conversion to IEN)\n
Also using fileman to get values for a pull down list (palce of service): D
LIST^DIC(353.1,"",".01;.02","","","","","","","","ARRAY","MSG")", "", "", "2008/12/03"], ["5282", "FBCS File #353.2 Read only", "File", "INTEGRATED BILLING", "2008/10/23", "", "Retired", "Controlled Subscription", "353.2", "
Verifying data at node: $D(^IBE(353.2,IEN,0)\n\n
Also using FM to retrieve a list for the GUI of HCFA type of Service: D
LIST^DIC(353.2,"",".01;.02","","","","","","","","ARRAY","MSG")", "", "", "2008/12/03"], ["5283", "FBCS File #200 Read only", "File", "KERNEL", "2008/10/23", "", "Withdrawn", "Controlled Subscription", "200", "", "", "", ""], ["5284", "FBCS File #161.5 R/W", "File", "FEE BASIS", "2008/10/24", "", "Retired", "Controlled Subscription", "161.5", "
The Fee Basis Claims system accesses the FEE CH REPORT
OF CONTACT (#161.5) file in order to add/edit contact information. Entries
may be deleted using ^DIK if the associated notification entry in file #162.2
is deleted.\n
^FBAA(161.5,D0,0) Global r ($D)
.01 ASSOCIATED REQUEST 0;1 Fileman r/w
1 VENDOR 0;2 Fileman r/w
2 VETERAN 0;3 Fileman r/w
3 INITIAL DATE OF CONT 0;4 Fileman r/w
4 AUTHORIZATION FROM D 0;5 Fileman r/w
5 TYPE OF CONTACT 0;6 Fileman r/w,Global r
7 STREET ADDRESS[1] OF 0;8 Fileman r/w
8 STREET ADDRESS[2] OF 0;9 Fileman r/w
9 CITY OF CONTACT 0;10 Fileman r/w
10 STATE OF CONTACT 0;11 Fileman r/w
11 ZIP CODE OF CONTACT 0;12 Fileman r/w
12 ATTENDING PHYSICIAN 0;13 Fileman r/w
13 ATTEND.PHYSICIAN TEL 0;14 Fileman r/w
^FBAA(161.5,D0,1)
14 TENTATIVE DIAGNOSIS 1;1 Fileman r/w
15 INSURANCE TYPE 1;2 Fileman r/w
16 MODE OF TRANSPORTATI 1;3 Fileman r/w
6.5 PHONE # OF PERSON CO 1;4 Fileman r/w
16.5 VETERAN HAVE OTHER I 1;5 Fileman r/w
18 APPROVING OFFICIAL 1;6 Fileman r/w
19 DATE OF ADMISSION 1;7 Fileman r/w
^FBAA(161.5,D0,2,D1,0)
.01 DATE/TIME OF CONTACT 0;1 Fileman r/w
2 USER 0;2 Fileman r/w
^FBAA(161.5,D0,2,D1,1,D2,0)
.01 NARRATIVE 0;1 Fileman r/w\n
^FBAA(161.5,"B") Lookup by request", "", "", "2009/06/11"], ["5285", "DBIA5285", "Routine", "HEALTH LEVEL SEVEN", "2008/11/03", "", "Withdrawn", "Private", "", "
PROVIDES A TOOL TO CONVERT MESSAGES GENERATED FOR HL7
TO MESSAGES THAT CAN BE SENT BY HLO. ALSO PROVIDES THE ABILITY TO OVERIDE
PARAMETERS DEFINED IN THE EVENT AND SUBSCRIBER PROTOCOLS.", "", "HLOCNRT1", ""], ["5286", "PAY-TO PROVIDER PHONE NUMBER API", "Routine", "INTEGRATED BILLING", "2008/11/06", "APPROVED", "Active", "Private", "", "
This is a replacement IA for IA# 4049. The purpose of
the IA is the same.\n
When an electronic EOB is received in error at a site, EDI Lockbox has
functionality to transfer that EOB electronically to another site. The IB
Site Parameters file (#350.9) contains the Pay-to Provider phone#. This
phone# is the contact information for the receiving site to use to contact the
sending site if there are questions regarding the EOB. Accounts Receivable
needs to be able to retrieve this phone# from the IB Site Parameters file in
order for it to be included in the transferred EOB.", "", "IBJPS3", "2008/11/21"], ["5287", "E CLAIMS MGMT ENGINE Option Access", "", "E CLAIMS MGMT ENGINE", "2011/05/16", "", "Withdrawn", "", "", "", "", "", ""], ["5288", "ZOSVKR", "Routine", "KERNEL", "2008/11/10", "APPROVED", "Active", "Private", "", "
The pharmacy re-engineering team needs a way to record
the time it takes to make a call for an order check. Order checks usually take
less than a second or two (possibly more if an RDI call is necessary). The
Kernel API $$STATS^%ZOSVKR breaks down the time frame into hundredths of a
second. This information is vital for Pharmacy Re-Engineering.", "", "%ZOSVKR", "2011/04/22"], ["5289", "VA Fileman Option Access", "", "1", "", "", "Withdrawn", "", "", "", "", "", ""], ["5290", "HLO VDEF API", "Routine", "HEALTH LEVEL SEVEN", "2008/11/20", "APPROVED", "Active", "Private", "", "\n
The routine HLOAPI6 is provided as an API to allow VDEF to verify that
HLO is installed, running and has all the required parameters for a
specific HL7 message type and HL7 event type. These parameters must
be defined prior to use by VDEF users before VDEF can use HLO.", "", "HLOAPI6", "2009/07/01"], ["5291", "DSIV IMAGING ACCESS", "File", "IMAGING", "2008/11/23", "APPROVED", "Active", "Private", "2005", "
The DSIV package is requsting use of the "ATRKID" cross
reference to get the image IEN in the Image file (#2005) of an image that is
has imported using the Import API. The IEN is stored in an SQL database and
also verifies that the scanned document, or other image, was successfully
uploaded to imaging. The DocManager piece of DSIV has been tested by VistA
Imaging.\n
Note: DSIV also uses ICR 4526 (MAG4 REMOTE IMPORT) RPC from Imaging. The use
of the MAG4 REMOTE IMPORT RPC and access to the "ATRKID" cross reference is
limited to the DSS DocManager application only. Any other DSIV application
will need approval before using the RPC or cross reference.", "", "", "2009/06/11"], ["5292", "INSURANCE CO FILE ACCESS", "File", "INTEGRATED BILLING", "2008/11/23", "APPROVED", "Active", "Private", "36", "
DSIV requests access to the Insurance Company file
(#36) to do the following for its Insurance Capture Buffer (ICB) application:\n
Using file #36 as a file lookup using ^DIC, and as a pointer directly to
^DIC(36) in DSI ICB AUDIT file (#19625 - INSURANCE DFN POINTER (#4.12))\n
Also these usages:
^DIC(36,D0,0)
.01 NAME 0;1 Read w/FileMan
1 REIMBURSE? 0;2 Read w/FileMan
2 SIGNATURE REQUIRED ON BILL? 0;3 Read/Write w/FileMan
.05 INACTIVE 0;5 Read w/FileMan
.12 FILING TIME FRAME 0;12 Read/Write w/FileMan
.13 TYPE OF COVERAGE 0;13 Read/Write w/FileMan and
with pointer to the
TYPE OF COVERAGE file
(#355.2). This is the type
of insurance coverage.
.18 STANDARD FTF 0;18 Read/Write w/FileMan and
with pointer to the
INSURANCE FILING TIME FRAME
file (#355.13). This is
the standard filing time
frame that applies to the
insurance.
.19 STANDARD FTF VALUE 0;19 Read/Write w/FileMan
^DIC(36,D0,.11)
.111 STREET ADDRESS [LINE 1] .11;1 Read w/FileMan
.112 STREET ADDRESS [LINE 2] .11;2 Read w/FileMan
.113 STREET ADDRESS [LINE 3] .11;3 Read w/FileMan
.114 CITY .11;4 Read w/FileMan
.115 STATE .11;5 Read w/FileMan
.116 ZIP CODE .11;6 Read w/FileMan
.119 FAX NUMBER .11;9 Read/Write w/FileMan
^DIC(36,D0,.13)
.131 PHONE NUMBER .13;1 Read w/FileMan
.132 BILLING PHONE NUMBER .13;2 Read w/FileMan
.133 PRECERTIFICATION PHONE NUMBER .13;3 Read w/FileMan
^DIC(36,D0,3)
3.01 TRANSMIT ELECTRONICALLY 3;1 Read/Write w/FileMan
3.09 ELECTRONIC INSURANCE TYPE 3;9 Read/Write w/FileMan
^DIC(36,D0,10,0) (#10) SYNOMYM Multiple (subfile #36.06)
.01 SYNONYM 0;1 Read/Write w/FileMan
^DIC(36,D0,11,0) (#11) REMARKS Word-processing (subfile #36.011)
.01 REMARKS 0;1 Read/Write w/FileMan", "", "", "2012/09/13"], ["5293", "GROUP INSURANCE PLAN ACCESS", "File", "INTEGRATED BILLING", "2008/11/23", "APPROVED", "Active", "Private", "355.3", "
Update: IB*2*497 increased the length of the GROUP NAME
field and GROUP NUMBER field to support the EDI New Standards and Operating
Rules for VHA providers. This required length increase made it necessary to
move the location of these 2 fields to new Data Dictionary nodes. To support
this implementation, all subscribers to this ICR will need to make the
necessary changes in their applications to reference the new fields and remove
the references to the old fields. When all subscribers have implemented the
use of the new fields, the old fields will be deleted with IB*2*518. New
fields are noted in the field list detail of this ICR.\n
DSIV requests access to file 355.3 GROUP INSURANCE PLAN to do the following
for its Insurance Capture Buffer (ICB) application:\n
As a pointer directly to ^DIC(355.3 in ICB AUDIT FILE file (#19625) - GROUP
PLAN IEN POINTER field (#4.14)\n
Also these usages:
^IBA(355.3,D0,0)
.01 INSURANCE COMPANY 0;1 Read w/FileMan
.02 IS THIS A GROUP POLICY? 0;2 Read w/FileMan
.03 *GROUP NAME 0;3 Read w/FileMan
Note: IB*2*497 - replaced by GROUP NAME field (2.01)
.04 *GROUP NUMBER 0;4 Read w/FileMan
Note: IB*2*497 - replaced by GROUP NUMBER field (2.02)
.05 IS UTILIZATION REVIEW REQUIRED 0;5 Read w/FileMan
.06 IS PRE-CERTIFICATION REQUIRED? 0;6 Read w/FileMan
.07 EXCLUDE PRE-EXISTING CONDITION 0;7 Read w/FileMan
.08 BENEFITS ASSIGNABLE? 0;8 Read w/FileMan
.09 TYPE OF PLAN 0;9 Read w/FileMan
.1 INDIVIDUAL POLICY PATIENT 0;10 Read w/FileMan
.11 INACTIVE 0;11 Read w/FileMan
.12 AMBULATORY CARE CERTIFICATION 0;12 Read w/FileMan
.13 PLAN FILING TIME FRAME 0;13 Read w/FileMan
.15 ELECTRONIC PLAN TYPE 0;15 Read w/FileMan\n
^IBA(355.3,D0,2)
2.01 GROUP NAME 2;1 Read w/FileMan
2.02 GROUP NUMBER 2;2 Read w/FileMan\n
^IBA(355.3,D0,6)
6.02 BANKING IDENTIFICATION NUMBER 6;2 Read w/FileMan
6.03 PROCESSOR CONTROL NUMBER 6;3 Read w/FileMan\n
^IBA(355.3,D0,11,D1,0)
.01 COMMENTS (WP) 0;1 FileMan read/write", "", "", "2014/02/21"], ["5294", "INSURANCE BUFFER FILE ACCESS", "File", "INTEGRATED BILLING", "2008/11/23", "APPROVED", "Active", "Private", "355.33", "
Update: IB*2*497 increased the length of the SUBSCRIBER
ID field, NAME OF INSURED field, GROUP NAME field, and GROUP NUMBER field to
support the EDI New Standards and Operating Rules for VHA providers. This
required length increase made it necessary to move the location of these 4
fields to new Data Dictionary nodes. To support this implementation, all
subscribers to this ICR will need to make the necessary changes in their
applications to reference the new fields and remove the references to the old
fields. When all subscribers have implemented the use of the new fields, the
old fields will be deleted with IB*2*518 patch. New fields are noted in the
field list detail of this ICR.\n
DSIV requests access to file 355.33 INSURANCE BUFFER to do the following for
its Insurance Capture Buffer (ICB) application to add/edit entries.\n
^IBA(355.33,D0,0)
.01 DATE ENTERED 0;1 FileMan read/write
.01 DATE ENTERED 0;1 Laygo new entry into file
.02 ENTERED BY 0;2 FileMan read/write
.03 SOURCE OF INFORMATION 0;3 FileMan read/write
.04 STATUS 0;4 FileMan read
.05 DATE PROCESSED 0;5 FileMan r,Direct Global r
.06 PROCESSED BY 0;6 FileMan read
.07 NEW COMPANY 0;7 FileMan read/write
.08 NEW GROUP/PLAN 0;8 FileMan read/write
.09 NEW POLICY 0;9 FileMan read/write
.1 DATE VERIFIED 0;10 FileMan read/write
.11 VERIFIED BY 0;11 FileMan read/write
.12 IIV STATUS 0;12 FileMan read/write
.13 OVERRIDE FRESHNESS FLAG 0;13 FileMan read
.14 REMOTE LOCATION 0;14 FileMan read
.15 IIV PROCESSED DATE 0;15 FileMan read
.17 BPS RESPONSE 0;17 FileMan read
^IBA(355.33,D0,20)
20.01 INSURANCE COMPANY NAME 20;1 FileMan read/write
20.02 PHONE NUMBER 20;2 FileMan read/write
20.03 BILLING PHONE NUMBER 20;3 FileMan read/write
20.04 PRECERTIFICATION PHONE NUMBER 20;4 FileMan read/write
20.05 REIMBURSE? 20;5 FileMan read/write
^IBA(355.33,D0,21)
21.01 STREET ADDRESS [LINE 1] 21;1 FileMan read/write
21.02 STREET ADDRESS [LINE 2] 21;2 FileMan read/write
21.03 STREET ADDRESS [LINE 3] 21;3 FileMan read/write
21.04 CITY 21;4 FileMan read/write
21.05 STATE 21;5 FileMan read/write
21.06 ZIP CODE 21;6 FileMan read/write
^IBA(355.33,D0,40)
40.01 IS THIS A GROUP POLICY? 40;1 FileMan read/write
40.02 *GROUP NAME 40;2 FileMan read/write
Note: IB*2*497 - replaced by field 90.01
40.03 *GROUP NUMBER 40;3 FileMan read/write
Note: IB*2*497 - replaced by field 90.02
40.04 UTILITZATION REVIEW REQUIRED 40;4 FileMan read/write
40.05 PRECERTIFICATION REQUIRED 40;5 FileMan read/write
40.06 AMBULATORY CARE CERTIFICATION 40;6 FileMan read/write
40.07 EXCLUDE PREEXISTING CONDITION 40;7 FileMan read/write
40.08 BENEFITS ASSIGNABLE 40;8 FileMan read/write
40.09 TYPE OF PLAN 40;9 FileMan read/write
40.1 BANKING IDENTIFICATION NUMBER 40;10 FileMan read/write
40.11 PROCESSOR CONTROL NUMBER (PCN) 40;11 FileMan read/write
^IBA(355.33,D0,60)
60.01 PATIENT NAME 60;1 FileMan read/write
60.02 EFFECTIVE DATE 60;2 FileMan read/write
60.03 EXPIRATION DATE 60;3 FileMan read/write
60.04 *SUBSCRIBER ID 60;4 FileMan read/write
Note: IB*2*497 - replaced by field 90.03
60.05 WHOSE INSURANCE 60;5 FileMan read/write
60.06 PT. RELATIONSHIP TO INSURED 60;6 FileMan read/write
60.07 *NAME OF INSURED 60;7 FileMan read/write
Note: IB*2*497 - replaced by field 91.01
60.08 INSURED'S DOB 60;8 FileMan read/write
60.09 INSURED'S SSN 60;9 FileMan read/write
60.1 PRIMARY CARE PROVIDER 60;10 FileMan read/write
60.11 PRIMARY PROVIDER PHONE 60;11 FileMan read/write
60.12 COORDINATION OF BENEFITS 60;12 FileMan read/write
60.13 INSURED'S SEX 60;13 FileMan read/write
60.14 PT. RELATIONSHIP - HIPAA 60;14 FileMan read/write
^IBA(355.33,D0,61)
61.01 ESGHP? 61;1 FileMan read/write
61.02 SPONSORING EMPLOYER NAME 61;2 FileMan read/write
61.03 EMPLOYMENT STATUS 61;3 FileMan read/write
61.04 RETIREMENT DATE 61;4 FileMan read/write
61.05 SEND BILL TO EMPLOYER 61;5 FileMan read/write
61.06 EMPLOYER CLAIMS STREET LINE 1 61;6 FileMan read/write
61.07 EMPLOYER CLAIMS STREET LINE 2 61;7 FileMan read/write
61.08 EMPLOYER CLAIMS STREET LINE 3 61;8 FileMan read/write
61.09 EMPLOYER CLAIMS CITY 61;9 FileMan read/write
61.1 EMPLOYER CLAIMS STATE 61;10 FileMan read/write
61.11 EMPLOYER CLAIMS ZIP CODE 61;11 FileMan read/write
61.12 EMPLOYER CLAIMS PHONE NUMBER 61;12 FileMan read/write
^IBA(355.33,D0,62)
62.01 PATIENT ID 62;1 FileMan read/write
^IBA(355.33,D0,90)
90.01 GROUP NAME 90;1 FileMan read/write
90.02 GROUP NUMBER 90;2 FileMan read/write
90.03 SUBSCRIBER ID 90;3 FileMan read/write
^IBA(355.33,D0,91)
91.01 NAME OF INSURED 91;1 FileMan read/write\n\n
"C" cross reference (Patient) Direct Global read
"AEST" cross reference (Status) Direct Global read by
Date Entered "E" entries", "", "", "2014/02/21"], ["5295", "DSIV PATIENT ACCESS", "File", "REGISTRATION", "2008/11/23", "", "Withdrawn", "Private", "2", "
DSIV requests access to file 2 PATIENT file to do the
following for its Insurance Capture Buffer (ICB) application:\n
^DPT(D0,ENR)
27.02 PREFERRED FACILITY ENR;2 Fileman read
returned to gui with
buffer data", "", "", ""], ["5296", "BILLING PATIENT ACCESS", "File", "INTEGRATED BILLING", "2008/11/23", "APPROVED", "Active", "Private", "354", "
DSIV requests access to file 354 BILLING PATIENT to do
the following for its Insurance Capture Buffer (ICB) application:\n
^IBA(354,DO) Direct global read ($D), lock/unlock
^IBA(354,D0,0)
.01 PATIENT NAME 0;1 Filman read/write
.01 PATIENT NAME 0;1 Laygo new entry
^IBA(354,D0,60)
60 NO COVERAGE VERIFICATION DATE 60;1 Fileman read/write", "", "", "2009/06/11"], ["5297", "IIV RESPONSE ACCESS", "File", "INTEGRATED BILLING", "2008/11/24", "APPROVED", "Active", "Private", "365", "
DSIV requests access to all fields in file #365 IIV
RESPONSE to run an EIV Report for its Insurance Capture Buffer (ICB)
application.", "", "", "2009/06/11"], ["5298", "CLAIMS TRK REVIEW TYPE ACCESS", "File", "INTEGRATED BILLING", "2008/11/24", "APPROVED", "Active", "Private", "356.11", "
The DSIV package is requesting FileMan read access to
file #356.11 CLAIMS TRACKING REVIEW TYPE for the Insurance Capture Buffer
application in order to list the review types for user selection in the
insurance review add/edit.\n
^IBE(356.11,D0,0)
.01 NAME 0;1 Read w/FileMan
.02 CODE 0;2 Read w/FileMan", "", "", "2009/06/11"], ["5299", "CLAIMS TRACKING ACTION ACCESS", "File", "INTEGRATED BILLING", "2008/11/24", "APPROVED", "Active", "Private", "356.7", "
The DSIV package is requesting FileMan read access to
file #356.7 CLAIMS TRACKING ACTION for the Insurance Capture Buffer
application in order to list the actions for user selection in the insurance
review add/edit.\n
^IBE(356.7,D0,0)
.01 NAME 0;1 Read w/FileMan", "", "", "2009/06/11"], ["5300", "FBCS FILE 424", "File", "IFCAP", "2009/03/12", "", "Retired", "Controlled Subscription", "424", "
The Fee Basis Claims system accesses the 1358 DAILY
RECORD (#424) file in order to look up entries using either the Interface ID
cross-reference or the B cross reference.\n
^PRC(424,"B") Used for IEN lookups
^PRC(424,"E") Used for Interface ID lookups
^PRC(424,"AD") Used to check for existence of the Authorization IEN", "", "", ""], ["5301", "FBCS FILE 420", "File", "IFCAP", "2009/03/12", "", "Retired", "Controlled Subscription", "420", "
The Fee Basis Claims system accesses the FUND CONTROL
POINT. It uses this access to validate FCP/Site combinations for users.
$D(^PRC(420,FBSTA,1,+FBFCP,1,DUZ,0))
^PRC(420,SITE,1,"B",FBFCP)
$D(^PRC(420,"A",DUZ,SITE,+FBFCP))
$P(^PRC(420,FBSTA,1,+FBFCP,1,DUZ,0),U,2)
$O(^PRC(420,"B") added with DSIF*3.2*1 (to obtain all station
numbers for a user)", "", "", ""], ["5302", "FBCS FILE 43.4", "File", "REGISTRATION", "2009/03/12", "", "Retired", "Controlled Subscription", "43.4", "
The Fee Basis Claims system accesses the VA ADMITTING
REGULATION (#43.4) file as part of validity checks in the application.\n
^DIC(43.4,D0,0)
.01 NAME 0;1 Fileman r,Global r ($D check)
2 CFR # 0;3 Fileman r
4 ACTIVE 0;4 Fileman r
5 NURSING HOME 0;5 Fileman r
6 EDR CODE 0;6 Fileman r", "", "", ""], ["5303", "DSIV INTEGRATED BILLING ACTION", "File", "INTEGRATED BILLING", "2008/11/24", "", "Withdrawn", "Private", "350", "
The DSIV package is requesting access to file #350
INTEGRATED BILLING ACTION for its Insurance Capture Buffer (ICB) application
to search for all charges on hold due to insurance for a specific patient then
update the On Hold Date to the current date, or send to the billing software
to release the charges depending on the incoming flag.\n
^IB("AH" patient charges hold x-ref Direct Global read\n
^IB(D0,0)
.05 STATUS 0;5 Direct Global read
^IB(D0,1)
16 ON HOLD DATE 1;6 Direct Global read, Fileman w", "", "", ""], ["5304", "PATIENT INSURANCE ACCESS", "File", "INTEGRATED BILLING", "2008/11/24", "APPROVED", "Active", "Private", "2", "
The DSIV package is requesting FileMan read access to
the Insurance Type data in file #2 PATIENT for the Insurance Capture Buffer
application in order to display insurance information to the user.\n
IB*2*497 increased the length of the SUBSCRIBER ID field and the NAME OF
INSURED field to support the EDI New Standards and Operating Rules for VHA
providers. This required length increase made it necessary to move the
location of these 2 fields to new Data Dictionary nodes in the INSURANCE TYPE
sub-file. To support this implementation, all subscribers to this ICR will
need to make the necessary changes in their applications to reference the new
fields and remove the references to the old fields. When all subscribers have
implemented the use of the new fields, the old fields will be deleted with a
IB*2*518. Old and new fields are noted in the field list detail of this ICR.\n
Update: IB*2*528 increased the length of the COMMENT-PATIENT POLICY field
(2.312, 1.08) from 80 characters to 250 characters; and therefore it was
necessary to move this field to a new subscript in the INSURANCE TYPE sub-file
(2.312). All subscribers to this ICR will need to make the necessary changes
in their applications to reference the new field. Old and new fields are
noted in the INSURANCE TYPE multiple details below.\n\n
^DPT(D0,.31)
.3192 COVERED BY HEALTH INSURANCE? .31;11 Fileman read/write
insurance verification
INSURANCE TYPE MULTIPLE access:
^DPT(D0,.312,D1,0)
.01 INSURANCE TYPE 0;1 Read w/FileMan
1 *SUBSCRIBER ID 0;2 Read w/FileMan
Note: IB*2*497 - Replaced by field 7.02
2 *GROUP NUMBER 0;3 Read w/FileMan
3 INSURANCE EXPIRATION DATE 0;4 Read w/FileMan
6 WHOSE INSURANCE 0;6 Read w/FileMan
8 EFFECTIVE DATE OF POLICY 0;8 Read w/FileMan
15 *GROUP NAME 0;15 Read w/FileMan
16 PT. RELATIONSHIP TO INSURED 0;16 Read w/FileMan
17 *NAME OF INSURED 0;17 Read w/FileMan
Note: IB*2*497 - Replaced by field 7.01
.18 GROUP PLAN 0;18 Read w/FileMan
.2 COORDINATION OF BENEFITS 0;20 Read w/FileMan
^DPT(D0,.312,D1,1)
1.01 DATE ENTERED 1;1 Read w/FileMan
1.02 ENTERED BY 1;2 Read w/FileMan
1.03 DATE LAST VERIFIED 1;3 Read w/FileMan
1.04 VERIFIED BY 1;4 Read w/FileMan
1.05 DATE LAST EDITED 1;5 Read w/FileMan
1.06 LAST EDITED BY 1;6 Read w/FileMan
1.08 *COMMENT - PATIENT POLICY 1;8 Read w/FileMan
Note: IB*2*528 - 1.08 replaced by COMMENT-SUBSCRIBER POLICY multiple
1.09 SOURCE OF INFORMATION 1;9 Read w/FileMan
1.1 DATE OF SOURCE OF INFORMATION 1;10 Read w/FileMan
^DPT(D0,.312,D1,2)
2.01 SEND BILL TO EMPLOYER 2;1 Read w/FileMan
2.02 EMPLOYER CLAIMS STREET ADDRESS 2;2 Read w/FileMan
2.03 EMPLOY CLAIM ST ADDRESS LINE 2 2;3 Read w/FileMan
2.04 EMPLOY CLAIM ST ADDRESS LINE 3 2;4 Read w/FileMan
2.05 EMPLOYER CLAIMS CITY 2;5 Read w/FileMan
2.06 EMPLOYER CLAIMS STATE 2;6 Read w/FileMan
2.07 EMPLOYER CLAIMS ZIP CODE 2;7 Read w/FileMan
2.08 EMPLOYER CLAIMS PHONE 2;8 Read w/FileMan
2.015 SUBSCRIBER'S EMPLOYER NAME 2;9 Read w/FileMan
2.1 ESGHP 2;10 Read w/FileMan
2.11 EMPLOYMENT STATUS 2;11 Read w/FileMan
2.12 RETIREMENT DATE 2;12 Read w/FileMan
^DPT(D0,.312,D1,3)
3.01 INSURED'S DOB 3;1 Read w/FileMan
3.02 INSURED'S BRANCH 3;2 Read w/FileMan
3.03 INSURED'S RANK 3;3 Read w/FileMan
3.04 POLICY NOT BILLABLE 3;4 Read w/FileMan
3.05 INSURED'S SSN 3;5 Read w/FileMan
3.06 INSURED'S STREET 1 3;6 Read w/FileMan
3.07 INSURED'S STREET 2 3;7 Read w/FileMan
3.08 INSURED'S CITY 3;8 Read w/FileMan
3.09 INSURED'S STATE 3;9 Read w/FileMan
3.1 INSURED'S ZIP 3;10 Read w/FileMan
3.11 INSURED'S PHONE 3;11 Read w/FileMan
3.12 INSURED'S SEX 3;12 Read w/FileMan
^DPT(D0,.312,D1,4)
4.01 PRIMARY CARE PROVIDER 4;1 Read w/FileMan
4.02 PRIMARY PROVIDER PHONE 4;2 Read w/FileMan
4.03 PT. RELATIONSHIP - HIPAA 4;3 Read w/FileMan
^DPT(D0,.312,D1,5)
5.01 PATIENT ID 5;1 Read w/FileMan
5.02 SUBSCRIBER'S SEC QUALIFIER(1) 5;2 Read w/FileMan
5.03 SUBSCRIBER'S SEC ID(1) 5;3 Read w/FileMan
5.04 SUBSCRIBER'S SEC QUALIFIER(2) 5;4 Read w/FileMan
5.05 SUBSCRIBER'S SEC ID(2) 5;5 Read w/FileMan
5.06 SUBSCRIBER'S SEC QUALIFIER(3) 5;6 Read w/FileMan
5.07 SUBSCRIBER'S SEC ID(3) 5;7 Read w/FileMan
5.08 PATIENT'S SEC QUALIFIER(1) 5;8 Read w/FileMan
5.09 PATIENT'S SECONDARY ID(1) 5;9 Read w/FileMan
5.1 PATIENT'S SEC QUALIFIER(2) 5;10 Read w/FileMan
5.11 PATIENT'S SECONDARY ID(2) 5;11 Read w/FileMan
5.12 PATIENT'S SEC QUALIFIER(3) 5;12 Read w/FileMan
5.13 PATIENT'S SECONDARY ID(3) 5;13 Read w/FileMan
^DPT(D0,.312,D1,7)
7.01 NAME OF INSURED 7;1 Read w/FileMan
7.02 SUBSCRIBER ID 7;2 Read w/FileMan
^DPT(D0,.312,D1,13,D2,0)
.01 COMMENT DATE 0;1 Read w/FileMan
.02 LAST EDITED 0;2 Read w/FileMan
^DPT(D0,.312,D1,13,D2,1)
.03 COMMENT 1;1 Read w/FileMan\n\n\n\n\n", "", "", "2017/07/24"], ["5305", "SOURCE OF INFORMATION ACCESS", "File", "INTEGRATED BILLING", "2008/11/24", "APPROVED", "Active", "Private", "355.12", "
The DSIV package is requesting FileMan read access to
file #355.12 SOURCE OF INFORMATION for the Insurance Capture Buffer
application in order to list the sources for user selection when creating a
buffer entry.\n
^IBE(355.12,D0,0)
.01 CODE 0;1 Read w/FileMan
.02 DESCRIPTION 0;2 Read w/FileMan", "", "", "2009/06/11"], ["5306", "PSJBLDOC", "Routine", "INPATIENT MEDICATIONS", "2008/12/08", "APPROVED", "Active", "Private", "", "
This entry point builds the drug information for
patient's orders entered in the Inpatient Medications package. The data
returned is used in First Data Bank order checks.", "", "PSJBLDOC", "2014/07/15"], ["5307", "DSIV CALLS TO IBCNBLL", "Routine", "INTEGRATED BILLING", "2008/12/10", "APPROVED", "Active", "Private", "", "
The Insurance Capture Buffer (ICB) application uses the
following APIs in IBCNBLL to determine if there are bills on hold for a
patient and to get the Symbol for the buffer entry. The symbol is displayed
in the application and will also denote if the buffer entry has been manually
verified.", "", "IBCNBLL", "2009/06/11"], ["5308", "LAB SERVICES TO #2817", "Other", "LAB SERVICE", "2008/12/10", "", "Pending", "Private", "", "", "", "", ""], ["5309", "DSIV CALL TO IBCNERP2", "Routine", "INTEGRATED BILLING", "2008/12/10", "APPROVED", "Active", "Private", "", "
The Insurance Capture Buffer (ICB) application uses the
X12 API in IBCNERP2 to convert the X12 code to a readable format for a report.\n", "", "IBCNERP2", "2009/06/11"], ["5310", "FBCS ACCESS TO DGRPU", "Routine", "REGISTRATION", "2009/03/12", "", "Withdrawn", "Controlled Subscription", "", "
These components are used by the FBCS application to
format the patient address data.", "", "DGRPU", ""], ["5311", "FBCS ACCESS TO DGSDUTL", "Routine", "REGISTRATION", "2009/03/12", "", "Withdrawn", "Private", "", "
These components are used by the FBCS application for
patient demographic inquiries.", "", "DGSDUTL", ""], ["5312", "PLAN LIMITATION CATEGORY ACCESS", "File", "INTEGRATED BILLING", "2008/12/10", "APPROVED", "Active", "Private", "355.31", "
The DSIV package is requesting FileMan read access to
file #355.31 PLAN LIMITATION CATEGORY for the Insurance Capture Buffer
application in order to perform coverage limitation add/edits.\n
^IBE(355.31,D0,0)
.01 NAME 0;1 Read w/FileMan", "", "", "2009/06/11"], ["5313", "CLAIMS TRACKING ACCESS", "File", "INTEGRATED BILLING", "2008/12/10", "APPROVED", "Active", "Private", "356", "
The DSIV package is requesting FileMan read access to
file #356 CLAIMS TRACKING for the Insurance Capture Buffer application in
order to look up and display a Claims Tracking record to be associated with an
Insurance Review.\n
^IBT(356,D0,0)
.01 ENTRY ID 0;1 Read w/FileMan
.03 VISIT 0;3 Read w/FileMan
.04 OUTPATIENT ENCOUNTER 0;4 Read w/FileMan
.05 ADMISSION 0;5 Read w/FileMan
.06 EPISODE DATE 0;6 Read w/FileMan
.07 ADMISSION TYPE 0;7 Read w/FileMan
.18 EVENT TYPE 0;18 Read w/FileMan
.2 INACTIVE 0;20 Read w/FileMan
.31 SPECIAL CONSENT ROI 0;31 Read w/FileMan", "", "", "2009/06/11"], ["5314", "HOSPITAL TRACKING ACCESS", "File", "INTEGRATED BILLING", "2008/12/10", "APPROVED", "Active", "Private", "356.1", "
The DSIV package is requesting FileMan read access to
file #356.1 HOSPITAL TRACKING for the Insurance Capture Buffer application in
order to look up and display a Hospital Tracking record to be associated with
an Insurance Review as a Related Review.\n
^IBT(356.1,D0,0)
.01 REVIEW DATE 0;1 Read w/FileMan
.02 TRACKING ID 0;2 Read w/FileMan
.07 SPECIALTY FOR REVIEW 0;7 Read w/FileMan
.19 ACTIVE 0;19 Read w/FileMan
.2 NEXT REVIEW DATE 0;20 Read w/FileMan
.21 REVIEW STATUS 0;21 Read w/FileMan", "", "", "2009/06/11"], ["5315", "ORQQCN GET CONSULT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2008/12/12", "APPROVED", "Active", "Controlled Subscription", "", "
This rpc is used to get consult and associated TIU
records using a Consult ID from File 123 as input.\n
Output results are: RESULTS[0] = ^GMR(123 zero node
RESULTS[i..j] = TIU records", "ORQQCN GET CONSULT", "GETCSLT ORQQCN1", "2009/06/11"], ["5316", "TIU SET ADMINISTRATIVE CLOSURE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2008/12/12", "APPROVED", "Active", "Controlled Subscription", "", "
This remote procedure sets the file attributes
necessary to close a document by administrative action (either manually or by
scanning a paper document that doesn't require the signature of an author as a
typical TIU Document would).\n
Input params: TIUDA IEN of document in 8925
MODE alphabetic code for manner closed:
"S" for Scanned (default)
"M" for Manual.
PERSON User who closed the document (default=DUZ)\n
Output: Success = IEN of document or 0^message", "TIU SET ADMINISTRATIVE CLOSURE", "ADMNCLO TIUSRVPT", "2009/06/11"], ["5317", "DSICDUZ", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/23", "APPROVED", "Active", "Controlled Subscription", "", "\n
This ICR records API's in the DSICDUZ routine. This routine is used by DSS
applications for NEW PERSON (#200) file accesses. The routine is a wrapper
around Standard FILEMAN calls to derive results.\n
Associated RPCs: DSIC ACTIVE USER, DSIC USER DEF DIV,
DSIC USER ID, DSIC ACTIVE USER LIST,
DSIC ACTIVE PERSON CLASS, DSIC ACTIVE CPRS PROVIDER\n\n\n
ROUTINE: DSICDUZ
COMPONENT: ACT
VARIABLES: DSIC Type: Output
A subscripted array with a value of 1
or 0 to indicated if user is active.\n
XDUZ Type: Input (Required)
A single value or a subscripted array
of security keys to be evaluated.
DSISCR Type: Input (Optional)
DSISCR(n) = string
where n = 0,1,2,3,4,...
Allowable formats of DSISCR(n) =
flag^val1^val2^val3^..\n
security key ck = KEY^security key
name
kernel param ck = PARM^parameter
name^ parameter instance
M code = M^<return message>^
<executable M code which
sets $T>\n
FUN Type: Input (Optional) Default is zero (0).
I $G(FUN) then extrinsic function,
else RPC.\n
This API is used by the "DSIC USER ACTIVE USER" rpc.
This API can be used to verify if a user is an active
VistA user.
The calling routine will send the DUZ to check and the
API will return a subscripted array with a value of 1
(user owns key) or 0 (key not found).\n
COMPONENT: CK
VARIABLES: XDUZ Type: Input (Required)
A single DUZ value to check.\n\n\n
This API does a basic check on a DUZ to see if user is active.\n
COMPONENT: DIV
VARIABLES: DSIC Type: Output
return p1^p2^p3:\n
p1=pointer to file 4
p2=institution name
p3=station number\n
XDUZ Type: Input (Required) default is currect user
DUZ.
A single value or a subscripted array
of security keys to be evaluated.
SITE Type: Input (Optional)
if SITE=1 and user has no divisions,
then return facility's default
division\n
FUN Type: Input (Optional) Default is zero (0).
I $G(FUN) then extrinsic function,
else RPC.\n
Return default division for user. If that user has
only one division in the file 200 DIVISION multiple,
then that entry is assumed to be the default division
unless it is explicitly marked as NO. This component is
used for the "DSIC USER DEF DIV" rpc.\n
COMPONENT: ID
VARIABLES: DSIC Type: Output
return p1^p2^p3^p4 for n=1,2,3,...
where
If error, return -1^message
If RPC or M API,
return List[n] = p1^p2^p3^p4
for n=1,2,3,4,...
If Ext. Function,
return
p1^p2^p3^p4;p1^p2^p3^p4;p1^p2^p3^p4;...
where p1 - ID mnemonic
p2 - ID value
p3 - location
(valid for OAI mnemonics
only)
p4 = 1 (valid for OAI only.)
(If 1, then default
Alt ID)\n
XDUZ Type: Input pointer to NEW PERSON file,
if optional default to DUZ\n
FLAGS Type: Input (Optional)
default to "AaDNSTVv"
FLAGS["A" - return alternate IDS in
field 21600 only
"a" - return default alternate
ID only
- either one must be
flagged as default or if
there is only one entry
in alt id.
"D" - return DEA#
"N" - return NPI#
"S" - return SSN
"T" - TAX ID
"v" - VA#
"V" - VPID\n
FUN Type: Input (Optional) Default is zero (0).
I $G(FUN) then extrinsic function,
else RPC.\n
Return all user IDs for a given user. This component
is used for the "DSIC USER ID" rpc.\n
COMPONENT: LIST
VARIABLES: DSIC Type: Output
Return ^TMP("DSIC",$J,"DILIST",#,0) = p1^p2^p3^...^p8
where:
p1 = ien p6 = initials
p2 = name (.01 field) p7 = title
p3 = sig block printed name p8 = service
p4 = sig block title p9 = division
p5 = first m last\n
VAL Type: Input (Required)
lookup value for NEW PERSON file.\n
SCR Type: Input (Optional)
array of additional screens to
perform:\n
string where n = 0,1,2,3,4,...
Allowable formats of SCR(n) =
flag^val1^val2^val3^..
security key ck = KEY^security key
name
kernel param ck = PARM^parameter
name^ parameter instance
M code = M^<return message>^
<executable M code which sets $T>\n
Return list of active users for a lookup value. This
component is used for the "DSIC ACTIVE USER LIST" rpc.\n\n\n
COMPONENT: PER
VARIABLES: DSIC Type: Output\n
Return user's current active person classification for
PCE.
Return p1^p2^p3^...^p8 where
p1 = IEN to file 8932.1 p5 = Effective date
p2 = Occupation p6 = expiration date
p3 = specialty p7 = VA Code
p4 = sub-specialty p8 = specialty code\n
USER Type: Input pointer to NEW PERSON file,
if optional default to DUZ.\n
DATE Type: Input ; DATE - default=today
Fileman date to check for
active person class.\n
FUN Type: Input (Optional) Default is zero (0).
I $G(FUN) then extrinsic function,
else RPC.\n
Return user's current active person classification for
PCE. This component is used for the "DSIC ACTIVE PERSON
CLASS" rpc.\n\n
COMPONENT: PROV
VARIABLES: DSIC Type: Output\n
Return: 3 if active user
2 if user is active via the XUORES security key
1 if user is a RDV visitor and you passed RDV=1
0 if user is a RDV visitor and you passed RDV=0
-1^message if problems or not a provider\n
XDUZ Type: Input (Required) default is current user DUZ.\n
A single value of the DUZ to return values for.\n\n
RDV Type: Input (Optional) default = today
Boolean flag to indicate whether or not to
include remote data view visitors - default to 0
to not include.\n
FUN Type: Input (Optional) Default is zero (0).
I $G(FUN) then extrinsic function, else RPC.\n
Return all user IDs for a given user. This component
is used for the "DSIC ACTIVE CPRS PROVIDER" rpc.", "", "DSICDUZ", "2009/06/11"], ["5318", "DSICDDR0", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/23", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR records APIs in the DSICDDR0 routine. This
routine is used by DSS applications for FILEMAN type file accesses. The
routine is a wrapper around Standard FILEMAN calls to derive results.", "", "DSICDDR0", "2009/06/11"], ["5319", "DSICFM05", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/23", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR records API's in the DSICFM05 routine. This
routine is used by DSS applications for FILEMAN type file accesses using the
LIST^DIC DBS call.\n
Associated RPCs: DSIC FM FIND, DSIC FM LIST.", "", "DSICFM05", "2009/06/11"], ["5320", "DSICXQA", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/23", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR records API's in the DSICXQA routine. This
routine is used by DSS applications for NEW PERSON (#200) file accesses. The
routine is a wrapper around Standard FILEMAN calls to Send Alerts to VistA
packages.", "", "DSICXQA", "2009/06/11"], ["5321", "DSICXM", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/23", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR records API's in the DSICXM routine. This
routine is used by DSS applications for SENDING MAILMAN mail messages. The
routine is a wrapper around Standard kernel calls to send messages to VistA
packages.", "", "DSICXM", "2009/06/11"], ["5322", "DSICXPR", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/23", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR records API's in the DSICXPR routine. This
routine is used by DSS applications for modifications to KERNEL System
Parameters. The routine uses standard FILEMAN and KERNEL calls to derive
results. KERNEL XPAR APIs (Supported ICR #2263) are wrapped by this routine.", "", "DSICXPR", "2025/05/13"], ["5323", "DSICXPDU", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/23", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR records API's in the DSICXPDU routine. This
routine is used by DSS applications for retrieving data from the INSTALL
(#9.7) file. The routine is a wrapper around Standard FILEMAN and KERNEL calls
to get dates and other information concerning KIDS installs.", "", "DSICXPDU", "2009/06/11"], ["5324", "DSICFM04", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/24", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR records API's in the DSICFM04 routine. This
invokes the Fileman filer to update fields for an existing entry. This will
allow you to update any field at the level of the FILE including word
processing fields. It does not allow for updating different levels of the
file. If you wish to update a subfile, then you will have to make multiple
calls to this RPC for each file or subfile.", "", "DSICFM04", "2009/06/11"], ["5325", "DSICFM01", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/24", "APPROVED", "Active", "Controlled Subscription", "", "
This contains common Fileman utilities.", "", "DSICFM01", "2009/06/11"], ["5326", "DSICHFS", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2008/12/24", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains various entry points for handling
HFS files. It can accomodate calling a VistA option that expects to write to a
printer or device.", "", "DSICHFS", "2009/06/11"], ["5327", "FBCS call to FBAAUTL1", "Routine", "FEE BASIS", "2008/12/31", "", "Retired", "Private", "", "", "", "FBAAUTL1", "2009/06/11"], ["5328", "FBCS Access to FBCH78", "Routine", "FEE BASIS", "2008/12/31", "", "Retired", "Controlled Subscription", "", "", "", "FBCH78", "2009/06/11"], ["5329", "FBCS Access to FBCHACT0", "Routine", "FEE BASIS", "2008/12/31", "", "Retired", "Controlled Subscription", "", "", "", "FBCHACT0", "2009/06/11"], ["5330", "FBCS ACCESS TO PRCSUT", "Routine", "IFCAP", "2008/12/31", "", "Retired", "Controlled Subscription", "", "", "", "PRCSUT", ""], ["5331", "FBCS ACCESS TO EASECU", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2008/12/31", "", "Withdrawn", "Controlled Subscription", "", "
We will need to clone this code into FBCS routine
DSIFNOT5 to send output to an array instead of a screen display.", "", "EASECU", ""], ["5332", "ORDER CHECK INSTANCES FILE - PHARMACY FIELDS", "File", "ORDER ENTRY/RESULTS REPORTING", "2009/01/07", "APPROVED", "Active", "Controlled Subscription", "100.05", "
This integration agreement allows subscribing packages
to read and write to those fields specific to medication orders.", "", "", "2009/01/12"], ["5333", "PROVIDER AND PHARMACIST OVER RIDE COMMENTS UTILITY", "Routine", "INPATIENT MEDICATIONS", "2009/01/08", "APPROVED", "Active", "Controlled Subscription", "", "
Utilities for printing Provider and Pharmacist Over
Ride Comments and updating Pharmacist Over Ride Comments.", "", "PSGSICH1", "2009/02/06"], ["5334", "FBCS ACCESS TO DGPM GLOBAL", "File", "REGISTRATION", "2009/01/11", "", "Withdrawn", "Controlled Subscription", "405", "
Access to Global nodes to check patient status and get
type of movement\n
I '$D(^DGPM("C",DFN)) Check if inpatient/lodger
I $D(^DGPM(+DGPMVI(17),0)) Check if Discharge movement exists\n
Also the following access:
^DGPM(D0,0)
.04 TYPE OF MOVEMENT 0;1 Global r", "", "", ""], ["5335", "ANNUAL MEANS TEST ACCESS", "File", "REGISTRATION", "2009/01/12", "", "Withdrawn", "Controlled Subscription", "408.31", "
The FBCS application accesses the ANNUAL MEANS TEST
(#408.31) file to get the current means test status information.\n
^DGMT(408.31,DGMTI,0)
.01 DATE OF TEST 0:1 Global r
.07 DATE/TIME COMPLETED 0:7 Global r
.11 AGREED TO PAY DEDUCT 0:11 Global r
.17 NO LONGER REQUIRED DATE 0:17 Global r
29 MEANS TEST SIGNED? 0:29 Global r
^DGMT(408.31,D0,2)
2.07 REASON FOR EXEMPTION 2;7 Global r", "", "", ""], ["5336", "FBCS ACCESS TO GLOBAL PRC(411", "File", "IFCAP", "2009/01/12", "", "Retired", "Controlled Subscription", "411", "
The Fee Basis Claims System accesses the .01 field of
the ADMIN. ACTIVITY SITE PARAMETER (#411) file in order to setup a new
obligation sequence number for a 7078.\n
^PRC(411,D0,0)
.01 STATION/SUBSTATION CODE 0;1 Global Read", "", "", ""], ["5337", "MEANS TEST STATUS ACCESS", "File", "REGISTRATION", "2009/01/12", "", "Withdrawn", "Controlled Subscription", "408.32", "
The FBCS application accesses the ANNUAL MEANS STATUS
(#408.32) file to get the message associated with the test status.\n
^DG(408.32,D0,MSG)
100 MESSAGE MSG:1 Global read", "", "", ""], ["5338", "MAS PARAMETERS ACCESS", "File", "REGISTRATION", "2009/01/12", "", "Withdrawn", "Controlled Subscription", "43", "
The FBCS application accesses the MAS PARAMETERS (#43)
file to determine whether to display the abbreviated or detailed patient
inquiry.\n
^DG(43,D0,0)
38 ABBREVIATED PATIENT INQUIRY 0:38 Global read", "", "", ""], ["5339", "ANNUAL BENEFITS ACCESS", "File", "INTEGRATED BILLING", "2009/01/12", "APPROVED", "Active", "Private", "355.4", "\n
The DSIV package is requesting FileMan read/write access to file #355.4
ANNUAL BENEFITS for the Insurance Capture Buffer application in order to add
and edit entries.\n
^IBA(355.4,D0,0)
.01 BENEFIT YEAR BEGINNING ON 0;1 FileMan read/write
.01 BENEFIT YEAR BEGINNING ON 0;1 Laygo new entry into file
.02 HEALTH INSURANCE POLICY 0;2 FileMan read/write
.05 MAX. OUT OF POCKET 0;5 FileMan read/write
.06 AMBULANCE COVERAGE (%) 0;6 FileMan read/write
^IBA(355.4,D0,1)
1.01 DATE ENTERED 1;1 FileMan read/write
1.02 ENTERED BY 1;2 FileMan read/write
1.03 DATE LAST VERIFIED 1;3 FileMan read
1.04 VERIFIED BY 1;4 FileMan read
1.05 DATE LAST EDITED 1;5 FileMan read
1.06 LAST EDIT BY 1;6 FileMan read
1.07 PERSON CONTACTED 1;7 FileMan read/write
1.08 COMMENTS 1;8 FileMan read/write
1.09 CONTACT'S PHONE NUMBER 1;9 FileMan read/write
^IBA(355.4,D0,2)
2.01 ANNUAL DEDUCTIBLE (OPT) 2;1 FileMan read/write
2.02 PER VISIT DEDUCTIBLE 2;2 FileMan read/write
2.03 OUTPATIENT LIFETIME MAXIMUM 2;3 FileMan read/write
2.04 OUTPATIENT ANNUAL MAXIMUM 2;4 FileMan read/write
2.05 MH LIFETIME OUTPATIENT MAX. 2;5 FileMan read/write
2.06 MH ANNUAL OUTPATIENT MAX. 2;6 FileMan read/write
2.07 DENTAL COVERAGE TYPE 2;7 FileMan read/write
2.08 DENTAL COVERAGE $ OR % 2;8 FileMan read/write
2.09 OUTPATIENT VISIT (%) 2;9 FileMan read/write
2.1 EMERGENCY OUTPATIENT (%) 2;10 FileMan read/write
2.11 MENTAL HEALTH OUTPATIENT (%) 2;11 FileMan read/write
2.12 PRESCRIPTION (%) 2;12 FileMan read/write
2.13 OUTPATIENT SURGERY (%) 2;13 FileMan read/write
2.14 MH OPT. MAX DAYS PER YEAR 2;14 FileMan read/write
2.15 OUTPATIENT VISITS PER YEAR 2;15 FileMan read/write
2.17 ADULT DAY HEALTH CARE 2;17 FileMan read/write
^IBA(355.4,D0,3)
3.01 HOME HEALTH CARE LEVEL 3;1 FileMan read/write
3.02 HOME HEALTH VISITS PER YEAR 3;2 FileMan read/write
3.03 HOME HEALTH MAX DAYS PER YEAR 3;3 FileMan read/write
3.04 HOME HEALTH MED. EQUIPMENT (%) 3;4 FileMan read/write
3.05 HOME HEALTH VISIT DEFINITION 3;5 FileMan read/write
3.06 OCCUPATIONAL THERAPY # VISITS 3;6 FileMan read/write
3.07 PHYSICAL THERAPY # VISITS 3;7 FileMan read/write
3.08 SPEECH THERAPY # VISITS 3;8 FileMan read/write
3.09 MEDICATION COUNSELING # VISITS 3;9 FileMan read/write
^IBA(355.4,D0,4)
4.01 HOSPICE ANNUAL DEDUCTIBLE 4;1 FileMan read/write
4.02 HOSPICE INPATIENT ANNUAL MAX 4;2 FileMan read/write
4.03 HOSPICE INPT. LIFETIME MAX 4;3 FileMan read/write
4.04 ROOM AND BOARD (%) 4;4 FileMan read/write
4.05 OTHER INPATIENT CHARGES (%) 4;5 FileMan read/write
4.06 IV INFUSION OPT. 4;6 FileMan read/write
4.07 IV INFUSION INPT. 4;7 FileMan read/write
4.08 IV ANTIBIOTICS OPT. 4;8 FileMan read/write
4.09 IV ANTIBIOTICS INPT. 4;9 FileMan read/write
^IBA(355.4,D0,5)
5.01 ANNUAL DEDUCTIBLE (INPATIENT) 5;1 FileMan read/write
5.02 PER ADMISSION DEDUCTIBLE 5;2 FileMan read/write
5.03 INPATIENT LIFETIME MAXIMUM 5;3 FileMan read/write
5.04 INPATIENT ANNUAL MAXIMUM 5;4 FileMan read/write
5.05 MH LIFETIME INPATIENT MAXIMUM 5;5 FileMan read/write
5.06 MH ANNUAL INPATIENT MAXIMUM 5;6 FileMan read/write
5.07 DRUG & ALCOHOL LIFETIME MAX 5;7 FileMan read/write
5.08 DRUG & ALCOHOL ANNUAL MAX 5;8 FileMan read/write
5.09 ROOM AND BOARD (%) (NJ3,0), 5;9 FileMan read/write
5.1 NURSING HOME (%) (NJ3,0), 5;10 FileMan read/write
5.11 MENTAL HEALTH INPATIENT (%) 5;11 FileMan read/write
5.12 OTHER INPATIENT CHARGES (%)) 5;12 FileMan read/write
5.14 MH INPT. MAX DAYS PER YEAR 5;14 FileMan read/write", "", "", "2009/06/11"], ["5340", "INSURANCE REVIEW ACCESS", "File", "INTEGRATED BILLING", "2009/01/12", "APPROVED", "Active", "Private", "356.2", "
The DSIV package is requesting FileMan read/write
access to file #356.2 INSURANCE REVIEW for the Insurance Capture Buffer
application in order to add and edit entries.\n
^IBT(356.2,D0,0)
.01 REVIEW DATE 0;1 FileMan read/write
.01 REVIEW DATE 0;1 Laygo new entry into file
.02 TRACKING ID 0;2 FileMan read/write
.03 RELATED REVIEW 0;3 FileMan read/write
.04 TYPE OF CONTACT 0;4 FileMan read/write
.05 PATIENT 0;5 FileMan read/write
.06 PERSON CONTACTED 0;6 FileMan read/write
.07 CONTACT PHONE # 0;7 FileMan read/write
.08 INSURANCE COMPANY CONTACTED 0;8 FileMan read/write
.1 APPEAL STATUS 0;10 FileMan read/write
.11 ACTION 0;11 FileMan read/write
.12 CARE AUTHORIZED FROM 0;12 FileMan read/write
.13 CARE AUTHORIZED TO 0;13 FileMan read/write
.14 DIAGNOSIS AUTHORIZED 0;14 FileMan read/write
.15 DATES OF DENIAL FROM 0;15 FileMan read/write
.16 DATES OF DENIAL TO 0;16 FileMan read/write
.17 METHOD OF CONTACT 0;17 FileMan read/write
.18 PARENT REVIEW 0;18 FileMan read/write
.19 REVIEW STATUS 0;19 FileMan read/write
.2 CASE PENDING 0;20 FileMan read/write
.21 NO COVERAGE 0;21 FileMan read/write
.22 FOLLOW-UP WITH APPEAL 0;22 FileMan read/write
.23 TYPE OF APPEAL 0;23 FileMan read/write
.24 NEXT REVIEW DATE 0;24 FileMan read/write
.25 NUMBER OF DAYS PENDING APPEAL 0;25 FileMan read/write
.26 OUTPATIENT TREATMENT 0;26 FileMan read/write
.27 TREATMENT AUTHORIZED 0;27 FileMan read/write
.29 FINAL OUTCOME OF APPEAL 0;29 FileMan read/write
^IBT(356.2,D0,1)
1.01 DATE ENTERED 1;1 FileMan read/write
1.02 ENTERED BY 1;2 FileMan read/write
1.03 DATE LAST EDITED 1;3 FileMan read/write
1.04 LAST EDITED BY 1;4 FileMan read/write
1.05 HEALTH INSURANCE POLICY 1;5 FileMan read/write
1.07 DENY ENTIRE ADMISSION 1;7 FileMan read/write
1.08 AUTHORIZE ENTIRE ADMISSION 1;8 FileMan read/write
^IBT(356.2,D0,2)
2.01 CALL REFERENCE NUMBER 2;1 FileMan read/write
2.02 AUTHORIZATION NUMBER 2;2 FileMan read/write
^IBT(356.2,D0,11,D1,0)
.01 COMMENTS 0;1 FileMan read/write
^IBT(356.2,D0,12,D1,0)
.01 REASONS FOR DENIAL 0;1 FileMan read/write
^IBT(356.2,D0,13,D1,0)
.01 PENALTY 0;1 FileMan read/write
.02 AMOUNT OF PENALTY 0;2 FileMan read/write
^IBT(356.2,D0,14,D1,0)
.01 APPROVE ON APPEAL FROM 0;1 FileMan read/write
.02 APPROVE ON APPEAL TO 0;2 FileMan read/write", "", "", "2013/03/22"], ["5341", "PLAN COVERAGE LIMITATION", "File", "INTEGRATED BILLING", "2009/01/12", "APPROVED", "Active", "Private", "355.32", "
The DSIV package is requesting FileMan read/write
access to file #355.32 PLAN COVERAGE LIMITATION for the Insurance Capture
Buffer application in order to add and edit entries.\n
^IBA(355.32,D0,0)
.01 PLAN 0;1 FileMan read/write
.01 PLAN 0;1 Laygo new entry into file
.02 COVERAGE CATEGORY 0;2 FileMan read/write
.03 EFFECTIVE DATE 0;3 FileMan read/write
.04 COVERAGE STATUS 0;4 FileMan read/write
^IBA(355.32,D0,1)
1.03 DATE LAST EDITED 1;3 FileMan write
1.04 LAST EDITED BY 1;4 FileMan write
^IBA(355.32,D0,2,D1,0)
.01 LIMITATION COMMENT 0;1 FileMan read/write", "", "", "2009/06/11"], ["5342", "DSIV IVM FILE 301.91 ACCESS", "File", "INCOME VERIFICATION MATCH", "2009/01/12", "APPROVED", "Active", "Private", "301.91", "
The DSIV package is requesting FileMan read access to
file #301.91 IVM REASONS FOR NOT UPLOADING INSURANCE for the Insurance Capture
Buffer application in order to get the reasons for not uploading when
rejecting buffer entries that were initiated by IVM.\n
^IVM(301.91,D0,0)
.01 REASON CODE 0;1 FileMan read
.02 REASON DESCRIPTION 0;2 FileMan read", "", "", "2009/06/09"], ["5343", "ACCESSION DIV", "File", "LAB SERVICE", "2009/01/14", "", "Pending", "Controlled Subscription", "68", "
The ONCOLOGY package needs to directly access (read
only) the following field:\n
DIV sub-field (#26) within the ACCESSION NUMBER multiple (#1) within the DATE
multiple (#2) of the ACCESSION file (#68)\n
This will allow ONCOLOGY casefinding to determine the division value of a LAB
DATA (#63) record.\n", "", "", ""], ["5344", "GIVE THIS DBIA A BETTER NAME THAN DBIA5344", "", "", "2010/12/15", "", "Pending", "", "", "", "", "", ""], ["5345", "FBCS ACCESS TO GLOBAL DGS(41.41", "File", "REGISTRATION", "2009/01/14", "", "Withdrawn", "Controlled Subscription", "41.41", "", "", "", ""], ["5346", "FBCS ACCESS TO GLOBAL DIC(21", "File", "REGISTRATION", "2009/01/14", "", "Withdrawn", "Controlled Subscription", "21", "", "", "", ""], ["5347", "FBCS ACCESS TO PATIENT", "File", "REGISTRATION", "2009/01/14", "", "Retired", "Controlled Subscription", "2", "
FBCS needs access to the Eligibility Status date for
demographic display.\n
^DPT(D0,.361)
.3612 ELIGIBILITY STATUS DATE .361;2 Fileman read", "", "", ""], ["5348", "CPT COPYRIGHT", "File", "CPT/HCPCS CODES", "2009/03/16", "", "Retired", "Controlled Subscription", "81.2", "
Read access to file 81.2 get the CPT Copyright
information for a broker application. The following data is read:
^DIC(81.2,D0,1,0)
.01 SIGNON COPYRIGHT MESSAGE 0;1\n
This ICR will be retired upon release of patch ICPT*6.0*46.", "", "", ""], ["5349", "FBCS ACCESS TO GLOBAL SCTM(404.51", "File", "SCHEDULING", "2009/01/15", "", "Retired", "Controlled Subscription", "404.51", "
Use cloned logic from existing routine "SDPPTEM" to
print Primary care team information to an array for the GUI interface.", "", "", ""], ["5350", "MEDICAL PATIENT IEN", "File", "CLINICAL PROCEDURES", "2009/01/15", "", "Pending", "Private", "", "
In CPRS v27, incorrect patient information could be
displayed to the user. In Consults, when the incorrect patient information
was displayed, the user could attach a result note to the wrong patient's
record.\n
Therefore, an agreement with Clinical Procedures is needed to allow the
MEDICAL PATIENT IEN to be pulled from the Medicine files using $$GET1^DIQ
based upon the Medicine Results stored in REQUEST/CONSULTATION file #123. The
IEN value will be reported on a Consults report which finds all ASSOCIATED
RESULTS that are attached to the wrong patient.\n
This IA will be used one time for patch GMRC*3.0*70.\n
FILE# FIELD# NODE
------ ------- -----
690 MEDICAL PATIENT .01 NAME 0;1 Read w/Fileman\n
691 ECHO 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
691.1 CARDIAC CATHETERIZATION 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
691.5 ELECTROCARDIOGRAM (EKG) 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
691.6 HOLTER 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
691.7 EXERCISE TOLERANCE TEST 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
691.8 ELECTROPHYSIOLOGY (EP) 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
694 HEMATOLOGY 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
698 GENERATOR IMPLANT 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
698.1 V LEAD IMPLANT 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
698.2 A LEAD IMPLANT 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
698.3 PACEMAKER SURVEILLANCE 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
699 ENDOSCOPY/CONSULT .02 MEDICAL PATIENT 0;2 Read w/Fileman\n
699.5 GENERALIZED PROCEDURE/CONSULT
.02 MEDICAL PATIENT 0;2 Read w/Fileman\n
700 PULMONARY FUNCTION TESTS 1 MEDICAL PATIENT 0;2 Read w/Fileman\n
701 RHEUMATOLOGY 1 MEDICAL PATIENT 0;2 Read w/Fileman", "", "", ""], ["5351", "TIU STORE POINTER TO 8925", "File", "TEXT INTEGRATION UTILITIES", "2009/01/16", "APPROVED", "Active", "Private", "8925", "
This ICR documents the fact that DSIV has a field
called TIU DOCUMENT (field #.08) in the DSI VISTA IMAGING QUEUE TRACKING file
(#19621) that points to the TIU DOCUMENT file (#8925).\n
^TIU(8925,DA,0)
.01 DOCUMENT TYPE 0;1 Pointed to", "", "", "2009/06/11"], ["5352", "TIU GET TITLE IFN", "Routine", "TEXT INTEGRATION UTILITIES", "2009/01/26", "APPROVED", "Active", "Private", "", "\n
Lab use $$DDEFIEN^TIUFLF7 to find the Title IFN in
file 8925.1.\n
S LRTITLE=$$DDEFIEN^TIUFLF7("LR "_LRO68_" REPORT","TL") I 'LRTITLE D .W $C(7)
.S LRMSG="No TIU title for this lab report. Cannot release." .D
EN^DDIOL(LRMSG,"","!!") K LRMSG\n\n\n\n\n", "", "TIUFLF7", "2009/02/13"], ["5353", "Accept/Reject Insurance Buffer data APIs", "Routine", "INTEGRATED BILLING", "2009/01/27", "APPROVED", "Active", "Private", "", "
This ICR provides APIs for the IB Insurance Application
which will suppress the Write Statements and Interactive Fileman calls for the
existing ACCEPT^IBCNBAR and REJECT^IBCNBAR logic. It includes logic to update
the Patient Insurance Type (2.312) sub file with a new Group Insurance Plan
and Insurance Company.\n
There is also an API (UPDTICB) which will allow for fields that are not stored
in the insurance buffer to be updated into the IB Insurance Files.\n
Update: IB*2*528 increased the data length of the COMMENT-PATIENT POLICY
field (2.312, 1.08) from 80 characters to 250 characters; and therefore a new
DD definition COMMENT-SUSCRIBER POLICY (2.342) subfile was created to store
the increased length and the history of comments entered. The UPDTICB
component (API) will be affected by this change. All subscribers to this ICR
will need to make the necessary changes in their applications to reference the
new field. When all subscribers have implemented the use of the new fields,
the old fields will need to be deleted with a subsequent IB patch. Old and new
fields are noted at the UPDTICB component details.\n\n", "", "UPDTICB", "2009/06/11"], ["5354", "MILITARY SERVICE INFORMATION", "Routine", "REGISTRATION", "2009/01/29", "APPROVED", "Active", "Private", "", "
Patch DG*5.3*797 modifies the PATIENT file (#2) to
support the entry of an unlimited number of military service episodes for the
patient. The storage of the service episodes is in the new MILITARY SERVICE
EPISODE sub-file (#2.3216). The following APIs will return service episode
data from the appropriate location in the PATIENT file.\n\n\n\n", "", "DGMSE", "2011/07/18"], ["5355", "BILL INFORMATION", "Routine", "INTEGRATED BILLING", "2009/02/02", "APPROVED", "Active", "Private", "", "
This APIs were created to provide detailed information
about bills created for prescription/refills.", "", "IBNCPUT3", "2010/08/25"], ["5356", "BILL INFO", "Routine", "INTEGRATED BILLING", "2009/02/04", "", "Pending", "Private", "", "", "", "", ""], ["5357", "Imaging-Radiology file 79.1", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2009/02/04", "APPROVED", "Active", "Private", "79.1", "
Radiology gives Imaging permission to point to file
IMAGING LOCATIONS (#79.1) in addition to reading and writing to the file.
(with VA FileMan)", "", "", "2010/01/26"], ["5358", "Imaging-Radiology file 79.2", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2009/02/04", "APPROVED", "Active", "Private", "79.2", "
Radiology gives Imaging permission to point to file
IMAGING TYPE (#79.2).", "", "", "2009/03/17"], ["5359", "Imaging- Radiology file 78.6", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2009/02/04", "APPROVED", "Active", "Private", "78.6", "
Radiology gives Imaging permission to read file
CAMERA/EQUIP/RM (#78.6).", "", "", "2009/03/17"], ["5360", "Imaging- Radiology file 78.4", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2009/02/04", "APPROVED", "Active", "Private", "78.4", "
Radiology gives Imaging permission to read file FILM
SIZE (#78.4).", "", "", "2009/03/17"], ["5361", "IBOSRX", "Routine", "INTEGRATED BILLING", "2009/02/05", "APPROVED", "Active", "Controlled Subscription", "", "
This IA allows a subscribing package to call
COLLECT^IBOSRX to identify and return potential secondary payer rx claims.", "", "IBOSRX", "2010/08/25"], ["5362", "PSB GETCOMMENTS", "Remote Procedure", "BAR CODE MED ADMIN", "2009/02/06", "", "Pending", "Controlled Subscription", "", "
Gives the client VDL Provider and Pharmacy Over Ride
information and Order Check Text.", "", "", ""], ["5363", "HINQ Option Access", "", "HINQ", "2011/01/25", "", "Withdrawn", "", "", "", "", "", ""], ["5364", "ADD VAFCPTAD(PARAM)", "Routine", "REGISTRATION", "2009/02/09", "APPROVED", "Active", "Private", "", "\n
Master Patient Index Austin (MPI) requests the ability to add a patient
to the PATIENT (#2) file via RPC VAFC VOA ADD PATIENT which calls
routine ADD^VAFCPTAD(PARAM).\n
A Remote Procedure Call containing the PARAM data adds a patient that
is new to the local PATIENT (#2) file. This is to support the Veteran
On-Line Application (VOA) project within the MyHealtheVet system.\n
The information for the new record originates from Person Service
Identity Management (PSIM) and National Enrollment Service (ESR).
An in-person authentication vetting process is conducted by ESR
prior to invoking the VAFC VOA ADD PATIENT Remote Procedure.", "", "VAFCPTAD", "2009/04/29"], ["5365", "REQUEST/CONSULTATION AIFC CROSS REFERENCE", "File", "CONSULT/REQUEST TRACKING", "2009/02/11", "APPROVED", "Active", "Private", "123", "
Prosthetics requires access to the "AIFC" cross
reference of file 123 in support of the Inter-Facility Consults (IFC) data
interface for Prosthetics. Reference RMPR*3*83 and GMRC*3*44.", "", "", "2009/06/12"], ["5366", "PHARMACY ENHANCED ORDER CHECKS MED PROFILE BUILDER", "Routine", "OUTPATIENT PHARMACY", "2009/02/12", "APPROVED", "Active", "Controlled Subscription", "", "
This API is used currently by CPRS and Inpatient Meds
to build med profile data for both IP meds and OP meds to return enhanced
order checks by using the new interface by First Data Bank (FDB).", "", "PSODDPR4", "2023/11/14"], ["5367", "EXPERT SYSTEM OCS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2009/02/13", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this IA is to provide access to three
order checks that are performed in the OE/RR Expert System.", "", "OROCAPI", "2014/07/15"], ["5368", "Prosthetics Option Access", "", "PROSTHETICS", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5369", "PHARMACY ENHANCED ORDER CHECKS FDB INTERFACE", "Routine", "PHARMACY DATA MANAGEMENT", "2009/02/13", "APPROVED", "Active", "Private", "", "
This API is used to request and get back order check
results from a server using First DataBank's Drug Information Framework (DIF).
This interface uses the Web Services to make the requests and get back
results.", "", "PSSHRQ2", "2014/10/28"], ["5370", "DSICDT", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2009/02/19", "APPROVED", "Active", "Controlled Subscription", "", "
This routine converts dates and times from one format
into another. It can be called via a function call, or the RPC: DSIC DATE
CONVERT.", "", "DSICDT", "2009/06/11"], ["5371", "DSICDPT", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2009/02/19", "APPROVED", "Active", "Controlled Subscription", "", "
Contains entry points to get patient demographic data.", "", "DSICDPT", "2009/06/11"], ["5372", "DSICLOCK", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2009/02/19", "APPROVED", "Active", "Controlled Subscription", "", "
Lock or unlock a global reference from a gui client or
a funtion call.", "", "DSICLOCK", "2009/06/11"], ["5373", "DSICVA", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2009/02/19", "APPROVED", "Active", "Controlled Subscription", "", "
Returns the default institution data.", "", "DSICVA", "2009/06/11"], ["5374", "DSICFM06", "Routine", "VA CERTIFIED COMPONENTS - DSSI", "2009/02/19", "APPROVED", "Active", "Controlled Subscription", "", "
Wrapper to FileMan utilities for accessing data
dictionary structures.", "", "DSICFM06", "2009/06/11"], ["5375", "ENROLLMENT STATUS", "File", "REGISTRATION", "2009/02/27", "APPROVED", "Active", "Private", "27.15", "\n
Master Patient Index Austin (MPI) will create an ENROLLMENT STATUS field
in our MPI FACILITY ASSOCIATION (#985.5) file. This field will point to
the ENROLLMENT STATUS (#27.15) file. Since the MPI is a central national
database, that environment does not currently contain this VistA file.
Development requests permission to place the ENROLLMENT STATUS (#27.15)
file on the Master Patient Index. We will be responsible for keeping
the file current.\n
On the Master Patient Index, MPI will use direct global and FileMan
access to read the following fields of the ENROLLMENT STATUS (#27.15)
file.\n", "", "", "2009/04/20"], ["5376", "Engineering Option Access", "", "ENGINEERING", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5377", "RADIOLOGY/NUCLEAR MEDICINE Option Access", "", "RADIOLOGY/NUCLEAR MEDICINE", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5378", "ONCOLOGY REMOVE IDENTIFIER DESIGNATION", "File", "1", "2009/03/04", "APPROVED", "Active", "Private", "164.18", "
ONCOLOGY needs to remove the IDENTIFIER label from the
1 field (NSC NUMBER) in file 164.18 (CHEMOTHERAPEUTIC DRUGS). This field has
been designated a "Key field" thereby making the IDENTIFIER redundant.\n\n
This integration agreement exists so we can KILL ^DD(164.18,0,"ID",1) with
ONCOLOGY patch ONC*2.11*49.\n", "", "", "2009/03/04"], ["5379", "FBCS ACCESS TO DGENA", "Routine", "REGISTRATION", "2009/03/09", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DGENA", "2013/04/10"], ["5380", "FBCS ACCESS TO DGENPTA", "Routine", "REGISTRATION", "2009/03/09", "", "Withdrawn", "Controlled Subscription", "", "", "", "DGENPTA", ""], ["5381", "FBCS ACCESS TO DGENQRY", "Routine", "REGISTRATION", "2009/03/09", "", "Withdrawn", "Controlled Subscription", "", "", "", "DGNEQRY", ""], ["5382", "FBCS ACCESS TO DGMTH", "Routine", "REGISTRATION", "2009/03/09", "", "Withdrawn", "Controlled Subscription", "", "", "", "DGMTH", ""], ["5383", "FBCS ACCESS TO DGMTR", "Routine", "REGISTRATION", "2009/03/09", "", "Retired", "Controlled Subscription", "", "", "", "DGMTR", ""], ["5384", "FBCS ACCESS TO DGPMV10", "Routine", "REGISTRATION", "2009/03/09", "", "Withdrawn", "Controlled Subscription", "", "
FBCS access to INP^DGPMV10 to set-up inpt variables
needed (mimic VAIP array)", "", "DGPMV10", ""], ["5385", "Dosing Checks for IVs", "Routine", "INPATIENT MEDICATIONS", "2009/03/11", "APPROVED", "Active", "Private", "", "
This API calls DOSE^PSSDSAPD to perform dosing checks
for display in CPRS. For full Output details, see the 'VistA to MOCHA
Interface Document', located under the 'Pharm: Data Management (PDM)' section,
under the 'Clinical' section of the VA Software Document Library (VDL).\n
Last Updated: June/2018
Patch: PSJ*5.0*538
Update: PSS*1.0*224 changed one of the output subscripts for the
Informational output message for the X(3) output.", "", "PSJAPIDS", "2024/10/24"], ["5386", "LEXU Lookup Screens", "Routine", "LEXICON UTILITY", "2009/03/13", "APPROVED", "Active", "Supported", "", "
This agreement includes common entry points for
filtering Lexicon searches. Similar to DIC("S") screens.\n", "", "LEXU", "2009/03/16"], ["5387", "Access to Lexicon file #757.03", "File", "LEXICON UTILITY", "2009/03/16", "", "Withdrawn", "Private", "757.03", "
Allows Radiology/Nuclear Medicine package to access
Lexicon file #757.03, Coding System, to be used for Fileman lookup as in
DIC("S") screen of medical terminology, diagnosis or classification.", "", "", ""], ["5388", "ICD-9 Diagnosis File 80", "File", "DRG GROUPER", "2009/03/16", "", "Retired", "Supported", "80", "
This ICR will be retired upon ICD10 Implementation
(retire action estimated to occur April 1,2016). New development efforts
should use ICR 5747.\n
Applications may conduct Fileman lookups of ICD Diagnosis file #80 provided
the 0 (zero) node is not returned as part of the output from the lookup.
Applications may also point to the ICD Diagnosis file #80. This agreement
provides very limited access to file 80, primarily the .01 field and selected
cross-references. Additional access to file 80 is given through the use of
APIs in routines ICDCODE and ICDAPIU.", "", "", "2009/04/02"], ["5389", "IBARXEU0", "Routine", "INTEGRATED BILLING", "2009/03/16", "", "Withdrawn", "Controlled Subscription", "", "", "", "IBARXEU0", ""], ["5390", "ORWORB GETDATA", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2009/03/16", "", "Withdrawn", "Controlled Subscription", "", "", "ORWORB GETDATA", "", ""], ["5391", "ORWPT SELCHK", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2009/03/16", "", "Withdrawn", "Controlled Subscription", "", "
Requires DFN input.", "ORWPT SELCHK", "", ""], ["5392", "FBCS ACCESS TO FBCHDI", "Routine", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "", "
The Fee Basis claims system calls END^FBCHDI after the
GUI rpc DSIF INP COMPLETE PAYMENT processing which completes a CH payment in
order to clean up all FB variables used by FB APIs.", "", "FBCHDI", "2009/06/11"], ["5393", "FBCS File #161.91 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.91", "
The FBCS GUI application reads the ADJUSTMENT REASON
(#161.91) file using Fileman for selection by the user.\n
^FB(161.91,D0,0)
.01 CODE 0;1 Fileman r
^FB(161.91,D0,1,D1,0)
.01 STATUS EFFECTIVE DATE 0;1 Fileman r
1 STATUS 0;2 Fileman r
2 FEE USE 0;3 Fileman r
^FB(161.91,D0,2,D1,0)
.01 DESCRIPTION EFFECTIVE DATE 0;1 Fileman r
^FB(161.91,D0,2,D1,D,D2,0)
.01 DESCRIPTION 0;1 Fileman r
^FB(161.91,D0,4,D1,0)
.01 SUSPENSION DESCRIPTION 0;1 Fileman r", "", "", "2009/06/11"], ["5394", "FBCS File #161.92 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.92", "
The FBCS GUI application reads the ADJUSTMENT GROUP
(#161.92) file using Fileman.\n
^FB(161.92,D0,0)
.01 CODE 0;1 Fileman r
^FB(161.92,D0,1,D1,0)
.01 STATUS EFFECTIVE DATE 0;1 Fileman r
1 STATUS 0;2 Fileman r
2 FEE USE 0;3 Fileman r
^FB(161.92,D0,2,D1,0)
.01 DESCRIPTION EFFECTIVE DATE 0;1 Fileman r
.02 SHORT DESCRIPTION 0;2 Fileman r
^FB(161.92,D0,2,D1,D,D2,0)
.01 DESCRIPTION 0;1 Fileman r", "", "", "2009/06/11"], ["5395", "FBCS File 161.93 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.93", "
The FBCS application reads the REMITTANCE REMARK
(#161.93) file using Fileman and checks for existence of the node.\n
^FB(161.93,D0,0)
.01 CODE 0;1 Fileman r,Global r
^FB(161.93,D0,1,D1,0)
.01 STATUS EFFECTIVE DATE 0;1 Fileman r
1 STATUS 0;2 Fileman r
2 FEE USE 0;3 Fileman r
^FB(161.93,D0,2,D1,0)
.01 DESCRIPTION EFFECTIVE DATE 0;1 Fileman r
^FB(161.93,D0,2,D1,D,D2,0)
.01 DESCRIPTION 0;1 Fileman r", "", "", "2009/06/11"], ["5396", "FBCS File 162.95 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "162.95", "
The FBCS application reads the FEE BASIS CHECK
CANCELLATION REASON (#162.95) file to get cancellation reasons.\n
^FB(162.95,D0,0)
.01 CANCELLATION REASON 0;1 Global r", "", "", "2009/06/11"], ["5397", "FBCS File #162.7 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Private", "162.7", "
The FBCS application reads the FEE BASIS UNAUTHORIZED
CLAIMS (#162.7) file.\n
^FB583(D0,0) $D(node)
.01 DATE CLAIM RECEIVED 0;1 Global r
.5 FEE PROGRAM 0;2 Global r
1 VENDOR 0;3 Global r
2 VETERAN 0;4 Global r
3 TREATMENT FROM DATE 0;5 Global r
4 TREATMENT TO DATE 0;6 Global r
9 PATIENT TYPE CODE 0;10 Global r
10 DISPOSITION 0;11 Global r
12 AUTHORIZED FROM DATE 0;13 Global r
13 AUTHORIZED TO DATE 0;14 Global r
19 PRINT LETTER? 0;16 Global r
23 CLAIM SUBMITTED BY 0;23 Global r
24 STATUS 0;24 Global r
30 AUTHORIZATION 0;27 Global r
31 38 U.S.C. 1725 0;28 Global r
^FB583(D0,5)
32 FPPS CLAIM ID 5;1 Global r
^FB583(D0,LOG1,D1,0)
.01 DATE/TIME EDITED 0;1 Fileman r
1 EDITED BY 0;2 Fileman r
2 COMMENTS 0;3 Fileman r
^FB583(DO,LOG2,D1,0)
.01 CHANGED DATE/TIME 0;1 Fileman r
1 FIELD 0;2 Fileman r
2 OLD VALUE 0;3 Fileman r
3 NEW VALUE 0;4 Fileman r
4 CHANGED BY 0;5 Fileman r\n
^FB\n
^FB583("AD") Used to lookup by Program and AUTHORIZED FROM DATE", "", "", "2016/04/29"], ["5398", "FBCS File #161.25 R/W", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.25", "
The FBCS application accesses the FEE BASIS VENDOR
CORRECTION (#161.25) file when transmitting/re-transmitting record data to
Austin.\n
^FBAA(161.25,D0,0) Global r ($D)
4 DATE TRANSMITTED 0;5 Global w (set to null)\n
^FBAA(161.25,"AE") Used to check if txns require transmission
direct global set of xref
^FBAA(161.25,"AD") Used to check if MRAs were xmitted on sel dt
direct global kill of xref for date
^FBAA(161.25,"AF") Used to check if the vendor is a linked vendor", "", "", "2009/06/11"], ["5399", "FBCS File #161.26 R/W", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.26", "
The FBCS application accesses the FEE BASIS PATIENT MRA
(#161.26) file when transmitting/re-transmitting record data to Austin.\n
^FBAA(161.26,D0,0)
.01 NAME 0;1 Fileman w, Laygo
1 STATUS 0;2 Fileman w Global w
2 POINTER TO AUTHORIZATION NODE 0;3 Fileman w
3 TYPE 0;4 Fileman w
4 DATE TRANSMITTED 0;5 Global w
5 AUTH. FROM DATE CHANGED 0;6 Fileman w
6 SHORT TERM MRA 0;7 Fileman w\n\n
^FBAA(161.26,"AC") Used to check if txns require transmission
direct global set/kill of xref
^FBAA(161.26,"AD") Used to check if MRAs were xmitted on selected dt
direct global kill of xref for date", "", "", "2009/06/11"], ["5400", "FBCS File #161.27 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.27", "
The FBCS application accesses the FEE BASIS SUSPENSION
(#161.27) file to get suspense codes.\n
^FBAA(161.27,D0,0)
.01 CODE 0;1 Global r
^FBAA(161.27,D0,2)
2 SHORT DESCRIPTION 0;1 Global r", "", "", "2009/06/11"], ["5401", "FBCS File #161.8 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.8", "
The FBCS application accesses the FEE BASIS PROGRAM
(#161.8 file to get the Program names and verify if the program is active.\n
^FBAA(161.8,D0,0) Global r ($D)
.01 NAME 0;1 Global r,Fileman r
2 ACTIVE? 0;3 Global r,Fileman r", "", "", "2009/06/11"], ["5402", "FBCS File #161.81 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.81", "
The FBCS application accesses the FEE BASIS
PARTICIPATION CODE (#161.81) file to get participation codes.\n
^FBAA(161.81,D0,0)
.01 NAME 0;1 Global r", "", "", "2009/06/11"], ["5403", "FBCS File #161.82 Read only", "File", "FEE BASIS", "2009/03/16", "", "Retired", "Controlled Subscription", "161.82", "
The FBCS application accesses the FEE BASIS PURPOSE OF
VISIT (#161.82) file to get names and codes of active purposes.\n
^FBAA(161.82,D0,0) Global r ($D)
.01 NAME 0;1 Global r, Fileman r
3 AUSTIN CODE 0;3 Global r, Fileman r
^FBAA(161.82,D0,I)
4 INACTIVATION DATE I;1 Fileman r", "", "", "2009/06/11"], ["5404", "ICD-9 Operation/Procedure file 80.1", "File", "DRG GROUPER", "2009/03/17", "", "Retired", "Supported", "80.1", "
This ICR will be retired upon ICD10 Implementation
(retire action estimated to occur April 1,2016). New development efforts
should use ICR 5747.\n
Applications may conduct Fileman lookups of ICD Operation Procedure file #80.1
provided the 0 (zero) node is not returned as part of the output from the
lookup. Applications may also point to the ICD Operation/Procedure file
#80.1. This agreement provides very limited access to file 80.1, primarily
the .01 field and selected cross-references. Additional access to file 80.1
is given through the use of APIs in routines ICDCODE and ICDAPIU.", "", "", "2009/04/02"], ["5405", "CPT File 81 Surgical Identifier", "File", "CPT/HCPCS CODES", "2009/03/17", "APPROVED", "Active", "Private", "81", "
The DD for the CPT file #81 includes the following DD
Identifier node which causes the CPT Versioned Description field #62 to be
displayed when a lookup is done on the CPT file:\n
^DD(81,0,"ID",6)=D EN^DDIOL((" "_$$IDCPF^ICPTID(+Y)),"","?0")
D:$D(SRSITE) ^SROCPT\n
An agreement is established for Surgery to call ^DD(81,0,"ID",6). This DD node
will remain in place to assist with CPT lookups from within the Surgery
package. Surgery will be responsible for support of the conditional call to
^SROCPT.\n
The following MUMPS code will be included with the file Identifier supporting
the Surgery Package to display the Versioned Description field #62 using the
Code Set Versioning API $$CPTD^ICDCODE:\n
D:$D(SRSITE) ^SROCPT\n", "", "", "2009/04/02"], ["5406", "Proxy User in File 200", "File", "KERNEL", "2009/03/17", "APPROVED", "Active", "Private", "200", "\n
The Veteran On-Line Application (VOA) project will make it easier
for veterans to register for medical benefits from VHA via the web.
National Enrollment Service (ESR), through Person Service Identity
Management (PSIM), uses a Remote Procedure to add a patient record
at the designated Preferred VistA Facility after the proper vetting
process.\n
The Remote Procedure is invoked on the Master Patient Index Austin
by PSIM via a proxy user in the NEW PERSON (#200) file. This proxy
user is assigned the PSIM GUI VistALink Access [MPI PSIM GUI
INTERFACE] secondary menu option. The user NAME and SECONDARY MENU
OPTION fields are created using the $$CREATE^XUSAP(proxyname,fmac,
options) API in IA# 4677. The other fields populated are listed below.\n
Because testing takes place on multiple "MPI" environments before
final installation on the national Austin Master Patient Index, the
PSUSER,APPLICATION PROXY user will be created in a post-init routine.
This ensures that the fields required for the RPC to work successfully
are created.\n", "", "", "2009/04/20"], ["5407", "OE/RR GET DEFAULT COSIGNER FOR USER", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2009/03/17", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Procedures would like use the entry point
GETDCOS^ORWTPN to get the default cosigner for the user.", "", "ORWTPN", "2009/03/19"], ["5408", "CPT/HCPCS Procedure File 81", "File", "CPT/HCPCS CODES", "2009/03/17", "APPROVED", "Active", "Supported", "81", "
Applications may conduct Fileman lookups of CPT
Procedure file #81 provided the 0 (zero) node is not returned as part of the
output from the lookup. Applications may also point to the CPT Procedure file
#81. This agreement provides very limited access to file 81, primarily the
.01 field and selected cross-references. Additional access to file 81 is given
through the use of APIs in routines ICPTCOD and ICPTAPIU.\n", "", "", "2014/11/17"], ["5409", "FBCS File #162.1 Read only", "File", "FEE BASIS", "2009/03/17", "", "Retired", "Controlled Subscription", "162.1", "
The FBCS application reads the FEE BASIS PHARMACY
INVOICE (#162.1) file to display pharmacy payment history.\n
^FBAA(162.1,D0,0)
.01 NUMBER 0;1 Global r
3 VENDOR 0;4 Global r
13 FPPS CLAIM ID 0;13 Global r
^FBAA(162.1,D0,RX,D1,0)
.01 PRESCRIPTION NUMBER 0;1 Global r
1 DRUG NAME 0;2 Global r
2 DATE PRESCRIPTION FILLED 0;3 Global r
3 AMOUNT CLAIMED 0;4 Global r
6 AMOUNT SUSPENDED 0;7 Global r
7 SUSPEND CODE 0;8 Global r
8 LINE ITEM STATUS 0;9 Global r
1.5 STRENGTH 0;12 Global r
1.6 QUANTITY 0;13 Global r
6.5 AMOUNT PAID 0;16 Global r
13 BATCH NUMBER 0;17 Global r
15 DATE CERTIFIED FOR PAYMENT 0;19 Global r
16 PAYMENT TYPE CODE 0;20 Global r
^FBAA(162.1,D0,RX,D1,2)
23 VOID PAYMENT 2;3 Global r
26 ASSOCIATED 7078/583 2;6 Global r
^FBAA(162.1,D0,RX,D1,3)
36 FPPS LINE ITEM 3;1 Global r
^FBAA(162.1,D0,RX,D1,FBREJ) Global r ($D)\n
^FBAA(162.1,"AD") Used to lookup by patient
^FBAA(162.1,"AE") Used to check if batch exists, loop on batch
^FBAA(162.1,"AN") Used to lookup by Vendor", "", "", "2009/06/11"], ["5410", "FBCS File #162.2 R/W/D", "File", "FEE BASIS", "2009/03/17", "", "Retired", "Controlled Subscription", "162.2", "
The FBCS application accesses the FEE
NOTIFICATION/REQUEST (#162.2) file. Entries may be deleted as long as there
is not a 7078 set up for the request and the user must either be the user who
entered the request or be the holder of the FBAASUPERVISOR security key.\n
^FBAA(162.2,D0,0) Global r ($D)
.01 DATE/TIME 0;1 Fileman r/w,Global r
1 VENDOR 0;2 Fileman r/w,Global r
2 PERSON WHO CALLED 0;3 Fileman r/w
3 VETERAN 0;4 Fileman w,Global r
4 AUTHORIZED FROM DATE/TIME 0;5 Fileman r/w,Global r
5 ADMITTING DIAGNOSIS 0;6 Fileman r/w,Global r
6 ATTENDING PHYSICIAN 0;7 Fileman r/w
7 USER ENTERING NOTIFICATION 0;8 Fileman r/w,Global r
8 LEGAL ENTITLEMENT 0;9 Fileman r/w,Global r
9 DATE OF LEGAL DETERMINATION 0;10 Fileman w
10 USER ENTERING LEGAL DETERM. 0;11 Fileman w
11 MEDICAL ENTITLEMENT 0;12 Fileman r/w,Global r
12 DATE OF MEDICAL DETERMINATION 0;13 Fileman w
13 USER ENTERING MEDICAL DETERM. 0;14
100 REQUEST STATUS 0;15 Fileman r/w,Global r
14 SUSPENSE CODE 0;16 Fileman r/w
16 ASSOCIATED 7078 0;17 Fileman r/w,Global r
6.5 ATTEN.PHYSICIAN PHONE NUMBER 0;18 Fileman r/w
3.5 DATE/TIME OF ADMISSION 0;19 Fileman r/w,Global r
^FBAA(162.2,D0,1,D1,0) [Field 15]
.01 DESCRIPTION OF SUSPENSION 0;1 Fileman r/w
^FBAA(162.2,D0,2) [Field 17]
17 REFERRING PROVIDER 2;1
^FBAA(162.2,DO,LOG1,D1,0)
.01 DATE/TIME EDITED 0;1 Fileman r
1 EDITED BY 0;2 Fileman r
2 COMMENTS 0;3 Fileman r\n
^FBAA(162.2,"AM") Lookup entry by ASSOCIATED 7078
^FBAA(162.2,"D") to check if record exists for Patient", "", "", "2016/04/29"], ["5411", "FBCS File #162.6 Read only", "File", "FEE BASIS", "2009/03/17", "", "Retired", "Controlled Subscription", "162.6", "
The FBCS application accesses the FEE BASIS DISPOSITION
CODE (#162.6) file.\n
^FBAA(162.6,D0,0) Global r ($D)
.01 NAME 0;1 Fileman r
1 CODE 0;2 Fileman r", "", "", "2009/06/11"], ["5412", "FBCS File #163.85 Read only", "File", "FEE BASIS", "2009/03/17", "", "Retired", "Controlled Subscription", "163.85", "
The FBCS application accesses the FEE BASIS VA TYPE OF
SERVICE (#163.85) file to get the VA Code when sending payment data to Austin.\n
^FBAA(163.85,D0,0)
.02 VA CODE 0;2 Global r", "", "", "2009/06/11"], ["5413", "CPT File 81 Identifier Update", "File", "1", "2009/03/19", "APPROVED", "Active", "Private", "0", "\n\n", "", "", "2009/03/19"], ["5414", "CPT Modifier File 81.3 Identifier Update", "File", "1", "2009/03/19", "APPROVED", "Active", "Private", "0", "", "", "", "2009/03/19"], ["5415", "ICD Diagnosis File 80 Identifier Update", "File", "1", "2009/03/19", "APPROVED", "Active", "Private", "0", "", "", "", "2009/04/04"], ["5416", "ICD Procedure File 80.1 Identifier Update", "File", "1", "2009/03/19", "APPROVED", "Active", "Private", "0", "", "", "", "2009/03/20"], ["5417", "EPHARM LOG OF TRANSACTION FILE", "File", "E CLAIMS MGMT ENGINE", "2009/03/19", "APPROVED", "Active", "Private", "9002313.57", "
The Outpatient Pharmacy package required direct Read
access to the following fields/indices of the BPS LOG OF TRANSACTIONS file
(#9002313.57).", "", "", "2009/03/21"], ["5418", "Set file 78.3 'ID','WRITE'", "File", "1", "2009/03/20", "APPROVED", "Active", "Private", "78.3", "
Radiology/Nuclear Medicine intends to add the following
node to file #78.3's Data Dictionary:\n
^DD(78.3,0,"ID","WRITE")=D EN^DDIOL($$EN1^RABIRAD,"","?33")\n
This will be a one-time IA with the installation of patch RA*5.0*97.", "", "", "2009/03/22"], ["5419", "Insert 'I' in file 78.3 header node", "File", "1", "2009/03/20", "APPROVED", "Active", "Private", "78.3", "
Radiology/Nuclear Medicine intends to insert an "I"
after the file number in the second piece of File 78.3's header node.\n
Here are the "before" and "after" from a development account:\n
"before": ^RA(78.3,0)=DIAGNOSTIC CODES^78.3^77^30\n
"after": ^RA(78.3,0)=DIAGNOSTIC CODES^78.3I^77^30\n\n
This will be a one-time IA with the installation of patch RA*5.0*97.", "", "", "2009/03/22"], ["5420", "XOBWLIB1", "Routine", "WEB SERVICES CLIENT", "2009/03/20", "APPROVED", "Active", "Private", "", "
$$IMPORT^XOBWLIB1 allows a package's pre-init routine
to automatically import a Cache Object from an XML host file, without the
package needing to resort to Cache-specific code in its pre-init routine.\n
Pharmacy Re-engineering was a very early adopter of HWSC whose early preview
documentation recommended a style of XML parsing that requires the application
to provide (and therefore export and install) Cache Objects.", "", "XOBWLIB1", "2009/06/17"], ["5421", "XOBWLIB", "Routine", "WEB SERVICES CLIENT", "2009/03/20", "", "Under Revision", "Supported", "", "
Public APIs for the HWSC package.", "", "XOBWLIB", "2009/06/16"], ["5422", "WDDE WARD ASSIGNMENT", "Routine", "PHARMACY DATA MANAGEMENT", "2009/03/24", "", "Withdrawn", "Private", "", "
This API checks if a ward is assigned to a specific
ward drug dispensing equipment (WDDE).\n", "", "PSSWDLL", "2009/03/24"], ["5423", "RETURN OTHER PRINT & SPEC INSTRUCTIONS FOR AN ORDER", "Routine", "INPATIENT MEDICATIONS", "2009/03/24", "", "Pending", "Controlled Subscription", "", "
This retrieves the Special Instructions or Other Print
Information for an order.", "", "PSJBCMA5", ""], ["5424", "INSURANCE FILING TIME FRAME", "File", "INTEGRATED BILLING", "2009/03/26", "APPROVED", "Active", "Private", "355.13", "
The Insurance Capture Buffer application reads file
#355.13 INSURANCE FILING TIME FRAME in order to display selections to the user
and determine if time frame Values are needed.\n
^IBE(355.13,D0,0)
.01 NAME 0;1 Fileman read
.02 VALUE 0;2 Fileman read", "", "", "2009/06/11"], ["5425", "DBIA 5425", "Routine", "PHARMACY DATA MANAGEMENT", "2009/04/07", "APPROVED", "Active", "Private", "", "
This DBIA provides various components that will be used
for Pharmacy Re-engineering order checking functionality.", "", "PSSDSAPI", "2014/06/19"], ["5426", "DBIA 5426", "Routine", "PHARMACY DATA MANAGEMENT", "2009/04/07", "APPROVED", "Active", "Private", "", "
This DBIA is for the call to perform Dosing checks on
Medication orders.\n
For full Input and Output details, see the 'VistA to MOCHA Interface
Document', located under the 'Pharm: Data Management (PDM)' section, under the
'Clinical' section of the VA Software Document Library (VDL).\n
Last Updated: June/2018
Patch: PSS*1.0*224
Update: Changed one of the output subscripts for the Informational
output message for the X(3) output.", "", "PSSDSAPD", "2024/10/28"], ["5427", "PSOSUCH1", "Routine", "OUTPATIENT PHARMACY", "2009/04/07", "APPROVED", "Active", "Controlled Subscription", "", "
When an Rx is placed on 3/4 days supply hold for
ePharamcy, CMOP updates the fill/refill date with the date that the Rx may be
filled and calls CHANGE^PSOSUCH1 to update file 52.5 and all cross references.\n", "", "PSOSUCH1", "2009/06/23"], ["5428", "ETIOLOGY FIELD FILE", "File", "LAB SERVICE", "2009/04/14", "", "Withdrawn", "Private", "61.2", "
The MRSA INITIATIVE REPORTS would like to request
Direct Global access to the following fields of the Etiology Field file
(#61.2) for reporting purposes:", "", "", ""], ["5429", "ORDER FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2009/04/14", "APPROVED", "Active", "Private", "100", "
The MRSA INITIATIVE REPORTS would like to request
Direct Global access to the following fields of the Order file (#100) for
reporting purposes.", "", "", "2009/06/08"], ["5430", "ORDERABLE ITEMS FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2009/04/14", "APPROVED", "Active", "Private", "101.43", "
The MRSA INITIATIVE REPORTS would like to request
Direct Global access to the following fields of the Orderable Items file
(#101.43) for reporting purposes.", "", "", "2009/06/08"], ["5431", "PATIENT FILE", "File", "REGISTRATION", "2009/04/14", "APPROVED", "Active", "Private", "2", "
The MRSA INITIATIVE REPORTS would like to request
Direct Global access to the following fields of the Patient file (#2) for
reporting purposes.", "", "", "2009/06/08"], ["5432", "ANTIMICROBIAL SUSCEPTIBILITY FILE", "File", "LAB SERVICE", "2009/04/14", "", "Withdrawn", "Private", "62.06", "
The MRSA INITIATIVE REPORTS would like to request
Direct Global access to the following fields of the Antimicrobial
Susceptibility file (#62.06) for reporting purposes.", "", "", ""], ["5433", "CENSUS FILE", "File", "REGISTRATION", "2009/04/14", "APPROVED", "Active", "Controlled Subscription", "41.9", "
The MRSA INITIATIVE REPORTS would like to request
Direct Global access to the following fields of the Census file (#41.9) for
reporting purposes.", "", "", "2009/06/08"], ["5434", "IV Parameter Validation", "Routine", "BAR CODE MED ADMIN", "2009/04/29", "APPROVED", "Active", "Private", "", "
This utility returns the status of the IV Bags
associated with an order.", "", "PSBPOIV", "2014/05/29"], ["5435", "VALM1 (PRT,PRTL)", "Routine", "LIST MANAGER", "2009/05/01", "", "Withdrawn", "Private", "", "
Outpatient Pharmacy requests an integration agreement
to call line tags PRT and PRTL of VALM1.", "", "VALM1", ""], ["5436", "VALM2 (HELP,MENU)", "Routine", "LIST MANAGER", "2009/05/01", "", "Withdrawn", "Private", "", "
Outpatient Pharmacy requests an integration agreement
to call line tags HELP and MENU of VALM2.", "", "VALM2", ""], ["5437", "VALM4 (FIRST,LAST,NEXT,PREV)", "Routine", "LIST MANAGER", "2009/05/01", "", "Withdrawn", "Private", "", "
Outpatient Pharmacy requests an integration agreement
to call line tags FIRST, LAST, NEXT and PREV of VALM4.", "", "VALM4", ""], ["5438", "VALM40 (DOWN,FIND,GOTO,LEFT,RIGHT,UP)", "Routine", "LIST MANAGER", "2009/05/01", "", "Withdrawn", "Private", "", "
Outpatient Pharmacy requests an integration agreement
to call line tags DOWN, FIND, GOTO, LEFT, RIGHT and UP of VALM40.", "", "VALM40", ""], ["5439", "DELETE WRITE ACCESS IN FILE 200 FOR PATCH ES*1*46", "File", "POLICE & SECURITY", "2009/05/05", "APPROVED", "Active", "Private", "200", "
This is a request to delete the delete, laygo, and
write access that any user may have to files 910-916 for patch ES*1*46. This
patch retires many of the Police package options that can write, add, or
delete to the legacy Police package files. Read-only options are left active
for historical data retrieval.\n
In file 200, field 32 (ACCESSIBLE FILE), subfields 2 (DELETE ACCESS), 3 (LAYGO
ACCESS), and 5 (WRITE ACCESS) would be deleted for any user who has either to
any file in the 910-916 range.\n
Here is the code to do so:\n
N DA,DIE,DR,I,II S DR="2///@;3///@;5///@"
F I=0:0 S I=$O(^VA(200,I)) Q:'I D
.F II=909.9:0 S II=$O(^VA(200,I,"FOF",II)) Q:'II!(II>916) D
..S DIE="^VA(200,"_I_",""FOF"",",DA(1)=I,DA=II D ^DIE
Q", "", "", "2009/05/07"], ["5440", "RDI OUTAGE INFO GLOBAL", "File", "ORDER ENTRY/RESULTS REPORTING", "2009/05/06", "APPROVED", "Active", "Controlled Subscription", "", "
This IA is used to allow subscribed packages to view
all of the ^XTMP("OUTAGE INFO") global nodes.", "", "", "2009/05/06"], ["5441", "FBCS Access to FBUCUTL5 routine", "Routine", "FEE BASIS", "2009/05/06", "", "Retired", "Controlled Subscription", "", "", "", "FBUCUTL5", ""], ["5442", "FBCS Access to FBNPILK", "Routine", "FEE BASIS", "2009/05/06", "", "Retired", "Controlled Subscription", "", "
Using $$EN^FBNPILK", "", "FBNPILK", ""], ["5443", "FBCS Access to FBAACO3", "Routine", "FEE BASIS", "2009/05/06", "", "Retired", "Controlled Subscription", "", "
Access to CALC^FBAACO3 (Calculate Current Invoice
Total)
OUT^FBAACO3 (Update payment line count in 161.7)
SETO^FBAACO3 (fiscal year of date)", "", "FBAACO3", ""], ["5444", "FBCS access to FBAASCB0", "Routine", "FEE BASIS", "2009/05/06", "", "Retired", "Controlled Subscription", "", "
FBCS needs access to $$INTER^FBAASCB0 (get internal
entry number from file 424)", "", "FBAASCB0", ""], ["5445", "HEALTH SUMMARY DESCRIPTION", "Routine", "HEALTH SUMMARY", "2009/05/06", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Reminders is requesting the ability to call
the EN^GMTSDESC. This API returns a formatted output array containing the
context of the entry from either file #142, 142.1, and 142.5.\n", "", "GMTSDESC", "2009/05/21"], ["5446", "ORDER DIALOG DESCRIPTION", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2009/05/06", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Reminders is requesting the ability to call
EN^ORORDDSC. This API returns a formatted output array containing the context
of the entry from file #101.41.\n", "", "ORORDDSC", "2022/12/20"], ["5447", "TIU OBJECTS AND TEMPLATE STATUS AND DESCRIPTION", "Routine", "TEXT INTEGRATION UTILITIES", "2009/05/06", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Reminders is requesting the ability to call
the different APIs in the routine TIUCHECK.\n", "", "TIUCHECK", "2009/05/21"], ["5448", "PXRM REMINDER DIALOG IS ACTIVE", "Routine", "CLINICAL REMINDERS", "2009/05/11", "APPROVED", "Active", "Controlled Subscription", "", "
TIU is requesting the ability to determine if an entry
from the REMINDER DIALOG file, file #801.41 is a dialog and if the entry is
active.\n", "", "PXRMDLG6", "2009/05/21"], ["5449", "KERNEL BSE LOOKUP IN HL LOGICAL LINK FILE", "File", "HEALTH LEVEL SEVEN", "2009/05/12", "APPROVED", "Active", "Private", "870", "
Kernel Broker Security Enhancement (BSE) requests the
ability to do a lookup within the HL LOGICAL LINK file (#870) using
FileManager and the command
D FIND^DIC(870,,".03;.08","X",L,,"C",,,"XUSBSE") where L=station#", "", "", "2012/04/16"], ["5450", "KERNEL BSE LOOKUP IN NETWORK LOCATION FILE", "File", "IMAGING", "2009/05/12", "APPROVED", "Active", "Private", "2005.2", "
Kernel Broker Security Enhancement (BSE) requests the
ability to do a lookup within the NETWORK LOCATION file (#2005.2) using
FileManager and the command
D FIND^DIC(2005.2,,"1","MO","VISTASITESERVICE",,,,,"XUSBSE")", "", "", "2010/06/16"], ["5451", "VALM HIDDEN ACTIONS protocol", "Other", "LIST MANAGER", "2009/05/13", "APPROVED", "Active", "Supported", "", "
Supported actions entries in the VALM HIDDEN ACTIONS
protocol.", "", "", "2009/06/11"], ["5452", "FILE 604 X-REFERENCE CLEAN UP", "File", "1", "2009/05/14", "APPROVED", "Active", "Private", "604", "
This IA is for cleaning up the x-references from a
faulty deletion of a field in file #604. Patch YS*5.01*100 will be used to run
the post-init routine YS501100 which does the following:
K ^DD(604,"B","PROGRESS NOTE POINTER",.53)
and K ^DD(604,"GL",.5,3,.53)", "", "", "2009/06/02"], ["5453", "ORWPS MEDHIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2009/05/21", "APPROVED", "Active", "Controlled Subscription", "", "
Returns the medication administration history for a med
in a report format. The input required is the DFN and Order IEN.", "ORWPS MEDHIST", "", "2018/02/09"], ["5454", "ORWTIU WINPRINT NOTE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2009/05/21", "APPROVED", "Active", "Controlled Subscription", "", "
Returns a TIU note formatted for output to a printer.
The input required is the TIU IEN (pointer to #8925). A second parameter
contains a Chart Copy flag denoting whether the user wants to print the chart
copy (=1). If the chart copy flag is 0 or not defined then the rpc outputs the
work copy.", "ORWTIU WINPRINT NOTE", "", "2018/02/09"], ["5455", "WOMEN'S HEALTH READS THE RAD/NUC MED ORDERS FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2009/05/26", "APPROVED", "Active", "Private", "75.1", "
This integration agreement allows the subscribing
package to read fields from the RAD/NUC MED ORDERS file (#75.1).", "", "", "2014/09/12"], ["5456", "Merged Records", "File", "TOOLKIT", "2009/06/04", "APPROVED", "Active", "Private", "15.3", "\n
The Health Data Repository (HDR) relies on the Master Patient
Index (MPI), and Person Service Identity Management (PSIM) to
provide national and correlated identifiers for patients. The
MPI does not currently have data for patient records involved
in past merge events.\n
Post-init routine, MPIF51P, will order through the XDR REPOINTED ENTRY
(#15.3) file. For the PATIENT (#2) file entries, data will be extracted
for the MERGED ENTRY (#.01) and MERGED TO ENTRY (#.02). This data
will be sent in A24 HL7 messages to the MPI to update PSIM and the
Administrative Data Repository (ADR).\n
MPIF51P will be distributed in VistA patch MPIF*1.0*51. It will be
run one time as part of the patch installation, and the routine can
then be deleted from the site's VistA system.\n", "", "", "2009/06/17"], ["5457", "NUTRITION STATUS file", "File", "DIETETICS", "2009/06/09", "", "Pending", "Controlled Subscription", "115.4", "
The Spinal Cord package would like to request direct
access to the following fields of the NUTRITION STATUS file (115.4) for
reporting purposes: .01 CATEGORY & 1 STATUS TEXT (U/L CASE)\n", "", "", ""], ["5458", "xobw.RestRequest", "Other", "WEB SERVICES CLIENT", "2009/06/10", "APPROVED", "Active", "Supported", "", "
This class is used to make REST-type requests to an
external web service.\n
The class extends Cache's %Net.HttpRequest class. As such, all methods in the
parent class are avialable in this one as well.", "", "", "2009/06/17"], ["5459", "xobw.error.BasicError", "Other", "WEB SERVICES CLIENT", "2009/06/10", "APPROVED", "Active", "Supported", "", "
class xobw.error.BasicError extends
xobw.error.AbstractError\n
Error class used by the HWSC error processing sub-system when a basic M/Cache
error occurs.", "", "", ""], ["5460", "xobw.error.DialogError", "Other", "WEB SERVICES CLIENT", "2009/06/10", "APPROVED", "Active", "Supported", "", "
class xobw.error.DialogError extends
xobw.error.AbstractError\n
Class for errors associated with DIALOG file (#.84) entries and used by the
HWSC error processing sub-system\n
The Kernel API EZBLD^DIALOG should be used to produce the 'text' property
value and the ien of the DIALOG file entry should be the 'code' property
value.", "", "", ""], ["5461", "xobw.error.HttpError", "Other", "WEB SERVICES CLIENT", "2009/06/10", "APPROVED", "Active", "Supported", "", "
class xobw.error.HttpError extends
xobw.error.AbstractError\n
Error class used by the HWSC error processing sub-system when an HTTP error
occurs.", "", "", ""], ["5462", "xobw.error.ObjectError", "Other", "WEB SERVICES CLIENT", "2009/06/10", "APPROVED", "Active", "Supported", "", "
class xobw.error.ObjectError extends
xobw.error.AbstractError\n
Error class used by the HWSC error processing sub-system when a CacheObject
error occurs.", "", "", ""], ["5463", "xobw.error.SoapError", "Other", "WEB SERVICES CLIENT", "2009/06/10", "APPROVED", "Active", "Supported", "", "
class xobw.error.SoapError extends
xobw.error.AbstractError\n
Error class used by the HWSC error processing sub-system when a SOAP fault is
returned.", "", "", "2009/06/17"], ["5464", "INCOME VERIFICATION MATCH Option Access", "", "INCOME VERIFICATION MATCH", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5465", "IFCAP Option Access", "", "IFCAP", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5466", "RETRIEVE COTS ACCESSION NUMBER", "Routine", "LAB SERVICE", "2009/06/19", "", "Pending", "Controlled Subscription", "", "
With the new integration to the Cerner Lab System,
there is a need to display the accession number from the Commercial Off the
Shelf (COTS) product in places outside the lab package.\n
This call allows the subscribing package to retrieve the COTS accession
nummber.", "", "LRJWLST", ""], ["5467", "PAID Option Access", "", "PAID", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5468", "ONE TIME RELEASE OF GMV CLOSEST READING", "Other", "GEN. MED. REC. - VITALS", "2009/06/23", "APPROVED", "Active", "Private", "", "
This is a one time ICR to allow OE/RR to release the
GMV CLOSEST READING RPC in patch OR*3.0*296.\n", "", "", "2009/06/23"], ["5469", "ORDERABLE ITEM LOOKUP", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2009/06/26", "APPROVED", "Active", "Controlled Subscription", "", "
This API is used to lookup an orderable item IEN from
file 101.43 to match it to a package reference. For instance Pharmacy can use
it to lookup one of their Pharmacy Orderable Items to a 101.43 Orderable Item.\n", "", "ORX8", "2014/09/04"], ["5470", "XUMF MFS EVENTS", "Other", "KERNEL", "2009/07/16", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by the Master File Server
(MFS) mechanism. Actions from any application area that are dependent on this
event may be added to this event upon approval of the DBIC.\n
MFS provides an event point that protocols of domain developers may subscribe.
The following data is provided by MFS that documents changes to records of the
files related to the domain updated:\n
UPDATE\n
^TMP("XUMF EVENT",$J,IFN,"NEW",IEN) -- this is a new record ^TMP("XUMF
EVENT",$J,IFN,"AFTER",IEN) -- updated record (internal format) ^TMP("XUMF
EVENT",$J,IFN,"BEFORE",IEN) -- before image (internal format)\n
STATUS\n
^TMP("XUMF EVENT",$J,IFN,"STATUS",IEN) = Term Status Before ^ Effective
Date/Time Before ^ Term Status After ^ Effective Date/Time After\n
REPLACED BY VHA STANDARD TERM (#99.97)\n
^TMP("XUMF EVENT",$J,IFN,"BEFORE",IEN,"REPLACED BY")=internal value ^TMP("XUMF
EVENT",$J,IFN,"BEFORE",IEN,"INHERITS FROM")=$$RPLCMNT^XTIDTRM ^TMP("XUMF
EVENT",$J,IFN,"AFTER",IEN,"REPLACED BY")=internal value ^TMP("XUMF
EVENT",$J,IFN,"AFTER",IEN,"INHERITS FROM")=$$RPLCMNT^XTIDTRM\n
ERROR\n
^TMP("XUMF EVENT",$J,"ERROR") = Error message ^TMP("XUMF EVENT",$J,"ERROR",1)
= IFN ^ IEN\n
Note:\n
A record updated with same values (overwrite existing values with identical
values) does not create a TMP record.\n
New Record\n
^TMP("XUMF EVENT",$J,"NEW",IFN,IEN) is set equal to NULL The BEFORE and AFTER
nodes are not set.\n
Update\n
The pre-update state of the record is merged into ^TMP("XUMF
EVENT",$J,"BEFORE",IFN,IEN)\n
The post-update state of the record is merged into ^TMP("XUMF
EVENT",$J,"AFTER",IFN,IEN)\n
The NEW node is not set.\n
Examples:\n
GMRV VITAL TYPE (#120.51)\n
NAME: WEIGHT ABBREVIATION: WT
RATE: YES RATE HELP: GMRV-WEIGHT RATE HELP
PCE ABBREVIATION: WT
RATE INPUT TRANSFORM: I '("UNAVAILABLEPASSREFUSED"...\n
Internal\n
^GMRD(120.51,9,0)=WEIGHT^WT^^1^^GMRV-WEIGHT RATE HELP^WT ^GMRD(120.51,9,1)=I
'("UNAVAILABLEPASSREFUSED"...\n
NEW RECORD\n
^TMP("XUMF EVENT",$J,120.51,"NEW",9)=\n
UPDATED RECORD\n
NAME: WEIGHT ABBREVIATION: WT
RATE: YES RATE HELP: GMRV-WEIGHT RATE HELP
PCE ABBREVIATION: WT
RATE INPUT TRANSFORM: I '("UNAVAILABLEPASSREFUSED"... EFFECTIVE DATE/TIME:
JUN 07, 2007@12:01:23
STATUS: ACTIVE
VUID: 4500639 MASTER ENTRY FOR VUID: YES\n
^TMP("XUMF EVENT",$J,120.51,"AFTER ,9,0)=WEIGHT^WT^^1^^GMRV-WEIGHT RATE
HELP^WT^ ^TMP("XUMF EVENT",$J,120.51,"AFTER ,9,1)=I
'("UNAVAILABLEPASSREFUSED"... ^TMP("XUMF EVENT",$J,120.51,"AFTER
,9,"TERMSTATUS",0)=^120.5199DA^1^1 ^TMP("XUMF EVENT",$J,120.51,"AFTER E
,9,"TERMSTATUS",1,0)=3070607.120123^1 ^TMP("XUMF EVENT",$J,120.51,"AFTER
,9,"TERMSTATUS","B",3070607.120123,1)= ^TMP("XUMF EVENT",$J,120.51,"AFTER
,9,"VUID")=4500639^1 ^TMP("XUMF EVENT",$J,120.51,"BEFORE
,9,0)=WEIGHT^WT^^1^^GMRV-WEIGHT RATE HELP^WT ^TMP("XUMF
EVENT",$J,120.51,"BEFORE ,9,1)=I '("UNAVAILABLEPASSREFUSED"...\n\n", "", "", "2011/10/31"], ["5471", "BAR CODE MED ADMIN Option Access", "", "BAR CODE MED ADMIN", "2011/01/26", "", "Withdrawn", "Private", "", "", "", "", ""], ["5472", "NATIONAL DRUG FILE Option Access", "", "NATIONAL DRUG FILE", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5473", "PCE PATIENT CARE ENCOUNTER Option Access", "", "PCE PATIENT CARE ENCOUNTER", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5474", "SCHEDULING Option Access", "", "SCHEDULING", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5475", "MAILMAN Option Access", "", "MAILMAN", "2011/01/26", "", "Withdrawn", "", "", "
The Consolidated Patient Accounts Center (CPAC) has
requested the ability to access data across all VA Medical Center VistA System
by using the telnet feature in CAPRI-Remote. CPAC needs access to the MAILMAN
XMEDITMG option in order to perform its business office functions.", "", "", ""], ["5476", "Withdrawn", "", "TEXT INTEGRATION UTILITIES", "2011/01/26", "", "Withdrawn", "", "", "", "", "", ""], ["5477", "DBIA-5477", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2011/01/28", "APPROVED", "Active", "Private", "", "
RAORDU routine is used as a utility to update a request
status.", "", "RAORDU", "2011/04/27"], ["5478", "LAB CODE MAPPING", "Routine", "AUTOMATED LAB INSTRUMENTS", "2011/01/28", "APPROVED", "Active", "Private", "", "
The routine LA7VHLU6 is used to resolve standardized
codes such as LOINC, SNOMED CT and other code sets when processing HL7
messages to internal data structures within the LAB DATA file (#63) for data
related to Microbiology, Surgical Pathology, Cytology, and Electron
Microscopsy.\n", "", "LA7VHLU6", "2011/03/28"], ["5479", "REGISTRATION OF NEW RAD EXAMS", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2011/01/28", "APPROVED", "Active", "Private", "", "
The routine RAREG1 is used in the registration of new
radiology exams.", "", "RAREG1", "2011/04/25"], ["5480", "HL7 MESSAGE FOR LAB", "Routine", "LAB SERVICE", "2011/01/28", "", "Pending", "Private", "", "
Request a subscription to Lab routine LR7OB1 that
constructs HL7 messages for Lab orders.", "", "LR7OB1", ""], ["5481", "DBIA-5481", "Routine", "LAB SERVICE", "2011/01/28", "", "Withdrawn", "Private", "", "", "", "", ""], ["5482", "DBIA-5482", "Routine", "LAB SERVICE", "2011/01/28", "", "Withdrawn", "Private", "", "", "", "", ""], ["5483", "DBIA-5483", "Routine", "LAB SERVICE", "2011/01/28", "", "Withdrawn", "Private", "", "", "", "LRMIEDZ", ""], ["5484", "DBIA-5484", "Routine", "LAB SERVICE", "2011/01/28", "", "Withdrawn", "Private", "", "", "", "", ""], ["5485", "DISCONTINUE LAB ORDER", "Routine", "LAB SERVICE", "2011/01/28", "APPROVED", "Active", "Private", "", "
Routine LRCENDE1 supports discontinuation of a Lab
order.", "", "LRCENDE1", "2011/04/27"], ["5486", "DBIA-5486", "Routine", "LAB SERVICE", "2011/01/28", "", "Withdrawn", "Private", "", "", "", "", ""], ["5487", "DBIA-5487", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "", ""], ["5488", "DBIA-5488", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRMIEDZ3", ""], ["5489", "DBIA-5489", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRMIUT", ""], ["5490", "DBIA-5490", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRCAPV2", ""], ["5491", "PATIENT RECORD FLAG VARIABLE POINTER", "Routine", "REGISTRATION", "2011/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
Builds and returns a variable pointer to the Patient
Record Flag National or Local files based on the textual flag name.", "", "DGPFAPIU", "2011/06/07"], ["5492", "DBIA-5492", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRVER5", ""], ["5493", "INPATIENT MEDICATIONS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2009/07/23", "APPROVED", "Active", "Controlled Subscription", "", "
Routine ORCD contains CPRS utilities for order dialogs.
Inpatient Medications would like permission to use the PTR, GETDLG, GETDLG1,
and GETORDER utilities.\n", "", "ORCD", "2013/05/09"], ["5494", "ACKQ A&SP STAFF CONVERSION", "Routine", "QUASAR", "2009/08/03", "APPROVED", "Active", "Supported", "", "
These API's facilitate retrieving A&SP Staff file
(#509850.3) information that corelates to the NEW PERSON file (#200).", "", "ACKQUTL4", "2009/08/27"], ["5495", "TIUSCFI API CALLS", "Routine", "TEXT INTEGRATION UTILITIES", "2009/08/06", "", "Pending", "Private", "", "
This ICR documents the API calls in the routine
TIUSCFI.", "", "TIUSCFI", ""], ["5496", "PSSFDBRT", "Routine", "PHARMACY DATA MANAGEMENT", "2009/09/03", "APPROVED", "Active", "Private", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to return a list of possible Medication Routes from First DataBank
(FDB) for a dispense drug.", "", "PSSFDBRT", "2014/06/20"], ["5497", "DBIA 5497", "Routine", "PHARMACY DATA MANAGEMENT", "2009/09/04", "APPROVED", "Active", "Controlled Subscription", "", "
This DBIA provides various components that will be used
for Pharmacy Re-engineering order checking functionality.", "", "PSSDSAPK", "2023/10/30"], ["5498", "ORAREN AUTORENEWAL", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2009/09/18", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this Application Programming Interface
(API) is to provide a mechanism for requesting a renewal of an Outpatient
prescription order from the Computerized Patient Record System (CPRS).", "", "ORAREN", "2023/04/27"], ["5499", "TIU GET PERSONAL PREFERENCES", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2009/09/25", "APPROVED", "Active", "Controlled Subscription", "", "
Add support for Mental Health\n
1796 NAME: TIU GET PERSONAL PREFERENCES
CUSTODIAL PACKAGE: TEXT INTEGRATION UTILITIES Salt Lake City
SUBSCRIBING PACKAGE: FUNCTIONAL INDEPENDENCE
ORDER ENTRY/RESULTS REPORTING
USAGE: Controlled Subscri ENTERED: APR 30,2003
STATUS: Active EXPIRES:
DURATION: VERSION:
DESCRIPTION: TYPE: Remote Procedure
Returns Users personal preferences for TIU in the following format:\n
TIUY = USER [1P] ^ DEFAULT LOCATION [2P] ^ REVIEW SCREEN SORT FIELD [3S] ^
==>REVIEW SCREEN SORT ORDER [4S] ^ DISPLAY MENUS [5S] ^ PATIENT
==>SELECTION PREFERENCE [6S] ^ ASK 'Save changes?' AFTER EDIT [7S]
^
==>ASK SUBJECT FOR PROGRESS NOTES [8S] ^\n
TAG^ROUTINE: GETPREF^TIUSRVR
KEYWORDS:", "TIU GET PERSONAL PREFERENCES", "", "2009/09/25"], ["5500", "TIU REQUIRES COSIGNATURE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2009/09/25", "APPROVED", "Active", "Controlled Subscription", "", "
Add Mental Health as a subscriber to REQCOS^TIUSRVA.", "TIU REQUIRES COSIGNATURE", "", "2009/12/14"], ["5501", "XUS SET VISITOR", "Remote Procedure", "KERNEL", "2009/09/28", "APPROVED", "Active", "Private", "", "
VistA Imaging is requesting permission to use a Kernel
API, SETVISIT^XUSBSE1, to obtain the BSE token.", "XUS SET VISITOR", "", "2010/06/16"], ["5502", "IMAGING BSE", "File", "KERNEL", "2009/09/28", "APPROVED", "Active", "Private", "8994.5", "
Imaging is requesting permission to add four entries
into file 8994.5 to be used by our Imaging applications. The entries will
contain the name of the application, the application code (encrypted,) method
of authentication, and authentication server IP, port, and entry point.", "", "", "2010/06/16"], ["5503", "EDPFMON", "Routine", "EMERGENCY DEPARTMENT", "2009/10/20", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement documents usage of various entry points
in routine EDPFMON.", "", "EDPFMON", "2009/10/20"], ["5504", "DBIA 5504", "Routine", "PHARMACY DATA MANAGEMENT", "2009/10/27", "", "Pending", "Private", "", "
This DBIA provides a component that will be used for
Pharmacy Re-engineering order checking functionality.", "", "PSSDSAPA", ""], ["5505", "OUTPATIENT PHARMACY VDEF EVENTS", "Other", "OUTPATIENT PHARMACY", "2009/11/02", "APPROVED", "Active", "Private", "", "
Outpatient Pharmacy provides access to the subscribing
package to use the following protocols:\n
PSO VDEF RDE O11 OP PHARM PRES VS
PSO VDEF RDS O13 OP PHARM PPAR VS
PSO VDEF RDS O13 OP PHARM PREF VS\n\n\n", "", "", "2009/10/30"], ["5506", "HDIS TEXT FILE DEPLOYMENT MFS INTERFACE", "Routine", "KERNEL", "2009/11/10", "", "Pending", "Supported", "", "
The text file deployment tool will replace the normal
VistA HL7 message processing (on development and test systems only) with a new
front end to feed MFS with HL7 message segments read from a text file.", "", "XUMF1H", ""], ["5507", "VI Imaging Outside ordering", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2009/11/19", "", "Pending", "Private", "75.1", "
VistA Imaging is requesting read and write access to
Radiology file RAD/NUC MED ORDERS (#75.1). The information will be used for
importing images from outside facilities.", "", "", ""], ["5508", "Imaging Outside/import images", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2009/11/20", "", "Pending", "Private", "70", "
VistA Imaging's importing of outside Radiology exams
requires reading Radiology file RAD/NUC MED PATIENT (#70) to obtain an exam
record for attaching the image to the exam.", "", "", ""], ["5509", "HDIS TEXT FILE DEPLOYMENT MD5 CHECKSUM QUERY", "Routine", "KERNEL", "2009/12/03", "", "Pending", "Supported", "", "
The text file deployment tool will call EN^XUMF5I to
calculate the checksum for a STS deployment.", "", "XUMF5I", ""], ["5510", "HDIS TEXT FILE DEPLOYMENT - ENTER PASSWORD", "Routine", "KERNEL", "2009/12/09", "", "Pending", "Supported", "", "
HDIS Text File Deployment Tool needs to enter a
password for an ftp session.", "", "XUS", ""], ["5511", "HDIS - TIU MAPPING EXTRACT 1", "File", "TEXT INTEGRATION UTILITIES", "2009/12/09", "", "Pending", "Supported", "8925.1", "
The HDIS Mapping Validation Server Option needs to
query data in TIU Document Definition file (#8925.1) to use in the Mapping
Validation Logic Field in the HDIS File/Field file (#7115.6).", "", "", ""], ["5512", "HDIS - TIU MAPPING EXTRACT 2", "File", "TEXT INTEGRATION UTILITIES", "2009/12/09", "", "Pending", "Supported", "8926.1", "
The HDIS Mapping Validation Server Option needs to
query data in the TIU VHA ENTERPRISE STANDARD TITLE File (#8926.1) to use in
the Mapping Validation Logic Field in the HDIS File/Field file (#7115.6).", "", "", ""], ["5513", "HDI PATCH 10 PREINSTALL CLEANUP", "File", "LIST MANAGER", "2009/12/10", "", "Pending", "Supported", "409.61", "
The pre-install routine (HDI1010I) deletes all but the
zero node of the List Manager (LM) Templates for the Generic Mapping Tool and
Text File Deployment Tool. This is to overcome a problem in KIDS where LM
templates are not updated when re-installed.", "", "", ""], ["5514", "TIU GET TEMPLATE DATA", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2009/12/10", "", "Pending", "Controlled Subscription", "", "
RPC TIU TEMPLATE GET TEMPLATE returns data on a
specific TIU TEMPLATE. 12/10/09: This RPC will be released in TIU*1*252.", "", "", ""], ["5515", "HTTP Client", "Routine", "TOOLKIT", "2009/12/29", "APPROVED", "Withdrawn", "Supported", "", "
This API provides access to a HTTP client to retrieve
WEB pages.", "", "XTHC10", "2009/12/29"], ["5516", "HTTP client utilities", "Routine", "TOOLKIT", "2009/12/29", "", "Withdrawn", "Supported", "", "
***** Replaced with DBIA $5555.\n
Utility API to help with HTML.", "", "XTHCUTL", "2009/12/29"], ["5517", "GET FDA MEDICATION GUIDE", "Routine", "NATIONAL DRUG FILE", "2010/01/22", "APPROVED", "Active", "Private", "", "
This allows the Outpatient Pharmacy application to
request an FDA Medication Guide to be printed via the JAVA Client.", "", "PSNFDAMG", "2010/01/22"], ["5518", "TIULC EXTRINSIC FUNCTIONS", "Routine", "TEXT INTEGRATION UTILITIES", "2010/02/10", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR describes the extrinsic functions found in the
routine TIULC, which support a variety of useful functions for determining a
document's state, size, checksum, etc.", "", "TIULC", "2010/02/12"], ["5519", "Return a RAD/NUC MED PATIENT file IEN", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2010/02/18", "APPROVED", "Active", "Controlled Subscription", "", "
This is a private integration agreement between VistA
Radiology/Nuclear Medicine and VistA Imaging. Vista Imaging is looking for a
Rad/Nuc Med patient. If that patient exists, return the DFN of the patient.\n
If the patient record does not exist, add (automate the radiology registration
process) the patient record to the RAD/NUC MED PATIENT (#70) file and return
the DFN of the patient.\n
If an error occurs, an error descriptor with a negative value is returned.", "", "RAMAGU04", "2010/02/23"], ["5520", "READ ACCESS TO V SKIN TEST FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2010/02/18", "APPROVED", "Active", "Private", "9000010.12", "
Clinical Case Registries requests access to the V SKIN
TEST file (#9000010.12): Direct global read access to the "C" cross-reference
(PATIENT NAME .02) and FileMan read access to the following fields: SKIN TEST
(.01) VISIT (.03) RESULTS (.04) READING (.05) DATE READ (.06) EVENT DATE AND
TIME (1201) ORDERING PROVIDER (1202) COMMENTS (81101)", "", "", "2010/02/20"], ["5521", "READ ACCESS TO V IMMUNIZATION FILE", "File", "PCE PATIENT CARE ENCOUNTER", "2010/02/18", "APPROVED", "Active", "Private", "9000010.11", "
Clinical Case Registries requests access to the V
IMMUNIZATION file (#9000010.11): Direct global read access to the "C"
cross-reference (PATIENT NAME .02) and FileMan read access to the following
fields: IMMUNIZATION (.01) VISIT (.03) REACTION (.06) CONTRAINDICATED (.07)
EVENT DATE AND TIME (1201) ORDERING PROVIDER (1202) COMMENTS (81101)", "", "", "2010/02/20"], ["5522", "ECAR", "File", "KERNEL", "2010/02/23", "", "Pending", "Private", "200", "", "", "", ""], ["5523", "kjlh", "File", "KERNEL", "2010/02/23", "", "Pending", "Private", "200", "", "", "", ""], ["5524", "CHANGE PACKAGE NAME AND DESCRIPTIONS", "File", "KERNEL", "2010/02/23", "", "Pending", "Controlled Subscription", "9.4", "
ICB (DSIV namespace) and FBCS (DSIF namespace) changed
their package names during the Class I process. The installation of the full
build at existing ICB and FBCS sites (the Class III sites) did not update the
package name. The VA Business office for these products would like the
package name and description fields to more accurately reflect the Class I
information.\n
A pre-install for patch 1 for both of these applications will do a look-up on
the 'C' cross-reference of the PACKAGE file (#9.4) to find the appropriate
entry and change the following fields using Fileman:\n
^DIC(9.4,D0,0)
.01 NAME 0;1 Fileman write
2 SHORT DESCRIPTION 0;3 Fileman write
^DIC(9.4,D0,1,D1,0)
.01 DESCRIPTION WP field Fileman write", "", "", ""], ["5525", "DETERMINE COST OF COPAYMENT", "Routine", "INTEGRATED BILLING", "2010/03/02", "APPROVED", "Retired", "Private", "", "
AR package needs to determine the potential cost of a
copayment bill. This DBIA will allow for lookup of the potential cost/charge.\n", "", "IBAUTL", "2010/03/03"], ["5526", "SPN ACCESS TO MESSAGE FILE (#3.9)", "File", "MAILMAN", "2010/04/06", "APPROVED", "Active", "Private", "3.9", "
The Spinal Cord Dysfunction package (SPN), requests
permission to directly access the global for the Message file (#3.9). This is
for a one-time emergency patch, SPN*2.0*27.\n
The SPN package needs to resend Mailman messages that failed to be delivered
during a several day period in March 2010. Delivery failed because the Austin
Automation Center inadvertently deactivated the domain of the server.\n
The post-install routine SPNP27 will locate the messages by referencing the
Message file at these locations:\n
1) "B" cross-reference 2) first line of the TEXT sub-file (#3.92) 3) "C"
cross-reference ont he RECIPIENT sub-file (#3.91) 4) 0 node of the RECIPIENT
subfile (#3.91)\n", "", "", "2010/04/07"], ["5527", "MEDICAL SPECIALTY file 723", "File", "EVENT CAPTURE", "2010/05/04", "", "Withdrawn", "Private", "723", "
Lab needs to access the MEDICAL SPECIALTY file (#723)
from print and sort templates for extracts to Cerner Lab system.", "", "", ""], ["5528", "ETHNICITY FILE ACCESS", "File", "REGISTRATION", "2010/05/05", "APPROVED", "Active", "Private", "10.2", "
LAB SERVICE package will use the NAME (#.01), HL7 VALUE
(#3) and INACTIVE (#200) fields in Fileman sort and print templates.", "", "", "2010/11/02"], ["5529", "SPN EDITS MAIL GROUP", "File", "MAILMAN", "2010/05/10", "APPROVED", "Active", "Private", "3.8", "
The Spinal Cord Dysfunction package needs to change the
recipient of its HL7 messages that are sent via MailMan. To accomplish that
it needs one-time permission to delete the old Remote Member and add a new
Remote Member of the Mail Group that is used to addres its HL7 messages.
This will be used in patch SPN*2.0*26.\n
The lookp is done via the "B" cross-reference. The adding and deleting of the
remote members are done via Fileman APIs.\n", "", "", "2010/05/10"], ["5530", "READ ACCESS TO COUNTRY CODE FILE", "File", "HEALTH LEVEL SEVEN", "2010/05/12", "APPROVED", "Active", "Controlled Subscription", "779.004", "
LAB SERVICE will use the CODE (#.01) and DESCRIPTION
(#2) fields in Fileman sort and print templates.", "", "", "2010/11/02"], ["5531", "CLINICAL REMINDER ORDER CHECKS", "Routine", "CLINICAL REMINDERS", "2010/05/19", "APPROVED", "Active", "Controlled Subscription", "", "
This provides the Clinical Reminder functionality
needed for reminder order checks.\n", "", "PXRMORCH", "2014/02/27"], ["5532", "XUS GET VISITOR", "Remote Procedure", "KERNEL", "2010/06/04", "APPROVED", "Active", "Private", "", "
VistA Imaging is requesting permission to use a Kernel
API, GETVISIT^XUSBSE1 to verify if a BSE token is still valid.\n", "XUS GET VISITOR", "", "2010/06/16"], ["5533", "ACCESS TO READ FILE #200 ANPI INDEX", "Other", "KERNEL", "2010/06/11", "", "Pending", "Controlled Subscription", "", "
Permission to access the file #200 ANPI index to find
records with NPIs.", "", "", ""], ["5534", "DBIA5534", "Routine", "REGISTRATION", "2010/06/16", "", "Pending", "Private", "", "
DG1 - Diagnosis Information Segment", "", "VAFHLDG1", ""], ["5535", "DBIA5535", "Routine", "REGISTRATION", "2010/06/16", "", "Pending", "Private", "", "
PR1 - Procedure Information Segment", "", "VAFHLPR1", ""], ["5536", "DBIA5536", "Routine", "REGISTRATION", "2010/06/17", "", "Pending", "Private", "", "
ZSC - VA-Specific Stop Code Segment", "", "VAFHLZSC", ""], ["5537", "DBIA5537", "Routine", "REGISTRATION", "2010/06/17", "", "Pending", "Private", "", "
ZEN - VA-Specific Enrollment Segment", "", "VAFHLZEN", ""], ["5538", "DBIA5538", "Routine", "REGISTRATION", "2010/06/17", "", "Pending", "Private", "", "
ROL - Role Segment", "", "VAFHLROL", ""], ["5539", "COTS INV LOG", "Routine", "IFCAP", "2010/06/22", "APPROVED", "Active", "Controlled Subscription", "", "
IFCAP API to log messaging transactions between VistA
and remote COTS Inventory System.", "", "PRCMCM", "2010/06/22"], ["5540", "Point to TIU file 8925.1", "File", "TEXT INTEGRATION UTILITIES", "2010/06/28", "APPROVED", "Active", "Private", "8925.1", "
This agreement permits MENTAL HEALTH file MH TESTS AND
SURVEYS (#601.71) to point to TIU DOCUMENT DEFINITION file 8925.1.", "", "", "2011/02/15"], ["5541", "User Requires Cosignature", "Routine", "TEXT INTEGRATION UTILITIES", "2010/06/28", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement permits packages to determine whether
the author requires a cosignature for a document of a given title.", "", "TIUSRVA", "2011/02/15"], ["5542", "Ward Clerk Menu Access", "Other", "ORDER ENTRY/RESULTS REPORTING", "2010/06/29", "APPROVED", "Active", "Controlled Subscription", "", "
The Ward Clerk Menu [OR MAIN MENU WARD CLERK] will be
added to the HRC Pharmacy Menu [DVBA HRC MENU PHARMACY] option and the new
menu, HRC Pharmacy Customer Care Menu [DVBA HRC MENU PHARMACY CC]. The Ward
Clerk Menu option will be used by the HRC contact representatives and
distributed in patch DVBA*2.7*148. The HRC has provided the following
justification for access to the Ward Clerk Menu option:\n
The request for the VistA option Ward Clerk Menu [OR MAIN MENU WARD CLERK]
will provide additional functionality to flag renewal requests for provider
action. Renewal of prescriptions that have expired or have no refills
remaining constitute 26.1% of the call fielded by the HRC Pharmacy Customer
Care Center (PCCC). This type of call cannot be easily resolved by the
facility pharmacies, because action on the part of the provider is required.
With access to the option, the HRC agent can send a "View Alert" directly to
the provider through VistA. The provider will receive the "View Alert"
immediately upon being flagged by the HRC agent to ensure prompt attention and
resolution of the required prescription renewal. Safeguards are built into the
Ward Clerk version of the VistA option not allowing the HRC PCCC agent to
discontinue, copy, change or renew a prescription without verification by a
facility clinician. CAPRI does recognize credentials so the renewals flagged
by HRC agents would not be processed until signed off by the provider.", "", "", "2010/07/08"], ["5543", "RPC's for NUPA in rtn: NUPABCL", "Remote Procedure", "PATIENT ASSESSMENT DOCUM", "2010/06/30", "", "Pending", "Controlled Subscription", "", "
Contains 11 RPC's which may reference any number of
files in VistA - thus the request for IA's.", "", "", ""], ["5544", "RPC's for NUPA in rtn: NUPABCL1", "Remote Procedure", "PATIENT ASSESSMENT DOCUM", "2010/06/30", "", "Pending", "Controlled Subscription", "", "
Contains 5 RPC's which may reference any number of
files in VistA - thus the request for IA's.", "", "", ""], ["5545", "RPC's for NUPA in rtn: NUPABCL2", "Remote Procedure", "PATIENT ASSESSMENT DOCUM", "2010/06/30", "", "Pending", "Controlled Subscription", "", "
Contains 6 RPC's which may reference any number of
files in VistA - thus the request for IA's.", "", "", ""], ["5546", "TIUCNSLT", "Routine", "TEXT INTEGRATION UTILITIES", "2010/07/07", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement documents and supports the TIUCNSLT
routine entry points listed.", "", "TIUCNSLT", "2011/02/15"], ["5547", "LAB LOINC FILE (#95.3) API(S)", "Routine", "LEXICON UTILITY", "2010/07/23", "", "Pending", "Controlled Subscription", "", "
These API(s) support the custodial transition of the
LAB LOINC file (#95.3) from Legacy LAB to Standards and Terminology Services
(STS). These API(s) provide Read Access to the LAB LOINC file (#95.3) and
should be used when accessing the file. The API(s) support Legacy LAB's
encapsulation efforts and STS's LOINC Deployment efforts.", "", "LEXLR", ""], ["5548", "CALCULATE MESSAGE SIZE", "Routine", "HEALTH LEVEL SEVEN", "2010/07/28", "APPROVED", "Active", "Private", "", "
IFCAP requests private usage of an HL7 API to determine
message size.", "", "HLCSUTL", "2010/08/17"], ["5549", "DBIA5549", "Routine", "ACCOUNTS RECEIVABLE", "2010/08/12", "APPROVED", "Active", "Private", "", "
This agreement allows by the Third Party Joint Inquiry
to display contact information from the AR ERA files and also allows a comment
transaction to be added to the AR bill record if payer contact information is
available for the bill.", "", "RCDPAYER", "2010/09/09"], ["5550", "VALIDATE FIELDS ON DD FOR REGULAR CROSS REFERENCES", "File", "1", "2010/08/16", "", "Other", "Private", "", "
Read-only access for the ^DD( Global\n
Read ^DD(filenum,"IX",fieldnum) to determine whether a field contains a
regular cross reference, to optimize ad hoc searches.", "", "MAGVRS42", "2010/08/17"], ["5551", "RETRIEVE ALL FIELDS IN A FILE", "File", "1", "2010/08/19", "", "Pending", "Private", "", "
Read-only access for the ^DD( global\n
Read ^DD(FN,"B",FLDNAME,FLDN), where FN is a file number, FLDNAME is a field
name, and FLDN is a field number. A function will be created to loop through
^DD(FN,"B",FLDNAME,FLDN) to create a list with all fields in a file.", "", "", ""], ["5552", "IFCAP SET DD NODES DURING POST INSTALL", "File", "1", "2010/08/24", "APPROVED", "Active", "Private", "", "
IFCAP needs to add ID nodes to files 410, 442, and
443.6 in support of patch PRC*5.1*146. As KIDS does not have a mechanism to
transport ID nodes of a files DD without exporting the entire file definition,
it is requested that for this patch IFCAP be permitted to set the ID node via
the post-init routine PRC5146P. The proposed lines of code are as follows
(without blank lines):\n
S ^DD(410,0,"ID","Z3")="D:$P($G(^(14)),U,2)]"""" EN^DDIOL(""Maximo""_$P(^(
14),U,3)_""-""_$P(^(14),U,2),,""?0""),EN^DDIOL("" "",,""!?2"")"\n
S ^DD(410.02,0,"ID","Z2")="D:$P($G(@(DIC_+Y_"",9)"")),U,2)]"""" EN^DDIOL("
"Maximo PR Line# ""_$P(^(9),U,2),,""!"")"\n
S ^DD(442,0,"ID","Z.04")="N PRCZZ S PRCZZ=$$MAX^PRCMOUTL(+Y,442) D:PRCZZ]" """
EN^DDIOL("" ""_PRCZZ,,""?0"")"\n
S ^DD(442.01,0,"ID","Z4")="N PRCZZ S PRCZZ=$$PRLINE^PRCMOUTL(D0,+Y,442) D:
PRCZZ]"""" EN^DDIOL(PRCZZ,,""!,?9"")"\n
S ^DD(443.6,0,"ID","Z.6")="N PRCZZ S PRCZZ=$$MAX^PRCMOUTL(+Y,443.6) D:PRCZ
Z]"""" EN^DDIOL("" ""_PRCZZ,,""?0"")"\n
S ^DD(443.61,0,"ID","Z2")="N PRCZZ S PRCZZ=$$PRLINE^PRCMOUTL(DA(1),+Y,443. 6)
D:PRCZZ]"""" EN^DDIOL(PRCZZ,,""!,?9"")"", "", "", "2010/08/26"], ["5553", "HTTP Client", "Routine", "TOOLKIT", "2010/08/24", "APPROVED", "Active", "Supported", "", "
This is a HTTP/1.1 client that can request a web page
from another system and pass the returned data to the calling routine.\n
It can make both GET and POST requests.", "", "XTHC10", "2015/06/26"], ["5554", "HTTP Client Helper", "Routine", "TOOLKIT", "2010/08/24", "APPROVED", "Active", "Supported", "", "
These are some helper functions for the HTTP/1.1
Client.", "", "XTHCURL", "2015/06/26"], ["5555", "HTTP Client Helper", "Routine", "TOOLKIT", "2010/08/24", "APPROVED", "Active", "Supported", "", "
Helper function for the HTTP/1.1 Client.", "", "XTHCUTL", "2015/06/26"], ["5556", "MAG4 DATA FROM IMPORT QUEUE", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
This call returns the Array of Data from the Import
Queue, given a QUEUE Number. Can be called from Delphi and 'M'.", "MAG4 DATA FROM IMPORT QUEUE", "", ""], ["5557", "MAG4 INDEX GET EVENT", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
This call will return an array of entries from the
IMAGE INDEX FOR PROCEDURE/EVENT (#2005.85) file based on the input parameters
CLS (Class) and SPEC (Specialty/subspecialty). When images are displayed, it
is desirable to limit the list of presented images to only those that are
likely to be relevant in the current context.\n
This procedure accepts an "image category" (either an IEN or the name of a
category) and returns all "image events" that belong to that category.", "", "", ""], ["5558", "MAG4 INDEX GET ORIGIN", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
This call will return an array of the ORIGIN INDEX
(field #45) from the IMAGE (#2005) file. The result array includes all ORIGIN
codes and abbreviations.", "", "", ""], ["5559", "MAG4 INDEX GET SPECIALTY", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
This call will return an array of entries from the
IMAGE INDEX FOR SPECIALTY/SUBSPECIALTY (#2005.84) file based on the input
parameters CLS (Class) and EVENT (Procedure/Event). When images are displayed,
it is desirable to limit the list of presented images to only those that are
likely to be relevant in the current context.\n
This procedure accepts an "image category" (either an IEN or the name of a
category) and returns all "(sub)specialties" that generate images in that
category.", "", "", ""], ["5560", "MAG4 INDEX GET TYPE", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
Used to filter out those image types that belong to a
given image category (Class). When images are displayed, it is desirable to
limit the list of presented images to only those that are likely to be
relevant in the current context.\n
This procedure accepts an "image class" (either an IEN or the name of a class)
and returns all "image types" that belong to that class.", "", "", ""], ["5561", "MAGN PATIENT HAS PHOTO", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
Checks if photo image exists for a patient. Returns 0
if no photo or the date/time (Fileman format) of the most recent photo.", "", "", ""], ["5562", "MAG4 GET SUPPORTED EXTENSIONS", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
Returns a list of supported file extensions used in
Imaging from the IMAGE FILE TYPES (#2005.021) file.", "MAG4 GET SUPPORTED EXTENSIONS", "", ""], ["5563", "MAG3 CPRS TIU NOTE", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
Returns a list of all images for a TIU document.", "MAG3 CPRS TIU NOTE", "", ""], ["5564", "MAGG CAPTURE USERS", "Remote Procedure", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
This call will find users that have captured images in
a date range. The list of users can be filtered by the FLAGS parameter. The
Flags Parameter can contain 'C' for images captured on the Capture Workstation
and/or 'I' for images captured throught the Import API. If the parameter is
null it defaults to 'CI'.", "", "", ""], ["5565", "IMAGING QUEUE STATUS", "Routine", "IMAGING", "2010/08/27", "", "Pending", "Controlled Subscription", "", "
This API will return the imaging queue status based on
a Queue Number or Tracking ID.
S X=$$STATUS^MAGQBUT3(Queue Number)
S X=$$STATUS^MAGQBUT3(Tracking ID)", "", "MAGQBUT3", ""], ["5566", "Registration for FBCNH Reports", "Routine", "FEE BASIS", "2010/08/30", "APPROVED", "Active", "Private", "", "
>The CAPRI application needs access to execute the
following FBCNH components so they can be executed from the CAPRI GUI
application via a DVBA namespace RPC. This Integration Agreement covers the
use of these components. Fee Basis cannot modify these components without
first notifying the CAPRI develoopment team and giving them ample time to make
any necessary changes.", "", "", "2010/10/12"], ["5567", "XPDPROT", "Routine", "KERNEL", "2010/09/01", "APPROVED", "Active", "Supported", "", "
A set of calls and extrinsic functions that can be used
to manage protocols in the PROTOCOL file during a KIDS install.\n", "", "XPDPROT", "2010/11/11"], ["5568", "IMAGE INDEX FOR CLASS file 2005.82", "File", "IMAGING", "2010/09/08", "", "Pending", "Controlled Subscription", "2005.82", "
The MAG4 INDEX GET TYPE remote procedure requires a
Class parameter. The IMAGE INDEX FOR CLASS file (#2005.82) contains the list
of available class types for imaging and will be read using FileMan.\n
^MAG(2005.82,D0,0)
.01 NAME 0;1 Read with Fileman", "", "", ""], ["5569", "HEALTH FACTORS FOR PADP", "File", "PCE PATIENT CARE ENCOUNTER", "2010/09/09", "", "Withdrawn", "Controlled Subscription", "9999999.64", "
As part of my C3-C1 Admission Assesment (PADP), I would
like to add ONS AA* and ONS RA* health factors to the Health Factor file.", "", "", ""], ["5570", "DBIA 5570", "Routine", "PHARMACY DATA MANAGEMENT", "2010/09/14", "APPROVED", "Active", "Controlled Subscription", "", "
This entry point will return the best entry from the
DRUG (#50) File to use for order checks (Drug Interaction, Duplicate Therapy
and Dosing), when there is only a Pharmacy Orderable Item associated with the
medication order. It will consider package, the match to National Drug File,
and whether the matched entry in the VA PRODUCT (#50.68) File has a GCNSEQNO
number.", "", "PSSDSAPM", "2015/06/11"], ["5571", "DBIA5571", "File", "REGISTRATION", "2010/10/21", "", "Pending", "Private", "2", "\n\n
The PATIENT file contains all the patients followed by the medical center/
Outpatient clinic. At a minimum each patient entry must have a NAME, DATE OF
BIRTH and SOCIAL SECURITY NUMBER. This file contains most of the demographic
data for a patient. Single Patient Registration will add/edit a subset of the
fields in the Patient file. A complete list of those fields is provided.\n
With the introduction of Single Patient Registration, Patient records for DOD
personal and recruits will also be added to the VistA Patient File using the
same Single Patient registration RPCs. In addition, VistA patients will be
added to the CHCS Patient File #2.", "", "", ""], ["5572", "IBNCPDPU", "Routine", "INTEGRATED BILLING", "2010/10/25", "APPROVED", "Active", "Private", "", "
This ICR provides access to data located in the GROUP
INSURANCE PLAN file #355.3 that will allow the ECME package to determine the
NCPDP version of a Payer Sheet.", "", "IBNCPDPU", "2011/01/18"], ["5573", "User OK as Certifier for a 1358?", "Routine", "IFCAP", "2010/10/28", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows subscribers to call an API
UOKCERT^PRCEMOA. This API verifies that a person would not violate
segregation of duty when certifying an invoice associated with a 1358
miscellaneous obligation by ensuring that they have not previously acted as a
requestor, approver, or obligator on that 1358.", "", "PRCEMOA", "2011/01/11"], ["5574", "Events (and Actors) for a 1358", "Routine", "IFCAP", "2010/10/28", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement allows subscribers to call an API
$$EV1358^PRCEMOA. This API provides information on the events (initial
obligation and increase/decrease adjustments) and IFCAP actors (requestor,
approving official, obligator) for a specified 1358 miscellaneous obligation.", "", "PRCEMOA", "2011/01/11"], ["5575", "DBIA5575", "File", "E CLAIMS MGMT ENGINE", "2010/11/04", "APPROVED", "Active", "Private", "9002313.19", "
Integrated Billing (IB) is using a FileMan look-up into
the BPS NCPDP PATIENT RELATIONSHIP CODE (#9002313.19) in order to ask the user
to choose a valid ECME Patient Relationship code to perform a NCPDP
Eligibility inquiry.", "", "", "2010/11/12"], ["5576", "BPSNCPD9", "Routine", "E CLAIMS MGMT ENGINE", "2010/11/08", "APPROVED", "Active", "Controlled Subscription", "", "", "", "BPSNCPD9", "2011/09/09"], ["5577", "DBIA-5577", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRVER4", ""], ["5578", "DBIA-5578", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRVERA", ""], ["5579", "OPAI ACCESS TO 52.53", "File", "OUTPATIENT PHARMACY", "2010/11/18", "APPROVED", "Active", "Private", "52.53", "
This ICR grants access to the automated dispensing
devices defined in the PHARMACY AUTOMATED DISPENSING DEVICES file (#52.53).\n", "", "", "2010/11/22"], ["5580", "DSS extract access", "File", "BAR CODE MED ADMIN", "2010/11/18", "", "Pending", "Private", "53.79", "
DSS (ECX) read access to file #53.79", "", "", ""], ["5581", "FEE BASIS VENDOR file #161.2 lookup", "File", "FEE BASIS", "2010/11/04", "", "Withdrawn", "Controlled Subscription", "161.2", "\n\n
The ECME package needs to look up entries and addresses in the FEE BASIS
VENDOR file (#161.2). The lookup is by the "NPI" cross-reference. The
desired fields are all on the zero node.\n
The fields:\n
2 STREET ADDRESS (F), [0;3] 2.5 STREET ADDRESS 2 (F), [0;14] 3
CITY (RF), [0;4] 4 STATE (RP5'), [0;5] 5 ZIP CODE (RFX),
[0;6]\n
This Integration Agreement is to be used to examine the "NPI" cross-reference
and to read the address fields.\n\n", "", "", ""], ["5582", "FILE 411 ACCESS", "File", "IFCAP", "2010/11/18", "APPROVED", "Active", "Controlled Subscription", "411", "
This IA provides read-only access to the ADMIN.
ACTIVITY SITE PARAMETER (#411) file via FileMan for lookups.", "", "", "2011/01/11"], ["5583", "IMAGING LSRP ACCESSSION AREA", "Routine", "LAB SERVICE", "2010/12/08", "", "Pending", "Private", "", "
Imaging is requesting to call routine CAALIST^LRJMAG
for creating a lista of COTS accession area mappings - LRO(68,"ALRJC" TAG:
CAALIST(OUT) INPUT: OUT <by ref> OUTPUT: OUT array. OUT(COTS area) ROUTINE:
LRJMAG
for example: OUT("AU")
OUT("BM")
. . .
OUT("SP")=""", "", "LRJMAG", ""], ["5584", "IMAGING LSRP ACCESSION NUMBER", "Routine", "LAB SERVICE", "2010/12/08", "", "Pending", "Private", "", "
IMAGING is requestin permission to call routine LRJMAG
for the corresponding VistA/COTS Accession number. TAG COTSACC(FALG,ACC)
Returns the corrsponding VistA/VOTS accession # for ACC # passed.
INPUTS: FLAG: 1=VistA to COTS<dflt> LR("ALRJH2"
2=COTS to VistA LR("ALRJH"
ACC: the accession # to lookup
OUTPUT: return the corresponding Accession # For example: S
VAACNUM=$$COTSACC^LRJMAG(2,"523-EM-09-0000001")
.
Imaging team will use the VistA accession # to link the captured image file(s)
with the selected study/patient.", "", "LRJMAG", ""], ["5585", "LOOKUP/READ ACCESS TO FILE #9002313.26", "File", "E CLAIMS MGMT ENGINE", "2010/12/09", "APPROVED", "Active", "Controlled Subscription", "9002313.26", "
Permission to subscriber package to make reference to
this file to perform lookups or read its fields. No write access.\n
Amendment: Effective 5/15/23, added field 2", "", "", "2023/05/15"], ["5586", "IMAGING LAB PATIENT STUDY", "Remote Procedure", "LAB SERVICE", "2010/12/09", "", "Pending", "Private", "", "
Imaging is requesting an RPC or API to get a list of
Lab data from selected VistA patient (DFN) So the image will be captured can
be linked to the LAB study. (Anatomic Pathology only - VI Capture)
.
Input: DFN (VistA patient ID) Output: OUT <array>
OUT(0) = total number of patient LAB study
OUT(no) = Patient name^
patient SSN^
Date - 1st piece of LR(lrdfn,sect,lri,0)^
Accession Number^
Pathologist Name^
Specimen^
Patient ID(DFN)^
Section^
LRDFN^
LRI^ If there is no Lab study, the OUT(0)=0 or -1 (patient
no found) For example: (DFN=1066)\n
D DFN^LRJMAG(.OUT,1066)\n
OUT(0)="3^DATA FOUND" OUT(1)="PATIENT,ONEZEROSIXSIX^000001066^08/21/2001^CY 01
1^UNKNOWN^LUNG^CY^1066^51^6989178^"
OUT(2)="PATIENT,ONEZEROSIXSIX^000001066^08/21/2001^EM 01
1^IMAGPROVIDERTHREEONE,THREEONE^SKIN^EM^1066^51^6989178^"
OUT(3)="PATIENT,ONEZEROSIXSIX^000001066^08/21/2001^SP 01
1^UNKNOWN^LUNG^SP^1066^51^6989178^"\n
(LSRP MAG*3.0*113)", "", "", ""], ["5587", "IMAGING ADD NEW FIELD TO ACTIONS FILE", "File", "KERNEL", "2010/12/09", "", "Pending", "Private", "2005.86", "
IMAGING is requesting permission to add one new field
into file 2005.86 IMAGE ACTIONS FILE - DIVISION The IMAGE ACTIONS file
(#2005.86) will be made division aware. A new multiple filed will be added
that referenced divisions are pointed to INSTITUTION FILE (#4). The "B" cross
reference of the IMAGING SITE PARAMETERS file (#2006.1) will be used to
collect possible divisions for the field value.", "", "", ""], ["5588", "LAB ACCESSIONS BY DOD", "Routine", "LAB SERVICE", "2011/01/31", "APPROVED", "Active", "Private", "", "
The Orders Portability requirement for the Federal
health Care Center at North Chicago requires the ability to handle Lab
accession services.", "", "LRPHITEM", "2011/08/01"], ["5589", "DBIA-5589", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "", ""], ["5590", "LAB ORDER ENTRY FUNCTIONS", "Routine", "LAB SERVICE", "2011/01/31", "APPROVED", "Active", "Private", "", "
Routine LROE1 performs functions related to Order
Entry.", "", "LROE1", "2011/08/01"], ["5591", "DBIA-5591", "Routine", "LAB SERVICE", "2011/01/31", "APPROVED", "Active", "Private", "", "
For the Orders Portability requirement at the Federal
Health Care Center at North Chicago, the JV applications needs the ability to
store an order and accession into the database.", "", "LRFAST", "2011/08/01"], ["5592", "DBIA-5592", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRX", ""], ["5593", "ROUTINE FOR UPDATING FILE 69", "Routine", "LAB SERVICE", "2011/01/31", "APPROVED", "Active", "Private", "", "
These entry points validate and update the contents of
File 69 (Lab Order Entry).", "", "LROW2", "2011/08/01"], ["5594", "DBIA-5594", "Routine", "LAB SERVICE", "2011/01/31", "", "Withdrawn", "Private", "", "", "", "LRCAPV", ""], ["5595", "DBIA-5595", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/01/31", "", "Pending", "Private", "", "
The routine ORWDXA contains a set of utility functions
for handling Orders.", "", "ORWDXA", ""], ["5596", "ACCESS TO ORDER DIALOG UTILITIES", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/01/31", "", "Pending", "Private", "", "
ORWDX is a set of utilities related to Order Dialogs,
which are used in the process of communicating and modifying Order status,
results, and modifications to status.", "", "ORWDX", ""], ["5597", "DPT", "File", "REGISTRATION", "2011/02/04", "APPROVED", "Active", "Controlled Subscription", "2", "
Requesting access to fields in file 2 PATIENT that are
not retrieved with the API VADPT. They reference the cell phone number for the
patient and the work phone numbers for the next of kin and emergency contacts.\n", "", "", ""], ["5598", "NOK WORK TELEPHONES", "File", "REGISTRATION", "2011/02/04", "", "Pending", "Private", "2", "
The following phone numbers are not currently avaialble
through VADPT or other API's. They will need to be retrieved through fileman
calls for usage in report displays.", "", "", ""], ["5599", "REMINDER LOCATION LIST", "File", "CLINICAL REMINDERS", "2011/02/07", "APPROVED", "Active", "Controlled Subscription", "810.9", "
To make it easier for users to run reports for a set of
Clinic Stops, the Scheduling package needs access to the Clinic Stop List
multiple in Reminder Location Lists.\n", "", "", "2011/03/23"], ["5600", "Site specific accession number switch", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/08", "APPROVED", "Active", "Private", "", "
Radiology/Nuclear Medicine is a comprehensive software
package designed to assist with the functions related to the processing of
patients for imaging examinations.", "", "RAHLRU1", "2011/02/10"], ["5601", "MPIUTL11 API FOR BHIE/FHIE", "Routine", "MASTER PATIENT INDEX", "2011/02/09", "APPROVED", "Active", "Private", "", "
The $$ISTF^MPIUTL11(ICN,STA) API returns 1 if the input
ICN has the input facility (STA) as a Treating Facility (#985.5). If the ICN
does not have the facility as a Treating Facility, a zero is returned. This
API is for the exclusive use of BHIE/FHIE only.", "", "MPIUTL11", "2011/04/27"], ["5602", "ACCESS TO RAD/NUC MED PATIENT FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/11", "APPROVED", "Active", "Private", "70", "
RADPT file #70, is the RAD/NUC MED Patient file. In
order to interface the VistA Radiology system with any external system, it is
necessary to be able to read from and write to this file. When external exams
are registered and results are filed entries in this file are made. This file
is one of three primary radiology reference files and is where are patient
related information is stored for radiological exams.", "", "", "2011/08/01"], ["5603", "YS MHAT LOOKUP", "File", "HEALTH LEVEL SEVEN", "2011/02/12", "APPROVED", "Active", "Private", "870", "
The Mental Health package requests permission to do a
FileMan lookup on the HL LOGICAL LINK (#870) file for the YS MHAT entry. We
wish to then do a EN^DIQ call to display the field values for that record. We
do not wish to edit any of the values.\n
Here is our code:\n
CKHL7 ;check hl7 status
N DIC,DA
W @IOF,!?15,"*** HL7 Check ***",!
S X="YS MHAT",DIC=870 D ^DIC
I +Y'>0 W !,"YS MHAT ERROR" Q ;-->out
S DA=+Y D EN^DIQ", "", "", "2011/02/14"], ["5604", "RADIOLOGY ORDER INFORMATION", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/14", "APPROVED", "Active", "Private", "75.1", "
This file contains the Radiology order information.
This is different and contains information not found in the Order file (#100).\n", "", "", "2011/04/25"], ["5605", "ACCESS TO RAD/NUC MED REPORT FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/14", "APPROVED", "Active", "Controlled Subscription", "74", "
Radiology Report file is the location all results,
impressions, and reports associated with a radiology exam are stored.", "", "", "2011/08/16"], ["5606", "RADIOLOGY EXAMINATION STATUS", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/14", "APPROVED", "Active", "Private", "72", "
Examination status for Radiology.", "", "", "2011/04/25"], ["5607", "ACCESS TO RAD/NUC MED PROCEDURE FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/14", "APPROVED", "Active", "Private", "71", "
File 71 is the Rad/Nuc Med Procedure file. It is
necessary for the interface project to be able to reference what procedures
are being requested and the exams status path from registration to completion,
which is referenced in this file.", "", "", "2011/05/09"], ["5608", "ORQQCN1", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/02/15", "APPROVED", "Active", "Private", "", "
The Mental Health package requests permission to call
GETCSLT^ORQQCN1 to retrieve a complete consult record.", "", "ORQQCN1", "2011/03/09"], ["5609", "DBIA-5609", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/15", "APPROVED", "Active", "Private", "78.3", "
This file contains the diagnostic codes that can be
associated with an exam. The code is attached to an exam at the time the
interpreting resident and/or staff physician is entered for the exam. The
diagnostic code represents a quick overall summary of what the interpreting
physician wrote in the report concerning the exam.", "", "", "2011/06/16"], ["5610", "DBIA-5610", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/02/15", "APPROVED", "Active", "Private", "79.1", "
This file contains, for each imaging location entry,
parameters that the module uses during various stages of exam and report
processing and inquiring. The parameter switches allow the 'customizing' of
the module for each location by the package coordinator.\n
The data for the 'IMAGING LOCATIONS' file is stored in the ^RA(79.1, global.
At the present time this file is very static.", "", "", "2011/06/16"], ["5611", "HOSPITAL LOCATION DATA AUDITING", "Other", "REGISTRATION", "2011/02/17", "APPROVED", "Active", "Controlled Subscription", "", "
Applications that need to monitor Medical
Administration changes made to Hospital Location, Ward Location, and Room-Bed
data may do so with subscription to this ICR. This Integration Control
Registration allows the Subscribing packages to turn on Auditing for the
following fields in the indicated file:\n
HOSPITAL LOCATION AUDITING:
FILE: 44
ROOT: SC(
AUDIT GLOBAL REFERENCE:
^SC(D0,0)
.01 NAME 0;1 Fileman Audit allowed
2 TYPE 0;3 Fileman Audit allowed
3 INSTITUTION 0;4 Fileman Audit allowed
3.5 DIVISION 0;15 Fileman Audit allowed\n
^SC(DO,I)
2505 INACTIVATE DATE I;1 Fileman Audit allowed
2506 REACTIVATE DATE I;2 Fileman Audit allowed\n\n
WARD LOCATION AUDITING:
FILE: 42
ROOT: ^DIC(42,
AUDIT GLOBAL REFERENCE:
^DIC(42,D0,0)
.01 NAME 0;1 Fileman Audit allowed
.015 DIVISION 0;11 Fileman Audit allowed\n
^DIC(42,D0,44)
44 HOSPITAL LOCATION FILE POINTER 44;1 Fileman Audit allowed\n\n
ROOM-BED AUDITING:
FILE: 405.4
ROOT: DG(405.4,
AUDIT GLOBAL REFERENCE:
^DG(405.4,D0,0)
.01 NAME 0;1 Fileman Audit allowed\n
ROOT: ^DG(405.4,D0,W,
AUDIT GLOBAL REFERENCE:
^DG(405.4,D0,W,D1,0)
.01 WARD(S) WHICH CAN ASSIGN 0;1 Fileman Audit allowed", "", "", "2011/02/18"], ["5612", "RE-INDEX 'AD' CROSS-REFERENCE ON SECONDARY MENU OPTIONS", "File", "KERNEL", "2011/03/02", "APPROVED", "Active", "Private", "200", "
The Laboratory System Re-engineering Project (LSRP)
Rollback Tool Kit (RTK) has a onetime request to re-index the 'AD'
cross-reference on the SECONDARY MENU OPTIONS field (#203) in the NEW PERSON
file (#200). The re-indexing will take place in the post-init for patch
LR*5.2*393 in routine LR393. The code is as follows:\n
REINDEX ; -- index 'AD' xref on NEW PERSON file
D MES^XPDUTL("Re-indexing 'AD' Cross Reference on SECONDARY MENU
OPTIONS (#203) field")
D MES^XPDUTL("in the NEW PERSON (#200) file...")
N LRDUZ
S LRDUZ=0
F S LRDUZ=$O(^VA(200,LRDUZ)) Q:'LRDUZ D
. N DIK,DA
. Q:'$O(^VA(200,LRDUZ,203,0))
. S DA(1)=LRDUZ,DIK="^VA(200,"_DA(1)_",203,",DIK(1)=".01^AD" D
ENALL^DIK
D MES^XPDUTL("Done re-indexing.")
Q", "", "", "2011/03/07"], ["5613", "XOBDATA RPC CONTEXT VARIABLE", "Other", "VISTALINK", "2011/03/02", "APPROVED", "Active", "Controlled Subscription", "", "
North Chicago (JV package) may access the subscripted
variable XOBDATA("XOB RPC","RPC CONTEXT")) during VistALink RPC execution, to
obtain the "B"-type context option authorizing the execution of the RPC to the
user.\n
This agreement will expire when VistALink is patched to properly set XQY
during RPC execution when the VistALink client is a WebLogic/J2EE server.", "", "", "2011/04/22"], ["5614", "READ/WRITE ACCESS W/FILEMAN TO LOCK FIELD (#3)", "File", "KERNEL", "2011/03/02", "APPROVED", "Active", "Controlled Subscription", "19", "
Additional package(s) have been added to this ICR as
subscribers. The listed packages may use standard FileMan APIs such as
$$GET1^DIQ to read the current value of the NAME and LOCK fields. It may
also be used to delete the current value of the LOCK field from an existing
option during a patch install since KIDS does not provide that capability.
The ICR supports the back-out/rollback process.\n
1) The following FileMan API is used to query for the NAME field (#.01) and
the LOCK field (#3) in the OPTION file (#19):\n
D LIST^DIC(19,"","@;.01I;.01;3I;3","PQ","","","","",LRSCR,"",,"LRMSG")\n
where LRSCR="I ($E(^(0),1,2)=""LA""!($E(^(0),1,2)=""LR""))"\n
2) The following FileMan API is used to update the LOCK field (#3) in the
OPTION file (#19):\n
S LRFDA(19,LROPT_",",3)=LRVALI
D FILE^DIE("","LRFDA","LRMSG")\n
where LROPT is the OPTION file (#19) IEN
LRVALI is the Name of the Key", "", "", "2011/03/07"], ["5615", "READ ACCESS W/FILEMAN TO OPTION SCHEDULING FILE (#19.2)", "File", "KERNEL", "2011/03/07", "APPROVED", "Active", "Private", "19.2", "
The Laboratory System Re-engineering project (LSRP)
Rollback Tool Kit (RTK) uses FileMan API(s) to query information in the OPTION
SCHEDULING file (#19.2) for the Preservation step in the RTK.\n
1) The following FileMan API is used to query for the NAME (#.01), QUEUED TO
RUN AT WHAT TIME (#2), DEVICE FOR QUEUED JOB OUTPUT (#3), QUEUED TO RUN ON
VOLUME SET (#5), RESCHEDULING FREQUENCY (#6), SPECIAL QUEUEING (#9), USER TO
RUN TASK (#11) and TASK PARAMETERS (#15) fields in the OPTION SCHEDULING file
(#19.2):\n
D LIST^DIC(19.2,"",LRFLDS,"PQ","","","","",LRSCR,"",LRQRY,"LRMSG")\n
where LRFLDS="@;.01;2;3;5;6;9;11;15"
LRSCR="N LRX S LRX=$G(^DIC(19,+^(0),0)) I ($E(LRX,1,2)=""LA""!
($E(LRX,1,2)=""LR"")),$E(LRX,1,3)'=""LRJ"",$E(LRX,1,4)
'=""LA7J"""\n
2) The following FileMan API is used to query the OTHER PARAMETERS (#10)
subfile (#19.21) field in the OPTION SCHEDULING file (#19.2):\n
D GETS^DIQ(19.2,LRIEN_",","10*","E","LROTHER","LRMSG")\n
where LRIEN is the OPTION SCHEDULING file (#19.2) IEN\n
3) The following FileMan API(s) are used to look-up and display an entry in
the OPTION SCHEDULING file (#19.2):\n
S DA=+$$FIND1^DIC(19.2,"","XQ",LROPTI,"B","","LRERR")
I 'DA Q
S DIC="^DIC(19.2,"
S DIQ(0)=""
D EN^DIQ\n
where LROPTI is the OPTION file (#19) IEN", "", "", "2011/03/08"], ["5616", "ADT/HL7 PIVOT FILE IEN", "File", "REGISTRATION", "2011/03/21", "APPROVED", "Active", "Private", "391.71", "
Lab Service is allowed Fileman Read access to return
the ADT/HL7 Pivot IEN via the "D" cross reference.", "", "", "2011/03/21"], ["5617", "PSSDSAPD Duration", "Routine", "PHARMACY DATA MANAGEMENT", "2011/03/21", "APPROVED", "Active", "Private", "", "
This DBIA returns the number of minutes to the calling
application based on the duration passed in.", "", "PSSDSAPD", "2018/05/29"], ["5618", "GIVE THIS DBIA A BETTER NAME THAN DBIA5618", "", "", "2011/03/24", "", "Pending", "", "", "", "", "", ""], ["5619", "PROJECT ARCH", "Routine", "FEE BASIS", "2011/03/24", "APPROVED", "Active", "Private", "", "\n\n
This Integration agreement provides two functions. The output data comes from
the ARCH ELIGIBILITY multiple from Fee Basis Patient file #161.\n
$$ELIG^FBARCH0 - lists the ARCH (Access Received Closer to Home) eligibility
for a patient on a specific date range.\n
$$LIST^FBARCH0 - provides a list of ARCH eligible patients on a specific date
range.", "", "FBARCH0", "2011/06/06"], ["5620", "JV APPLIC ACCESS TO LAB 60 FILE", "File", "LAB SERVICE", "2011/03/29", "APPROVED", "Active", "Private", "60", "
The JV application (James A Lovell Federal Health Care
Center) requests access to file LAB(60 which holds the names and ordering and
display of tests.", "", "", "2011/04/07"], ["5621", "DBIA-5621", "File", "LAB SERVICE", "2011/03/30", "", "Withdrawn", "Private", "69.9", "
This file holds specific information which defines
certain site parameters relating to the actual functioning of your laboratory.", "", "", ""], ["5622", "DBIA-5622", "File", "LAB SERVICE", "2011/03/31", "", "Pending", "Private", "63", "
The Federal Health Care Center project requires access
to Lab Service File LR(63 - Lab Data File - for its Orders Portability
requirement.", "", "", ""], ["5623", "NHIN GET VISTA DATA", "Remote Procedure", "NATIONAL HEALTH INFO NETWORK", "2011/03/31", "", "Retired", "Controlled Subscription", "", "
This RPC pulls data from VistA and returns it in an
array formatted as XML.", "", "", ""], ["5624", "DBIA-5624", "File", "LAB SERVICE", "2011/04/04", "", "Pending", "Private", "68", "
For its Orders Portability requirement, the JV
application (Federal Health Care Center in North Chicago) request permission
to access file (LRO(68. This file contains entries which represent the
functional subdivisions or departments of the laboratory, referred to by the
Laboratory package software as accession areas.", "", "", ""], ["5625", "DBIA-5625", "File", "LAB SERVICE", "2011/04/05", "", "Pending", "Private", "69", "
This IA documents access by the JV application, the
Federal Health Care Center at North Chicago for the Orders Portability
requirement, to the Lab Order Entry file (69), which contains data pertinent
to Lab tests ordered for VA patients.", "", "", ""], ["5626", "LAB COLLECTION SAMPLE", "File", "LAB SERVICE", "2011/04/06", "APPROVED", "Active", "Private", "62", "
The Lab Collection Sample file (62) contains
information about collection samples for lab tests.", "", "", "2011/04/27"], ["5627", "Patient File POW field (#.525)", "File", "REGISTRATION", "2011/04/15", "APPROVED", "Active", "Private", "2", "
Lab is granted read access to the Patient File (#2) POW
STATUS INDICATED? field (#.525).\n
ADT generates HL7 1.6 messages containing Patient Movement information. LSRP
converts the HL7 1.6 ADT messages into HLO formatted messages and forwards
them to Pathnet. Not all ADT A11 (Cancel Patient Admit) ZPD segments have the
POW STATUS INDICATED? data populated. When LSRP receives an ADT A11 message
with a ZPD-17 (POW STATUS INDICATED?) containing a NULL value, POW STATUS
INDICATED? is added to the HLO message during the HL7 1.6 to HLO conversion.\n", "", "", "2011/05/03"], ["5628", "CHECK FOR MAGDISP CLIN KEY", "File", "IMAGING", "2011/04/15", "APPROVED", "Active", "Private", "", "
This ICR allows the subscribing package(s) to check for
the MAGDISP CLIN key using the ^XUSEC global. Reference ICR 10076 for more
information on the XUSEC global.", "", "", "2011/05/03"], ["5629", "ORKPS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/04/19", "", "Pending", "Supported", "", "
The agreement is for using the GLCREAT entry point in
the ORKPS routine to return the CRCL value of a patient.", "", "ORKPS", ""], ["5630", "DETERMINE IF A CLAIN IS A NON-ACCRUED ACCOUNT", "Routine", "ACCOUNTS RECEIVABLE", "2011/04/19", "APPROVED", "Active", "Private", "", "
Integrated Billing has permission to make the following
call to AR to determine if a claim is a non-accrued account: $ACCK^PRCAACC.
When the user is attempting to use the IB option: [IB CORRECT
REJECTED/DENIED], if the claim is non-accrued ('$$ACCK^PRCAACC(IBIFN)), the
user will be prevented from using the option and directed instead to IB
option: [IB COPY AND CANCEL].", "", "PRCAACC", "2011/04/19"], ["5631", "DSICXIP ZIP CODE", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/04/26", "", "Withdrawn", "Private", "", "", "", "", ""], ["5632", "HL7 APPLICATION PARAMETER LOOKUP .01", "File", "HEALTH LEVEL SEVEN", "2008/01/08", "APPROVED", "Active", "Private", "771", "
ALLOWS RADIOLOGY TO READ THE .01 FILED OF THE HL7
APPLICATION PARAMETER FILE", "", "", ""], ["5633", "FEE BASIS INVOICE", "File", "FEE BASIS", "2011/04/28", "APPROVED", "Active", "Private", "162.5", "
CCR needs read-only access to fields in the FEE BASIS
INVOICE file #162.5.", "", "", "2011/05/03"], ["5634", "FEE BASIS PHARMACY INVOICE", "File", "FEE BASIS", "2011/04/28", "APPROVED", "Active", "Private", "162.1", "
CCR needs read-only access to the FEE BASIS PHARMACY
INVOICE file #162.1.", "", "", "2011/05/03"], ["5635", "FEE BASIS PAYMENT", "File", "FEE BASIS", "2011/04/28", "APPROVED", "Active", "Private", "162", "
CCR needs read-only access to all fields in the FEE
BASIS PAYMENT file #162.", "", "", "2011/04/28"], ["5636", "CPRS ARRAY", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/04/28", "", "Pending", "Private", "", "
Routine ORCD contains CPRS utilities for order dialogs.
The JV application (James A Lovell Federal Health Care Center in North
Chicago) requests permission to use the GETDLG utility.", "", "ORCD", ""], ["5637", "ORDER CHECK API", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Controlled Subscription", "", "
The OROCAPI1 routine contains APIs that applications
can use to add and read order checking information.", "", "OROCAPI1", "2011/05/04"], ["5638", "ORWU HAS OPTION ACCESS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "", "Pending", "Private", "", "", "ORWU HAS OPTION ACCESS", "", ""], ["5639", "ORWU1 NEWLOC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Controlled Subscription", "", "
Returns a list of Clinics, Wards, and "Other" category
entries from the HOSPITAL LOCATION (#44) file.\n
Input:
ORFROM [optional] = Text to $O from or passed in an external value
of the name from the HOSPITAL LOCATION FILE #44,.01
DIR [required] = $Order direction or the collating sequence,
where, it must be 1 or -1
1 = return the return list(s) in next order
-1 = return the return list(s) in reverse order\n
Output:
Y(n)=DATA delimited by "^" where n=1,2,3,4,. .\n
Return Parameter Description
If successful:
Y(n)=p1^p2\n
Where:
p1 := IEN from Hospital Location file#44
p2 := Location name-the external value from file #44,.01", "ORWU1 NEWLOC", "", "2014/04/07"], ["5640", "ORWORR GETBYIFN", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "", "Pending", "Private", "", "", "ORWORR GETBYIFN", "", ""], ["5641", "ORWOR RESULT HISTORY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Private", "", "\n
**NOTE: This ICR is for JAL and Mobile Scheduling Application
Suite only.", "ORWOR RESULT HISTORY", "", "2017/02/21"], ["5642", "ORWOR RESULT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWOR RESULT", "", "2017/02/14"], ["5643", "ORWDXR GTORITM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "", "Pending", "Private", "", "", "ORWDXR GTORITM", "", ""], ["5644", "ORWDX ORDITM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Private", "", "\n
**NOTE: This ICR is for JAL and Mobile Scheduling Application Suite
only.", "ORWDX ORDITM", "", "2017/02/21"], ["5645", "ORWDX DLGDEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Private", "", "\n
**NOTE: This ICR is for JAL and Mobile Scheduling Application
Suite only.", "ORWDX DLGDEF", "", "2017/02/21"], ["5646", "ORWDXC DELORD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "", "Pending", "Private", "", "", "ORWDXC DELORD", "", ""], ["5647", "ORWDXA VALID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Controlled Subscription", "", "
Returns an error message if the selected action is not
valid for a particular CPRS GUI order.\n
OUTPUT: SINGLE VALUE
Returns an error message if the selected action is not valid for a
particular CPRS GUI order.\n
INPUT:
ORID [REQUIRED] - INTERNAL ENTRY NUMBER FOR THE ORDER file (#100)\n
ACTION [REQUIRED] - CODE REPRESENTING TYPE OF ACTION TAKEN ON THE ORDER
WHEN IN CPRS
"XFR" == TRANSFER ORDER TO INPATIENT/OUTPATIENT
"RW" == REWRITE/COPY ORDER
"RN" == RENEW ORDER
"XX" == EDIT/CHANGE ORDER
"VR" == VERIFY ORDER
"RF" == REFILL ORDER
"CP" == COMPLETE ORDER
"AL" == FLAG ORDER
"HD" == HOLD ORDER
"NW" == NEW ORDER
"DC" == DISCONTINUE ORDER
"RL" == RELEASE HOLD ON ORDER\n
DUZ [REQUIRED] - NEW PERSON file (#200) IEN (user performing the
action)\n
NATURE OF ORDER [OPTIONAL] - CODE REPRESENTING HOW THE ORDER WAS ENTERED
"W" == WRITTEN
"V" == VERBAL
"P" == TELEPHONED
"S" == SERVICE CORRECTION
"I" == POLICY
"D" == DUPLICATE
"X" == REJECTED
"E" == ELECTRONICALLY ENTERED
"A" == AUTO
"C" == CHANGED
"M" == MAINTENANCE
"R" == REJECTED BY SERVICE", "ORWDXA VALID", "", "2017/02/13"], ["5648", "ORWDXA HOLD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "", "Pending", "Private", "", "", "ORWDXA HOLD", "", ""], ["5649", "ORWDXA DC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Private", "", "\n
**NOTE: This ICR is for JAL and Mobile Scheduling Application
Suite only.", "ORWDXA DC", "", "2017/02/22"], ["5650", "ORWDLR32 DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "", "Pending", "Private", "", "", "ORWDLR32 DEF", "", ""], ["5651", "ORWDLR32 ALLSAMP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "", "Pending", "Private", "", "", "ORWDLR32 ALLSAMP", "", ""], ["5652", "ORWDAL32 SAVE ALLERGY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/02", "APPROVED", "Active", "Private", "", "", "ORWDAL32 SAVE ALLERGY", "", "2016/11/10"], ["5653", "RETURN CPRS ORDER CHECKS AND OVERRIDES TO BCMA", "Routine", "INPATIENT MEDICATIONS", "2011/05/02", "APPROVED", "Active", "Private", "", "
The entry point GETPROVL^PSGSICH1 is provided by
Inpatient Medications package to return CPRS order checks and provider
override reason to Bar Code Medication Administration to be used by
administering nurses when administering medications at patient's bedside.", "", "PSGSICH1", "2018/04/02"], ["5654", "INPATIENT INTERVENTIONS TO BCMA", "Routine", "INPATIENT MEDICATIONS", "2011/05/02", "APPROVED", "Active", "Private", "", "
Return Pharmacy Intervention information, from the APSP
INTERVENTION (#9009032.4) file, for Pharmacy Interventions associated with a
specific Inpatient order.", "", "PSGSICH1", "2018/04/02"], ["5655", "ORQOR DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/03", "APPROVED", "Active", "Private", "", "\n
**NOTE: This ICR is for HMP, JAL and Mobile Scheduling Application
Suite only.", "ORQOR DETAIL", "", "2016/11/10"], ["5656", "ORWDX SEND", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/03", "APPROVED", "Active", "Private", "", "", "ORWDX SEND", "", "2015/02/10"], ["5657", "ORWDX SAVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/05/03", "", "Pending", "Private", "", "", "ORWDX SAVE", "", ""], ["5658", "DETERMINE LOGICAL LINK BASED ON DNS DOMAIN STRING", "File", "HEALTH LEVEL SEVEN", "2011/05/03", "", "Pending", "Private", "870", "
The VistA Health Level Seven application grants
permission to the VistA Radiology/Nuclear Medicine application to reference a
cross reference tied to a specific NODE (#.01) record filed in the HL LOGICAL
LINK (#870) file.\n
cross reference: ^HLCS(870,"AD",<LLP TYPE>,<DNS DOMAIN>,<NODE>)=""\n
LLP TYPE will always be "TCP". DNS DOMAIN is derived from the third component
of the Sending Facility (MSH-4) field of the MSH segment.\n
There is one NODE record for each unique DNS DOMAIN value.", "", "", ""], ["5659", "VA FORM 10-7078 #162.4", "File", "FEE BASIS", "2011/05/05", "APPROVED", "Active", "Private", "162.4", "
CCR needs FileMan read-only access to fields in the VA
FORM 10-7078 file #162.4.", "", "", "2011/05/09"], ["5660", "DSIC DDR GETS ENTRY DATA", "Remote Procedure", "RPC BROKER", "2011/05/06", "APPROVED", "Active", "Private", "", "
This is the Broker RPC that is called to request that a
RPC be run on a remote system. The data is passed by HL7 to the remote system
as is the return value. The difference between this and the XWB REMOTE RPC is
this is a blocking call meaning the user's workstation will not process
anything else until the data returns from the remote system.", "DSIC DDR GETS ENTRY DATA", "", "2011/06/02"], ["5661", "UPDATE RAD EXAM STATUS/ACTIVITY LOG", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2011/05/10", "APPROVED", "Active", "Private", "", "
The JV application, Federal Health Care Center at North
Chicago, requires an interface to legacy Radiology for the purpose of updating
the Radiology exam status and activity log in its Orders Portability
requirement.", "", "RADD3", "2011/08/01"], ["5662", "RADIOLOGY FILM SIZES FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/05/10", "APPROVED", "Active", "Private", "78.4", "
This file contains the allowable film sizes that the
technologist can choose from when entering film data for an exam. Entries in
this file should not be deleted.", "", "", "2011/06/07"], ["5663", "REFERENCE TO CAMERA/EQUIP/RM FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/05/10", "APPROVED", "Active", "Private", "78.6", "
This file contains all the camera/equip/rm that may be
used to perform imaging examinations.", "", "", "2011/06/07"], ["5664", "REFERENCE TO PROCEDURE MODIFIERS FILE", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2011/05/10", "APPROVED", "Active", "Private", "71.2", "
This file contains the modifiers that can be associated
with an imaging exam. These modifiers are used to further describe the
procedure associated with the exam.", "", "", "2011/06/07"], ["5665", "DSIC DDR DELETE ENTRY", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Withdrawn", "Private", "", "", "", "", ""], ["5666", "DSIC DDR GETS ENTRY DATA", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Pending", "Private", "", "
This RPC calls GETS^DIQ to get a list of field values
for a record.", "", "", ""], ["5667", "DSIC DDR UPDATE SUBFILE", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Withdrawn", "Private", "", "", "", "", ""], ["5668", "DSIC FM FILER", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Pending", "Private", "", "
This RPC invokes the FileMan filer to update records
for an existing entry. This will allow you to update any field at the level
of the FILE including word processing fields. It does not allow for updating
different levels of the file. If you wish to update a subfile, then you will
have to make multiple calls to this RPC for each file or subfile.", "", "", ""], ["5669", "DSIC FM FIND", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Pending", "Private", "", "
This RPC provides a wrapper around the FIND^DIC API.
It exposes more of the functionality of the API to the RPC than the old DSIC
DDR FINDER RPC.\n
For a lookup value, this RPC will return all matches. It allows for input a
multiple screening logic which would be ANDed together.", "DSIC FM FIND", "", ""], ["5670", "DSIC FM LIST", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Pending", "Private", "", "
The RPC provides a wrapper around the LIST^DIC API. It
exposes more of the functionality of the API than the DSIC DDR LISTER RPC.\n
For a lookup value, return all entries starting from that lookup value and
which collates after that lookup value.", "DSIC FM LIST", "", ""], ["5671", "COPY FUNCTIONS FOR IB EOB FILE #361.1", "Routine", "INTEGRATED BILLING", "2011/05/11", "APPROVED", "Active", "Private", "", "
File 361.1 EXPLANATION OF BENEFITS is shared by
Accounts Receivable and Integrated Billing. A/R already has full read access
to the data in this file and options to add new entries.\n
The additional functions defined below are required to allow AR to MOVE COPY,
REMOVE or RESTORE erroneous entries in File 361.1 and update audit trail
fields.", "", "IBCEOB4", "2011/05/17"], ["5672", "DSIC XIP", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Pending", "Private", "", "
This RPC returns address demographics for a 5 or 9
digit zip code\n
The return value is for the primary location associated with the ZIP code.
if an error: -1 ^ ERROR MESSAGE
if OK: Input ZIP code ^ city ^ state ^ county ^ FIPS county code
the return is for the primary location associated with the ZIP code.", "DSIC XIP", "", ""], ["5673", "DSIC XUTIL NAME COMPONENT", "Remote Procedure", "VA CERTIFIED COMPONENTS - DSSI", "2011/05/11", "", "Pending", "Private", "", "
This RPC will take a standard VistA person name in the
format Last,First M and return the individual name components.", "", "", ""], ["5674", "CONSULT UTILITY CALLS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/05/11", "", "Pending", "Private", "", "
The routine contains multiple entry points for consults
utilities.", "", "ORWDCN32", ""], ["5675", "SURGERY FILE DATA", "File", "SURGERY", "2011/05/24", "APPROVED", "Active", "Private", "130", "
This agreement documents additional fields read from
the Surgery file #130 that are not returned by other SR api's.\n
Amended in August 2022: Added fields .04,.164,.205,.232,15, 39, 100,121-125
effective with patch VPR*1*30.", "", "", "2022/08/26"], ["5676", "TIUSROI", "Routine", "TEXT INTEGRATION UTILITIES", "2011/05/24", "APPROVED", "Active", "Private", "", "
This agreement documents and supports the TIUSROI
routine entry points listed.", "", "TIUSROI", "2013/08/02"], ["5677", "TIU NATIONAL TITLE LINK", "File", "TEXT INTEGRATION UTILITIES", "2011/05/24", "APPROVED", "Active", "Private", "8925.1", "
The Virtual Patient Record (VPR) needs the Document
Definitions to accurately apply ASU business rules in the Health Management
Platform (HMP) client, and filter documents based on their VHA ENTERPRISE
STANDARD TITLE attributes.", "", "", "2013/08/05"], ["5678", "TIU NATIONAL TITLES", "File", "TEXT INTEGRATION UTILITIES", "2011/05/24", "APPROVED", "Active", "Private", "8926.1", "
This agreement documents and supports read access via
FileMan to the TIU VHA ENTERPRISE STANDARD TITLE file #8926.1.", "", "", "2013/08/05"], ["5679", "LEXU (ICD-10 UPDATE)", "Routine", "LEXICON UTILITY", "2011/06/03", "APPROVED", "Active", "Supported", "", "
This is an addendum to ICR 1573 and contains functions
added to LEXU during the implementation of ICD-10 Coding system. The APIs in
this ICR become effective on the date of release of patches ICD*18.0*57 and
LEX*2.0*80.\n", "", "LEXU", "2014/07/11"], ["5680", "LEXCODE Expression", "Routine", "LEXICON UTILITY", "2011/06/03", "APPROVED", "Active", "Supported", "", "
This is an addendum to ICR 1614 and contains functions
added to LEXCODE during the implementation of ICD-10 Coding system. The API
in this ICR becomes effective on the date of release of patches ICD*18.0*57
and LEX*2.0*80.\n", "", "LEXCODE", "2014/07/11"], ["5681", "LEX10CS", "Routine", "LEXICON UTILITY", "2011/06/06", "APPROVED", "Active", "Supported", "", "
Supported APIs for the implementation of ICD-10. The
APIs in this ICR become effective on the date of release of patches
ICD*18.0*57 and LEX*2.0*80.\n", "", "LEX10CS", "2014/07/11"], ["5682", "ICD10DX", "File", "DRG GROUPER", "2011/06/07", "", "Withdrawn", "Private", "8010", "
File 8010, global ^ICD10DX, was created to store ICD-10
diagnosis under the two file solution. The two file solution had the ICD-9
codes and ICD-10 codes stored in two separate files. This solution was
abandoned in favor of the one file solution where both ICD-9 and ICD-10 are
stored in the same file (ICD Diagnosis file 80). File 8010 will not be
exported. This ICR is not used.\n", "", "", ""], ["5683", "ICD10PR", "File", "DRG GROUPER", "2011/06/07", "", "Withdrawn", "Private", "8010.1", "
File 8010.1, global ^ICD10PR, was created to store
ICD-10 procedures under the two file solution. The two file solution had the
ICD-9 codes and ICD-10 codes stored in two separate files. This solution was
abandoned in favor of the one file solution where both ICD-9 and ICD-10 are
stored in the same file (ICD Diagnosis file 80). File 8010 will not be
exported. This ICR is not used.\n", "", "", ""], ["5684", "ICDXCD", "Routine", "DRG GROUPER", "2011/06/08", "", "Withdrawn", "Private", "", "
Routine ICDXCD was developed to replace ICDCODE during
the ICD-10 project to navigate between the ICD-9 Diagnosis file 80 and the
ICD-10 Diagnosis file 8010 under the two file solution. The two file solution
had the ICD-9 codes and ICD-10 codes stored in two separate files. This
solution was abandoned in favor of the one file solution where both ICD-9 and
ICD-10 are stored in the same file (ICD Diagnosis file 80). Routine ICDXCD
was abandoned and never exported to test sites, and will not be released to
the field. This ICR is not used.\n", "", "ICDXCD", ""], ["5685", "ICDXAU", "Routine", "DRG GROUPER", "2011/06/08", "", "Withdrawn", "Private", "", "
Routine ICDXAU was developed to replace ICDAPIU during
the ICD-10 project to navigate between the ICD-9 Diagnosis file 80 and the
ICD-10 Diagnosis file 8010 under the two file solution. The two file solution
had the ICD-9 codes and ICD-10 codes stored in two separate files. This
solution was abandoned in favor of the one file solution where both ICD-9 and
ICD-10 are stored in the same file (ICD Diagnosis file 80). Routine ICDXAU
was abandoned and never exported to test sites, and will not be released to
the field. This ICR is not used.\n", "", "ICDXAU", ""], ["5686", "ICDXLK Special Lookup", "Routine", "DRG GROUPER", "2011/06/08", "", "Withdrawn", "Private", "", "
Routine ICDXLK was developed to replace as a special
lookup routine during the ICD-10 project to navigate between the ICD-9
Diagnosis file 80 and the ICD-10 Diagnosis file 8010 under the two file
solution. The two file solution had the ICD-9 codes and ICD-10 codes stored
in two separate files. This solution was abandoned in favor of the one file
solution where both ICD-9 and ICD-10 are stored in the same file (ICD
Diagnosis file 80). A special lookup routine ICDEXLK was written to navigate
between the two code sets in the same file. Routine ICDXLK was abandoned and
never exported to test sites, and will not be released to the field. This ICR
is not used.\n", "", "ICDXLK", ""], ["5687", "Transport of Reminder Exchange File Entries", "File", "CLINICAL REMINDERS", "2011/06/17", "APPROVED", "Active", "Controlled Subscription", "811.8", "
The subscribing packages are allowed to use a KIDS
build to transport Reminder Exchange File entries. This works in conjunction
with ICR #4371 which covers the Reminder Exchange APIs that are used to
include the Reminder Exchange file entries in the KIDS build and install them
during the post-init.\n\n\n", "", "", "2015/01/14"], ["5688", "USE XTMP GLOBAL DURING KIDS INSTALL PROCESS", "File", "KERNEL", "2011/06/22", "APPROVED", "Active", "Private", "", "
The AMIE package has a requirement to version control
new CAPRI TEMPLATE DEFINITIONS (#396.18) file entries when installing a patch.
Each test patch install has a different version control number appended to
the exported entries (e.g. ~###T1 for patch ### test version 1) versus the
released patch (e.g. ~### for released patch ###). Currently the developers
code this in the Pre/Post Init Routine and update it for each test version
that is done. After the final test version is signed off by test sites the
Pre/Post Init Routine is appropriately updated to remove the "T#" text.\n
Using KERNEL data that is already available within the KIDS installation
process, the AMIE developers will be able to provide appropriate version
control of CAPRI TEMPLATE DEFINITION file entries without editing the Pre/Post
Init Routine for each new test and the final released patch version.\n
When patch XU*8*559 is released it will define two supported variables for
this purpose: XPDNM("TST")=test number and XPDNM("SEQ")=sequence number.
Until this patch is released the AMIE team request the ability to utilize the
following global created in the KERNEL KIDS process which is present during
the pre and post install process:
^XTMP("XPDI",XPDA,"BLD",XPDBLD,6)=test number^sequence number.\n
AMIE Pre/Post Init Routines will check if the above mentioned ^XTMP global
exists and if it does use the test number or sequence number for its version
control requirement. Please note that once the patch is installed the Pre/Post
Init Routine is deleted from the system.\n
This ICR needs to be in place until patch XU*8*559 has been nationally
released and installed at all Medical Centers.", "", "", "2011/06/28"], ["5689", "RADIOLOGY PROTOCOLS", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "2011/06/22", "", "Pending", "Private", "", "
The JV application (James A Lovell Federal Health Care
Center in North Chicago) is requesting the usage of legacy Radiology event
driver protocols in support of its Radiology Orders Portability requirement.", "", "", ""], ["5690", "Access to GMR ALLERGIES file (#120.82)", "File", "ADVERSE REACTION TRACKING", "2011/06/22", "APPROVED", "Active", "Private", "120.82", "
This DBIA allows Outpatient Pharmacy package to
directly read from the VA DRUG CLASSES (#5) multiple.", "", "", "2011/06/23"], ["5691", "IDENTIFY CLINIC ORDERS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/06/24", "", "Withdrawn", "Controlled Subscription", "", "
The purpose of this API call is to allow the calling
package to identify if an order is a clinic order.", "", "ORUTL1", "2012/09/27"], ["5692", "FIX TO OVERLENGTH NODE IN FILE 162", "File", "1", "2011/06/30", "", "Withdrawn", "Private", "162.03", "
In 2004 a change was made to the FEE BASIS PAYMENT file
(#162) which caused
the node ^FBAAC(D3,1,D2,1,D1,1,DA,0) to exceed the maximum length allowed
by the SACC.\n
The Fee Basis patch FB*3.5*108 will also need to make changes to the Fee BASIS
PAYMENT file (#162). These changes cannot be made with the node in its
current length.\n
During the pre-install for patch FB*3.5*108 the pre-install routine needs to
make changes to the DD global to move 3 fields from the 0 node to the 2 node
in order to make the 0 node of such a length the required changes can be made.\n", "", "", ""], ["5693", "VEIL CPRS ORDER", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/07/06", "APPROVED", "Active", "Private", "", "
This API will allow Lab to veil/unveil an order in
CPRS.\n
This API should ONLY be used if it is necessary to perform rollback for the
Lab Re-engineering Project that is, as of February 15, 2013, only installed at
the Huntington, WV, site.", "", "ORUTL2", "2013/02/20"], ["5694", "Create & Maintain Links in HL LOGICAL LINK file (#870)", "File", "HEALTH LEVEL SEVEN", "2011/07/13", "APPROVED", "Active", "Private", "870", "
The LSRP software creates and configures 3 new outbound
links to the Cerner PathNet LIMS system.\n
LA7JAPHX - Used for Anatomic Pathology History
LA7JMFN - Used for Master File Notifications
LA7JPNET - Used for Admissions, Discharge & Transfers\n
During this initialization process and as part of the ongoing LSRP
maintenance, the software will perform FileMan B cross reference lookups and
allows for editing fields in the HL7 LOGICAL LINK File (#870).\n
The initial configuration of these links is addressed via FileMan calls during
the post installation process. All subsequent updates to any field in #870
are handled via the use of the [HL7 LOGICAL LINK] ScreenMan form and calls to
^DDS which is supported by ICR #10031.\n
LSRP is requesting permission to update the following list of fields during
the post installation process via FileMan and all fields in #870 via the use
of the existing [HL7 LOGICAL LINK] form.\n
GLOBAL REFERENCE:
^HLCS(870,
.01 NODE
.02 INSTITUTION
.08 DNS DOMAIN
1 DESCRIPTION
2 LLP TYPE
4.5 AUTOSTART
21 QUEUE SIZE
400.01 TCP/IP ADDRESS
400.02 TCP/IP PORT
400.08 TCP/IP PORT (OPTIMIZED)
"B" X-REF", "", "", "2011/08/03"], ["5695", "OPEN LINK", "Routine", "HEALTH LEVEL SEVEN", "2011/07/13", "APPROVED", "Active", "Private", "", "
LSRP requests private usage of an HL7 API to determine
if a link can be opened.", "", "HLOUSR1", "2011/08/03"], ["5696", "Add the MDA comments into a List Manager array", "Routine", "ACCOUNTS RECEIVABLE", "2011/07/25", "APPROVED", "Active", "Private", "", "
The following subroutine call is made to the routine
PRCAMDA2. The input PRCABN is the internal entry number of an entry in the
BILL/CLAIMS (#399) file, which is dinumed to the ACCOUNTS RECEIVABLE (#430)
file. The input PRCALN is a line counter for the List Manager screen array.
The subroutine will load the List Manager VALMAR array.", "", "PRCAMDA2", "2011/07/25"], ["5697", "PCMM MHTC API's for CPRS", "Routine", "SCHEDULING", "2011/07/26", "APPROVED", "Active", "Controlled Subscription", "", "
This is a API that returns the Mental Health treatment
Coordinator from PCMM to CPRS for display in the CPRS Gui.", "", "SCMCMHTC", "2011/12/07"], ["5698", "HL7 Sending Facility/Logical Link relationship", "File", "HEALTH LEVEL SEVEN", "2011/07/26", "APPROVED", "Active", "Private", "870", "
The VistA Radiology/Nuclear Medicine application uses
HL7 messages to communicate with the teleradiologists associated with the
National Teleradiology Program. The interface between these two applications
requires the software on the NTP side to query the VistA radiology database
when an order is received by NTP for a new patient.\n
The first iteration of the NTP query/Radiology response software utilized v2.3
HL7 messages and the destination of those responses was defined by the data
stored in the following two fields: TCP/IP ADDRESS (#400.01) and the TCP/IP
PORT (OPTIMIZED) (#400.08). These two fields reside within the HL LOGICAL LINK
(#870) file.\n
RA*5.0*107 is the second iteration of the NTP query/Radiology response
interface. This iteration will upgrade the HL7 version of the message from
V2.3 to V2.4 and the query will identify the DNS Domain (MSH-4.2) where the
responses are to be broadcast.\n
DNS Domain information is passed as a component of the Sending Facility
(MSH-4) field associated with the query.\n
The DNS Domain is then used to 'look up' the logical link record required to
complete the HL7 information transfer.", "", "", "2011/08/01"], ["5699", "ICDXCODE", "Routine", "DRG GROUPER", "2011/08/02", "", "Retired", "Supported", "", "
Routine ICDXCODE was developed to replace ICDCODE
during the ICD-10 project to navigate between the ICD-9 Diagnosis file 80 and
the ICD-10 Diagnosis file 8010 under the two file solution. The two file
solution had the ICD-9 codes and ICD-10 codes stored in two separate files.
This solution was abandoned in favor of the one file solution where both ICD-9
and ICD-10 are stored in the same file (ICD Diagnosis file 80). A one file
solution of these APIs can be found in the routine ICDEX (ICD Data Extraction)
Routine ICDXCODE will be exported to support applications through the
transition between the one and two file solutions. It will be retired 18
months after the ICD-10 compliance date.\n", "", "ICDXCODE", "2016/04/14"], ["5700", "ACCESS TO LAB LOINC FILE", "File", "LAB SERVICE", "2011/08/03", "", "Pending", "Private", "95.3", "
This file contains information about LOINC codes and
associated text for describing Lab tests.", "", "", ""], ["5701", "ACCESS TO LAB WKLD FILE", "File", "LAB SERVICE", "2011/08/03", "", "Pending", "Private", "64", "
This file contains information on Laboratory
procedures.", "", "", ""], ["5702", "GMVRPCM", "Routine", "GEN. MED. REC. - VITALS", "2011/08/03", "APPROVED", "Active", "Private", "", "
This routine performs various actions such as building
selection lists and modifying package parameters; VPR requests use of it to
pull values from the GMRV Vitals Parameters file #120.57. Complete details
about this call may be found in ICR #4360, RPC 'GMV MANAGER'.", "", "GMVRPCM", "2012/05/25"], ["5703", "PROBLEM file data", "File", "PROBLEM LIST", "2011/08/03", "APPROVED", "Active", "Private", "9000011", "
This private agreement allows the Virtual Patient
Record (VPR) access to data in the Problem file #9000011 that is not available
in internal format via the current GMPL api's.", "", "", "2013/08/02"], ["5704", "ORQ12", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/08/03", "APPROVED", "Active", "Private", "", "", "", "ORQ12", "2013/08/02"], ["5705", "FILE 410 DESCRIPTION UPDATE", "File", "1", "2011/08/08", "APPROVED", "Active", "Private", "410", "
Add to end of file 410 description the wording:
*******DO NOT RE-INDEX THIS FILE*******\n
per instructions from national support as re-indexing has been causing site
errors.\n
One time agreement in patch PRC*5.1*157. Post install routine PRC157P will add
file description node in file global ^DIC:\n
^DIC(410,"%D",7,0)=" *********DO NOT RE-INDEX THIS FILE**********"", "", "", "2011/08/08"], ["5706", "FILE 442 DESCRIPTION UPDATE", "File", "1", "2011/08/08", "APPROVED", "Active", "Private", "442", "
Add to end of file 442 description the wording:
*******DO NOT RE-INDEX THIS FILE*******\n
per instructions from national support as re-indexing has been causing site
errors.\n
One time agreement in patch PRC*5.1*157. Post install routine PRC157P will add
file description node in file global ^DIC:\n
^DIC(442,"%D",5,0)=" *********DO NOT RE-INDEX THIS FILE**********"", "", "", "2011/08/08"], ["5707", "FILE 443.6 DESCRIPTION UPDATE", "File", "1", "2011/08/08", "APPROVED", "Active", "Private", "443.6", "
Add to end of file 443.6 description the wording:
*******DO NOT RE-INDEX THIS FILE*******\n
per instructions from national support as re-indexing has been causing site
errors.\n
One time agreement in patch PRC*5.1*157. Post install routine PRC157P will add
file description node in file global ^DIC:\n
^DIC(443.6,"%D",7,0)=" *********DO NOT RE-INDEX THIS FILE**********"", "", "", "2011/08/08"], ["5708", "ALIAS SUBFILE", "File", "REGISTRATION", "2011/08/08", "APPROVED", "Active", "Controlled Subscription", "2", "
Virtual Patient Record (VPR) requests permission to
read the ALIAS field #1 (subfile #2.01).\n
Outpatient Pharmacy (PSO) requests permission to read the ALIAS field #1
(subfile #2.01)", "", "", "2013/04/24"], ["5709", "DEA DATA RETRIEVAL", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/08/12", "APPROVED", "Active", "Controlled Subscription", "", "
Provide information about controlled substance signing
and digital signatures.", "", "ORDEA", "2018/03/22"], ["5710", "POTENTIAL COPAYMENT CHARGE AMOUNT", "Routine", "INTEGRATED BILLING", "2011/08/15", "APPROVED", "Active", "Private", "", "
This Integration Agreement will allow the AR package to
look up a potential copayment charge amount based on the rate to be charged
TODAY.", "", "IBAUTL", "2011/08/16"], ["5711", "IB NCPDP EVENT LOG FILE", "File", "INTEGRATED BILLING", "2011/08/22", "APPROVED", "Active", "Private", "366.14", "
The ECME package is performing direct global read-only
access to the IB NCPDP EVENT LOG file (#366.14) for the purpose of generating
data from the IB ECME EVENT LOG report to be included in the ECME report View
ePharmacy Prescription.", "", "", "2011/09/14"], ["5712", "PRINT IB ECME BILLING EVENTS REPORT", "Routine", "INTEGRATED BILLING", "2011/08/22", "APPROVED", "Active", "Private", "", "
The ECME report "View ePharmacy Rx" will include data
from the IB ECME BILLING EVENT REPORT. The ECME report compile process will
establish the necessary scratch global and set up the correct IB variables and
will make a routine call to PRINT^IBNCPEV which will output the report to the
open device.", "", "IBNCPEV", "2011/09/14"], ["5713", "IB LIST MANAGER DISPLAY DATA", "Routine", "INTEGRATED BILLING", "2011/08/22", "APPROVED", "Active", "Controlled Subscription", "", "
This is a generic billing API which allows the
subscribers to obtain the ListManager display array data from various IB
ListManager list templates/screens.\n
This IB API will return detailed billing information about TPJI third party
bills and patient insurance policy information. The content of the data is
strictly owned by IB and may be changed at any time. IB does not have to
notify the subscribers that the content of the IB data which is to be returned
to them may be changing.", "", "IBJTU6", "2011/09/14"], ["5714", "IB PHARMACY INSURANCE", "Routine", "INTEGRATED BILLING", "2011/08/22", "APPROVED", "Active", "Private", "", "
This IB API identifies all active pharmacy insurance
policy data as of a given date of service and returns an array of insurance
policies in COB (Coordination of Benefits) sequence order (primary, secondary,
tertiary).", "", "IBNCPDPU", "2011/09/14"], ["5715", "WITHDRAWN", "", "INTEGRATED BILLING", "2011/08/22", "", "Withdrawn", "", "", "", "", "", ""], ["5716", "WITHDRAWN", "", "INTEGRATED BILLING", "2011/08/22", "", "Withdrawn", "", "", "", "", "", ""], ["5717", "WITHDRAWN", "", "INTEGRATED BILLING", "2011/08/22", "", "Withdrawn", "", "", "", "", "", ""], ["5718", "OP ACCESS WINDOWS NETWORK PRINTER NAME IN THE DEVICE FILE", "File", "KERNEL", "2011/08/24", "APPROVED", "Active", "Private", "3.5", "
Outpatient Pharmacy requests permission to access the
WINDOWS NETWORK PRINTER NAME field (#75) in the Kernel DEVICE (#3.5) file.
This field is used to identify the printer location in the Windows network.
Outpatient Pharmacy will pass the printer location to a Java application so it
can print documentation in a .pdf format related to a specific prescription.", "", "", "2011/08/24"], ["5719", "WITHDRAWN", "", "INTEGRATED BILLING", "2011/09/06", "", "Withdrawn", "", "", "", "", "", ""], ["5720", "WITHDRAWN", "", "OUTPATIENT PHARMACY", "2011/09/01", "", "Withdrawn", "", "", "", "", "", ""], ["5721", "TPJI Comment Array", "Routine", "INTEGRATED BILLING", "2011/08/29", "", "Withdrawn", "Private", "", "
The following subroutine call is made to the routine
IBJTTC. The input IBIFN is the internal entry number of an entry in the
BILL/CLAIMS (#399) file, which is dinumed to the ACCOUNTS RECEIVABLE (#430)
file. The subroutine will load the List Manager VALMAR array.", "", "IBJTTC", ""], ["5722", "WITHDRAWN", "", "INTEGRATED BILLING", "", "", "Withdrawn", "", "", "", "", "", ""], ["5723", "VIEW ECME PRESCRIPTION", "Routine", "E CLAIMS MGMT ENGINE", "2011/09/15", "APPROVED", "Active", "Controlled Subscription", "", "
Allows subscribing packages to call ECME routine BPSVRX
in order to build the View ECME Prescription List Manager screen.", "", "BPSVRX", "2011/09/15"], ["5724", "BPS RPT VIEW ECME RX", "Other", "E CLAIMS MGMT ENGINE", "2011/09/15", "APPROVED", "Active", "Private", "", "
This agreement allows the ECME option "View ePharmacy
Rx" [BPS RPT VIEW ECME RX] to be included on the Outpatient Pharmacy parent
menu option "ePharmacy Menu" [PSO EPHARMACY MENU].", "", "", "2011/09/15"], ["5725", "TERMINAL TYPE", "File", "KERNEL", "2011/09/15", "APPROVED", "Active", "Private", "3.2", "
The Mental Health package requests permission to read
some fields in the TERMINAL TYPE (#3.2) file.", "", "", "2012/03/05"], ["5726", "LSRP ADD X-REF TO NEW PERSON FILE", "File", "KERNEL", "2011/09/16", "APPROVED", "Active", "Private", "200", "
The Lab System Re-Engineering Project (LSRP) has
permission to define 2 New Style Cross references on the New Person File
(#200) with patch LR*5.2*393. These cross references are added to the New
Person file as part of the KIDS Post-Installation process of the LR*5.2*393
distribution. These Cross References are installed using the CREIXN^DDMOD
Fileman API.\n
Kernel development grants this "one-time" ICR allowing LSRPs' addition of
"ALSRP" and "AKLSRP" cross-references to the New Person file (#200) by the
LR*5.2*393 patch.\n\n
New Style Cross references "ALSRP" and "AKLSRP" are described as follows:\n
"ALSRP"
-------
"ALSRP" checks for changes to specific fields in the New Person File (#200).
When data in a relative field is changed, "ALSRP" SET logic invokes OPKG^XUHUI
(allowed via ICR #3589) referencing the "LA7J MFN NEW PERSON MOD PRTCL" entry
in the Protocol file (#101).\n
"ALSRP" is defined for the following New Person fields:
NAME (#.01)
OFFICE PHONE (#.132)
VOICE PAGER (#.137)
DIGITAL PAGER (#.138)
SEX (#4)
DOB (#5)
SSN (#9)
NPI (#41.99)\n\n
Data Dictionary Description:\n
ALSRP RECORD MUMPS ACTION
Short Descr: LSRP monitoring of New Person Field changes
Description: This M New Style Cross reference will monitor changes to
New Person fields that are relevant to the Lab System
Re-Engineering Project.\n
User contact and other information on the Cerner Pathnet
system must be synchronized with changes made (for Lab
users) on VistA. This cross- reference will invoke code
that sends a Master File Notification to Cerner when a
change to pertinent data is made.\n
Only users holding either the LRJ CERNER PRA or LRJ CERNER
STF security keys will be sent via MFN to Cerner.
Set Logic: D OPKG^XUHUI("101","LA7J MFN NEW PERSON MOD PRTCL","","ALSRP")
Kill Logic: Q
Whole Kill: Q\n
X(1): NAME (200,.01) (forwards)
X(2): OFFICE PHONE (200,.132) (forwards)
X(3): VOICE PAGER (200,.137) (forwards)
X(4): DIGITAL PAGER (200,.138) (forwards)
X(5): SEX (200,4) (forwards)
X(6): DOB (200,5) (forwards)
X(7): SSN (200,9) (forwards)
X(8): NPI (200,41.99) (forwards)\n\n
"AKLSRP"
--------
"AKLSRP" checks changes to the set of New Persons holding specific Security
Keys and is defined on the New Person file KEYS subfile (#200.051), KEY field
(#.01). When KEY allocations and de-allocations occur, "AKLSRP" SET and KILL
logic invoke OPKG^XUHUI (see ICR #3589) referencing the "LA7J MFN NEW PERSON
KEY MOD PRTCL" entry in the Protocol file (#101).\n\n
Data Dictionary Description:\n
Subfile #200.051\n
AKLSRP FIELD MUMPS ACTION WHOLE FILE (#200)
Short Descr:
This cross reference creates LSRP MFNs when a lab key is added.
Description: The AKLSRP New Style Cross reference will invoke a protocol
that checks when a key is added or deleted. If the
affected key is LRJ CERNER PRA or LRJ CERNER STF, then an
MFN will be sent to Cerner Pathnet, as necessary.
Set Logic:
D OPKG^XUHUI("101","LA7J MFN NEW PERSON KEY MOD PRTCL","","AKLSRP")\n
Kill Logic:
D OPKG^XUHUI("101","LA7J MFN NEW PERSON KEY MOD PRTCL","K","AKLSRP")\n
X(1): KEY (200.051,.01) (forwards)\n", "", "", "2011/10/27"], ["5727", "GMTSMHPE", "Routine", "HEALTH SUMMARY", "2011/09/28", "", "Pending", "Private", "", "
The Mental Health package is removing the MEDICAL
RECORD (#90) file with YS*5.01*60.\n
The Health Summary package's MENTAL HEALTH PHYSICAL EXAM component calls
MAIN^GMTSMHPE which checks for data in the MEDICAL RECORD (#90) file.\n
The Mental Health package requests permission to alter the GMTSMHPE routine
with YS*5.01*60. We would export a routine named YSTSMHPE that is a copy of
GMTSMHPE, but with a QUIT at the start of the MAIN entry point. In our patch
installation, we will save YSTSMHPE as GMTSMHPE. This would result in the
MENTAL HEALTH PHYSICAL EXAM component not returning anything.\n
In a future Health Summary patch, we request the component be removed.", "", "GMTSMHPE", ""], ["5728", "PSNNGR ROUTINE", "Routine", "NATIONAL DRUG FILE", "2011/09/29", "APPROVED", "Active", "Private", "", "
This IA provides another entry point (component) for
Outpatient Pharmacy & Inpatient Medications to use in to store Drug-Allery
Order Checks. The line tag currently already exists but is not documented as
an IA. The component requires the developer to pass in PSNDA and PSNID. The
utility will return all of the primary drug ingredients to an entry in the VA
Product file (#50.68).\n
*******************************************************
The calling package(s) assumes the responsibily to kill variables
(PSNDA,PSNID,J,K,X) and ^TMP("PSN",$J, going in, and when exiting, do the
same.
*******************************************************", "", "PSNNGR", "2011/10/03"], ["5729", "ORDER CHECK INSTANCES API", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/10/03", "APPROVED", "Active", "Private", "", "
This integration agreement allows subscribing packages
to save data into and retrieve data from the ORDER CHECK INSTANCES file
(#100.05).", "", "OROCAPI1", "2016/07/28"], ["5730", "MAG RESCIND IMAGES", "Routine", "IMAGING", "2011/10/05", "APPROVED", "Active", "Private", "", "
This ICR will allow the TIU Package to set a Queue so
that Images attached to a Rescinded Advance Directive will be Watermarked with
the word 'RESCINDED'.", "", "MAGGSIU4", "2011/10/14"], ["5731", "ORDER CHECK INSTANCES FILE - DRUG ALLERGIES", "File", "ORDER ENTRY/RESULTS REPORTING", "2011/10/12", "APPROVED", "Active", "Private", "100.05", "
This integration agreement allows subscribing packages
to read and write to those fields stored in the DRUG ALLERGIES multiple field
(#17).", "", "", "2011/10/12"], ["5732", "HLEMEU APIs", "Routine", "HEALTH LEVEL SEVEN", "2011/10/17", "APPROVED", "Active", "Controlled Subscription", "", "
The use of the HL7 API MSGIEN^HLEMU(message id) is
allowed per the description documented with this Integration Control
Registration.", "", "HLEMU", "2011/10/27"], ["5733", "HLOMSG1 APIs", "Routine", "HEALTH LEVEL SEVEN", "2011/10/17", "APPROVED", "Active", "Controlled Subscription", "", "
The use of the HL7 API FINDMSG^HLOMSG1(message id,list)
is allowed per the description documented with this Integration Control
Registration.", "", "HLOMSG1", "2011/10/27"], ["5734", "YTQ SAVE", "Remote Procedure", "MENTAL HEALTH", "2011/10/17", "APPROVED", "Active", "Private", "", "
This RPC can be used to add or edit a Mental Health
file entry. The subscripted YS array is passed to the RPC containing all of
the values needed to create or update the entry.\n
Input: YS("FILEN")=File Number (e.g., the file # for administrations
would be 601.84)
YS("IEN")=the internal number of the record you want to edit.
Leave blank if creating a new record. If creating a
new record you must send ".01^NEW" for those MH files
using the New input transform.
YS(1)=FIELD #^Value^[3rd piece is 1 if you need to bypass
validation (use only if approved by developer)
YS(n)=FIELD #^Value^[3rd piece]\n
Output: YSDATA(1)=[DATA] or [ERROR]
YSDATA(2)=error message\n
Example: Adding a new entry to the MH ADMINISTRATION (#601.84) file.\n
S YS(1)=".01^NEW^1"
S YS(2)="1^`134"
S YS(3)="2^5"
S YS(4)="3^3111017.0945"
S YS(5)="4^NOW"
S YS(6)="5^`547"
S YS(7)="6^`547"
S YS(8)="7^NO"
S YS(9)="8^NO"
S YS(10)="9^0"
S YS(11)="13^`87"
S YS("FILEN")=601.84", "YTQ SAVE", "", "2013/05/16"], ["5735", "YTQ SET ANSWER ALL", "Remote Procedure", "MENTAL HEALTH", "2011/10/17", "APPROVED", "Active", "Private", "", "
This RPC saves all answers for an administration to the
MH ANSWERS (#601.85) file.\n
Input: YS("AD")=internal entry number of the MH ADMINISTRATION (#601.84)
entry
YS(n)=File 601.72 IEN^File 601.75 IEN
YS(n,n1)=text
where n and n1 are integers starting at 1.\n
The YS(n) array identifies the questions and responses for the administration.
The first piece of every YS(n) should be a pointer to an entry in the MH
QUESTIONS (#601.72) file. In most cases, the second piece will be a pointer to
an entry in the MH CHOICES (#601.75) file. If the response to the question is
not in FILE 601.75, the second piece is null and the YS(n,n1) value should be
defined with the text of the response.\n
Output: YSDATA(1)=[DATA]
YSDATA(2)=number of answers^OK
or
YSDATA(1)=[ERROR]
YSDATA(2)=error message\n
The release of patch YS*5.01.123 changes the routine name called by the RPC.
The routine before patch YS*5.01*123 is YTQAPI17, and the routine after the
patch isYTQAPI21. Input, output and tag name are not changed with this patch.
The above changes are dependent upon the release of CPRS v31A.", "YTQ SET ANSWER ALL", "", "2013/05/16"], ["5736", "GIVE THIS DBIA A BETTER NAME THAN DBIA5736", "", "", "2011/10/18", "", "Pending", "", "", "", "", "", ""], ["5737", "CHECK DRUG INTERACTIONS UTILITY", "Routine", "PHARMACY DATA MANAGEMENT", "2011/10/18", "APPROVED", "Active", "Controlled Subscription", "", "
This utility routine is called to determine what Drug
Interactions exist for Inpatient and Outpatient Pharmacy.", "", "PSSDIUTL", "2014/10/24"], ["5738", "GIVE THIS DBIA A BETTER NAME THAN DBIA5738", "", "", "2011/10/25", "", "Pending", "", "", "", "", "", ""], ["5739", "NwHIN DIRECT 7079 GUI TRIGGER", "Routine", "NATIONAL HEALTH INFO NETWORK", "2011/10/25", "APPROVED", "Active", "Controlled Subscription", "161.01", "
To facilitate the sending of Fee Basis and related data
which populate the Treatment Authorization Form 7079 to VA contracted vendors,
triggers are created on a number of fields of the Fee Basis Patient File
#161.01. When triggered by Fee Basis, the NwHIN routine PUSH^NHIND79C sends
Fee Basis and related data in XML format to NwHIN Direct via the HeatheVet Web
Service.\n
The Fee Basis fields upon which a trigger are placed include:\n
FROM DATE - 161.01,.01 Field
PRINT AUTHORIZATION (Y/N) - 161.01,1 Field
TO DATE - 161.01,.02 Field
VENDOR - 161.01,.04 Field
PATIENT TYPE CODE - 161.01,.065 Field
PURPOSE OF VISIT CODE - 161.01,.07 Field
DIAGNOSIS LINE 1 - 161.01,.08 Field
DIAGNOSIS LINE 2 - 161.01,.085 Field
DIAGNOSIS LINE 3 - 161.01,.086 Field
TREATMENT TYPE CODE - 161.01,.095 Field
ACCIDENT RELATED (Y/N) - 161.01,.096 Field
POTENTIAL COST RECOVERY CASE - 161.01,.097 Field
TYPE OF CARE - 161.01,2 Field
CLERK - 161.01,100 Field
PRIMARY SERVICE AREA - 161.01,101 Field
REFERRING PROVIDER - 161.01,104 Field", "", "NHIND79C", "2012/03/29"], ["5740", "PSOFDAUT", "Routine", "OUTPATIENT PHARMACY", "2011/10/31", "APPROVED", "Active", "Private", "", "
This Outpatient Pharmacy utility routine contains APIs
related to the printing of FDA Medication Guides.", "", "PSOFDAUT", "2012/03/07"], ["5741", "Message Status Data Retrieval from 773", "File", "HEALTH LEVEL SEVEN", "2011/10/31", "APPROVED", "Active", "Private", "773", "\n\n
The HL7 MESSAGE ADMINISTRATION file (#773) defines and maintains unique
message IDs. It conains information related to the respective message such as
Statuses and date/times.\n
LSRP has permission to retrieve message status information from the HL7 1.6
data structures.\n\n", "", "", "2011/12/07"], ["5742", "Message Status Data Retrieval from 778", "File", "HEALTH LEVEL SEVEN", "2011/10/31", "APPROVED", "Active", "Private", "778", "\n\n
The HLO MESSAGES file (#778) records each message sent or received via HLO.
It conains information related to the respective message such as Statuses and
date/times.\n
LSRP has permission to retrieve message status information from the HLO data
structures.\n\n", "", "", "2011/12/07"], ["5743", "FBAAV2 HL7NAME FOR FBCS (DSS)", "Routine", "FEE BASIS", "2011/11/02", "", "Retired", "Controlled Subscription", "", "
FBCS is requesting access to HL7NAME^FBAAV2 in support
of the new 35 character requirement for the name field when transmitting data
to Central Fee.", "", "FBAAV2", ""], ["5744", "FBCS USAGE OF CONTRACT API'S IN FBUTL7", "Routine", "FEE BASIS", "2011/11/02", "", "Retired", "Controlled Subscription", "", "
FBCS requests to be allowed to use the following two
contract related API's in FBUTL7\n
1. VCNTR^FBUTL7 2. EDCNTRA^FBUTL7", "", "FBUTL7", "2011/11/04"], ["5745", "FBCS REQUEST TO USE FBUTL8", "Routine", "FEE BASIS", "2011/11/02", "", "Retired", "Controlled Subscription", "", "
FBCS request to use API FILERP^FBUTL8 to file the Line
item provider into the invoice file.", "", "FBUTL8", "2011/11/04"], ["5746", "USE SCREENMAN DDS VARIABLE", "Other", "1", "2011/11/04", "APPROVED", "Active", "Controlled Subscription", "", "
The ScreenMan documentation recommends that
applications use $D(DDS) to determine if their code is being executed from
within a ScreenMan form. Reading the contents of ScreenMan's DDS variable
allows application developers to determine the ScreenMan form their code is
being invoked from. The format of DDS is formIEN^formName. This ICR allows
reading of DDS variable.\n
In order for an application to integrate and simultaneously use the Browser,
List Manager, and ScreenMan the application must be able to manipulate the DDS
variable. If List Manager is invoked from ScreenMan List Manager prompts will
not display correctly because ^DIR works differently when DDS is defined.
Therefore the application must save DDS and kill it before calling List
Manager and restore it when returning from List Manager to ScreenMan. If the
Browser is invoked from List Manager and DDS is not defined because of the
above situation then the Browser will kill on exit some of variables needed by
ScreenMan. Therefore the application needs to temporarily set DDS=1 before
invoking the Browser.\n
In summary, this ICR allows the application to read, kill, set, and NEW the
DDS variable.\n
Note that if List Manager is being invoked from ScreenMan the following Kernel
calls should be made to restore the terminal settings required by ScreenMan
before calling REFRESH^DDSUTL.\n
N IOAWMO,X S X=0 X ^%ZOSF("RM"),^%ZOSF("TYPE-AHEAD") S X="IOAWM0" D
ENDR^%ZISS W IOAWM0\n
If this is not done the ScreenMan display will be corrupted.\n", "", "", "2012/03/20"], ["5747", "ICD Data Extraction", "Routine", "DRG GROUPER", "2011/11/06", "APPROVED", "Active", "Controlled Subscription", "", "
Application Programmer Interfaces (APIs) in this
routine were developed to remove the need for direct global access to either
the DIAGNOSIS file 80 or OPERATIONS/PROCEDURE file 80.1.\n
These entry points are meant to replace the following active/retired ICRs:\n
48 Private YS File 80.2 Weight (2)
280 Private HBH File 80 Code (.01)
365 Private QAM File 80 Code (.01)
368 Private IB File 80 Retired Nov 15, 2008
369 Private IB File 80.1 Retired Nov 15, 2008
370 Private IB/DSS 80.2 DRG Name (.01)
582 Private IMR File 80 Code (.01)
647 Private IB File 80 Retired Nov 15, 2008
1161 Private VAM File 80 Retired Nov 15, 2008
1275 Private GMTS File 80 Retired Nov 15, 2008
1276 Private GMTS File 80.1 Retired Nov 15, 2008
1294 Subscription PCE/TIU/OR File 80 Retired Nov 15, 2008
1487 Private ACKQ File 80 Retired Nov 15, 2008
1586 Subscription AICS/PCE File 80.3 MDC Name (.01)
2435 Private PXRM File 80 Hdr ^ICD9(0)
2436 Private PXRM File 80.1 Hdr ^ICD0(0)
3990 Supported Routine ICDCODE To be retired Apr 2016
3991 Supported Routine ICDAPIU To be retired Apr 2016
4052 Supported Routine ICDGTDRG
5028 Subscription GMPL File 80
5388 Supported File 80 Code (.01), AB/BA/D/AST/ACT
To be retired Apr 2016
5404 Supported File 80.1 Code (.01), BA/ACT
To be retired Apr 2016
5699 Supported Routine ICDXCODE To be retired Apr 2016
5757 Supported Routine ICDSAPI To be retired Apr 2016
10082 Supported File 80 Retired Nov 15, 2008
10083 Supported File 80.1 Retired Nov 15, 2008\n\n", "", "ICDEX", "2014/07/11"], ["5748", "CLIO TERM FILE", "File", "CLINICAL PROCEDURES", "2011/11/16", "APPROVED", "Active", "Private", "704.101", "", "", "", "2013/03/26"], ["5749", "Updating DD 'VR' Nodes", "File", "1", "2011/11/30", "APPROVED", "Active", "Private", "", "", "", "", "2011/12/07"], ["5750", "ORQQPXRM REMINDERS APPLICABLE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/12/02", "APPROVED", "Active", "Controlled Subscription", "", "
In support of Capacity Management Tools 3.0, the RPC
Broker looks for the execution of the ORQQPXRM REMINDERS APPLICABLE remote
procedure (by RPC name) to measure the load times for CPRS cover sheets loaded
in the foreground.", "ORQQPXRM REMINDERS APPLICABLE", "", "2011/12/07"], ["5751", "ORQQPXRM REMINDERS UNEVALUATED", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/12/02", "APPROVED", "Active", "Controlled Subscription", "", "
In support of Capacity Management Tools 3.0, the RPC
Broker looks for the execution of the ORQQPXRM REMINDERS UNEVALUATED remote
procedure (by RPC name) to measure the load times for CPRS cover sheets loaded
in the foreground.", "ORQQPXRM REMINDERS UNEVALUATED", "", "2011/12/07"], ["5752", "ORQQPXRM REMINDER CATEGORIES", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/12/02", "APPROVED", "Active", "Controlled Subscription", "", "
In support of Capacity Management Tools 3.0, the RPC
Broker looks for the execution of the ORQQPXRM REMINDER CATEGORIES remote
procedure (by RPC name) to measure the load times for CPRS cover sheets loaded
in the foreground.", "ORQQPXRM REMINDER CATEGORIES", "", "2011/12/07"], ["5753", "ORWCV START", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2011/12/02", "APPROVED", "Active", "Controlled Subscription", "", "
In support of Capacity Management Tools 3.0, the RPC
Broker looks for the execution of the ORWCV START remote procedure by tag
(START) and routine (ORWCV) to measure the load times for CPRS cover sheets
loaded in the foreground.", "ORWCV START", "ORWCV", "2011/12/07"], ["5754", "PROSTHETICS USE OF HCPCS (#.01) FIELD", "File", "PROSTHETICS", "2011/12/05", "APPROVED", "Active", "Private", "661.1", "
Provide DSS Extracts access to the PROSTHETIC HCPCS
(#661.1) File in order to read the HCPCS (#.01) Field record.\n
Revised 04/21/23 to add #.02 Code Description field for DSS FY24 Development
on the Prosthetics Unusual Cost Report.", "", "", "2023/04/24"], ["5755", "ICD CODING SYSTEMS", "File", "DRG GROUPER", "2011/12/24", "APPROVED", "Active", "Private", "80.4", "
Lexicon Utility has all privileges as though it were
the custodial package.\n", "", "", "2014/07/10"], ["5756", "CHECK QUICK ORDERS ASSOCIATED WITH ANCILLARY ORDERABLE ITEM", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2011/12/28", "", "Pending", "Private", "", "
The purpose of this Integration Control Agreement is to
give the Laboratory V5.2 (Lab) system and the Pharmay Data Management V1.0
system permission to call an Application Programming Interface (API) that will
check all quick orders associated with a specified orderable item.\n
When certain fields (determined by the Lab package) are modified, it might
affect the way quick orders are used or defined. Lab will call the provided
API when any of these fields are updated. The API will notify the people at
the site who are responsible for quick orders of the changes and which quick
orders need to be reviewed.\n
The same is true for Pharmacy. Whenever certain fields are modified
(determined by the Pharmacy package), the quick order search will be
performed.", "", "ORUQO", ""], ["5757", "SEARCH ICD FILES", "Routine", "DRG GROUPER", "2011/12/29", "", "Retired", "Supported", "", "
Routine ICDSAPI was developed as a wrapper routine for
DIC lookups during the ICD-10 project to navigate between the ICD-9 Diagnosis
file 80 and the ICD-10 Diagnosis file 8010 under the two file solution. The
two file solution had the ICD-9 codes and ICD-10 codes stored in two separate
files. This solution was abandoned in favor of the one file solution where
both ICD-9 and ICD-10 are stored in the same file (ICD Diagnosis file 80). A
one file solution of these APIs can be found in the routine ICDEXLK (ICD Data
Extraction, special lookup). Routine ICDSAPI will be exported to support
applications through the transition between the one and two file solutions.
It will be retired 18 months after the ICD-10 compliance date.\n", "", "ICDSAPI", "2016/04/14"], ["5758", "ICD CODE UPDATE EVENT Protocol", "Other", "DRG GROUPER", "2012/01/03", "", "Pending", "Controlled Subscription", "", "
This protocol is used to notify other applications and
processes when the ICD-9/10 Code Set is updated.\n
This is an extended action protocol. Applications may attach actions on this
protocol that should be taken in the event of an ICD update.\n
NOTE: This protocol is commonly invoked by the LEXICAL SERVICES UPDATE
protocol when there is a change in ICD data.\n", "", "", ""], ["5759", "GIVE THIS DBIA A BETTER NAME THAN DBIA5759", "", "", "2012/01/04", "", "Pending", "", "", "", "", "", ""], ["5760", "EXCEPTIONS DISPLAYED", "Routine", "OUTPATIENT PHARMACY", "2012/01/04", "", "Pending", "Controlled Subscription", "", "", "", "PSODDPR5", ""], ["5761", "DISPLAY ORDER CHECKS RETURNED", "Routine", "OUTPATIENT PHARMACY", "2012/01/04", "", "Withdrawn", "Controlled Subscription", "", "", "", "PSODDPR2", ""], ["5762", "GIVE THIS DBIA A BETTER NAME THAN DBIA5762", "", "", "2012/01/10", "", "Pending", "", "", "", "", "", ""], ["5763", "GETSIOPI", "Routine", "INPATIENT MEDICATIONS", "2012/01/10", "", "Pending", "Controlled Subscription", "", "
Inpatient Medications has expanded the Special
Instructions and Other Print Info associated with Inpatient orders to an
unlimited maximum length. Bar Code Medication Administration (BCMA) requests
access to the new data via an API that will return the word processing data in
a ^TMP global node.", "", "PSJBCMA5", ""], ["5764", "PSODGAL1", "Routine", "OUTPATIENT PHARMACY", "2012/01/12", "APPROVED", "Active", "Private", "", "
This API displays drug allergy order checks.", "", "PSODGAL1", "2012/04/11"], ["5765", "ENTERED IN ERROR", "Routine", "OUTPATIENT PHARMACY", "2012/01/31", "", "Pending", "Controlled Subscription", "", "", "", "", ""], ["5766", "ORWCH LOADSIZ", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/02/13", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWCH LOADSIZ", "", "2014/06/12"], ["5767", "ALLERGY SIGN/SYMPTOMS", "File", "ADVERSE REACTION TRACKING", "2012/02/15", "APPROVED", "Active", "Private", "120.83", "
Outpatient Pharmacy and Inpatient Meds packages are
requesting permission to retrieve Name field (.01) from the SIGN/SYMPTOMS FILE
(#120.83)", "", "", "2012/04/11"], ["5768", "COUNTRY CODE FILE", "File", "HEALTH LEVEL SEVEN", "2012/02/16", "APPROVED", "Active", "Supported", "779.004", "
The HL Package grants read-only public access via
FileMan to the Country Code file (#779.004). This applies to all fields
defined in the file.\n\n
Please Note:\n
Per VHA Directive 2005-044, this file has been "locked down" by Data
Standardization (DS). The file definition (i.e. data dictionary) shall not be
modified. All additions, changes and deletions to entries in the file shall
be done by Enterprise Reference Terminology (ERT) using the Master File Server
(MFS), provided by Common Services (CS). Creating and/or editing locally
defined fields in the file are not permitted. Use of locally defined fields
that were created prior to the VHA Directive's 2005-044 effective date shall
not be supported.\n
This file is a table of country codes that are used by the Messaging System
when building message header segments.\n
This file should not be modified locally.\n\n\n\n\n", "", "", "2012/04/16"], ["5769", "ORDER ACKNOWLEDGEMENT FILE", "File", "CARE MANAGEMENT", "2012/02/22", "APPROVED", "Active", "Private", "102.4", "
This ICR grants VPR permission to read the Order
Acknowledgement file.", "", "", "2013/05/09"], ["5770", "PRE CRCL CALCULATIONS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2012/02/23", "APPROVED", "Active", "Private", "", "
Returns patient height and weight.", "", "ORQQVI", "2014/07/18"], ["5771", "ORDERS FILE DATA", "File", "ORDER ENTRY/RESULTS REPORTING", "2012/02/23", "APPROVED", "Active", "Controlled Subscription", "100", "
This documents data that VPR is reading from the Orders
file #100.\n
Amendments:
10/6/22 Added the following fields for VPR subscribing package,
effective with VPR*1*30:
^OR(100,D0,0)
11 TREATING SPECIALTY
15 EVENT
^OR(100,D0,3)
8.1 TYPE
^OR(100,D0,6)
61 NATURE OF DC
68 DC EVENT
^OR(100,D0,8,D1,0)
12 NATURE OF ORDER
17 RELEASING PERSON", "", "", "2022/10/07"], ["5772", "PREGNANCY LOG", "File", "WOMEN'S HEALTH", "2012/02/23", "APPROVED", "Retired", "Controlled Subscription", "790.05", "
VPR requests permission to read the WV Pregnancy Log.", "", "", "2013/05/09"], ["5773", "ICD-9/ICD-10 Lookup", "File", "DRG GROUPER", "2012/02/24", "APPROVED", "Active", "Controlled Subscription", "", "
Applications may conduct Fileman lookups of ICD
Diagnosis file #80 and the ICD OPERATIONS/PROCEDURE file #80.1 using ^DIC and
the Special Lookup routine ICDEXLK. Applications may also point to these
files.\n
A special lookup program was written for the ICD DIAGNOSIS file #80 and ICD
OPERATION/PROCEDURE file #80.1 to navigate through the versioned (date
sensitive) data stored in these files. The Name of the special lookup is
stored in the Data Dictionary for these files:\n
^DD(80,0,"DIC")="ICDEXLK"
^DD(80.1,0,"DIC")="ICDEXLK"\n
Each time an application makes a ^DIC call to either file 80 or 80.1, the
special lookup routine is invoked, provided the FileMan variable DIC(0) does
not contain an "I" for "ignore the special lookup."\n
NOTE: Only the ^DIC call honors the special lookup routine. Those calls that
allow the user to specify the indexes (IX^DIC and MIX^DIC1), and the Data Base
Server calls (FIND^DIC, $$FIND1^DIC, and UPDATE^DIE) all ignore the Special
Lookup Program. As a result, the FileMan calls that ignore the Special Lookup
Program will not be able to conduct versioned searches or return versioned
data so use IX^DIC, MIX^DIC1 FIND^DIC, and $$FIND1^DIC with a great deal of
care. Never use any FileMan entry point that alters the data in these files
(i.e., ^DIE, EN^DIB, ^DIK FILE^DIE, UPDATE^DIE and FILE^DICN)\n
Package Special Lookup Variables\n
The following local variables in the ICD namespace should be NEWed
or KILLed by the calling application. The global variables may
be used in instances where local environment variables get NEWed
and the special lookup values need to be retained. The calling
application is responsible for KILLing the ^TMP global variables.\n\n
Versioning Date (Fileman format)\n
ICDVDT or ^TMP("ICDEXLK",$J,"ICDVDT")=<versioning date>\n
If supplied only active codes on that date will be
included in the selection list.\n
1. V74.6 SCREENING FOR YAWS
2. V77.5 SCREENING FOR GOUT
3. V76.9 SCREEN-NEOPLASM NOS
4. V76.43 SCREEN MAL NEOP-SKIN
5. V78.8 SCREEN-BLOOD DIS NEC\n
If not supplied, the date will default to TODAY and
all codes may be selected, active and inactive.\n
1. V74.6 SCREENING FOR YAWS
2. V77.5 SCREENING FOR GOUT
3. V76.8 SCREEN-NEOPLASM NEC (Inactive)
4. V76.9 SCREEN-NEOPLASM NOS
5. V76.43 SCREEN MAL NEOP-SKIN\n
Coding System (from file 80.4)\n
ICDSYS or ^TMP("ICDEXLK",$J,"ICDSYS")=<coding system>\n
1 ICD ICD-9-CM
2 ICP ICD-9 Proc
30 10D ICD-10-CM
31 10P ICD-10-PCS\n
If supplied only codes belonging to the coding system
will be included in the selection list.\n
S ICDSYS=1,X="DIABETES MELLITUS KETOACIDOSIS"\n
2 matches found\n
1. 249.11 SEC DM KETOACD UNCNTRLD (Major CC)
2. 249.10 SEC DM KETO NT ST UNCNTR (Major CC)\n
S ICDSYS=30,X="DIABETES MELLITUS KETOACIDOSIS"\n
8 matches found\n
1. E09.11 Drug/chem diabetes mellitus w
ketoacidosis w coma
2. E13.11 Oth diabetes mellitus with
ketoacidosis with coma
3. E09.10 Drug/chem diabetes mellitus w
ketoacidosis w/o coma
4. E10.11 Type 1 diabetes mellitus with
ketoacidosis with coma
5. E13.10 Oth diabetes mellitus with
Ketoacidosis without coma\n
If not supplied codes from any coding system will be
included in the selection list.\n
S X="DIABETES MELLITUS KETOACIDOSIS"\n
10 matches found\n
1. 249.11 SEC DM KETOACD UNCNTRLD (Major CC)
2. 249.10 SEC DM KETO NT ST UNCNT (Major CC)
3. E09.11 Drug/chem diabetes mellitus w
ketoacidosis w coma
4. E13.11 Oth diabetes mellitus with
Ketoacidosis with coma
5. E09.10 Drug/chem diabetes mellitus w
ketoacidosis w/o coma\n
Display Format (numeric, 1-4)\n
ICDFMT or ^TMP("ICDEXLK",$J,"ICDFMT")=<display format>\n
Controls the format of the terms and code presented
for selection on the selection list, 1-4,
default = 1\n
1 Fileman format, code and short text (default)\n
250.00 DMII WO CMP NT ST UNCNTR\n
2 Fileman format, code and description\n
250.00 DIABETES MELLITUS WITHOUT MENTION OF
COMPLICATION, TYPE II OR UNSPECIFIED
TYPE, NOT STATED AS UNCONTROLLED\n
3 Lexicon format, short text followed by code\n
DMII WO CMP NT ST UNCNTR (250.00)\n
4 Lexicon format, description followed by code\n
DIABETES MELLITUS WITHOUT MENTION OF
COMPLICATION, TYPE II OR UNSPECIFIED TYPE, NOT
STATED AS UNCONTROLLED (250.00)\n
Fileman Variables used\n
The following are FileMan local variables used by the Special
Lookup and should be NEWed or KILLed by the calling application\n
Input\n
X (Optional) User's input. If it exists, DIC(0)
should not contain "A" for "Ask"\n
DIC (Required) The file number or an explicit global
root in the form ^GLOBAL( or ^GLOBAL(X,Y,\n
DIC(0) (Optional) A string of alphabetic characters which
alter how DIC responds. At a minimum this string
must be set to null. (Required) Default value for
ICD files "AEM"\n
The following characters are applicable to a
versioned file\n
A Ask the entry; if erroneous, ask again
B Only the B index is used
E Echo information
F Forget the lookup value
I Ignore the special lookup program
O Only find one entry if it matches exactly
Q Question Input ??
S Suppresses display of .01
T Search until user selects or enters ^^
X EXact match required
Z Zero node in Y(0), external form in Y(0,0)\n
The following characters are NOT applicable to a
versioned file (not used)\n
C Versioned cross-references not turned off
K Primary Key not established
L Learning a new entry LAYGO not allowed
M Multiple-index lookup allowed
N Uppercase, IEN lookup allowed (not forced)
n ICD has no pure numeric entries
U All values are external
V Verification is not optional\n
DIC("A") (Optional) A prompt that is displayed prior to the
reading of the X input. If DIC("A") is not defined,
a prompt will be supplied by the special lookup
routine.\n
DIC("B") (Optional) The default answer which is presented to
the user when the lookup prompt is issued. If a
terminal user simply presses the Enter/Return key,
the DIC("B") default value will be used, and
returned in X. DIC("B") will only be used if it is
non-null.\n
DIC("S") (Optional) DIC("S") is a string of M code that DIC
executes to screen an entry from selection. DIC("S")
must contain an IF statement to set the value of $T.
Those entries that the IF sets as $T=0 will not be
displayed or selectable. When the DIC("S") code is
executed, the local variable Y is the internal
number of the entry being screened and the M naked
indicator is at the global level @(DIC_"Y,0)")\n
DIC("W") (Optional) An M command string which is executed
when DIC displays each of the entries that match the
user's input. The condition of the variable Y and of
the naked indicator is the same as for DIC("S").
WARNING: If DIC("W") is defined, it overrides the
display of the versioned identifiers for the file.
Thus, if DIC("W") is set it will suppress the
display of versioned data and there is a risk of
displaying unversioned data.\n
DIC("?N",<file>)=n (Optional) The number "n" should be an
integer set to the number of entries to be displayed
on the screen at one time when using "?" help in a
lookup.\n
FileMan Variables not used\n
DIC("DR")
DIC("PTRIX",<from>,<to>,<file>)
DIC("T")
DIC("V")
DIC("?PARAM",<file>,"INDEX")
DIC("?PARAM",<file>,"FROM",<subscript>)
DIC("?PARAM",<file>,"PART",<subscript>)\n
FileMan Variables KILLed\n
DLAYGO
DINUM\n
FileMan Variables Modified\n
If DIC(0) contains an "L" it will be removed\n
Output Variables\n
Always Returned\n
Y IEN ^ Code FileMan\n
If DIC(0) contains "Z"\n
Y(0) 0 Node FileMan
Y(0,0) Code FileMan
Y(0,1) $$ICDDX or $$ICDOP Non-FileMan
Y(0,2) Long Description Non-FileMan\n", "", "", "2014/07/11"], ["5774", "RAD/NUC MED PATIENT file data extract", "", "RADIOLOGY/NUCLEAR MEDICINE", "", "", "Withdrawn", "", "", "", "", "", ""], ["5775", "ORWTIU GET TIU CONTEXT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/01/31", "APPROVED", "Active", "Controlled Subscription", "", "
Returns the current notes view context for a user. ICB
would like to present the same notes context view as CPRS for consistency.", "ORWTIU GET TIU CONTEXT", "", "2012/03/13"], ["5776", "LISTEN~%ZISTCPS", "Routine", "KERNEL", "2012/03/05", "APPROVED", "Active", "Controlled Subscription", "", "", "", "%ZISTCPS", "2012/04/30"], ["5777", "FEE BASIS FILE 161 R", "File", "FEE BASIS", "2012/03/05", "APPROVED", "Active", "Controlled Subscription", "161", "\n
NwHIN Direct accesses the FEE BASIS PATIENT (#161) file to read.", "", "", "2012/03/29"], ["5778", "FEE BASIS FILE 161.2 R", "File", "FEE BASIS", "2012/03/05", "APPROVED", "Active", "Controlled Subscription", "161.2", "\n
NwHIN Direct accesses the FEE BASIS VENDOR (#161.2) file to read.", "", "", "2012/03/29"], ["5779", "FEE BASIS PUSH_NHIND79C CALL", "Routine", "NATIONAL HEALTH INFO NETWORK", "2012/03/05", "", "Withdrawn", "Controlled Subscription", "", "\n
Fee Basis call to PUSH^NHIND79C in order to push abstracted
data to NwHIN Direct for the creation of Form 7079.", "", "NHIND79C", ""], ["5780", "ICD CODING SYSTEM FILE", "File", "DRG GROUPER", "2012/03/05", "APPROVED", "Active", "Supported", "80.4", "
This is a static file containing information about ICD
coding systems. Applications may conduct FileMan lookups and point to this
file.\n
Use the API $$SINFO^ICDEX(IEN) to retrieve the information about an ICD Coding
System (ICR 5747)\n
Applications may not alter or add data to this file.\n", "", "", "2014/07/11"], ["5781", "Mixed Case", "Routine", "LEXICON UTILITY", "2012/03/08", "APPROVED", "Active", "Controlled Subscription", "", "
This API provides mixed case terminology primarily for
ICD-10 Lookup.\n", "", "LEXXM", "2014/07/11"], ["5782", "API TO UPDATE PT PROBLEMS WHEN SCT TO ICD MAPPINGS CHANGE", "Routine", "PROBLEM LIST", "2012/03/13", "", "Pending", "Private", "", "
This API supports the updating of patient problems when
Standards & Terminology Service (STS) updates a mapping between SNOMED CT and
ICD-9-CM.\n
When a clinician creates a Problem List entry using an unmapped SNOMED CT
concept, the entry in the PROBLEM file (#9000011) is saved with the ICD-9-CM
code 799.9 - OTHER UNKNOWN AND UNSPECIFIED CAUSE OF MORBIDITY OR MORTALITY,
and a bulletin is sent to STS informing them that an unmapped SNOMED CT
Concept has be used as a patient problem. STS will find the appropriate
mapping issued by the National Library of Medicine (NLM) and deploy that
mapping using NTRT. When the NTRT deployment finishes, the Clinical Lexicon
application will call SCTMAP^GMPLX1 to update all instances in the PROBLEM
file where the SNOMED CT concept has been filed with the ICD-9-CM code of
799.9, replacing the non-specific Diagnosis with the newly mapped ICD-9-CM
code.\n
NOTE: This API will be updated in GMPL*2*42 to accommodate either SNOMED
CT-to-ICD-9-CM or SNOMED CT-to-ICD-10-CM mappings.", "", "GMPLX1", ""], ["5783", "MILITARY SERVICE EPISODE API", "Routine", "REGISTRATION", "2012/03/20", "APPROVED", "Active", "Controlled Subscription", "", "
The HINQ (DVB) application and the Enrollment
Application System (EAS) have a need to obtain military service episode (MSE)
data from the PATIENT (#2) file. This can be accomplished by using the APIs
in military service episode utility routine, DGMSETUL.", "", "DGMSEUTL", "2024/04/04"], ["5784", "DBIA 5784 Duplicate Supply Check", "Routine", "OUTPATIENT PHARMACY", "2012/03/27", "APPROVED", "Active", "Private", "", "
The DBIA documents the API that CPRS can call to do a
duplicate Supply check against a patient's profile for orders being entered
through the Pharmacy dialogues in CPRS.", "", "PSODDPR8", "2012/10/02"], ["5785", "PRE CRCL VITALS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2012/03/28", "APPROVED", "Active", "Private", "", "
This function returns the age of a patient for use in
calculating Creatinine Clearance values.", "", "ORQPTQ4", "2014/07/23"], ["5786", "ACCESS TO STATUS INFORMATION", "File", "ORDER ENTRY/RESULTS REPORTING", "2012/03/29", "", "Withdrawn", "Private", "100", "
The purpose of this ICR is to grant Lab access to the
order status information in the CPRS ORDERS file (#100).\n
One usage of this status is in the pending order migration, where speed is of
the essence, so we are granting direct global read access.", "", "", ""], ["5787", "CURRENT LAB RESULTS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2012/04/03", "APPROVED", "Active", "Private", "", "
Returns patient's current laboratory results in an
array determined by input parameters.", "", "ORQQLR1", "2014/07/18"], ["5788", "BT DASHBOARD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/04/03", "", "Withdrawn", "Controlled Subscription", "", "
RPC VST1^ORWCV is used by the new Beneficiary Travel
Dashboard for patient selection", "", "", ""], ["5789", "Remove PROCEDURE field (#2006.5841,1) as identifier", "File", "1", "2012/04/13", "", "Withdrawn", "Private", "2006.584", "
IMAGING to remove PROCEDURE field (#2006.5841,1) as
identifier:\n
K ^DD(2006.5841,0,"ID",1)\n
There currently is no other way to remove a field as an identifier.", "", "", ""], ["5790", "LSRP Proxy User in File 200", "File", "KERNEL", "2012/04/24", "", "Pending", "Private", "200", "
The Lab System Re-engineering Project (LSRP) has a
requirement that the DIVISION and DEFAULT fields of the NEW PERSON file (#200)
be defined for the LSRP proxy user LRLAB,AUTOACCEPT at multi-divisional
facilities.", "", "", ""], ["5791", "DBIA5791 - Update Field #309 in File #44", "File", "SCHEDULING", "2012/04/30", "APPROVED", "Active", "Private", "44", "
To support delivery of the VA Point of Service (VPS
Kiosks), access to the HOSPITAL LOCATION file (#44) is requested in order to
update field #309 (CHECKED-IN) via a direct FileMan edit. This field will be
updated when a patient executes the CHECK-IN procedure via a Remote Procedure
call (RPC) at a VA Kiosk.", "", "", "2012/09/26"], ["5792", "DBIA5792 - $$FIND call in SDAM2", "Routine", "SCHEDULING", "2012/04/30", "APPROVED", "Active", "Private", "", "
To support delivery of the VA Point of Service (VPS
Kiosks), access to the API $$FIND^SDAM2() is requested in order to find all
the appointments for a patient on a given date.", "", "SDAM2", "2012/09/26"], ["5793", "Inpatient Medication NON-VERIFIED ORDERS (#53.1) file", "File", "INPATIENT MEDICATIONS", "2012/04/30", "APPROVED", "Active", "Private", "53.1", "
The Outpatient Pharmacy package requests read access to
the NON-VERIFIED ORDERS (#53.1) file using VA FileMan and direct reads.", "", "", "2018/01/22"], ["5794", "PSB VERSION CHECK", "Remote Procedure", "BAR CODE MED ADMIN", "2012/05/03", "", "Withdrawn", "Private", "", "\n
The RPC returns the current and previous version numbers.\n
INPUT PARAMETER DESCRIPTION:
No input parameters are passed.\n
RETURN PARAMETER DESCRIPTION:
(0) = Count
(1) = Current Gui Version^Previous Gui Version\n
Note: Previous GUI version may be blank.", "PSB VERSION CHECK", "", ""], ["5795", "PSB UTL XSTATUS SRCH", "Remote Procedure", "BAR CODE MED ADMIN", "2012/05/04", "", "Withdrawn", "Private", "", "\n
Utility to check the latest order activities of a patient.\n
INPUT:
^ piece 1 - DFN Patient's Internal Entry Number(required).
^ piece 2 - OrderNumber ON_V/U/P Inpatient Medications Package V.
5.0 Order Number.
^ piece 3 - Action (status) to search for.
^ piece 4 - A Time Frame of "X" followed by a number will indicate the
number of administrations to check.
A Time Frame set to "FREQ" will use the order's frequency.
A Time Frame set to "PRN", "On Call", or "One-Time" will show
activity over the past 72 hours by default.
A Time Frame value of "Continuous" uses two frequency
options.
1. If the frequency is <24 hours use the default of 72
hours.
2. If the frequency is >= 24 hour, look back 3.5 times
the frequency.
A Time Frame set to "" and not set to "FREQ" gives no
location found during activity error message.\n
Example call: D FNDACTV^PSBVDLU3(.results,"1234^1U^H^12")\n
RETURN PARAMETER DESCRIPTION:
Procedure will return the results to the GUI executable.\n
OUTPUT:
RESULTS(0)= Returned line count.
RESULTS(1)= Patient's location during activity. Free text room-bed and
ward location.
RESULTS(2)= Medication^ordernumber. Contains the IEN to the actual order
in PHARMACY PATIENT (#55) followed by a U for Unit Dose or V
for IV.
RESULTS(3)= Action fileman date&time.
RESULTS(4)= Scheduled administration fileman date&time. If a continuous
order, this field will contain the actual administration date
and time the medication was ordered for.", "", "", ""], ["5796", "PSB MAN SCAN FAILURE", "Remote Procedure", "BAR CODE MED ADMIN", "2012/05/04", "", "Withdrawn", "Private", "", "
Utility to Manage scanning failures. Procedure will
populate the BCMA Unable To Scan Log located in the database ^PSB(53.77) and
send off MailMan message if necessary.\n
INPUT:
There is one input parameter with two options:
For Wristband scanning failures a single value array PSBPARAM(0).
For medication scanning failures a two value array PSBPARAM(0) and
PSBPARAM(1).\n
PSBPARAM(0):
^ piece 1 - IEN (Patient's Internal Entry Number).
^ piece 2 - Order number (Only used with medication entries, not with the
Wristband input).
^ piece 3 - Reason for Unable to Scan.
^ piece 4 - User's Comment.
^ piece 5 - The type of scan event.
The value that is placed here is determined by the user's
actions when attempting to scan a medication/wristband during
an administration. Those types beginning with "M" are
events dealing with medications; those beginning with "W" are
events with wristbands. "*UAS" occur when the user actually
uses the "unable to scan" functionality to document
the activity. "*SCN" are types that occur during normal
scanning activities. The "*KEY" designates a type of event
where the user has by-passed the BCMA scanning system by
"keying", via the system's keyboard device.
BCMA input data:
"W" for Wristband with a value WSCN, WKEY, or WUAS
"M" for Medication with a value of MSCN, MKEY,or MUAS
^ piece 6 - "0" for unable to scan, "1" for keyed entry, or "2" for
scanned\n
PSBPARAM(1):
^ piece 1 - "DD" Dispense Drug, "ADD" Additive, "SOL" Solution
^ piece 2 - IEN (Internal Entry Number) of failed item\n
RETURN PARAMETER DESCRIPTION:
There is one parameter returned consisting of two values RESULTS(0) and
RESULTS(1).\n
OUTPUT:
RESULTS(0)=1
RESULTS(1)=1 (Successful)
or
RESULTS(1)="-1^Unable to Scan documentation NOT
successful!" (Unsuccessful)
or
RESULTS(1)="-1^Unable to Scan MAILGROUP NOT SETUP!" (Unsuccessful)", "", "", ""], ["5797", "DBIA5797 - Update File #41.41 by VPS", "File", "REGISTRATION", "2012/05/07", "APPROVED", "Active", "Controlled Subscription", "41.43", "
The VA Point of Service (VPS Kiosks) package needs
access to file #41.41 (Pre-Registration Audit) to update it after a veteran
has completed his/her pre-registration at a VA kiosk. The fields to be updated
will be #.01 (PATIENT), #1 (DATE CHANGED), and #2 (USER) via a direct FileMan
call to FILE^DICN.", "", "", "2012/11/09"], ["5798", "DBIA5798 - Update File #41.43 by VPS", "File", "REGISTRATION", "2012/05/07", "APPROVED", "Active", "Private", "41.43", "
The VA Point of Service (VPS Kiosks) package needs
access to file #41.43 (Pre-Registration Call Log) to update it after a veteran
has completed his/her pre-registration at a VA kiosk. The fields to be updated
will be #.01 (DATE CALLED), #1 (PATIENT NAME), #2 (USER), #3 (STATUS), and #5
(DIVISION) via a direct FileMan to ^DIE.", "", "", "2012/11/09"], ["5799", "DBIA5799 UPDATE OF FIELDS IN FILE #2", "File", "REGISTRATION", "2012/05/16", "APPROVED", "Active", "Private", "2", "
To support the delivery of the VA Point of Service (VPS
Kiosks) project, global access to the PATIENT file (#2) is being requested in
order to update demographic information for the patient's record. The record
to be updated will be identified by the internal entry number (DFN) in file
#2. New demographic information can result from the execution of the Remote
Procedure Call (RPC) "VPS EDIT PATIENT DEMOGRAPHIC" on a VPS kiosk at a local
VA hospital. The updates to the patient record are performed using Fileman's
Database Server (DBS) APIs.", "", "", "2012/11/29"], ["5800", "MODIFY PACKAGE REFERENCE", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2012/05/22", "APPROVED", "Active", "Private", "", "
For Lab Re-engineering, there is a need to break apart
orders which were combined, such as Sodium and Potassium, to a single lab
order.\n
Therefore, there is a need to be able to update the package reference only.", "", "ORMLR4", "2013/02/07"], ["5801", "ED LOG file data extract", "File", "EMERGENCY DEPARTMENT", "2012/05/25", "APPROVED", "Active", "Private", "230", "
This integration agreement will allow the DSS package
to obtain emergency room disposition information to be used in its data
extracts.", "", "", "2012/08/27"], ["5802", "TRACKING CODE file data extract", "File", "EMERGENCY DEPARTMENT", "2012/05/25", "APPROVED", "Active", "Private", "233.1", "
This integration agreement will allow the DSS package
to obtain emergency room disposition information to be used in its data
extracts.", "", "", "2012/07/03"], ["5803", "PHARMACY PATIENT file information for data extract", "File", "PHARMACY DATA MANAGEMENT", "2012/05/25", "APPROVED", "Active", "Private", "55", "
The decision support software (DSS) package had a need
to obtain specific information related to UNIT DOSE orders. This information
is in a multiple within the PHARMACY PATIENT file (#55).", "", "", "2012/07/03"], ["5804", "BCMA GUI IV PARAMETERS", "Routine", "BAR CODE MED ADMIN", "2012/05/25", "", "Pending", "Controlled Subscription", "", "
Bar Code Medication Administration (BCMA) contains BCMA
IV Parameters that are used to define the fields that, when edited in
Inpatient Medications order entry, invalidate previously printed IV labels.
The BCMA IV Parameters are maintained using the GUI BCMA Site Parameters
application. The BCMA IV Parameters are available to other applications via
this API.", "", "PSBINPT", ""], ["5805", "One Time Exception Domain File (#4.2) Write", "File", "MAILMAN", "2012/05/30", "APPROVED", "Active", "Private", "4.2", "
Integrated Billing application requesting onetime
exception write privileges to create new domains needed by Electronic
Insurance Identification module. The domains are being created by Integrated
Billing patch IB*2*457 and informational patch XM*DBA*176 will be released to
address documentation needs for the new domains.", "", "", "2012/06/05"], ["5806", "FB PROVIDER TO IB AUTOMATION", "Routine", "INTEGRATED BILLING", "2012/05/31", "APPROVED", "Active", "Private", "", "
This private agreement between FB and IB will allow Fee
Basis to file Fee Vendor and 5010 Providers to the IB NON/OTHER VA BILLING
PROVIDER (#355.93) file for paid Fee claims that are potentially billable by
IB. The call is made during a nightly process (option FB PAID TO IB) within
FB.", "", "IBCEP8C", "2012/07/11"], ["5807", "TIU GET LINKED TEMPLATE", "Routine", "TEXT INTEGRATION UTILITIES", "2012/06/11", "", "Pending", "Private", "", "
This private agreement between TIU and GMRC will allow
the Consult package to retrieve the template associated with a consult
service. The Healthcare Claims Processing System (HCPS) interface for
Purchased Care will use the standard templates created by the Non-VA Care
Coordination (NVCC) project to parse the Reason For Request field when
receiving consults from VistA.", "", "TIUSRVT1", ""], ["5808", "INSURANCE MULTIPLE ACCESS", "File", "INTEGRATED BILLING", "2012/06/11", "", "Withdrawn", "Private", "2.312", "
The VA POINT OF SERVICE (KIOSK) package needs Fileman
read access to the INSURANCE TYPE multiple of the PATIENT file (#2). The VPS
GET PATIENT DEMOGRAPHIC remote procedure call will retrieve data from this
multiple and return the data to the MDWS web service. MDWS will then push the
data to the Vecna Kiosk located a the local VAMC.\n", "", "", ""], ["5809", "CLIO TERM TYPE FILE", "File", "CLINICAL PROCEDURES", "2012/06/11", "APPROVED", "Active", "Private", "704.102", "", "", "", "2013/03/26"], ["5810", "CLIO OBS FILE", "File", "CLINICAL PROCEDURES", "2012/06/11", "APPROVED", "Active", "Private", "704.117", "", "", "", "2013/03/26"], ["5811", "CLIO OBS QUALIFIER FILE", "File", "CLINICAL PROCEDURES", "2012/06/11", "APPROVED", "Active", "Private", "704.118", "", "", "", "2013/03/26"], ["5812", "MAX LINES SEND/RECEIVE", "File", "MAILMAN", "2012/06/13", "APPROVED", "Active", "Controlled Subscription", "4.3", "
The Mental Health package requests permission to 'Read
with FileMan' the following fields from the MAILMAN SITE PARAMETERS file
(#4.3):
NETWORK - MAX LINES SEND (#8.3)
NETWORK - MAX LINES RECEIVE (#8.31)", "", "", "2018/05/01"], ["5813", "Add Availability Resource to WEB SERVER File (#18.12)", "File", "WEB SERVICES CLIENT", "2012/06/14", "APPROVED", "Active", "Private", "18.12", "
Pharmacy Data Management needs FILEMAN read/write
access for AUTHORIZED WEB SERVICES sub-file (#100) for WEB SERVER FILE
(#18.12). This includes the "B" cross-reference.", "", "", "2012/09/06"], ["5814", "Read access for WEB SERVICE FILE (#18.02)", "File", "WEB SERVICES CLIENT", "2012/06/15", "APPROVED", "Active", "Private", "18.02", "
Pharmacy Data Management needs FILEMAN read access for
WEB SERVICE FILE (#18.02).", "", "", "2012/09/06"], ["5815", "GIVE THIS DBIA A BETTER NAME THAN DBIA5815", "", "", "2012/06/18", "", "Pending", "", "", "", "", "", ""], ["5816", "XUS PKI GET UPN", "Remote Procedure", "KERNEL", "2012/06/25", "APPROVED", "Active", "Controlled Subscription", "", "
Allows retrieval of the SUBJECT ALTERNATIVE NAME field
(#501.2) in the NEW PERSON file (#200).", "XUS PKI GET UPN", "XUSER2", "2012/09/10"], ["5817", "Read/Update 41.42 file entries", "File", "REGISTRATION", "2012/07/17", "APPROVED", "Active", "Private", "41.42", "
The VA Point of Service (VPS) package needs access to
the PRE-REGISTRATION CALL LIST FILE (#41.42) to update it after a veteran has
completed pre-registration from a Vetlink Kiosk.\n", "", "", "2012/11/07"], ["5818", "HLO IFCAP API", "Routine", "HEALTH LEVEL SEVEN", "2012/07/18", "APPROVED", "Active", "Private", "", "
The IFCAP package requests private usage of an HLO API
(PORT2^HLOTLNK) to obtain the TCP/IP PORT (OPTIMIZED) field for a record in
the HL LOGICAL LINK (#870) file.\n
The port obtained from the HL Logical Link record will be used to set the
PARMS("PORT") input parameter prior to calling the supported HLO API
$$SENDONE^HLOAPI1(.MSG,.PARMS,.WHOTO,.ERROR).", "", "HLOTLNK", "2012/07/23"], ["5819", "IFCAP SET ID NODES DURING POST INSTALL", "File", "1", "2012/06/28", "APPROVED", "Active", "Private", "", "
IFCAP needs to add ID nodes to the Control Point
Activity file (#410) at the header (#410) and at the Item subfile (#410.02)
level in support of patch PRC*5.1*167 (eCMS Interface to IFCAP - Phase 1). As
KIDS does not have a mechanism to transport ID nodes of a file's Data
Dictionary without exporting the entire file definition, it is requested that
for this patch IFCAP be permitted to set the ID nodes via the post-int routine
PRC5167P. The proposed lines of code are as follows (without blank lines):\n
S ^DD(410,0,"ID","Z3")="D:$P($G(^(1)),U,8)]"""" EN^DDIOL(""Sent to
eCMS"",,""?0""),EN^DDIOL("" "",,""!?2"")"\n
S ^DD(410.02,0,"ID","Z2")="D:$P($G(@(DIC_+Y_"",4)"")),U,3)]""""
EN^DDIOL(""eCMS Item Line ID ""_$P(^(4),U,3),,""!?10"")"", "", "", "2012/07/02"], ["5820", "GIVE THIS DBIA A BETTER NAME THAN DBIA5820", "", "", "2012/06/28", "", "Pending", "", "", "", "", "", ""], ["5821", "CENSUS DATE", "File", "REGISTRATION", "2012/07/01", "APPROVED", "Active", "Private", "45.86", "", "", "", "2013/07/10"], ["5822", "CENSUS/DISCHARGE/MOVEMENT/SURGERY DATES", "File", "REGISTRATION", "2012/07/01", "APPROVED", "Active", "Private", "45", "", "", "", "2013/07/10"], ["5823", "XUS PKI SET UPN", "Remote Procedure", "KERNEL", "2012/07/11", "APPROVED", "Active", "Controlled Subscription", "", "
Allows updating of the SUBJECT ALTERNATIVE NAME field
(#501.2) in the NEW PERSON file (#200).", "XUS PKI SET UPN", "", "2012/09/10"], ["5824", "XU EPCS EDIT", "Remote Procedure", "KERNEL", "2012/07/11", "APPROVED", "Active", "Controlled Subscription", "", "
Creates an entry in the XUEPCS DATA file (#8991.6) that
serves as an audit log of changes made to data in fields in the NEW PERSON
file (#200) that are used in the electronic Prescribing of Controlled
Substances (e-PCS) functionality.", "XU EPCS EDIT", "", "2012/09/10"], ["5825", "FBAAVR5 for FBCS", "Routine", "FEE BASIS", "2012/07/23", "", "Retired", "Private", "", "
Access to the API FBAAVR5 API's for FBCS to generate
voucher batch messages to Central Fee when finalizing batches. Also to
generate the correct ICN when transmitting batches to Central Fee.", "", "FBAAVR5", "2012/09/14"], ["5826", "FBAAVR4 for FBCS", "Routine", "FEE BASIS", "2012/07/23", "", "Retired", "Private", "", "
Access to use API's in routine FBAAVR4 for FBCS", "", "FBAAVR4", "2012/09/14"], ["5827", "ACCESS TO FB1358 FOR FBCS", "Routine", "FEE BASIS", "2012/07/23", "APPROVED", "Active", "Private", "", "
Access to API's in the routine FB1358 for FBCS. Used
to manipulate 1358 values.", "", "FB1358", "2012/09/14"], ["5828", "ACCESS TO FBAADD1 FOR FBCS", "Routine", "FEE BASIS", "2012/07/23", "", "Retired", "Private", "", "", "", "FBAADD1", "2012/09/14"], ["5829", "ACCESS TO FBAARJP FOR FBCS", "Routine", "FEE BASIS", "2012/07/23", "", "Retired", "Private", "", "", "", "FBAARJP", "2012/09/14"], ["5830", "ACCESS TO FBAARR3 FOR FBCS", "Routine", "FEE BASIS", "2012/07/23", "", "Retired", "Private", "", "", "", "FBAARR3", "2012/09/14"], ["5831", "PATIENT FILE FIELDS", "File", "REGISTRATION", "2012/08/08", "APPROVED", "Active", "Private", "2", "
This ICR documents access to several Patient (#2) file
fields not supported by other ICRs or APIs for the VPS Kiosk project.", "", "", "2012/08/08"], ["5832", "LOCK MANAGER APIs", "Routine", "KERNEL", "2012/08/14", "APPROVED", "Active", "Supported", "", "", "", "XULMU", "2012/09/10"], ["5833", "CLINIC PHYSICAL LOCATION", "File", "SCHEDULING", "2012/08/14", "APPROVED", "Active", "Private", "44", "
The VA POINT OF SERVICE (KIOSK) package needs Fileman
read access to the PHYSICAL LOCATION field (10) of the HOSPITAL LOCATION file
(#44). The VPS GET PATIENT DEMOGRAPHIC remote procedure call will retrieve
data from this field and return the data to the Vecna Kiosk located at the
local VAMC.", "", "", "2012/08/20"], ["5834", "GIVE THIS DBIA A BETTER NAME THAN DBIA5834", "", "", "2012/08/20", "", "Pending", "", "", "", "", "", ""], ["5835", "PADP ACCESS TO 601.84 & 601.85", "File", "PATIENT ASSESSMENT DOCUM", "2012/08/27", "", "Withdrawn", "Private", "", "
The PADP package would like to be able to add Mental
Health Instrument Administrations and responses to files 601.84 & 601.85
respectively via Fileman calls. There are no documented APIs.", "", "", ""], ["5836", "DBIA5836", "File", "DRUG ACCOUNTABILITY", "2012/08/29", "APPROVED", "Active", "Private", "58.81", "
Outpatient Pharmacy requests read access to the DRUG
ACCOUNTABILITY file (#58.81) via the "AOP" x-reference to determine if an
outpatient prescription for a controlled substance has been posted.\n\n", "", "", "2014/09/03"], ["5837", "GIVE THIS DBIA A BETTER NAME THAN DBIA5837", "", "", "2012/08/30", "", "Pending", "", "", "", "", "", ""], ["5838", "SDAMEVT", "Routine", "SCHEDULING", "2012/08/30", "APPROVED", "Active", "Private", "", "
THE [VETERAN POINT OF SERVICE] CHECK-IN RPC CALLS
BEFORE,HANDLE, AFTER, AND EVT IN SDAMEVT TO ENSURE THAT ALL OTHER PROCESSES
REQUIRING NOTIFICATION OF THE CHECK-IN ACTIVITY ARE NOTIFIED.\n
Parameters in the RPC have the following mapping for VPS:
VPSDT -> SDT Patient's appt. date and time.
VPSCLIN -> SDCL IEN of clinic in HOSPITAL LOCATION file #44
VPSCIEN -> SDDA IFN for ^SC(CLINIC,"S",DATE,1,IFN)
SDCIHDL -> SDHDL Event handle", "", "SDAMEVT", "2012/10/12"], ["5839", "VPS PATIENT LOOKUP", "Routine", "REGISTRATION", "2012/08/30", "", "Withdrawn", "Controlled Subscription", "", "", "", "DPTLK1", ""], ["5840", "ICD-10 Suggestions", "Routine", "LEXICON UTILITY", "2012/09/06", "APPROVED", "Active", "Controlled Subscription", "", "
Supported APIs for the implementation of ICD-10. The
APIs in this ICR become effective on the date of release of patches
ICD*18.0*57 and LEX*2.0*80.\n", "", "LEX10CX", "2014/07/11"], ["5841", "GIVE THIS DBIA A BETTER NAME THAN DBIA5841", "", "", "2012/09/07", "", "Pending", "", "", "", "", "", ""], ["5842", "ADVERSE REACTION TRACKING FILE 120.8", "File", "ADVERSE REACTION TRACKING", "2012/09/07", "", "Pending", "Controlled Subscription", "120.8", "
Veterans Point of Service Kiosk requires access to
several fields in Patient Allergies File #120.8 that are not available from
the ^GMRADPT API or other File ICRs. The specific fields required for read
are:\n
.02 REACTANT (RFX), [0;2] 1 GMR ALLERGY (V), [0;3] 4
ORIGINATION DATE/TIME (RDX), [0;4] 5 ORIGINATOR (RP200'), [0;5] 10
REACTIONS (Multiple-120.81), [10;0]
.01 REACTION (MP120.83'), [0;1]
1 OTHER REACTION (F), [0;2] 22 ENTERED IN ERROR (S),
[ER;1] 23 DATE/TIME ENTERED IN ERROR (DX), [ER;2] 24 USER
ENTERING IN ERROR (P200'), [ER;3] 26 COMMENTS (Multiple-120.826),
[26;0]
.01 DATE/TIME COMMENT ENTERED (MD), [0;1]
1 USER ENTERING (P200'), [0;2]
1.5 COMMENT TYPE (S), [0;3]
2 COMMENTS (Multiple-120.8262), [2;0]
.01 COMMENTS (W), [0;1]", "", "", ""], ["5843", "READ FIELDS IN PATIENT ALLERGY FILE", "File", "ADVERSE REACTION TRACKING", "2012/09/07", "APPROVED", "Active", "Controlled Subscription", "120.8", "
Veterans Point of Service Kiosk requires access to
fields in Patient Allergies File #120.8 that are not available from ^GMRADPT
API or other file ICRs.\n
Read access is requested.", "", "", "2012/09/25"], ["5844", "XLFIPV (IP UTILITIES)", "Routine", "KERNEL", "2012/09/11", "APPROVED", "Active", "Supported", "", "
Use of the VistA XLFIPV IPv4 and IPv6 Utility
Application Programming Interfaces (APIs).\n
These APIs support the dual-stack protocol implementation as an IPv4-to-IPv6
transition technology per Internet Engineering Task Force (IETF) Request For
Comments (RFC) #4213.\n
They support input of IPv4 or IPv6 addresses either in standard form, or in a
hybrid form using IPV4-Mapped IPv6 addresses. In hybrid dual-stack
implementations the first 96-bits are written in the standard IPv6 format, and
the remaining 32 bits written in the dot-decimal notation of IPv4.\n
IP address output of the APIs will be in standardized IPv4 dot-decimal
notation or in expanded IPv6 notation, where the address is represented by 8
groups of 16-bit values, each represented as 4 hexadecimal digits and
separated by colons. The hexadecimal digits will be capitalized to facilitate
storage of IP addresses in a consistent form to simplify searches and reports.
The exception will be the IPv6 null address returned when the input is in an
invalid format, which is commonly represented as "::0".", "", "XLFIPV", "2014/01/14"], ["5845", "Consults by Service and Status", "File", "CONSULT/REQUEST TRACKING", "2012/09/17", "", "Retired", "Controlled Subscription", "123", "
Fee Basis Claims System reads fields from the
REQUEST/CONSULTATION file to gather a list of consults to display to the Fee
Basis staff to assist in the creation of authorizations for care related to
consults requests. The Fee Basis Claims System application will also extract
this information in a discrete format to help pre-populate the authorization
with information already present in the consult to assist in accuracy and
workflow.", "", "", "2014/06/03"], ["5846", "Clear ScreenMan Help Area", "Routine", "1", "2012/09/28", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DDS", "2012/11/05"], ["5847", "Write to ScreenMan Help Area", "Routine", "1", "2012/09/28", "APPROVED", "Active", "Controlled Subscription", "", "", "", "DDSMSG", "2012/11/05"], ["5848", "HL7 PKG ACCESS TO TASKMAN SITE PARAMETERS FILE", "File", "KERNEL", "2012/10/02", "APPROVED", "Active", "Private", "14.7", "
Configuration files of the HL7 package need to point to
the TASKMAN SITE PARAMETERS file (#14.7) to allow sites to configure HLO
processes to run on specific nodes. The node is read from the BOX-VOLUME PAIR
field (#.01) and used as an input parameter to Taskman.\n\n", "", "", "2013/01/17"], ["5849", "PADP Package Adding Health Factors", "File", "PCE PATIENT CARE ENCOUNTER", "2012/10/03", "", "Retired", "Private", "9999999.64", "
PADP Package version 1.1 needs to add 809 Health
Factors to the Health Factor file. They are in the ONS AA and ONS RA
namespace. They get added in the post-init for package NUPA 1.1.", "", "", ""], ["5850", "PADP READ OF ORDERS FILE TO GET ORDERS", "File", "ORDER ENTRY/RESULTS REPORTING", "2012/10/03", "", "Withdrawn", "Private", "100", "
The PADP package pulls in Today's orders and
Active/Pending orders via loops through ^OR(100,"AC". I would like to request
an ICR to allow this.", "", "", ""], ["5851", "PADP PULL OF ADMISSION INFO", "File", "REGISTRATION", "2012/10/03", "", "Withdrawn", "Private", "45", "
The PADP package pulls in the patient's last admission
info. It uses ICR 2090 (Access to ^DPGM("APTT1") and ^DPGM("APTT3")) to get
the admission date, but also does a GET1^DIQ call to file 405 to pull in the
patient's DIAGNOSIS [SHORT]. I would like to request an ICR to allow this.", "", "", ""], ["5852", "PADP PULL OF EMERGENCY CONTACT INFO", "File", "REGISTRATION", "2012/10/03", "", "Withdrawn", "Private", "2", "
The PADP package pulls in the patient's Emergency
Contact info from the Patient file (#2) and allows the user to change this
information. I would like to request an ICR to allow this. Global
^DPT(DFN,.33.\n
OAD^VADPT (IA 10061) is used to pull in most of the info except for the
emergency contact person's home & work phones which is obtained using
$$GET1^DIQ.\n
Any changes made to the emergency contact information in the PADP package is
also written back to the corresponding field in file 2 using DIE.", "", "", ""], ["5853", "PADP PACKAGE READING HEALTH FACTORS", "File", "PCE PATIENT CARE ENCOUNTER", "2012/10/03", "", "Withdrawn", "Private", "9999999.64", "
The PADP executables pull in a list of all ONS AA & ONS
RA Health Factors. This is a FIND^DIC call to file 9999999.64 in an RPC.
Global ^AUTTHF. I would like to request an ICR to allow this.", "", "", ""], ["5854", "PADP INTERACTION WITH MH ADMINISTRATIONS FILE", "File", "MENTAL HEALTH", "2012/10/03", "", "Withdrawn", "Private", "601.84", "
The PADP package sets data via Fileman into file 601.84
(MH ADMINISTRATIONS) when a CIWA or AUDIT-C is done via the program and not by
using the MH DLL. This was added in case a nurse cannot access the DLL for
some reason. A new record is created using FILE^DICN and then fields are
populated using DIE.\n
Data is also read from this file in order to create a note in TIU.", "", "", ""], ["5855", "PADP INTERACTION WITH MH ANSWERS FILE", "File", "MENTAL HEALTH", "2012/10/03", "", "Withdrawn", "Private", "601.85", "
The PADP package sets data via Fileman into file 601.85
(MH ANSWERS) when a CIWA or AUDIT-C is done via the program and not by using
the MH DLL. This was added in case a nurse cannot access the DLL for some
reason. A new record is created using FILE^DICN and then fields are populated
using DIE.", "", "", ""], ["5856", "TIU CREATE RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2012/10/04", "", "Withdrawn", "Private", "", "
The PADP package would like permission to use RPC TIU
CREATE RECORD. This is necessary in order to upload notes from PADP to TIU.", "TIU CREATE RECORD", "", ""], ["5857", "TIU CREATE ADDENDUM RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2012/10/04", "", "Withdrawn", "Private", "", "
The PADP package uses RPC TIU CREATE ADDENDUM RECORD in
order to create addendums to notes that the package uploads. I would like to
request permission to use it.", "TIU CREATE ADDENDUM RECORD", "", ""], ["5858", "TIU SIGN RECORD", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2012/10/04", "", "Withdrawn", "Private", "", "
The PADP package uses RPC TIU SIGN RECORD in order to
sign, from the package, notes that were just uploaded. I would like to request
permission to use it.", "TIU SIGN RECORD", "", ""], ["5859", "DG SENSITIVE RECORD ACCESS", "Remote Procedure", "REGISTRATION", "2012/10/04", "", "Withdrawn", "Private", "", "
The PADP package uses RPC DG SENSITIVE RECORD ACCESS in
order to check if the patient just accessed is sensitized. I would like to
request permission to use it.", "DG SENSITIVE RECORD ACCESS", "", ""], ["5860", "DG SENSITIVE RECORD BULLETIN", "Remote Procedure", "REGISTRATION", "2012/10/04", "", "Withdrawn", "Private", "", "
The PADP package uses RPC DG SENSITIVE RECORD ACCESS in
order to log access to patients whose record is sensitized. I would like to
request permission to use it.", "DG SENSITIVE RECORD BULLETIN", "", ""], ["5861", "GMV MANAGER", "Remote Procedure", "GEN. MED. REC. - VITALS", "2012/10/04", "", "Withdrawn", "Private", "", "
The PADP package uses RPC GMV MANAGER in order to pull
in qualifiers of vitals. The package uses these when the nurse enters vitals
for their patient. I would like to request permission to use it.", "GMV MANAGER", "", ""], ["5862", "GMV ADD VM", "Remote Procedure", "GEN. MED. REC. - VITALS", "2012/10/04", "", "Withdrawn", "Private", "", "
The PADP package uses RPC GMV ADD VM in order to upload
vitals. I would like to request permission to use it.", "GMV ADD VM", "", ""], ["5863", "ORQQVI2 VITALS VALIDATE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Withdrawn", "Private", "", "
The PADP package uploads Vitals to the vitals package
and uses RPC ORQQVI2 VITALS VALIDATE to validate the input. I would like to
request permission to use this.", "ORQQVI2 VITALS VALIDATE", "", ""], ["5864", "ORQQVI VITALS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Withdrawn", "Private", "", "
The PADP package uploads Vitals to the vitals package
and uses RPC ORQQVI VITALS to upload the input. I would like to request
permission to use this.", "ORQQVI VITALS", "", ""], ["5865", "ORWDX SAVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Withdrawn", "Private", "", "
The PADP package uploads Consults to the Consults
package and uses RPC ORWDX SAVE to upload the input. I would like to request
permission to use this.", "ORWDX SAVE", "", ""], ["5866", "ORWTPP GETCOS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Withdrawn", "Private", "", "
The PADP package requires that nursing students have a
cosigner for their note and uses RPC ORWTPP GETCOS to upload the input. I
would like to request permission to use this.", "ORWTPP GETCOS", "", ""], ["5867", "ORQQPXRM REMINDER DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Withdrawn", "Private", "", "
The PADP package allows users to view and resolve a
small list of reminders that may be due on a patient. It uses RPC ORQQPXRM
REMINDER DETAIL to view the detail. I would like to request permission to use
this.", "ORQQPXRM REMINDER DETAIL", "", ""], ["5868", "ORQQPXRM REMINDER INQUIRY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Retired", "Private", "", "
The PADP package allows users to view and resolve a
small list of reminders that may be due on a patient. It uses RPC ORQQPXRM
REMINDER DETAIL to view the reminders. I would like to request permission to
use this.", "ORQQPXRM REMINDER INQUIRY", "", ""], ["5869", "ORWPCE SAVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Withdrawn", "Private", "", "
The PADP package uploads a select group of applicable
Helath Factors and uses RPC ORWPCE SAVE to save the reminders. I would like to
request permission to use this.", "ORWPCE SAVE", "", ""], ["5870", "ORWRP GET DEFAULT PRINTER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/05", "", "Withdrawn", "Private", "", "
The PADP package gets the User's default printer by
using RPC ORWRP GET DEFAULT PRINTER. I would like to request permission to
use this.", "ORWRP GET DEFAULT PRINTER", "", ""], ["5871", "ORWORR AGET", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWORR AGET to obtain a raw
list of orders for a patient. I would like to request permission to use this.\n", "ORWORR AGET", "", ""], ["5872", "ORWORR GET4LST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWORR GET4LST in conjunction
with RPC ORWORR AGET to obtain a list of orders for a patient. I would like
to request permission to use this.", "ORWORR GET4LST", "", ""], ["5873", "ORWDAL32 DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWDAL32 DEF to obtain the
patient's allergies. I would like to request permission to use this.", "ORWDAL32 DEF", "", ""], ["5874", "ORWU CLINLOC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWDU CLINLOC in order to
obtain a list of clinics. I would like to request permission to use this.", "ORWU CLINLOC", "", ""], ["5875", "ORWDAL32 ALLERGY MATCH", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWDAL32 ALLERGY MATCH in
order to search for potential allergies for a patient. I would like to request
permission to use this.", "ORWDAL32 ALLERGY MATCH", "", ""], ["5876", "ORWU VALIDSIG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWU VALIDSIG in order to
validate a user's electronic signature. I would like to request permission to
use this.", "ORWU VALIDSIG", "", ""], ["5877", "ORWDX SEND", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWDX SEND in order to allow
the user to sign their note and consults from the package. I would like to
request permission to use this.", "ORWDX SEND", "", ""], ["5878", "ORWDAL32 SAVE ALLERGY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP Package uses RPC ORWDAL32 SAVE ALLERGY to save
new allergies. I would like to request permission to use this.", "ORWDAL32 SAVE ALLERGY", "", ""], ["5879", "ORWU DT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORWU DT in order to convert
dates. I would like to request permission to use this.", "ORWU DT", "", ""], ["5880", "ORQQPX GET DEF LOCATIONS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2012/10/11", "", "Withdrawn", "Private", "", "
The PADP package uses RPC ORQQPX GET DEF LOCATIONS in
order to help resolve reminders. I would like to request permission to use
this.", "ORQQPX GET DEF LOCATIONS", "", ""], ["5881", "PROBLEM LIST DATA", "Routine", "PROBLEM LIST", "2012/10/29", "", "Pending", "Controlled Subscription", "", "
This API is designed to work with the Clinical
Reminders Index, it returns data for a Problem List entry found in the Index.
The format of the call is PROBDATA^GMPLPXRM(DAS,.DATA).\n\n", "", "GMPLPXRM", "2012/11/15"], ["5882", "VEIL ORDER IN CPRS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2012/11/09", "", "Pending", "Private", "", "
The purpose of this API is to allow the Laboratory V5.2
to veil an order to discontinue the display on the Orders Tab only.", "", "ORUTL2", ""], ["5883", "GIVE THIS DBIA A BETTER NAME THAN DBIA5883", "", "", "2012/11/19", "", "Pending", "", "", "", "", "", ""], ["5884", "INFUSION INSTRUCTIONS (#53.47) FILE", "File", "PHARMACY DATA MANAGEMENT", "2012/11/19", "APPROVED", "Active", "Private", "53.47", "
Inpatient Medications requests read and write
permission to the INFUSION INSTRUCTIONS (#53.47) file.\n
This file is used to expand abbreviated free text entered in the INFUSION RATE
(#.08) field in the IV multiple (#100) in the PHARMACY PATIENT (#55) file.", "", "", "2014/05/30"], ["5885", "MOVESEG~HLOAPI", "Routine", "HEALTH LEVEL SEVEN", "2012/11/30", "", "Withdrawn", "Supported", "", "
These APIs are useful for building HL7 messages.\n", "", "HLOAPI", ""], ["5886", "BUILDHDR~HLOPBLD1", "Routine", "HEALTH LEVEL SEVEN", "2012/11/30", "APPROVED", "Active", "Supported", "", "
This API is used to build an MSH or BHS segment for an
HL7 message.\n\n", "", "HLOPBLD1", "2012/12/26"], ["5887", "VETERANS POINT OF SERVICE KIOSK CALL TO TIULP", "Routine", "TEXT INTEGRATION UTILITIES", "2012/12/06", "", "Withdrawn", "Private", "", "
Veteran's Point of Service (VPS) Kiosk needs to call
$$CANENTR^TIULP(TITLE) to verify that a Kiosk user has the required privileges
to create a TIU note with the Note title selected.", "", "TIULP", ""], ["5888", "VIC API", "Routine", "REGISTRATION", "2012/12/13", "APPROVED", "Active", "Controlled Subscription", "", "
Allows patient lookup based on VIC card value. The
value can be from a legacy VIC or a newer VIC 4.0 card. The value can be the
data from the swipe (magnetic stripe) input or the scan (barcode) of the card.
Using applications should not attempt to parse the card value but pass into
the API the whole card value and allow the API to parse the values needed.\n
Example of usage within M code:
R X:DTIME Q:'$T!(X=U)
X ^%ZOSF("EOFF") R X(1):1 X ^%ZOSF("EON")
D RPCVIC^DPTLK(.DFN,X)
I DFN<1 W !,"Patient not in database, use ADT options to load patient" Q\n
With this example the DFN is now defined to the patient.", "", "DPTLK", "2013/11/20"], ["5889", "DG VIC PATIENT LOOKUP", "Remote Procedure", "REGISTRATION", "2012/12/13", "", "Deferred (re)approval until a Release Occurs", "Controlled Subscription", "", "
NOTE: On 3/31/17, the status for ICR #5889 was changed
from Pending to Deferred (re)approval until a Release Occurs. DG*5.3*857
distributed the DG VIC PATIENT LOOKUP RPC but no known subscribers are
currently using the RPC. The ICR could be activated in the future when an
application requests to be added as a subscriber to the ICR.\n\n
Allows patient lookup based on VIC card value. The value can be from a legacy
or a newer VIC 4.0 card. The value can be the data from the swipe (magnetic
stripe) input or the scan (barcode) of the card. Using applications should
not attempt to parse the card value but pass into the RPC the whole card value
and allow the RPC to parse the values needed.\n
INPUT PARAMETER: DPTX PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 255 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
This should be the entire input from either the Magnetic Strip or the
Barcode.\n
RETURN PARAMETER DESCRIPTION:
If the patient is known locally the patient's DFN is returned. If not
then a -1 is returned.", "DG VIC PATIENT LOOKUP", "", ""], ["5890", "FIND NATURE OF ORDER", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2012/12/19", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this API is to provide a way for the
Pharmacy application(s) to retrieve the nature of order from a specified CPRS
order number.", "", "ORUTL3", "2014/07/25"], ["5891", "WEB SERVER File (#18.12) access", "File", "WEB SERVICES CLIENT", "2013/01/03", "APPROVED", "Active", "Private", "18.12", "
This agreement allows read-only access to the WEB
SERVER File (#18.12).", "", "", "2014/05/30"], ["5892", "DBIA5892", "Routine", "REGISTRATION", "2013/01/16", "", "Pending", "Private", "", "", "", "DGENA4", "2013/04/10"], ["5893", "RETRIEVE LINK DATA FOR PSIM", "File", "HEALTH LEVEL SEVEN", "2013/01/17", "APPROVED", "Active", "Private", "870", "
The MPI will provide a new RPC for PSIM/TK to call to
retrieve HL7 Logical Link file (#870) data, specifically the DNS DOMAIN
(#.08), TCP/IP address (#400.01) and TCP/IP Port (#400.02) for a specified
VistA instance or for all VistAs. Name: MPI HL7 LOGICAL LINK DATA Pass in
"ALL" or Station Number Returned: Station Number^DNS Name^TCP/IP
Address^TCP/IP Port for each entry required. If there isn't a link for that
station number, return error message.\n
No write to the records, only retrieving data using FileMan API, $$GET1^DIQ,
from entries of file #870 in the MPI account:\n
GLOBAL REFERENCE:
^HLCS(870,
.02 INSTITUTION
.08 DNS DOMAIN
400.01 TCP/IP ADDRESS
400.02 TCP/IP PORT
"C" X-REF", "", "", "2013/01/22"], ["5894", "DBIA5894", "Routine", "REGISTRATION", "2013/01/24", "APPROVED", "Active", "Private", "", "
This routine brings back encounter information for a
patient based on the input values defined by the calling application.
SCAN~DGSDU calls several supported APIs documented in ICR #2548.", "", "DGSDU", "2013/03/25"], ["5895", "PSS*1*174 POST INSTALL WITH DD(52.6", "File", "1", "2013/01/25", "APPROVED", "Active", "Private", "", "
This is a one-time ICR valid only for the Post-Install
Routine for patch PSS*1.0*174.\n
A new field STRENGTH (#19) has been added to the IV ADDITIVES File (#52.6).\n
The new STRENGTH (#19) field will be displayed on any lookup performed on the
IV ADDITIVES File (#52.6) by creating a new "W19" node by direct global set
into ^DD(52.6,0,"ID" by Post-Install Routine PSS0174.\n
^DD(52.6,0,"ID","W19") will be set to "W "" Additive Strength:
"",$S($P(^(0),U,15)="""":""N/A"", 1:$P(^(0),U,15)_""
""_$$GET1^DIQ(52.6,$P(^(0),U,3)_"","",2))"\n", "", "", "2013/02/04"], ["5896", "ORWRP PRINT REPORT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/01/31", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWRP PRINT REPORT", "ORWRPP", "2013/10/02"], ["5897", "TIU DOCUMENT CLASS TITLES QUERY", "File", "TEXT INTEGRATION UTILITIES", "2013/02/04", "APPROVED", "Active", "Controlled Subscription", "8925.1", "
This agreement permits Fileman reads of file 8925.1 to
find all the Titles under a particular Document Class and some of their
attributes.", "", "", "2013/02/04"], ["5898", "TIU DOCUMENT IEN", "Other", "TEXT INTEGRATION UTILITIES", "2013/02/05", "APPROVED", "Active", "Private", "", "", "", "", "2014/11/06"], ["5899", "IFCAP", "File", "KERNEL", "2013/02/05", "APPROVED", "Active", "Private", "200", "
Removal of PRCFA SUPERVISOR key from file #200 (NEW
PERSON) for terminated employees. Currently the key has a KEEP AT TERMINATE
set to YES and the key is changing (via patch PRC*5.1*168) KEEP AT TERMINATE
to NO. This will satisfy fiscal audits that show the key falsely assigned to
terminated employees.\n
This one-time key removal for terminated employees will be done by a post
install routine PRC168P that will flip the KEEP AT TERMINATE setting for PRCFA
SUPERVISOR key to NO and remove key from any terminated employee in file #200.\n", "", "", "2013/04/12"], ["5900", "IFCAP", "File", "KERNEL", "2013/02/06", "APPROVED", "Active", "Private", "19.1", "
Modification of PRCFA SUPERVISOR key field KEEP AT
TERMINATE from 'YES' to 'NO'. Currently the key has KEEP AT TERMINATE set to
YES and the key is changing (via patch PRC*5.1*168) KEEP AT TERMINATE to NO.
This will satisfy fiscal audits that show the key still assigned to terminated
employees.\n
This one-time field update of KEEP AT TERMINATE will be done by a post install
routine PRC168P that will flip the KEEP AT TERMINATE setting for the PRCFA
SUPERVISOR key to NO and remove the key from any terminated employee in file
#200.", "", "", "2013/04/12"], ["5901", "PROMPT USER FOR DIVISION", "Routine", "TEXT INTEGRATION UTILITIES", "2013/03/04", "APPROVED", "Active", "Private", "", "
Routine TIULA calls Registration routine VAUTOMA (ICR
#664) to prompt the user for one, many or all Medical Center (#40.8)
divisions. If one or many divisions are selected, routine TIULA modifies the
array returned by DIVISION~VAUTOMA to return the IEN from the Institution (#4)
file for the selected division(s).", "", "TIULA", "2013/04/10"], ["5902", "New Person Telephone and e-Mail Address", "File", "KERNEL", "2013/03/08", "", "Withdrawn", "Private", "200", "
IFCAP needs to extract contact information including
telephone numbers and e-mail address from user's record in the New Person file
(#200) for display and transmission via HL7 messages to external system.", "", "", ""], ["5903", "STATUS Portion of ORCSAVE2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2013/03/11", "APPROVED", "Active", "Private", "", "
This ICR allows the STATUS (#5) field of an order in
the ORDERS (#100) file to be set to a predetermined value depending on the
needs of the routine calling STATUS^ORCSAVE2.", "", "ORCSAVE2", "2013/03/27"], ["5904", "DG PRINT PATIENT LABEL", "Routine", "REGISTRATION", "2013/03/12", "APPROVED", "Active", "Private", "", "
Routine DGPLBL provides a generic patient demographics
label print that includes Patient Name, SSN, DOB and an optional inpatient
location (ward and bed). Support for various printer types (i.e. bar code,
laser, etc.) is provided using the CONTROL CODES (#3.2055) subfile of the
TERMINAL TYPE (#3.2) file. The control code mnemonics are documented in DBIA#
3435.", "", "DGPLBL", "2016/04/12"], ["5905", "DG PRINT WRISTBAND", "Routine", "REGISTRATION", "2013/03/18", "APPROVED", "Active", "Private", "", "", "", "DGPWB", "2015/04/10"], ["5906", "RESTRICT IV FLAG WRITE ACCESS", "File", "1", "2013/03/26", "APPROVED", "Active", "Private", "50.7", "
This request is to allow the Pharmacy Data Management
package to edit the IV FLAG field to restrict write access from Fileman.\n
This change will be used in patch PSS*1.0*150 only.\n", "", "", ""], ["5907", "DELETE FIELD 64 FROM FILE 399", "File", "1", "2013/03/26", "APPROVED", "Active", "Private", "399", "
This agreement is to make a fileman call to delete the
ICD DIAGNOSIS CODE field (#64) from the BILL/CLAIMS file (#399).\n
This agreement is only for patch IB*2.0*481.\n", "", "", "2013/03/26"], ["5908", "VBECS CPT ACCESS", "File", "CPT/HCPCS CODES", "2013/03/28", "APPROVED", "Retired", "Controlled Subscription", "81", "\n
Now covered by supported ICR #5408,CPT/HCPS Procedure File 81.
^ICPT(D0,0) CPT CODE 0;1 Read w/Fileman", "", "", "2013/04/15"], ["5909", "VPR use of BCMA Med Log", "File", "BAR CODE MED ADMIN", "2013/04/11", "APPROVED", "Active", "Private", "53.79", "
This agreement documents VPR read access to file
#53.79.\n
Several fields have been added to this ICR to document their use in patch
VPR*1*3; this patch was not released nationally and is not installed at any VA
site, but is available through OSEHRA.", "", "", "2018/01/16"], ["5910", "XWB IM HERE", "Remote Procedure", "RPC BROKER", "2013/05/02", "APPROVED", "Active", "Private", "", "", "XWB IM HERE", "", "2013/05/13"], ["5911", "ORWU16 USERINFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/05/02", "APPROVED", "Active", "Private", "", "", "ORWU16 USERINFO", "", "2013/05/15"], ["5912", "PSOREJP2", "Routine", "OUTPATIENT PHARMACY", "2013/05/09", "APPROVED", "Active", "Private", "", "
Retrieve the most recent last date of service and last
days supply from the previous prescription.", "", "PSOREJP2", "2013/07/23"], ["5913", "READ/WRITE ACCESS TO FILE #6914 (EQUIPMENT INV.)", "File", "ENGINEERING", "2013/05/14", "APPROVED", "Active", "Private", "6914", "
Request permission for READ/WRITE access via FileMan
calls to file #6914 in order to complete RPC queries from IntelligentInsites,
and to update the file in VistA when requested. This is part of the RTLS
National project to facilitate tracking equipment updates in Engineering,
while keeping IntelligentInsites with up to date information.", "", "VIAAEAD", "2014/06/27"], ["5914", "READ ACCESS TO FILE #6911 (EQUIPMENT CATEGORY)", "File", "ENGINEERING", "2013/05/15", "APPROVED", "Active", "Private", "6911", "
Request permission for READ access via FileMan calls to
file #6911 in order to complete RPC queries from IntelligentInsites. This is
part of the RTLS National project to facilitate tracking equipment updates in
Engineering, while keeping IntelligentInsites with up to date information.", "", "VIAAEUT", "2014/06/27"], ["5915", "READ ACCESS TO FILE #6928 (ENG SPACE)", "File", "ENGINEERING", "2013/05/15", "APPROVED", "Active", "Private", "6928", "
Request permission for READ access via FileMan calls to
file #6928 in order to complete RPC queries from IntelligentInsites. This is
part of the RTLS National project to facilitate tracking equipment updates in
Engineering, while keeping IntelligentInsites with up to date information.", "", "VIAAEUT", "2014/06/27"], ["5916", "READ ACCESS TO FILE #6917 (CATEGORY STOCK NUMBER)", "File", "ENGINEERING", "2013/05/15", "APPROVED", "Active", "Private", "6917", "
Request permission for READ access via FileMan calls to
file #6917 in order to complete RPC queries from IntelligentInsites. This is
part of the RTLS National project to facilitate tracking equipment updates in
Engineering, while keeping IntelligentInsites with up to date information.", "", "VIAAEAD", "2014/06/27"], ["5917", "READ ACCESS TO FILE #6914.1 (CMR)", "File", "ENGINEERING", "2013/05/15", "APPROVED", "Active", "Private", "6914.1", "
Request permission for READ access via FileMan calls to
file #6914.1 in order to complete RPC queries from IntelligentInsites. This is
part of the RTLS National project to facilitate tracking equipment updates in
Engineering, while keeping IntelligentInsites with up to date information.", "", "VIAAEAD", "2014/06/27"], ["5918", "READ ACCESS TO FILE #6912 (MANUFACTURER LIST FILE)", "File", "ENGINEERING", "2013/05/15", "APPROVED", "Active", "Private", "6912", "
Request permission for READ access via FileMan calls to
file #6912 in order to complete RPC queries from IntelligentInsites. This is
part of the RTLS National project to facilitate tracking equipment updates in
Engineering, while keeping IntelligentInsites with up to date information.", "", "VIAAEAD", "2014/06/27"], ["5919", "READ ACCESS TO FILE #6922 (ENGINEERING SECTION LIST)", "File", "ENGINEERING", "2013/05/15", "", "Withdrawn", "Private", "6922", "
Request permission for READ access via FileMan calls to
file #6922 in order to complete RPC queries from IntelligentInsites. This is
part of the RTLS National project to facilitate tracking equipment updates in
Engineering, while keeping IntelligentInsites with up to date information.", "", "VIAAEAD", ""], ["5920", "READ ACCESS TO FILE #6910 (ENG INIT PARAMETERS)", "File", "ENGINEERING", "2013/05/15", "APPROVED", "Active", "Private", "6910", "
Request permission for READ access via FileMan calls to
file #6910 in order to complete RPC queries from IntelligentInsites. This is
part of the RTLS National project to facilitate tracking equipment updates in
Engineering, while keeping IntelligentInsites with up to date information.", "", "VIAAEAD", "2014/06/27"], ["5921", "READ ACCESS TO FILE #441 (ITEM MASTER)", "File", "IFCAP", "2013/05/16", "APPROVED", "Active", "Private", "441", "
Request permission for READ access via FileMan calls to
file #441 in order to complete RPC queries from WaveMark. This is part of the
RTLS National project to facilitate tracking clinical supplies in the Cathlab
inventory point for GIP.", "", "VIAAIMUP", "2014/06/30"], ["5922", "READ ACCESS TO FILE #440 (VENDOR)", "File", "IFCAP", "2013/05/16", "APPROVED", "Active", "Private", "440", "
Request permission for READ access via FileMan calls to
file #440 in order to complete RPC queries from WaveMark. This is part of the
RTLS National project to facilitate tracking clinical supplies in the Cath lab
inventory point for GIP.", "", "VIAAIMUP", "2014/07/02"], ["5923", "READ/WRITE ACCESS TO FILE #445 (GENERIC INVENTORY)", "File", "IFCAP", "2013/05/16", "APPROVED", "Active", "Private", "445", "
Request permission for READ and WRITE access via
FileMan calls to file #445 in order to complete RPC queries from WaveMark.
This is part of the RTLS National project to facilitate tracking clinical
supplies in the Cathlab inventory point for GIP.", "", "VIAAIPDE", "2014/07/07"], ["5924", "DESCRIPTION UPDATE FOR 627.8 FILE", "File", "1", "2013/05/16", "APPROVED", "Active", "Private", "627.8", "
Important Note: This is a One-Time Agreement, just for
Patch YS*5.01*107.\n
Update of DESCRIPTION for File (#627.8) which is the DIAGNOSTIC RESULTS -
MENTAL HEALTH File to replace occurrences of 'ICD9' to 'ICD DIAGNOSIS' to
accommodate ICD-10 Remediation project for Patch YS*5.01*107. DESCRIPTION
will be updated using Post-Init routine YS107P.\n
Routine YS107P directly sets nodes in the File Description for File (#627.8).\n
End result should be as below:\n
^DIC(627.8,"%D",7,0)="""AE"" Xref - Type (DSM or ICD DIAGNOSIS), DFN, System
Dte, Dx, DFN."\n
^DIC(627.8,"%D",13,0)="""AG"" Xref - Type (DSM or ICD DIAGNOSIS), DFN, Dx,
IFN."", "", "", "2013/05/23"], ["5925", "IS PATIENT PREGNANT/LACTATING", "Routine", "WOMEN'S HEALTH", "2015/08/27", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to determine if a patient is pregnant or lactating on a specific date or on at
least one day within a date range.", "", "WVUTL11", "2017/11/17"], ["5926", "PREGNANCY AND LACTATION DATA", "Routine", "WOMEN'S HEALTH", "2013/06/05", "", "Withdrawn", "Supported", "", "
Returns current patient data from file 790.8 and 790.9.\n", "", "WVTDLPD", ""], ["5927", "EDIS POINTING TO FILE 1", "File", "1", "2013/06/05", "APPROVED", "Active", "Private", "1", "
The Adhoc worksheets and reports portions of EDIS
requests approval to point to the file of files (File #1). EDIS will only
point to files that belong to EDIS. This is to be used for building calls to
File Manager API's dynamically.", "", "", "2013/07/02"], ["5928", "DBIA 5928", "Routine", "REGISTRATION", "2013/06/18", "APPROVED", "Active", "Private", "", "
SUB^DGSAUTL returns the sub-categories associated with
either an admitting regulation or an appointment type. If none provided or
user times out then "NULL" will be returned.\n\n", "", "DGSAUTL", "2013/06/24"], ["5929", "ORWDX UNLOCK ORDER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/20", "APPROVED", "Active", "Private", "", "
Provides the ability to unlock an order to update
consult information.", "ORWDX UNLOCK ORDER", "", "2014/04/21"], ["5930", "ORWDCN32 DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/20", "", "Retired", "Private", "", "
Returns a set of Urgencies and places for use in
Consults.", "ORWDCN32 DEF", "", "2014/06/03"], ["5931", "ORQQCN URGENCIES", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/20", "", "Retired", "Private", "", "
Returns a list of available urgencies for a specific
Consult.\n
Fee Basis Claims System utilizes this RPC to provide users the ability to
update Consult information from within FBCS.", "ORQQCN URGENCIES", "", "2014/06/03"], ["5932", "Lab Access to Room-Bed Wards Which Can Assign Multiple", "File", "REGISTRATION", "2013/06/24", "APPROVED", "Active", "Private", "405.4", "\n\n
Lab has permission to access the ROOM-BED file (#405.4) WARD(S) WHICH CAN
ASSIGN Multiple.\n", "", "", "2013/06/28"], ["5933", "OREVNTX PAT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/25", "", "Withdrawn", "Private", "", "", "", "", ""], ["5934", "ORIMO IMOLOC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/26", "", "Withdrawn", "Private", "", "
via", "", "", ""], ["5935", "ORPRF ISIVQO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/26", "", "Withdrawn", "Private", "", "", "", "", ""], ["5936", "ORQQCN GET ORDER NUMBER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/03/06", "APPROVED", "Active", "Controlled Subscription", "", "
A new OR*3*392 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*392 patch is associated with the
VIAB*1*1 patch.\n
The following information is available about the RPC:\n
NAME: ORQQCN GET ORDER NUMBER TAG: GETORDER
ROUTINE: ORQQCN1 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns OERR order number for consult/procedure. INPUT PARAMETER: Consult ID
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 16 REQUIRED: YES", "ORQQCN GET ORDER NUMBER", "", "2014/03/06"], ["5937", "ORQQCN UNRESOLVED", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/26", "", "Withdrawn", "Private", "", "", "", "", ""], ["5938", "ORQQVI VITALS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/26", "", "Withdrawn", "Private", "", "", "ORQQVI VITALS", "", ""], ["5939", "ORVAA VAA", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/26", "APPROVED", "Active", "Private", "", "
This ICR was created for VIA. The RPC was used by MDWS,
and never previously documented in an ICR. Since MDWS already uses this RPC,
and VIA is responsible for exposing all RPCs used by MDWS, the CPRS
development team agrees to the use of the RPC.\n
For future subscribers there first needs to be a check for an RPC created in
the namespace that owns the data accessed by this RPC.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch. Patch
OR*3*495 modified this ICR and changed PARAMETER TYPE of REFERENCE to LITERAL.
This is in concordance with the VistA Security Remediation (VSR) project.\n
The following is the definition of the Remote Procedure: NAME: ORVAA VAA
TAG: VAA
ROUTINE: ORVAA RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns the policy name for a veteran with VA Advantage. If the veteran
does not have VA Advantage the return value will be 0. INPUT PARAMETER: DFN
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 255 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
The DFN is the veteran patient's Internal Entry Number in the PATIENT
file.", "ORVAA VAA", "", "2014/03/13"], ["5940", "ORWCIRN FACLIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/06/26", "APPROVED", "Active", "Private", "", "
A new OR*3*392 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*392 patch is associated with the
VIAB*1*1 patch.\n
The following information is available about the RPC:\n
NAME: ORWCIRN FACLIST TAG: FACLIST
ROUTINE: ORWCIRN RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns a list of the remote VA facilities at which the selected patient
has been seen.\n
This information is from the TREATING FACILITY LIST file which is not owned by
CPRS. This ICR is created to satisfy the needs of the VIA project which is
tasked to replace MDWS services. Future subscribers should check for an RPC
owned by the Registration package that owns this data.", "ORWCIRN FACLIST", "", "2014/03/13"], ["5941", "ORWDCN32 NEWDLG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5942", "ORWDPS2 QOGRP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "", "ORWDPS2 QOGRP", "", "2017/02/13"], ["5943", "ORWDX DISMSG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5944", "ORWDX LOADRSP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC gets responses from Order Dialog file (#101.41) or Order file (#100).\n
The following information is available about the RPC:\n
NAME: ORWDX LOADRSP TAG: LOADRSP
ROUTINE: ORWDX RETURN VALUE TYPE: ARRAY INPUT
PARAMETER: RSPID PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 1 INPUT PARAMETER: TRANS PARAMETER TYPE:
LITERAL
SEQUENCE NUMBER: 2", "ORWDX LOADRSP", "", "2014/03/17"], ["5945", "ORWDX LOCK", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC attempts to lock patient for ordering.\n
The following information is available about the RPC:
NAME: ORWDX LOCK TAG: LOCK
ROUTINE: ORWDX RETURN VALUE TYPE: SINGLE VALUE
DESCRIPTION:
RPC to attempt to lock patient for ordering (returns 1 if successful or 0
if unsuccessful).", "ORWDX LOCK", "", "2014/03/17"], ["5946", "Return displayable medication and radiopharmaceutical data", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2013/07/01", "APPROVED", "Active", "Private", "", "
This request grants permission to the VistA Imaging
application to call supported VistA Radiology/Nuclear Medicine (VistA RIS) API
for the purpose of exam specific medication and radiopharmaceutical data.\n
Medication and radiopharmaceutical data will display together with requisition
and report data (already displayed) as needed by radiology personnel when
viewing images through VistARad.", "", "RARTUTL", "2013/07/25"], ["5947", "ORWDX LOCK ORDER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC attempts to lock a specific order, returning a single value.
NAME: ORWDX LOCK ORDER TAG: LOCKORD
ROUTINE: ORWDX RETURN VALUE TYPE: SINGLE VALUE", "ORWDX LOCK ORDER", "", "2014/03/17"], ["5948", "ORWDX UNLOCK", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC attempts to unlock a patient for ordering, returning a single value.", "ORWDX UNLOCK", "", "2014/03/17"], ["5949", "ORWDX UNLOCK ORDER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5950", "ORWDX UNLOCK ORDER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5951", "ORWDX WRLST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "", "ORWDX WRLST", "", "2017/02/14"], ["5952", "ORWDX2 DCREASON", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5953", "ORWDXC DISPLAY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "", "ORWDXC DISPLAY", "", "2017/02/22"], ["5954", "ORWDXC ON", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5955", "ORWDXC SESSION", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC returns a list of Order Checks on Release Order.", "ORWDXC SESSION", "", "2014/03/17"], ["5956", "ORWDXM DLGNAME", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC returns name(s) of dialog and base dialog given IEN.", "ORWDXM DLGNAME", "", "2014/03/17"], ["5957", "ORWDXM MENU", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5958", "ORWDXM1 BLDQRSP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.", "ORWDXM1 BLDQRSP", "", "2014/03/17"], ["5959", "ORWDXM3 ISUDQO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5960", "ORWLRR ALLTESTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC returns array of Lab Test names starting with the input value FROM.", "ORWLRR ALLTESTS", "", "2014/03/17"], ["5961", "ORWLRR INTERIM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5962", "ORWLRR INTERIMG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC uses parameters to return the Lab package interim report for display.\n", "ORWLRR INTERIMG", "", "2014/03/17"], ["5963", "ORWORB KILL EXPIR MED ALERT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5964", "ORWORB KILL UNSIG ORDERS ALERT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5965", "ORWORB KILL UNVER MEDS ALERT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5966", "ORWORB KILL UNVER ORDERS ALERT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5967", "ORWORDG MAPSEQ", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC is for organizing a list of display groups from the Display Group
file (#100.98).", "ORWORDG MAPSEQ", "", "2014/03/17"], ["5968", "ORWPCE GETSVC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5969", "ORWPCE NOTEVSTR", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5970", "ORWPT INPLOC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5971", "ORWPT1 PCDETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC gets patient information from the Primary Care Managment Module of
the Scheduling package. This patient information is not owned by CPRS, but the
RPC is in the OR namespace.\n
Future subscribers should check for an RPC owned by the Scheduling package
that owns this data, instead of using this RPC.\n
The following information is available about the RPC:
NAME: ORWPT1 PCDETAIL TAG: PCDETAIL
ROUTINE: ORWPT1 RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns primary care detailed information about a patient.", "ORWPT1 PCDETAIL", "", "2014/03/13"], ["5972", "ORWPT1 PRCARE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC gets patient information from the Primary Care Management Module of
the Scheduling package. This patient information is not owned by CPRS, but the
RPC is in the OR namespace.\n
Future subscribers should check for an RPC owned by the Scheduling package
that owns this data, instead of using this RPC.\n
The following information is available about the RPC:\n
NAME: ORWPT1 PRCARE TAG: PRCARE
ROUTINE: ORWPT1 RETURN VALUE TYPE: SINGLE VALUE
DESCRIPTION:
Return primary care information for a patient in the format:
VAL=Primary Care Team^Primary Care Provider^Attending^MH Treatment
Coordinator
INPUT PARAMETER: dfn", "ORWPT1 PRCARE", "", "2014/03/13"], ["5973", "ORWRA IMAGING EXAMS1", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5974", "ORWRP2 HS COMPONENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC gets Health Summary Ad Hoc definitions from the Health Summary Type
and Health Summary Component file, owned by the Health Summary (GMTS) package.
The data is not owned by CPRS, but the RPC is in the OR namespace.\n
Future subscribers should check for an RPC owned by the Health Summary package
and use it, instead of using this RPC, if it exists.\n
The following information is available about the RPC:\n
NAME: ORWRP2 HS COMPONENTS TAG: COMP
ROUTINE: ORWRP2 RETURN VALUE TYPE: ARRAY
AVAILABILITY: RESTRICTED
DESCRIPTION:
This RPC returns an array of the ADHOC Health Summary components.
RETURN PARAMETER DESCRIPTION:
Here is the format of the returned array:
Y(i)=(1)I;IFN^(2)Component Name [Abb]^(3)Occ Limit^(4)Time
Limit^(5)Header
Name^(6)Hosp Loc Disp^(7)ICD Text Disp^(8)Prov Narr Disp^(9)Summary
Order", "ORWRP2 HS COMPONENTS", "", "2014/03/13"], ["5975", "ORWRP2 HS REPORT TEXT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC uses the Health Summary Component definitions owned by the Health
Summary package. The data accessed is not owned by CPRS, but the RPC is in the
OR namespace.\n
New subscribers must use their own Namespaced Context option to use this RPC
(not OR CPRS GUI CHART).\n
The following information is available about the RPC:\n
NAME: ORWRP2 HS REPORT TEXT TAG: REPORT
ROUTINE: ORWRP2 RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: RESTRICTED WORD WRAP ON: TRUE
DESCRIPTION:
This RPC is used to build the ADHOC Health Summary from an array of
pre-selected health summary components. INPUT PARAMETER: COMPS
PARAMETER TYPE: LIST
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
The input array is defined as:
COMPS(i)=array of subcomponents chosen, value is pointer at
^GMT(142,DA(1),1,DA)
Additional pieces may be present for components that require additional
parameters such as Headers, Time and Occurrence limits, and selected
file entries, such as selected lab tests.\n
COMPS(i)=segment^OccuranceLimit^TimeLimit^Header^segment^file^ifn^zeroth
node of file
RETURN PARAMETER DESCRIPTION:
Text array for report section is returned.
Also, the first line of the text contains the following information:
<number of current section being passed> ^ <last section number>", "ORWRP2 HS REPORT TEXT", "", "2014/03/13"], ["5976", "ORWSR RPTLIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC gets the list of Surgery Reports to use in CPRS, based on data owned
by the Surgery (SRO) package. The data is not owned by CPRS, but the RPC is in
the OR namespace.\n
Future subscribers should check for an RPC owned by the Surgery package and
use it, instead of using this RPC, if it exists.\n
The following information is available about the RPC:\n
NAME: ORWSR RPTLIST TAG: RPTLIST
ROUTINE: ORWSR RETURN VALUE TYPE: GLOBAL ARRAY
WORD WRAP ON: TRUE", "ORWSR RPTLIST", "", "2014/03/13"], ["5977", "ORWTIU CHKTXT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "APPROVED", "Active", "Private", "", "", "ORWTIU CHKTXT", "", "2014/04/07"], ["5978", "ORWTPD1 GETCSRNG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5979", "ORWTPD1 PUTCSRNG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5980", "ORWU NPHASKEY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5981", "ORWU1 NEWLOC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/01", "", "Withdrawn", "Private", "", "", "", "", ""], ["5982", "TIU GET LINKED PRF NOTES", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/02", "", "Withdrawn", "Private", "", "", "", "", ""], ["5983", "TIU GET PRF ACTIONS", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2013/07/02", "APPROVED", "Active", "Private", "", "", "TIU GET PRF ACTIONS", "", "2014/03/14"], ["5984", "TIU GET PRF TITLE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/02", "", "Withdrawn", "Private", "", "", "", "", ""], ["5985", "TIU HAS AUTHOR SIGNED?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2013/07/02", "APPROVED", "Active", "Private", "", "", "TIU HAS AUTHOR SIGNED?", "", "2014/03/14"], ["5986", "TIU ISPRF", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2013/07/02", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU ISPRF", "", "2014/03/14"], ["5987", "TIU ONE VISIT NOTE?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2013/07/02", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU ONE VISIT NOTE?", "", "2014/03/14"], ["5988", "XUS CVC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/07/02", "", "Withdrawn", "Private", "", "", "", "", ""], ["5989", "Read Access to Laboratory Anatomic Pathology fields", "File", "LAB SERVICE", "2013/07/03", "APPROVED", "Active", "Private", "63", "
This integration agreement provides VistA Imaging (VI)
with read-only access to LAB DATA file (#63) using VA FileMan APIs and it is
limited to fields:\n
EM field (#63, 2)
EM sub-file (#63.02)
DATE/TIME SPECIMEN TAKEN field (#63.02, .01)
DATE/TIME SPECIMEN RECEIVED field (#63.02, .1)
SPECIMEN SUBMITTED BY field (#63.02, .011)
BRIEF CLINICAL HISTORY field (#63.02, .013) sub-file
(#63.213)
PREOPERATIVE DIAGNOSIS field (#63.02, .014) sub-file
(#63.214)
OPERATIVE FINDINGS field (#63.02, .015) sub-file
(#63.205)
POSTOPERATIVE DIAGNOSIS field (#63.02, .016) sub-file
(#63.206)
DATE REPORT COMPLETED field (#63.02, .03)
EM ACC # field (#63.02, .06)
PHYSICIAN field (#63.02, .07)
REPORT RELEASE DATE field (#63.02, .11)
TIU REFERENCE DATE/TIME - EM field (#63.02, .16)
TIU REFERENCE DATE/TIME - EM sub-file (#63.49)
TIU ENTRY POINTER - EM field (#63.49, 1)\n
ORDERED TEST field (#63.02, .35)
ORDERED TEST sub-file (#63.52)
LAB TEST ORDERED field (#63.52, 13)\n
COMMENT field (#63.02, .99) sub-file
(#63.208)
COMMENT field (#63.208, .01)\n
GROSS DESCRIPTION field (#63.02, 1) sub-file
(#63.201)
MICROSCOPIC EXAMINATION field (#63.02, 1.1) sub-file
(#63.211)
EM DIAGNOSIS field (#63.02, 1.4) sub-file
(#63.204)\n
SPECIMEN field (#63.02, .012)
SPECIMEN sub-file (#63.202)
SPECIMEN field (#63.202, .01)
SPECIMEN TOPOGRAPHY field (#63.202, .06)\n
EPON BLOCK field (#63.202, 1)
EPON BLOCK sub-file (#63.2021)
EPON BLOCK field (#63.2021, .01)
DATE/TIME BLOCK PREPARED field (#63.2021, .02)
EM PROCEDURE field (#63.2021, 1)
EM PROCEDURE sub-file (#63.20211)
EM PROCEDURE field (#63.20211, .01)
SECTION PREPARED (#) field (#63.20211, .02)
DATE/TIME SECTION STAINED field (#63.20211, .04)
SECTIONS COUNTED(#) field (#63.20211, .06)
NEW SECTIONS field (#63.20211, .07)
SECTIONS EXAMINED(#) field (#63.20211, .08)
NON-CONTROL SLIDES COUNTED field (#63.20211, .09)
PRINTS MADE(#) field (#63.20211, .1)
PRINTS COUNTED(#) field (#63.20211, .12)
EXAMINED SECTIONS COUNTED(#) field (#63.20211, .13)\n\n\n\n
SURGICAL PATHOLOGY field (#63, 8)
SURGICAL PATHOLOGY sub-file (#63.08)
DATE/TIME SPECIMEN TAKEN field (#63.08, .01)
DATE/TIME SPECIMEN RECEIVED field (#63.08, .1)
SPECIMEN SUBMITTED BY field (#63.08, .011)
BRIEF CLINICAL HISTORY field (#63.08, .013) sub-file
(#63.813)
PREOPERATIVE DIAGNOSIS field (#63.08, .014) sub-file
(#63.814)
OPERATIVE FINDINGS field (#63.08, .015) sub-file
(#63.815)
POSTOPERATIVE DIAGNOSIS field (#63.08, .016) sub-file
(#63.816)
DATE REPORT COMPLETED field (#63.08, .03)
SURGICAL PATH ACC # field (#63.08, .06)
SURGEON/PHYSICIAN field (#63.08, .07)
REPORT RELEASE DATE/TIME field (#63.08, .11)
TIU REFERENCE DATE/TIME - SP field (#63.08, .16)
TIU REFERENCE DATE/TIME - SP sub-file (#63.19)
TIU ENTRY POINTER - SP field (#63.19, 1)\n
ORDERED TEST field (#63.08, .35)
ORDERED TEST sub-file (#63.53)
LAB TEST ORDERED field (#63.53, 13)\n
COMMENT field (#63.08, .99) sub-file
(#63.98)
COMMENT field (#63.98, .01)\n
GROSS DESCRIPTION field (#63.08, 1) sub-file
(#63.81)
MICROSCOPIC DESCRIPTION field (#63.08, 1.1) sub-file
(#63.811)
SURGICAL PATH DIAGNOSIS field (#63.08, 1.4) sub-file
(#63.802)\n
SPECIMEN field (#63.08, .012)
SPECIMEN sub-file (#63.812)
SPECIMEN field (#63.812, .01)
SPECIMEN TOPOGRAPHY field (#63.812, .06)\n
PARAFFIN BLOCK field (#63.812, 1)
PARAFFIN BLOCK sub-file (#63.8121)
PARAFFIN BLOCK ID field (#63.8121, .01)
DATE/TIME BLOCK PREPARED field (#63.8121, .02)
STAIN/PROCEDURE field (#63.8121, 1)
STAIN/PROCEDURE sub-file (#63.8122)
STAIN/PROCEDURE field (#63.8122, .01)
SLIDES PREPARED (#) field (#63.8122, .02)
CONTROL SLIDES (#) field (#63.8122, .03)
DATE/TIME SLIDES STAINED field (#63.8122, .04)
SLIDES COUNTED (#) field (#63.8122, .06)
LABELS TO PRINT field (#63.8122, .07)
NON-CONTROL SLIDES COUNTED field (#63.8122, .09)\n
PLASTIC BLOCK field (#63.812, 2)
PLASTIC BLOCK sub-file (#63.822)
PLASTIC BLOCK ID field (#63.822, .01)
DATE/TIME BLOCK PREPARED field (#63.822, .02)
PLASTIC STAIN/PROCEDURE field (#63.822, 1)
PLASTIC STAIN/PROCEDURE sub-file (#63.823)
PLASTCI STAIN/PROCEDURE field (#63.823, .01)
PLASTIC SLIDES PREPARED (#) field (#63.823, .02)
CONTROL SLIDES (#) field (#63.823, .03)
DATE/TIME SLIDES STAINED field (#63.823, .04)
SLIDES COUNTED (#) field (#63.823, .06)
LABELS TO PRINT field (#63.823, .07)
NON-CONTROL SLIDES COUNTED field (#63.823, .09)\n
FROZEN TISSUE BLOCK field (#63.812, 3)
FROZEN TISSUE BLOCK sub-file (#63.824)
FROZEN COUNTED field (#63.824, .01)
DATE/TIME FROZEN PREPARED field (#63.824, .02)
STAIN/PROCEDURE field (#63.824, 1)
STAIN/PROCEDURE sub-file (#63.825)
STAIN/PROCEDURE field (#63.825, .01)
SLIDES PREPARED (#) field (#63.825, .02)
CONTROL SLIDES (#) field (#63.825, .03)
DATE/TIME SLIDES STAINED field (#63.825, .04)
SLIDES COUNTED (#) field (#63.825, .06)
LABELS TO PRINT field (#63.825, .07)
NON-CONTROL SLIDES COUNTED field (#63.825, .09)\n\n\n
CYTOPATHOLOGY field (#63, 9)
CYTOPATHOLOGY sub-file (#63.09)
DATE/TIME SPECIMEN TAKEN field (#63.09, .01)
DATE/TIME SPECIMEN RECEIVED field (#63.09, .1)
SPECIMEN SUBMITTED BY field (#63.09, .011)
BRIEF CLINICAL HISTORY field (#63.09, .013) sub-file
(#63.913)
PREOPERATIVE DIAGNOSIS field (#63.09, .014) sub-file
(#63.914)
OPERATIVE FINDINGS field (#63.09, .015) sub-file
(#63.905)
POSTOPERATIVE DIAGNOSIS field (#63.09, .016) sub-file
(#63.906)
DATE REPORT COMPLETED field (#63.09, .03)
CYTOPATH ACC # field (#63.09, .06)
PHYSICIAN field (#63.09, .07)
REPORT RELEASE DATE/TIME field (#63.09, .11)
TIU REFERENCE DATE/TIME - CY field (#63.09, .16)
TIU REFERENCE DATE/TIME - CY sub-file (#63.47)
TIU ENTRY POINTER - CY field (#63.47, 1)\n
ORDERED TEST field (#63.09, .35)
ORDERED TEST sub-file (#63.51)
LAB TEST ORDERED field (#63.51, 13)\n
COMMENT field (#63.09, .99) sub-file
(#63.908)
COMMENT field (#63.908, .01)\n
GROSS DESCRIPTION field (#63.09, 1) sub-file
(#63.91)
MICROSCOPIC EXAMINATION field (#63.09, 1.1) sub-file
(#63.911)
CYTOPATHOLOGY DIAGNOSIS field (#63.09, 1.4) sub-file
(#63.903)\n
SPECIMEN field (#63.09, .012)
SPECIMEN sub-file (#63.902)
SPECIMEN field (#63.902, .01)
SPECIMEN TOPOGRAPHY field (#63.902, .06)
SMEAR PREP field (#63.902, 1)
SMEAR PREP sub-file (#63.9121)
SMEAR PREP field (#63.9121, .01)
STAIN/PROCEDURE field (#63.9121, 1)
STAIN/PROCEDURE sub-file (#63.9122)
STAIN/PROCEDURE field (#63.9122, .01)
SLIDES PREPARED (#) field (#63.9122, .02)
CONTROL SLIDES (#) field (#63.9122, .03)
DATE/TIME SLIDES STAINED field (#63.9122, .04)
SLIDES COUNTED (#) field (#63.9122, .06)
LABELS TO PRINT field (#63.9122, .07)
SLIDES SCREENED (#) field (#63.9122, .08)
NON-CONTROL SLIDES COUNTED field (#63.9122, .09)\n
CELL BLOCK field (#63.902, 2)
CELL BLOCK sub-file (#63.922)
CELL BLOCK field (#63.922, .01)
CELL BLOCK STAIN field (#63.922, 1)
CELL BLOCK STAIN sub-file (#63.923)
CELL BLOCK STAIN field (#63.923, .01)
SLIDES PREPARED (#) field (#63.923, .02)
CONTROL SLIDES (#) field (#63.923, .03)
DATE/TIME SLIDES STAINED field (#63.923, .04)
SLIDES COUNTED (#) field (#63.923, .06)
LABELS TO PRINT field (#63.913, .07)
SLIDES SCREENED (#) field (#63.923, .08)
NON-CONTROL SLIDES COUNTED field (#63.923, .09)\n
MEMBRANE FILTER field (#63.902, 3)
MEMBRANE FILTER sub-file (#63.924)
MEMBRANE FILTER field (#63.924, .01)
MEMBRANE FILTER STAIN field (#63.924, 1)
MEMBRANE FILTER STAIN sub-file (#63.9241)
MEMBRANE FILTER STAIN field (#63.9241, .01)
SLIDES PREPARED (#) field (#63.9241, .02)
CONTROL SLIDES (#) field (#63.9241, .03)
DATE/TIME SLIDES STAINED field (#63.9241, .04)
SLIDES COUNTED (#) field (#63.9241, .06)
LABELS TO PRINT field (#63.9241, .07)
SLIDES SCREENED (#) field (#63.9241, .08)
NON-CONTROL SLIDES COUNTED field (#63.9241, .09)\n
PREPARED SLIDES field (#63.902, 4)
PREPARED SLIDES sub-file (#63.9024)
PREPARED SLIDES field (#63.9024, .01)
PREPARED SLIDES STAIN field (#63.9024, 1)
PREPARED SLIDES STAIN sub-file (#63.90241)
PREPARED SLIDES STAIN field (#63.90241, .01)
SLIDES PREPARED (#) field (#63.90241, .02)
CONTROL SLIDES (#) field (#63.90241, .03)
DATE/TIME SLIDES STAINED field (#63.90241, .04)
LABELS TO PRINT field (#63.90241, .07)
SLIDES COUNTED (#) field (#63.90241, .06)
SLIDES SCREENED (#) field (#63.90241, .08)
NON-CONTROL SLIDES COUNTED field (#63.90241, .09)\n
CYTOSPIN field (#63.902, 5)
CYTOSPIN sub-file (#63.9025)
CYTOSPIN field (#63.9025, .01)
CYTOSPIN STAIN field (#63.9025, 1)
CYTOSPIN STAIN sub-file (#63.90251)
CYTOSPIN STAIN field (#63.90251, .01)
SLIDES PREPARED (#) field (#63.90251, .02)
CONTROL SLIDES (#) field (#63.90251, .03)
DATE/TIME SLIDES STAINED field (#63.90251, .04)
SLIDES COUNTED (#) field (#63.90251, .06)
LABELS TO PRINT field (#63.90251, .07)
SLIDES SCREENED (#) field (#63.90251, .08)
NON-CONTROL SLIDES COUNTED field (#63.90251, .09)", "", "", "2013/09/20"], ["5990", "ICD SEARCH API FILE", "File", "SURGERY", "2013/07/10", "", "Pending", "Supported", "130.4", "
This file contains the ICD and Procedure API
references. These allow applications to call the correct search API's based
on application parameters that control the type of search. This allows the
search API's to be controlled by file entries rather than having to hard code
the calls.", "", "", ""], ["5991", "READ B CROSS REFERENCE OF PRF NATIONAL FLAG FILE", "File", "REGISTRATION", "2013/07/17", "", "Pending", "Private", "26.15", "
Health Summary (GMTS) requires read-only access to
^DGPF(26.15,"B" in order to retrieve the name of each National Patient Record
Flag. These names are used to retrieve and subsequently display flag
assignment information for inactive PRF assignments.", "", "", "2013/10/17"], ["5992", "EC FILER", "Remote Procedure", "EVENT CAPTURE", "2013/07/18", "", "Pending", "Private", "", "
A general purpose Event Capture filer used when filing
data into ECS files", "EC FILER", "", ""], ["5993", "RTLS POINTING TO FILE 1", "File", "1", "2013/07/23", "APPROVED", "Active", "Private", "1", "
The Real Time Location System (RTLS) is requesting
approval to point to the file of files (#1), field FILE ID (#1), in the
PENDING RTLS EVENTS file (#6930). This is to be used for building calls to
File Manager API'S dynamically.", "", "", "2014/06/30"], ["5994", "DBIA5994", "Routine", "IMAGING", "2013/07/29", "APPROVED", "Active", "Private", "", "
VistA Imaging gives permission to Laboratory Package to
call CANCEL^MAGT7MA, EDIT^MAGT7MA, NEW^MAGT7MA, REPORT^MAGT7MA . These calls
create VistA Imaging HL7 DICOM PACS messages pertain to Anatomic Pathology
order updates. The messages are stored in PACS MESSAGE file (#2006.5) and are
processed by VistA Imaging DICOM Text gateway.", "", "MAGT7MA", "2013/09/27"], ["5995", "CLIO OBS SET FILE", "File", "CLINICAL PROCEDURES", "2013/07/29", "APPROVED", "Active", "Private", "704.116", "", "", "", "2014/01/14"], ["5996", "CLIO OBS SET OBS PAIR FILE", "File", "CLINICAL PROCEDURES", "2013/07/29", "APPROVED", "Active", "Private", "", "", "", "", "2014/01/14"], ["5997", "DBA5997", "Routine", "IMAGING", "2013/07/30", "APPROVED", "Active", "Private", "", "
VistA Imaging gives permission to Laboratory Package to
call ADD^MAGTP005", "", "MAGTP005", "2013/09/20"], ["5998", "GIVE THIS DBIA A BETTER NAME THAN DBIA5998", "", "", "2013/07/30", "", "Pending", "", "", "", "", "", ""], ["5999", "CLIO OBS FLOWSHEET SUPP PAGE FILE", "File", "CLINICAL PROCEDURES", "2013/07/30", "APPROVED", "Active", "Private", "", "", "", "", "2014/01/14"], ["6000", "MAGV GET IRRADIATION DOSE", "Routine", "IMAGING", "2013/07/31", "APPROVED", "Active", "Private", "", "
The TAG^ROUTINE documented will return the attributes
for the irradiation instance related to the patient and the procedure.", "", "MAGVRD03", "2013/08/14"], ["6001", "LRLAB security key", "Other", "LAB SERVICE", "2013/08/01", "APPROVED", "Active", "Private", "", "
This integration agreement allows use of LRLAB security
key.", "", "", "2013/09/20"], ["6002", "DGPFMPI", "Routine", "REGISTRATION", "2013/08/01", "APPROVED", "Active", "Private", "", "
This routine contains a function call for use by MPIF
to get the Category I flags from each VistA treatment facility that sees the
patient.\n
The following summarizes the process flow where MPIF will call this function:\n
First, a patient is added to the local VA system and a background job called
VAFC BATCH UPDATE JOB runs regularly on the VA system which assigns local
ICNs. Second, Once the local ICN is assigned, a background job called MPIF
LOC/MIS ICN RES runs (scheduled to run regularly in the background on the VA
system). This background job gets the national ICN and populates the
patient's treating facilities in the Treating Facility List file (#391.91).
After the Treating Facilities are added for the patient, the MPIF logic will
make a function call to the EN1^DGPFMPI routine documented in this ICR.", "", "DGPFMPI", "2013/08/21"], ["6003", "DBIA6003", "File", "LAB SERVICE", "2013/08/06", "APPROVED", "Active", "Private", "68", "
This agreement provides access to Laboratory patient
ID, date and accession number.", "", "", "2013/09/20"], ["6004", "READ STANDARD REPORTS File (#74.1)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2013/08/06", "APPROVED", "Active", "Private", "74.1", "
Imaging requests read access to the STANDARD REPORTS
File (#74.1) to allow the Hybrid DICOM Gateway Importer application to display
the standard report data for user selection when reconciling imported studies.\n", "", "", "2013/08/14"], ["6005", "READ DIAGNOSTIC CODES File (#78.3)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2013/08/06", "APPROVED", "Active", "Controlled Subscription", "78.3", "
Imaging requests read access to the DIAGNOSTIC CODES
File (#78.3) to allow the Hybrid DICOM Gateway Importer application to display
diagnostic code data for selection by users when reconciling imported studies.\n", "", "", "2013/08/14"], ["6006", "IMAGING ABNORMAL ALERT TRIGGER", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2013/08/06", "APPROVED", "Active", "Private", "", "
Imaging requests permission to call two elements of the
RA package alert handling code for DIAGNOSTIC CODE alert generation.", "", "RARTE7", "2013/08/14"], ["6007", "READ IMAGING LOCATIONS File (#79.1)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2013/08/06", "APPROVED", "Active", "Private", "79.1", "
Imaging requests read access to the IMAGING LOCATIONS
File (#79.1) to allow the Hybrid DICOM Gateway Importer application data for
selection by users when reconciling imported studies.", "", "", "2013/08/14"], ["6008", "DBIA6008 READ ACCESS TO FILE 200", "File", "KERNEL", "2013/08/08", "", "Withdrawn", "Private", "200", "
Retrieves all authorized DSS Unit IENs from NEW PERSON
file using "EC" cross reference. ^VA(200,D0,"EC",DSS Unit IEN)", "", "", ""], ["6009", "DBIA6009 READ ACCESS TO FILE 720.3", "File", "EVENT CAPTURE", "2013/08/08", "APPROVED", "Active", "Private", "720.3", "
MHV Secure Messaging - Work Load Credit functionality
allows users to save the workload credit using the assigned DSS units, and
stores the record in Event Capture System. The use of the DSS units is the
same as in ECS, users have access to link their work to DSS units that send
the record to PCE, as well as historical DSS units for historical workload
credit forms that do not send the information to PCE. To implement this
functionality, MHV SM reads files and calls existing APIs from Event Capture
System.\n
MyHealtheVet (MHV) uses the "AP" cross reference in EC EVENT CODE SCREENS File
(#720.3) to get DSS Units, Categories, Procedures and IEN values of a location
specified in MHV Secure Messaging front end. Using IEN of the zero node, MHV
references the fields Inactive Date, Procedure and Synonym from file (#720.3).
If data in ^ECJ(D0,0) exists, Inactive Date is retrieved to see if Procedure
is active or not. ^ECJ(D0,'PRO') node is used to retrieve Synonym and
Procedure Name.
^ECJ("AP",Location IEN,DSS Unit IEN,Cateogry,Procedure, IEN)", "", "", "2013/11/07"], ["6010", "DBIA6010-EVENT CAPTURE API-ECUERPC", "Routine", "EVENT CAPTURE", "2013/08/08", "APPROVED", "Active", "Private", "", "
MHV Secure Messaging - Work Load Credit functionality
allows users to save the workload credit using the assigned DSS units, and
stores the record in Event Capture System. The use of the DSS units is the
same as in ECS, users have access to link their work to DSS units that send
the record to PCE, as well as historical DSS units for historical workload
credit forms that do not send the information to PCE. To implement this
functionality, MHV SM reads files and calls existing APIs from Event Capture
System.\n
EC routine ELIG^ECUERPC is used to retrieve Patient Eligibility details. This
routine is also called via RPC [EC GETPATELIG].", "", "ECUERPC", "2013/11/07"], ["6011", "DBIA6011-EVENT CAPTURE API-ECUERPC1-PATCLAST", "Routine", "EVENT CAPTURE", "2013/08/08", "APPROVED", "Active", "Private", "", "
MHV Secure Messaging - Work Load Credit functionality
allows users to save the workload credit using the assigned DSS units, and
stores the record in Event Capture System. The use of the DSS units is the
same as in ECS, users have access to link their work to DSS units that send
the record to PCE, as well as historical DSS units for historical workload
credit forms that do not send the information to PCE. To implement this
functionality, MHV SM reads files and calls existing APIs from Event Capture
System.\n
EC routine PATCLAST^ECUERPC1 is used to retrieve Patient status and
Classification data. This routine is also called via RPC [EC GETPATCLASTAT].", "", "ECUERPC1", "2017/01/10"], ["6012", "DBIA6012-EVENT CAPTURE API-ECFLRPC", "Routine", "EVENT CAPTURE", "2013/08/08", "APPROVED", "Active", "Private", "", "
MHV Secure Messaging - Work Load Credit functionality
allows users to save the workload credit using the assigned DSS units, and
stores the record in Event Capture System. The use of the DSS units is the
same as in ECS, users have access to link their work to DSS units that send
the record to PCE, as well as historical DSS units for historical workload
credit forms that do not send the information to PCE. To implement this
functionality, MHV SM reads files and calls existing APIs from Event Capture
System via VistA's HL7 interface. Event Capture routine ECFLRPC is used to
file data in Event Capture Patient File (#721) and it is called from the My
HealtheVet HL7 filer routine.\n\n
EC routine FILE^ECFLRPC is used to file data in Event Capture Patient File
(#721).", "", "ECFLRPC", "2015/02/25"], ["6013", "DBIA6013-READ ACCESS TO DSS UNIT FILE, #724", "File", "EVENT CAPTURE", "2013/08/08", "APPROVED", "Active", "Private", "724", "
MHV Secure Messaging - Work Load Credit functionality
allows users to save the workload credit using the assigned DSS units, and
stores the record in Event Capture System. The use of the DSS units is the
same as in ECS, users have access to link their work to DSS units that send
the record to PCE, as well as historical DSS units for historical workload
credit forms that do not send the information to PCE. To implement this
functionality, MHV SM reads files and calls existing APIs from Event Capture
System.\n
MyHealtheVet (MHV) references Event Capture data from DSS Unit File (#724).
When provider is ready to file a workload, he/she is presented with a workload
form. On the form, they have "DSS Units" drop down box. In the drop down
box, MHV needs to present to Provider all the active DSS Units that he/she has
access to. To fill the drop down box, MHV calls an MHV RPC called "MHV
GETDSSUNIT" which has logic to retrieve provider's assigned DSS Units and
their associated fields (Name, Inactive, SEND to PCE flag). "MHV GETDSSUNIT"
sends DSS units back to frontend which uses them to populate drop down box.
Then provider can select one of those DSS Units to file workload. Three
conditions need to be satisfied before DSS Unit can be presented to provider
1. DSS Unit must be active. 2. Provider should have that DSS Unit in the
assigned (MHV) list of DSS Units. 3. DSS Unit should also be associated with
Location (Associated clinic) selected in front-end MHV GETDSSUNIT RPC checks
for these three conditions and sends back DSS Units that pass this criteria.
MHV reads DSS Unit (#724) file to get Name, Inactive flag, SEND TO PCE flag
values. At this time, it will result in only 2 assigned (MHV) DSS Units. But
in future, it may return more DSS Units.", "", "", "2013/11/15"], ["6014", "MEANS TEST DATA FIELDS IN MAS PARAMETERS FILE", "File", "REGISTRATION", "2013/08/12", "APPROVED", "Active", "Private", "43", "
Access to fields in the MEANS TEST DATA (#43.03)
multiple in the MAS PARAMETERS (#43) file.\n
EAS routine EASECSCU sets a local variable to the zeroth node of an entry in
the Means Test Data (#43.03) multiple in the MAS Parameters (#43) file. Only
the CHILD INCOME EXCLUSION (#17) field is used by the Enrollment Application
System.", "", "", "2018/05/02"], ["6015", "READ ACCESS OF BENEFICIARY TRAVEL CERTIFICATION FILE", "File", "BENEFICIARY TRAVEL", "2013/08/23", "", "Deferred (re)approval until a Release Occurs", "Private", "392.2", "
The Enrollment and Eligibility (VistA REE) software
needs access to the Beneficiary Travel Certification file in order to satisfy
the requirements of the Veterans Financial Assessment (VFA) project.\n
NOTE: ICR was entered in 2013 but never activated. The BENEFICIARY TRAVEL
CERTIFICATION (#392.2) file is accessed from SET+16 in routine EASBTBUL to use
FileMAN API $$FIND1~DIC to get the IFN in file 392.2. A comment at SET+15 in
the routine states this file data does not exist. SET+18 is a commented out
line calling $$GET1~DIQ to retrieve the Date Certified field and compare it to
the current date. Active code is referencing the file and an ICR is needed.
On 4/13/18, the Status was changed from Pending to Deferred because the value
retured by the DIC call is not used. If a future patch activates the line of
code in SET+18~EASBTBUL, the ICR can be re-evaluated and activated if
approved.", "", "", ""], ["6016", "DBIA6016-EVENT CAPTURE API-ECUMRPC1-SRCLST", "Routine", "EVENT CAPTURE", "2013/08/27", "APPROVED", "Active", "Private", "", "
MHV Secure Messaging - Work Load Credit functionality
allows users to save the workload credit using the assigned DSS units, and
stores the record in Event Capture System. The use of the DSS units is the
same as in ECS, users have access to link their work to DSS units that send
the record to PCE, as well as historical DSS units for historical workload
credit forms that do not send the information to PCE. To implement this
functionality, MHV SM reads files and calls existing APIs from Event Capture
System.\n
EC routine SRCLST^ECUMRPC1 is used to retrieve diagnosis codes and description
based on search criteria. This routine is also called via RPC [EC GETLIST].", "", "ECUMRPC1", "2013/11/07"], ["6017", "ORWLEX GETI10DX", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2013/09/18", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement is between CPRS and Group Notes.\n
Group Notes would like to utilize the new RPC, ORWLEX GETI10DX,that is
introduced with the ICD-10 project initiative of CPRS GUI v30.\n
This RPC returns a list of Lexicon expressions for a treeview of ICD-10-CM
categories/codes. Two parameters are required to be passed in: the first is
the array (passed by reference) in which the expressions will be returned and
the second is the search term.\n
Input Parameters: .ARRAY This is the local output array passed by
reference. (Required)\n
TEXT Text or Code to search for. (Required)\n
DATE The date for which the search is applicable
for, which usually corresponds to the
encounter date. If not passed, TODAY's date
will be used. (Optional)\n
Output Parameters: ARRAY Output Array passed by reference containing
the ICD-10 expressions and codes found:\n
ARRAY(#)=Lexicon Expression IEN^Preferred
Text^ICD Coding System^ICD
Diagnosis Code^^^^^ICD Diagnosis
IEN\n
If ICD-10 categories are found, then the
parent node is returned in the following
format:\n
ARRAY(#)=+^Preferred Text^ICD Coding System
^ICD Diagnosis Code^^^^^-1\n
where each # is a sequence number per
expression to group the data elements.", "ORWLEX GETI10DX", "ORWLEX", "2014/06/13"], ["6018", "DESCRIPTION UPDATE FOR 9999999.17 FILE", "File", "1", "2013/10/09", "", "Retired", "Private", "9999999.17", "
Important Note: This is a One-Time Agreement, just for
Patch PX*1.0*199.\n
Update of DESCRIPTION for File (#9999999.17) which is the TREATMENT File to
replace occurrences of 'ICD-9-CM' to 'ICD-CM' to accommodate ICD-10
Remediation project for Patch PX*1.0*199. DESCRIPTION will be updated using
Pre-Init routine PX10P199.\n
Routine PX10P199 directly sets nodes in the File Description for File
(#9999999.17).\n
End result should be as below:\n
^DIC(9999999.17,"%D",2,0)="of treatments that are not covered in the ICD-CM
Procedures or the CPT"\n
^DIC(9999999.17,"%D",8,0)="the lack of a coded CPT or ICD-CM."", "", "", ""], ["6019", "DESCRIPTION UPDATE FOR 9000010.07 FILE", "File", "1", "2013/10/10", "", "Retired", "Private", "9000010.07", "
Important Note: This is a One-Time Agreement, just for
Patch PX*1.0*199.\n
Update of DESCRIPTION for File (#9000010.07) which is the V POV File to
replace occurrence of 'ICD9' to 'ICD' to acommodate ICD-10 Remediation project
for Patch PX*1.0*199. DESCRIPTION will be updated using Pre-Init routine
PX10P199.\n
Routine PX10P199 directly sets node in the File Description for File
(#9000010.07).\n
End result should be as below:\n
^DIC(9000010.07,"%D",24,0)="appropriate ICD diagnosis code. Physician entered
narrative which modifies"", "", "", ""], ["6020", "DESCRIPTION UPDATE FOR ACR INDEX OF 9000010.07 FILE", "File", "1", "2013/10/10", "", "Pending", "Private", "", "
Important Note: This is a One-Time Agreement, just for
Patch PX*1.0*199.\n
Update of DESCRIPTION for ACR Index of File (#9000010.07) which is the V POV
File to replace occurrences of 'ICD9' to 'diagnosis' and 'ICD9 CODE' to 'ICD
IEN' to accommodate ICD-10 Remediation project for Patch PX*1.0*199.
DESCRIPTION for ACR Index will be updated using Pre-Init routine PX*1.0*199.\n
Routine PX10P199 directly sets nodes in the File Description for the ACR Index
for File (#9000010.07).\n
ACR Index # should be retrieved by looping through those that are under
^DD("IX","IX","ACR") then looking at uparrow piece 1 of ^DD("IX",<ACR Index
#>,0) node for each and, if it equals 9000010.07, then the end result should
be as below:", "", "", ""], ["6021", "ACR INDEX DESCRIPTION UPDATE FOR 9000010.07 FILE", "File", "1", "2013/10/10", "", "Pending", "Private", "9000010.07", "
Important Note: This is a One-Time Agreement, just for
Patch PX*1.0*199.\n
Update of DESCRIPTION for ACR Index of File (#9000010.07) which is the V POV
File to replace occurrences of 'ICD9' to 'diagnosis' and 'ICD9 CODE' to 'ICD
IEN' to accommodate ICD-10 Remediation project for Patch PX*1.0*199.
DESCRIPTION for ACR Index will be updated using Pre-Init routine PX*1.0*199.\n
Routine PX10P199 directly sets nodes in the File Description for the ACR Index
for File (#9000010.07).\n
ACR Index # should be retrieved by looping through those that are under
^DD("IX","IX","ACR") then looking at uparrow piece 1 of ^DD("IX",<ACR Index
#>,0) node for each and, if it equals 9000010.07, then the end result should
be as below:\n
^DD("IX",<ACR Index #>,.1,2,0)="all patients with a particular diagnosis code
and one for finding all"\n
^DD("IX",<ACR Index #>,.1,3,0)="the diagnosis codes a patient has."\n
^DD("IX",<ACR Index #>,.1,5,0)=" ^PXRMINDX(9000010.07,""IPP"",ICD
IEN,PS,DSN,VISIT DATE,DAS) and"\n
^DD("IX",<ACR Index #>,.1,6,0)=" ^PXRMINDX(9000010.07,""PPI"",DFN,PS,ICD
IEN,VISIT DATE,DAS)"", "", "", ""], ["6022", "VPR GET PATIENT DATA", "Remote Procedure", "VIRTUAL PATIENT RECORD", "2014/01/15", "APPROVED", "Active", "Controlled Subscription", "", "
VPR GET PATIENT DATA is an rpc that pulls patient data
from VistA and returns it in an array formatted as XML. Please see the VPR
Technical Manual for details about input parameters and output data elements.", "VPR GET PATIENT DATA", "", "2014/03/21"], ["6023", "PX SAVE DATA", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2014/01/17", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this RPC is to allow the calling
application to save data to PCE.\n
Revision History:
----------------
Added 8/8/24, effective with the ENHANCED PCE ENCOUNTER LOOKUP 1.0
multi-Package, PX*1.0*238, TIU*1.0*362 and OR*3.0*606 the sequence of calls to
add PCE data using PX SAVE DATA, should be:
1) call PX SAVE DATA, then
2) call TIU CREATE NOTE. This will ensure the PKGNAME and SRC fields
populate the Visit and PCE data and this supports reporting PCE results based
on the PKGNAME or SRC fields. ICR 7315 is preferred as it returns error
information.\n
Added 8/1/24, effective with PX*1*217, note the explanation of INPUT
PARAMETERS for PKGNAME and SRC and RETURN PARAMETERs expanded return values.\n\n\n
INPUT PARAMETER: PCELIST PARAMETER TYPE: LIST
MAXIMUM DATA LENGTH: 10000 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
PCELIST (n)=HDR^Encounter Inpatient?^Note has CPT codes?^Visit
string [Encounter location; Encounter date/time; Encounter
Service category] (REQUIRED)
(n)=VST^DT^Encounter date/time
(n)=VST^PT^Encounter patient (DFN) (n)=VST^HL^Encounter location
(n)=VST^VC^ Encounter Service Category\n
If applicable:\n
(n)=VST^PR^ Parent for secondary visit
(n)=VST^OL^ Outside Location for Historical visits
(n)=VST^SC^ Service Connected related?
(n)=VST^AO^ Agent Orange related?
(n)=VST^IR^ Ionizing Radiation related?
(n)=VST^EC^ Environmental Contaminates related?
(n)=VST^MST^ Military Sexual Trauma related?
(n)=VST^HNC^ Head and/or Neck Cancer related?
(n)=VST^CV^ Combat Vet related?
(n)=VST^SHD^ Shipboard Hazard and Defense related?
(n)=PRV(+: add, -: delete) ^ Provider IEN ^^^ Provider Name ^
Primary Provider?
(n)=POV(+: add, -: delete) ^ ICD diagnosis code ^ Category ^
Narrative (Diagnosis description) ^ Primary Diagnosis? ^
Provider String ^ Add to Problem List? ^^^ Next comment
sequence # if saving comments
(n)=COM^COM (Comments) ^ Next comment sequence # ^ @ = no
comments added
(n)=CPT (+: add, -: delete) ^ Procedural CPT code ^ Category ^
Narrative (Procedure description) ^ Quantity ^ Provider IEN
^^^ [# of modifiers; Modifier code/Modifier IEN ^ Next
comment sequence # ^\n
Effective with PX*1*209, the PCELIST input parameter contains
modifications for IMM (Immunization) type data to include
additional fields: Encounter Provider, Event Info Source,
Dosage, Route, Admin Site, Lot #, Manufacturer, Expiration Date.
The IMM PCELIST items are not required to have the new fields -
to support backward compatibility.\n
(n)=IMM (+: add, -: delete) ^ Immunization IEN ^ Category ^
Narrative (Immunization description/name) ^ Series ^
Encounter Provider ^ Reaction ^ Contraindicated? ^^ Next
comment sequence # ^ CVX Code ^ Event Info Source HL7
Code;IEN ^ Dose;Units;Units IEN ^ Route Name;HL7 Code;IEN ^
Admin Site Name;HL7 Code;IEN^ Lot #;IEN ^ Manufacturer ^
Expiration Date ^ Event Date and Time ^ Ordering Provider ^
VIS1 IEN/VIS1 Date;VISn IEN/VISn Date;...^ Remarks Start Seq
#;End Seq # ^ Warning Ack ^ Override Reason (Seq #)\n
(n)=SK (+: add, -: delete) ^ Skin Test IEN ^ Category ^
Narrative (Skin Test description/name) ^ Results ^ Enc
Provider ^ Reading ^ D/T Read ^ Event D/T ^ Next comment
sequence # ^ Reader ^ Ordering Provider ^ Anatomic Location
of Placement;HL7 Code;IEN ^ Reading Comment (Seq #)
(n)=PED (+: add, -: delete) ^ Patient Education IEN ^ Category ^
Narrative (Patient Education description/name) ^ Level of
understanding ^^^^^ Next comment sequence #
(n)=HF (+: add, -: delete) ^ Health Factor IEN ^ Category ^
Narrative (Health Factor description/name) ^ Level ^^^^^ Next
comment sequence # ^ Get Reminder
(n)=XAM(+: add, -: delete) ^ Exam IEN ^ Category ^ Narrative
(Exam description/name) ^ Results ^^^^^ Next comment sequence
#
(n)=ICR (+: add, -: delete) ^ Variable Pointer IMM
Contraindication Reasons/IMM Refusal Reasons ^ Category ^
Narrative ^ Immunization IEN ^ Warn Until Date ^ Event
Date/Time ^ Enc Provider IEN ^ ^ Next comment sequence #\n
INPUT PARAMETER: LOC PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 40 REQUIRED: NO
SEQUENCE NUMBER: 2
DESCRIPTION:
This is the hospital location. This is not used when the information is
from an outside source.\n
INPUT PARAMETER: PKGNAME PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 60 REQUIRED: YES
SEQUENCE NUMBER: 3
DESCRIPTION:
The package name that is sending the data to PCE. This should be the
full package name from the PACKAGE file or a pointer to the PACKAGE file
(#9.4). If Middleware is involved, the Middleware package name should be the
PKGNAME. If the calling product has a PACKAGE file entry and is not
middleware, then the product's PACKAGE file name should be the PKGNAME. For
CPRS PCE updates, the PKGNAME is PATIENT CARE ENCOUNTERS, but that should not
be used generically for any product.\n
Note:The Package Name field will only be updated in the PCE Visit and
V-files when PX SAVE DATA is called before TIU CREATE NOTE by the
application/middleware.\n
INPUT PARAMETER: SRC PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 64 REQUIRED: YES
SEQUENCE NUMBER: 4
DESCRIPTION:
The source of the data being sent to PCE. If the source is an application
using middleware, the SRC should be the name of that application. This
applies to COTS, Class 3, Class 2, and Class 1 applications. SRC can be text
or a pointer to the PCE DATA SOURCE file (#839.7). The text does not need to
be pre-defined in the PCE DATA SOURCE file because it will be added using
LAYGO for new data sources.\n
Note: The Data Source will only be updated in the PCE Visit and V-files when
PX SAVE DATA is called before TIU CREATE NOTE by the application/middleware.\n\n
RETURN PARAMETER DESCRIPTION: Returned Value:
1 If no errors occurred and data was processed.
-1 If errors occurred, but data was processed as completely as
possible.
-2 Unable to identify a valid Visit. No data was processed.
-3 RPC was called incorrectly. No data was processed.
-4 If cannot get a lock on the encounter.
-5 If there were only warnings.\n
Optionally, if the argument RETVISIT was "1", than the Visit IEN will be
returned as the second piece (e.g., "1^65234").", "PX SAVE DATA", "", "2016/09/19"], ["6024", "GIVE THIS DBIA A BETTER NAME THAN DBIA6024", "", "", "2014/01/31", "", "Pending", "", "", "", "", "", ""], ["6025", "PATIENT APPOINTMENT MULTIPLE", "File", "REGISTRATION", "2014/02/12", "", "Pending", "Private", "2", "
This Integration Agreement gives the Surgery Quality
and Workflow Manager (SQWM) module of VistA Surgery authority to add and
modify appointments to the Patient file (#2) Appointment sub-file (#2.98).\n
Clinic appointments created in the SQWM COTS application transmitted are
transmitted to VistA through an HL7 interface. The SIU HL7 message types and
associated events (S12, S14, and S15) contain segments that are used to pass
the validated data elements to VistA and are added to Appointment multiple.", "", "", ""], ["6026", "HOSPITAL LOCATION CLINIC APPOINTMENTS", "File", "SCHEDULING", "2014/02/12", "", "Pending", "Private", "44", "
This agreement give the Surgery Quality and Workflow
Manager (SQWM) module of the VistA Surgery package permission to add and
update clinic appointments on the APPOINTMENT sub-file of the HOSPITAL
LOCATION file (#44).", "", "", ""], ["6027", "SCMC PCMM/R GET PRIMARY CARE DETAILS", "Routine", "SCHEDULING", "2014/02/21", "APPROVED", "Active", "Private", "", "
This is a new API developed for PCMMR that will return
details regarding the Patient Aligned Care Team (PACT) and other team
assignments (Mental Health, Specialty, OEF/OIF/OND) for a patient. This
information will be retrieved from PCMMR and displayed when a user clicks on
the PCMM "button" on the CPRS header.", "", "SCMCWS1", "2014/06/16"], ["6028", "BPSUTIL2", "Routine", "E CLAIMS MGMT ENGINE", "2014/02/24", "APPROVED", "Active", "Private", "", "
Integrated Billing requires access to data and indices
of the BPS LOG OF TRANSACTIONS file (#9002313.57). The data will be used to
match payments to claims. The data will be gathered by calling
CLMECME^BPSUTIL2.", "", "BPSUTIL2", "2014/06/19"], ["6029", "RETURN REMINDER ORDER CHECK ITEMS", "Routine", "CLINICAL REMINDERS", "2014/03/07", "APPROVED", "Active", "Private", "", "
The Clinical Reminders package stores lists of items in
the REMINDER ORDER CHECK ITEMS GROUP file (#801).", "", "PXRMAPI", "2016/08/04"], ["6030", "WARD AT DISCHARGE", "Routine", "REGISTRATION", "2014/03/07", "APPROVED", "Active", "Private", "", "
This agreement allows the AR application to get the
ward at the time of discharge performed by PTF^DGPMUTL to determine the care
type of VA care or Non-VA care for the bill.", "", "DGPMUTL", "2017/04/03"], ["6031", "DBIA6031", "Routine", "REGISTRATION", "2014/03/19", "", "Withdrawn", "Controlled Subscription", "", "
The Enrollment Application System (EAS) have a need to
obtain enrollment data from Patient Enrollment File (#27.11). This can be
accomplished using the API in the Registration Enrollment routine DGENA.\n
Added piece 24, 25, 26, and 27 to variable Node New Pieces include Camp
Lejeune Data
Camp Lejeune Indicator
CL Date/Time Stamp
CL Source
CL Site\n\n\n", "", "DGENA", ""], ["6032", "PRE CLINICAL REMINDER ORDER CHECK", "File", "CLINICAL REMINDERS", "2014/03/21", "", "Withdrawn", "Private", "801", "
In order to display Clinical Reminders based on
Orderable Items and Pharmacy Items, the Inpatient Meds and Outpatient Pharmacy
packages request read-only access to the following nodes in the REMINDER ORDER
CHECK ITEMS GROUP FILE (^PXD(801):\n
^PXD(801,D0,1.5,0)=^801.015V^^ (#15) PHARMACY ITEM LIST
^PXD(801,D0,1.5,D1,0)= (#.01) PHARMACY ITEM [1V] ^ ^PXD(801,D0,2,0)=^801.02P^^
(#20) ORDERABLE ITEM LIST ^PXD(801,D0,2,D1,0)= (#.01) ORDERABLE ITEM
[1P:101.43] ^", "", "", ""], ["6033", "IB BILL/CLAIMS PRESCRIPTION REFILL FILE ACCESS", "File", "INTEGRATED BILLING", "2014/03/25", "APPROVED", "Active", "Controlled Subscription", "362.4", "
As part of the implementation of PRCA*4.5*298, the
Accounts Receivable package is requesting read access to the BILL NUMBER (C)
cross-reference and the zero node of IB BILL/CLAIMS PRESCRIPTION REFILL file
(362.4).\n", "", "", "2014/06/12"], ["6034", "Editing Label Date/Time multiple HELP-PROMPT (file #52)", "File", "1", "2014/03/26", "", "Retired", "Private", "52", "
This request is to allow the Outpatient Pharmacy
package to remove the HELP-PROMPT for multiple field Label Date/Time (#32) of
the Prescription file (#52).\n
This change will be used in patch PSO*7.0*370 only.", "", "", ""], ["6035", "ORWPT16 ID INFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/03/31", "APPROVED", "Active", "Private", "", "
This ICR is created to satisfy the needs of the VIA
project which is tasked to replace MDWS services, where MDWS was referencing
this RPC without an approved ICR.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.", "ORWPT16 ID INFO", "", "2014/03/31"], ["6036", "National Utility Clean-up", "Routine", "OUTPATIENT PHARMACY", "2014/04/02", "", "Withdrawn", "Private", "", "
This agreement describes the call made from
Computerized Patient Record System (CPRS) to Outpatient Pharmacy as part of a
combined build that contains patches OR*3.0*378 and PSO*7.0*433.", "", "PSOUT433", ""], ["6037", "DGPM C CROSS REFERENCE", "File", "REGISTRATION", "2014/04/10", "", "Withdrawn", "Private", "405", "
The MBAA RPC, MBAA PATIENT ADMISSIONS uses routine
MBAAMEXT reads the DGPM("C" cross reference to see if a patient has a
movement. If a movement is found, the record number for the movement is used
to access the record and get the Date/Time (.01) field.", "", "", ""], ["6038", "BCMA ADMINISTRATION DATA", "Routine", "BAR CODE MED ADMIN", "2014/04/11", "APPROVED", "Active", "Private", "", "
The purpose of this Application Programming Interface
(API) is to provide the next scheduled administration information.\n
The 4th parameter passed into this API is optional, which is the date and
time. If not passed in, then the API defaults to date/time = NOW, and will
return the next admin time that follows NOW. So, if an admin time was due 1
minute ago, then that admin will not be returned, as the Next admin dose.
However, that admin of 1 minute ago, is most likely the admin that nursing
staff would actually give to the patient via BCMA.", "", "PSBVPR", "2016/05/10"], ["6039", "ORWDXA OFCPLX", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/04/14", "APPROVED", "Active", "Private", "", "
This ICR was created for VIA. The RPC was used by MDWS,
and never previously documented in an ICR. Since MDWS already uses this RPC,
and VIA is responsible for exposing all RPCs used by MDWS, the CPRS
development team agrees to the use of the RPC.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC is used to evaluate a true/false value to: is ORID child of PRTORDER.\n", "ORWDXA OFCPLX", "", "2014/04/21"], ["6040", "ORWLRR INFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/04/14", "APPROVED", "Active", "Private", "", "
This ICR was created for VIA. The RPC was used by MDWS,
and never previously documented in an ICR. Since MDWS already uses this RPC,
and VIA is responsible for exposing all RPCs used by MDWS, the CPRS
development team agrees to the use of the RPC.\n
A new OR*3*392 patch will be distributed that turns on this RPC's flag - APP
PROXY ENABLED. The OR*3*392 patch is associated with the VIAB*1*1 patch.\n
This RPC is used to return lab test description information.", "ORWLRR INFO", "", "2014/04/21"], ["6041", "VERIFIED DATE/TIME OF RADIOLOGY REPORTS", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2014/04/15", "APPROVED", "Active", "Private", "74", "
This Integration Agreement will allow the VistA
Decision Support System (DSS) to identify verified reports over a date range.", "", "", "2014/06/04"], ["6042", "SCMC PCMM/R GET PRIMARY CARE SUMMARY", "Routine", "SCHEDULING", "2014/04/15", "APPROVED", "Active", "Private", "", "
This is a new API developed for PCMMR that will return
Patient Aligned Care Team (PACT) summary data for a patient. This information
will include site name, PACT name, Primary Care Provider (PCP) and Associate
Provider (AP) names. PCMMR will keep this data current. It will be stored in
the Outpatient Profile (404.41) file in the CPRS Header Text (.06) field.", "", "SCMCWSUT", "2014/06/16"], ["6043", "READ DUPLICATE RECORD FILE", "File", "KERNEL", "2014/04/15", "APPROVED", "Active", "Private", "15", "
PCMMR would like to reference fields in the following
file directly:\n
DUPLICATE RECORD (#15) FILE\n
IEN, .01 RECORD1, .02 RECORD2, .03 STATUS, .04 MERGE DIRECTION, .05 MERGE
STATUS\n
When PCMMR receives an ADT-A24 HL7 message from MPI indicating a merge of
identities that is a "local merge" on a single station, PCMMR needs to query
the Duplicate Record file to determine whether VistA has completed the
resolution of duplicate patients. If and only if the local VistA staff
performing the Local Merges chooses to accept and process this local data
merge, PCMMR will complete the data merge in its own enterprise database,
enabling it to continue data synchronization with the VistA site. If VistA
chooses to deny the merge request, or merge the patient data in the opposite
direction, PCMMR can use the status in this file to adjust its behavior
accordingly.\n
The code queries field .05 MERGE STATUS to find the status of the merge
process for each pair of duplicate records. If it finds value 3 - IN PROCESS,
it starts polling VistA. It will poll VistA at increasing time interval until
we exceed the maximum polling limit (currently 5 days from start of polling).
If during polling it finds a value of 2 - MERGED, in a duplicate pair, the
code processes the patient's data for the site and sends an application ack
(acknowledgement) to MVI.\n
The file is accessed using a PCMMR restricted RPC "SCMC LISTER", which employs
a Fileman DBS API to retrieve data from File 15. It is deployed as part of
patch SD*5.3*603.", "", "", "2014/07/09"], ["6044", "MBAA Access to SC files", "File", "SCHEDULING", "2014/04/22", "APPROVED", "Active", "Private", "44", "
The Scheduling Calendar View (MBAA namespace) RPCs,
MBAA APPOINTMENT MAKE, MBAA CANCEL APPOINTMENT, MBAA PATIENT PENDING APPT,
MBAA GET CLINIC AVAILABILITY, and MBAA PROVIDER TO CLINIC and the routines
below make reads and writes to the Hospital Location file (#44). The Routines
and Linetags list below describe the access:\n
Routine: MBAAMDA1 reads and writes from/to the Hospital Location file (#44) in
order to make and cancel appointments.\n
Linetags:\n
1. GETCLNX makes a FileMan read of the Hospital Location file (#44) to see if
a clinic exists.\n
2. GETPATT does a FileMan read of the ^SC(D0,"ST" node to get the clinic
availability for a specified date.\n
3. GETSCAP does a direct global read of the ^SC(D0,"S" node to get clinic
appointment information for a specific patient and date/time.\n
4. GETCAPT does a FileMan read to get appointment data for a patient. Fields
read are: Patient (.01), Length of Appointment (1), Other (3), Data Entry
Clerk (7), Date Appointment Made (8), OverBook (9), Eligibility (30),
Checked-in (309), Check in User (302), Checked Out (303), Check Out User
(304), Check Out Entered (306), Consult Link (688)\n
5. LOCKST locks the ^SC(D0,"ST" node for a specified date prior to record for
an appointment.\n
6. UNLCKST unlocks the ^SC(D0,"ST" node for a specified date after updating
the record for an appointment.\n
7. LOCKS locks the ^SC(D0,"S" node for a specific date/time in order to enter
a new appointment.\n
8. UNLCKS unlocks the ^SC(D0,"S", node for a specific date/time after an
appointment record has been created.\n
9. SETST uses FileMan to set the ^SC(D0,"ST",Date,1 node in order to set
appointment availability. This call updates fields .01, Pattern Date and 1
Current Availability.\n
10. MAKE uses UPDATE^DIE to make a clinic appointment in the Hospital Location
file (#44). The Appointment multiple is updated with a new appointment. Fields
that are updated are .01, 1, 3, 7, 8, 10, 688.\n
The SC("ARAD" cross reference is being hardset in existing SD namespaced
routines. The SDCNP0 routine is hardsetting this cross reference to be equal
to 'N'.\n\n
CANCEL updates the Hospital Location file (#44) when an appointment is
canceled:\n
a. The ^SC("ARAD" cross reference is hard set to "N".
b. The ^SC(D0,"S" node with the appointment record is deleted using
a KILL command.
c. A FileMan read (GETS^DIQ) is used to get the values of the Hour
Clinic Display Begins (#1914) and Display Increments Per Hour
(#1917). These fields are used to calculate the value to be used
to update the Current Availability field in the Pattern multiple
(See d and e below).
d. The value of the ^SC(D0,"ST",Date,1 node is read with a
FileMan read. (Date is the date the appointment is being canceled).
e. The ^SC(D0,"ST",Date/Time,1 node is set using a FileMan write to
the newly calculated Current Availability as calculated when
canceling an appointment. Steps c, d and e are making the
calculations to reset the current availability pattern to recover
the slot that was used when making the appointment.\n
11. COVERB checks to see if the clinic is overbooked for a specific date/time.
If so, the first overbooking is deleted using a KILL command.\n
12. GETFSTA gets the first available day for an appointment by reading the
^SC(D0,"T", node.\n
13. GETDAYA loops through the ^SC(D0,"S" nodes from a beginning date to get
the appointment status and overbooking status for each date/time where an
appointment is booked.\n
14. GETDST does a direct global read of the ^SC(D0,"ST",Date/Time, 1 node and
returns the current availability status for the date/time.\n
15. GETDPATT returns the day pattern for a specific date. Does a direct global
read of the ^SC(D0,"ST",date,D1,1) read and returns the data on this node.\n
16. ADDPATT uses UPDATE^DIE to update the PATTERN multiple for a specific
date.\n
Routine: MBAAMDA2 makes calls to read data from the Hospital Location file
(#44) to get information in order to make or cancel appointments.\n
Linetags: SLOTS does a FileMan read of the ^SC(D0,"ST" node for a clinic to
get the .01, Pattern Date and 1, Current Availability fields. Returns all
nodes for the clinic in the RETURN array.\n
Routine MBAAMDA4 makes calls to read and update the Hospital Location file
(#44) in order to make or cancel appointments.\n
Linetag:\n
1. UPDCAPT uses UPDATE^DIE to update the APPOINTMENT multiple for a new
appointment.\n
2. GETCAPT does a direct global read of the ^SC(D0,"S",Appointment Date/Time
to check if the appointment exists. If it exists, uses an EN^DIQ call to read
the appointment record. Fields that are read are Patient (.01), Length of
Appointment (1), Other (3), Data Entry Clerk (7), Date Appointment Made (8),
OverBook (9), Eligibility (30), Checked-in (309), Check in User (302), Checked
Out (303), Check Out User (304), Check Out Entered (306)\n
Routine MBAARPC1 In linetag PROVCLIN a direct global read is made to the
^SC(D0,"PR" to get the pointer to the NEW PERSON file (#200) for each Provider
that is associated with the specified clinic.\n
Routine MBAARPC2 makes direct global reads of the HOSPITAL LOCATION file (#44)
to read appointment information.\n
Linetag:\n
1. CLNDATA does a FileMan read of the ^SC(D0,0 node to get fields, STOP CODE
NUMBER (8), TREATING SPECIALTY (9.5), CREDIT STOP CODE (2503).\n
2. RECALL does a FileMan read to check to see if the Clinic ID entered exists
in the Hospital Location file (#44).", "", "", "2015/03/23"], ["6045", "MBAA Access to SD(403.5", "File", "SCHEDULING", "2014/04/22", "APPROVED", "Active", "Private", "403.5", "
The Scheduling Calendar View RPCs and code accesses the
Recall Reminders file (#403.5) to read recall data. The RPCs are the MBAA
RECALL BY FACILITY LIST and MBAA RECALL LIST BY PATIENT.\n
Routine MBAARPCL reads the Recall Reminders file (#403.5) to get the data
necessary to provide the facility Recall Reminders List and a Recall Reminders
List by patient.\n
Linetags:\n
RECALL does a FileMan read of the ^SD(403.5 file to get fields Patient Name
(.01), Clinic (4.5), Accession (2), Test/App (3), Provider (4), Recall Date
(5), Comment (2.5), Fast/Non-Fasting (2.6), Length of Appt (4.7), Date
Reminder Sent (6), User Who Entered Recall (7), Recall Date (Per Patient)
(5.5), Second Print (8).\n
RCLDFN does a FileMan read of the ^SD(403.5 file to get fields Patient Name
(.01), Clinic (4.5), Accession (2), Test/App (3), Provider (4), Recall Date
(5), Comment (2.5), Fast/Non-Fasting (2.6), Length of Appt (4.7), Date
Reminder Sent (6), User Who Entered Recall (7), Recall Date (Per Patient)
(5.5), Second Print (8).", "", "", "2016/06/10"], ["6046", "MBAA ACESS TO SDWL(409.3", "File", "SCHEDULING", "2014/04/22", "APPROVED", "Active", "Private", "409.3", "
The Scheduling Calendar View accesses the SD Wait List
file (#409.3) to read and write data in order to provide information about
patients on the Electronic Wait List (EWL) and to update the status of
patients on the EWL in order to remove them from the EWL. The mobile app
verifies the user holds the VistA security key, SDWL MENU prior to allowing
access to the mobile wait list options.\n
Routine MBAARPC1 reads data using direct global reads to confirm the patient
is on the EWL and then checks the status of the patient on the EWL.\n
Linetag:\n
UPDTEWL does a direct global read the ^SDWL(409.3,"B" cross reference to check
to see if the patient is on a EWL. If the patient is on an EWL, a FileMan read
of field 23, Current Status, is made to get the current status of the patient
on the EWL.\n
Routine MBAARPCL makes direct global reads to the ^SDWL(409.3 file to get EWL
information for a patient or for a facility.\n
Linetags:\n
EWL does a direct global read of the ^SDWL(409.3,"B" cross reference to check
to see if the patient is on the EWL. If the patient is on the EWL, it does a
FileMan read of for the Current Status (23), Originating Date (1), Desired
Date of Appointment (22), WL Specific Clinic (8), Priority (10), EWL Enrollee
Status (27), Date Appt. Made (13.1).\n
FACEWL does a direct global read of data on the ^SDWL(409.3,"B" cross
reference. A FileMan read is made of the Current Status (23) field to see if
the patient's entry is closed. If it is open, then a FileMan read is made to
pull the Originating Date (1), Desired Date of Appointment (22), WL Specific
Clinic (8), Priority (10), EWL Enrollee Status (27), Date Appt. Made (13.1)
fields.\n
Routine MBAAWLDA locks and unlocks records in the ^SDWL(409.3 file and\n
Linetags:\n
LOCK locks ^SDWL(409.3,D0 in order to perform and edit action.\n
UNLOCK unlocks ^SDWL(409.3,D0 after performing an edit action.\n
DISP edits Disposition (21), Date Dispositioned (19), Dispositioned By (20),
Current Status (23), Scheduled Date of Appt (13), Date Appt. Made (13.1), Appt
Clinic (13.2), Appt Institution (13.3), Appt Stop Code (13.4), Appt Credit
Stop Code (13.5), Appt Station Number (13.6), Appt Status (13.8), Apt Clerk
(13.7) using a FileMan call.\n
DISP also uses GET1^DIQ to get WL Specific Clinic. If there is a WL Specific
Clinic, the ^SDWL(409.3, "SC" cross reference for the entry is KILLed.", "", "", "2016/08/17"], ["6047", "MBAA Access to SDWL(409.32", "File", "SCHEDULING", "2014/04/22", "APPROVED", "Active", "Private", "409.32", "
ICR 6047 MBAA Access to SDWL(409.32.\n
The Scheduling Calendar View application access the SD WL Clinic Location file
(#409.32) to get the WL Clinic. The MBAA RPCs, MBAA WAIT LIST BY DFN and MBAA
FACILITY WAIT LIST makes this call to the file.\n
Routine MBAARPCL does a FileMan read of the SD WL CLINIC LOCATION File for the
specified record to get the Clinic field (.01) in external format.\n
Linetag:\n
EWL does a FileMan read of the SD WL CLINIC LOCATION File for the specified
record to get the Clinic field (.01) in external format. (RPC: MBAA WAIT LIST
BY DFN)\n
FACEWL does a FileMan read of the SD WL CLINIC LOCATION File to get the Clinic
field (.01) in external format. (RPC: MBAA FACILITY WAIT LIST)", "", "", "2015/02/26"], ["6048", "MBAA SDAMEVT API CALLS", "Routine", "SCHEDULING", "2014/04/23", "APPROVED", "Active", "Private", "", "
The Scheduling Calendar View application uses APIs in
the SDAMEVT routine to handle scheduling events.\n
API:\n
CANCEL^SDAMEVT - This API is used to log or trigger events when an appointment
is canceled. The API is called from routines MBAAMAP2 and MBAARPC2 and the RPC
is MBAA CANCEL APPOINTMENT.\n
MAKE^SDAMEVT - This API is used to log or trigger events when an appointment
is made. The API is called from routine MBAAMAP2 and the RPC is MBAA
APPOINTMENT MAKE.", "", "SDAMEVT", "2015/02/24"], ["6049", "MBAA SDMANA API USE", "Routine", "SCHEDULING", "2014/04/23", "APPROVED", "Active", "Private", "", "
The Scheduling Calendar View application uses the
NAVA^SDMANA API to compute the next available indicator when making an
appointment.\n
Routine MBAAMAP2 calls this API when making an appointment. MBAAMAP2 is called
by the MBAA APPOINTMENT MAKE RPC.", "", "SDMANA", "2015/01/05"], ["6050", "MBAA SDQQCN2 API", "Routine", "SCHEDULING", "2014/04/23", "APPROVED", "Active", "Private", "", "
The Scheduling Calendar View package uses the
SCH^SDQQCN2 API to schedule and change the status of a consult when an
appointment is made for the consult request.\n
Routine MBAAAPI1 calls this API when making an appointment.", "", "SDQQCN2", "2016/06/09"], ["6051", "MBAA use of SDWLE6 API", "Routine", "SCHEDULING", "2014/04/23", "", "Withdrawn", "Private", "", "
The Scheduling Calendar View RPC, MBAA REMOVE FROM EWL
uses the DIS^SDWLE6 API to disposition an EWL entry when removing a patient
from the SD EWL. Prior to allowing a user to access the EWL options, the
software checks to be sure the user holds the SDWL MENU security key.\n
Routine MBAAWLAP calls the API in order to update the disposition of the EWL
entry. DIS^SDWLE6 updates the status of the specified entry on the Electronic
Wait List (EWL) to remove (Status of Closed) the patient from the EWL. The API
also checks to see if the patient is in the SDWL TRANSFER ACCEPT FILE
(#409.36). If the patient is in the file, a message is sent to the
S.SDWL-XFER-SERVER at the facility indicated in the SDWL TRANSFER ACCEPT FILE.\n", "", "SDWLE6", ""], ["6052", "MBAA ACCESS TO GMR(123", "File", "CONSULT/REQUEST TRACKING", "2014/04/23", "APPROVED", "Active", "Private", "123", "
The Scheduling Calendar View (SCV) app is accessing the
REQUEST/CONSULTATION File (#123) in order to update the consult request from
scheduled to pending and to add a comment when an appointment for the consult
has been cancelled.", "", "", "2018/05/16"], ["6053", "MBAA ACCESS TO THE PATIENT FILE", "File", "REGISTRATION", "2014/04/23", "APPROVED", "Active", "Private", "2", "
The Scheduling Calendar View application accesses the
Patient file (#2) in order to lookup up appointments, to make appointments and
to cancel appointments and to get a list of a patient's pending appointments.
SCV RPC that are called and access the file are MBAA APPOINTMENT MAKE, MBAA
CANCEL APPOINTMENT and MBAA PATIENT PENDING APPT\n
Routine MBAAMDA2: Linetags:\n
GETDAPTS does a direct global read of the ^DPT(D0,"S",Date/time to get the
Clinic (.01) and Status (3) fields.\n
GETAPTO returns the ^DPT(D0,"S",Date/time,0) node if the patient has an
appointment at that date/time. The fields returned are the (#.01) CLINIC ,
(#3) STATUS , (#5) LAB DATE/TIME , (#6) X-RAY DATE/TIME , (#7) EKG DATE/TIME ,
(#8) ROUTING SLIP PRINTED , (#9) PURPOSE OF VISIT , (#10) SPECIAL SURVEY
DISPOSITION (#11) NUMBER OF COLLATERAL SEEN , (#12) AUTO-REBOOKED APPT.
DATE/TIME , (#13) COLLATERAL VISIT , (#14) NO-SHOW/CANCELLED BY , (#8.5)
ROUTING SLIP PRINT DATE , (#15) NO-SHOW/CANCEL DATE/TIME , (#16) CANCELLATION
REASON , (#9.5) APPOINTMENT TYPE , (#18) APPT. CANCELLED , (#19) DATA ENTRY
CLERK , (#20) DATE APPT. MADE ,(#21) OUTPATIENT ENCOUNTER , (#22) ENCOUNTER
FORMS PRINTED , (#23) ENCOUNTER FORMS AS ADD-ONS , (#23.1) ENCOUNTER
CONVERSION STATUS ,(#24) APPOINTMENT TYPE SUB-CATEGORY , (#25) SCHEDULING
REQUEST TYPE , (#26) NEXT AVA. APPT. INDICATOR.\n
Routine MBAAMDA3 Linetag:\n
MAKE uses FILE^DIE to enter a new appointment into the Appointment multiple in
the Patient file (#2). Fields that are edited are Clinic (.01), Status (3),
Purpose of Visit (9), Appointment Type (9.5), Date Appt Made (20), Lab
Date/Time (5), X-Ray Date/Time (6), EKG Date/Time (7), Data Entry Clerk (19),
Appointment Type Sub-Category (24), Scheduling Request Type (25), Next Ava.
Appt. Indicator (26).\n
CANCEL uses FILE^DIE to update the Appointment multiple in order to cancel an
appointment for a patient. Fields that are edited are Status (3),
No-Show/Cancelled By (14), No-Show/Cancel Date/Time (15), Cancellation Reason
(16), Data Entry Clerk (19), Date Appt Made (20), Cancellation Remarks (17).\n
Routine: MBAAMDA4 Linetag: GETCAPT does a direct global read to get the Clinic
field (.01) from the ^DPT(D0,"S",Date/time node for an appointment in order to
cancel the appointment.\n
Routine MBAARPC2\n
Linetag CHKCAN does a direct global read of the ^DPT(D0,"S",Date/Time) node to
see if the patient has an appointment on the date/time.", "", "", "2015/03/23"], ["6054", "MBAA USE OF SDAM2 API", "Routine", "SCHEDULING", "2014/04/24", "APPROVED", "Active", "Private", "", "
The Scheduling Calendar View application makes a call
to the API INP^SDAM2 from MAKE^MBAAMAP2 when scheduling an appointment for a
patient to check the inpatient status of the patient.\n
The SDAM2 API will be used by the MBAA APPOINTMENT MAKE RPC.", "", "SDAM2", "2014/12/31"], ["6055", "MBAA USE OF API IN XUMF", "Routine", "KERNEL", "2014/04/24", "", "Pending", "Private", "", "", "", "", ""], ["6056", "GIVE THIS DBIA A BETTER NAME THAN DBIA6056", "", "", "2014/05/09", "", "Pending", "", "", "", "", "", ""], ["6057", "MBAA ACCESS TO SDAM1 API", "Routine", "MOBILE SCHEDULING APPLICATIONS SUITE", "2014/05/09", "", "Withdrawn", "Private", "", "
The MBAA Scheduling Calendar View (SCV) package needs
to access the STATUS^SDAM1 API in order to get the status of an appointment.", "", "SDAM1", ""], ["6058", "MBAA ACCESS TO GMRCGUIS API", "Routine", "CONSULT/REQUEST TRACKING", "2014/05/20", "", "Withdrawn", "Private", "", "
The Scheduling Calendar View (MBAA namespace) uses the
STATUS^GMRCGUIS API to get the status of a consult.", "", "GMRCGUIS", ""], ["6059", "DISABLE REMINDER EVALUATION DURING INDEX BUILD", "Routine", "CLINICAL REMINDERS", "2014/05/20", "APPROVED", "Active", "Private", "", "", "", "PXRMDIEV", "2014/05/21"], ["6060", "IB CLAIM REJECT FLAG", "Routine", "INTEGRATED BILLING", "2014/05/23", "APPROVED", "Active", "Private", "", "
This function checks file #361 and returns a flag that
indicates whether the bill that was input has a rejected status. Input:
BILL - Bill number from #399 Output:
REJECT - Reject status (blank = not found, 0 = not a reject, 1 = rejected)", "", "IBJTU6", "2014/06/11"], ["6061", "IBCNHUT1 (HPID/OEID)", "Routine", "INTEGRATED BILLING", "2014/05/28", "APPROVED", "Active", "Private", "", "
The purpose of the standardized HPID is to eliminate
the ambiguity that presently exists in electronic standard healthcare
transactions, and to streamline the numerous ways in which the term "health
plan" is interpreted based on the different ways that health plans operate.
This ambiguity undermines the value of electronic transactions by requiring
repeated manual intervention.\n
Both the IB and BPS (e-Claims Mgmt) namespaces will be displaying the HPID on
various reports and screens, and BPS will need to be able to access the IB
utility that was developed to find, validate and display the HPID for a
particular health plan.\n
The functions of IBCNHUT1 will return the HPID/OEID for an insurance company
and validate that the HPID/OEID is in the correct format (10 numeric
characters, 1st character is a 6 or 7 and the 10th character is the Luhn
check-digit).", "", "IBCNHUT1", "2014/06/19"], ["6062", "LANGUAGE file", "File", "1", "2014/06/02", "APPROVED", "Active", "Controlled Subscription", ".85", "
With VA FileMan 22.2, the LANGUAGE file (#.85) has been
updated to contain ISO 639-1 and 639-2 compatible languages. This file can be
used as a Pointer to file for any field that wants to reference a language.
Any application that points to this file should set screening logic to
constrict the user selection. The screening logic should use the TYPE field
(#.07), $P(^(0),U,7), which is a set of codes:
'L' FOR Living
'C' FOR Constructed
'A' FOR Ancient
'H' FOR Historical
'E' FOR Extinct\n
If you only want to allow selections of languages that are currently spoken,
you can use the following:
S DIC("S")="I $P(^(0),U,7)=""L"""\n
Also, read access is permitted using FileMan APIs.\n
Amended: 1/3/23 Added Field.03 THREE LETTER CODE for use by REGISTRATION,
INCOME VERIFICATION MATCH effective with patch DG*5.3*1085/IVM*2.0*208", "", "", "2023/01/03"], ["6063", "MBAA RPC REGISTRATION", "File", "ORDER ENTRY/RESULTS REPORTING", "2014/06/04", "", "Withdrawn", "Private", "19", "", "", "", ""], ["6064", "MBAA ACCESS TO SCTM(404.57", "File", "SCHEDULING", "2014/06/04", "APPROVED", "Active", "Private", "404.57", "
The Scheduling Calendar View application is doing a
FileMan read of the ^SCTM(404.57 file for the specified record to check for
the existence of the record in the file. This check is to make sure the team
position exists in the file. If the position doesn't exist in the file an
error message is return to the calling application and the RPC stops
execution.\n
This is a data validation check to be sure the data that will be filed when
making a new entry for the Electronic Wait List is valid data. The record in
the file pointed to actually exists. This insures there will not be a broken
pointer when the new record is created.", "", "", "2015/01/30"], ["6065", "GMPL EVENT", "Other", "PROBLEM LIST", "2014/06/13", "APPROVED", "Active", "Controlled Subscription", "", "
The GMPL EVENT protocol is used to pass patient problem
list items from the Problem List package to other packages. This protocol is
exported by the Problem List package.", "", "", "2014/06/16"], ["6066", "DRG SURGICAL HIERARCHY", "File", "DRG GROUPER", "2014/06/13", "APPROVED", "Active", "Private", "80.5", "
Lexicon Utility has all privileges as though it were
the custodial package.\n", "", "", "2014/07/10"], ["6067", "READ ACCESS TO FILE #445.6 (GROUP CATEGORY)", "File", "IFCAP", "2014/06/19", "APPROVED", "Active", "Private", "445.6", "
Request permission for READ access via FileMan calls to
file #445.6 in order to complete RPC queries from WaveMark. This is part of
the RTLS National project to facilitate tracking clinical supplies in the Cath
lab inventory point for GIP.", "", "", "2014/07/02"], ["6068", "READ ACCESS TO FILE #420.5 (UNIT OF ISSUE)", "File", "IFCAP", "2014/06/19", "APPROVED", "Active", "Private", "420.5", "
Request permission for READ access via FileMan calls to
file #420.5 in order to complete RPC queries from WaveMark. This is part of
the RTLS National project to facilitate tracking clinical supplies in the Cath
lab inventory point for GIP.", "", "", "2014/07/02"], ["6069", "ENGINEERING CALL TO RTLS AFTER DATA CHANGE", "Routine", "REAL TIME LOCATION SYSTEM", "2014/06/27", "APPROVED", "Active", "Private", "", "
The RTLS project has requested the Engineering files
#6914 and #6928 to have a number of fields modified with MUMPS
cross-references to report data changes.\n
Whenever an entry is changed in either file #6914 or #6928 which affects any
of the modified fields, a call is made to the RTLS routine VIAATRI to notify
InSites that a data change occurred in Engineering. The call is made by the
MUMPS cross-reference as follows: D WC^VIAATRI(File,DA), where File represents
either file 6914 or file 6928 and DA is the internal entry number of a record
in one of the files. Upon execution of the call, a record is added in the
PENDING RTLS EVENTS file, #6930, and later the record is sent to update
InSites. This event keeps both InSites and VistA synchronized.\n
Patch EN*7.0*95 added cross-references that call WC^VIAATRI on the following
fields:\n
File 6914 Fields .01, 1, 2, 3, 4, 5, 6, 7, 11, 12, 13, 18, 19, 20, 21, 22, 30,
60.\n
File 6928 Fields .01, 1, 1.5", "", "VIAATRI", "2014/07/11"], ["6070", "Pending Outpatient Orders Lookup", "File", "OUTPATIENT PHARMACY", "2014/07/09", "APPROVED", "Active", "Private", "52.41", "
Inpatient Pharmacy allergy order checks need to include
all prescription ordering processes. Inpatient Medications requests direct
global read access to the following pharmacy file:\n\n
^PS(52.41, - PENDING OUTPATIENT ORDERS FILE (#52.41)
Node 0, piece 8 - PHARMACY ORDERABLE ITEM FIELD (#8)
Node 0, piece 9 - DRUG FIELD (#9)", "", "", "2014/09/04"], ["6071", "Outpatient Pharmacy Allergy", "File", "OUTPATIENT PHARMACY", "2014/07/09", "", "Pending", "Private", "", "
This global is used to return the data from a call to
DAOC^PSONEWOA. It contains data split into drug classes, drug ingredients and
pharmacy interventions. Inpatient Medications must access Outpatient Pharmacy
namespaced ^TMP global to perform allergy order checks. This global is
generated by an Inpatient Medications process calling an Outpatient routine.
Inpatient Medications requests direct global Read/Write access to the
following pharmacy ^TMP file:\n
^TMP("PSODAOC",$J,"ALLERGY",) - Outpatient Pharmacy Allergy Data\n
Inpatient Meds kills the TMP global before and after the call to the
Outpatient Pharmacy API.\n
VARIABLES: Input TMP GLOBAL
Nodes descendant from ^TMP("PSODAOC",$J,"ALLERGY",PSOALGCT)
are stored.\n
ROUTINE: PSONEWOA
COMPONENT: DAOC
INPUT:
^TMP("PSODAOC",$J,"ALLERGY",PSOALGCT)=List of allergy order checks
^TMP("PSODAOC",$J,"ALLERGY",PSOALGCT,"ALLERGY DD")=DRUG File IEN
^TMP("PSODAOC",$J,"ALLERGY",PSOALGCT,"ALLERGY PKG")="IP" Hard Set
^TMP("PSODAOC",$J,"ALLERGY",PSOALGCT,"INTERVENTION")=APSP INTERVENTION
File IEN
^TMP("PSODAOC",$J,"ALLERGY","ALLERGY PKG")
$P1 = "IP" Hard Set
$P2 = Process ID i.e., "COPY IV","RENEW UD"
$P3 = Prescription Order Number
$P4 = ORDER File IEN
^TMP("PSODAOC",$J,"ALLERGY","PROVR")= Provider Override Reason", "", "", ""], ["6072", "Allergy Order Check Filing", "Routine", "OUTPATIENT PHARMACY", "2014/07/09", "APPROVED", "Active", "Private", "", "
This DBIA provides the DAOC^PSONEWOA routine call for
Inpatient Medications to make to Outpatient Pharmacy. It takes the ^TMP global
input data sent in from Inpatient Medications that contains allergy order
check data and creates an entry in the ORDER CHECK INSTANCES File (#100.05),
by invoking SAVEOC^OROCAPI1.", "", "PSONEWOA", "2017/11/14"], ["6073", "PREGNANCY AND LACTATION DATA", "Routine", "WOMEN'S HEALTH", "2014/07/10", "", "Expired", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to retrieve pregnancy and lactation data for a patient. The APIs were
designed for use by the reminder computed finding functionality of the
Clinical Reminders package.", "", "WVTDCF", ""], ["6074", "Stored Order Check Display", "", "OUTPATIENT PHARMACY", "", "", "", "Private", "", "", "", "", ""], ["6075", "Pharmacy Order Check Display", "Routine", "OUTPATIENT PHARMACY", "2014/07/14", "APPROVED", "Active", "Private", "", "
This is an internal Pharmacy API used to display stored
pharmacy order checks.", "", "PSOOCKV1", "2014/07/25"], ["6076", "Pharmacy Intervention Log", "Routine", "INPATIENT MEDICATIONS", "2014/07/14", "APPROVED", "Active", "Private", "", "
This is an internal pharmacy API used by Inpatient
Medications and Outpatient Pharmacy to log pharmacy interventions.", "", "PSJRXI", "2014/09/05"], ["6077", "TIU APIS FOR VPR", "Routine", "TEXT INTEGRATION UTILITIES", "2014/07/16", "APPROVED", "Active", "Private", "", "
TIUVPR provides generic api's to allow the Virtual
Patient Record (VPR) to retrieve all of a patient's documents, regardless of
status or class. Class and authorization filters will be applied by the
Health Management Platform (HMP) as documents are requested by the current
user.", "", "TIUVPR", "2014/09/24"], ["6078", "VPR EVENTS", "Routine", "VIRTUAL PATIENT RECORD", "2014/07/16", "APPROVED", "Active", "Controlled Subscription", "", "
VPREVNT contains various line tags to be used by other
VistA applications without event protocols to notify VPR of new or modified
data.\n
These hooks were exported in the VPR*1*3 patch bundle which was never released
to the field; it was, however, posted to OSEHRA as code-in-flight and as such
are being documented here. The patches referenced with each subscriber were
included in this bundle to install the respective indices.", "", "VPREVNT", "2015/08/21"], ["6079", "CLINICAL REMINDERS API", "Routine", "CLINICAL REMINDERS", "2014/07/31", "", "Withdrawn", "Controlled Subscription", "", "
VPS Kiosk calls MAIN^PXRM to retrieve the clinical
reminders due now for a specific patient DFN. VPS Kiosk input parameters
VPSDFN and VPSIEN map to PXRM parameters DFN and PXRMITEM, respectively. VPS
Kiosk reads Clinical Reminder data returned in ^TMP("PXRHM",$J).", "", "", ""], ["6080", "CLINICAL REMINDERS API", "Routine", "CLINICAL REMINDERS", "2014/08/04", "APPROVED", "Active", "Controlled Subscription", "", "
VPS Kiosk needs the use of CATREM^PXRMAPI0 to store
CATEGORY Clinical Reminders to an array. VPS input to the routine is the
patient DFN and the pointer to the VPS array to receive the Clinical Reminder
data returned.", "", "", "2014/10/21"], ["6081", "Proxy User for HCPS", "Routine", "KERNEL", "2014/08/05", "APPROVED", "Active", "Private", "200", "
The Consult/Request Tracking (GMRC) package can
establish the Application Proxy HCPS,APPLICATION PROXY user. This user will
be used to establish an user environment when processing HL7 messages between
Healthcare Claims Processing System (HCPS) and VistA. The user will not have
Access or Verify codes and will have a User Class of APPLICATION PROXY.\n
The GMRC application can use the API $$CREATE^XUSAP(proxyname, fmacc, options)
in patch GMRC*3*75 to create the user.
INPUT: proxyname = HCPS,APPLICATION PROXY
fmacc = FileMan Access Code
options = should be blank, user doesn't need any options\n
This ICR is for 1 year. At the end of a year it should be re-evaluated to see
if a non-anonymous solution exists in VistA.\n\n", "", "XUSAP", "2015/08/21"], ["6082", "Calls to GMRCAPI", "Routine", "CONSULT/REQUEST TRACKING", "2014/08/13", "APPROVED", "Active", "Controlled Subscription", "", "
GMRCAPI contains calls to return data from the
Request/Consultation file #123.", "", "GMRCAPI", "2014/09/05"], ["6083", "TIU GET DOCUMENT STATUS", "Routine", "TEXT INTEGRATION UTILITIES", "2014/08/13", "APPROVED", "Active", "Controlled Subscription", "", "
This API is used to retrieve the Status (8925.6 IEN) of
a TIU DOCUMENT.", "", "TIUPRF2", "2014/09/11"], ["6084", "MDC OBSERVATION UPDATE", "Other", "CLINICAL PROCEDURES", "2014/08/14", "APPROVED", "Active", "Controlled Subscription", "", "
The MDC OBSERVATION UPDATE protocol is used to notify
other packages when observation data is updated.", "", "", "2014/09/05"], ["6085", "PSB EVSEND VPR", "Other", "BAR CODE MED ADMIN", "2014/08/14", "APPROVED", "Active", "Controlled Subscription", "", "
The PSB EVSEND VPR protocol notifies subscribing
packages when a med order is administered.", "", "", "2016/05/04"], ["6086", "RA EVSEND OR", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "2014/08/14", "APPROVED", "Active", "Controlled Subscription", "", "
The RA EVSEND OR protocol is used to pass order
messages from the Radiology/Nuclear Medicine package to other VistA
applications.", "", "", "2014/09/05"], ["6087", "LR7O CH EVSEND OR", "Other", "LAB SERVICE", "2014/08/14", "APPROVED", "Active", "Controlled Subscription", "", "
The LR7O CH EVSEND OR protocol is used to pass order
messages from the Laboratory package to other VistA applications.", "", "", "2014/09/05"], ["6088", "VPR READ OF USER CLASS", "File", "AUTHORIZATION/SUBSCRIPTION", "2014/08/15", "APPROVED", "Active", "Private", "8930", "
The Virtual Patient Record (VPR) needs the User Classes
to accurately apply ASU business rules in the Health Management Platform (HMP)
client.", "", "", "2016/05/09"], ["6089", "VPR READ OF ASU RULES", "File", "AUTHORIZATION/SUBSCRIPTION", "2014/08/15", "APPROVED", "Active", "Private", "8930.1", "
The Virtual Patient Record (VPR) needs the
Authorization/Subscription rules to accurately apply ASU business rules in the
Health Management Platform (HMP) client.", "", "", "2014/09/05"], ["6090", "OR EVSEND FH", "Other", "ORDER ENTRY/RESULTS REPORTING", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when a new order, or
action to an order, is placed to the Dietetics package. Actions from any
application area that are dependent on this event may be added as Items upon
approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order to Dietetics as defined in the
'OE/RR Version 3 Package Interface Specifications' document.", "", "", "2015/09/25"], ["6091", "OR EVSEND LRCH", "Other", "ORDER ENTRY/RESULTS REPORTING", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when a new order, or
action to an order, is placed to the Laboratory package. Actions from any
application area that are dependent on this event may be added as Items upon
approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order to Lab as defined in the 'OE/RR
Version 3 Package Interface Specifications' document.", "", "", "2015/09/25"], ["6092", "OR EVSEND ORG", "Other", "ORDER ENTRY/RESULTS REPORTING", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when a new order, or
action to an order, is placed to the OE/RR package. Actions from any
application area that are dependent on this event may be added as Items upon
approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order to OE/RR as defined in the 'OE/RR
Version 3 Package Interface Specifications' document.", "", "", "2015/09/25"], ["6093", "OR EVSEND PS", "Other", "ORDER ENTRY/RESULTS REPORTING", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when a new order, or
action to an order, is placed to the Pharmacy packages. Actions from any
application area that are dependent on this event may be added as Items upon
approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order to Pharmacy as defined in the 'OE/RR
Version 3 Package Interface Specifications' document.", "", "", "2015/09/25"], ["6094", "OR EVSEND RA", "Other", "ORDER ENTRY/RESULTS REPORTING", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when a new order, or
action to an order, is placed to the Radiology/NM package. Actions from any
application area that are dependent on this event may be added as Items upon
approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order to Radiology as defined in the
'OE/RR Version 3 Package Interface Specifications' document.", "", "", "2015/09/25"], ["6095", "OR EVSEND VPR", "Other", "ORDER ENTRY/RESULTS REPORTING", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when an action to an
order occurs that does not trigger any other event, to notify the Virtual
Patient Record. Actions from any application area that are dependent on this
event may be added as Items upon approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the order action as defined in the 'OE/RR
Version 3 Package Interface Specifications' document.", "", "", "2015/09/25"], ["6096", "OR EVSEND DGPM", "Other", "ORDER ENTRY/RESULTS REPORTING", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
This is the event invoked by CPRS when an order is
placed that can update patient movements or assign providers, to notify the
Registration package. Actions from any application area that are dependent on
this event may be added as Items upon approval.\n
The array XQORMSG(#) will be available for all subscribers to read only,
containing the HL7 message with the information as defined in the 'OE/RR
Version 3 Package Interface Specifications' document.", "", "", "2015/09/25"], ["6097", "FH EVSEND OR", "Other", "DIETETICS", "2014/08/20", "APPROVED", "Active", "Controlled Subscription", "", "
The FH EVSEND OR protocol is used to pass order
messages from the Dietetics package to other VistA applications.", "", "", "2017/07/10"], ["6098", "MEANS TEST STATUS file", "File", "REGISTRATION", "2014/08/24", "APPROVED", "Active", "Private", "408.31", "
VPS Kiosks has a need to provide a patient's HARDSHIP
means test status to the VetLink application. VPS RPC, VPS ENHANCED GET
PATIENT DEMOGRAPHICS, uses the "C" cross-reference of ^DGMT(408.31 to find a
patient's means test, then reads field .2 (0;20) of the patient's entry to
obtain the patient's hardship status.", "", "", "2015/07/22"], ["6099", "READ PATIENT ENROLLMENT (#27.11) FILE", "File", "REGISTRATION", "2014/08/24", "APPROVED", "Active", "Controlled Subscription", "27.11", "
VPS Kiosks has a need to provide patient eligibility
information to the VetLink application.", "", "", "2015/04/27"], ["6100", "ORWOR DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/08/25", "APPROVED", "Active", "Private", "", "
VA Point of Service (Kiosks) has a need to provide the
detailed information for a patient's lab orders to VetLink. VA Point of
Service (Kiosks) will pass the order IEN and patient DFN as parameters to
retrieve the order details.\n
Input: ORDIEN ; order identifier
DFN ; patient identifier\n
TAG^ROUTINE: DETAIL^ORWOR", "", "", "2014/09/30"], ["6101", "ORPRO7 ORDOC", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2014/08/25", "APPROVED", "Active", "Controlled Subscription", "", "
Returns the ordering provider for a patient order.", "", "ORPR07", "2014/10/29"], ["6102", "ORDER FILE READ", "File", "ORDER ENTRY/RESULTS REPORTING", "2014/08/25", "APPROVED", "Active", "Controlled Subscription", "100", "", "", "", "2014/08/29"], ["6103", "HLO MESSAGE BODY (#777) direct global read", "File", "HEALTH LEVEL SEVEN", "2014/09/08", "APPROVED", "Active", "Private", "777", "
The VistA Health Level Seven application will grant
VistA Imaging the privilege to read the HLO MESSAGE BODY (#777) global
directly.", "", "", "2015/01/12"], ["6104", "LRHY GET SITES RPC", "Remote Procedure", "LAB SERVICE", "2014/09/23", "APPROVED", "Active", "Controlled Subscription", "69.86", "\n
NAME: LRHY GET SITES TAG: GETSITES
ROUTINE: LRHYRP01 RETURN VALUE
TYPE: ARRAY
DESCRIPTION:
This RPC will return all Howdy Sites
USAGE: Controlled Subscri ENTERED: SEP 23,2014
STATUS: Pending EXPIRES:
DURATION: VERSION:
DESCRIPTION: TYPE: Remote Procedure", "", "", "2014/10/02"], ["6105", "69.01 SPECIMEN # SUB-FILE", "File", "LAB SERVICE", "2014/09/23", "", "Withdrawn", "Controlled Subscription", "69.01", "
The laboratory Specimen # sub-file.", "", "", ""], ["6106", "DGCN(391.91 GET DFN FROM EDIPI", "File", "REGISTRATION", "2014/09/24", "", "Withdrawn", "Controlled Subscription", "391.91", "
Treating Facility List where patients have had
treatment.", "", "", ""], ["6107", "ORWPT1 PCDETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/09/24", "", "Withdrawn", "Controlled Subscription", "", "
Following are details of the RPC:\n
NAME: ORWPT1 PRCARE TAG: PRCARE
ROUTINE: ORWPT1 RETURN VALUE TYPE: SINGLE VALUE
DESCRIPTION:\n\n
Return primary care information for a patient in the format:
VAL=Primary Care Team^Primary Care Provider^Attending^MH Treatment
Coordinator
INPUT PARAMETER: dfn
Return primary care information for a patient in the format:
VAL=Primary Care Team^Primary Care Provider^Attending\n
TAG^ROUTINE: PRCARE^ORWPT1", "", "", ""], ["6108", "LRHY GET BINGO BOARDS", "Remote Procedure", "LAB SERVICE", "2014/09/24", "", "Pending", "Controlled Subscription", "", "
ABC", "", "", ""], ["6109", "LRHY GET SITE PRINTERS", "Remote Procedure", "LAB SERVICE", "2014/09/25", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: LRHY GET SITE PRINTERS TAG: GETHYPRT
ROUTINE: LRHYRP01
RETURN VALUE TYPE: ARRAY
DESCRIPTION:
This RPC will return all Howdy Printers for a given Howdy Site INPUT
PARAMETER: LRSITE PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 15 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Howdy Site IEN", "", "", "2014/10/02"], ["6110", "LRHY GET BINGO BOARDS", "Remote Procedure", "LAB SERVICE", "2014/09/25", "", "Pending", "Controlled Subscription", "", "\n
NAME: LRHY GET BINGO BOARDS TAG: GETBINGO
ROUTINE: LRHYRP01 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
This RPC will return Howdy Bingo Board Devices for a given Howdy Site INPUT
PARAMETER: LRSITE PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 30 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Howdy Site", "", "", ""], ["6111", "LRHY GET BINGO BOARDS", "Remote Procedure", "LAB SERVICE", "2014/09/25", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
NAME: LRHY GET BINGO BOARDS TAG: GETBINGO
ROUTINE: LRHYRP01 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
This RPC will return Howdy Bingo Board Devices for a given Howdy Site INPUT
PARAMETER: LRSITE PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 30 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Howdy Site", "", "", "2014/10/02"], ["6112", "LRHY PATIENT CHECK-IN", "Remote Procedure", "LAB SERVICE", "2014/09/25", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: LRHY PATIENT CHECK-IN
TAG: PTCHKIN ROUTINE: LRHYRP02
RETURN VALUE TYPE: SINGLE VALUE
DESCRIPTION:
This RPC will return result of Howdy Patient Check-In. INPUT PARAMETER:
LRHYPTYP PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 7 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION:
Patient ID Type. Valid Value: SSN, DFN, ICN, or VIC/CAC INPUT PARAMETER:
LRHYPTID PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 15 REQUIRED: YES
SEQUENCE NUMBER: 2
DESCRIPTION:
Patient ID for the type. INPUT PARAMETER: LRHYSITE PARAMETER
TYPE: LITERAL
MAXIMUM DATA LENGTH: 5 REQUIRED: YES
SEQUENCE NUMBER: 3
DESCRIPTION:
Howdy Site IEN INPUT PARAMETER: LRHYTYPE PARAMETER TYPE:
LITERAL", "", "", "2014/10/02"], ["6113", "811.9", "File", "CLINICAL REMINDERS", "2014/09/25", "", "Withdrawn", "Controlled Subscription", "811.9", "", "", "", ""], ["6114", "AUPNPROB REFERENCES", "File", "PROBLEM LIST", "2014/09/26", "APPROVED", "Active", "Controlled Subscription", "9000011", "
VA Point of Service (Kiosks) reference to PROBLEM file
#9000011.", "", "", "2014/11/05"], ["6115", "IBA 354", "File", "INTEGRATED BILLING", "2014/09/26", "", "Withdrawn", "Controlled Subscription", "354", "", "", "", ""], ["6116", "123 REFERENCES", "File", "CONSULT/REQUEST TRACKING", "2014/09/26", "APPROVED", "Active", "Controlled Subscription", "123", "", "", "", "2014/10/02"], ["6117", "123.5 REFERENCES", "File", "CONSULT/REQUEST TRACKING", "2014/09/26", "", "Withdrawn", "Controlled Subscription", "123.5", "", "", "", ""], ["6118", "VPS VALIDATE PATIENT ID", "Routine", "VA POINT OF SERVICE (KIOSKS)", "2014/10/01", "", "Withdrawn", "Supported", "", "
The VPS Validate Patient ID is an API that accepts a
patient identifier type-value pair and returns the DFN of the patient. Valid
patient identifier types are SSN, DFN, ICN, and VIC/CAC.\n
The API checks the format of the patient identifier value to verify that the
identifier value conforms to the expected format for the specified identifier
type. If the value format does not match the identifier type format, an error
message is returned.\n
The patient identifier type is used to select a lookup routine to use to
obtain the DFN corresponding to the type-value pair submitted. If the DFN is
found in PATIENT file #2, the DFN is returned, otherwise a PATIENT NOT FOUND
error message is returned.", "", "VPSRPC1", ""], ["6119", "ROR LIST HOSPITAL LOCATION RPC", "Remote Procedure", "CLINICAL CASE REGISTRIES", "2014/10/01", "", "Withdrawn", "Controlled Subscription", "", "", "", "", ""], ["6120", "REBUILD TAXONOMY AUID INDEX", "Routine", "CLINICAL REMINDERS", "2014/10/02", "APPROVED", "Active", "Private", "", "", "", "PXRMTAXD", "2014/10/03"], ["6121", "REMOVE SCHEDULED OPTIONS FROM #19.2", "File", "KERNEL", "2014/10/03", "", "Active", "Private", "19.2", "
Scheduling (PCMM, PCMM WEB, PAIT, ACRP, and EWL)
requests permission to lookup and delete entries in the Option Scheduling
(19.2) File for the Options - SCMC PCMM NIGHTLY TASK, SCMC PCMM HL7 NIGHTLY
TASK, SD-PAIT TASKED TRANSMISSION, SCDX AMCAR NIGHTLY XMIT, SD WAIT LIST TRANS
TO AAC. Task SCMC PCMM NIGHTLY TASK will no longer be required to run on
VistA; it will be performed by the new PCMM Web application. SCMC PCMM HL7
NIGHTLY TASK, SD-PAIT TASKED TRANSMISSION, SCDX AMCAR NIGHTLY XMIT, SD WAIT
LIST TRANS TO AAC have been replaced by the Corporate Data Warehouse (CDW).
This will be done by a post-install routine using the ^DIK Fileman API in
patch SD*5.3*603, SD*5.3*624, SD*5.3*638, SD*5.3*639, AND SD*5.3*640. (PCMM,
PCMM WEB, PAIT, ACRP, and EWL functionality falls under the Scheduling
namespace.)\n
AMIE and CAPRI Options - DVBA C PURGE 2507 and DVBA REGIONAL PURGING PROGRAM
will also use this agreement to be deleted from the Option Scheduling File.
This will be done by a post-install routine using the ^DIK Fileman API in
patch DVBA*2.7*195.\n
This ICR is only valid for SD*5.3*603, SD*5.3*624, SD*5.3*638, SD*5.3*639,
SD*5.3*640 and DVBA*2.7*195.\n\n\n", "", "", "2015/01/29"], ["6122", "HLB OUT POINTER X-REF", "File", "HEALTH LEVEL SEVEN", "2014/11/03", "APPROVED", "Active", "Controlled Subscription", "778", "
VA POINT OF SERVICE (KIOSKS) is providing patient
appointment status using HL7 messaging, and needs to use the
^HLB("QUEUE","OUT",LINKPORT,QUEUE) global reference to lock and unlock an
active VPS message queue.", "", "", "2015/03/20"], ["6123", "DOWORK HLOCLNT", "Routine", "HEALTH LEVEL SEVEN", "2014/11/03", "", "Withdrawn", "Controlled Subscription", "", "", "", "HLOCLNT", ""], ["6124", "CLOSE HLOT", "Routine", "HEALTH LEVEL SEVEN", "2014/11/05", "", "Withdrawn", "Controlled Subscription", "", "", "", "HLOT", ""], ["6125", "READ PATIENT FILE FIELDS", "File", "REGISTRATION", "2014/11/06", "APPROVED", "Active", "Controlled Subscription", "2", "", "", "", "2015/02/25"], ["6126", "IB READ/WRITE ACCESS W/FILEMAN TO LOCK FIELD (#3)", "File", "KERNEL", "2014/11/07", "APPROVED", "Active", "Private", "19", "
IB requires the ability to delete a LOCK from an
OPTION. This cannot be accomplished using KIDS. Permission is required to
accomplish this task using pre- or post-install routines in KIDS.", "", "", "2014/12/03"], ["6127", "ORWOR VWGET", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/11/17", "APPROVED", "Active", "Controlled Subscription", "", "", "ORWOR VWGET", "", "2015/08/13"], ["6128", "ICPTCOD Update CSV APIs", "Routine", "CPT/HCPCS CODES", "2014/11/17", "APPROVED", "Active", "Supported", "", "
$$NM and $$LD were added as part of the Code Set
Versioning APIs in patch ICPT*6.0*46.\n", "", "ICPTCOD", "2015/02/23"], ["6129", "ICPTMOD Update CSV APIs", "Routine", "CPT/HCPCS CODES", "2014/11/17", "APPROVED", "Active", "Supported", "", "
$$NM, $$LD, $$CM and $$MODC were added as part of the
Code Set Versioning APIs in patch ICPT*6.0*46.\n", "", "ICPTMOD", "2015/02/23"], ["6130", "DGPTFUT", "Routine", "REGISTRATION", "2014/11/20", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR supports access to PTF (#45) data fields for
the following PTF record types.\n
Patient Treatment File record types:
------------------------------------
401 - Surgery 501 -
Movement 601 -
Procedure 701 -
Diagnosis 801 - CPT\n
Data fields may be accessed using the following APIs.\n
PTFIEN
------
This subroutine provides information about the subscripts of the multiples of
the different PTF record types. These subscripts are needed for the other API
calls.\n
PTFICD
------
This subroutine returns an array of the ICD's (IENs, codes, & descriptions),
along with present on admission (POA) indicators (codes & values), where
appropriate.\n
STR401
------
Given a patient (PTF IEN) and operation record type multiple, return a
twenty-five piece string containing the operation code ICD IENs.\n
STR501
------
Given a patient (PTF IEN) and movement record type multiple, return a
twenty-five piece string containing the movement code ICD IENs.\n
STR501P
-------
Given a patient (PTF IEN) and movement record type multiple, return a
twenty-five piece string containing the present on admission (POA) codes.\n
STR601
------
Given a patient (PTF IEN) and procedure record type multiple, return a
twenty-five piece string containing the procedure code ICD IENs.\n
STR701
------
Given a patient (PTF IEN), return a twenty-five piece string containing the
diagnosis code ICD IENs.\n
STR701P
-------
Given a patient (PTF IEN), return a twenty-five piece string containing the
present on admission (POA) codes.", "", "DGPTFUT", "2015/08/03"], ["6131", "IBNCPEV3", "Routine", "INTEGRATED BILLING", "2014/11/20", "APPROVED", "Active", "Private", "", "
The ECME application requires access to the IB NCPDP
EVENT LOG to extract data needed for the ECME Non-Billable Status Report.", "", "IBNCPEV3", "2015/02/06"], ["6132", "ORWPCE PCE4NOTE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/11/21", "", "Pending", "Controlled Subscription", "", "", "ORWPCE PCE4NOTE", "", ""], ["6133", "ORWGRPC ITEMDATA", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2014/11/21", "", "Withdrawn", "Controlled Subscription", "", "", "", "ORWGRPC", ""], ["6134", "ORWPCE SAVE", "Routine", "PCE PATIENT CARE ENCOUNTER", "2014/11/21", "", "Withdrawn", "Controlled Subscription", "", "
Saves PCE information.", "ORWPCE SAVE", "PXRPC", "2015/11/24"], ["6135", "ORWLRR INTERIM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2014/11/21", "", "Pending", "Controlled Subscription", "", "", "ORWLRR INTERIM", "", ""], ["6136", "DB6136", "File", "INTEGRATED BILLING", "2014/11/24", "APPROVED", "Active", "Private", "366.17", "
The ECME application needs to extract the NON-BILLABLE
REASON (#.01) field from the IB NCPDP NON-BILLABLE REASONS file. This is a
read-only action and does not modify any fields in the file.\n
The ECME application also requests lookup capabilities on the file via
Fileman. No modification of the data will be done.", "", "", "2015/02/06"], ["6137", "APPT CANCEL REMARKS", "File", "SCHEDULING", "2014/11/26", "APPROVED", "Active", "Controlled Subscription", "2.98", "
VPS returns a patient's outpatient clinic appointment
status to Vetlink. The outpatient clinic appointment information returned
includes the cancellation remarks obtained from the APPOINTMENT sub-file 2.98,
field 17.", "", "", "2015/01/06"], ["6138", "HEALTH BENEFIT PLAN INFORMATION", "Routine", "REGISTRATION", "2014/12/02", "APPROVED", "Active", "Controlled Subscription", "", "
ICR for Health Benefit Plans (HBP) to be shared by
other VistA applications.\n
8/21/15: Routine DGHBPUTL will be distributed by patch DG*5.3*871. The status
of the ICR has been set to Deferred until patch is released and Subscribing
Packages are identified.", "", "DGHBPUTL", "2015/12/17"], ["6139", "BPSUTIL2", "Routine", "E CLAIMS MGMT ENGINE", "2014/12/02", "APPROVED", "Active", "Controlled Subscription", "", "
The Accounts Receivable (AR) and Integrated Billing
(IB) packages need to verify whether a pharmacy electronic claim number
returned by a third party payer is valid or not. The verification will be used
in the process to match payments received with existing open claims.", "", "BPSUTIL2", "2014/12/10"], ["6140", "FINDC", "Routine", "INPATIENT MEDICATIONS", "2014/12/03", "", "Pending", "Private", "", "
Inpatient Meds allows Outpatient Pharmacy to use
$$FIND^PSJDGAL2 which returns the formated orderable item, dose form and units
as: orderable item doseform (units) ex: MORPHINE TAB,SA (100MG).", "", "PSJDGAL2", ""], ["6141", "RPC VEJDVEST", "Routine", "VENDOR - DOCUMENT STORAGE SYS", "2014/12/04", "", "Withdrawn", "Controlled Subscription", "", "", "", "VEJDVEST", ""], ["6142", "INSURANCE COMPANY LOOKUP", "File", "INTEGRATED BILLING", "2014/12/09", "APPROVED", "Active", "Private", "36", "
Outpatient Pharmacy requires a lookup and extract on
the NAME (#.01) field of the Insurance Company (#36) file via Fileman. No
changes to the file will be made.", "", "", "2015/02/06"], ["6143", "IB SITE PARAMETERS FILE ACCESS", "File", "INTEGRATED BILLING", "2015/01/08", "APPROVED", "Active", "Private", "350.9", "
The Insurance Capture Buffer application reads file
#350.9 IB SITE PARAMETERS to determine what field lengths the site wishes to
use.", "", "", "2018/01/04"], ["6144", "PID SEGMENT BUILDING - RETURN RACE AND ETHNICITY", "Routine", "REGISTRATION", "2015/01/13", "APPROVED", "Active", "Private", "", "
VAFHLPI1 is a routine that is used to build the PID
segment of HL7 messages. It is comprised of functions that return the race and
the ethnicity of a patient.", "", "VAFHLPI1", "2015/08/04"], ["6145", "VPS READ 40.8", "File", "REGISTRATION", "2015/01/20", "", "Withdrawn", "Controlled Subscription", "40.8", "
This IA provides for the Fileman read of the NAME,
INSTITUTION FILE POINTER, and FACILITY NUMBER fields in the INSTITUTION FILE
file #40.8.", "", "", ""], ["6146", "VPS READ OF 8930.3", "File", "AUTHORIZATION/SUBSCRIPTION", "2015/01/20", "", "Withdrawn", "Controlled Subscription", "8930.3", "
VA Point of Service Kiosks needs to read global
references in the USER CLASS MEMBERSHIP FILE #8930.3.", "", "", ""], ["6147", "VPS READ OF 3.5", "File", "KERNEL", "2015/01/26", "APPROVED", "Active", "Controlled Subscription", "3.5", "
This IA provides for the Fileman read of the NAME,
LOCATION OF TERMINAL, MARGIN WIDTH, PAGE LENGTH, and PRINT SERVER NAME OR
ADDRESS fields in the DEVICE file #3.5.", "", "", "2015/03/03"], ["6148", "VPS READ OF 52.41", "File", "OUTPATIENT PHARMACY", "2015/01/26", "APPROVED", "Active", "Controlled Subscription", "52.41", "
This IA provides for the Fileman read of the\n
PLACER NUMBER, ORDER TYPE, # OF REFILLS, REASON ORDER CREATED, PATIENT
of the PENDING OUTPATIENT ORDERS FILE #52.41,\n
CONJUNCTION, UNITS fields of the QUANTITY TIMING SUB-FILE
subfile #52.413 of the PENDING OUTPATIENT ORDERS file #52.41, and\n
the DISPENSING INSTRUCTIONS field of the DISPENSING
INSTRUCTIONS subfile #52.4124 in the PENDING OUTPATIENT
ORDERS file #52.41.", "", "", "2015/03/19"], ["6149", "VPS READ OF 52", "File", "OUTPATIENT PHARMACY", "2015/01/26", "APPROVED", "Active", "Controlled Subscription", "52", "
This IA provides for the Fileman read of the RX #,
PLACER ORDER #, STATUS, NDC, # OF REFILLS, REMARKS, RELEASED DATE/TIME,
PREVIOUS ORDER #, FORWARD ORDER # fields in the PRESCRIPTION file #52.", "", "", "2015/03/11"], ["6150", "VPS READ OF 403.5", "File", "SCHEDULING", "2015/01/26", "APPROVED", "Active", "Controlled Subscription", "403.5", "
This IA provides for the Fileman read of the PATIENT
NAME, TEST/APP, PROVIDER, CLINIC, RECALL DATE fields in the RECALL REMINDERS
file #403.5.", "", "", "2015/04/07"], ["6151", "VPS READ OF 52.4124", "File", "OUTPATIENT PHARMACY", "2015/01/26", "APPROVED", "Withdrawn", "Controlled Subscription", "52.41", "
This IA provides for the Fileman read of the DISPENSING
INSTRUCTIONS field in the DISPENSING INSTRUCTIONS sub-file #52.4124.", "", "", "2015/03/06"], ["6152", "VPS READ OF 120.8", "File", "ADVERSE REACTION TRACKING", "2015/01/26", "APPROVED", "Active", "Controlled Subscription", "120.8", "
This IA provides for the Fileman read of the REACTANT,
ALLERGY TYPE, VERIFICATION DATE/TIME, and PATIENT fields in the PATIENT
ALLERGIES file #120.8.", "", "", "2015/03/26"], ["6153", "VPS WRITE TO 9000010.23", "File", "PCE PATIENT CARE ENCOUNTER", "2015/01/26", "", "Withdrawn", "Controlled Subscription", "9000010.23", "
This IA provides for the Fileman WRITE of the PATIENT
NAME (.02) and VISIT (.07) fields in the V HEALTH FACTORS file #9000010.23.", "", "", "2015/11/09"], ["6154", "VPS READ OF 8925", "File", "TEXT INTEGRATION UTILITIES", "2015/01/26", "APPROVED", "Active", "Controlled Subscription", "8925", "
This IA provides for the Fileman read of the DOCUMENT
TYPE, STATUS, EPISODE BEGIN DATE/TIME, AUTHOR/DICTATOR, VISIT LOCATION,
PATIENT fields in the TIU DOCUMENT file #8925.", "", "", "2015/03/24"], ["6155", "READ ACCESS TO DMMS UNITS SUB-FIELD IN NEW PERSON FILE #200", "File", "EVENT CAPTURE", "2015/01/27", "APPROVED", "Active", "Private", "200", "
EVENT CAPTURE owns the DMMS UNITS sub-field (#720) in
NEW PERSON File (#200).\n
MHV Secure Messaging - Work Load Credit functionality allows users to save the
workload credit using the assigned DSS units, and stores the record in Event
Capture System. The use of the DSS units is the same as in ECS, users have
access to link their work to DSS units that send the record to PCE, as well as
historical DSS units for historical workload credit forms that do not send the
information to PCE.\n
Three conditions need to be satisfied before DSS Unit can be presented to
provider 1. DSS Unit must be active. 2. Provider should have that DSS Unit in
the assigned (MHV) list of DSS Units. 3. DSS Unit should also be associated
with Location (Associated clinic) selected in front-end. MHV checks for these
three conditions and sends back DSS Units that pass this criteria. To check
Condition #2, MHV reads DMMS Units sub-field (#720) in NEW PERSON File (#200)
which is owned by EVENT CAPTURE.", "", "", "2015/01/29"], ["6156", "PSOTRI", "Routine", "OUTPATIENT PHARMACY", "2015/01/28", "APPROVED", "Active", "Private", "", "
The ECME application requires the ability to create
entries in the PSO Audit Log (#52.87) file by using the AUDIT^PSOTRI entry
point that is already used internally by the Outpatient Pharmacy package.", "", "PSOTRI", "2015/02/02"], ["6157", "XLFSHAN", "Routine", "KERNEL", "2015/02/05", "APPROVED", "Active", "Supported", "", "
This DBIA describes supported references in the routine
XLFSHAN which provides Kernel APIs for Secure Hash Algorithm (SHA) hashing of
input of various formats.\n
Federal Information Processing Standards Publication 180-4 (FIPS PUB 180-4)
specifies secure hash algorithms for computing a condensed representation of
electronic data (message). The hash algorithms specified in this Standard are
called secure because, for a given algorithm, it is computationally infeasible
1) to find a message that corresponds to a given message digest, or 2) to find
two different messages that produce the same message digest. Any change to a
message will, with a very high probability, result in a different message
digest.", "", "XLFSHAN", "2017/12/19"], ["6158", "MBAA Read Access to Recall Reminders Providers File", "File", "SCHEDULING", "2015/02/12", "", "Withdrawn", "Private", "403.54", "
The Scheduling Calendar View Mobile App (MBAA
namespace) needs to read the Recall Reminders Providers File (#403.54) to look
up what security keys are required for a provider to use the recall reminders.\n
This is used by the MBAA RPC MBAA REMOVE FROM RECALL LIST, in routine
MBAARPC1, line tag REMREC. A FileMan read is made to the file to get the
security key (Field #6, KEY) needed for a user to enter or edit a recall
reminder for the specified provider.", "", "", ""], ["6159", "MAG4 ADD IMAGE", "Remote Procedure", "IMAGING", "2015/02/18", "", "Withdrawn", "Controlled Subscription", "", "", "MAG4 ADD IMAGE", "", ""], ["6160", "MAG3 TIU IMAGE", "Remote Procedure", "IMAGING", "2015/02/18", "", "Withdrawn", "Controlled Subscription", "", "", "MAG3 TIU IMAGE", "", ""], ["6161", "MAG4 IMAGE LIST", "Remote Procedure", "IMAGING", "2015/02/18", "", "Withdrawn", "Controlled Subscription", "", "", "", "", ""], ["6162", "MAGBAPIP", "Routine", "IMAGING", "2015/02/18", "APPROVED", "Active", "Controlled Subscription", "", "", "", "MAGBAPIP", "2015/04/03"], ["6163", "MAGBAPI", "Routine", "IMAGING", "2015/02/18", "APPROVED", "Active", "Controlled Subscription", "", "", "", "MAGBAPI", "2015/04/03"], ["6164", "RETRIEVE PATIENT'S PREGNANCY/LACTATION DATA", "Routine", "WOMEN'S HEALTH", "2015/02/24", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to retrieve data from the Women's Health package.", "", "WVRPCPT", "2017/11/17"], ["6165", "UPDATE PATIENT DATA", "Routine", "WOMEN'S HEALTH", "2015/02/24", "APPROVED", "Active", "Private", "", "
This integration agreement allows subscribing packages
to add or update data in a subset of files and fields. These files and fields
are:\n
WVPATIENT (#790)
CX TX NEED (#.11)
CX TX NEED DUE DATE (#.12)
BR TX NEED (#.18)
BR TX NEED DUE DATE (#.19)
PREGNANCY STATUSES (#40), as file #790.05
All fields
LACTATION STATUSES (#50), as file #790.16
All fields
WV PROCEDURE (#790.1)
PROCEDURE (#.04)
RESULTS/DIAGNOSIS (#.05)
OUTSIDE REPORT (#.36)
COMMENTS (#3.01)
PROCEDURE ACTIONS (#10), as file #790.23
WV NOTIFICATION (#790.4)
All fields
WV PREGNANCY/LACTATION STATUS CONFLICT EVENTS (#790.9)
DATE/TIME OCCURRED (#.01)\n
Subscribers of this agreement should also subscribe to agreement #6166 UPDATE
PATIENT DATA VERIFICATION. The proper calling order for these agreements is to
first call the application programming interface (API) documented in agreement
#6166 to verify the WVDATA array is valid and well-constructed then call the
API in this agreement to save the data in the WVDATA array.\n
This API is transactional in nature. If the subscriber needs to both update
existing data and add new data, then the subscriber needs to call this API
twice: once for the update and once for the add.", "", "WVRPCPT", "2017/11/17"], ["6166", "UPDATE PATIENT DATA VERIFICATION", "Routine", "WOMEN'S HEALTH", "2015/02/24", "APPROVED", "Active", "Private", "", "
This integration agreement allows subscribing packages
to verify the data to send to the application programming interface (API)
documented in agreement #6165 is valid and well-constructed.\n
Subscribers of this agreement should also subscribe to agreement #6165 UPDATE
PATIENT DATA. The proper calling order for these agreements is to first call
the API documented in this agreement to verify the data to save then call the
API documented in agreement #6165 to save the data that was verified.\n
This API is transactional in nature. If the subscriber needs to both update
existing data and add new data, then the subscriber needs to call this API
twice: once for the update and once for the add.", "", "WVRPCPT2", "2017/11/17"], ["6167", "READ ACCESS TO DD(409.68", "File", "1", "2015/03/02", "APPROVED", "Active", "Private", "", "
Scheduling requests read access to ^DD(409.68,.08,0).
This reference is in legacy code that is missing an ICR. It is retrieving the
external value for a code in OUTPATIENT ENCOUNTER (#409.68) file, ORIGINATING
PROCESS TYPE (#.08) field.", "", "", "2015/03/27"], ["6168", "READ ACCESS TO DD(404.52", "File", "1", "2015/03/02", "APPROVED", "Active", "Private", "", "
This is a onetime agreement via patch SD*5.3*603.
Scheduling requests read access to ^DD(404.52,.09,1,2,0). The post-install
routine, SD53P603, in SD*5.3*603 will delete the FTEXR trigger cross-reference
on the POSITION ASSIGNMENT HISTORY (#404.52) file, FTEE EQUIVALENT (#.09)
field. Access to the ^DD(404.52 global is required to verify the cross
reference is present and the correct number prior to deleting it.\n
Entry point in SD53P603: DELTRIGR ;Delete FTEE History trigger in
404.52
;
NEW SDERR
DO BMES^XPDUTL("Delete the FTEXR Trigger in 404.52/.09")
;
IF $DATA(^DD(404.52,.09,1,2,0)),^DD(404.52,.09,1,2,0)["FTEXR" DO
. DO DELIX^DDMOD(404.52,.09,2,"","SDERR")
. IF '$DATA(SDERR) DO
. . DO BMES^XPDUTL("The FTEXR trigger was deleted.")
. ELSE DO
. . DO BMES^XPDUTL("ERROR encountered deleting the trigger.")
ELSE DO
. DO BMES^XPDUTL("The FTEXR trigger does not exist - previously deleted.")
QUIT
;", "", "", "2015/03/27"], ["6169", "READ/WRITE ACCESS TO NEW PERSON FILE", "File", "KERNEL", "2015/03/03", "APPROVED", "Active", "Private", "200", "
This is a onetime agreement via patch SD*5.3*603.\n
Post install processing looks for users that have a secondary menu option of
SCMC PCMM GUI WORKSTATION (legacy PCMM broker menu) and changes it to SCMC
PCMMR WEB USER MENU (PCMM Web broker menu).\n
Scheduling (PCMM Web) requests read access to the NEW PERSON (#200) file to
$ORDER through the records, $ORDER through SECONDARY MENU OPTIONS (#200.03)
multiple, then FileMan API ($$GET1^DIQ) to interrogate the value of the
SECONDARY MENU OPTIONS (.01) field. If it resolves to SCMC PCMM GUI
WORKSTATION, then we request write access to change the value to SCMC PCMMR
WEB USER MENU using FileMan API FILE^DIE.", "", "", "2015/03/27"], ["6170", "READ ACCESS TO NEW PERSON DIVISION MULTIPLE", "File", "KERNEL", "2015/03/03", "", "Withdrawn", "Private", "200", "
Scheduling (PCMM Web) requests direct global read
access to the NEW PERSON (#200) file, DIVISION (#16) multiple to $ORDER
through a person's assigned Divisions.", "", "", ""], ["6171", "READ WRITE ACCESS TO WEB SERVER FILE", "File", "WEB SERVICES CLIENT", "2015/03/03", "APPROVED", "Retired", "Controlled Subscription", "18.12", "
This request is for a one time use in patch SD*5.3*603
post installation processing.\n
Scheduling (PCMM Web) requests read and write access to the WEB SERVER
(#18.12) file. The post-install routine checks if the server record exists,
then either creates or updates the record using either the UPDATE^DIE or
FILE^DIE FileMan API calls, respectively. In addition it adds an entry (if it
doesn't exist) to the AUTHORIZED WEB SERVICES (#100) multiple, WEB SERVICE
(#.01) field using the UPDATE^DIE FileMan API.\n
This processing is done programmatically to avoid having sites manually
configure HWSC using the Web Server Manager.\n
Revision History:
- 3/18/24, effective with Kernel patch XU*8*802 which was released to support
WEB SERVER, EXPIRATION DATE of ICR reflects JAN 7,2025.
- 8/21/24, effective with patch SD*5.3*884 the Scheduling application is
requesting a one-time use in the SD*5.3*884 patch post installation processing
to create 2 new entries in the WEB SERVER (#18.12) file. The post-install
routine SDES884P will add two entries to the WEB SERVER (#18.12) file using
UPDATE^DIE: 1. To connect SD VVS WEB SERVER TEST to the VVS system from
VistA Test accounts. 2. To connect SD VVS WEB SERVER to the VVS system
from VistA Production accounts.
This processing is done programmatically to avoid having sites manually
configure the VVS interface manually using the Web Server Manager.
GLOBAL REFERENCE:
^XOB(18.12,D0
.01 NAME 0;1 Write w/Fileman
.04 SERVER 0;4 Write w/Fileman
.06 STATUS 0;6 Write w/Fileman
.07 DEFAULT HTTP TIMEOUT 0;7 Write w/Fileman
3.01 SSL ENABLED 3;1 Write w/Fileman
3.02 SSL CONFIGURATION 3;2 Write w/Fileman
3.03 SSL PORT 3;3 Write w/Fileman
100 AUTHORIZED WEB SERVICES multiple 100;0
.01 WEB SERVICE 0;1 Write w/Fileman
.06 STATUS 0;6 Write w/Fileman", "", "", "2015/03/13"], ["6172", "WRITE ACCESS TO WEB SERVER LOOKUP KEY FILE", "File", "WEB SERVICES CLIENT", "2015/03/03", "APPROVED", "Active", "Private", "18.13", "
This request is for a one time use in patch SD*5.3*603
post installation processing.\n
Scheduling (PCMM Web) requests write access to the WEB SERVER LOOKUP KEY
(#18.13) file. The post-install routine creates the lookup key record using
the supported $$SKEYADD^XOBWLIB API, and then updates the 18.13 record,
ASSOCIATED WEB SERVER (#.03) field using the FILE^DIE FileMan API call.\n
This processing is done programmatically to avoid having sites manually
configure HWSC using the Web Server Manager.", "", "", "2015/03/13"], ["6173", "READ ACCESS TO THE WEB SERVICE FILE", "File", "WEB SERVICES CLIENT", "2015/03/03", "APPROVED", "Active", "Private", "18.02", "
This request is for a one time use in patch SD*5.3*603
post installation processing.\n
Scheduling (PCMM Web) requests read access to the WEB SERVICE (#18.02) file.
The post-install routine creates a WEB SERVICE record using the supported
REGREST^XOBWLIB API, then reads the WEB SERVICE file with the $$FIND1^DIC
FileMan API to get the IEN of the WEB SERVICE record. Then in further
processing (reference ICR-6171) updates the WEB SERVER (#18.12) file,
AUTHORIZED WEB SERVICES (#100) multiple.\n
This processing is done programmatically to avoid having sites manually
configure HWSC using the Web Server Manager.", "", "", "2015/03/13"], ["6174", "OE/RR APIS", "Routine", "WOMEN'S HEALTH", "2015/03/05", "APPROVED", "Active", "Controlled Subscription", "", "
This integration control registration allows
subscribing packages to access pregnancy and lactation status data in a manner
suitable for the Computerized Patient Record System (CPRS).", "", "WVRPCOR", "2017/11/17"], ["6175", "PXRMRPCC PROMPTVL", "Remote Procedure", "CLINICAL REMINDERS", "2015/03/05", "", "Pending", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the PXRMRPCC PROMPTVL remote procedure call.", "PXRMRPCC PROMPTVL", "", ""], ["6176", "HLCS 870 B CROSS REFERENCE", "File", "HEALTH LEVEL SEVEN", "2015/03/06", "APPROVED", "Active", "Controlled Subscription", "870", "
VA POINT OF SERVICE (KIOSKS) uses the
^HLCS(870,"B",LINK,0) and ^HLCS(870,IEN,400) cross references to obtain the
internal entry number of the VPS HL Logical Link and the ports for message
transmission.", "", "", "2015/03/20"], ["6177", "HLO DEQUE", "Routine", "HEALTH LEVEL SEVEN", "2015/03/06", "", "Withdrawn", "Controlled Subscription", "", "", "", "HLOQUE", ""], ["6178", "READ ACCESS TO NEW PERSON FILE B CROSS REFERENCE", "File", "KERNEL", "2015/03/10", "", "Withdrawn", "Private", "200", "
Scheduling (PCMM) requests read access to the B cross
reference of the NEW PERSON (#200) file. The code in question will $ORDER
through the cross reference looking for a name match to a passed parameter.", "", "", ""], ["6179", "VPS PAT PROVIDER AND ATTENDING", "File", "REGISTRATION", "2015/03/10", "", "Withdrawn", "Controlled Subscription", "2", "", "", "", ""], ["6180", "ORWCV LAB", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/03/10", "", "Withdrawn", "Controlled Subscription", "", "", "ORWCV LAB", "", ""], ["6181", "$$FIND API in SDAM2", "Routine", "SCHEDULING", "2015/03/18", "", "Withdrawn", "Private", "", "
To support delivery of the Insurance Verification
Processor (IVP) project, which is part of Integrated Billing application,
access to the API $$FIND^SDAM2() is requested in order to find all the
appointments for a patient on a given date.\n
The input data will be 3 required data elements as follows: the patient's DFN,
date/time of the appointment (FileMan format), and the clinic's internal entry
number (IEN). The data of the input will be determined by the IVP software
based on the IVP Daily Appointment Worklist information. This API is called
by IVP code to get IEN of the sub file (#44.003), which is required to call
SDAMEVT APIs and to update the appointment entry properly.\n
Data input: 3 variables defined as follows: DFN - Patient's IEN from PATIENT
file (#2) SDT - Date/Time for the appointment in the File Man format SDCL -
clinic IEN from the HOSPITAL LOCATION FILE (#44)\n
Data output ($$FIND return value): If 0, no appointment was found and the
patient is notified. If > 0, then applicable appointment for that day is
passed back as IEN of the sub file (#44.003) of the sub file (#44.001) of the
file (#44).", "", "SDAM2", ""], ["6182", "Update fields (#309) and (#302) in file #44", "File", "SCHEDULING", "2015/03/18", "", "Withdrawn", "Private", "44", "
To support delivery of the Insurance Verification
Processor (IVP) project, which is part of Integrated Billing application,
access to the fields (#309) and (#302) in the file #44 is requested in order
to check-in the patient for a given appointment. Both fields (#309)
CHECKED-IN and (#302) CHECK IN USER of the file (#44) will be updated by the
FileMan call, which is made by IVP RPC "IBVP CHECKIN APPOINTMENT " at the
time when IVP user check in the patient in IVP web application.", "", "", ""], ["6183", "SDAMEVT APIs", "Routine", "SCHEDULING", "2015/03/18", "", "Withdrawn", "Private", "", "
The APIs will are used by IB to check-in the patient
from the Insurance Verification Processor's GUI interface via IB RPC "IBVP
CHECKIN APPOINTMENT " call. The IB RPC will use HDLKILL^SDAMEVT,
BEFORE^SDAMEVT, HANDLE^SDAMEVT, AFTER^SDAMEVT, and EVT^SDAMEVT APIs to ensure
that all other processes requiring notification of the check-in activity are
notified.", "", "SDAMEVT", ""], ["6184", "'AG' Cross reference in Request/Consultation file", "File", "CONSULT/REQUEST TRACKING", "2015/03/30", "APPROVED", "Active", "Private", "123", "
This cross reference contains entries of the
REQUEST/CONSULTATION file sorted by DATE OF REQUEST that do not have an
appointment scheduled.", "", "", "2015/12/08"], ["6185", "ACCESS DATA FROM REQUEST/CONSULTATION", "File", "CONSULT/REQUEST TRACKING", "2015/03/30", "APPROVED", "Active", "Private", "123", "
The VistA Scheduling Enhancement (VSE) requests
permission to access the REQUEST/CONSULTATION file 123 in order to obtain data
to be returned to the GUI. The "AD", "AG", "E", and "H" cross references will
be used for lookup. Note that the "AG" cross reference is added in
GMRC*3.0*83.", "", "", "2015/12/08"], ["6186", "Lookup REQUEST ACTION TYPES", "File", "CONSULT/REQUEST TRACKING", "2015/03/30", "APPROVED", "Active", "Private", "123.1", "
The VistA Scheduling Enhancement (VSE) requests
permission to access the REQUEST ACTION TYPES file 123.1 using the ^DIC
FileMan call in order to obtain internal IDs using a given REQUEST ACTION
TYPES name. These IDs will be used in searching the REQUEST/CONSULTATION file
for REQUEST PROCESSING ACTIVITY entries based on the ACTIVITY field (pointer
to REQUEST ACTION TYPES file). No field reads will be needed.", "", "", "2015/12/07"], ["6187", "Get ASSOCIATED STOP CODE list", "File", "CONSULT/REQUEST TRACKING", "2015/03/30", "", "Withdrawn", "Private", "123.5", "
The VistA Scheduling Enhancement (VSE) requests
permission to access the REQUEST SERVICES file 123.5 to obtain data from the
ASSOCIATED STOP CODE multiple field 688.", "", "", ""], ["6188", "Update/Add REQUEST PROCESSING ACTIVITY", "File", "CONSULT/REQUEST TRACKING", "2015/03/30", "", "Withdrawn", "Private", "123", "
The VistA Scheduling Enhancement (VSE) requests
permission to set (write implied here) data by adding an entry into the
REQUEST PROCESSING ACTIVITY multiple of the REQUEST/CONSULTATION file 123
using FileMan.", "", "", ""], ["6189", "XUSHSH Hashing and Encryption APIs", "Routine", "KERNEL", "2015/04/02", "APPROVED", "Active", "Supported", "", "
This DBIA describes supported references in the routine
XUSHSH which provides Kernel APIs for hashing, encoding/decoding, or
encryption/decryption of input of various formats.", "", "XUSHSH", "2015/08/18"], ["6190", "ORDER DIALOG 101.41", "File", "ORDER ENTRY/RESULTS REPORTING", "2015/04/05", "", "Withdrawn", "Controlled Subscription", "101.41", "
This IA provides for the read with Fileman of field 19,
ADDITIONAL TEXT, in the ORDER DIALOG file # 101.41.", "", "", ""], ["6191", "READ OR 100 FIELDS", "File", "ORDER ENTRY/RESULTS REPORTING", "2015/04/05", "", "Withdrawn", "Controlled Subscription", "100", "
This IA provides for the FileMan Read of ORDER FILE
#100 fields.", "", "", ""], ["6192", "MAG 2005 READ", "File", "IMAGING", "2015/04/17", "APPROVED", "Active", "Controlled Subscription", "2005", "
This ICR provides for the FileMan read of the
^MAG(2005, "ATRKID" index in the IMAGE FILE (#2005) and the PATIENT field #5
in the IMAGE FILE (#2005).\n
These fields provide the ability to associate an image to a patient when a
callback is execued by the Imaging Background Processor which passes only the
Tracking ID and Queue ID to the callback routine. Once the IEN of the image
entry in found using "ATRKID", the patient can be identified by reading fieled
# in ^MAG(2005,D0,0).", "", "", "2015/04/21"], ["6193", "LAB FILE 60 B X-REF", "File", "LAB SERVICE", "2015/04/17", "", "Withdrawn", "Controlled Subscription", "60", "
This ICR provides for the use of the "B"
cross-reference in LAB FILE (#60) to obtain the Lab information based on a Lab
Test Name.", "", "", ""], ["6194", "GMPLUTL2", "Routine", "PROBLEM LIST", "2015/05/07", "", "Withdrawn", "Private", "", "
During SQA of patch TIU*1.0*286 it was discovered that
routine TIUWRIIS contains a call to LIST^GMPLUTL2. There is no intergration
agreement for its use in TIU. This has existed in past patches and this
integration agreement request is an attempt to complete missing ICR
documentation\n", "", "TIUWRIIS", ""], ["6195", "60", "File", "LAB SERVICE", "2015/05/07", "", "Withdrawn", "Private", "60", "
During SQA for patch TIU*1.0*286 it was found that TIU
routine TIUWRIIS reads ^LAB(60 and no integration agreement exist. This read
has existed in past patches and this is an attempt to complete the missing ICR
documentation.\n", "", "", ""], ["6196", "DIA", "File", "1", "2015/05/19", "APPROVED", "Active", "Private", "1.1", "
DSS request a one-time agreement allowing a direct
global kill of the AUDIT file (#1.1) for 3 ECX related files in the
post-install routine in patch ECX*3.0*154. Details of this request are below.\n
The DSS extract software (ECX) audits certain fields in the PRESCRIPTION
EXTRACT file (#727.81), the UNIT DOSE LOCAL EXTRACT file (#727.809) and the IV
DETAIL EXTRACT file (#727.819) when they are edited using the Pharmacy Volume
Edit [ECX PHA VOL EDIT] option.\n
The auditing of the specified fields was to be turned on and off using this
option. However, a bug in the software caused the auditing to never be turned
off so when the monthly extract files were built, an audit log entry was
created for every entry in the extract file.\n
In order to make this option, and its associated information useful, DSS is
requesting permission to delete the entire audit log for files 727.81,
727.809, and 727.819. This would be done by killing the entire audit log for
each file via a direct global kill of ^DIA(File #).", "", "", "2015/06/11"], ["6197", "MOST RECENT PREGNANT STATE", "Routine", "WOMEN'S HEALTH", "2015/05/22", "APPROVED", "Active", "Private", "71", "
This integration agreement allows the subscribing
package to retrieve a detailed display of a patient's most recent instance of
a pregnant state.", "", "WVRPCPT1", "2017/11/17"], ["6198", "STATUS REVIEW NOTIFICATION TEXT", "Routine", "WOMEN'S HEALTH", "2015/05/26", "", "Pending", "Private", "", "
This integration agreement allows the subscribing
package to retrieve the event that generated a status review notification in a
user friendly format. This text is displayed when the user processes the
notification within the Computerized Patient Record System (CPRS) GUI.", "", "WVRPCPT1", ""], ["6199", "HIGH RISK MEDICATIONS FOR FEMALE PATIENTS", "Routine", "CLINICAL REMINDERS", "2015/05/26", "", "Withdrawn", "Private", "", "
This integration agreement will allow the subscriber to
determine which pharmacy orders are considered teratogenic or unsafe for a
specific female patient.", "", "PXRMCWH1", ""], ["6200", "PATIENT'S HEALTHCARE MANAGERS", "Routine", "WOMEN'S HEALTH", "2015/05/27", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to determine the healthcare managers for a patient.", "", "WVRPCPT1", "2017/11/17"], ["6201", "DBIA 6201", "File", "PCE PATIENT CARE ENCOUNTER", "2015/05/29", "APPROVED", "Active", "Private", "9999999.14", "
The Health Summary Package desires to set up an
integration agreement with the PCE Package to point to the Immunizations
(#9999999.14) file. The Selection Item (.01) field in the Structure Multiple
(field 1) of the Health Summary Type (#142) file points to the Immunizations
file. The Selection File (.01) field in the Selection File multiple (field 7)
of the Health Summary Component (#142.1) file points to the Immunizations
file. Health Summary also requires the ability to add the application group
"GMTS" ^DIC(9999999.14) when the Health Factors files exists. This is done
with a Fileman Call.", "", "", "2015/09/08"], ["6202", "MAIL GROUP MEMBER", "File", "MAILMAN", "2015/06/04", "APPROVED", "Active", "Private", "3.8", "
The PTF module of the REGISTRATION package requests
permission to read the MEMBER multiple (#2) of the MAIL GROUP (#3.8) file for
patch DG*5.3*884. This is a one-time use to populate the new PTI mail group
with the same MEMBERS as the existing PTT mail group. This will save the IRMS
staff from having to manually enter the information and save possible data
entry errors.\n
Also, we request permission to read the B cross-reference this one time in
order to find the existing PTT mail group.", "", "", "2015/06/22"], ["6203", "Delete the 'RDE' cross reference and the data (70.03 ; 1.1)", "Routine", "1", "2015/06/15", "APPROVED", "Active", "Private", "", "", "", "", "2015/06/22"], ["6204", "DRG FILE ENTRY COUNTS", "File", "DRG GROUPER", "2015/06/17", "APPROVED", "Active", "Private", "", "
The Registration package requests permission to loop
through and count the number of entries in the following DRG files:\n
File Name Global
---- ---- ------
80.5 DRG SURGICAL HIERARCHY ^ICDRS
80.6 DRG HAC ^ICDHAC
82 DRG DIAGNOSIS INDENTIFIER CODES ^ICDID
82.1 DRG PROCEDURE IDENTIFIER CODES ^ICDIP
82.11 DRG PROCEDURE CODE COMBINATIONS ^ICDIDP
82.12 DRG DIAGNOSIS CODE COMBINATIONS ^ICDIDD
82.13 DRG CC EXCLUSIONS ^ICDCCEX\n
This is a one-time request for Registration patch DG*5.3*884. It is important
that these DRG files are correctly populated so the new functionality
introduced in DG*5.3*884 will work properly. The environment check routine
will check these file counts and display a message to the patch installer if
there is any discrepancy. The installer will be instructed to log a Remedy
ticket. Also, a MailMan message will be sent to a customer support group as an
added precaution.", "", "", "2015/07/30"], ["6205", "ORWTPP DELLIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/06/19", "", "Pending", "Controlled Subscription", "", "
This RPC deletes an entry in the OE/RR LIST file
(#100.21). Its only parameter is the Internal Entry Number (IEN) of the list,
and it returns a Boolean result (1=Yes if successful, or 0=No otherwise).\n
NOTE: Authorization is enforced. A user may only delete lists which they own
(i.e., they must be identified as a USER of the list, AND the list must be of
type PERSONAL). Users are identified by the individual DUZ. Application
Proxies are forbidden.", "ORWTPP DELLIST", "", ""], ["6206", "ORWTPP SAVELIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/06/19", "", "Pending", "Controlled Subscription", "", "
This RPC updates an entry in the OE/RR LIST file
(#100.21). Parameters include the patients to be included in the list (passed
as an ARRAY of DFNs), the Internal Entry Number (IEN) of the list, and the
Visibility of the list (i.e., 0=OWNER ONLY (private) or 1=ALL CPRS USERS
(public)). It returns a Boolean result (1=Yes if successful, or 0=No
otherwise).\n
NOTE: Authorization is enforced. A user may only delete lists which they own
(i.e., they must be identified as a USER of the list, AND the list must be of
type PERSONAL). Users are identified by the individual DUZ. Application
Proxies are forbidden.", "ORWTPP SAVELIST", "", ""], ["6207", "ABBVAL GMVUTL", "Routine", "GEN. MED. REC. - VITALS", "2015/07/13", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR authorizes access to the ABBVAL function in
GMVUTL7 to retrieve the high and low measurements of a vital type.", "", "GMVUTL7", "2015/07/27"], ["6208", "DB6208", "File", "INTEGRATED BILLING", "2015/07/14", "APPROVED", "Active", "Private", "364", "
The Accounts Receivable (AR) application needs to
extract EDI transmission data from the EDI TRANSMIT BILL file (#364). This is
a read-only action and does not modify any fields in the file.", "", "", "2015/08/06"], ["6209", "DB6209", "File", "INTEGRATED BILLING", "2015/07/14", "APPROVED", "Active", "Private", "364.1", "
The Accounts Receivable (AR) application needs to
extract the EDI transmission batch data from the EDI TRANSMISSION BATCH file
(#364.1). This is a read-only action and does not modify any fields in the
file.", "", "", "2015/08/06"], ["6210", "CLINICAL REMINDERS INDEX REBUILD", "Routine", "CLINICAL REMINDERS", "2015/07/14", "APPROVED", "Active", "Controlled Subscription", "", "
BLDINDEX^PXRMSXRM provides an API that subscribing
packages can use to rebuild their portion of the Clinical Reminders Index.\n", "", "PXRMSXRM", "2015/11/19"], ["6211", "CALLS TO TIUCOP", "Routine", "TEXT INTEGRATION UTILITIES", "2015/07/31", "", "Pending", "Controlled Subscription", "", "
This DBIA documents calls to routine TIUCOP, which are
used to implement Copy/Paste tracking functionality.", "", "TIUCOP", ""], ["6212", "ZTMGRSET", "Routine", "KERNEL", "2015/08/12", "APPROVED", "Active", "Private", "", "\n
VA FileMan request use of MOVE^ZTMGRSET to rename the following routines:
DIDT renamed to %DT
DIDTC renamed to %DTC
DIRCR renamed to %RCR\n
This is needed during the install of any new version of VA FileMan.
It will be called in the post install routine.\n\n", "", "ZTMGRSET", "2015/09/24"], ["6213", "INPATIENT VADPT30", "Routine", "REGISTRATION", "2015/08/17", "", "Withdrawn", "Controlled Subscription", "", "
This ICR provides for the use of VADPT30 to read a
patient's inpatient demographic variables. The data returned by the routine
includes: ward, treating specialty, room/bed assignment, attending physician,
diagnosis, IEN of the movement entry, and the patient's response to the
facility directory question.\n
All input parameters are set into the input variables DFN, VAPRC, VAPRT, VATD,
VAWD, VATS, VARM, VAPP, VAMV, VAFD prior to calling VAR^VADPT30. No input
parameters are passed to this routine.", "", "VADPT30", ""], ["6214", "ECME COMMENTS", "Routine", "E CLAIMS MGMT ENGINE", "2015/08/19", "APPROVED", "Active", "Controlled Subscription", "", "
This API retrieves comments from the BPS Transaction
file in ECME and builds an array of comments for the subscribing packages.", "", "BPSSCRU3", "2016/01/25"], ["6215", "ORWEBPS CLINPTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/06/19", "", "Pending", "Controlled Subscription", "", "
This RPC returns a an ARRAY of patients with
appointments scheduled for a given Clinic, identified by its internal entry
number in the HOSPITAL LOCATION file (#44), within a specified date range. The
0-node of the array includes the attributes of the clinic. Each subsequent
node contains attributes of a patient, as specified below:\n
RESULT(0)="CLINIC IEN^CLINIC NAME^LIST TYPE^COUNT^VISIBILITY"
RESULT(1...n)="DFN^SSN^DOB^SEX^VET?^SC%^WARD^RMBD^NAME^AGE^ICN"", "", "", ""], ["6216", "ORWEBPS GETCDRNG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC returns the user's list of preferred date
ranges for clinic appointment search, as well as their default date range.\n
The return array from this RPC will look like this:\n
RESULT(0)="T^T"
RESULT(1)="T;T^Today"
RESULT(2)="T+1;T+1^Tomorrow"
RESULT(3)="T-1;T-1^Yesterday"
RESULT(4)="T-7;T^Past Week"
RESULT(5)="T-31;T^Past Month"
RESULT(6)="S^Specify Date Range..."\n
Where the 0th element of the array is the user's default range, and the
subsequent elements are the remaining choices to be presented for list
retrieval.", "", "", ""], ["6217", "ORWEBPS GETLIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC returns a CPRS Patient List as an ARRAY,
identified by its internal entry number in the OE/RR LIST file (#100.21), as
described below. An optional second parameter allows the calling application
to specify a start value for filtering the results in a manner compatible with
CPRS (e.g., name (or partial name), SSN, Last Initial/Last 4, etc.).\n
The 0-node of the return array includes the attributes of the list. Each
subsequent node contains attributes of a patient, as specified below:\n
RESULT(0)="LIST IEN^LIST NAME^LIST TYPE^COUNT^VISIBILITY"
RESULT(1...n)="DFN^SSN^DOB^SEX^VET?^SC%^WARD^RMBD^NAME^AGE^ICN"", "", "", ""], ["6218", "ORWEBPS MYLISTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC returns the user's default Patient List
source, as well as the user's Personal Patient Lists.\n
The return array includes the user's default list (if specified) in the
zero-node, along with the user's Personal Lists. The following data elements
are returned:\n
RESULT(0)=DFLT LIST IEN^DFLT LIST NAME^TYPE^COUNT^VISIBILITY"
RESULT(1..n)=IEN^NAME^TYPE^UPPER CASE^DEVICE^CREATOR^ SUBSCRIBE^CREATE D/T\n
Note: this comprises the list of OE/RR Lists that the user owns, and is
authorized to change or delete.", "", "", ""], ["6219", "ORWEBPS TEAMPERS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC returns the list of all Team and Personal
lists which are visible to the user in question.\n
An optional parameter allows the calling application to pass the user ID (DUZ)
of the user in question. If no value is provided, the DUZ from the VistA
session will be assumed.\n
The return array includes of all Team and Personal Lists which are visible to
the user. The following data elements are returned:\n
RESULT(n)=IEN^NAME^TYPE^UPPER CASE^DEVICE^CREATOR^SUBSCRIBE^CREATION D/T\n
Note: this does NOT comprise the list of OE/RR Lists that the user may modify,
but the lists that user may read.", "", "", ""], ["6220", "ORWEBPS WARDPTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC returns a an ARRAY of patients admitted a
given Ward, identified by its internal entry number in the WARD LOCATION file
(#42), within a specified date range.\n
The 0-node of the return array includes the attributes of the ward. Each
subsequent node contains attributes of a patient, as specified below:\n
RESULT(0)="WARD IEN^WARD NAME^LIST TYPE^COUNT^VISIBILITY"
RESULT(1...n)="DFN^SSN^DOB^SEX^VET?^SC%^WARD^RMBD^NAME^AGE^ICN"", "", "", ""], ["6221", "ORWEBUSR USERINFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC wraps the call to ORWU USERINFO and returns
the SITE NAME and INTEGRATION NAME for the VistA instance to which the user is
connected, in addition to the attributes described for ORWU USERINFO.\n
The following '^'-delimited string is returned:\n
DUZ^NAME^USRCLS^CANSIGN^ISPROVIDER^ORDERROLE^NOORDER^DTIME^
COUNTDOWN^ENABLEVERIFY^NOTIFYAPPS^MSGHANG^DOMAIN^SERVICE^
AUTOSAVE^INITTAB^LASTTAB^WEBACCESS^ALLOWHOLD^ISRPL^RPLLIST^
CORTABS^RPTTAB^STANUM^GECSTATUS^PRODACC^SITENAME^INTEGNM", "", "", ""], ["6222", "ORWEBPS LISTALL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC returns a list of Patients from the current
VistA instance as an ARRAY, sorted alphabetically by name, as described below.
An optional parameter allows the calling application to specify a start value
for filtering the results in a manner compatible with CPRS (e.g., name (or
partial name), SSN, Last Initial/Last 4, etc.). Omitting this parameter will
cause the fetch to begin with the first entry (alphabetically by name) in the
PATIENT File (#2). A second optional parameter allows the calling application
to specify the direction of the search from the start value (i.e., default or
1 -> forward; -1 -> backward).\n
The 0-node of the return array includes the attributes of the list. Each
subsequent node contains attributes of a patient, as specified below:\n
RESULT(0)="-1^All Patients^All^COUNT^VISIBILITY"
RESULT(1...n)="DFN^SSN^DOB^SEX^VET?^SC%^WARD^RMBD^NAME^AGE^ICN"", "", "", ""], ["6223", "ORWTPP NEWLIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/08/21", "", "Pending", "Controlled Subscription", "", "
This RPC creates a Personal List entry in the OE/RR
LIST file (#100.21). Parameters include the List Name, User ID (DUZ), and
Visibility (1: All CPRS Users, 0: Self Only).\n
The return value is a string literal.\n
If the call fails, the result will be a two "^"-piece string, where the first
piece is empty and the second piece is a brief explanation of the failure
(e.g., "^invalid list name - duplicate of another name").\n
If the call succeeds, the result will have the format:\n
IEN_U_LISTNAME_"^^^^^^^"_VISIBILITY", "ORWTPP NEWLIST", "", ""], ["6224", "UCUM CODES FILE", "File", "LEXICON UTILITY", "2015/08/26", "APPROVED", "Active", "Controlled Subscription", "757.5", "", "", "", "2015/09/02"], ["6225", "UCUM CODES APIs", "Routine", "LEXICON UTILITY", "2015/08/26", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR works in conjunction with ICR #6224 to allow
packages to use UCUM Codes for storing measurements.\n", "", "LEXMUCUM", "2015/09/02"], ["6226", "Pull Data from BPS Response File", "Routine", "E CLAIMS MGMT ENGINE", "2015/09/03", "APPROVED", "Active", "Controlled Subscription", "", "
This API pulls data from the BPS Response file in ECME.\n", "", "BPSOS03", "2016/01/25"], ["6227", "OUTPATIENT PHARMACY REJECT COMMENTS", "Routine", "OUTPATIENT PHARMACY", "2015/09/11", "APPROVED", "Active", "Private", "", "
This is an API to allow the Pharmacist comments entered
and stored in Outpatient Pharmacy to be shared with the subscribing package.
These are pharmacist comments pertaining to ePharmacy rejections received and
the pharmacist comments about those rejections.", "", "PSOREJU4", "2016/02/12"], ["6228", "MEDICATION PROFILE/PATIENT INFORMATION LIST MANAGER", "Routine", "OUTPATIENT PHARMACY", "2015/09/14", "APPROVED", "Active", "Private", "", "
This is an Integration Agreement between Outpatient
Pharmacy and ECME. The Chief Business Office eBusiness Solutions ePharmacy
team requests the ability for the Outpatient Pharmacy Electronic Claims
Coordinator (OPECC) using the ECME User Screen to be able to view both the
Outpatient Pharmacy Medication Profile List Manager screen and the Outpatient
Pharmacy Patient Information List Manager screen. This agreement allows ECME
to call these PSO API entry points to display these List Manager screens.", "", "PSOREJU4", "2016/02/12"], ["6229", "PSSUTIL1", "Routine", "PHARMACY DATA MANAGEMENT", "2015/09/16", "APPROVED", "Active", "Private", "", "
This agreement allows the Outpatient Pharmacy
application to invoke APIs in the PSSUTIL1 routine related to the dispensing
of Outpatient Pharmacy prescriptions.", "", "PSSUTIL1", "2015/10/26"], ["6230", "VACAA BULK-LOAD NON-VA PROVIDER INFORMATION", "Routine", "KERNEL", "2015/09/28", "APPROVED", "Active", "Private", "", "
Bulk-load non-VA entities and providers to be
identified in VistA when documenting patient care.\n
On August 7, 2014, the President signed into law PL 113-146, the Veterans
Access, Choice, and Accountability Act of 2014 (VACAA). The law offers an
additional authority for VHA to expand current capacity and ensure that
Veterans have timely access to high-quality care. The law creates a new
paradigm for providing health care, set forth in the Veterans Choice program
provisions within Title I Section 101 of VACAA. VA is utilizing a Contractor
to provide health care and third party administrative (TPA) services set forth
through VACAA Section 101. As a result of this law, VA must upload a list of
non-VA medical care providers into the VistA system in order to maintain an
accurate and updated list of non-VA providers in the Choice program.\n
This interface is available under a private Integration Agreement for support
of VACAA only, and should not be used under any other circumstances.", "", "XUESSO4", "2016/08/29"], ["6231", "Date of Death Triggers Insurance Termination", "Routine", "INTEGRATED BILLING", "2015/09/29", "APPROVED", "Active", "Controlled Subscription", "", "
A new style MUMPS cross reference is added to DATE OF
DEATH field (#.351) in the Patient (#2) file which is invoked when the DATE OF
DEATH is populated and has not previously been entered. The set code of this
cross reference calls DEATH^IBCNEUT7. This IB code terms all of the patient's
active insurance policies (without an expiration date). The term date is to be
set to date of death. This functionality does not trump any existing or
future validation/rules for the actual date of death. The patient insurance
policies are stored in the INSURANCE TYPE (#2.312) subfile in the Patient (#2)
file.", "", "IBCNEUT7", "2016/01/08"], ["6232", "APPT MULTIPLE 2.98 READ/WRITE", "File", "SCHEDULING", "2015/09/29", "", "Withdrawn", "Controlled Subscription", "2.98", "
VA Point of Service (Kiosks) (VPS) allows Veterans to
Make and Cancel clinic appointments using the VetLink Kiosk. This ICR provides
read/write access to the APPOINTMENT SUB-FILE #2.98 defined in the PATIENT
file (2). The sub-file contains patient appointment data such as clinic,
appointment date/time and reason for the appointment to be captured.\n", "", "", ""], ["6233", "READ/WRITE TO HOSPITAL LOCATION file (#44)", "File", "SCHEDULING", "2015/09/29", "", "Withdrawn", "Controlled Subscription", "44", "
VA Point of Service (Kiosks) (VPS) allows Veterans to
Make and Cancel clinic appointments using the VetLink Kiosk. This ICR provides
read/write access to the subfiles 44.001, 44.003, and 44.005 of the HOSPITAL
LOCATION file (#44).\n", "", "", ""], ["6234", "IPAC VENDOR AGREEMENT FILE", "File", "FEE BASIS", "2015/09/30", "APPROVED", "Active", "Private", "161.95", "
Fee Basis Claims System needs the ability to read the
records found within the file to display to clerks for proper payment of
claims identified as IPAC. All fields are displayed to the user for proper
identifaction.", "", "", "2015/09/30"], ["6235", "IPAC VENDOR AGREEMENT MRA FILE", "File", "FEE BASIS", "2015/09/30", "APPROVED", "Active", "Private", "161.96", "
Fee Basis Claims System needs the ability to check
whether pending IPAC MRAs are ready for trasmission to Austin (Central Fee) by
using the AS cross reference.", "", "", "2015/09/30"], ["6236", "FBAAV8", "Routine", "FEE BASIS", "2015/09/30", "", "Retired", "Private", "", "
During the Transmit to Austin functionality, FBCS needs
the ability to trigger the sending of the IPAC MRA messages along with the
other MRAs and batches sent during this process. FBCS will call FBAAV8 to
trigger the creation of the messages (MailMan) if there are pending MRAs in
the IPAC VENDOR AGREEMENT IPAC FILE (#161.96) AS cross reference.", "", "FBAAV8", "2015/09/30"], ["6237", "ALLOW IB ACCESS TO AR EDI RARC DATA", "File", "ACCOUNTS RECEIVABLE", "2015/09/30", "APPROVED", "Active", "Private", "346", "
This integration agreement allows Integrated Billing
(IB) to have read access to the code (.01) and description (#4) field of AR
file #346 - AR EDI RARC DATA. This is a read-only action and does not modify
any fields in the file.", "", "", "2015/12/31"], ["6238", "IB ACCESS TO AR EDI CARC DATA", "File", "ACCOUNTS RECEIVABLE", "2015/09/30", "APPROVED", "Active", "Private", "345", "
This integration agreement allows Integrated Billing
(IB) to have read access to the code (.01) and description (#4) field of AR
file #345 - AR EDI CARC DATA. This is a read-only action and does not modify
any fields in the file.", "", "", "2015/12/31"], ["6239", "RETRIEVE PATIENT'S DATA FOR FINDINGS", "Routine", "WOMEN'S HEALTH", "2015/10/01", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to retrieve a sub-set of a patient's data from the Women's Health package in a
format that is easily convertible into Clinical Reminders general findings.", "", "WVRPCPT1", "2017/11/17"], ["6240", "GIVE THIS DBIA A BETTER NAME THAN DBIA6240", "", "", "2015/10/06", "", "Pending", "", "", "", "", "", ""], ["6241", "GIVE THIS DBIA A BETTER NAME THAN DBIA6241", "", "", "2015/10/06", "", "Pending", "", "", "", "", "", ""], ["6242", "GIVE THIS DBIA A BETTER NAME THAN DBIA6242", "", "", "2015/10/06", "", "Pending", "", "", "", "", "", ""], ["6243", "EPHARMACY BILLABLE STATUS", "Routine", "INTEGRATED BILLING", "2015/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This function returns the ePharmacy Billable status to
subscribing packages. The subscribing application shall pass in the
PRESCRIPTION File #52 IEN and the BILLING ELIGIBILITY INDICATOR: TRICARE(T),
CHAMPVA(C), or VETERAN(V) field of PRESCRIPTION file to make this
determination.", "", "IBNCPDP", "2016/02/01"], ["6244", "RETRIEVE SENSITIVE DIAGNOSIS DRUG FROM DRUG FILE", "Routine", "INTEGRATED BILLING", "2015/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This function returns the SENSITIVE DIAGNOSIS DRUG
Field #87 from the DRUG File (#50) "EPH" node to subscribing packages.", "", "IBNCPDR", "2016/02/01"], ["6245", "RETURN EBILLABLE & SENSITIVE DIAGNOSIS DRUG FLDS", "Routine", "PHARMACY DATA MANAGEMENT", "2015/10/06", "APPROVED", "Active", "Controlled Subscription", "", "
This function returns the EPHARMACY BILLABLE, EPHARMACY
BILLABLE (TRICARE), EPHARMACY BILLABLE (CHAMPVA) and SENSITIVE DIAGNOSIS DRUG
fields from the DRUG File (#50) "EPH" node to subscribing packages.", "", "PSS50", "2016/02/12"], ["6246", "PXVIMM INFO SOURCE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2015/10/07", "APPROVED", "Retired", "Controlled Subscription", "", "\n
*******************************************************************\n
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.\n
*******************************************************************\n\n
Returns entries from the IMMUNIZATION INFO SOURCE file (920.1). INPUT
PARAMETER: PXVFLTR PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 1
DESCRIPTION:
Filter. Possible values are:
R:XXX - Return entry with IEN XXX.
H:XXX - Return entry with HL7 Code XXX.
N:XXX - Return entry with #.01 field equal to XXX
S:X - Return all entries with a status of X.
Possible values of X:
A - Active Entries
I - Inactive Entries
B - Both active and inactive entries\n
Defaults to "S:B". INPUT PARAMETER: PXVDATE PARAMETER TYPE:
LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION: Used for determining status (both for filtering and for return
value).
Defaults to NOW.
RETURN PARAMETER DESCRIPTION:
Returns:
PXVRSLT(0)=Count of elements returned (0 if nothing found)
PXVRSLT(n)=IEN^Name^HL7 Code^Status (1:Active, 0:Inactive)\n
When filtering based off IEN, HL7 Code, or #.01 field, only one entry will
be returned in PXVRSLT(1).\n
When filtering based off status, multiple entries can be returned. The
first entry will be returned in subscript 1, and subscripts will be
incremented by 1 for further entries. Entries will be sorted
alphabetically.\n
If no entries are found based off the filtering criteria, PXVRSLT(0) will
equal 0, and there will be no data returned in the subsequent subscripts.", "PXVIMM INFO SOURCE", "", "2017/10/18"], ["6247", "Direct KMPV read to KMPTMP", "File", "CAPACITY MANAGEMENT TOOLS", "2015/10/08", "APPROVED", "Active", "Private", "", "
Allows VistA System Monitor (VSM) to read and write
data directly to temporary global ^KMPTMP("KMPV".\n
^KMPTMP has no file number. This is a temporary global specific to the
Capacity Planning packages (RUM-KMPR, SAGG-KMPS, CM Tools-KMPD and VSM-KMPV).
The data is gathered during the collection periods and stored in this global.
Daily there are TaskMan jobs that put this global in FileMan files and purge
the temporary global.", "", "", "2015/11/18"], ["6248", "Validation messages to Resubmit or Reverse a claim", "Routine", "E CLAIMS MGMT ENGINE", "2015/10/15", "APPROVED", "Active", "Controlled Subscription", "", "
This API does validation checks before resubmitting or
reversing an ECME claim.", "", "BPSPSOU1", "2016/01/25"], ["6249", "GIVE THIS DBIA A BETTER NAME THAN DBIA6249", "", "", "2015/10/15", "", "Pending", "", "", "", "", "", ""], ["6250", "e-Pharmacy HL7 Processing", "Routine", "INTEGRATED BILLING", "2015/10/15", "APPROVED", "Active", "Controlled Subscription", "", "
ECME (Electronic Claims Management Engine) is the
initial receiving point for incoming HL7 messages from FSC (Financial Services
Center). When the system detects that an inbound MFN (Master File
Notification) message is intended to update the IB (Integrated Billing) files
of e-Pharmacy, then ECME makes the following calls into the IB processing
routines to accomplish the task.", "", "IBCNRHLU", "2016/02/01"], ["6251", "ACTLOC~ORWU", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/10/21", "APPROVED", "Retired", "Private", "", "
The Enterprise Health Management Platform (HMP) uses
the $$ACTLOC^ORWU API in order to determine if a specified hospital location
in the Hospital Location file (#44) is an active location.\n
Returns 1 is the location is active, otherwise returns 0 (zero).\n
**NOTE: HMP is the only package that will be granted this level of access. **\n\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORWU", "2016/03/10"], ["6252", "GMRAPENC", "Routine", "ADVERSE REACTION TRACKING", "2015/10/21", "", "Withdrawn", "Controlled Subscription", "", "
HMP calls the CLP2CLDA^GMRAPENC API to return the drug
class code and drug class classification for a specific drug.", "", "GMRAPENC", ""], ["6253", "PXVIMM ADMIN ROUTE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2015/10/21", "", "Withdrawn", "Controlled Subscription", "", "
Returns entries from the IMM ADMINISTRATION ROUTE file
(920.2).", "", "", ""], ["6254", "LEXXFRM~ORQQPL4", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/10/26", "APPROVED", "Retired", "Controlled Subscription", "", "
HMP calls LEXXFRM^ORQQPL4 from PROB^HMPEF to transform
text for the SCT look-up.\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORQQPL4", "2015/11/13"], ["6255", "$$OUTTYPE~GMRAUTL", "Routine", "ADVERSE REACTION TRACKING", "2015/10/26", "", "Withdrawn", "Controlled Subscription", "", "
HMP calls the $$OUTTYPE^GMRAUTL API to transform the
internal for the Allergy Type field (#3.1) in the Patient Allergies file
(#120.8) or the Allergy Type field (#1) in the GMR Allergies file (#120.82) to
the external value.", "", "GMRAUTL", ""], ["6256", "DELETE SCREEN NODES", "File", "1", "2015/10/29", "APPROVED", "Active", "Private", "", "
There is a bug in FileMan that is not deleting the
screen nodes (12 and 12.1) out of the DD global when a DD update is sent out
via KIDS. The PCE team is therefore requesting a one-time direct delete access
to the following nodes:\n
^DD(9000010.11,.01,12)\n
^DD(9000010.11,.01,12.1)\n
This will be used in the PX*1*210 Post-Install Routine PXVP210.", "", "", "2015/11/04"], ["6257", "GMRC READ OF OR(100 GLOBAL", "File", "ORDER ENTRY/RESULTS REPORTING", "2015/11/03", "APPROVED", "Retired", "Private", "100", "
This ICR is temporary and only applicable to
GMRC*3.0*85. It will be retired when the patch has been nationally released
and the compliance window and warranty periods have elapsed.\n
For emergency patch GMRC*3.0*85, GMRC needs to access and read the ^OR(100
global. This patch has an emergent need to quickly search the ORDER file
(#100) global in order to find consult/procedure orders that have been
rejected with a very specific message of "Code not valid for Coding System".\n
This search output will assist sites with identifying and ensuring that all
Veterans who may have had consult orders rejected by a known GMRC defect have
had a replacement order entered into the system.", "", "", "2015/11/04"], ["6258", "LOAD PXRMDLL", "Routine", "CLINICAL REMINDERS", "2015/11/05", "", "Withdrawn", "Controlled Subscription", "", "
PXRMDLL provides the capability to load/retrieve
clinical reminder dialog questions into an array.", "", "PXRMDLL", ""], ["6259", "811.9 READ LINKED REMINDER", "File", "CLINICAL REMINDERS", "2015/11/05", "APPROVED", "Active", "Controlled Subscription", "811.9", "", "", "", "2015/12/02"], ["6260", "801.41 READ", "File", "CLINICAL REMINDERS", "2015/11/05", "", "Withdrawn", "Controlled Subscription", "801.41", "", "", "", ""], ["6261", "DEFSORT~ORQPTQ11", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/11/05", "APPROVED", "Retired", "Private", "", "
The HMP package is using the DEFSORT^ORQPTQ11 API to
the default patient list for the user that is logged on.\n
**NOTE: HMP is the only package that will be granted this level of access. **\n\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORQPTQ11", "2016/03/10"], ["6262", "WVRPCOR CONSAVE", "Remote Procedure", "WOMEN'S HEALTH", "2015/11/05", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR CONSAVE remote procedure.", "WVRPCOR CONSAVE", "", "2017/11/17"], ["6263", "CPRS UTILITIES", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/11/06", "APPROVED", "Active", "Controlled Subscription", "", "
This integration control registration allows
subscribing packages to access internal utility functions within the Order
Entry/Results Reporting package.", "", "ORUTL", "2017/11/14"], ["6264", "VPS WRITE TO 9000010", "File", "PCE PATIENT CARE ENCOUNTER", "2015/11/09", "", "Withdrawn", "Controlled Subscription", "9000010", "
This IA provides for the Fileman Write of the TYPE
(.03), PATIENT NAME (.05) and SERVICE CATEGORY (.07) fields in the VISIT FILE
#9000010.", "", "", ""], ["6265", "Lexicon Expression Extracts", "Routine", "LEXICON UTILITY", "2015/11/16", "APPROVED", "Active", "Supported", "", "
Effective upon release of patch LEX*2.0*103.\n", "", "LEXU", "2015/01/15"], ["6266", "Convert to Mixed Case", "Routine", "LEXICON UTILITY", "2015/11/17", "", "Pending", "Supported", "", "
Effective upon release of patch LEX*2.0*103.\n", "", "LEXXMC", ""], ["6267", "Lexicon Silent Lookup", "Routine", "LEXICON UTILITY", "2015/11/17", "", "Pending", "Supported", "", "
Effective upon release of patch LEX*2.0*103. Expands
upon LOOK^LEXA ICR 2950.\n", "", "LEXA", ""], ["6268", "COMBPTS~ORQPTQ6", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/11/18", "APPROVED", "Retired", "Private", "", "\n\n
The code returns a list of patients for clinic appointments based on input
parameters, the results are in ^TMP("OR",$J).\n
** NOTE: Access to this file for direct reads will only be granted to the HMP
project. **\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORQPTQ6", "2016/03/14"], ["6269", "IMTYPSEL~ORWDRA32", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2015/11/18", "APPROVED", "Retired", "Private", "", "
The code returns data from Radiology, a list of active
imaging types from the IMAGING TYPE file (#79.2). The list returned is
passed-by-reference to the calling routine.\n
** NOTE: Access to this file for direct reads will only be granted to the HMP
project. **\n\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORWDRA32", "2016/03/14"], ["6270", "RUN~PXRMLCR", "Routine", "CLINICAL REMINDERS", "2015/11/18", "", "Withdrawn", "Controlled Subscription", "", "
This is used to build a Patient List for Clinical
Reminders.\n
It is called internally in Clinical Reminders by the PXRM PATIENT LIST CREATE
protocol.", "", "PXRMLCR", ""], ["6271", "BCMA UTILITIES", "Routine", "BAR CODE MED ADMIN", "2015/11/19", "", "Active", "Controlled Subscription", "", "
Integration agreement to allow Inpatient Medications to
call BCMA Utilities.", "", "PSBUTL", "2018/03/22"], ["6272", "HMP USE OF ORWPT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/11/19", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform (HMP) makes calls
to the BYWARD^ORWPT API to retrieve a list of patients in a specific ward. HMP
also calls the INPLOC^ORWPT API to retrieve a patient's current location.\n
**NOTE: HMP is the only package that will be granted this level of access. **\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORWPT", "2016/03/14"], ["6273", "PCDETAIL~ORWPT1", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/11/19", "APPROVED", "Retired", "Private", "", "
Primary Care Detail information is returned as a list.
The list is text that can be displayed to a user or added to a patient record.\n
**NOTE: Only the Enterprise Health Management Platform (HMP) will be permitted
this access.\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORWPT1", "2016/04/01"], ["6274", "GETLIST~ORQQPX", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/11/19", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform calls
GETLIST^ORQQPX API in order to retrieve the information to build the cover
sheet for the reminders list.\n
**NOTE: HMP is the only package that will be granted this level of access. **\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "ORQQPX", "2016/03/10"], ["6275", "EDP(230", "File", "EMERGENCY DEPARTMENT", "2015/11/23", "APPROVED", "Retired", "Controlled Subscription", "230", "
The Enterprise Health MGMT Platform (HMP) accesses the
data in the ED Log file (#230) to retrieve information about emergency room
visits.\n\n
**************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library for list of retired HMP ICRs.
**************************************************************", "", "", "2016/04/26"], ["6276", "DIC(4.2", "File", "MAILMAN", "2015/11/24", "", "Withdrawn", "Controlled Subscription", "4.2", "
The Enterprise Health MGMT Platform (HMP) uses site
hashing to identify the individual sites that have treated a patient. The HMP
code is looping thru the Domain file (#4.2) using direct global access (read
only) in order to read the date in the Station field (#5.5) in order compare
the results to the Institution field (#.02) from the Treating Facility List
file (#391.91). When a match is made, the domain name (.01) field The Name
(#.01) from the Domain file (#4.2) for the matching entry is is used to create
the unique hash identified for the treating site.\n
All access to the Domain file is via direct global reads and with FileMan.", "", "", ""], ["6277", "HMP ACCESS TO YTT(601.72", "File", "MENTAL HEALTH", "2015/11/24", "APPROVED", "Retired", "Controlled Subscription", "601.72", "
The Enterprise Health MGMT Platform (HMP) is accessing
the MH Questions file (#601.72) to retrieve the Questions field for a
specified entry.\n
ICR will not be supported after the release of patch YS*5.01*123\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
If HMP is restarted in the future, this ICR must be reviewed with the
Custodial Package due to the global references and changes implemented with
YS*5.01*123. The Mental Health team will not allow the direct global reads
that are associated with this ICR.
**********************************************************************", "", "", "2016/04/20"], ["6278", "HMP UPDATE TO 9000010.23", "File", "PCE PATIENT CARE ENCOUNTER", "2015/11/24", "", "Withdrawn", "Controlled Subscription", "9000010.23", "
The Enterprise Health MGMT Platform (HMP) is adding new
records to the V Health Factors file (#9000010.23). HMP uses UPDATE^DIE to add
new health factors for a patient visit.\n
HMP identifies the last record in the file using a reverse $O.", "", "", ""], ["6279", "TIU AUDIT TRAIL", "File", "TEXT INTEGRATION UTILITIES", "2015/11/24", "APPROVED", "Retired", "Controlled Subscription", "8925.5", "
Used to retrieve information about TIU audits.\n
Access to the "B" cross-reference is needed, also.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2015/11/25"], ["6280", "HMP ACCESS TO LAB(64.5", "File", "LAB SERVICE", "2015/11/24", "", "Retired", "Private", "64.5", "
The Enterprise Health MGMT Platform (HMP) accesses the
Lab Reports file (#64.5) to retrieve lab report data.", "", "", "2017/11/06"], ["6281", "HMP ACCESS TO NPHASKEY~ORWU", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2015/11/24", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) request
permission to ue the NPHASKEY^ORWU API in order check to see if a user has a
specified security key.", "", "ORWU", ""], ["6282", "HMP ACCESS TO AUTTHF", "File", "PCE PATIENT CARE ENCOUNTER", "2015/11/24", "", "Withdrawn", "Controlled Subscription", "9999999.64", "
The Enterprise Health MGMT Platform (HMP) is accessing
the Health Factors file (#9999999.64) to get the Factor (.01) field.", "", "", ""], ["6283", "OE/RR PT SEL COMBO", "File", "ORDER ENTRY/RESULTS REPORTING", "2015/11/24", "APPROVED", "Retired", "Private", "100.24", "
Used to retrieve data from the OE/RR PT SEL COMBO file
(100.24). This is for read-only purposes.\n
Reading the "B" cross-reference is allowed.\n
NOTE: This access will only be granted to the Enterprise Health Management
Platform (HMP).\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/04/19"], ["6284", "HMP ACCESS TO DGCN(391.91", "File", "REGISTRATION", "2015/11/25", "", "Withdrawn", "Controlled Subscription", "391.91", "
HMP uses the AISS index to determine the record for the
specified Institution that is associated with the fully qualified ID that is
made up of the Source ID, Assigning Authority and Source ID Type. If the
record exists, the Patient DFN is parsed from the record.\n
HMP also uses the APAT cross reference to determine if there is an entry for
the specified pateint and specified Site IEN.\n
HMP uses the APAT cross reference to identify the institutions for the
specified patient. HMP loops through the APAT cross reference to get the IEN
for all records for the patient. Then HMP parse the Institution, Patient DFN,
Assigning Authority, Source ID, Identifier Status and Source ID Type.", "", "", ""], ["6285", "SELECTABLE IMMUNIZATIONS", "File", "PCE PATIENT CARE ENCOUNTER", "2015/11/30", "APPROVED", "Active", "Private", "9999999.14", "\n\n\n", "", "", "2015/12/16"], ["6286", "XUS KEY CHECK", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Supported", "", "
This RPC will check if the user (DUZ) holds a security
key or an array of keys. If a single security KEY is sent the result is
returned in R(0). If an array is sent down then the return array has the same
order as the calling array.\n
Input parameter: KEY - If key is a single value it holds one key to check. If
key is an array then the result is an array that matches the key list with
values that match the status of the key check for each key. The return is a 1
if the user has the key and 0 if not.\n
Input parameter: IEN - (Optional) If provided, this is the IEN of the user in
the NEW PERSON file (#200) to check if they hold the key(s) listed in KEY. If
not provided, this parameter defaults to the DUZ (IEN) of the current user.", "XUS KEY CHECK", "", "2016/09/12"], ["6287", "XUS ALLKEYS", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Supported", "", "
This RPC will return all the KEYS that a user holds. If
the FLAG is set to some value the list of KEYS will be screened to only be
those for J2EE use. The RPC was designed for FATKAAT and KAAJEE (VistALink
clients) but may be used by other applications.\n
Input parameter: IEN - This is the IEN or DUZ of the user in question. If not
passed in, the RPC will use the current user DUZ (IEN).", "XUS ALLKEYS", "", "2017/10/03"], ["6288", "XUS IAM FIND USER", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "XUS IAM FIND USER", "", "2016/08/22"], ["6289", "XUS IAM DISPLAY USER", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "XUS IAM DISPLAY USER", "", "2016/08/22"], ["6290", "XUS IAM ADD USER", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "XUS IAM ADD USER", "", "2016/08/22"], ["6291", "XUS IAM EDIT USER", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "XUS IAM EDIT USER", "", "2016/08/22"], ["6292", "XUS IAM TERMINATE USER", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "XUS IAM TERMINATE USER", "", "2016/09/12"], ["6293", "XUS IAM REACTIVATE USER", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "XUS IAM REACTIVATE USER", "", "2016/09/12"], ["6294", "XUS IAM BIND USER", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Controlled Subscription", "", "", "XUS IAM BIND USER", "", "2016/08/22"], ["6295", "XUS ESSO VALIDATE", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Private", "", "", "XUS ESSO VALIDATE", "", "2016/08/22"], ["6296", "XUS CVC", "Remote Procedure", "KERNEL", "2015/12/09", "APPROVED", "Active", "Private", "", "", "XUS CVC", "", "2017/09/01"], ["6297", "USAGE OF SCHEDULING ENTRY POINT", "Routine", "SCHEDULING", "2015/12/10", "", "Withdrawn", "", "", "
VPS CANCEL APPOINTMENT RPC calls the CANCEL^SDCNSLT
entry point when an appointment is cancelled with the Vetlink Kiosk
application. The Vetlink Kiosk application provides the veteran Scheduling
functionality via the KIOSKS located at VA Medical Centers. The
CANCEL^SDCNSLT is a pre-existing procedure that is called to update the
consult as part of the processing of the CANCEL APPOINTMENT action located on
Appt Mgt Module screen associated with the Appointment Management [SDAM APPT
MGT] option.\n
If a consult link exists, determined at ^SC(D0,S,D1,1,D2,CONS), then VPS KIOSK
application will need to call the CANCEL^SDCNSLT entry point to support the
Scheduling Consult Appointment linkage functionality.\n", "", "SDCNSLT", ""], ["6298", "HMP ACCESS TO PSB(53.79", "File", "BAR CODE MED ADMIN", "2015/12/14", "APPROVED", "Retired", "Controlled Subscription", "53.79", "
The Enterprise Health MGMT Platform (HMP) is accessing
the BCMA Medication Log file (53.79) to retrieve information about the
administration of med orders.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/04/22"], ["6299", "TIU use of TIU~HMPEVNT", "Routine", "HEALTH MANAGEMENT PLATFORM", "2015/12/15", "APPROVED", "Retired", "Controlled Subscription", "", "
Patch TIU*1*106 introduces code in the TIU package to
trigger sync actions to update the eHMP JDS database system when new notes are
added or existed notes are edited.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
subscribing application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "HMPEVNT", "2016/01/11"], ["6300", "CLINIC DEFINITION", "File", "INPATIENT MEDICATIONS", "2015/12/15", "", "Pending", "Supported", "53.46", "
The purpose of this Application Programming Interface
(API) is to provide the information from the Clinic Definition (#53.46) file
from Inpatient Medications.", "", "", ""], ["6301", "USR use of POSTX~HMPEVNT", "Routine", "HEALTH MANAGEMENT PLATFORM", "2015/12/15", "APPROVED", "Retired", "Controlled Subscription", "", "
Patch USR*1*37 introduces code to trigger a sync to HMP
JDS system wheneve a new user class is created or when an existing user class
is edited.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
subscribing application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "HMPEVNT", "2016/01/11"], ["6302", "ORALWORD ALLWORD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/16", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORALWORD ALLWORD TAG: ALLWORD
ROUTINE: ORALWORD RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes INPUT
PARAMETER: DFN PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1 INPUT PARAMETER:
OROI PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 2 INPUT PARAMETER:
ORX PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 3 INPUT PARAMETER:
ORTYPE PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 4\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORALWORD ALLWORD", "", "2016/02/05"], ["6303", "ORCHECK GETXTRA", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORCHECK GETXTRA TAG: GETXTRA
ROUTINE: ORCHECK RETURN VALUE TYPE: ARRAY
WORD WRAP ON: TRUE APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORCHECK GETXTRA", "", "2016/02/05"], ["6304", "ORDDPAPI CLOZMSG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORDDPAPI CLOZMSG TAG: CLOZMSG
ROUTINE: ORDDPAPI RETURN VALUE TYPE: WORD PROCESSING
WORD WRAP ON: TRUE APP PROXY ALLOWED: Yes
RETURN PARAMETER DESCRIPTION:
Returns the text of the OR CLOZ INPT MSG parameter used to display to the
user if it is set when entering an inpatient clozapine order.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORDDPAPI CLOZMSG", "", "2016/02/05"], ["6305", "OREVNTX1 GETSTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: OREVNTX1 GETSTS TAG: GETSTS
ROUTINE: OREVNTX1 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "OREVNTX1 GETSTS", "", "2016/02/05"], ["6306", "ORQQCN STATUS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORQQCN STATUS TAG: STATUS
ROUTINE: ORQQCN2 RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns a list of consult statuses currently in use, as reflected in the
"AC" XREF of ^GMR(123.1.
RETURN PARAMETER DESCRIPTION:
List of [Status IEN in ^ORD(100.01 concatenated with status text]\n
IEN^Text\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORQQCN STATUS", "", "2016/02/05"], ["6307", "ORQQCN SVC W/SYNONYMS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORQQCN SVC W/SYNONYMS TAG: SVCSYN
ROUTINE: ORQQCN2 RETURN VALUE TYPE: GLOBAL ARRAY
WORD WRAP ON: TRUE APP PROXY ALLOWED: Yes
DESCRIPTION:
This is a modified version of ORQQCN GET SERVICE TREE that also includes
synonyms for the services returned. It also allows passing of an optional
Consult IEN, for screening allowable services to forward the consult to,
especially in the case of interfacility consults. INPUT PARAMETER: Start
With PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 32
DESCRIPTION:
Which service in the hierarchy to begin with. INPUT PARAMETER: Purpose
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 2
DESCRIPTION:
0 for display purposes, 1 to order or forward a consult. INPUT PARAMETER:
Include Synonyms PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 2
DESCRIPTION:
0 to exclude synonyms, 1 to include synonyms. INPUT PARAMETER: Consult IEN
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 16 REQUIRED: NO
DESCRIPTION:
OPTIONAL - Include pointer to file 123, the Consult Request file. Used
when forwarding a consult, and screening needs to be done to limit the
list of services.
RETURN PARAMETER DESCRIPTION:
Output: Array formatted as follows-\n
svc ien^svc name or syn^parent^has children^svc usage^orderable item\n\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORQQCN SVC W/SYNONYMS", "", "2016/02/05"], ["6308", "ORWD1 PRINTGUI", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWD1 PRINTGUI TAG: PRINTGUI
ROUTINE: ORWD1 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
RPC used by CPRS GUI to print orders to a designated print device.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWD1 PRINTGUI", "", "2016/02/05"], ["6309", "ORWD1 RVPRINT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWD1 RVPRINT TAG: RVPRINT
ROUTINE: ORWD1 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
RPC used by CPRS GUI to print orders to a designated print device after
the review or sign actions were used.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWD1 RVPRINT", "", "2016/02/05"], ["6310", "ORWD2 DEVINFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWD2 DEVINFO TAG: DEVINFO
ROUTINE: ORWD2 RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns device information related to a location/nature of order when an
order is signed or released via CPRS GUI.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWD2 DEVINFO", "", "2016/02/03"], ["6311", "ORWDCN32 ORDRMSG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDCN32 ORDRMSG TAG: ORDRMSG
ROUTINE: ORWDCN32 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDCN32 ORDRMSG", "", "2016/02/03"], ["6312", "ORWDPS1 FAILDEA", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS1 FAILDEA TAG: FAILDEA
ROUTINE: ORWDPS1 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS1 FAILDEA", "", "2016/02/03"], ["6313", "ORWDPS1 ODSLCT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS1 ODSLCT TAG: ODSLCT
ROUTINE: ORWDPS1 RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS1 ODSLCT", "", "2016/02/03"], ["6314", "ORWDPS2 DAY2QTY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS2 DAY2QTY TAG: DAY2QTY
ROUTINE: ORWDPS2 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS2 DAY2QTY", "", "2016/02/03"], ["6315", "ORWDPS2 MAXREF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS2 MAXREF TAG: MAXREF
ROUTINE: ORWDPS2 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS2 MAXREF", "", "2016/02/03"], ["6316", "ORWDPS2 QTY2DAY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS2 QTY2DAY TAG: QTY2DAY
ROUTINE: ORWDPS2 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS2 QTY2DAY", "", "2016/02/03"], ["6317", "ORWDPS32 DRUGMSG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS32 DRUGMSG TAG: DRUGMSG
ROUTINE: ORWDPS33 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Return message text that is associated with a dispense drug.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS32 DRUGMSG", "", "2016/02/05"], ["6318", "ORWDPS32 ISSPLY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS32 ISSPLY TAG: ISSPLY
ROUTINE: ORWDPS33 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Return 1 if orderable item is a supply, otherwise return 0.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS32 ISSPLY", "", "2016/02/05"], ["6319", "ORWDPS32 VALQTY", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS32 VALQTY TAG: VALQTY
ROUTINE: ORWDPS33 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Validate a medication quantity and return a 1 if it is valid, otherwise
return 0.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS32 VALQTY", "", "2016/02/05"], ["6320", "ORWDPS32 VALROUTE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDPS32 VALROUTE TAG: VALROUTE
ROUTINE: ORWDPS32 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns the IEN for a route if the name is valid.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDPS32 VALROUTE", "", "2016/02/02"], ["6321", "ORWDRA32 APPROVAL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDRA32 APPROVAL TAG: APPROVAL
ROUTINE: ORWDRA32 RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDRA32 APPROVAL", "", "2016/02/02"], ["6322", "ORWDRA32 DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDRA32 DEF TAG: DEF
ROUTINE: ORWDRA32 RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
Loads dialog data (lists & defaults) for a radiology order.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDRA32 DEF", "", "2016/02/02"], ["6323", "ORWDX DGNM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDX DGNM TAG: DGNM
ROUTINE: ORWDX RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDX DGNM", "", "2016/02/02"], ["6324", "ORWDX LOCK ORDER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "", "Withdrawn", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDX LOCK ORDER TAG: LOCKORD
ROUTINE: ORWDX RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
RPC to attempt to lock a specific order.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "", "", ""], ["6325", "ORWDX UNLOCK ORDER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "", "Withdrawn", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDX UNLOCK ORDER TAG: UNLKORD
ROUTINE: ORWDX RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
RPC to unlock a specific order.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "", "", ""], ["6326", "ORWDX2 DCREASON", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDX2 DCREASON TAG: DCREASON
ROUTINE: ORWDX2 RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
RPC to return a list of valid discontinuation reasons.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDX2 DCREASON", "", "2016/02/02"], ["6327", "ORWDXA ISACTOI", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDXA ISACTOI TAG: ISACTOI
ROUTINE: ORWDXA RETURN VALUE TYPE: SINGLE VALUE
WORD WRAP ON: TRUE APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDXA ISACTOI", "", "2016/02/02"], ["6328", "ORWDXR RNWFLDS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDXR RNWFLDS TAG: RNWFLDS
ROUTINE: ORWDXR RETURN VALUE TYPE: ARRAY
APP PROXY ALLOWED: Yes
DESCRIPTION:
Return fields for renew action in format:
LST(0)=RenewType^Start^Stop^Refills^Pickup LST(n)=Comments\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDXR RNWFLDS", "", "2016/02/02"], ["6329", "ORWDXR01 CANCHG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWDXR01 CANCHG TAG: CANCHG
ROUTINE: ORWDXR01 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWDXR01 CANCHG", "", "2016/02/02"], ["6330", "ORWGRPC ITEMDATA", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWGRPC ITEMDATA TAG: ITEMDATA
ROUTINE: ORWGRPC RETURN VALUE TYPE: GLOBAL ARRAY
WORD WRAP ON: TRUE APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWGRPC ITEMDATA", "", "2016/02/02"], ["6331", "ORWGRPC ITEMS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWGRPC ITEMS TAG: ITEMS
ROUTINE: ORWGRPC RETURN VALUE TYPE: GLOBAL ARRAY
WORD WRAP ON: TRUE APP PROXY ALLOWED: Yes\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWGRPC ITEMS", "", "2016/02/02"], ["6332", "ORWOR1 GETDSCH", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWOR1 GETDSCH TAG: GETDSCH
ROUTINE: ORWOR1 RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns the schedule of the drug.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWOR1 GETDSCH", "", "2016/02/02"], ["6333", "ORWRP GET DEFAULT PRINTER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWRP GET DEFAULT PRINTER TAG: GETDFPRT
ROUTINE: ORWRP RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Returns default printer.\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWRP GET DEFAULT PRINTER", "", "2016/02/02"], ["6334", "ORWTPD GETDFLT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2015/12/17", "APPROVED", "Active", "Private", "", "
A new OR*3*426 patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The OR*3*426 patch is associated with the
VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: ORWTPD GETDFLT TAG: GETDFLT
ROUTINE: ORWTPD RETURN VALUE TYPE: SINGLE VALUE
WORD WRAP ON: TRUE APP PROXY ALLOWED: Yes
DESCRIPTION:
get default setting for all reports(time/occ limits)\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "ORWTPD GETDFLT", "", "2016/02/02"], ["6335", "TIU DETAILED DISPLAY", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2015/12/17", "", "Withdrawn", "Private", "", "
A new TIU*1*??? patch will be distributed that turns on
this RPC's flag - APP PROXY ENABLED. The TIU*1*??? patch is associated with
the VIAB*1*5 patch.\n\n
The following information is available about the RPC:\n
NAME: TIU DETAILED DISPLAY TAG: RPC
ROUTINE: TIUSRV RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION WORD WRAP ON: TRUE
APP PROXY ALLOWED: Yes
DESCRIPTION:
Gets details for display of a given record. INPUT PARAMETER: TIUDA
PARAMETER TYPE: LITERAL
REQUIRED: YES
DESCRIPTION:
This is the record number (IEN) in the TIU Document File (#8925).
RETURN PARAMETER DESCRIPTION:
Returns all known details of the record identified by TIUDA (Source,
Signature, Linked Problems, Body of document, etc.).\n
This ICR is created to satisfy the needs of the VIA project which is tasked to
replace MDWS services.", "", "", ""], ["6336", "SAVE STATUS REVIEW NOTIFICATION DATA", "Routine", "WOMEN'S HEALTH", "2017/06/30", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to add entries to the WV PREGNANCY/LACTATION STATUS CONFLICT EVENTS file
(#790.9). Entries in this file are created when a patient's pregnancy or
lactation state stored in the Women's Health software package conflicts with
data in other software packages. For example, the Women's Health pregnancy
state is NOT PREGNANT and a pregnancy laboratory test is resulted as positive,
subscribers should create an entry in file #790.9 with the pertinent details.", "", "WVRPCPT1", "2017/11/17"], ["6337", "POTENTIAL UNSAFE ORDERS LIST", "Routine", "WOMEN'S HEALTH", "2015/12/21", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to retrieve a list of potentially unsafe orders in a user friendly format.
This list is displayed when changing the patient's pregnancy status to
pregnant or lactation status to lactating.", "", "WVRPCPT1", "2017/11/17"], ["6338", "PSS*1*189 POST INSTALL WITH DD(52.6", "File", "1", "2015/12/21", "APPROVED", "Active", "Private", "52.6", "
This is a one-time ICR valid only for the Post-Install
Routine for patch PSS*1.0*189.\n
The INACTIVATION DATE field (#12) field will be displayed on any lookup
performed on the IV ADDITIVES File (#52.6) by creating a new "ID" node by
direct global set into ^DD(52.6,0,"ID",12) by Post-Install Routine PSS*1*189.", "", "", "2016/07/12"], ["6339", "PSS*1*189 POST INSTALL WITH DD(52.7", "File", "1", "2015/12/21", "APPROVED", "Active", "Private", "52.7", "
This is a one-time ICR valid only for the Post-Install
Routine for patch PSS*1.0*189\n
The INACTIVATION DATE field (#8) field will be displayed on any lookup
performed on the IV SOLUTIONS File (#52.7) by creating a new "ID" node by
direct global set into ^DD(52.7,0,"ID",8) by Post-Install Routine PSS*1*189.", "", "", "2016/07/12"], ["6340", "SEARCH FOR FINDINGS", "Routine", "CLINICAL REMINDERS", "2016/01/05", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to search for reminder definitions, terms, list rules, dialogs, order check
items groups and order check rules that reference an entity, such as orderable
items or quick orders.", "", "PXRMFRPT", "2016/01/27"], ["6341", "NOTIFICATIONS API", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/01/06", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
access to notification-related entry points.\n
REVISION: 10/2/23 - Added line tag EN", "", "ORBSMART", "2023/10/02"], ["6342", "Kernel-Storage API", "Routine", "KERNEL", "2016/01/06", "APPROVED", "Active", "Private", "", "
This API documents the callable APIs in the Kernel
routine %ZOSVKSD used for OS specific calls on behalf of VistA Capacity
Planning software. The purpose of this routine is to gather storage metrics.", "", "%ZOSVKSD", "2016/01/13"], ["6343", "Kernel Global Size APIs", "Routine", "KERNEL", "2016/01/06", "APPROVED", "Active", "Private", "", "
This API documents the callable APIs in the Kernel
routine %ZOSVKSE used for OS specific calls on behalf of VistA Capacity
Planning software. The purpose of this routine is to gather storage metrics
related to VistA globals.", "", "%ZOSVKSE", "2016/01/13"], ["6344", "x", "", "LAB SERVICE", "", "", "", "Supported", "", "", "", "", ""], ["6345", "Mental Health Instrument Listbox API", "Routine", "MENTAL HEALTH", "2016/01/06", "APPROVED", "Active", "Controlled Subscription", "", "
API to appropriately filter Mental Health instruments.", "", "YTQGMTS", "2016/01/20"], ["6346", "REMINDER MANAGEMENT MAILGROUP", "File", "CLINICAL REMINDERS", "2016/01/07", "APPROVED", "Active", "Private", "800", "
PCE PATIENT CARE ENCOUNTER would like to access the
REMINDER MANAGEMENT MAILGROUP (#800, #3) so that we can send MailMan messages
to the mailgroup defined in that field.", "", "", "2016/03/29"], ["6347", "PSJ53P46", "Routine", "INPATIENT MEDICATIONS", "2016/01/12", "APPROVED", "Active", "Supported", "", "
This API is provided to return the NUMBER OF DAYS field
(#1), AUTO-DC IMO ORDERS field (#2), SEND TO BCMA? field (#3), IMO DC/EXPIRED
DATE LIMIT field (#6), PRE-EXCHANGE REPORT DEVICE field (#5) and MISSING DOSE
field (#4) from the CLINIC DEFINITION file (#53.46).", "", "PSJ53P46", "2016/01/22"], ["6348", "ORQQPL4 LEX", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/01/26", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform UI calls the RPC
ORQQPL4 LEX in order to retrieve an indefinite list of terms that match the
user's search string.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "ORQQPL4 LEX", "", "2016/04/05"], ["6349", "Modify HL7 Version File", "File", "HEALTH LEVEL SEVEN", "2016/02/02", "APPROVED", "Active", "Private", "771.5", "
Check for existence of version 2.6 in the HL7 VERSION
(771.5) File. If it is missing add via call to FILE^DICN during the package
pre-installation routine. The following entries will be added:
.01 VERSION 2.6
2 STANDARD HEALTH LEVEL SEVEN\n
This ICR is temporary and only applicable to IB*2.0*547. The changes will be
overwritten by HL*1.6*164. It will be retired when the patch has been
nationally released and the compliance window and warranty periods have
elapsed.", "", "", "2016/03/02"], ["6350", "Modify HL7 Message Type File", "File", "HEALTH LEVEL SEVEN", "2016/02/02", "APPROVED", "Active", "Private", "771.2", "
Check for existence of Message Type EHC in the HL7
MESSAGE TYPE (771.2) File. If it is missing add via call to FILE^DICN during
the package pre-installation routine. The following entries will be added:
.01 ABBREVIATED NAME EHC
2 FULL NAME Health Care Invoice
3 VERSION 2.6\n
This ICR is temporary and only applicable to IB*2.0*547. The changes will be
overwritten by HL*1.6*164. It will be retired when the patch has been
nationally released and the compliance window and warranty periods have
elapsed.", "", "", "2016/03/02"], ["6351", "Modify the HL7 Event Type Code File", "File", "HEALTH LEVEL SEVEN", "2016/02/02", "APPROVED", "Active", "Private", "779.001", "
Check for existence of Event Type Code E12 in the HL7
EVENT TYPE CODE ( 779.001) File. If it is missing add via call to FILE^DICN
during the package pre-installation routine. The following entries will be
added:
.01 CODE E12
2 DESCRIPTION Request Additional Information
100 VERSION 2.6\n
This ICR is temporary and only applicable to IB*2.0*547. The changes will be
overwritten by HL*1.6*164. It will be retired when the patch has been
nationally released and the compliance window and warranty periods have
elapsed.", "", "", "2016/03/02"], ["6352", "Modify the HL7 Message Structure Code File", "File", "HEALTH LEVEL SEVEN", "2016/02/02", "APPROVED", "Active", "Private", "779.005", "
Check for existence of Message Structure Code EHC_E12
in the HL7 MESSAGE STRUCTURE CODE (779.005) File. If it is missing add via
call to FILE^DICN during the package pre-installation routine. The following
entries will be added:
.01 CODE EHC_E12
2 DESCRIPTION E12
3 VERSION 2.6\n
This ICR is temporary and only applicable to IB*2.0*547. The changes will be
overwritten by HL*1.6*164. It will be retired when the patch has been
nationally released and the compliance window and warranty periods have
elapsed.", "", "", "2016/03/02"], ["6353", "SCHEDULING BSE LOOKUP IN NETWORK LOCATION FILE", "File", "IMAGING", "2016/02/08", "APPROVED", "Active", "Private", "2005.2", "
VistA Scheduling GUI Enhancement (VS GUI) patch
SD*5.3*642 requests the ability to do a lookup of the PHYSICAL REFERENCE field
#1 within the NETWORK LOCATION file (#2005.2) using FileManager. This value
will be passed back to VS GUI in order to obtain values to support Single Sign
On (SSO) using the Broker Security Enhancement (BSE) lookup.", "", "", "2016/03/07"], ["6354", "DGPF ASSIGN FLAG", "Other", "REGISTRATION", "2016/02/12", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) is modifying
the DGPF ASSIGN FLAG Protocol to make it an extended action type protocol and
adding the HMP DGPF ASSIGN FLAG protocol as an Item under the DGPF ASSIGN FLAG
protocol.\n
HMP is modifying this protocol that a sync action between VistA and the JDS
system will occur when a patient's Patient Record Flags are added or edited.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/05/12"], ["6355", "SCMC PATIENT TEAM CHANGES", "Other", "SCHEDULING", "2016/02/12", "", "Retired", "Controlled Subscription", "", "
The Electronic Health MGMT Platform (HMP) is modifying
the SCMC PATIENT TEAM CHANGES Protocol to add the HMP PCMM TEAM POSTION
Protocol as an Item to the SCMC PATIENT TEAM CHANGES Protocol. Adding the HMP
PCMM TEAM POSITION as an Item will trigger a sync action between VistA and JDS
whenever the Patient Team Assignment File (#404.42) is updated.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
If HMP is reactivated in the future, this ICR should be discussed with PCMM
Web team to confirm the HMP protocols attached to the SCMC PATIENT TEAM
CHANGES and SCMC PATIENT TEAM POSITION CHANGES protocols provide the necessary
data for HMP.
**********************************************************************", "", "", ""], ["6356", "SCMC PATIENT TEAM POSITION CHANGES", "Other", "SCHEDULING", "2016/02/12", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) is adding the
HMP PCMM TEAM POSITION Protocol as an Item under the SCMC PATIENT TEAM
POSITION CHANGES Protocol. The HMP PCMM TEAM POSITION Protocol will trigger a
sync action between VistA and JDS whenever the Patient Team Position
Assignment File (#404.43) is updated.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
If HMP is reactivated in the future, this ICR should be discussed with PCMM
Web team to confirm the HMP protocols attached to the SCMC PATIENT TEAM
CHANGES and SCMC PATIENT TEAM POSITION CHANGES protocols provide the necessary
data for HMP.
**********************************************************************", "", "", ""], ["6357", "GMRD(120.83", "File", "ADVERSE REACTION TRACKING", "2016/02/17", "APPROVED", "Retired", "Private", "120.83", "
The Enterprise Health MGMT Platform (HMP) is accessing
the SIGNS/SYMPTOMS File (#120.83) to retrieve a list of all the Signs/Symptoms
in the file.\n
HMP is looping thru the file and pulling the IEN and the Name (.01) in order
to use this data to update the JDS database system that stores all the patient
data used by HMP.\n
NOTE: ICR #6357 was retired on 6/16/17 with the release of HMP*2*3.
References to the Signs/Symptoms (#120.83) file and associated code was
removed from HMP with this patch.", "", "", "2016/03/30"], ["6358", "ORD(100.98", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/02/18", "APPROVED", "Retired", "Private", "100.98", "
The Enterprise Health MGMT Platform (HMP) accesses the
DISPLAY GROUP File (#100.98) to retrieve a current list of Display Groups to
update the JDS database system used by the eHMP software.\n
HMP does direct global reads of the ORD(100.98 "B" cross reference in order to
lookup the Display Group for Pharmacy and Nursing Treatment orders. This data
is then used by HMP during the initial patient sync process that uploads this
data to the JDS database.\n
HMP also loops thru the file using a direct global read and $Order to retrieve
a list of all Display Groups. As each record is read, the HMP process collects
the record IEN, Name, Mixed Name and Short Name to send to JDS.\n
** NOTE: Access to this file for direct reads will only be granted to the HMP
project. **\n\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/03/14"], ["6359", "HMP USE OF STATUS~SDAMA308", "Routine", "SCHEDULING", "2016/02/18", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) requests to
use the STATUS^SDAMA308 API in order to retrieve the status of a patient
appointment.\n
HMP is retrieving this information along with other information about a
patient's appointments and syncing this data with the HMP JDS database system.\n
This is a temporary agreement until the HMP application can switch from using
STATUS~SDAMA308 to SDAPI~SDAMA301 documented in ICR #4433. Expiration date is
set for 1/1/17.\n\n
10/24/17-ICR has been retired and expiration date changed to 6/16/17 to match
the release date for HMP*2.0*3. The patch description references DE4469 and
use of SDAMA308 API. Search of HMP routines found a commented line at
SDAM1+12 in routine HMPDJ04 noting the change from SDAMA308 API to supported
SDAMA301 API (ICR #4433). No other reference to routine SDAMA308 in HMP
routines. HMP will be shutdown as of 10/27/17. If HMP is reactivated in the
future and this ICR is needed, the ICR should be reviewed by the custodial
application for approval.", "", "SDAMA308", "2016/04/20"], ["6360", "NDS associated fields", "File", "GEN. MED. REC. - VITALS", "2016/02/18", "", "Pending", "Supported", "120.51", "
Implement the native standardization LOINC for file
#120.51 Vital Signs
terminology domain GMRV VITAL TYPE file (#120.51)", "", "", ""], ["6361", "NDS Associated Fields", "File", "GEN. MED. REC. - VITALS", "2016/02/18", "", "Pending", "Supported", "120.52", "
Implement the native standardization for SNOMED CT for
file #120.52 for the
Vital Signs terminology domain GMRV VITAL QUALIFIER file (#120.52).", "", "", ""], ["6362", "NDS associated fields", "File", "GEN. MED. REC. - VITALS", "2016/02/18", "", "Pending", "Supported", "120.53", "
Implement the native standardization SNOMED CT for file
#120.53 for the
Vital Signs terminology domain GMRV VITAL CATEGORY file (#120.53).", "", "", ""], ["6363", "REMOVE SCHEDULED OPTION FROM #19.2", "File", "KERNEL", "2016/02/19", "", "Pending", "Private", "19.2", "
In Prosthetics package, the Patient Notification Letter
project was terminated, but there were options/routines already sent out via
patch RMPR*3.0*125. One of the options 'RMPR DVN NIGHTLY JOB' was directed to
be set as a nightly job in Taskman.\n
We have been directed to remove this option from the option file as well as
four remaining routines (RMPRDVN, RMPRDVN1, RMPRDVN2 & RMPRDVN3) be deleted.\n
Since the option is being removed and may have been tasked at various sites,
we want to insure that this task is removed from Taskman in a pre-install run
prior to deleting the option during the install. The pre-install routine
(RMPRTDEL) will be deleted immediately after execution as part of the build.\n
This ICR is only valid for RMPR*3.0*180.", "", "", ""], ["6364", "HMP ACCESS TO GMRD(120.53", "File", "GEN. MED. REC. - VITALS", "2016/02/19", "APPROVED", "Retired", "Controlled Subscription", "120.53", "
The Electronic Health MGMT Platform (HMP) is making
direct global reads of the GMRV VITAL CATEGORY File (#120.53) in order to
retrieve all the data in the file. HMP is syncing this file and the data it
contains between the local VistA system and the JDS database system.\n
HMP is using a $ORDER to loop thru the file to pull all the data and send it
to JDS.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/03/23"], ["6365", "HMP ACCESS TO GMRD(120.52", "File", "GEN. MED. REC. - VITALS", "2016/02/19", "APPROVED", "Retired", "Controlled Subscription", "120.52", "
The Electronic Health MGMT Platform (HMP) is making
direct global reads of the GMRC VITAL QUALIFIER File (#120.52) in order to
retrieve all the data in teh file. HMP syncs a copy of the local file with the
JDS database system used by the eHMP interface.\n
HMP is using a $ORDER to loop thru the file to pull all the data and send it
to JDS.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/03/23"], ["6366", "HMP ACCESS TO GMRD(120.51", "File", "GEN. MED. REC. - VITALS", "2016/02/19", "APPROVED", "Retired", "Controlled Subscription", "120.51", "
The Electronic Health MGMT Platform (HMP) is accessing
the GMRV VIAL TYPE File (#120.51) using direct global in order to sync the
local file with the JDS database system used the HMP user interface.\n
HMP is using a $ORDER to loop thru the file and pull all data and send the
data to JDS.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/03/23"], ["6367", "HMP ACCESS TO ORD(101.41", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/02/19", "APPROVED", "Retired", "Controlled Subscription", "101.41", "
The Electronic Health MGMT Platform (HMP) is accessing
the ORDER DIALOG File (#101.41) using direct global reads to retrieve data
related to specific order dialogs. HMP syncing this data with the HMP JDS
database system used by the eHMP user interface.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "", "2016/03/04"], ["6368", "HMP ACCESS TO ORD(101.42", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/02/19", "APPROVED", "Retired", "Private", "101.42", "
The Electronic Health MGMT Platform (HMP) is accessing
the ORDER URGENCY File (#101.42) using direct global reads. HMP is looping
thru the ORD(010.42,"S.RA" cross reference to identify records for the
Radiology/Nuclear Medicine usage for the urgency.\n
This data passed to the JDS database system used by the eHMP interface. The
data is collected when the initial sync process syncs data from VistA to JDS
for any of the HMP data domains.\n
**NOTE: HMP is the only package that is allowed this level of access.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "", "2016/03/10"], ["6369", "HMP ACCESS TO PS(51.2", "File", "PHARMACY DATA MANAGEMENT", "2016/02/19", "APPROVED", "Retired", "Controlled Subscription", "51.2", "
The Electronic Health MGMT Platform (HMP) is accessing
the MEDICATION ROUTES File (#51.2) using direct global reads to collect data
when syncing the HMP data domains during the intial sync for a patient. The
sync process syncs data from the local VistA system with the HMP JDS database
system.", "", "", "2016/04/20"], ["6370", "HMP ACCESS TO SC(", "File", "SCHEDULING", "2016/02/23", "", "Withdrawn", "Controlled Subscription", "44", "
The Enterprise Health MGMT Platform (HMP) is accessing
the Hospital Location file (#44) to retrieve a list of all active clinics. HMP
builds a list containing the IEN for the entry and the Name (.01). HMP loops
thru the B cross reference to get each entry, then checks the Type field (2)
and if the location is designated as a clinic it is added to the list. This
list is then synced with the HMP JDS database.", "", "", ""], ["6371", "ROUTINE PSSREF", "Routine", "PHARMACY DATA MANAGEMENT", "2016/02/24", "APPROVED", "Active", "Private", "", "
The National Drug File makes a call to routine ^PSSREF
from routine ^PSNPPSNW to create an Activity Log entry in the DRUG file (#50).\n", "", "PSSREF", "2018/04/25"], ["6372", "ROUTINE GMRAUIX0", "Routine", "ADVERSE REACTION TRACKING", "2016/02/24", "", "Withdrawn", "Private", "", "
The National Drug File makes a call to routine
^GMRAUIX0 at line tag EN2. This line tag will set the needed cross reference
in the PATIENT ALLERGIES file #120.8.", "", "GMRAUIX0", ""], ["6373", "LOOKUP PATIENTS IN PATIENT FILE", "File", "REGISTRATION", "2016/02/24", "", "Withdrawn", "Controlled Subscription", "2", "
This integration agreement allows subscribing packages
to look up patients in the PATIENT file (#2).", "", "", ""], ["6374", "PROSTHETICS-POINT OF USE-GIP LOOKUP", "File", "IFCAP", "2016/02/26", "APPROVED", "Active", "Private", "445", "
The IFCAP Generic Inventory Package (GIP) provides the
ability for sites to use Point of Use (POU) supply stations. An INVENTORY
POINT (#.01), which is stored and managed in the GENERIC INVENTORY file (#445)
can be linked to a Point of Use supply station with a pointer from its SS
PROVIDER field (#22). The SS PROVIDER field points to the AUTOMATED SUPPLY
STATIONS file (#445.5). When an INVENTORY POINT in file 445 has an entry in
field 22 that points to an AUTOMATED SUPPLY STATION entry, then the INVENTORY
POINT is known to be linked to a POU supply cabinet. These are special
cabinets that automatically update GIP inventory balances, via HL7 messaging,
when stock is removed.\n
This DBIA gives the Prosthetics package permission to read the SS PROVIDER
FIELD (#22) and determine if that field points to a valid entry in the
AUTOMATED SUPPLY STATIONS file (#445.5).\n\n", "", "", "2016/03/16"], ["6375", "NDS Laboratory Associated Fields", "File", "LAB SERVICE", "2016/02/29", "", "Pending", "Supported", "66.3", "
Implement the standardized Master Laboratory Test with
the native
standardization LOINC code for use in the Laboratory Services Domain. b", "", "", ""], ["6376", "VA Community Care Access to ASISTS GUI SUPERVISOR", "Other", "ASISTS", "2016/02/29", "", "Withdrawn", "Private", "", "
Responsibility for processing VA Community Care (VACC)
claims has changed from the VISNs/VAMCs to the Chief Business Office for
Purchased Care (CBOPC). As a national program, staff members often require
access to multiple VistA systems in order to perform their duties. A VACC
Supervisor menu is being created for use as a primary menu in accessing remote
VistA systems via CAPRI. Besides accessing roll and scroll VistA options the
supervisors also need to access ASISTS on remote systems through the
Supervisor GUI.", "", "", ""], ["6377", "VA Community Care Access to Fee Basis Options", "Other", "FEE BASIS", "2016/02/29", "APPROVED", "Active", "Private", "", "
Responsibility for processing VA Community Care (VACC)
claims has changed from the VISNs/VAMCs to the Chief Business Office for
Purchased Care (CBOPC). As a national program, staff members often require
access to multiple VistA systems in order to perform their duties. Two new,
role-based menus General VACC User CAPRI Menu [DVBA VACC GENERAL USER] and
VACC Supervisor CAPRI Menu [DVBA VACC SUPERVISOR] are being created for use as
a primary menu in accessing remote VistA systems via CAPRI. VACC staff need
to be able to access Fee Basis options on multiple VistA systems for
processing claims.", "", "", "2016/03/14"], ["6378", "VA Community Care Access to Registration Options", "Other", "REGISTRATION", "2016/02/29", "APPROVED", "Active", "Private", "", "
Responsibility for processing VA Community Care (VACC)
claims has changed from the VISNs/VAMCs to the Chief Business Office for
Purchased Care (CBOPC). As a national program, staff members often require
access to multiple VistA systems in order to perform their duties. Two new,
role-based menus General VACC User CAPRI Menu [DVBA VACC GENERAL USER] and
VACC Supervisor CAPRI Menu [DVBA VACC SUPERVISOR] are being created for use as
a primary menu in accessing remote VistA systems via CAPRI. VACC staff need
to be able to access some Registration options.", "", "", "2016/03/15"], ["6379", "VA Community Care Access to Imaging", "Other", "IMAGING", "2016/03/01", "", "Withdrawn", "Private", "", "
Responsibility for processing VA Community Care (VACC)
claims has changed from the VISNs/VAMCs to the Chief Business Office for
Purchased Care (CBOPC). As a national program, staff members often require
access to multiple VistA systems in order to perform their duties. Four new
menus are being created for use as a primary menu in accessing remote VistA
systems via CAPRI. VACC staff need to be able to access Imaging in support of
processing claims.", "", "", ""], ["6380", "VA Community Care Access to CPRSChart", "Other", "ORDER ENTRY/RESULTS REPORTING", "2016/03/01", "", "Withdrawn", "Private", "", "
Responsibility for processing VA Community Care (VACC)
claims has changed from the VISNs/VAMCs to the Chief Business Office for
Purchased Care (CBOPC). As a national program, staff members often require
access to multiple VistA systems in order to perform their duties. Four new,
role-based menus are being created for use as a primary menu in accessing
remote VistA systems via CAPRI. VACC staff need to be able to access CPRS
while processing claims.", "", "", ""], ["6381", "VA Community Care Access to Insurance Capture Buffer", "Other", "INSURANCE CAPTURE BUFFER", "2016/03/01", "", "Withdrawn", "Private", "", "
Responsibility for processing VA Community Care (VACC)
claims has changed from the VISNs/VAMCs to the Chief Business Office for
Purchased Care (CBOPC). As a national program, staff members often require
access to multiple VistA systems in order to perform their duties. Four new,
role-based menus are being created for use as a primary menu in accessing
remote VistA systems via CAPRI. VACC staff need to be able to access
documents in Insurance Capture Buffer while processing claims.", "", "", ""], ["6382", "VA Community Care Access to Fee Basis Claims System", "Other", "FEE BASIS CLAIMS SYSTEM", "2016/03/01", "", "Withdrawn", "Private", "", "
Responsibility for processing VA Community Care (VACC)
claims has changed from the VISNs/VAMCs to the Chief Business Office for
Purchased Care (CBOPC). As a national program, staff members often require
access to multiple VistA systems in order to perform their duties. Four new,
role-based menus are being created for use as a primary menu in accessing
remote VistA systems via CAPRI. VACC staff need to be able to use the Fee
Basis Claims System (FBCS) connected to different VistA systems in order to
process claims.", "", "", ""], ["6383", "IB ACCESS TO FB #162", "File", "FEE BASIS", "2016/03/03", "APPROVED", "Active", "Private", "162", "
Integrated Billing (IB) accesses the Fee Basis Payment
File (#162) in order to submit claims to third party payers for reimbursement
of Fee Basis payments. This is read only access.", "", "", "2016/05/18"], ["6384", "IB ACCESS TO FB #161", "File", "FEE BASIS", "2016/03/03", "APPROVED", "Active", "Private", "161", "
Integrated Billing (IB) accesses the Fee Basis Payment
File (#161) in order to submit claims to third party payers for reimbursement
of Fee Basis payments. This is read only access.", "", "", "2016/05/09"], ["6385", "RPC", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/03/08", "", "Pending", "Private", "", "", "", "", ""], ["6386", "DQSAVE", "Routine", "PCE PATIENT CARE ENCOUNTER", "2016/03/08", "APPROVED", "Active", "Private", "", "", "", "PXRPC", "2016/03/10"], ["6387", "IMMUNIZATION APIS", "Routine", "PCE PATIENT CARE ENCOUNTER", "2016/03/08", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
REVISIONS: 8/22/23 - Patch PX*1*236 adds a new parameter, PXSKIPNOTLIMITED, to
the IMMGRP component and a new parameter, PXSKIPFOUR, to the PATICR component
of this agreement. These new parameters will not impact current subscribers,
as the components will function as they do currently without this new
parameter.", "", "PXAPIIM", "2023/10/10"], ["6388", "INTEGRATED BILLING FB INTERFACE", "File", "FEE BASIS", "2016/03/09", "APPROVED", "Active", "Private", "162.4", "
THIS DATA WILL BE USED TO FACILITATE THIRD PARTY
REIMBURSEMENT OF FEE BASIS SERVICES IN INTEGRATED BILLING.", "", "", "2016/05/09"], ["6389", "6389 - Label CATC in FBPCR for IB", "Routine", "FEE BASIS", "2016/03/09", "APPROVED", "Active", "Private", "", "
Integrated Billing (IB) requires use of CATC^FBPCR to
determine if patient is liable for a copayment in the FEE BASIS system. IB
uses this information to seek third party reimbursement for FEE BASIS charges.\n", "", "FBPCR", "2016/09/20"], ["6390", "6390 - Label MKARRLTC in routine FBPCR4 for IB", "Routine", "FEE BASIS", "2016/03/09", "APPROVED", "Active", "Private", "", "
Determines if POV code is LTC, and whether it is
subject to a copayment.", "", "FBPCR4", "2016/05/09"], ["6391", "6391 - Function INSUR in IBBAPI", "Routine", "INTEGRATED BILLING", "2016/03/10", "", "Withdrawn", "Supported", "", "
Displays all insurance company information.", "", "IBBAPI", ""], ["6392", "6392 - IBFBUTIL FOR FEE BASIS", "Routine", "INTEGRATED BILLING", "2016/03/10", "APPROVED", "Active", "Private", "", "
Utility functions in Integrated Billing for use by Fee
Basis.", "", "IBFBUTIL", "2016/05/09"], ["6393", "VPR GET PATIENT DATA JSON", "Routine", "VIRTUAL PATIENT RECORD", "2016/03/17", "", "Withdrawn", "Private", "", "
The VISTA SERVICES ASSEMBLER package provides a set of
standard RESTified services. One of these services provides patient related
data collected from the GET^VPRDJ API and adds the ndcCode value associated
with any patient medications returned to the output.", "", "VPRDJ", ""], ["6394", "PROSTHETICS-DYNAMED LOOKUP", "Other", "IFCAP", "2016/03/18", "APPROVED", "Active", "Private", "", "
The Prosthetics package needs the ability to determine
whether a site is using DynaMed for inventory. Sites using DynaMed will
continue to use Prosthetics Inventory Package (PIP) until a better solution is
devised. This DBIA grants the Prosthetics package the permission to read the
system parameter "PRCV COTS INVENTORY" with the following kernel call:
($$GET^XPAR("SYS","PRCV COTS INVENTORY",1,"Q")). The "PRCV COTS INVENTORY"
parameter identifies which COTS product is being utilized for the inventory
management system of the site. The current values are:\n
NAME: PRCV COTS INVENTORY DISPLAY TEXT: COTS Inventory
MULTIPLE VALUED: No VALUE TERM: 0 or 1
VALUE DATA TYPE: set of codes VALUE DOMAIN: 0:NONE;1:DYNAMED
VALUE HELP: ?/ INSTANCE DATA TYPE: numeric\n
DESCRIPTION:
This parameter identifies which COTS product is being utilized for the
inventory management system of the site. The current values are:\n
0 NONE - means no COTS product is being used and the inventory
management system in use is GIP/IFCAP
1 DYNAMED - means the DynaMed product is being used", "", "", "2016/03/23"], ["6395", "HMP READ ACCESS TO PS(55", "File", "PHARMACY DATA MANAGEMENT", "2016/03/18", "APPROVED", "Retired", "Private", "55", "\n\n\n
The Enterprise Health MGMT Platform (HMP) request permission to do a Pharmacy
Patient to retrieve the ORDERS FILE ENTRY (#110) on the IV Multiple and the
ORDERS FILE ENTRY (#66) on the Unit Dose Multiple. HMP request temporary
approval to do direct global reads rather than using FileMan or the existing
APIs because of the need to get the data quickly so the process doesn't slow
down the data retrieval and impact the user interface.\n
HMP collects this data as part of the sync actions that syncs the patients
medication data between the local VistA system and the eHMP JDS database.", "", "", "2016/03/23"], ["6396", "HMP ACCESS TO SCTM(404.51", "File", "SCHEDULING", "2016/03/18", "APPROVED", "Retired", "Private", "404.51", "
The Enterprise Health MGMT Platform (HMP) requests
permissions to do a direct global read of the TEAM File (#404.51) to retrieve
the Name (.01) and Team Phone Number (.02) from the file. HMP uses this data
as part of the sync process that syncs the local VistA data with the HMP JDS
data system.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "", "2016/04/07"], ["6397", "HMP CALL TO FASTUSER~ORWORB", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/03/24", "APPROVED", "Retired", "Private", "", "
The Enterprise Health Management Platform (HMP) is
making a call to FASTUSER^ORWORB to retrieve a user's current notifications
for all patients. This data is collected and synced with the HMP JSON Data
System (JDS) for use with the HMP user interface.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "ORWORB", "2016/04/12"], ["6398", "IB ACCESS TO FB #161.2", "File", "FEE BASIS", "2016/03/31", "APPROVED", "Active", "Private", "161.2", "
Integrated Billing requires access to the Fee Basis
Vendor File (#161.2) to get the (#41.01) NPI and (#42) TAXONOMY CODE.", "", "", "2016/05/11"], ["6399", "BCMA MEDHIST", "", "BAR CODE MED ADMIN", "2016/04/01", "", "Pending", "Private", "", "", "", "", ""], ["6400", "HMP ACCESS TO FILE 101", "File", "KERNEL", "2016/04/07", "APPROVED", "Retired", "Private", "101", "
**NOTE: This ICR is for the Enterprise Health
Management Platform (HMP) only!\n
HMP Post Install Init Routine HMP0311P does a direct read of the B cross
reference to see if the HMP DGPF ASSIGN FLAG, DGPF ASSIGN FLAG exists in the
Protocol file. If the DGPF ASSIGN FLAG protocol exists, the routine edits the
protocol using FileMan to make the protocol an extended action protocol and to
add HMP DGPF ASSIGN FLAG protocol as an Item.\n
HMP Post Install Init routine HMP0311Q does a FileMan read of the Protocol
File to lookup to check for the HMP ADT-A04 CLIENT, VAFC ADT-A04 SERVER, HMP
ADT-A08 CLIENT and VAFC ADT-A08 SERVER protocols exist in the Protocol file.
If the protocols exist, the routine uses FileMan to subscribe the HMP protocol
to the VAFC protocol. HMP ADT-A04 Client is subscribed to VAFC ADT-A04 Server
protocol and HMP ADT-A08 Client is subscribed to the VAFC ADT-A08 Server
protocol.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "", "2016/04/12"], ["6401", "ACCOUNT PROFILE", "Routine", "ACCOUNTS RECEIVABLE", "2016/04/08", "APPROVED", "Active", "Controlled Subscription", "", "
Users working the Copay on Hold will be able to access
the Patient Account Profile report while still in the Copays on Hold List
Manager. This will aid them in determining if the copay may be released or
not.", "", "PRCAAPR1", "2016/08/31"], ["6402", "HMP ACCESS TO FILE 404.42", "File", "SCHEDULING", "2016/04/08", "", "Retired", "Private", "404.42", "
The Enterprise Health Management Platform (HMP) uses a
FileMan read to retrieve the Patient assigned to a Team from the PATIENT TEAM
ASSIGNMENT FILE (#404.42).\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
There are APIs available for PCMM data but HMP was not able to convert to use
an API prior the the shut down of HMP on 10/27/17. HMP requested temporary
approval of this ICR to give the project team time to convert to an API and to
work with the PCMM Web team to identify the best path for retrieving data with
the current and web version of PCMM.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the PCMM/Scheduling teams to resolve this issue and decide if this ICR is
needed.\n
**********************************************************************", "", "", ""], ["6403", "ACCOUNT PROFILE REPORT", "Routine", "ACCOUNTS RECEIVABLE", "2016/04/08", "APPROVED", "Active", "Controlled Subscription", "", "
Users working the Copay on Hold will be able to access
the Patient Account Profile report while still in the Copays on Hold List
Manager. This will aid them in determining if the copay may be released or
not.", "", "PRCAAPR", "2016/08/31"], ["6404", "FBUTL9", "Routine", "FEE BASIS", "2016/04/18", "", "Retired", "Controlled Subscription", "", "
Access to ADDUA and UOKPAY API's in FBUTL9", "", "FBUTL9", "2016/04/27"], ["6405", "LANGDEL~DGPRE", "Routine", "REGISTRATION", "2016/05/10", "APPROVED", "Active", "Private", "", "
The Scheduling routine ^SDM (expected w/SD*5.3*619) is
using Registration routine LANGDEL^DGRPE to check if Preferred Language
sub-field of the LANGUAGE DATE/TIME multiple (#7) in the PATIENT file (#2) is
entered. If not, call the LANGDEL^DGRPE to remove the sub record.", "", "DGRPE", "2016/07/22"], ["6406", "LANGUAGE DATE/TIME", "File", "REGISTRATION", "2016/05/11", "APPROVED", "Active", "Private", "2", "
Scheduling package requests permission to read/update
using FileMan to all fields in the LANGUAGE DATE/TIME multiple (#7) of the
PATIENT file (#2).", "", "", "2016/07/22"], ["6407", "Access to file 669", "File", "PROSTHETICS", "2016/05/17", "", "Pending", "Supported", "669", "
Access to the MASTER MEDICAL DEVICE file, #669, a
locked down file is granted as needed for display, reading functions", "", "", ""], ["6408", "ADD/UPDATE RESOURCE ON WEB SERVER FILE (#18.12)", "File", "WEB SERVICES CLIENT", "2016/05/18", "APPROVED", "Active", "Private", "18.12", "
The Master Veteran Index (MVI) team requests read/write
access to the WEB SERVER (#18.12) file to add a new entry during a
post-install process. The post-install routine process will create the new
server record entry using FILE^DICN and will also create a new entry to the
AUTHORIZED WEB SERVICES (#100) multiple, WEB SERVICE (#.01) field using the
FILE^DICN API.\n
In addition, the MVI team will require read/write access to the WEB SERVER
(#18.12) file to update the entry through the remote procedure (RPC) [MPI
VISTA HWS CONFIG] using FILE^DIE when needed/required.\n
NOTE: This processing is done programmatically to avoid having sites manually
configure HWSC using the Web Server Manager. This will ensure all sites have
the same configuration installed correctly.", "", "", "2021/11/23"], ["6409", "Access to HLCS(870)", "File", "HEALTH LEVEL SEVEN", "2016/05/20", "APPROVED", "Active", "Controlled Subscription", "870", "
Update all the logical links that use Vista Interface
Engine (VIE) to transmit HL7 messages to be replaced by VA Enterprise
Messaging Infrastructure (VA eMI).\n
The process to replace VIE to eMI will be to update the DNS DOMAIN field in
file 870, HL LOGICAL LINK, for existing logical links.\n
Revision History:
1/13/25: Added field 400.08, TCP/IP PORT (OPTIMIZED) for use by IB*2*769
patch - IB COPAY ACCUMULATION CONTINUE", "", "", "2016/06/02"], ["6410", "FORBID PURGING AUDITS", "File", "1", "2016/05/24", "APPROVED", "Active", "Controlled Subscription", "", "
The following data dictionary (DD) nodes can be set to
restrict purging of data and/or DD audits. These nodes have to be set directly
in programmer mode, since there is no utility to set them. These nodes can be
transported using the KIDS utility, if you send the full file Data Dictionary.\n\n", "", "", "2016/07/08"], ["6411", "Decode/Encode JSON", "Routine", "VIRTUAL PATIENT RECORD", "2016/05/24", "APPROVED", "Active", "Controlled Subscription", "", "
This is a utility for decoding and encoding JSON.", "", "VPRJSON", "2016/07/28"], ["6412", "HMP Access to TPPR~SCAPMC", "Routine", "SCHEDULING", "2016/05/25", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health Management Platform (HMP) makes a
call to the TPPR^SCAPMC API to retrieve all the positions for a practitioner.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "SCAPMC", "2017/08/09"], ["6413", "HMP Access to EN1~ORQPT2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/05/25", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health Management Platform (HMP) calls
the EN1^ORQPT2 API to determine if a patient's record is flag as sensitive or
NOT sensitive.", "", "ORQPT2", ""], ["6414", "HMP ACCESS TO PXRM APIS", "Routine", "CLINICAL REMINDERS", "2016/05/25", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health Management Platform (HMP) calls
the BMI^PXRMBMI and BSA^PXRMBMI APIs to retrieve the patient's BMI and BSA
results.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "PXRMBMI", "2016/08/29"], ["6415", "HMP USE OF DGPF EDIT ASSIGNMENT PROTOCOL", "Other", "REGISTRATION", "2016/05/27", "APPROVED", "Retired", "Controlled Subscription", "", "
HMP modified the DGPF EDIT ASSIGNMENT protocol to make
it an extended action type and to add the HMP DGPF ASSIGN FLAG protocol as an
Item. the HMP DGPF ASSIGN FLAG will initiate a sync action when a patient's
flags are edited.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "", "2016/08/12"], ["6416", "HMP USE OF DGPF CHANGE ASSIGNMENT OWNERSHIP", "Other", "REGISTRATION", "2016/05/27", "APPROVED", "Retired", "Controlled Subscription", "", "
HMP modified the DGPF CHANGE ASSIGNMENT OWNERSHIP
protocol to make it an extended action type and to add the HMP DGPF ASSIGN
FLAG protocol as an Item. the HMP DGPF ASSIGN FLAG will initiate a sync action
when a patient's flags change ownership.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "", "2016/08/12"], ["6417", "SCV ACCESS TO DATP~SDWLEVAL", "Routine", "SCHEDULING", "2016/06/01", "APPROVED", "Active", "Controlled Subscription", "", "
The Scheduling Calendar View Mobile App (MBAA) calls
the DATP^SDWLEVAL API to retrieve specific appointment data for a patient.", "", "SDWLEVAL", "2016/06/10"], ["6418", "SCV ACCESS TO CHKENC~SDWLQSC1 API", "Routine", "SCHEDULING", "2016/06/01", "APPROVED", "Active", "Controlled Subscription", "", "
This API checks for any encounters for a patient and
returns encounter data.", "", "SDWLQSC1", "2016/06/10"], ["6419", "MBAA ACCESS TO 1010EZ DATA", "File", "REGISTRATION", "2016/06/01", "APPROVED", "Active", "Controlled Subscription", "2", "
The Scheduling Calendar View Mobile App (MBAA) is
access the 1010EZ data in the Patient File (#2) in order to provide
information about patients on the NEAR list.\n
The Scheduling Calendar View Mobile Apps allows users to get a list of
patients on the NEAR list and if the user schedules an appointment for a
patient to the list, they can then update the NEAR list to remove the patient
from the list.", "", "", "2016/06/13"], ["6420", "FEE BASIS ACTIVITY CHECKS", "Routine", "FEE BASIS", "2016/06/15", "APPROVED", "Active", "Private", "", "
The Master Veteran Index (MVI) team requests access to
the Application Programmer Interface (API) $$ACTIVITY^FBUTLMVI to determine if
there has been any activity for a patient that has been reported as deceased.
MVI will determine the activity for a given patient through a remote procedure
call (RPC) to each VistA site from the MVI to determine if the patient is
really deceased.", "", "FBUTLMVI", "2016/08/12"], ["6421", "VAFC DOD ACCEPT SET/DISPLAY", "Remote Procedure", "REGISTRATION", "2016/06/20", "APPROVED", "Active", "Private", "", "
The Master Veteran Index (MVI) team requests access to
the REGISTRATION remote procedure call (RPC) : VAFC DOD ACCEPT SET/DISPLAY.
This RPC will be used to set whether a site can process Date of Death (DOD)
messages from the MVI, and also be used to query a site to determine its
current ability to process DOD messages from the MVI.\n
TAG: EN ROUTINE:VAFCDODA\n
Parameters:
TYPE (Required) - "S" - Set the PROCESS MVI DOD UPDATE? (#1401) field
in the MAS PARAMETERS (#43) file.
"D" - Retrieve the PROCESS MVI DOD UPDATE? (#1401)
field in the MAS PARAMETERS (#43) file.
SET (Optional) - "1" for "YES"
"0" for "NO"", "VAFC DOD ACCEPT SET/DISPLAY", "", "2016/08/10"], ["6422", "HMP Access to ERROR~GMVUTL1", "Routine", "GEN. MED. REC. - VITALS", "2016/06/29", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) uses the
ERROR^GMVUTL1 API to mark a vital as entered in error.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
HMP developer verified HMP needs an ICR for access to GMVUTL1 API. Custodial
package could not review this ICR prior to HMP shutdown. It will need to be
reviewed by the custodial package in the future if HMP is reactivated.\n
**********************************************************************", "", "GMVUTL1", ""], ["6423", "MBAB USE OF ORWORR APIS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/07/05", "", "Withdrawn", "Controlled Subscription", "", "
The Warfarin Mobile App (MBAB) calls AGET^ORWORR to
retrieve an abbreviated order list for a patient. This list is used to
determine if the patient has a prescription for Warfarin.\n
ICRs #6423, 6424 and 6425 were withdrawn on 3/8/18. ICRs were initially
requested on 7/5/16. The National Patch Module does not have patches for this
package. It does not look like the project is active. If these Integration
Control Registration (ICRs) are needed, they can be resubmitted for review
with the custodial package.", "", "ORWORR", ""], ["6424", "MBAB ACCESS TO THE ORDER STATUS FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/07/05", "", "Withdrawn", "Controlled Subscription", "101.01", "
The Warfarin Mobile App (MBAB) extracts a list of the
Order Status Names form the Order Status File (#101.01) using FileMan calls.\n
ICRs #6423, 6424 and 6425 were withdrawn on 3/8/18. ICRs were initially
requested on 7/5/16. The National Patch Module does not have patches for this
package. It does not look like the project is active. If these Integration
Control Registration (ICRs) are needed, they can be resubmitted for review
with the custodial package.", "", "", ""], ["6425", "MBAB ACCESS TO THE DISPLY GROUP FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/07/05", "", "Withdrawn", "Controlled Subscription", "100.98", "
The Warfarin Mobile App (MBAB) accesses the Display
Group file (#100.98) to retrieve the Display Group Name and Mixed Name using
FileMan.\n
ICRs #6423, 6424 and 6425 were withdrawn on 3/8/18. ICRs were initially
requested on 7/5/16. The National Patch Module does not have patches for this
package. It does not look like the project is active. If these Integration
Control Registration (ICRs) are needed, they can be resubmitted for review
with the custodial package.", "", "", ""], ["6426", "HMP ACCESS TO ORDRNUM~PSSUTLA2", "Routine", "PHARMACY DATA MANAGEMENT", "2016/07/06", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the PSS
API, ORDRNUM^PSSUTLA2 in order to retrieve the order number for a specific
inpatient med order.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "PSSUTLA2", "2017/10/13"], ["6427", "HMP USE OF EDITSAVE~ORWDAL32", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/07/14", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health Management Platform (HMP) is
calling EDITSAVE^ORWDAL32 in order to save allergy or adverse reaction data
for a patient.", "", "ORWDAL32", ""], ["6428", "HMP USE OF GETXTRA~ORCHECK", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/07/14", "APPROVED", "Retired", "Private", "", "
The Enterprise Health Management Platform (HMP) uses
GETXTRA^ORCHECK to retrieve any extra lines used for order checks.\n
**NOTE: This ICR is for HMP use only!\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
*********************************************************************", "", "ORCHECK", "2016/08/19"], ["6429", "PSO use of TCP/IP, Domain, and TCP/IP Port", "File", "HEALTH LEVEL SEVEN", "2016/07/18", "", "Retired", "Private", "870", "
The Outpatient Pharmacy package is in need of modifying
the DNS DOMAIN, TCP/IP ADDRESS, and TCP/IP PORT of the HL LOGICAL LINK file
(#870). Outpatient Pharmacy will also be looking at the 'B' index for the IEN
of the new logical link named PSORRXSEND.\n
This ICR is a one-time agreement for PSO*7.0*454.", "", "", ""], ["6430", "DATE OF DEATH UPDATE CHECK", "Routine", "REGISTRATION", "2016/07/19", "", "Pending", "Private", "", "
The CLINICAL INFO RESOURCE NETWORK (RG) package
requests access to the REGISTRATION Application Program Interface (API)
$$CHK^VAFCDODA. This API will be used to determine whether the site should
receive and process the Date of Death update for the patient or not.", "", "VAFCDODA", "2016/10/12"], ["6431", "OR ACCESS TO HMP SUBSCRIPTION", "Routine", "HEALTH MANAGEMENT PLATFORM", "2016/07/20", "APPROVED", "Retired", "Private", "", "
The Enterprise Health Management Platform (HMP) process
to sync the data between the VistA system and the eHMP JSON Database System
(JSON) requires date/timestamps that include seconds in order to correctly
sequence different events/actions on an order that occur within the same
minute. Routines ORCSAVE, ORCSAVE2, ORWDX and ORWDXA have been modified to
update the HMP SUBSCRIPTION FILE (#800000) when order events occur. This
update will store the event and event date/time including seconds in the HMP
SUBSCRIPTION FILE. All updates are made by calling APIs in the HMPOR routine.\n\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
subscribing application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "HMPOR", "2017/10/04"], ["6432", "GMRV ACCESS TO GMRV~HMPEVNT", "Routine", "HEALTH MANAGEMENT PLATFORM", "2016/07/22", "APPROVED", "Retired", "Controlled Subscription", "", "
The GMRV VITAL MEASUREMENT FILE (#120.5) Index, AHMP
makes a call to the GMRV^HMPEVNT API to trigger a sync activity to sync local
VistA data with the HMP JSON Database System (JDS) when a vital measurement is
marked as entered in error.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
subscribing application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "HMPEVNT", "2016/08/22"], ["6433", "HMP USE OF SAVE~ORWDX", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/07/25", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
SAVE^ORWDX API to save a new order.", "", "ORWDX", ""], ["6434", "HMP USE OF VALID~ORWDXA", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/07/25", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform (HMP) calls the
VALID^ORWDXA API to determine if an action is valid for an order.\n
**NOTE: This ICR is approved for HMP only!\n\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "ORWDXA", "2016/08/08"], ["6435", "HMP USE OF ACCEPT~ORWDXC", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/07/25", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform (HMP) calls
ACCEPT^ORWDXC in order when a provider accepts an order.\n
**NOTE: This ICR is approved for HMP only!\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "ORWDXC", "2016/08/08"], ["6436", "HMP USE OF EDITSAVE~ORWDAL32", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/07/26", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform (HMP) calls
EDITSAVE^ORWDAL32 to edit allergy information or to mark an allergy as entered
in error.\n
**NOTE: This ICR is for HMP only.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "ORWDAL32", "2016/08/22"], ["6437", "HMP USE OF CLINPTS2~ORQPTQ2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/08/02", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform (HMP) makes a call
to CLINPTS2^ORQPTQ2 to retrieve a list of up to 200 patients that have
appointments at a specified clinic for a specified date range.\n
**NOTE: This ICR is approved for HMP only.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "ORQPTQ2", "2016/08/08"], ["6438", "HMP USE OF LOCK AND UNLOCK ORWDX", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/08/02", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
LOCK^ORWDX and UNLOCK^ORWDX APIs to lock and unlock a patient record as a new
order is entered for the patient.", "", "ORWDX", ""], ["6439", "HMP USE OF LOCKORD AND UNLKORD IN ORWDX", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/08/02", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls
LOCKORD^ORWDX and UNLKORD^ORWDX to lock and unlock an order in the ORDER FILE
(#100) when saving or editing an order.", "", "ORWDX", ""], ["6440", "HMP USE OF ORWDX APIs", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/08/02", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform (HMP) calls
SEND^ORWDX to sign an order.\n
**NOTE: This ICR is for HMP use only!\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "ORWDX", "2016/08/19"], ["6441", "HMP USE OF LEX~ORWPCE4", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/08/02", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
LEX^ORWPCE4 API to retrieve a list of Lexicon information.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "ORWPCE4", "2016/08/05"], ["6442", "HMP USE OF VALIDSIG~ORWU", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/08/02", "APPROVED", "Retired", "Private", "", "
The Enterprise Health MGMT Platform (HMP) calls
VALIDSIG^ORWU in check to be sure the electronic signature code entered by the
user is valid.\n
**NOTE: This ICR is only approved for HMP.\n\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "ORWU", "2016/08/08"], ["6443", "HMP USE OF DQSAVE~ORWPCE1", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/08/03", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) makes a call
to DQSAVE^ORWPCE1 in order to save encounter data.\n\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
The CPRS team did not approve access to the ORWPCE SAVE RPC or DQSAVE~ORWPCE1
API. One reason is because the code sets the source as TIU which can cause
downstream confusion. The API is called from the HMP WRITEBACK ENCOUNTERS
RPC. HMP stated the HMP WRITEBACK ENCOUNTERS RPC is not used but it is an RPC
in the HMP UI CONTEXT option. The call to DQSAVE~ORWPCE1 API is found in
routine HMPWB5.\n
If HMP is reactivated in the future, the HMP project team should review this
ICR with the Custodial Package. OR*3.0*377 will be modifying this API. HMP
may need to modify HMP to remove the HMP WRITEBACK ENCOUNTERS RPC from the
context option and the call to ORWPCE1 routine.\n
**********************************************************************", "", "ORWPCE1", ""], ["6444", "ADD THREE FIELDS TO INSTITUTION FILE#4", "File", "KERNEL", "2016/08/05", "APPROVED", "Active", "Private", "4", "
The VA FileMan team would like to add three (3) new
fields to the INSTITUTION file (#4). The new fields will be used to support
the determination of GMT and TimeZone offset based on a given Institution
Entry.\n
Descriptions:
-------------\n
4,800 LOCATION TIMEZONE 8;1 POINTER TO WORLD TIMEZONES FILE (#1.71)
LAST EDITED: AUG 10, 2016
HELP-PROMPT: Enter the timezone or '?' to list timezones
DESCRIPTION: This is the timeZone of this specific location.\n
4,801 COUNTRY 8;2 POINTER TO COUNTRY CODE FILE (#779.004 )
LAST EDITED: AUG 15, 2016
HELP-PROMPT: Enter the country, or '?' to list countries
DESCRIPTION: Country of this location.\n
4,802 TIMEZONE EXCEPTION 8;3 SET '0' FOR SST Only;
LAST EDITED: AUG 09, 2016
HELP-PROMPT: Enter 0 if this is for Standard Time only.
DESCRIPTION: This location does not follow the TimeZone and country
timeframe changes therefore only follows STANDARD time. Example: Some
locations in the USA do not follow the change to DAYLIGHT SAVINGS but remain
STANDARD all year long. Those locations would need this exception defined.
Puerto Rico's TimeZone is Atlantic which is also used by Canada, Dominican
Republic, and Bermuda. Canada and Bermuda change timeframes and Puerto Rico
and Dominican Republic do not. A location in Puerto Rico or Dominican
Republic would need to have the exception field set to SST only.\n
----------\n
The three fields will be sent out to the sites via the VA FILEMAN patch
DI*22.2*2. We will only send the three fields (partial), not the entire
Institution DD in KIDS. These fields will be maintained via the FORUM process.\n", "", "", "2016/08/17"], ["6445", "DIUTC", "Routine", "1", "2016/08/05", "APPROVED", "Active", "Supported", "", "
This Coordinated Universal Time (UTC) API will convert
a FileMan date/time into Greenwich Mean Time (GMT) with a time zone offset
based on various input values entered by the user or the default institution
in the DUZ(2) variable.\n
The format of the default output will be a GMT represented in standard FileMan
date/time format and an internal three digit time zone offset appended to the
end. The calculation for the internal offset is the external offset converted
to minutes, then divided by 5, and then added to 500. So -07:00 is -420
minutes, then divided by 5 is -84, and added to 500 is 416.\n
There may be other output variables based on the value of the EXT input
parameter. The details for the other output values are documented in the
$$UTC variable below.\n
To determine the offset, the API needs to have a TimeZone and Country. These
values are determined using the following algorithm:\n
1. No optional input parameters are passed in. The user's default
Institution will be used based on the DUZ(2) variable. The TimeZone and
Country are determined by the new fields in the Institution file.\n
2. If only Institution is passed in as an input parameter, the TimeZone
and Country are determined by the new fields in the Institution file.\n
3. The TimeZone and Country parameters are both passed in as input
parameters.\n\n
The UTC API will return an error for any of the following conditions:\n
1. If the TimeZone or Country cannot be determined from any of the
methods documented above, an error will be returned.\n
2. If the TimeZone parameter is passed in without Country parameter or
the Country parameter is passed in without a TimeZone parameter, an error will
be returned.\n
3. If the Institution parameter is passed in with either the TimeZone or
Country parameter, an error will be returned.\n
4. Once the TimeZone and Country are determined, they will be validated
for consistency. An error will be returned if they are inconsistent e.g. if
user passes in TimeZone = "Australian Eastern Time" and Country="Mexico", the
UTC API will return an error.", "", "DIUTC", "2017/06/23"], ["6446", "HMP ACCESS TO THE LAB DATA FILE", "File", "LAB SERVICE", "2016/08/10", "", "Retired", "Controlled Subscription", "63", "
The Enterprise Health MGMT Platform is doing direct
global reads in the Lab Data File (#63) to get the TIU ENTRY POINTER from TIU
REFERENCE DATE/TIME - X where X is the type of report. HMP loops thru
^LR(D0,HMPSUB,D1,.05 and gets the value in the second field on the
^LR(D0,HMPSUB,D1,.05,D2,0) node (HMPSUB is the type of report). The field is a
pointer to the TIU DOCUMEMNT FILE (#8925). This value is then used to lookup
the enter in TIU DOCUMENT FILE (#8925) to get the name of the TIU Document.\n
HMP also accesses the data nodes, LR(D0,HMPSUB,D1,.1,D2,0 to get the .01
field, SPECIMENT.\n
This data is collected during the pateint sync processes that sync the local
VistA patient data with the HMP JSON Database System (JDS).\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Discussions between the Lab package resources and HMP contacts identified
possible concerns that eHMP may be getting Lab updates from the protocol but
may not be getting 'AP' updates they are expecting. It was also noted AP
orders are not currently part of CPRS. EHMP was also asked if they knew that
TIU document names are nationally standardized and there is a 1:1 correlation
between the API section and the corresponding TIU Document definition. It was
also noted that not all sites use electronic signature so their AP reports are
stored in the Lab Data file.\n
These questions and issues were not resolved prior to HMP shutdown on 10/27/17
and the ICR was not activated. It will be retired as part of the HMP shutdown
process. If HMP is reactivated in the future, the access provided by this ICR
should be reviewed with the custodial application to assure HMP is getting the
Lab data the application needs.\n
**********************************************************************", "", "", ""], ["6447", "HMP CALL TO ORCNOTE GET TOTAL RPC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/16", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORCNOTE GET TOTAL RPC in order to retrieve the number of progress notes for a
patient.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Use of this RPC was disapproved by CPRS on 11/3/16. However the RPC is an RPC
in the HMP UI CONTEXT option. This ICR will be retired with an expiration
date of 10/27/17 as part of the HMP shut down process.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the CPRS team to resolve this issue.\n
**********************************************************************", "", "", ""], ["6448", "ORQQPL ADD SAVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/16", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORQQPL ADD SAVE RPC to
save a new record in the PROBLEM FILE (#9000011).\n
**NOTE: This ICR is for HMP only.", "ORQQPL ADD SAVE", "", "2016/11/08"], ["6449", "ORQQPL DELETE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/16", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORQQPL DELETE RPC to
delete an entry in the PROBLEM FILE (#9000011).\n
**NOTE: This ICR is for HMP only.", "ORQQPL DELETE", "", "2016/11/08"], ["6450", "ORQQPL EDIT LOAD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/16", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORQQPL EDIT LOAD RPC to
retrieve an array of default fields and original fields from the PROBLEM FILE
(#9000011).\n
**NOTE: This ICR is for HMP only.", "ORQQPL EDIT LOAD", "", "2016/11/08"], ["6451", "ORQQPL EDIT SAVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/16", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORQQPL EDIT SAVE RPC to
save changes to an existing problem in the PROBLEM FILE (#9000011).\n
**NOTE: This ICR is for HMP only.", "ORQQPL EDIT SAVE", "", "2016/11/08"], ["6452", "ORQQPL USER PROB LIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/16", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORQQPL USER PROB LIST RPC
to retrieve a list of user specific problems to select from.\n
**NOTE: This ICR is for HMP only.", "ORQQPL USER PROB LIST", "", "2016/11/08"], ["6453", "ORQQPX REMINDER DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORQQPX REMINDER DETAILS RPC in order to retrieve the Clinical Reminder
Identifier from the PCE REMINDER/MAINTENANCE ITEM FILE (#811.9).\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Use of this RPC was disapproved by CPRS on 11/3/16. However the RPC is an RPC
in the HMP UI CONTEXT option. This ICR will be retired with an expiration
date of 10/27/17 as part of the HMP shut down process.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the CPRS team to resolve this issue.\n
**********************************************************************", "ORQQPX REMINDER DETAIL", "", ""], ["6454", "ORQQVI NOTEVIT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORQQVI NOTEVIT RPC in
order to retrieve the patient's most recent vital measurements.\n
**NOTE: This ICR is for HMP only.", "ORQQVI NOTEVIT", "", "2016/11/08"], ["6455", "ORWDAL32 ALLERGY MATCH", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORWDAL32 ALLERGY MATCH RPC
to search for potential allergies for a patient.\n
**NOTE: This ICR is for HMP only.", "ORWDAL32 ALLERGY MATCH", "", "2016/11/08"], ["6456", "ORWDAL32 CLINUSER", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORWDAL32 CLINUSER RPC to
determine if the user can perform cover sheet allergy actions.\n
**NOTE: This ICR is for HMP only.", "ORWDAL32 CLINUSER", "", "2016/11/08"], ["6457", "ORWDAL32 SYMPTOMS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORWDAL32 SYMPTOMS RPC to
retrieve a subset of symptoms.\n
**NOTE: This ICR is for HMP only.", "ORWDAL32 SYMPTOMS", "", "2016/11/08"], ["6458", "XSAPXUTL APIs", "Routine", "VISTA SERVICES ASSEMBLER", "2016/08/17", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR allows any VistA application that uses the
VISTA SERVICES ASSEMBLER (VistA.js) Platform to call these APIs in order to
create supported VistA.js REST services.", "", "XSAPXUTL", "2016/09/15"], ["6459", "ORWDRA32 RAORDITM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "APPROVED", "Active", "Private", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWDRA32 RAORDITM RPC to retrieve a subset of orderable items.\n
**NOTE: This ICR is for HMP and Mobile Scheduling Application Suite only.", "ORWDRA32 RAORDITM", "", "2016/11/08"], ["6460", "HMP CALL TO ORWLEX GETFREQ RPC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWLEX GETFREQ RPC to wrap the Lexicon API $$FREQ^LEXU to satisfy the
requirements of the ICD-10-CM diagnostic search.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Use of this RPC was disapproved by CPRS on 11/3/16. However the RPC is an RPC
in the HMP UI CONTEXT option. This ICR will be retired with an expiration
date of 10/27/17 as part of the HMP shut down process.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the CPRS team to resolve this issue.\n
**********************************************************************", "", "", ""], ["6461", "ORWPCE GETSVC", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/17", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWPCE GETSVC RPC to to calculate the correct service category.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Use of this RPC was disapproved by CPRS on 11/3/16. However the RPC is an RPC
in the HMP UI CONTEXT option. This ICR will be retired with an expiration
date of 10/27/17 as part of the HMP shut down process.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the CPRS team to resolve this issue.\n
**********************************************************************", "ORWPCE GETSVC", "", ""], ["6462", "ORWPCE HASVISIT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWPCE HASVISIT RPC to retrieve the status of a visit associated with a note.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Use of this RPC was disapproved by CPRS on 11/3/16. However the RPC is an RPC
in the HMP UI CONTEXT option. This ICR will be retired with an expiration
date of 10/27/17 as part of the HMP shut down process.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the CPRS team to resolve this issue.\n
**********************************************************************", "ORWPCE HASVISIT", "", ""], ["6463", "ORWPCE LEXCODE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWPCE LEXCODE RPC to retrieve the code associated with a lexicon entry.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Use of this RPC was disapproved by CPRS on 11/3/16. However the RPC is an RPC
in the HMP UI CONTEXT option. This ICR will be retired with an expiration
date of 10/27/17 as part of the HMP shut down process.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the CPRS team to resolve this issue.\n
**********************************************************************", "ORWPCE LEXCODE", "", ""], ["6464", "ORWPCE NOTEVSTR", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORWPCE NOTEVSTR RPC to
retrieve the visit location, episode begin date and the visit type for the TIU
Document File (#8925).\n
**NOTE: This ICR is for HMP only.", "ORWPCE NOTEVSTR", "", "2016/11/08"], ["6465", "ORWPCE SAVE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWPCE SAVE RPC to save PCE information enter through the eHMP User Interface
(UI).", "ORWPCE SAVE", "", ""], ["6466", "ORWPCE SCSEL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWPCE SCSEL RPC to retrieve a list of service connected conditions that may
be selected.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Use of this RPC was disapproved by CPRS on 11/3/16. CPRS recommended HMP go
to PCE for the PXAPI routine. However the RPC is an RPC in the HMP UI CONTEXT
option. On 10/27/17, HMP will be shutdown. This ICR will be retired with an
expiration date of 10/27/17.\n
If HMP is reactivated in the future, the HMP project team will need to work
with the CPRS team to resolve this issue.\n
**********************************************************************", "ORWPCE SCSEL", "", ""], ["6467", "ORWRP COLUMN HEADERS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORWRP COLUMN HEADERS RPC
to get a list of column headers for a ListView type of report from file
101.24.", "ORWRP COLUMN HEADERS", "", "2016/11/07"], ["6468", "ORWRP3 EXPAND COLUMNS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the ORWRP3 EXPAND COLUMNS RPC
to load and expand nested reports defined in the OE/OR Reports file (#101.24)
for use in the eHMP User Interface (UI).", "ORWRP3 EXPAND COLUMNS", "", "2016/11/07"], ["6469", "ORWU EXTNAME", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/08/18", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the
ORWU EXTNAME RPC to get the external form of a pointer value given the IEN and
file number.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
HMP defect DE8431 was entered by the HMP project team to remove the ORWU
EXTNAME RPC from the HMP UI CONTEXT option. This defect was not resolved
before HMP was shut down on 10/27/17.\n
If HMP is reactivated in the future, the HMP project team will need to reopen
this defect to remove the RPC from the context option or ask CPRS for access
to the ORWU EXTNAME RPC.\n
**********************************************************************", "ORWU EXTNAME", "", ""], ["6470", "HMP CALL TO XHD GET PARAMETER DEF LIST", "Remote Procedure", "HEALTHEVET DESKTOP", "2016/08/18", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the XHD
GET PARAMETER DEF LIST RPC to retrieve all the parameter definitions as a list
with the IEN^NAME^DISPLAY NAME in each node of the return array.", "", "", ""], ["6471", "HMP CALL TO YTQ ALLKEYS RPC", "Remote Procedure", "MENTAL HEALTH", "2016/08/18", "", "Withdrawn", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) calls the YTQ
ALLKEYS RPC to retrieve a list of all security keys for a specified user.", "", "", ""], ["6472", "Get Designation ID for an Expression", "Routine", "LEXICON UTILITY", "2016/08/23", "", "Pending", "Supported", "", "", "", "LEXTRAN1", ""], ["6473", "ICR6473 - PROSTHETICS SERVICE", "File", "CONSULT/REQUEST TRACKING", "2016/08/23", "APPROVED", "Active", "Private", "123.5", "
VIA needs permission to read File #123.5, field #131 to
provide data to consuming applications.\n", "", "", "2017/02/28"], ["6474", "PATIENT APPOINTMENT", "File", "SCHEDULING", "2016/08/23", "", "Withdrawn", "Private", "44", "
VIA needs to read File #44, field #1900 (sub-file
#44.001) to provide data to consuming applications via a remote procedure call
(RPC).\n", "", "", ""], ["6475", "LIST ORDERS", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/23", "APPROVED", "Active", "Private", "100", "
VIA is using FileMan LIST^DIC and reading fields from
File #100 to provide data to consuming applications via VIAB BMS RPC.\n", "", "", "2016/11/14"], ["6476", "RESEARCH", "File", "LAB SERVICE", "2016/08/23", "APPROVED", "Active", "Private", "67.1", "
VIA needs to read File #67.1, fields .01, 9, 63 and the
"B" and "C" cross references to provide data to consuming applications via a
remote procedure call (RPC) VIAB EFR.\n", "", "", "2017/04/14"], ["6477", "HMP ACCESS TO AUPNVIMM", "File", "PCE PATIENT CARE ENCOUNTER", "2016/08/24", "", "Retired", "Controlled Subscription", "9000010.11", "
The Enterprise Health MGMT Platform (HMP) requests
access to do direct global reads of the V IMMUNIZATION FILE (#9000011.11). HMP
does a direct global read of the Immunization file in order to check to see if
the immunization for the visit has already been entered prior to entering a
new immunization for the visit. To do this HMP does a loop thru the
AUPNVIMM("AD" cross reference. If an entry is found in the AD cross reference,
then a check is made to compare the immunization and patient against the data
for the new entry. If a match is found, HMP doesn't add the immunization
record, otherwise a new immunization is added to the file for the patient's
visit.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
Discussions between PCE and HMP stopped after 12/21/16 and temporary approval
was not processed. Access to AUPNVIMM was found in ENC+18 in routine HMPWB5
and several places in routine HMPWBIM1 in Albany's DNS gold account.\n
If HMP is reactivated in the future, the HMP project team will need to work
with PCE developers to resolve this issue.\n
**********************************************************************", "", "", ""], ["6478", "NOTEVSTR", "File", "TEXT INTEGRATION UTILITIES", "2016/08/24", "APPROVED", "Active", "Private", "8925", "
VIA needs to read File fields #.07,.13,1207 and 1211 in
the TIU Document (#8925) file to provide data to consuming applications via a
remote procedure call (RPC) VIAB NOTEVSTR.", "", "", "2016/11/15"], ["6479", "VIA USE OF THE ORDERS FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "100", "
This documents the Vista Integration Adapter
application's use of the Orders file. The ICR will be used by VIAB MEDHIST RPC
and OrderMgmtSvc - getMedHistory service.\n", "", "", ""], ["6480", "VIAB USE OF 100.02 'C' INDEX", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "100.02", "
This documents the Vista Integration Adapter
application's use of the NATURE OF ORDER file.", "", "", ""], ["6481", "VIAB USE OF ORDER CHECK INSTANCES FILE (100.05)", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "100.05", "
This documents the Vista Integration Adapter
application's use of the ORDER CHECK INSTANCES file.", "", "", ""], ["6482", "VIAB USE OF OE/RR PATIENT EVENT FILE (100.2)", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "100.2", "
This documents the Vista Integration Adapter
application's use of the OE/RR PATIENT EVENT file.", "", "", ""], ["6483", "VIAB USE OF OE/RR RELEASE EVENTS FILE (100.5)", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "100.5", "
This documents the Vista Integration Adapter
application's use of the OE/RR RELEASE EVENTS file.", "", "", ""], ["6484", "VIAB USE OF DISPLAY GROUP FILE (100.98)", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "100.98", "
This documents the Vista Integration Adapter
application's use of the DISPLAY GROUP file. The ICR will be used by the
following RPCs and services.
VIAB MEDHIST OrderMgmtSvc - getMedHistory
VIAB IMTYPSEL OrderMgmtSvc - getImagingTypes\n", "", "", ""], ["6485", "VIAB USE OF THE ORDER DIALOG FILE (101.41)", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "101.41", "
This documents the Vista Integration Adapter
application's use of the ORDER DIALOG file. The ICR will be used by the
following RPCs and services.
VIABDPS2 OISLCT OrderMgmtSvc - getMedOrderableItemDefaults\n\n", "", "", ""], ["6486", "VIA USE OF ORDERABLE ITEMS FILE (101.43)", "File", "ORDER ENTRY/RESULTS REPORTING", "2016/08/25", "", "Withdrawn", "Private", "101.43", "
This documents the Vista Integration Adapter
application's use of the ORDERABLE ITEMS file. The ICR will be used by the
following RPCs and services.
VIAB LOAD OrderMgmtSvc - getLabTestSpecificParams
VIABDPS2 OISLCT OrderMgmtSvc - getMedOrderableItemDefaults
VIAB IMTYPSEL OrderMgmtSvc - getImagingTypes\n", "", "", ""], ["6487", "VIAB READ DPT(D0,0) - FULL SUBSCRIPT", "File", "REGISTRATION", "2016/08/25", "APPROVED", "Active", "Private", "2", "\n\n
This documents the Vista Integration Adapter application's use of the PATIENT
file.", "", "", "2016/11/10"], ["6488", "HMP READ FOR SECONDARY VISIT", "File", "TEXT INTEGRATION UTILITIES", "2016/08/29", "APPROVED", "Retired", "Private", "8925", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Then Enterprise Health MGMT Platform (HMP) requests permission to do a FileMan
read of the TIU DOCUMENT FILE (#8925) to retrieve the SECONDARY VISIT field
(#1207) in order to pass the Visit Pointer into a call to ENCEVENT^PXAPI to
retrieve the visit information.", "", "", "2016/08/30"], ["6489", "HMP ACCESS TO CLINDOC~TIUCL1", "Routine", "TEXT INTEGRATION UTILITIES", "2016/09/12", "APPROVED", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) is calling
the CLINDOC^TIUCL1 API in order to retrieve the Clinical Document subclass for
a specified document type.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "TIULC1", "2016/09/14"], ["6490", "HMP CALL TO GETFREQ~ORWLEX", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2016/09/12", "", "Retired", "Controlled Subscription", "", "
The Enterprise Health MGMT Platform (HMP) requests
temporary approval to call GETFREQ^ORWLEX to check the frequency of use of
keywords contained in a search string. In patch HMP*2.0*2, HMP makes a call
the call to GETFREQ^ORWLEX. After reviewing the code, HMP is changing this
call to call the FREQ^LEXU API directly.", "", "ORWLEX", ""], ["6491", "PERSON CLASS file (#8932.1) maint.", "File", "KERNEL", "2016/09/15", "", "Pending", "Private", "8932.1", "
As part of the VHA standardization of VistA files the
PERSON CLASS file (#8932.1) will be passed to the Standards & Terminology
Services Team (STS) for maintenance of data. This will happen with the
release of patch XU*8.0*671. This is for file data maintenance only. The
PERSON CLASS file (#8932.1) will remain within the KERNEL names/number space.\n
Lexicon Utility has all privileges as though it were the custodial package.", "", "", ""], ["6492", "HOME OXYGEN TRANSACTIONS FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "665.72", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests permission to
check for the existence of the "AC" cross reference of the
^RMPO(665.72 file.", "", "", "2020/07/30"], ["6493", "EQUIPMENT INV. FILE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914", "
Above PAR requests permission to write to the
ENGINEERING FILE #6914 to record additions and edits of Equipment Inventory
data. Above PAR also reads data from this file to display Equipment Inventory
data in both the Equipment and Work Order functions.\n
Above PAR Ad-Hoc Reporting includes the ENGINEERING FILE #6914. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2022/09/12"], ["6494", "WORK ORDER # FILE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "6920", "
Above PAR requests permission to write to the WORK
ORDER FILE #6920 to record additions, deletions and edits of Work Order data.
Above PAR also reads data from this file to display Work Order data in both
the Equipment and Work Order functions. The Advanced Prosthetics Acquisition
Tool (APAT) reads from the Work Order (#6920) file when a detailed purchase
card order is being created.\n
Above PAR Ad-Hoc Reporting includes the WORK ORDER FILE #6920. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2019/09/12"], ["6495", "TURN-IN REQUEST FILE ACCESS", "File", "EQUIPMENT/TURN-IN REQUEST", "2016/10/17", "APPROVED", "Active", "Private", "413.1", "
Above PAR requests permission to write to the TURN-IN
REQUEST FILE #413.1 to record additions, edits and deletions of Turn-In
Requests. Above PAR also reads data from this file to display Turn-In
information within the Equipment function.\n
Above PAR Ad-Hoc Reporting includes the TURN-IN REQUEST FILE #413.1. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2020/07/31"], ["6496", "RECORD OF PROSTHETIC APPLIANCE/REPAIR FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "660", "\n
The Advanced Prosthetics Acquisition Tool (APAT) reads from the RECORD
OF PROS APPLIANCE/REPAIR (#660) when displaying appliance transactions
on the 2319 tab and when extracting appliance data to SQL Server to
determine if duplicate appliances have been purchased for a patient.
When creating a Prosthetic 1358, a 2529-3, a GIP or PIP Stock Issue,
and when adding a cancellation note to a Prosthetic Suspense, APAT
writes to the RECORD OF PROS APPLIANCE/REPAIR (#660) in order to record
the purchase/issue on the patient's 2319. APAT also allows for the
editing of specific fields in the RECORD OF PROS APPLIANCE/REPAIR
(#660).\n
During reconciliation and close out, APAT stores the shipment date
(DATE OF SERVICE (#39)) of each 2319 entry associated with a purchase
card order.\n
Amendment - Effective 4/14/23, The Advanced Prosthetics Acquisition Tool
(APAT) requests changes in the types of access for the following fields in the
RECORD OF PROS APPLIANCE/REPAIR (#660) file. Direct global reads of fields
are requested to prevent VistA timeouts when reports are produced or grids are
filled.\n
Amendment (requested 1/23/24) - The Advanced Prosthetics Acquisition Tool
(APAT) requests changes in the types of access for the indicated fields in the
RECORD OF PROS APPLIANCE/REPAIR (#660) file. Direct global reads of the
indicated fields are requested to prevent VistA timeouts when reports and
lists are generated. The requested direct global reads have existed in APAT
since it was released in 2019.", "", "", "2024/02/01"], ["6497", "EQUIPMENT CATEGORY FILE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6911", "
Above PAR requests permission to read the EQUIPMENT
CATEGORY FILE #6911 to display EQUIPMENT CATEGORY information within the
Equipment function.\n
Above PAR Ad-Hoc Reporting includes the EQUIPMENT CATEGORY FILE #6911. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2019/09/12"], ["6498", "CMR FILE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914.1", "
Above PAR requests permission to read from the CMR FILE
#6914.1 to display CMR/EIL information within the Equipment and Work Order
functions.\n
Above PAR Ad-Hoc Reporting includes the CMR FILE #6914.1. Ad-Hoc functionality
provides the ability to select fields from the file for display on
user-defined reports. Ad-Hoc offers only FileMan read access and only if the
user has permission to view the file.", "", "", "2022/09/06"], ["6499", "PM PROCEDURES ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914.2", "
Above PAR requests permission to read from the PM
PROCEDURES FILE #6914.2 to display PM Procedure Information within the
Equipment function.", "", "", "2019/09/12"], ["6500", "PROS RETURNED/CONDEMNED FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "660.1", "
The Advanced Prosthetics Acquisition Tool (APAT) reads
the PROS RETURNED CONDEMNED File (#660.1) when displaying 2319 appliance
transactions including HISA and Home Oxygen.\n
APAT also writes to the PROS RETURNED CONDEMNED file (#660.1) when an
appliance transaction in the RECORD OF PROS APPLIANCE/ REPAIR file (#660) is
returned or condemned. A PROS RETURNED CONDEMNED item may be edited or
deleted as well.\n
As is done in Prosthetics, APAT accesses fields undefined in the file using
direct reads:
File 660.1 node 0 ^-piece 9
File 660.1 node 0 ^-piece 10", "", "", "2017/01/20"], ["6501", "NX SGL ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914.3", "
Above PAR requests permission to read from the NX SGL
File #6914.3 to display Standard General Ledger information within the
Equipment function.", "", "", "2019/09/12"], ["6502", "NX BOC FILE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914.4", "
Above PAR requests permission to read from the NX BOC
FILE #6914.4 to display BOC information within the Equipment function.", "", "", "2019/09/12"], ["6503", "NX FUND ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914.6", "
Above PAR requests permission to read from the NX FUND
File #6914.6 to display FUND information within the Equipment function.", "", "", "2019/09/12"], ["6504", "PROS ITEM MASTER FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "661", "
The PROS ITEM MASTER (#661) File is read when creating
a GIP Stock Issue, a Prosthetic purchase card order, an OWL (Orthotic and Lab
Work Order), and when displaying 2319 appliance transactions. Also, new
Prosthetic Item Master items may be added or revised in inventory processing
in Above PAR. This file is accessed as well when various reports are produced
and grids are filled.", "", "", "2023/04/14"], ["6505", "NX A/O ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914.7", "
Above PAR requests permission to read from the NX A/O
File #6914.7 to display Accounting Office information within the Equipment
function.", "", "", "2019/09/12"], ["6506", "PROSTHETIC HCPCS FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "661.1", "
The PROSTHETIC HCPCS FILE #661.1 is read when creating
a GIP Stock Issue, creating a Prosthetics purchase card order, displaying 2319
appliance transactions, and producing the PFFS and NPPD lists. It is also
used when extracting 2319 data for determination of duplicate appliance
transactions issued to a patient. In inventory processing, this file is read
and written to when an Item Master item is associated with a HCPCS via the
Synonym field.\n
Above PAR Ad-Hoc Reporting includes the PROSTHETIC HCPCS FILE #661.1. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2021/04/13"], ["6507", "NX DISPOSITION METHOD ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6914.8", "
Above PAR requests permission to read from the NX
DISPOSITION METHOD File #6914.8 to display information within the Equipment
and Turn-In functions.", "", "", "2022/09/06"], ["6508", "AV REASON ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6915.11", "
Above PAR requests permission to read from the AV
REASON File #6915.11 to display information within the Equipment function.", "", "", "2019/09/12"], ["6509", "PROS DISABILITY CODE FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "662", "
The Advanced Prosthetics Acquisition Tool (APAT) reads
the PROS DISABILITY CODE File (#662) when adding disability codes to a patient
and to display those disability codes on the 2319.", "", "", "2020/07/30"], ["6510", "PROSTHETICS 1358 FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "664", "
The Advanced Prosthetics Acquisition Tool (APAT) writes
to the PROSTHETIC 1358 File (#664) to record the creation of a Prosthetic
purchase card order, to delete a specific PROSTHETIC 1358 record, and to read
the PROSTHETIC 1358 file to display the Prosthetic 1358.", "", "", "2019/09/10"], ["6511", "FA DOCUMENT LOG ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6915.2", "
Above PAR requests permission to read from the FA
DOCUMENT LOG File # 6915.2 to display information within the Equipment
function.", "", "", "2022/09/07"], ["6512", "CATEGORY STOCK NUMBER FILE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6917", "
Above PAR requests permission to read from the CATEGORY
STOCK NUMBER FILE #6917 to display information within the Equipment function.", "", "", "2019/09/12"], ["6513", "UTILITY SYSTEMS ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6918.1", "
Above PAR requests permission to read from the UTILITY
SYSTEMS File #6918.1 to display information within the Equipment function.", "", "", "2019/09/12"], ["6514", "NEW WORK ACTION ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6920.1", "
Above PAR requests permission to read from the NEW WORK
ACTION File #6920.1 to display information within the Work Order module.", "", "", "2022/09/07"], ["6515", "ENGINEERING SECTION LIST ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6922", "
Above PAR requests permission to read from the
ENGINEERING SECTION LIST File #6922 to display information within the Work
Order function.", "", "", "2022/09/07"], ["6516", "ENG SPACE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6928", "
Above PAR requests permission to read from the ENG
SPACE File #6928 to display information within the Equipment and Work Order
functions.", "", "", "2022/09/06"], ["6517", "ENG EMPLOYEE ACCESS", "File", "ENGINEERING", "2016/10/17", "APPROVED", "Active", "Private", "6929", "
Above PAR requests permission to read from the ENG
EMPLOYEE File #6929 to display information with in the Work Order function.", "", "", "2022/09/06"], ["6518", "REPETITIVE ITEM LIST ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Under Revision", "Private", "410.3", "
Above PAR requests permission to write to the
REPETITIVE ITEM LIST File #410.3 to record additions and edits of Repetitive
Item Requests within the Inventory function.", "", "", "2022/02/17"], ["6519", "COUNTER FILE ACCESS", "File", "EQUIPMENT/TURN-IN REQUEST", "2016/10/17", "APPROVED", "Active", "Private", "413.7", "
Above PAR requests permission to write to the COUNTER
FILE #413.7 to create temporary transaction numbers for turn-in requests.\n
Above PAR Ad-Hoc Reporting includes the COUNTER FILE #413.7. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2020/07/31"], ["6520", "PURCHASE ORDER STATUS ACCESS", "File", "IFCAP", "2016/10/17", "", "Withdrawn", "Controlled Subscription", "442.3", "
Above PAR requests permission to read from the PURCHASE
ORDER STATUS File #442.3 to display information within the Inventory function.\n
APAT reads from the PURCHASE ORDER STATUS (#442.3) file to determine the
status of a purchase card order.", "", "", ""], ["6521", "SIC CODE FILE ACCESS", "File", "IFCAP", "2016/10/17", "", "Withdrawn", "Private", "444.2", "
Above PAR requests permission to read from the SIC CODE
File #444.2 to display information within the Inventory function.", "", "", ""], ["6522", "INTERNAL DISTRIBUTION ORDER/ADJ. ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Private", "445.3", "
Above PAR requests permission to read and write to the
INTERNAL DISTRIBUTION ORDER/ADJ. FILE #445.3 to display and record
Distribution Orders within the Inventory function.\n
Above PAR Ad-Hoc Reporting includes the INTERNAL DISTRIBUTION ORDER/ADJ FILE
#445.3. Ad-Hoc functionality provides the ability to select fields from the
file for display on user-defined reports. Ad-Hoc offers only FileMan read
access and only if the user has permission to view the file.", "", "", "2022/02/17"], ["6523", "AUTOMATED SUPPLY STATIONS ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Private", "445.5", "
Above PAR requests permission to read from the
AUTOMATED SUPPLY STATIONS File #445.5 to validate that the Automated Supply
Station is defined.\n
Permission is also requested in order to: 1. Retrieve the value of the
INVENTORY UPDATES field for use in logic for populating the Item Name subfield
the HL7 message's RQD segment.\n
2. Retrieve the value of the LINK NAME for use in specifying the link over
which the HL7 message will be sent to the Supply Station's database.", "", "", "2018/12/07"], ["6524", "GROUP CATEGORY FILE ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Private", "445.6", "
Above PAR requests permission to read and write to the
GROUP CATEGORY FILE #445.6 to display, add, edit, and delete GROUP CATEGORY
entries.\n
Above PAR Ad-Hoc Reporting includes the GROUP CATEGORY FILE #445.6. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2022/03/04"], ["6525", "INVENTORY DISTRIBUTED PATIENT SUPPLIES ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Private", "446.1", "
Above PAR requests permission to read and write to the
INVENTORY DISTRIBUTED PATIENT SUPPLIES FILE #446.1 to display and edit the
inventory point within the file if a Distribution Order is posted with patient
supplies.\n
Above PAR Ad-Hoc Reporting includes the INVENTORY DISTRIBUTED PATIENT SUPPLIES
FILE #446.1. Ad-Hoc functionality provides the ability to select fields from
the file for display on user-defined reports. Ad-Hoc offers only FileMan read
access and only if the user has permission to view the file.", "", "", "2018/03/26"], ["6526", "BARCODE PROGRAM FILE ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Private", "446.4", "
Above PAR requests permission to read and write to the
BARCODE PROGRAM File #446.4 to record and display uploads from the Bar Code
Reader.", "", "", "2022/03/04"], ["6527", "CUSTOM LABEL FILE ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Private", "446.5", "
Above PAR requests permission to read from the CUSTOM
LABEL File # 446.5 to display information within the Inventory function.", "", "", "2018/03/26"], ["6528", "INVENTORY LOCK MANAGEMENT", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Private", "447", "
Above PAR requests permission to read and write to the
INVENTORY LOCK MANAGEMENT File #447 to display and update the Lock management
information within the Inventory function.", "", "", "2018/03/26"], ["6529", "INSTALL FILE ACCESS", "File", "KERNEL", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "9.7", "
Above PAR and Advanced Prosthetics Acquisition Tool
request permission to read from the INSTALL FILE (#9.7) to display information
about the last install within the Administrator function.", "", "", "2023/07/11"], ["6530", "VENDOR FILE ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "440", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request permission to read from the VENDOR FILE #440 to display
information within the Equipment, Work Order and Inventory functions and when
creating and displaying purchasing documents. Above PAR also updates the
VENDOR (#440) File.\n
Above PAR Ad-Hoc Reporting includes the VENDOR FILE #440. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2023/03/30"], ["6531", "ITEM MASTER FILE ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "441", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request permission to add, edit, and display ITEM MASTER FILE #441
data.\n
Above PAR adds, edits, and displays items in the ITEM MASTER FILE #441 as part
of its Inventory functionality. Above PAR Ad-Hoc Reporting provides the
ability to select fields from the file for display on user-defined reports.
Ad-Hoc offers only FileMan read access and only if the user has permission to
view the file.\n
The Advanced Prosthetics Acquisition Tool (APAT) reads from the ITEM MASTER
FILE #441 when creating patient-centric purchase card orders, detailed
purchase card orders, and GIP and PIP stock issues as well as when displaying
Prosthetic appliance transaction information on the 2319. The detailed
purchase card order functionality also performs FileMan writes to specified
fields of the ITEM MASTER #441 as each item is added to the order.", "", "", "2023/01/12"], ["6532", "FEDERAL SUPPLY CLASSIFICATION ACCESS", "File", "IFCAP", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "441.2", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request permission to read from the FEDERAL SUPPLY CLASSIFICATION File
(#441.2) to display information within the Inventory and Create Detailed
Purchase Card Order functionality.", "", "", "2023/04/28"], ["6533", "PROS AMIS CODES FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Controlled Subscription", "663", "
The PROS AMIS CODES (#663) File is read during
inventory processing in order to present valid AMIS Codes based on the
Issue/Repair Code.", "", "", "2019/09/10"], ["6534", "PROSTHETIC 2529-3 FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "664.1", "
The PROSTHETIC 2529-3 File (#664.1) is written to and
read during the creation, revision, and display of an Orthotics Lab Work Order
(OWL).", "", "", "2019/09/10"], ["6535", "PROSTHETIC WORK ORDER FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "664.2", "
The Advanced Prosthetics Acquisition Tool (APAT)
creates, updates, deletes, and displays records in the PROSTHETIC WORK ORDER
File (#664.2) during Orthotics Lab Work Order (OWL) functionality.", "", "", "2019/09/10"], ["6536", "PROSTHETIC LAB HOURS DATE FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "664.3", "
The Advanced Prosthetics Acquisition Tool (APAT)
accesses the PROSTHETIC LAB HOURS DATE File (#664.3) during the creation,
revision, and display of an Orthotics Lab Work Order (OWL).", "", "", "2019/09/10"], ["6537", "PROSTHETICS PATIENT FILE ACCESS", "File", "PROSTHETICS", "2016/10/17", "APPROVED", "Active", "Private", "665", "
In the Advanced Prosthetics Acquisition Tool (APAT),
the PROSTHETICS PATIENT File (#665) is written to during the addition of
Prosthetic patients and when Prosthetic disability codes are
added/edited/deleted/displayed. The file is read during the location of
prosthetic patients, the creation of GIP Stock Issues, 2319 processing
(including critical comments, patient demographics, appliance transactions
(including HISA and Home Oxygen)), the creation of Orthotic Lab Work Orders
(OWLs), and during suspense processing.", "", "", "2020/07/30"], ["6538", "PROS LETTER FILE ACCESS", "File", "PROSTHETICS", "2016/10/18", "APPROVED", "Active", "Private", "665.2", "
In the Advanced Prosthetics Acquisition Tool (APAT),
the PROS LETTER File (#665.2) is read during the Create RFQ (Request for
Quote/10-90) process to validate and display Pros Letter Types.", "", "", "2023/04/13"], ["6539", "PROS LETTER TRANSACTIONS FILE ACCESS", "File", "PROSTHETICS", "2016/10/18", "APPROVED", "Active", "Private", "665.4", "
The Advanced Prosthetics Acquisition Tool (APAT) writes
to the PROS LETTER TRANSACTIONS File (#665.4) when creating a Request for
Quote (RFQ, 10-90), and it is read when displaying an RFQ/10-90 or any other
Prosthetic Letter.", "", "", "2023/04/14"], ["6540", "PROSTHETIC SUSPENSE FILE ACCESS", "File", "PROSTHETICS", "2016/10/18", "APPROVED", "Active", "Controlled Subscription", "668", "
The PROSTHETIC SUSPENSE (#668) File is read and written
to in order to create cloned suspense items or to add initial action, other,
cancellation, and completion notes.", "", "", "2023/04/14"], ["6541", "PROSTHETIC LAB W.O. # FILE ACCESS", "File", "PROSTHETICS", "2016/10/18", "APPROVED", "Active", "Private", "669.1", "
The Advanced Prosthetics Acquisition Tool (APAT)
accesses the PROSTHETIC LAB W.O. # File (#669.1) to determine the last work
order number used. When creating a work order, the LAST NUMBER USED field is
incremented for the STATION, YEAR, and QUARTER.", "", "", "2023/04/14"], ["6542", "PROSTHETIC SITE PARAMETERS FILE ACCESS", "File", "PROSTHETICS", "2016/10/18", "APPROVED", "Active", "Private", "669.9", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) accesses the PROSTHETIC SITE PARAMETERS File (#669.9) to obtain details
about a given Prosthetics site. This file is written to in order to maintain
the GROUPER COUNTER (#11).", "", "", "2020/07/30"], ["6543", "DISPLAY PRIVACY STATEMENT", "Routine", "PROSTHETICS", "2016/10/18", "", "Pending", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call routine RMPR9P23 in order to
display the current privacy statement as the last page of a Prosthetics
purchase card order.", "", "RMPR9P23", ""], ["6544", "RETURN PRIVACY STATEMENT", "Routine", "PROSTHETICS", "2016/10/18", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call routine RMPRP23 in order to return
the current privacy statement for display as the last page of Prosthetics
purchase card order.", "", "RMPRP23", "2018/02/05"], ["6545", "CHECK CPT MODIFIER FOR STOCK ISSUE", "Routine", "PROSTHETICS", "2016/10/18", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call CHK^RMPRED5 to check for Source
and Type of Transaction changes to the CPT Modifier when creating a Generic
Inventory Program Stock Issue.", "", "RMPRED5", "2017/11/14"], ["6546", "FIRST DATE OF QUARTER", "Routine", "IFCAP", "2016/10/18", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call IFCAP routine PRC0D. This
extrinsic function returns the first date of the specified quarter.", "", "PRC0D", "2019/06/07"], ["6547", "GENERIC INVENTORY FILE ACCESS", "File", "IFCAP", "2016/10/18", "APPROVED", "Active", "Controlled Subscription", "445", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request permission to read and write to the GENERIC INVENTORY FILE #445
to display and edit both Distribution Points and Items within a Distribution
Point within the Inventory function. Inventory levels are also adjusted by
the APAT stock issue and edit 2319 functionality. Above PAR will address the
conversion of a secondary to a primary in a future version.\n
Above PAR Ad-Hoc Reporting includes the GENERIC INVENTORY FILE #445. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2022/03/04"], ["6548", "INVENTORY TRANSACTION FILE ACCESS", "File", "IFCAP", "2016/10/18", "APPROVED", "Active", "Controlled Subscription", "445.2", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request permission to read and write to the INVENTORY TRANSACTION FILE
#445.2 to update Inventory Transactions within the Inventory and Stock Issue
functionality.\n
Above PAR Ad-Hoc Reporting includes the INVENTORY TRANSACTION FILE #445.2.
Ad-Hoc functionality provides the ability to select fields from the file for
display on user-defined reports. Ad-Hoc offers only FileMan read access and
only if the user has permission to view the file.", "", "", "2019/06/07"], ["6549", "STORAGE LOCATION ACCESS", "File", "IFCAP", "2016/10/18", "APPROVED", "Active", "Controlled Subscription", "445.4", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request permission to read and write to the STORAGE LOCATION FILE
#445.4 to maintain a master list of storage locations within the Inventory
function.\n
Above PAR Ad-Hoc Reporting includes the STORAGE LOCATION FILE #445.4. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2021/11/18"], ["6550", "FMS DOCUMENTS FOR SUPPLY FUND SPECIAL CTL PT", "Routine", "IFCAP", "2016/10/18", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call IFCAP routine PRCFFMO.", "", "PRCFFMO", "2019/07/02"], ["6551", "CREATE 2237 FOR NEW PURCHASE CARD ORDER", "Routine", "IFCAP", "2016/10/18", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call IFCAP routine PRCH410 to create
the 2237 record, record the electronic signature, and update due-ins.", "", "PRCH410", "2018/11/21"], ["6552", "CHECKSUM GENERATION", "Routine", "IFCAP", "2016/10/18", "APPROVED", "Active", "Private", "", "
The Advanced Prosthetics Acquisition Tool (APAT)
requests access to IFCAP checksum generation.", "", "PRCUESIG", "2019/06/07"], ["6553", "REFORMAT WORD PROCESSING VALUE", "Routine", "IFCAP", "2016/10/18", "APPROVED", "Active", "Private", "", "
The Advanced Prosthetics Acquisition Tool (APAT) uses
the IFCAP Word Processing Reformatting utility.", "", "PRCUTL", "2019/06/07"], ["6554", "VISTA PARAMETER HANDLING", "Routine", "TOOLKIT", "2016/10/18", "", "Withdrawn", "Private", "", "
The Logistics and Prosthetics Suite cloned certain XPAR
functionality into its native DSIY namespace.", "", "XPAR1", ""], ["6555", "IFCAP FCP ACCOUNTING INFORMATION", "Routine", "IFCAP", "2016/10/18", "APPROVED", "Active", "Controlled Subscription", "", "
The Advanced Prosthetics Acquisition Tool (APAT) and
Above PAR use extrinsic functions in PRC0C to retrieve fund control point
parameters and to convert calendar dates to Fiscal Year and Fiscal Quarter.
This data is used during the creation and display of detailed purchase card
orders.", "", "PRC0C", "2019/06/07"], ["6556", "POST PM HOUR TO FILE 6922", "Routine", "ENGINEERING", "2016/10/25", "", "Pending", "Private", "", "
This integration agreement allows Above PAR to call
COUNT^ENBCPM8 to update Preventive Maintenance hours within a Work Order in
File #6922 and call UNPOST^ENBCPM8 to unpost Preventive Maintenance hours with
a Work Order in File #6922.", "", "ENBCPM8", ""], ["6557", "UNPOST/REMOVE PM HOURS FROM FILE 6922", "Routine", "ENGINEERING", "2016/10/25", "", "Withdrawn", "Private", "", "", "", "ENBCPM8", ""], ["6558", "TRANSMIT EQUIPMENT BULLETIN", "Routine", "ENGINEERING", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows Above PAR to call
BULL^ENEQ3 to transmit an equipment bulletin whenever a new piece of equipment
is added - if a mail group is established.", "", "ENEQ3", "2019/07/23"], ["6559", "UPDATE EQUIPMENT PM PARAMETERS", "Routine", "ENGINEERING", "2016/10/25", "", "Pending", "Private", "", "
This integration agreement allows Above PAR to call
PMSE3^ENEQPMP to copy Preventive Maintenance parameters from the Equipment
Category File to the Equipment Inventory File.", "", "ENEQPMP", ""], ["6560", "EXTRACT PM HOURS FROM WORK ORDER", "Routine", "ENGINEERING", "2016/10/25", "", "Pending", "Private", "", "
This integration agreement allows Above PAR to call
PMHRS^ENEQPMR4 to extract the Preventive Maintenance Hours from a work order
and provide a total back to the calling routine.", "", "ENEQPMR4", ""], ["6561", "MAINTAIN FA DOCUMENT LOG", "Routine", "ENGINEERING", "2016/10/25", "", "Pending", "Private", "", "
This integration agreement allows Above PAR to call
ENFAACQ for FA Code Sheet processing.", "", "ENFAACQ", ""], ["6562", "CHECK EQUIPMENT FAP STATUS", "Routine", "ENGINEERING", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows Above PAR to call
CHKFA^ENFAUTL to check the current FAP status for a piece of equipment.", "", "ENFAUTL", "2019/07/23"], ["6563", "PURCHASE ORDERS: FIND AMENDMENTS", "Routine", "IFCAP", "2016/10/25", "", "Pending", "Private", "", "
This integration agreement allows the call
START^PRCHDP5 to retrieve for subsequent display what changes were made by a
specified amendment to a purchase order.", "", "PRCHDP5", ""], ["6564", "PURCHASE ORDER: SET UP AMENDMENT HISTORY", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
AMENDS^PRCHDP6 to set up a ^TMP($J,"PRCHDP6" temp file with the amendment
history for a purchase order.", "", "PRCHDP6", "2019/07/02"], ["6565", "PURCHASE ORDER: E-SIGNATURE ON RECEIVING PARTIAL", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This is called to encode the e-signature on the PARTIAL
entry during receipt into inventory.", "", "PRCHES2", "2019/06/07"], ["6566", "PURCHASE ORDER: RETURN FACILITY TYPE", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
FTYP^PRCHFPNT to return the free-text facility type for a purchase order.", "", "PRCHFPNT", "2019/07/02"], ["6567", "PURCHASE ORDER: RETURN EDI STATUS", "Routine", "IFCAP", "2016/10/25", "", "Withdrawn", "Private", "", "
This integration agreement allows the call
EDISTAT^PRCHUTL to determine the EDI status of a purchase order.", "", "PRCHUTL", ""], ["6568", "REPETITIVE ITEM LIST - ADD OR DELETE ITEMS", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the calls to
$$ADDITEM^PRCPAGPR which adds to REPETITIVE ITEM LIST (RIL) (#410.3), to
$$NEWRIL^PRCPAGPR which creates new RIL items, and to DELRIL^PRCPAGPR which
deletes RIL items.", "", "PRCPAGPR", "2019/06/07"], ["6569", "DELETE TEMP STOCK LEVEL", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
DELTEMP^PRCPAGU1 to delete the temporary stock level in the Generic Inventory
File ^PRCP(445).", "", "PRCPAGU1", "2019/06/07"], ["6570", "INVENTORY: BUILD HL7 FOR ITEM DELETION", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
BLDSEG^PRCPHLFM which builds an HL7 segment whenever a secondary inventory
item is deleted.\n
This updates the inventory in the automated supply stations.", "", "PRCPHLFM", "2019/06/07"], ["6571", "DISTRIBUTION ORDER: SEND ORDER DELETED MESSAGE", "Routine", "IFCAP", "2016/10/25", "", "Pending", "Private", "", "
This integration agreement allows the call
MESSAGE^PRCPOPD which sends the user a message if a Distribution Order is
deleted.", "", "PRCPOPD", ""], ["6572", "DISTRIBUTION ORDER: ITEM CHECK", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
$$ITEMCHK^PRCPOPER to check items within a distribution order.", "", "PRCPOPER", "2019/06/07"], ["6573", "DISTRIBUTION ORDER: POSTING", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the following calls:
RECEIPT^PRCPOPPP to Receive Items at a Secondary Distribution Point
SALE^PRCPOPPP to Disburse Items from a Primary Distribution Point These
calls are used when a Distribution Order is Posted within the Inventory
function.", "", "PRCPOPPP", "2019/06/07"], ["6574", "DISTRIBUTION ORDER: CREATE NEW ORDER", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the following calls:
NEWORDER^PRCPOPUS to get the next Order # available
$$ADDNEW^PRCPOPUS to create the new order in ^PRCP(445.3) This extrinsic
function is used when creating a new Distribution Order in the Inventory
function.", "", "PRCPOPUS", "2019/06/07"], ["6575", "INVENTORY: DELETE ITEM, UPDATE CODESHEET", "Routine", "IFCAP", "2016/10/25", "", "Withdrawn", "Private", "", "
This integration agreement allows Above PAR to call
CODESHT^PRCPSMGO to update the Code Sheet if deleting the item from a
Warehouse.", "", "PRCPSMGO", ""], ["6576", "INVENTORY: DELETE ITEM, GET DELETE SEGMENT", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
DELETE^PRCPSMS0 to get segments needed to delete an item from the Supply Fund
Warehouse inventory point.", "", "PRCPSMS0", "2019/06/07"], ["6577", "INVENTORY: UPDATE ITEM BALANCE", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration allows the following calls:\n
BALANCE^PRCPUBAL in order to file in the INVENTORY BALANCE file (#445.1) the
beginning monthly balances for an item in that inventory point.\n
$$GETOPEN^PRCPUBAL to obtain an Inventory item's current inventory point
balance.", "", "PRCPUBAL", "2019/06/07"], ["6578", "DISTRIBUTION ORDER: RECEIVE AND UPDATE COST CENTER", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
COSTCNTR^PRCPUCC to create the initial year_month/cost_center/inventory_point
entry in the DISTRIBUTION /USAGE HISTORY file (#446) or update the entry's
total cost field's value when an issue book or internal distribution order is
received by an inventory point.", "", "PRCPUCC", "2019/06/07"], ["6579", "DISTRIBUTION ORDER: INVENTORY ITEM DELETION", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
DELITEM^PRCPUITM to delete the item from the inventory point and any supply
station that was linked to that (secondary) inventory point during an AutoGen
process when the item is flagged as KILL WHEN ZERO. The call to DELITEM is a
sub-process of DSIYGO01 (cloned PRCPAGP1 process) and DSIYGO07 (cloning
PRCPAGS1 process).", "", "PRCPUITM", "2019/06/07"], ["6580", "INVENTORY: SCREEN VENDOR FOR ITEM", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
SCREEN^PRCPUMAN to screen selection of source vendor when adding to an Item
within a Distribution Point.", "", "PRCPUMAN", "2019/07/02"], ["6581", "DISTRIBUTION ORDER: CREATE PATIENT ENTRY", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
$$PATIENT^PRCPUPAT() to create an entry in the INVENTORY DISTRIBUTED PATIENT
SUPPLIES file (#446.1) during posting of the distribution order if it includes
patient supplies.", "", "PRCPUPAT", "2019/06/07"], ["6582", "INVENTORY: BARCODE UPDATE", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
$$UPDATE^PRCPUSA() to update Distribution Points when reading data from a bar
code scanner.", "", "PRCPUSA", "2018/08/15"], ["6583", "INVENTORY - UPDATE ITEM RECEIPT HISTORY RECEIPTS", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
RECEIPTS^PRCPUSAG to update the Inventory Item's Receipts History in the
Generic Inventory file (#445) Receipts History By Item subfile (#445.06) when
a replenishment order is received into a Distribution Point.\n
NOTE: Although the order for Primary Inventory Points would be a Purchase
Order, for Secondary Inventory Points, the order would be a Distribution
Order. (If sites were operating a Supply Fund Warehouse, the order for
Primary Inventories would be either Issue Book for receipt from Warehouse or
Purchase Order for receipt from external vendor.)", "", "PRCPUSAG", "2019/06/07"], ["6584", "INVENTORY: UPDATE QTY ORD'D,DUE-IN,OR DEL OUTSTANDING REQST", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the following calls:
KILLTRAN^PRCPUTRA to kill any outstanding transactions
OUTST^PRCPUTRA to add Quantity to outstanding transactions", "", "PRCPUTRA", "2019/06/07"], ["6585", "INVENTORY: GET INVENTORY TRANSACTION # & CREATE TRANS", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows these calls:
ADDTRAN^PRCPUTRX to add a transaction entry to the Transaction Register
^PRCP(445.2) to record a received Purchase Order, Distribution Order, or
Issue Book\n
$$ORDERNO^PRCPUTRX() to receive a new transaction entry #", "", "PRCPUTRX", "2019/06/07"], ["6586", "INVENTORY: BARCODE PRINT", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call EN^PRCTLAB
to print Bar Code labels.", "", "PRCTLAB", "2018/11/21"], ["6587", "INVENTORY: BARCODE TASKMAN REQUEST", "Routine", "IFCAP", "2016/10/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
TASK^PRCTREAD to create the TaskMan process to run entry points in routine
PRCPBALM to update the inventory counts or calculate inventory usage based on
the data uploaded from the barcode reader after barcode scanning inventory
stock.", "", "PRCTREAD", "2018/08/27"], ["6588", "DISTRIBUTION ORDER: NEW DOCUMENT ID", "Routine", "IFCAP", "2016/10/25", "", "Withdrawn", "Private", "", "
This integration agreement allows the call
EN1^PRCUTL1(.X) to either add a new entry in the Transaction Number file
(#410.1) or to update the value in the COUNTER field (#1) of an existing entry
of this file of counters. This call gets a new Document ID. The stub of the
transaction number is set into a variable which is passed by reference to the
API. After the call, the assigned transaction number is passed back in that
variable.", "", "PRCUTL1", ""], ["6589", "PURCHASE ORDER: UPDATE DRUG ACCOUNTABILITY", "Routine", "DRUG ACCOUNTABILITY", "2016/10/25", "", "Pending", "Private", "", "
This integration agreement permits the following
programming calls:
EN^PSAGIP to set up information to pass to Drug Accountability.
EX^PSAGIP to set up the TaskMan job to pass information.", "", "PSAGIP", ""], ["6590", "RIL: UPDATE DELIVERY ORDER ITEM FIELD", "Routine", "IFCAP", "2016/10/27", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call
CHECK^PRCSRIE1 to update for a given REPETITIVE ITEM LIST file (#410.3) item
entry, the DELIVER ORDER ITEM field (#5) the based on whether that item is
under contract for the assigned vendor.", "", "PRCSRIE1", "2019/06/07"], ["6591", "GUI PURCHASE CARD PROS ORDER INTERFACE", "Routine", "IFCAP", "2016/10/28", "APPROVED", "Active", "Private", "", "
The Advanced Prosthetics Acquisition Tool (APAT) uses
the existing IFCAP GUI interface to create Prosthetic Purchase Card Orders.", "", "PRCH7PUC", "2019/06/07"], ["6592", "PURCHASE ORDER NUMBER RETRIEVAL", "Routine", "IFCAP", "2016/10/28", "APPROVED", "Active", "Private", "", "
The Advanced Prosthetics Acquisition Tool (APAT) uses
the existing IFCAP API to take the specified Common Numbering Series and
update the PAT NUMBER (#442.6) File for the next number. An entry in the
PROCUREMENT & ACCOUNTING TRANSACTIONS (#442) File is also created for use in
obligation.", "", "PRCH7PA1", "2019/06/07"], ["6593", "READ ACCESS FOR SERVICE/SECTION FILE", "File", "KERNEL", "2016/10/28", "", "Pending", "Controlled Subscription", "49", "
Above PAR and Advanced Prosthetics Acquisition Tool
request read access to the SERVICE/SECTION FILE #49 for use in retrieving the
Service Name and Mail Symbol when displaying a detailed purchase card order
and when providing a list of services.\n
Above PAR Ad-Hoc Reporting includes the SERVICE/SECTION FILE #49. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", ""], ["6594", "HOSPITAL LOCATION FILE ACCESS", "File", "SCHEDULING", "2016/11/03", "APPROVED", "Active", "Private", "44", "
The Advanced Prosthetics Acquisition Tool (APAT) checks
the HOSPITAL LOCATION File (#44) to obtain the location name, to determine if
the clinic is non-count, and to check the stop code number.", "", "", "2018/07/26"], ["6595", "ADMIN. ACTIVITY SITE PARAMETER FILE ACCESS", "File", "IFCAP", "2016/11/03", "APPROVED", "Active", "Controlled Subscription", "411", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request READ access to the ADMIN. ACTIVITY SITE PARAMETER FILE #411 to
retrieve Receiving Locations and Substation data when creating or displaying
detailed purchase card orders and when verifying that a site is an IFCAP site.\n
If SCREEN FOR FISCAL USER (#39) is set, APAT may require that the user is an
AUTHORIZED FISCAL USER (#40 (subfile 411.05)).\n
Above PAR Ad-Hoc Reporting includes the ADMIN. ACTIVITY SITE PARAMETER FILE
#411. Ad-Hoc functionality provides the ability to select fields from the file
for display on user-defined reports. Ad-Hoc offers only FileMan read access
and only if the user has permission to view the file.", "", "", "2019/06/07"], ["6596", "PATIENT FILE ACCESS", "File", "REGISTRATION", "2016/11/03", "APPROVED", "Active", "Private", "2", "
The Advanced Prosthetics Acquisition Tool (APAT)
retrieves the patient's computed 1U4N (#.0905) field from the PATIENT file
(#2) via FileMan APIs for use in patient identification.", "", "", "2018/07/26"], ["6597", "REQUEST/CONSULTATION FILE ACCESS", "File", "CONSULT/REQUEST TRACKING", "2016/11/04", "APPROVED", "Active", "Private", "123", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access to
the Request/Consultation file when determining if a Prosthetic Suspense
needs to be sent to PCE.\n
Revision History:
- 10/24/24: Added following to ICR, .07 ROUTING FACILITY, 4 WHO ENTERED
ACTIVITY, 5 COMMENT and .21 REMOTE ORDERING PERSON", "", "", "2024/10/28"], ["6598", "HL7 APPLICATION PARAMETER FILE ACCESS", "File", "HEALTH LEVEL SEVEN", "2016/11/04", "", "Withdrawn", "Private", "771", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access to
the HL7 APPLICATION PARAMETER file. Reading this field will allow APAT to
determine if the HL7 application associated with the HL7 interface
is active or not. If the HL7 application is not active, the call to
the HL7 interface will quit, thus avoiding needless processing.", "", "", ""], ["6599", "PROTOCOL FILE ACCESS", "File", "KERNEL", "2016/11/04", "", "Withdrawn", "Private", "101", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests access to find
the IEN associated with the HL7 server protocol in order to set up HL7
environment variables.\n
^ORD(101,D0,0)
.01 NAME 0;1 Fileman r", "", "", ""], ["6600", "FACILITY TYPE (TEMPORARY) FILE ACCESS", "File", "IFCAP", "2016/11/04", "APPROVED", "Active", "Private", "411.2", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access to
the Facility type/name in the Facility Type (Temporary) file in order to
display it on the detailed purchase card order.", "", "", "2023/04/04"], ["6601", "DIRECT DELIVERY PATIENTS FILE ACCESS", "File", "IFCAP", "2016/11/04", "APPROVED", "Active", "Controlled Subscription", "440.2", "
The Advanced Prosthetics Acquisition Tool (APAT)
requests read access to the patient name and address in the DIRECT DELIVERY
PATIENTS FILE #440.2 for display on the detailed purchase card order.\n
Above PAR Ad-Hoc Reporting includes the DIRECT DELIVERY PATIENTS FILE #440.2.
Ad-Hoc functionality provides the ability to select fields from the file for
display on user-defined reports. Ad-Hoc offers only FileMan read access and
only if the user has permission to view the file.", "", "", "2018/11/21"], ["6602", "PURCHASE AUTHORITY FILE ACCESS", "File", "IFCAP", "2016/11/04", "APPROVED", "Active", "Controlled Subscription", "442.4", "\n
Permission for read access to the Purchase Authority Abbreviation in the
PURCHASE AUTHORITY file (#442.4) is requested for display on the detailed
purchase card order.", "", "", "2019/06/07"], ["6603", "PAT NUMBER FILE ACCESS", "File", "IFCAP", "2016/11/04", "APPROVED", "Active", "Private", "442.6", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access to
the PAT Number file (#442.6) when presenting the available Common
Numbering Series to be chosen when creating a purchase card order.", "", "", "2019/06/07"], ["6604", "ADMINISTRATIVE CERTIFICATIONS FILE ACCESS", "File", "IFCAP", "2016/11/04", "APPROVED", "Active", "Private", "442.7", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access to
the ADMINISTRATIVE CERTIFICATIONS File (#442.7) when displaying the
Administrative Certifications on the detailed purchase card order.", "", "", "2019/06/07"], ["6605", "DELIVERY SCHEDULE (ORDER) FILE ACCESS", "File", "IFCAP", "2016/11/04", "APPROVED", "Active", "Private", "442.8", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access to
the DELIVERY SCHEDULE (ORDER) file (#442.8) when displaying the delivery
schedule on a purchase order.", "", "", "2019/07/02"], ["6606", "VAFHPIVT", "Routine", "REGISTRATION", "2016/11/09", "", "Pending", "Private", "", "
For the Pharmacy Interface Automation Project (PIA), it
is necessary to send the Pivot number assigned to an admission in the HL7
message. This helps vendors subscribing to these messages to uniquely identify
patient movements that are related to admission/transfer/discharge.\n
Inpatient Medications is requesting to use the call $$PIVCHK^VAFHPIVT, which
returns the Pivot number assigned to a particular admission.", "", "VAFHPIVT", ""], ["6607", "SC PERCENTAGE", "File", "REGISTRATION", "2016/11/09", "APPROVED", "Active", "Private", "2", "
VIA needs to read the SERVICE CONNECTED PERCENTAGE
(#.302) field in the PATIENT (#2) file to provide data to consuming
applications via the remote procedure call, VIAB BMS RPC.", "", "", "2016/11/09"], ["6608", "FUND CONTROL POINT FILE ACCESS", "File", "IFCAP", "2016/11/10", "APPROVED", "Active", "Controlled Subscription", "420", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request READ access to the FUND CONTROL POINT FILE #420.\n
Above PAR Ad-Hoc Reporting includes the FUND CONTROL POINT FILE #420. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2019/06/07"], ["6609", "WARD", "File", "REGISTRATION", "2016/11/10", "APPROVED", "Active", "Private", "42", "
VIA needs to read fields from the WARD LOCATION (#42)
file to provide data to consuming applications via the remote procedure call,
VIAB BMS RPC.\n", "", "", "2016/11/10"], ["6610", "FACILITY MOVEMENT TYPE", "File", "REGISTRATION", "2016/11/10", "APPROVED", "Active", "Private", "405.1", "
VIA needs to read fields from the FACILITY MOVEMENT
TYPE (#405.1) file to provide data to consuming applications via the remote
procedure call, VIAB BMS RPC.\n", "", "", "2016/11/10"], ["6611", "SCHEDULED ADMISSION", "File", "REGISTRATION", "2016/11/10", "APPROVED", "Active", "Private", "41.1", "
VIA needs to read fields from the SCHEDULED ADMISSION
(#41.1) file to provide data to consuming applications via the remote
procedure call, VIAB BMS RPC.\n", "", "", "2016/11/10"], ["6612", "ROOM-BED", "File", "REGISTRATION", "2016/11/10", "APPROVED", "Active", "Private", "405.4", "
VIA needs to read fields from the ROOM-BED (#405.4)
file to provide data to consuming applications via the remote procedure call,
VIAB BMS RPC.\n", "", "", "2016/11/10"], ["6613", "PATIENT MOVEMENT", "File", "REGISTRATION", "2016/11/10", "APPROVED", "Active", "Private", "405", "
VIA needs to read fields from the PATIENT MOVEMENT
(#405) file to provide data to consuming applications via the remote procedure
call, VIAB BMS RPC.\n", "", "", "2016/11/10"], ["6614", "ORWPCE PCE4NOTE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2016/11/15", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
HMP calls the ORWPCE PCE4NOTE RPC to retrieve encounter information for an
associated note in the format:\n
LST(1)=HDR^AllowEdit^CPTRequired^VStr^Author^hasCPT
LST(n)=TYP+^CODE^CAT^NARR^QUAL1^QUAL2 (QUAL1=Primary!Qty, QUAL2=Prv)", "ORWPCE PCE4NOTE", "", "2017/10/12"], ["6615", "TRANSACTION NUMBER FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Private", "410.1", "\n
The Advanced Prosthetics Acquisition Tool (APAT) checks for new
transaction number availability for detailed purchase card orders.", "", "", "2019/06/07"], ["6616", "DELIVERY POINT FILE ACCESS", "File", "IFCAP", "2016/11/16", "", "Withdrawn", "Private", "410.8", "\n
The Advanced Prosthetics Acquisition Tool (APAT) pulls data from
the DELIVERY POINT (#410.8) file for reporting on detailed purchase
card orders.", "", "", ""], ["6617", "SORT GROUP FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Private", "410.7", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access
to the SORT GROUP (#410.7) file.", "", "", "2019/06/07"], ["6618", "SUB-CONTROL POINT FILE ACCESS", "File", "IFCAP", "2016/11/16", "", "Pending", "Private", "410.4", "\n
The Advanced Prosthetics Acquisition Tool (APAT) pulls data from
file SUB-CONTROL POINT (#410.4) when creating detailed purchase card
orders.", "", "", ""], ["6619", "CLASSIFICATION OF REQUEST FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Private", "410.2", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access
to the CLASSIFICATION OF REQUEST File (#410.2).", "", "", "2019/06/07"], ["6620", "INSTRUMENT KITS FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "445.8", "
The Advanced Prosthetics Acquisition Tool (APAT) and
ABOVE PAR determine whether a given INSTRUMENT KIT exists within the
INSTRUMENT KITS FILE #445.8.\n
Above PAR Ad-Hoc Reporting includes the INSTRUMENT KITS FILE #445.8. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2019/07/02"], ["6621", "CASE CARTS FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "445.7", "
The Advanced Prosthetics Acquisition Tool (APAT) and
ABOVE PAR request read access to the CASE CARTS FILE #445.7 in order to
determine whether a given Case Cart exists.\n
Above PAR Ad-Hoc Reporting includes the CASE CARTS FILE #445.7. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2019/06/07"], ["6622", "CODE INDEX FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "420.6", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access
to the CODE INDEX File (#420.6).", "", "", "2019/07/02"], ["6623", "EVALUATED PREFERENCE FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Private", "420.54", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access
to the EVALUATED PREFERENCE File (#420.54).", "", "", "2019/06/07"], ["6624", "EXTENT COMPETED FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Private", "420.53", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access
to the EXTENT COMPETED File (#420.53).", "", "", "2019/06/12"], ["6625", "SOLICITATION PROCEDURE FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Private", "420.52", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access
to the SOLICITATION PROCEDURE File (#420.52).", "", "", "2019/06/12"], ["6626", "REASON NOT COMPETED FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Private", "420.51", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests read access
to the REASON NOT COMPETED file (#420.51).", "", "", "2019/06/12"], ["6627", "PURCHASE CARD INFORMATION FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "440.5", "\n
Above PAR and the Advanced Prosthetics Acquisition Tool (APAT)
request READ access to specific fields of the Purchase Card
Information file (#440.5).", "", "", "2018/11/21"], ["6628", "PROCUREMENT & ACCOUNTING TRANSACTIONS FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "442", "
The Advanced Prosthetics Acquisition Tool (APAT)
requests read and write access to the PROCUREMENT & ACCOUNTING TRANSACTIONS
FILE (#442). APAT creates and displays simplified and detailed purchase card
orders in this file. Simplified purchase card orders are based on those
created by the Prosthetic VistA Suite GUI, and detailed purchase card orders
are based on those created in option PRCH ENTER DETAILED ORDER (New Detailed
Purchase Card Order).\n
Above PAR requests read access to the PROCUREMENT & ACCOUNTING TRANSACTIONS
FILE #442 for display and reporting purposes.\n
Above PAR Ad-Hoc Reporting includes the PROCUREMENT & ACCOUNTING TRANSACTIONS
FILE #442. Ad-Hoc functionality provides the ability to select fields from the
file for display on user-defined reports. Ad-Hoc offers only FileMan read
access and only if the user has permission to view the file.", "", "", "2023/05/01"], ["6629", "TYPE OF SPECIAL HANDLING FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "443.4", "\n
Above PAR and the Advanced Prosthetics Acquisition Tool (APAT)
request READ access to specific fields of the Type of Special
Handling file (#443.4).", "", "", "2018/11/21"], ["6630", "COST CENTER FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "420.1", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request READ access to the COST CENTER FILE #420.1.\n
Above PAR Ad-Hoc Reporting includes the COST CENTER FILE #420.1. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2023/04/28"], ["6631", "BUDGET OBJECT CODE FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "420.2", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request read access the BUDGET OBJECT CODE FILE #420.2.\n
Above PAR Ad-Hoc Reporting includes the BUDGET OBJECT CODE FILE #420.2.
Ad-Hoc functionality provides the ability to select fields from the file for
display on user-defined reports. Ad-Hoc offers only FileMan read access and
only if the user has permission to view the file.", "", "", "2018/11/21"], ["6632", "SOURCE CODE FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "420.8", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request read access to the SOURCE CODE FILE #420.8.\n
Above PAR Ad-Hoc Reporting includes the SOURCE CODE FILE #420.8. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2018/11/21"], ["6633", "PAT TYPE FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "442.5", "\n
Above PAR and the Advanced Prosthetics Acquisition Tool (APAT)
request read access to specific fields of the PAT TYPE (#442.5)
File.", "", "", "2019/06/13"], ["6634", "CONTROL POINT ACTIVITY FILE ACCESS", "File", "IFCAP", "2016/11/16", "APPROVED", "Active", "Controlled Subscription", "410", "
Above PAR and the Advanced Prosthetics Acquisition Tool
(APAT) request permission to reference the CONTROL POINT ACTIVITY FILE #410 to
create/edit 2237's during the creation of purchase card orders and 2237's and
during purchase card reconciliation/close-out.\n\n
Above PAR Ad-Hoc Reporting includes the CONTROL POINT ACTIVITY FILE #410.
Ad-Hoc functionality provides the ability to select fields from the file for
display on user-defined reports. Ad-Hoc offers only FileMan read access and
only if the user has permission to view the file.", "", "", "2018/11/14"], ["6635", "PXVIMM ADMIN CODES", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/18", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Making a call to the PXVIMM ADMIN CODES RPC to retrieve immunization
administration CPT codes.", "PXVIMM ADMIN CODES", "", "2017/01/11"], ["6636", "FPDS HL7 MESSAGE GENERATION FOR AAC", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics
Acquisition Tool (APAT) to call IFCAP routine AAC^PRCHAAC. When a
detailed purchase card order is created, this functionality will gather
FPDS data for the report requested by the Austin Automation Center
(AAC), create an HL7 message, and send it to the Austin server via the
VistA HL7 package.", "", "PRCHAAC", "2019/06/12"], ["6637", "ENCODING E-SIGNATURE ON PC ORDER", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics
Acquisition Tool (APAT) to call IFCAP routine ENCODE^PRCHES5 to encode
an esignature when a detailed purchase card order is created.", "", "PRCHES5", "2019/06/12"], ["6638", "ENTER NEW PURCHASE CARD ORDER", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCHNPO when creating a detailed
purchase card order.", "", "PRCHNPO", "2020/10/15"], ["6639", "FPDS CODE SELECTION SCREEN", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call EN7^PRCHNPO2 when creating a detailed purchase
card order.", "", "PRCHNPO2", "2019/06/13"], ["6640", "AUDITS OF PURCHASE CARD ORDER LINE ITEMS", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCHNPO7 when creating a detailed
purchase card order.", "", "PRCHNPO7", "2019/06/12"], ["6641", "BBFY OF PURCHASE CARD ORDER", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics
Acquisition Tool (APAT) to call BBFY^PRCHNPO8 when creating a
detailed purchase card order.", "", "PRCHNPO8", "2019/06/12"], ["6642", "PCDO TRANSACTION NUMBER VALIDATION", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCHNPOA when creating a detailed
purchase card order.", "", "PRCHNPOA", "2019/06/12"], ["6643", "USAGE OF PRCHNPOB", "Routine", "IFCAP", "2016/11/22", "", "Withdrawn", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCHNPOB when creating a detailed
purchase card order.", "", "PRCHNPOB", ""], ["6644", "ESIG PROBLEM ERROR MESSAGE", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCHQQ when creating a detailed
purchase card order.", "", "PRCHQQ", "2019/06/13"], ["6645", "STATUS UPDATE PURCHASE CARD ORDER", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCHSTAT when creating a detailed
purchase card order.", "", "PRCHSTAT", "2019/07/02"], ["6646", "PRCHOBL BASED ON FCP SWITCHES/MOP", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCHSWCH when creating a detailed
purchase card order.", "", "PRCHSWCH", "2019/06/13"], ["6647", "PRCHLOG VARIABLE SETUP", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call SWITCH^PRCHUTL when creating a detailed purchase
card order.", "", "PRCHUTL", "2019/07/02"], ["6648", "PHA FIELD VALIDATION", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call NEW^PRCOEDC when creating a detailed purchase
card order.", "", "PRCOEDC", "2019/06/13"], ["6649", "INVENTORY DUE-IN RECALCULATION", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call UPDATE^PRCPWIU when creating a detailed purchase
card order.", "", "PRCPWIU", "2019/06/13"], ["6650", "FUNDS AVAILABILITY CHECK", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call $$OVCOM^PRCS0A when creating a detailed purchase
card order.", "", "PRCS0A", "2019/06/13"], ["6651", "COMMITTED BALANCE DETAILED PC ORDER", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call COMM^PRCSPC when creating a detailed purchase card
order.", "", "PRCSPC", "2019/06/13"], ["6652", "BBFY OF FCP", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call $$BBFY^PRCSUT() when creating a detailed purchase
card order.", "", "PRCSUT", "2019/06/13"], ["6653", "PURCHASE ORDER DATA FOR DYNAMED", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call UPD^PRCV442A() when creating a detailed
purchase card order.", "", "PRCV442A", "2019/07/02"], ["6654", "PC ORDER NET, TOTAL & BOC $ UPDATES", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call ^PRCHSF when creating a detailed purchase card
order.", "", "PRCHSF", "2019/06/13"], ["6655", "PHA TXN FOR EDI & PHA QUEUES", "Routine", "IFCAP", "2016/11/22", "APPROVED", "Active", "Private", "", "\n
This integration agreement allows the Advanced Prosthetics Acquisition
Tool (APAT) to call IFCAP routine PRCOEDI when creating or amending a
detailed purchase card order.", "", "PRCOEDI", "2019/07/02"], ["6656", "PXVIMM ADMIN ROUTE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM ADMIN ROUTE RPC to retrieve the entries from the IMM
ADMINISTRATION ROUTE File (#920.2).", "PXVIMM ADMIN ROUTE", "", "2017/01/11"], ["6657", "PXVIMM ADMIN SITE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM ADMIN SITE RPC to retrieve entries from the IMM
ADMINISTRATION SITE (BODY) File (#920.3).", "PXVIMM ADMIN SITE", "", "2017/01/11"], ["6658", "PXVIMM ICR LIST", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM ICR LIST RPC to retrieve entries from the IMM
CONTRAINDICATION REASONS File (#920.4) and the IMM REFUSAL REASONS File
(#920.5).", "PXVIMM ICR LIST", "", "2017/01/11"], ["6659", "PXVIMM IMM DETAILED", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls to the PXVIMM IMM DETAILED RPC to retrieve a detailed Immunization
Record.", "PXVIMM IMM DETAILED", "", "2017/01/11"], ["6660", "PXVIMM IMM FORMAT", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM IMM FORMAT RPC to retrieve a formatted text of an
immunization for use in documentation.", "PXVIMM IMM FORMAT", "", "2017/01/11"], ["6661", "PXVIMM IMM LOT", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM IMM LOT RPC to retrieve information from the IMMUNIZATION LOT
File (#9999999.41).", "PXVIMM IMM LOT", "", "2017/01/11"], ["6662", "PXVIMM IMM MAN", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM IMM MAN RPC to retrieve information from the IMM MANUFACTURER
File (#9999999.04).", "PXVIMM IMM MAN", "", "2017/01/11"], ["6663", "PXVIMM IMM SHORT LIST", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Active", "Controlled Subscription", "", "\n\n
Calls the PXVIMM IMM SHORT LIST RPC to retrieve a short list of immunizations.\n", "PXVIMM IMM SHORT LIST", "", "2017/11/20"], ["6664", "PXVIMM IMMDATA", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM IMMDATA RPC to retrieve information from the IMMUNIZATION
File (#9999999.14).", "PXVIMM IMMDATA", "", "2017/01/11"], ["6665", "PXVIMM VICR EVENTS", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM VICR EVENTS RPC to retrieve "active" entries from the V IMM
CONTRA/REFUSAL EVENTS File (#9000010.707) that are related to the given
patient and immunization. "Active" is defined as entries where the Event Date
and Time is greater than or equal to PXDATE and the Warn Until Date is null or
greater than PXDATE.", "PXVIMM VICR EVENTS", "", "2017/01/11"], ["6666", "PXVIMM VIS", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2016/11/25", "APPROVED", "Retired", "Controlled Subscription", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
Calls the PXVIMM VIS RPC to retrieve information from the VACCINE INFORMATION
STATEMENT File (#920).", "PXVIMM VIS", "", "2017/01/11"], ["6667", "YTQ USERQ", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ USERQ Mental Health RPC.", "YTQ USERQ", "", "2017/09/20"], ["6668", "YTQ TSLIST1", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ TSLIST1 Mental Health RPC.", "YTQ TSLIST1", "", "2017/09/20"], ["6669", "YTQ QUESTALL", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ QUESTALL Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine called by the RPC. The
routine before patch YS*5.01*123 is YTQAPI3, and the routine after the patch
is YTQAPI24. Input, output and tag name are not changed with this patch. The
above changes are dependent upon the release of CPRS v31A.", "YTQ QUESTALL", "", "2017/09/14"], ["6670", "YTQ SECTION", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ SECTION Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine name called by the RPC.
The routine before patch YS*5.01*123 is YTQAPI, and the routine after the
patch is YTQAPI24. Input, output and tag name are not changed with this
patch. The above changes are dependent upon the release of CPRS v31A.", "YTQ SECTION", "", "2017/09/18"], ["6671", "YTQ RULES", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ RULES Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine called by the RPC. The
routine before patch YS*5.01*123 is YTQAPI1, and the routine after the patch
is YTQAPI24. Input, output and tag name are not changed with this patch. The
above changes are dependent upon the release of CPRS v31A.", "YTQ RULES", "", "2017/09/18"], ["6672", "YTQ SKIP", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ SKIP Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine name called by the RPC.
The routine before patch YS*5.01*123 is YTQAPI, and the routine after the
patch is YTQAPI24. Input, output and tag name are not changed with this
patch. The above changes are dependent upon the release of CPRS v31A.", "YTQ SKIP", "", "2017/09/19"], ["6673", "YTQ CHOICES", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ CHOICES Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine called by the RPC. The
routine before patch YS*5.01*123 is YTQAPI, and the routine after the patch
is YTQAPI24. Input, output and tag name are not changed with this patch. The
above changes are dependent upon the release of CPRS v31A.", "YTQ CHOICES", "", "2017/09/14"], ["6674", "YTQ GET SCALES", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ GET SCALES Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine called by the RPC. The
routine before patch YS*5.01*123 is YTQAPI3, and the routine after the patch
is YTQAPI23. Input, output and tag name are not changed with this patch. The
above changes are dependent upon the release of CPRS v31A.", "YTQ GET SCALES", "", "2017/09/14"], ["6675", "YTQ GET REPORT", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ GET REPORT Mental Health RPC.", "YTQ GET REPORT", "", "2017/09/14"], ["6676", "YTQ SAVE", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "", "Withdrawn", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ SAVE Mental Health RPC.", "YTQ SAVE", "", ""], ["6677", "YTQ SET ANSWER ALL", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "", "Withdrawn", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ SET ANSWER ALL Mental Health
RPC.", "YTQ SET ANSWER ALL", "", ""], ["6678", "YTQ ALL ANSWERS", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ ALL ANSWERS Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine called by the RPC. The
routine before patch YS*5.01*123 is YTQAPI2 and the new routine after the
patch is YTQAPI21. Input, output and tag name are not changed with this
patch. The above changes are dependent upon the release of CPRS v31A.", "YTQ ALL ANSWERS", "", "2017/09/14"], ["6679", "YTQ SCORE ADMIN", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ SCORE ADMIN Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine name called by the RPC.
The routine before patch YS*5.01*123 is YTQAPI8, and the routine after the
patch is YTQAPI23. Input, output and tag name are not changed with this
patch. The above changes are dependent upon the release of CPRS v31A.", "YTQ SCORE ADMIN", "", "2017/09/18"], ["6680", "YTQ SCORE SAVE", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "APPROVED", "Active", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ SCORE SAVE Mental Health RPC.\n
The release of patch YS*5.01.123 changes the routine name called by the RPC.
The routine before patch YS*5.01*123 is YTQAPI11, and the routine after the
patch is YTQAPI23. Input, output and tag name are not changed with this
patch. The above changes are dependent upon the release of CPRS v31A.", "YTQ SCORE SAVE", "", "2017/09/18"], ["6681", "YTQ PN CREATE", "Remote Procedure", "MENTAL HEALTH", "2016/12/08", "", "Withdrawn", "Private", "", "
The Mental Health Patient Reported Outcome (MHPRO)
mobile application requests access to the YTQ PN CREATE Mental Health RPC.", "YTQ PN CREATE", "", ""], ["6682", "Decode/Encode JSON", "Routine", "KERNEL", "2016/12/13", "APPROVED", "Active", "Supported", "", "
This is a utility for decoding and encoding JSON.", "", "XLFJSON", "2017/07/06"], ["6683", "MBAA LIST CANCELLATION REASONS", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call returns the list of
cancellation reasons from the CANCELLATION REASONS file ($409.2).\n", "", "", ""], ["6684", "MBAA VERIFY CLINIC ACCESS", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call checks to see if the logon
user has access to a clinic.\n", "", "", ""], ["6685", "MBAA APPOINTMENT LIST BY NAME", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call returns a list of
appointment types based on the input parameters from the Appointment Types
file (#409.1).\n", "", "", ""], ["6686", "MBAA APPOINTMENT MAKE", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call makes an appointment for a
patient.\n", "", "", ""], ["6687", "MBAA FACILITY WAIT LIST", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call will return the full
Facility Electronic Wait List.\n", "", "", ""], ["6688", "MBAA CANCEL APPOINTMENT", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call will return the full
Facility Electronic Wait List.\n", "", "", ""], ["6689", "MBAA PATIENT PENDING APPT", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call returns data about pending
appointments for a patient.\n", "", "", ""], ["6690", "MBAA REMOVE FROM EWL", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call removes a patient from the
EWL.\n", "", "", ""], ["6691", "MBAA PROVIDERS BY CLINIC", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure takes input of the clinic id, IEN
from the Hospital Location file (#44), and returns the list of providers
assigned to that clinic. The return data is the provider name and IEN for the
provider from the New Person file (#200).\n", "", "", ""], ["6692", "MBAA GET CLINIC AVAILABILITY", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call returns the available slots
for a clinic.\n", "", "", ""], ["6693", "MBAA GET CLINIC DETAILS", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call returns clinic details
needed for scheduling appointments into a clinic.\n", "", "", ""], ["6694", "MBAA WAIT LIST BY DFN", "Remote Procedure", "MOBILE SCHEDULING APPLICATIONS SUITE", "2016/12/16", "", "Pending", "Private", "", "
This remote procedure call returns the EWL for a
patient.\n", "", "", ""], ["6695", "XUS BSE TOKEN", "Remote Procedure", "KERNEL", "2016/12/21", "APPROVED", "Active", "Controlled Subscription", "", "
Provide Broker Security Enhancement (BSE) login string
for Station-number authentication into a remote (visited) VistA system using
credentials from a home (authenticating) VistA system.", "XUS BSE TOKEN", "", "2017/05/25"], ["6696", "READ ACCESS TO DD(404.43", "File", "1", "2017/01/03", "APPROVED", "Active", "Private", "", "
This is a onetime agreement via patch SD*5.3*659.
Scheduling requests read access to the following ^DD(404.43 nodes to obtain
the cross reference numbers that will be deleted by the patch post-install
routine.
^DD(404.43,.01,1, ^DD(404.43,.02,1, ^DD(404.43,.03,1,
^DD(404.43,.04,1, ^DD(404.43,.05,1,\n
The patch post-install routine will delete the following cross references.
These cross references are associated with HL7 messaging that PCMM no longer
performs.
PATIENT TEAM POSITION ASSIGNMENT FILE (#404.43)
.01 PATIENT TEAM ASSIGNMENT
Xref-AEVENT1
.02 TEAM POSITION
Xref-AEVENT3
.03 POSITION ASSIGNED DATE
Xref-AEVENT4
.04 POSITION UNASSIGNED DATE
Xref-AEVENT5
.05 PC ROLE
Xref-AEVENT2\n
Code to delete cross references.\n
DELXREF(SDFILE,SDFIELD,SDXREFNM) ; Delete traditional cross reference
;Inputs: SDFILE - file number
; SDFIELD - field number
; SDXREFNM - xref name
;
NEW SDHIT,SDOUT,SDERR,SDXREF
DO BMES^XPDUTL("Delete the "_SDXREFNM_" xref in "_SDFILE_"/"_SDFIELD_".")
;
SET SDHIT=0
SET SDXREF=0
FOR SET SDXREF=$O(^DD(SDFILE,SDFIELD,1,SDXREF)) QUIT:('+SDXREF)!(SDHIT) DO
. IF $GET(^DD(SDFILE,SDFIELD,1,SDXREF,0))[SDXREFNM DO
. . ;W !,"SDXREF: ",SDXREF," Node: ",^DD(SDFILE,SDFIELD,1,SDXREF,0),!
. . DO DELIX^DDMOD(SDFILE,SDFIELD,SDXREF,"","SDOUT","SDERR")
. . IF '$DATA(SDERR) DO
. . . DO MES^XPDUTL("The "_SDXREFNM_" cross reference was deleted.")
. . . SET SDHIT=1
. . ELSE DO
. . . DO MES^XPDUTL("ERROR encountered deleting the "_SDXREFNM_" cross
reference.")
;
DO:'SDHIT MES^XPDUTL("The "_SDXREFNM_" cross reference was not found.")
;
QUIT
;", "", "", "2017/02/02"], ["6697", "ORWDXR ISREL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "\n\n", "ORWDXR ISREL", "", "2017/02/17"], ["6698", "ORWDX1 ORDMATCH", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "", "ORWDX1 ORDMATCH", "", "2017/02/17"], ["6699", "ORWOR PKISITE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "
The RPC determines if PKI is turned on at the site.\n", "ORWOR PKISITE", "", "2017/02/17"], ["6700", "ORWDXC SAVECHK", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "\n\n", "ORWDXC SAVECHK", "", "2017/02/13"], ["6701", "ORWUL FVSUB", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "
The RPC returns a subset of orders in view.\n", "ORWUL FVSUB", "", "2017/02/14"], ["6702", "ORWDXR ISCPLX", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "
The RPC returns 1 is complex order or 0 is not a
complex order.\n", "ORWDXR ISCPLX", "", "2017/02/17"], ["6703", "ORWORDG ALLTREE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "\n\n", "ORWORDG ALLTREE", "", "2017/02/14"], ["6704", "ORWORDG REVSTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/05", "APPROVED", "Active", "Private", "", "\n\n", "ORWORDG REVSTS", "", "2017/02/14"], ["6705", "ORWDXR GETPKG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns the package for an order.\n", "ORWDXR GETPKG", "", "2017/02/14"], ["6706", "OREVNTX1 ODPTEVID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns the event the order was delayed for.\n", "OREVNTX1 ODPTEVID", "", "2017/02/22"], ["6707", "ORWDRA32 ISOLATN", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns a value if patient has active isolation
order (or 0 if not).\n", "ORWDRA32 ISOLATN", "", "2017/02/14"], ["6708", "ORWDPS2 CHKPI", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns pre-existing patient instructions.\n", "ORWDPS2 CHKPI", "", "2017/02/14"], ["6709", "ORIMO IMOOD", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Controlled Subscription", "", "
RPCS returns - Is it an IMO order?\n", "ORIMO IMOOD", "", "2017/02/17"], ["6710", "ORWD2 MANUAL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "", "ORWD2 MANUAL", "", "2017/02/21"], ["6711", "ORWUL FVIDX", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns index of item beginning with FROM
parameter.\n", "ORWUL FVIDX", "", "2017/02/21"], ["6712", "ORWUL FV4DG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns the current full list and item count.\n", "ORWUL FV4DG", "", "2017/02/21"], ["6713", "ORWDPS5 LESGRP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC checks and returns the orders belonging to the
following display group
1. LAB/LABORATORY ORDERS
2. BLOOD BANK ORDERS
3. CHEMISTRY ORDERS\n", "ORWDPS5 LESGRP", "", "2017/02/21"], ["6714", "ORWDPS2 CHKGRP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC will
- return 1: Inpatient Med Order Group or Clin Meds Group
- return 2: If order belong to Outpatient Med Order Group
- return 0: Otherwise\n", "ORWDPS2 CHKGRP", "", "2017/02/21"], ["6715", "ORWORR GETTXT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "", "ORWORR GETTXT", "", "2017/02/22"], ["6716", "ORWDRA32 PROCMSG", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns order message for a procedure.\n", "ORWDRA32 PROCMSG", "", "2017/02/22"], ["6717", "ORWDXM FORMID", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "", "ORWDXM FORMID", "", "2017/02/22"], ["6718", "OREVNTX1 DLGIEN", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/01/06", "APPROVED", "Active", "Private", "", "
RPC returns Order Dialog IEN based on name.\n", "OREVNTX1 DLGIEN", "", "2017/02/21"], ["6719", "OE/RR CALL TO PSOORCPY", "Routine", "OUTPATIENT PHARMACY", "2017/01/11", "APPROVED", "Active", "Private", "", "
The Order Entry/Results Reporting would like approval
to call the extrinsic function $$ORCOPY^PSOORCPY(Placer).", "", "PSOORCPY", "2017/07/10"], ["6720", "GIVE THIS DBIA A BETTER NAME THAN DBIA6720", "", "", "2017/01/13", "", "Pending", "", "", "", "", "", ""], ["6721", "READ ACCESS TO DD(404.52", "File", "1", "2017/01/20", "APPROVED", "Active", "Private", "", "
This is a onetime agreement via patch SD*5.3*659.
Scheduling requests read access to the following ^DD(404.52 nodes to obtain
the cross reference numbers that will be deleted by the patch post-install
routine.
^DD(404.52,.01,1, ^DD(404.52,.02,1, ^DD(404.52,.03,1,
^DD(404.52,.04,1, ^DD(404.52,.09,1,\n
The patch post-install routine will delete the following cross references.
These cross references are associated with HL7 messaging that PCMM no longer
performs.
POSITION ASSIGNMENT HISTORY FILE (#404.52)
.01 TEAM POSITION
Xref-AEVENT1
.02 EFFECTIVE DATE
Xref-AEVENT2
.03 PRACTITIONER
Xref-AEVENT3
.04 STATUS
Xref-ASTATUS
.09 FTEE EQUIVALENT
Xref-AFTEE\n
Code to delete cross references. DELXREF(SDFILE,SDFIELD,SDXREFNM) ; Delete
traditional cross reference
;Inputs: SDFILE - file number
; SDFIELD - field number
; SDXREFNM - xref name
;
NEW SDOUT,SDERR,SDXREF
DO BMES^XPDUTL("Delete the "_SDXREFNM_" xref in "_SDFILE_"/"_SDFIELD_".")
;
SET SDXREF=0
FOR SET SDXREF=$O(^DD(SDFILE,SDFIELD,1,SDXREF)) QUIT:'+SDXREF DO
. IF $GET(^DD(SDFILE,SDFIELD,1,SDXREF,0))[SDXREFNM DO
. . ;W !,"SDXREF: ",SDXREF," Node: ",^DD(SDFILE,SDFIELD,1,SDXREF,0),!
. . DO DELIX^DDMOD(SDFILE,SDFIELD,SDXREF,"","SDOUT","SDERR")
. . IF '$DATA(SDERR) DO
. . . DO MES^XPDUTL("The "_SDXREFNM_" cross reference was deleted.")
. . ELSE DO
. . . DO MES^XPDUTL("ERROR encountered deleting the "_SDXREFNM_" cross
reference.")
QUIT
;", "", "", "2017/02/02"], ["6722", "READ ACCESS TO DD(404.53", "File", "1", "2017/01/20", "APPROVED", "Active", "Private", "", "
This is a onetime agreement via patch SD*5.3*659.
Scheduling requests read access to the following ^DD(404.53 nodes to obtain
the cross reference numbers that will be deleted by the patch post-install
routine.
^DD(404.53,.01,1, ^DD(404.53,.02,1, ^DD(404.53,.04,1,
^DD(404.53,.06,1, The patch post-install routine will delete the following
cross references. These cross references are associated with HL7 messaging
that PCMM no longer performs.\n
PRECEPTOR ASSIGNMENT HISTORY FILE (#404.53)
.01 TEAM POSITION
Xref-AEVENT1
.02 EFFECTIVE DATE
Xref-AEVENT2
.04 STATUS
Xref-AEVENT3
.06 PRECEPTOR TEAM POSITION
Xref-AEVENT4\n
Code to delete cross references. DELXREF(SDFILE,SDFIELD,SDXREFNM) ; Delete
traditional cross reference
;Inputs: SDFILE - file number
; SDFIELD - field number
; SDXREFNM - xref name
;
NEW SDOUT,SDERR,SDXREF
DO BMES^XPDUTL("Delete the "_SDXREFNM_" xref in "_SDFILE_"/"_SDFIELD_".")
;
SET SDXREF=0
FOR SET SDXREF=$O(^DD(SDFILE,SDFIELD,1,SDXREF)) QUIT:'+SDXREF DO
. IF $GET(^DD(SDFILE,SDFIELD,1,SDXREF,0))[SDXREFNM DO
. . ;W !,"SDXREF: ",SDXREF," Node: ",^DD(SDFILE,SDFIELD,1,SDXREF,0),!
. . DO DELIX^DDMOD(SDFILE,SDFIELD,SDXREF,"","SDOUT","SDERR")
. . IF '$DATA(SDERR) DO
. . . DO MES^XPDUTL("The "_SDXREFNM_" cross reference was deleted.")
. . ELSE DO
. . . DO MES^XPDUTL("ERROR encountered deleting the "_SDXREFNM_" cross
reference.")
QUIT
;", "", "", "2017/02/02"], ["6723", "DBIA 6723", "File", "KERNEL", "2017/01/23", "APPROVED", "Active", "Private", "4", "
Event Capture requests permission to delete and rebuild
the "LOC" cross-reference in the INSTITUTION file (#4).\n
Due to an issue resulting from changing the name of an entry in the
INSTITUTION file, the "LOC" cross-reference may no longer show the correct
facility name in the "LOC" cross-reference.\n
As a result, a direct kill of the cross-reference, using K ^DIC(4,"LOC") is
needed to completely delete the table as the KILL logic of the cross-reference
will not correctly remove incorrectly named entries.\n
After manually killing the cross-reference, a call to ENALL^DIK will be made
to rebuild the cross-reference using the most up-to-date facility names.\n
This request is for a one-time deletion and rebuild of the cross-reference in
the post-install process of patch EC*2.0*134.", "", "", "2017/08/14"], ["6724", "LR7OSUM2", "Routine", "LAB SERVICE", "2017/01/25", "APPROVED", "Active", "Controlled Subscription", "", "
For CPRS v32 development, the OR and GMTS packages need
access to an existing lab report API, $$PLSADDR^LR7OSUM2, which has also been
modified for CPRS v32. The modification is to allow an optional effective date
to be passed, so the correct current or archived facility address will be
pulled based on that date. These changes are all related to NSR 20081206 and
will be part of the CPRS v32 bundled release.", "", "LR7OSUM2", "2017/07/11"], ["6725", "VIAB CALL TO FIRST~ORCDPS3", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/01/25", "", "Withdrawn", "Controlled Subscription", "", "
VIAB makes a call to the FIRST^ORCDPSA3 API to get the
expected first admin time for an order.", "", "ORCDPS3", ""], ["6726", "VIAB FILE READS OF 101.416", "File", "ORDER ENTRY/RESULTS REPORTING", "2017/01/26", "", "Withdrawn", "Controlled Subscription", "101.41", "
The VistA Integration Adaptor (VIAB) VIABDPS2 OISLCT
RPC is retrieving data from the ORDER DIALOG FILE (#101.41) RESPONSE MULTIPLE
(#101.416) in order retrieve the default dialogs for pharmacy orderable items.\n", "", "", ""], ["6727", "VIAB ACCESS TO FILE 101.43", "File", "ORDER ENTRY/RESULTS REPORTING", "2017/01/26", "", "Withdrawn", "Controlled Subscription", "101.43", "
The VistA Integration Adaptor (VIAB) VIABDPS2 OISLCT
RPC is accessing the ORDERABLE ITEMS FILE (#101.43) to retrieve data for the
default order dialog for a pharmacy orderable item.", "", "", ""], ["6728", "VIAB LOAD", "File", "LAB SERVICE", "2017/01/26", "", "Withdrawn", "Private", "60", "
VIAB needs to read Field #4 (SUBSCRIPT) and the "B"
cross-reference of File #60 for VIAB LOAD RPC.\n", "", "", ""], ["6729", "MD CLIO", "Remote Procedure", "CLINICAL PROCEDURES", "2017/01/26", "APPROVED", "Active", "Private", "", "\n\n", "MD CLIO", "", "2017/02/28"], ["6730", "VIAB SRGY RPTLIST", "File", "SURGERY", "2017/01/26", "APPROVED", "Active", "Private", "130", "
VIA needs to read a number of fields from Surgery File
#130 for VIAB SRGY RPTLIST RPC.", "", "", "2017/03/09"], ["6731", "ETSLNC", "Routine", "ENTERPRISE TERMINOLOGY SERVICE", "2017/01/30", "APPROVED", "Active", "Supported", "", "
These API(s) allow access to the LOINC data that is
contained in the LOINC files in the Enterprise Terminology Services (ETS)
package.", "", "ETSLNC", "2018/06/08"], ["6732", "VISTA IMAGING RAD DOSE DATABASE ACCESS", "File", "IMAGING", "2017/02/07", "APPROVED", "Active", "Private", "2005.632", "
VistA Radiology/Nuclear Medicine requires VA FileMan
(FM) read/with FM and direct global read access to the CT DOSE (#2005.632)
file.\n
The direct global read will be used to determine the presence of data in file
2005.632.", "", "", "2017/07/11"], ["6733", "VISTA IMAGING RAD DOSE DATABASE ACCESS (2)", "File", "IMAGING", "2017/02/07", "APPROVED", "Active", "Private", "2005.633", "
VistA Radiology/Nuclear Medicine requires VA FileMan
(FM) read/with FM and direct global read access to the PROJECTION X-RAY DOSE
(#2005.633) file.\n
The direct global read will be used to determine the presence of data in file
2005.633.", "", "", "2017/07/11"], ["6734", "CANCEL 2237 FROM PC ORDER", "Routine", "IFCAP", "2017/02/13", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call C2237^PRCH442A. The call will
cancel a 2237 from a purchase card order.", "", "PRCH442A", "2019/06/13"], ["6735", "GMPLBLD2", "Routine", "PROBLEM LIST", "2017/02/13", "APPROVED", "Active", "Private", "", "
This ICR documents calls made to GMPLBLD2.", "", "GMPLBLD2", "2017/02/14"], ["6736", "Executable Help Deletion", "Other", "1", "2017/02/17", "", "Retired", "Private", "", "
This is a temporary agreement to be used only if
PSS*1*202, which is the RollBack patch for PSS*1*201, needs to be released or
sent to any number of sites. The Post-Init routine (PSS202RB) will kill the 4
node of the NAME (#.01) Field and SYNONYM (#.5) Field of the MEDICATION
INSTRUCTION (#51) File Data Dictionary. The 4 node contains the Executable
Help.\n\n
0n 8/14/17, the developer said the 90-warranty period for PSS*1*201 was
reached and the functionality provided by this ICR will not be needed for the
rollback patch PSS*1*202. ICR #6736 was retired on 11/15/17.", "", "", ""], ["6737", "ORWDXC ACCEPT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/02/23", "", "Withdrawn", "Private", "", "
The ICR will be used by this service: OrderMgmtSvc -
acceptOrder.\n", "ORWDXC ACCEPT", "", ""], ["6738", "ORWDLR32 DEF", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2017/02/23", "", "Withdrawn", "Private", "", "
The ICR will be used by this service: OrderMgmtSvc -
getInitialLabOrderParams.\n", "ORWDLR32 DEF", "", ""], ["6739", "HMP ACCESS TO THE MHY TESTS AND SURVEYS FILE", "File", "MENTAL HEALTH", "2017/02/24", "", "Retired", "Controlled Subscription", "601.71", "
The Enterprise Health MGMT Platform is accessing the MH
TESTS AND SURVEYS FILE (#601.71) to retrieve fields .01 - NAME, 21 - COPYRIGHT
TEXT and 25 - IS COPYRIGHTED as part of the data collection for the HMP sync
process.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated.\n
ICR #6739 was entered to replace ICR #5044. ICR #6739 must be revisited if
HMP is restarted in the future due to global reference and changes implemented
with YS*5.01*123.\n
**********************************************************************", "", "", ""], ["6740", "DD 'AUTOLINK' MULT .01 FLD TO REMOVE REF TO 44/409.67 FILES", "File", "1", "2017/02/24", "APPROVED", "Active", "Private", "100.21", "
Patch OR*3.0*399 to remove AUTOLINK Multiple from Data
Dictionary of OE/RR LINK File in a pre-install routine that is part of the
patch and then the patch itself will rebuild the Multiple with only those
Variable Pointer entries that should remain (all but refs to 44 and 409.67).\n
Patch will rebuild 100.213,.01 AUTOLINK field of ^DD(100.213) leaving only the
following in the VARIABLE POINTER field:\n
FILE ORDER PREFIX LAYGO MESSAGE
42 1 W n WARD
405.4 2 R n ROOM-BED
200 3 P n PROVIDER
45.7 4 S n SPECIALTY\n
Formerly it had a link to either File 44 or 409.67 (which OR*3.0*399 deletes),
e.g.:\n
44 5 C n CLINIC\n
Deletion of AUTOLINK Multiple is done by OR3P399 pre-install routine with the
use of the following FileMan call:\n
S DIU=100.213,DIU(0)="S" D EN^DIU2 K DIU", "", "", "2017/03/02"], ["6741", "RESIDENTIAL ADDRESS DISPLAY", "Routine", "REGISTRATION", "2017/03/02", "", "Withdrawn", "Controlled Subscription", "", "
The routine RESDISP^DGADDUT1(DFN) will display the
current residential address in the format found on screen 1.1 of patient
registration.\n
The display will be placed at the current $Y with the following format:\n
123 DRIVE ROAD County:
APT 8 Phone: UNANSWERED
BED 1
MINNEAPOLIS,MN 55114
UNITED STATES From/To: JUN 10,2014/APR 6,2017\n", "", "DGADDUT1", ""], ["6742", "DBIA6742", "File", "TEXT INTEGRATION UTILITIES", "2017/03/03", "APPROVED", "Active", "Controlled Subscription", "8925", "
The consult closure tool needs to find all the amended
or completed notes that have been entered for a particular patient for a
consult within a selected time frame.\n
The "ADCPT" cross-reference addresses each of these requirements. This ICR is
for direct global read only.", "", "", "2017/11/20"], ["6743", "VIAB LAB", "File", "LAB SERVICE", "2017/03/06", "APPROVED", "Active", "Private", "63", "", "", "", "2017/04/14"], ["6744", "DBIA6744", "Routine", "SCHEDULING", "2017/03/14", "APPROVED", "Active", "Private", "", "
Registration version 5.3 uses entry point $$PCMMXMY to
build xmy array for the appropriate type of PCMM message.\n\n", "", "SCAPMC25", "2017/03/30"], ["6745", "DBIA6745", "Routine", "SCHEDULING", "2017/03/14", "APPROVED", "Active", "Private", "", "
Registration Version 5.3 uses API call $$PCMAIL^SCMCMM
to load standard patient centered information into a mail message.", "", "SCMCMM", "2017/03/30"], ["6746", "DBIA6746", "File", "INCOME VERIFICATION MATCH", "2017/03/14", "", "Pending", "Private", "301.9", "
Registration Version 5.3 access the IVM Site Parameter
file (#301.9) to get the ENROLLMENT ALERT MAIL GROUP field (#.09) that is on
the 9th piece of the zero node.\n\n", "", "", ""], ["6747", "PRCA READ/WRITE ACCESS W/FILEMAN TO LOCK FIELD (#3)", "File", "KERNEL", "2017/03/15", "APPROVED", "Active", "Private", "19", "
PRCA requires the ability to delete a LOCK from an
OPTION for patch PRCA*4.5*318. This cannot be accomplished using KIDS.
Permission is required to accomplish this task using pre- or post-install
routines in KIDS.", "", "", "2017/03/27"], ["6748", "DBIA6748", "File", "MASTER PATIENT INDEX", "2017/03/20", "", "Withdrawn", "Private", "2", "
Master Patient Index grants Registration Version 5.3
permission to export the data dictionary of the SELF IDENTIFIED GENDER field
(#.024) in the PATIENT file (#2) in patch DG*5.3*907 to update the DESCRIPTION
of the field. The reference to "sexual orientation" was replaced with "gender
identity". The updated DESCRIPTION now reads:\n
This SELF IDENTIFIED GENDER value indicates the
patient's view of their gender identity, if
they choose to provide it.\n\n\n\n", "", "", ""], ["6749", "REJECT INFORMATION", "Routine", "OUTPATIENT PHARMACY", "2017/03/22", "APPROVED", "Active", "Controlled Subscription", "", "
Pull and return reject information from subfile 52.25.", "", "PSOREJU2", "2017/04/10"], ["6750", "ACCOUNT PROFILE FOR OUTPATIENT PHARMACY", "Routine", "ACCOUNTS RECEIVABLE", "2017/03/28", "", "Withdrawn", "Controlled Subscription", "", "
Users working Patient Medication Worklist will be able
to access the patient Account Profile report while still in the worklist. This
will aid them in determinig if the charge needs to be canceled or not.", "", "PRCAAPR1", ""], ["6751", "ACCOUNT PROFILE REPORT FOR OUTPATIENT PHARMACY", "Routine", "ACCOUNTS RECEIVABLE", "2017/03/28", "", "Withdrawn", "Controlled Subscription", "", "
Users working Patient Medication Worklist will be able
to access the patient Account Profile report while still in the worklist. This
will aid them in determinig if the charge needs to be canceled or not.", "", "PRCAAPR", ""], ["6752", "OUTPATIENT PHARMACY PATIENT INQUIRY", "Routine", "REGISTRATION", "2017/03/29", "", "Withdrawn", "Controlled Subscription", "", "
This allows users of the Patient Medication LM to do
patient inquiry without leaving the list manager", "", "DGRPD", ""], ["6753", "OUTPATIENT PHARMACY BILL INQUIRY", "Routine", "INTEGRATED BILLING", "2017/03/29", "APPROVED", "Active", "Private", "", "
This allows users of the Patient Medication LM to do
Bill Inquiry without leaving the List Manager.", "", "IBOLK", "2018/03/09"], ["6754", "DBIA6754", "Routine", "NATIONAL DRUG FILE", "2017/04/07", "", "Pending", "Controlled Subscription", "", "
This API was released with PSN*4.0*396. It displays
the Formulary Indicator and Product Text.\n
Pharmacy Data Management requests an ICR to utilize this API.", "", "PSNACT", ""], ["6755", "GMRC CALL TO POST~HMPEVNT", "Routine", "HEALTH MANAGEMENT PLATFORM", "2017/04/12", "APPROVED", "Retired", "Private", "", "
The Consult package is making a call to POST^HMPEVNT
API to sync VistA with the eHMP JSON database system when a new comment is
added to an existing consult.\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
subscribing application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************", "", "HMPEVNT", "2017/10/23"], ["6756", "ORWDAL32 APIS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/04/14", "APPROVED", "Active", "Controlled Subscription", "", "
For CPRS v32 development, the GMRA package needs access
to new OR APIs, CHKMEDS^ORWDAL32, GETPROV^ORWDAL32, & SENDALRT^ORWDAL32, which
have also been developed for CPRS v32.\n
These changes are all related to NSR 20070203 for allergy order check
enhancements and will be part of the CPRS v32 bundled release.", "", "ORWDAL32", "2017/06/06"], ["6757", "GIVE THIS DBIA A BETTER NAME THAN DBIA6757", "", "", "2017/04/25", "", "Pending", "", "", "", "", "", ""], ["6758", "ETSRXN", "Routine", "ENTERPRISE TERMINOLOGY SERVICE", "2017/04/26", "APPROVED", "Active", "Supported", "", "
These API(s) allow access to the RxNorm data that is
contained in the RxNorm files in the Enterprise Terminology Services (ETS)
package.", "", "ETSRXN", "2018/06/08"], ["6759", "DGWPT BYWARD", "Remote Procedure", "REGISTRATION", "2017/05/01", "APPROVED", "Retired", "Private", "", "\n
**********************************************************************
This ICR was retired as of 10/27/17 when HMP was shut down. HMP*2.0*12
released on 10/17/17 is an informational patch outlining the steps for the
sites to shut down the application. If HMP is reactivated in the future, the
HMP project team should review the access provided by this ICR with the
custodial application before the ICR is reactivated. See VistA Document
Library (VDL) for list of retired HMP ICRs.
**********************************************************************\n\n
The Enterprise Health MGMT Platform (HMP) calls the DGWPT BYWARD RPC in order
to retreive the current list of patients for the specified ward.", "DGWPT BYWARD", "", "2017/10/18"], ["6760", "READ FILE ENTRY DATE", "File", "CONSULT/REQUEST TRACKING", "2017/05/03", "", "Withdrawn", "Private", "123", "", "", "", ""], ["6761", "Update patient demographics via HL7 w/VI", "Routine", "IMAGING", "2017/05/18", "APPROVED", "Active", "Private", "", "
VistA Imaging provides a routine type entry point that
will build and broadcast HL7 ADT A08 Patient Information Update messages to
subscribers of ADT messages.\n
A HL7 ADT A47 Change Patient Identifier List message will also be built and
broadcast for each SSN change.", "", "MAGDHLE", "2017/09/14"], ["6762", "Reminder List Rule", "File", "CLINICAL REMINDERS", "2017/05/18", "APPROVED", "Active", "Private", "810.4", "
ORDER ENTRY/RESULTS REPORTING would like to access the
Reminder List Rule file (#810.4). This will be used to update the list of
patients in an OE/RR List (commonly called CPRS Team List) using a reminder
list rule. We are requesting to be able to point to this file as well as
access the NAME field (#.01).", "", "", "2017/09/26"], ["6763", "ELIGIBILITY", "Routine", "OUTPATIENT PHARMACY", "2017/05/19", "APPROVED", "Active", "Controlled Subscription", "", "
APIs in PSOREJP1 concern third-party payer information.\n", "", "PSOREJP1", "2017/08/02"], ["6764", "DEVELOPER LOG", "Routine", "E CLAIMS MGMT ENGINE", "2017/05/19", "APPROVED", "Active", "Controlled Subscription", "", "
BPSOSL contains APIs for adding entries to the BPS LOG
file.", "", "BPSOSL", "2017/08/02"], ["6765", "DELETION OF DIC(S) VALUE FROM OPTION", "File", "KERNEL", "2017/05/22", "", "Pending", "Private", "19", "
During installation by KIDS distribution of a patch
which updates an option's definition to delete a DIC(S) value, although the
value of other fields are overlaid with the incoming values, the existing
DIC(S) value is not nulled out when the incoming value is null. The
post-install routine must include logic like invoking FILE^DIE() to remove the
value from the Option (#19) file entry.", "", "", ""], ["6766", "ESSO VALIDATE FOR FILEMAN INTEGRATED WEB SERVICE", "Routine", "KERNEL", "2017/05/22", "", "Pending", "Supported", "", "
This API allows ESSO^XUESSO4 to be called from the
DIFSMAIN routine.", "", "", ""], ["6767", "PROS ITEM LOCATION FILE ACCESS", "File", "PROSTHETICS", "2017/06/06", "APPROVED", "Active", "Private", "661.3", "
The Pros Item Location file is read during Orthotic and
Lab Work Order processing and during Stock Issue processing in order to
display the location of the selected item.", "", "", "2023/04/13"], ["6768", "IBCEF75 PROVIDER ID APIS", "Routine", "INTEGRATED BILLING", "2017/06/19", "APPROVED", "Active", "Controlled Subscription", "", "
APIs that return Provider ID information.", "", "IBCEF75", "2017/11/29"], ["6769", "SD RECEIVE OR Protocol", "Other", "SCHEDULING", "2017/06/20", "APPROVED", "Active", "Private", "", "
This agreement grants permission to Order Entry /
Result Reporting to use the protocol in order to send appointment requests to
Scheduling.", "", "", "2017/08/23"], ["6770", "OR RECEIVE Protocol", "Other", "ORDER ENTRY/RESULTS REPORTING", "2017/06/20", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement grants permission for the subscribing
packages to use the protocol OR RECEIVE to transmist updates to Order
Entry/Results reporting. The updates would be related to orders - things such
as status changes, results completed, etc.", "", "", "2017/08/23"], ["6771", "DBIA6771", "Routine", "ENROLLMENT APPLICATION SYSTEM", "2017/06/20", "APPROVED", "Active", "Private", "", "
Registration Version 5.3 has one routine DGRPD which
displays the Patient Inquiry calls DIS^EASECU to display the patient's current
LTC Copay Test status and test date.", "", "EASECU", "2017/08/09"], ["6772", "CLINICAL REMINDERS GENERIC EVALUATOR", "Routine", "CLINICAL REMINDERS", "2017/06/22", "APPROVED", ["The reminder evaluation status as a", "string value", "DUE DATE: The date the reminder is due", "LAST DONE: The date the reminder evaluation", "determines as the last time the", "reminder was completed.", "The following subscript will only be returned", "if pass in parameters specified if they", "should returned.", "^TMP($J,SUB,REMINDER,\"PRINT NAME\")=", "Reminder's print name (or name if print name", "is null) ^TMP($J,SUB,REMINDER,\"FIEVAL\")=", "Merged copy of the FIEVAL array. ^TMP($J,SUB,REMINDER,\"MAINTENANCE\",X)=", "Line X of the maintenance output.", "^TMP($J,SUB,REMINDER,\"FINDINGS\",COMPONENT REMINDER)=", "\"STATUS^DUE DATE^LAST DONE\"", "If REMINDER has the VA-REMINDER DEFINITION", "computed finding and its SAVETEMP parameter", "value is 1, then data for the COMPONENT", "REMINDER that is executed is returned under", "this node. ^TMP($J,SUB,REMINDER,\"FINDINGS\",COMPONENT REMINDER,\"FIEVAL\")=", "Merged copy of the FIEVAL array for", "COMPONENT REMINDER that is executed as a", "finding, where COMPONENT REMINDER is the", "PRINT NAME of that reminder. ^TMP($J,SUB,REMINDER,\"FINDINGS\",COMPONENT", "REMINDER,\"MAINTENANCE\",X)=", "Line X of the maintenance output for COMPONENT", "REMINDER that is executed as a finding, where", "COMPONENT REMINDER is the PRINT NAME of that", "reminder.", "Reminder Terms ^TMP($J,SUB,\"TERMS\",TERM)=RESULT", "TERM: The IEN of the entry from file 811.5,", "or the .01 of the entry from file 811.5. RESULT: 1 for the term", "applies to the patient", "or 0 the term does not apply to the", "patient.", "The following subscript will only be returned", "if pass in parameters specified if they", "should returned.", "^TMP($J,SUB,\"TERMS\",TERM,\"FIEVAL\")=Merged copy of", "the term FIEVAL array. ^TMP($J,SUB,\"TERMS\",TERM,\"DETAIL", "TEXT\",X,0)=Line", "X of the term."], "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to execute various components within the Clinical Reminders package, such as
order checks and list rules.\n
Revision History:
-3/26/25- Effective with patch PXRM*2.0*81, added Reminder Terms as an item
that can be evaluated and made it so multiple list rules can be pass to the
API.", "", "PXRMGEV", "2025/03/17"], ["6773", "DOCUMENT ACTION ANCILLARY DATA DISPLAY", "Other", "TEXT INTEGRATION UTILITIES", "2017/06/22", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribers to attach
items to the TIU DOCUMENT ACTION DISPLAY protocol, which will display an
onscreen message provided by the subscriber to TIU users when a document is
deleted, retracted or reassigned.\n
The following data is available to subscribers:
^TMP("TIUDOCDIS",$J,"PATIENT")=DFN
DFN: internal entry number of the patient in the PATIENT file (#2)
^TMP("TIUDOCDIS",$J,"VISIT")=VISIT
VISIT: internal entry number of the visit in the VISIT file (#9000010)
^TMP("TIUDOCDIS",$J,"DOCUMENT")=DOC IEN^DOC NAME
DOC IEN: internal entry number of the document in the TIU DOCUMENT file
(#8925)
DOC NAME: name of the document in the TIU DOCUMENT DEFINITION file
(#8925.1)
^TMP("TIUDOCDIS",$J,"ACTION")=ACTION
ACTION: the action taken on the document; either "DELETE", "RETRACT" or
"REASSIGN"\n
Place the text to display in the ^TMP global with the following structure:\n
^TMP("TIUDOCDIS",$J,"MESSAGES",DISPLAY)=LINE COUNT
DISPLAY: the display name of the package as it should appear to the
user; for example, "Women's Health"
LINE COUNT: total number of lines to display to the user\n
^TMP("TIUDOCDIS",$J,"MESSAGES",DISPLAY,N)=TEXT
N: line number of text, starting at one and incrementing by one
TEXT: the line of text to display. The subscriber is responsible for
ensuring that the length is not more than 80 characters as TIU
will not wrap the text that is displayed. When the text is
displayed in the CPRS GUI, it will wrap depending on the screen
size of the user's display; subscribers should not assume that
how the text is displayed in a roll and scroll environment is how
it will appear in a GUI environment.", "", "", "2017/11/21"], ["6774", "DOCUMENT ACTION NOTIFICATION", "Other", "TEXT INTEGRATION UTILITIES", "2017/06/26", "APPROVED", "Active", "Controlled Subscription", "", "
This protocol will notify subscribers when a document
is deleted, retracted or reassigned.\n
The following data is available to subscribers:
^TMP("TIUDOCAT",$J,"ACTION")=ACT
ACT: the action taken on the document; possible values are "DELETE",
"RETRACT", and "REASSIGN"\n
When ACT is "DELETE" or "RETRACT",
^TMP("TIUDOCAT",$J,"PATIENT")=DFN
DFN: internal entry number of the document's patient in the PATIENT
file (#2)
^TMP("TIUDOCAT",$J,"VISIT")=VISIT
VISIT: internal entry number of the document's visit in the VISIT file
(#9000010)
^TMP("TIUDOCAT",$J,"DOCUMENT")=DOC IEN^DOC NAME
DOC IEN: internal entry number of the document in the TIU DOCUMENT file
(#8925)
DOC NAME: name of the document in the TIU DOCUMENT DEFINITION file
(#8925.1)\n
When ACT is "REASSIGN",
^TMP("TIUDOCAT",$J,"PATIENT","OLD")=DFN
DFN: internal entry number of the document's patient in the PATIENT
file (#2) before reassignment
^TMP("TIUDOCAT",$J,"PATIENT","NEW")=DFN
DFN: internal entry number of the document's patient in the PATIENT
file (#2) after reassignment
^TMP("TIUDOCAT",$J,"VISIT","OLD")=VISIT
VISIT: internal entry number of the document's visit in the VISIT file
(#9000010) before reassignment
^TMP("TIUDOCAT",$J,"VISIT","NEW")=VISIT
VISIT: internal entry number of the document's visit in the VISIT file
(#9000010) after reassignment
^TMP("TIUDOCAT",$J,"DOCUMENT","OLD")=DOC IEN^DOC NAME
DOC IEN: internal entry number of the retracted document in the TIU
DOCUMENT file (#8925)
DOC NAME: name of the retracted document in the TIU DOCUMENT DEFINITION
file (#8925.1)
^TMP("TIUDOCAT",$J,"DOCUMENT","NEW")=DOC IEN^DOC NAME
DOC IEN: internal entry number of the reassigned document in the TIU
DOCUMENT file (#8925)
DOC NAME: name of the reassigned document in the TIU DOCUMENT
DEFINITION file (#8925.1)", "", "", "2017/11/21"], ["6775", "HMP CHECK OF %ZTSCH GLOBAL", "File", "KERNEL", "2017/06/26", "", "Withdrawn", "Private", "", "
The Enterprise Health MGMT Platform (HMP) needs to make
a check to see if a task exists in the %ZTSCH global and if the task exist, if
it is still active. HMP does this by checking to see if a lock can be obtained
for the task in %ZTSCH, if the lock can be obtained then the job is not active
and the HMP EXTRACT RESOURCE slot that is in use by that task can be cleared.", "", "", ""], ["6776", "WV APIS FOR CLINICAL REMINDERS", "Routine", "WOMEN'S HEALTH", "2017/06/26", "", "Pending", "Private", "", "
This provides a list of APIs used by the Clinical
Reminder packages for procedure tracking from the Women's Veterans files in
CPRS, effective with CPRS 31.B, patches WV*1.0*24 and PXRM*2.0*45 for SMART
alert functionality.\n\n", "", "WVRPCGF1", ""], ["6777", "OR COMPLETE ORDER", "Other", "ORDER ENTRY/RESULTS REPORTING", "2017/06/28", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this ICR is to grant access to packages
that need to subscribe to OR COMPLETE ORDER protocol. The purpose of the
protocol OR COMPLETE ORDER is to notify other packages that an order has been
marked complete in the Computerized Patient Record System.\n
The following information will be passed into the protocol in the array
ORINFO. Any subscribers will have access to it:\n
ORINFO("OR0")=0 node of the ORDER file (#100)
ORINFO("OR3")=3 node of the ORDER file (#100)
ORINFO("OR4")=4 node of the ORDER file (#100)
ORINFO("OR6")=6 node of the ORDER file (#100)
ORFINO("OR7")=7 node of the ORDER file (#100)
ORINFO("DIALOG")=Dialog IEN for the dialog used to create this order
(pointer to the ORDER DIALOG file (#101.4)
ORFINO("RESPONSES")=Responses from the 4.5 level of the ORDER file
(#100)\n
The OR COMPLETE ORDER protocol will be distributed in OR*3*397. It's called
when the RPC, ORWDXA COMPLETE is invoked.\n
Subscribing Packages will be added to the ICR as they are identified and
approved by CPRS.", "", "", "2018/09/25"], ["6778", "PROS INVENTORY TRANSACTION FILE ACCESS", "File", "PROSTHETICS", "2017/07/03", "APPROVED", "Active", "Private", "661.6", "
The Pros Inventory Transaction file is read during the
display of a Prosthetics Inventory Program (PIP) stock issue in order to
present inventory transaction information.", "", "", "2020/07/30"], ["6779", "PROSTHETIC HCPCS ITEM MASTER FILE ACCESS", "File", "PROSTHETICS", "2017/07/03", "APPROVED", "Active", "Private", "661.11", "
The Prosthetic HCPCS Item Master file is read during
the display of a Prosthetics Inventory Program (PIP) stock issue in order to
present Prosthetic HCPCS Item Master information.\n
Amended: Added 1/12/23, effective with DSSO*2.0*3, APAT requested adding
'ASHMDI' index. This is to identify the MANUFACTURER and MFG PART NO.
associated with items in Prosthetics Inventory that have a specified STATION
and PSAS HCPCS. The MANUFACTURER and MFG PART NO. are associated with the
ITEM MASTER (#441) item referenced in the "ASHMDI" index.", "", "", "2023/01/17"], ["6780", "HL7 VERSION CHECK", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "420.5", "
This integration agreement allows the DSS PeriOp
Manager to call V^SRHLU, which returns boolean value that tells whether the
HL7 messaging is compatible with 1.5 version. If the answer is yes, then no
HL7 message will be sent.", "", "SRHLU", ""], ["6781", "SURGICAL HL7 TRANSMISSION", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call MSG^SRHLZIU, which sends ZIU message for various events such
as S12 New Appointment, S13 Reschedule, S14 Modification, S15 Cancellation,
and S17 Deletion.", "", "SRHLZIU", ""], ["6782", "SURGICAL OUTGOING HL7 STANDARD SEGMENT UTILITIES", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call SRHLUO routines which contains various utility modules to
build outgoing surgery HL7 standard segments.", "", "SRHLUO", ""], ["6783", "SURGICAL OUTGOING HL7 CUSTOM SEGMENT UTILITIES 1", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call SRHLUO1 routines, which contains various utility modules to
build HL7 custom segments.", "", "SRHLUO1", ""], ["6784", "SURGICAL OUTGOING HL7 CUSTOM SEGMENT UTILITIES 2", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call SRHLUO2 routines which contains various utility modules to
build custom HL7 segments.", "", "SRHLUO2", ""], ["6785", "SURGICAL CASE LOCK/UNLOCK", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call SROUTL, which contains various utility modules including
locking, and unlocking surgical cases so that cases can be modified without
being modified by other processes.", "", "SROUTL", ""], ["6786", "SURGERY CASE'S DIVISION SETUP", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call SROUTL0 which contains various utility modules including
getting divisions of a given OR.", "", "SROUTL0", ""], ["6787", "SURGICAL CASE STATUS", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call STATUS^SROERR0 to find status about a given surgery case.", "", "SROERR0", ""], ["6788", "SURGICAL CASE STATUS II", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call DIS1^SRSBUTL to check and set new service block for surgery
availability graph.", "", "SRSBUTL", ""], ["6789", "SURGERY DRAW GRAPH", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call ^SRSGRPH to draw surgery OR room availability graph.", "", "SRSGRPH", ""], ["6790", "SURGERY CANCEL GRAPH", "Routine", "SURGERY", "2017/07/03", "", "Pending", "Private", "", "
This integration agreement allows the DSS PeriOp
Manager to call ^SRSCG to update graph when a case is cancelled.", "", "SRSCG", ""], ["6791", "ORDER CHECK TEXT", "Routine", "CLINICAL REMINDERS", "2017/07/06", "", "Pending", "Private", "", "
This integration agreement allows the subscribing
package to retrieve a portion of a reminder definition evaluation's clinical
maintenance section for inclusion in a reminder order check's text that is
displayed to an end user.", "", "PXRMCWH1", ""], ["6792", "NUMER OF DAYS IN EDD GRACE PERIOD", "Routine", "CLINICAL REMINDERS", "2017/07/06", "APPROVED", "Active", "Private", "", "
This integration agreement allows subscribers to obtain
the number of days in the Expected Due Date (EDD) grace period. The grace
period is defined as a parameter to the VA-WH PATIENT DOCUMENTATION reminder
computed finding in the VA-WH UPDATE PREGNANCY STATUS reminder definition. If
this parameter does not exist, a hard-coded default period is used.", "", "PXRMCWH1", "2021/01/21"], ["6793", "LOOK FOR ENTRIES POINTING TO VISIT ENTRIES", "File", "1", "2017/07/06", "APPROVED", "Active", "Private", "", "
This integration agreement allows the subscribing
package to determine all of the entries that point to an entry in the VISIT
file (#9000010). Read-only global access is granted to the global references
listed below.", "", "", "2017/11/15"], ["6794", "IV SOLUTIONS FILE (#52.7) PREMIX FIELD (#18) FROM PSO", "File", "PHARMACY DATA MANAGEMENT", "2017/07/13", "APPROVED", "Active", "Private", "52.7", "
VistA code decides which orders need to go through
enhanced order checking in PSODDPR* routines, including IV Fluids. This ICR
will allow the IV SOLUTION File (52.7), PREMIX field (18) to be checked from
within PSO. GLOBAL REFERENCE:
^PS(52.7,D0,0)
18 PREMIX 0;14 Direct Global Read & w/Fileman", "", "", "2017/07/26"], ["6795", "GIVE THIS DBIA A BETTER NAME THAN DBIA6795", "", "", "2017/07/13", "", "Pending", "", "", "", "", "", ""], ["6796", "DATE FORMATTING", "Routine", "CLINICAL REMINDERS", "2017/07/20", "APPROVED", "Active", "Private", "", "
Allowing Health Summary to use Clinical Reminders date
formatting will provide for a consistent display of dates in Clinical
Reminders output and the Health Summary Clinical Reminders components.\n", "", "PXRMDATE", "2017/08/07"], ["6797", "CLINICAL REMINDERS OUTPUT", "Routine", "CLINICAL REMINDERS", "2017/07/20", "APPROVED", "Active", "Private", "", "
Allowing Health Summary to use the Clinical Reminders
text formatting routines provides for a consistent display of Clinical
Reminders output in Health Summary Clinical Reminders components and Clinical
Reminders.\n", "", "PXRMFMTO", "2017/08/07"], ["6798", "UPDATE STATUS OF HL7 MESSAGE", "Routine", "HEALTH LEVEL SEVEN", "2017/07/24", "", "Pending", "Private", "", "
This ICR will update the status of the entry in the
Message Text File and log an event for errors.", "", "HLTF0", ""], ["6799", "GENERATE OUTGOING HL7 MESSAGE", "Routine", "HEALTH LEVEL SEVEN", "2017/07/24", "", "Pending", "Private", "", "
This ICR allows the creation of an outgoing HL7 message
and returns a value if there is an error while creating the message.", "", "HLTP", ""], ["6800", "HL7 DE-ESCAPE DELIMITERS", "Routine", "HEALTH LEVEL SEVEN", "2017/07/24", "", "Pending", "Private", "", "
This ICR will allow the conversion of HL7 escape
characters to original characters including field separator, component
separator, repetition separator, escape characters, and subcomponent
separator.", "", "HLTPCK2A", ""], ["6801", "GET ORDER RESULTS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/07/24", "", "Pending", "Private", "", "
This ICR allows the return of results information for
orders such as lab, consult, and x-ray.", "", "ORCXPND1", ""], ["6802", "GET ORDER RESULTS BY ID", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/07/24", "", "Pending", "Private", "", "
This ICR allows the return of order results when an
input with order ID is passed in.", "", "ORWOR", ""], ["6803", "GET EVENT DELAYED ORDER LIST FOR PATIENT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/07/24", "", "Pending", "Private", "", "
This ICR allows the return of a list of orders that are
event delayed.", "", "ORWORR", ""], ["6804", "GET PATIENT ENCOUNTER DATA", "Routine", "PCE PATIENT CARE ENCOUNTER", "2017/07/24", "", "Pending", "Private", "", "
This ICR allows the return of all information about one
encounter in a global array.", "", "PXKENC", ""], ["6805", "SC PATIENT LOOKUP", "Routine", "SCHEDULING", "2017/07/24", "", "Pending", "Private", "", "
This ICR allows the return of patient information using
a lookup value.", "", "SCUTBK11", ""], ["6806", "REMINDER DIALOG SEARCHER REPORT APIS", "Routine", "CLINICAL REMINDERS", "2017/07/25", "APPROVED", "Active", "Private", "", "
This routine provides two APIs that receives either a
finding item or a list of finding items. This routine will search through the
REMINDER DIALOG file, file #801.41. It will return any reminder dialog that
contains the finding item in a written report format.\n\n", "", "PXRMDLR3", "2022/11/22"], ["6807", "UPDATE THE EPISODE OF CARE FILE", "Routine", "CLINICAL REMINDERS", "2017/07/25", "", "Pending", "Private", "", "
This ICR allows a calling application to send data to
the cascade file to either create an open cascade or add data to the open
cascade. This ICR also allows a calling application to request the open
cascade be closed.\n\n", "", "PXRMEOC", ""], ["6808", "Determine if radiology procedure is for breast image", "Routine", "CLINICAL REMINDERS", "2017/08/01", "APPROVED", "Active", "Private", "", "
This ICR provide a way to determine if a Radiology
Procedure is for a Breast Image, by using Reminder Term. If the Reminder Term
has a taxonomy assigned to it the API will check the taxonomy for CPT and
HCPCS codes.\n
Amendments: 10/20/22: Added the EARLDATE and BLDTARR components. These were
introduced in PXRM*2.0*71, which was part of the SMART enhancements included
in CPRS v31b.", "", "PXRMPRAD", "2022/10/27"], ["6809", "Erroneously entered", "", "VENDOR - AUDIOFAX, INC.", "2017/08/01", "", "Withdrawn", "", "", "", "", "", ""], ["6810", "CAPRI Call to VAFCPTAD", "Routine", "REGISTRATION", "2017/08/08", "", "Pending", "Controlled Subscription", "", "", "", "VAFCPTAD", ""], ["6811", "GET TEAM, USERS, AND PRINTER FROM FILE #100.21", "File", "ORDER ENTRY/RESULTS REPORTING", "2017/08/14", "APPROVED", "Active", "Private", "100.21", "
Text Integration Utilities (TIU) needs read access via
Fileman to 3 fields of the OE/RR LIST file (#100.21) in order to find a team
list name, its users, and the printer where alerts are printed. Additionally,
access to the "B" cross reference is requested to find quickly the team's IEN.\n", "", "", "2017/09/21"], ["6812", "REGISTRATION FILE USED BY BCMA - DG(43", "File", "REGISTRATION", "2017/08/21", "APPROVED", "Active", "Private", "43", "
The BAR CODE MED ADMIN (BCMA) needs to extract the
MULTIDIVISION MED CENTER? data from the MAS PARAMETERS file (#43) for use in
the routine PSBMD to determine if a facility is multidivisional.", "", "", "2017/09/06"], ["6813", "XUS GET TOKEN", "Remote Procedure", "KERNEL", "2017/08/23", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC returns a handle to a token that can be used
instead of an Access/Verify code authentication to sign on a new process by a
user that is currently authenticated and active.", "XUS GET TOKEN", "", "2017/08/30"], ["6814", "MAIL GROUP REMOTE MEMBER DELETION", "File", "MAILMAN", "2017/09/12", "APPROVED", "Active", "Private", "3.812", "
Accounts Receivable needs a ONE-TIME ONLY Integration
Agreement to allow deletion of remote members from a mail group. Since no
utility exists to delete a remote member from the mail group file, the
following access is requested:\n
1. The ability to Fileman read ^XMB(3.8) using $$FIND1^DIC
2. The ability to Fileman/global read the remote member subfile 3.812
in global ^XMB(3.8,,6)
3. The ability to remove the remote members from a specific mail group
using the ^DIK utility.\n
This would be done once, in the Post-install routine RCP321, to update the
RCDPE AUDIT mail group.", "", "", "2017/09/26"], ["6815", "SURGICAL OUTBOUND HL7 GENERATION UTILITY FOR NTE", "Routine", "SURGERY", "2017/09/14", "", "Pending", "Private", "", "
SURGICAL OUTBOUND HL7 GENERATION UTILITY FOR NTE will
allow DSS Integration Framework to generate an NTE segment based on OBR
segment. NTE segment contains comments and other free texts written by care
providers.", "", "SRHLVUI2", ""], ["6816", "SURGERY CONFIGURATION FILE ACCESS", "File", "SURGERY", "2017/09/14", "", "Pending", "Private", "133.2", "
This integration agreement will allow the DSS
Integration Framework to iterate through the list in ^SRO(133.2) global as
well as look up its internal entry number by TEXT through the use of "AC"
cross reference. NO direct reads or writes to the globals will be done. The
primary purpose of the ICR is to iterate this file in D0 node (1,2,3...etc),
and "AC" cross reference.\n
^SRO(133.2,D0) Uses $O to iterate the surgery file\n
File 133.2 "AC" cross-reference used to look up by TEXT", "", "", ""], ["6817", "ORDERABLE LOOKUP ORDERABLE ITEMS", "File", "ORDER ENTRY/RESULTS REPORTING", "2017/09/14", "", "Pending", "Private", "101.43", "
This integration agreement will allow the DSS CyberREN
to check whether the primary node exists, as well as look up internal entry
number with NAME field through the use of "B" cross reference. No direct reads
or writes to the globals will be done. The primary purpose of the ICR is to
check whether the node exists using $D, and calculate the internal entry
number given its name.", "", "", ""], ["6818", "ORDER SAVE RESPONSES", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/09/14", "", "Pending", "Private", "", "
ORDER SAVE RESPONSES will allow the DSS CyberREN to
take responses in ORDIALOG() and save into ^OR(100,ORIFN,4.5)", "", "ORCSAVE", ""], ["6819", "ORDER BUILD AND SAVE ORDER TEXT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/09/14", "", "Pending", "Private", "", "
ORDER BUILD AND SAVE ORDER TEXT will allow the DSS
CyberREN to build and save order text from ORDIALOG() into ORDER file.", "", "ORCSAVE1", ""], ["6820", "ORDER TRIGGER UNSIGNED ORDER NOTIFICATION", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/09/14", "", "Pending", "Private", "", "
ORDER TRIGGER UNSIGNED ORDER NOTIFICATION will allow
the DSS CyberREN to send a notification for unsigned orders.", "", "ORCSIGN", ""], ["6821", "ORDER LOAD ORDERS FOR LAB TEST", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2017/09/14", "", "Pending", "Private", "", "
ORDER LOAD ORDERS FOR LAB TEST will allow the DSS
CyberREN to take lab test as an input and return all orders that have the lab
test.", "", "ORWDLR32", ""], ["6822", "OUTPATIENT ENCOUNTER LOOKUP", "Routine", "SCHEDULING", "2017/09/14", "", "Pending", "Private", "", "
OUTPATIENT ENCOUNTER LOOKUP will allow the DSS CyberREN
to take patient, appointment date/time, hospital location, as well as visit
file pointer and return all outpatient encounter IENs matching the given
criteria.", "", "SDVSIT2", ""], ["6823", "Points to PXRMD(811.5)", "File", "CLINICAL REMINDERS", "2017/09/14", "", "Pending", "Private", "811.5", "
This agreements documents the package that have
permission to point to the Reminder Term file, file #811.5 from within their
own package files.\n\n", "", "", ""], ["6824", "ACCESS TO WV(790.1", "File", "WOMEN'S HEALTH", "2017/09/14", "", "Pending", "Private", "790.1", "
This agreements documents the usages of the package
that have permission to point to the WV PROCEDURE file, file #790.1 from
within their own package files.", "", "", ""], ["6825", "CHANGE NAME OF OPTION IBCNR RELEASE OF INFORMATION", "File", "KERNEL", "2017/10/18", "APPROVED", "Active", "Private", "19", "
eBusiness product owners wish to change the name of the
existing option IBCNR RELEASE OF INFORMATION to IBCNR ROI SENSITIVE DRUG MGMT
as part of patch IB*2.0*617. Permission is required to Accomplish this name
change using a pre-install routine. This agreement is one time only and
expires with the installation of IB*2.0*617.", "", "", "2018/03/06"], ["6826", "SCHEDULE AN OPTION SILENTLY SET 'USER TO RUN TASK' FIELD", "File", "KERNEL", "2017/10/18", "APPROVED", "Active", "Private", "19.2", "
The VistA Radiology/Nuclear Medicine (RIS) application
requests permission to schedule a RIS option with the 'USER TO RUN TASK' field
(#11) in the OPTION SCHEDULING (#19.2) file.\n
The Kernel option 'RESCH^XUTMOPT()' or 'Set Up Option Schedule' option does
not define an input parameter for the 'USER TO RUN TASK' field.\n
The RIS must guarantee that the user identified discontinuing orders in the
RAD/NUC MED ORDERS (#75.1) file is the same user recorded as discontinuing
that same order in the Computerized Patient Record System (CPRS) ORDER (#100)
file.", "", "RAIPS135", "2017/12/11"], ["6827", "YTQ SAVE ADMIN", "Remote Procedure", "MENTAL HEALTH", "2017/10/23", "APPROVED", "Active", "Private", "", "
This RPC is used to add or edit a Mental Health
Administration File entry. The subscripted YS array is passed to the RPC
containing all of the values needed to create or update the entry.", "YTQ SAVE ADMIN", "", "2017/11/08"], ["6828", "ACCESS TO READ EKG FILE", "File", "CLINICAL PROCEDURES", "2017/10/30", "APPROVED", "Active", "Private", "691.5", "
Users need the ability to access the patient EKG
Date/Time, Summary and AUTO Instrument Diagnosis using a Health Summary
Object. Routines will use the "C" cross reference to obtain data for a
patient using a Fileman call.", "", "", "2018/04/12"], ["6829", "V.O.R. TRANSACTION FILE ACCESS", "File", "PROSTHETICS", "2017/11/13", "APPROVED", "Active", "Private", "667.3", "
The ADVANCED PROSTHETICS ACQUISITION TOOL requests
permission to use a FileMan API to edit a returned/condemned item in the
V.O.R. TRANSACTION (#667.3) FILE.", "", "", "2019/09/10"], ["6830", "PURCHASE CARD RECONCILE FILE ACCESS", "File", "IFCAP", "2017/11/13", "APPROVED", "Active", "Private", "440.6", "
The ADVANCED PROSTHETICS ACQUISITION TOOL requests
permission to use FileMan APIs to read from and write to the PURCHASE ORDER
RECONCILE file (#440.6).", "", "", "2019/06/13"], ["6831", "CPT AND DIAGNOSIS UPDATE", "Routine", "REGISTRATION", "2017/11/13", "", "Pending", "Private", "", "
CPT AND DIAGNOSIS UPDATE is an API that contains
modules that update CPT codes and diagnosis codes. ERR module allows printing
of error message based on flag parameter for DATA2PTF.", "", "DGAPI", ""], ["6832", "GET NUMBER OF FILERS", "Routine", "HEALTH LEVEL SEVEN", "2017/11/13", "", "Pending", "Private", "", "
GET NUMBER OF FILERS will return the number of filers
that are currently running.", "", "HLCSUTL2", ""], ["6833", "ICD EFFECTIVE DATE AND STATUS FOR CODE/MODIFIER", "Routine", "DRG GROUPER", "2017/11/13", "", "Pending", "Private", "", "
ICD EFFECTIVE DATE AND STATUS FOR CODE/MODIFIER will
return an effective date and status for code/modifier.", "", "ICDSUPT", ""], ["6834", "EXECUTE PCE'S EVENT", "Routine", "PCE PATIENT CARE ENCOUNTER", "2017/11/13", "", "Pending", "Private", "", "
EXECUTE PCE'S EVENT is an integration agreement that
lets the caller execute PCE'S event.", "", "PXKMAIN", ""], ["6835", "CONVERT INTERNAL NAME TO HL NAME", "Routine", "SURGERY", "2017/11/13", "", "Pending", "Private", "", "
CONVERT INTERNAL NAME TO HL NAME is an integration
agreement that allows the caller to convert internal entry number into an HL7
CN data type.", "", "SRHLU", ""], ["6836", "PRINT SURGERY CASE STATUS", "Routine", "SURGERY", "2017/11/13", "", "Pending", "Private", "", "
PRINT SURGERY CASE STATUS allows the caller to print
surgery cases.", "", "SROP1", ""], ["6837", "LEXICON CODES", "File", "LEXICON UTILITY", "2017/11/13", "", "Pending", "Private", "757.02", "
LEXICON CODES contain codes, their classification
sources (such as ICD), and some flags.", "", "", ""], ["6838", "SUBSET DEFINITIONS", "File", "LEXICON UTILITY", "2017/11/13", "", "Pending", "Private", "757.2", "
SUBSET DEFINITIONS contains various terminologies and
codes related to certain areas defined in other LEX globals.", "", "", ""], ["6839", "PXRMRPCG CANCEL REMOTE PROCEDURE", "Remote Procedure", "CLINICAL REMINDERS", "2017/11/15", "", "Pending", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the PXRMRPCG CANCEL remote procedure call.", "", "", ""], ["6840", "PXRMRPCG GENFUPD", "Remote Procedure", "CLINICAL REMINDERS", "2017/11/15", "", "Pending", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the PXRMRPCG GENFUPD remote procedure call.\n
Subscribers of this agreement should also subscribe to agreement #6841
PXRMRPCG GENFVALD REMOTE PROCEDURE. The PXRMRPCG GENFVALD remote procedure
should be called before calling the PXRMRPCG GENFUPD remote procedure to
ensure that data passed in to the latter call is valid.", "PXRMRPCG GENFUPD", "", ""], ["6841", "PXRMRPCG GENFVALD", "Remote Procedure", "CLINICAL REMINDERS", "2017/11/15", "", "Pending", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the PXRMRPCG GENFVALD remote procedure call.", "PXRMRPCG GENFVALD", "", ""], ["6842", "PXRMRPCG VIEW REMOTE PROCEDURE", "Remote Procedure", "CLINICAL REMINDERS", "2017/11/15", "", "Pending", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the PXRMRPCG VIEW remote procedure call.", "", "", ""], ["6843", "WVRPCOR COVER", "Remote Procedure", "WOMEN'S HEALTH", "2017/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR COVER remote procedure.", "WVRPCOR COVER", "", "2017/11/20"], ["6844", "WVRPCOR DETAIL", "Remote Procedure", "WOMEN'S HEALTH", "2017/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR DETAIL remote procedure.", "WVRPCOR DETAIL", "", "2017/11/20"], ["6845", "WVRPCOR EIE", "Remote Procedure", "WOMEN'S HEALTH", "2017/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR EIE remote procedure.", "WVRPCOR EIE", "", "2017/11/20"], ["6846", "WVRPCOR POSTREP", "Remote Procedure", "WOMEN'S HEALTH", "2017/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR POSTREP remote procedure.", "WVRPCOR POSTREP", "", "2017/11/20"], ["6847", "WVRPCOR REASONS", "Remote Procedure", "WOMEN'S HEALTH", "2017/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR REASONS remote procedure.", "WVRPCOR REASONS", "", "2017/11/20"], ["6848", "WVRPCOR SAVEDATA", "Remote Procedure", "WOMEN'S HEALTH", "2017/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR SAVEDATA remote procedure.", "WVRPCOR SAVEDATA", "", "2017/11/20"], ["6849", "WVRPCOR SITES", "Remote Procedure", "WOMEN'S HEALTH", "2017/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call the WVRPCOR SITES remote procedure.", "WVRPCOR SITES", "", "2017/11/20"], ["6850", "PTF ICD DIAGNOSIS NOTIFICATION", "Other", "REGISTRATION", "2017/11/24", "APPROVED", "Active", "Controlled Subscription", "", "
The DG PTF ICD DIAGNOSIS NOTIFIER protocol notifies
subscribers when an International Classification of Diseases (ICD) diagnosis
code is added, modified or removed for entries within the PTF file (#45).\n
The following data is available to subscribers:\n
^TMP("DG PTF ICD NOTIFIER",$J,"DFN")=DFN
DFN: internal entry number of the patient in the PATIENT file (#2).\n
^TMP("DG PTF ICD NOTIFIER",$J,TYPE,"IENS")=IENS
TYPE: The activity type; possible values are "DISCHARGE", "MOVEMENT",
"SERVICE" and "SERVICE46". "DISCHARGE" codes are from the
PRINCIPAL DIAGNOSIS field and the SECONDARY DIAGNOSIS series of
fields in the PTF file (#45). "MOVEMENT" codes are from the ICD
series of fields in the 501 sub-file (#45.02) in the PTF file
(#45). "SERVICE" code is from the PRIMARY DIAGNOSIS field in the
CPT RECORD DATE/TIME sub-file (#45.06) in the PTF file (#45).
"SERVICE46" codes are from the PRIMARY DIAGNOSIS field and the
SECONDARY DIAGNOSIS series of fields in the INPATIENT CPT CODE file
(#46).
IENS: The internal entry number string identifying the record in which
the associated codes are stored.\n
^TMP("DG PTF ICD NOTIFIER",$J,TYPE,FIELD,"OLD")=ICDP
This is how the field appeared in the file before the change was made.
FIELD: This is an abbreviation denoting which field the code came from.
The following table should assist in determining which field a
code came from:
TYPE FIELD Field Name
-----------------------------------------------------
DISCHARGE PDX PRINCIPAL DIAGNOSIS
DISCHARGE SDXnn SECONDARY DIAGNOSIS nn (nn is a whole number)
DISCHARGE PDX-P1986 PRINCIPAL DIAGNOSIS pre 1986
MOVEMENT DXnn ICD nn (nn is a whole number)
SERVICE PDX PRIMARY DIAGNOSIS
SERVICE46 PDX PRIMARY DIAGNOSIS
SERVICE46 SDX0n SECONDARY DIAGNOSIS n (n is a whole number)
ICDP: Internal entry number of the diagnosis code in the ICD DIAGNOSIS
file (#80).\n
^TMP("DG PTF ICD NOTIFIER",$J,TYPE,FIELD,"NEW")=ICDP
This is how the field appeared in the file after the change was made.\n
When a code is added, the "OLD" value will be blank and the "NEW" value will
not be. When a code is deleted, the "OLD" value will not be blank and the
"NEW" value will be. When a code is changed, both the "OLD" and "NEW" values
will not be blank.", "", "", "2018/06/19"], ["6851", "GET FMS DOCUMENT STATUS FOR AR BATCH PAYMENT", "Routine", "ACCOUNTS RECEIVABLE", "2017/12/08", "APPROVED", "Active", "Private", "", "
The subroutine FMSSTAT^RCDPUREC is used to get the
status and FMS document given the internal entry number from the AR BATCH
PAYMENT FILE [#344]. There is a need to access this call from within the
INTEGRATED BILLING (IB) package to provide the FMS DOCUMENT number and STATUS
for information on IB reports and worklists.", "", "RCDPUREC", "2018/02/08"], ["6852", "UPLOADED EQUIPMENT INVENTORY", "Routine", "ENGINEERING", "2017/12/12", "", "Pending", "Private", "", "
This integration agreement allows ABOVE PAR to call
ENGINEERING routine ENEQNX3 to verify the ITEM is in the database and to
process a PM item.", "", "ENEQNX3", ""], ["6853", "ITEM - VERIFY ITEM MASTER NUMBER", "Routine", "IFCAP", "2017/12/13", "", "Withdrawn", "Private", "", "
This integration agreement allows ABOVE PAR to call
IFCAP routine PRCVITMU to verify the ITEM MASTER item number.", "", "PRCVITMU", ""], ["6854", "VENDOR - CHECK ONE VENDOR'S CHECKSUM", "Routine", "IFCAP", "2017/12/13", "", "Pending", "Private", "", "
This integration agreement allows ABOVE PAR to call
ONECHK routine PRCVNDR to verify the vendor record and, if necessary, send
updated data to DynaMed.", "", "PRCVNDR", ""], ["6855", "ENGINEERING COMPUTER PORT FILE ACCESS", "File", "ENGINEERING", "2017/12/13", "APPROVED", "Active", "Private", "6910.1", "
The ENGINEERING COMPUTER PORT FILE #6910.1 is read
during:
- Print Location label setup. The location format and location data
will be used if the port has a custom setup.
- Print Equipment label setup. The equipment format and equipment
data will be used if the port has a custom setup.\n
Above PAR Ad-Hoc Reporting includes the ENGINEERING COMPUTER PORT FILE
#6910.1. Ad-Hoc functionality provides the ability to select fields from the
file for display on user-defined reports. Ad-Hoc offers only FileMan read
access and only if the user has permission to view the file.", "", "", "2022/09/06"], ["6856", "COUNTER FILE ACCESS", "File", "IFCAP", "2017/12/13", "", "Withdrawn", "Private", "422.2", "
Above PAR requests permission to update the COUNTER
(#422.2) file when sending a FMS VENDOR REQUEST to Austin.\n
Above PAR will create a COUNTER entry to support the FMS VENDOR REQUEST if the
COUNTER NAME (.01) is not defined.\n
Above PAR will increment the COUNTER field COUNTER (1).", "", "", ""], ["6857", "AUTOMATED SUPPLY STATION PROCESSING QUEUE FILE ACCESS", "File", "IFCAP", "2017/12/13", "APPROVED", "Active", "Private", "447.1", "
ABOVE PAR requests permission to check the AUTOMATED
SUPPLY STATION PROCESSING QUEUE (#447.1) file's STATION NUMBER (#1) and
SECONDARY INVENTORY POINT (#2) fields.", "", "", "2018/11/21"], ["6858", "INVENTORY BALANCES FILE ACCESS", "File", "IFCAP", "2017/12/13", "APPROVED", "Active", "Private", "445.1", "
The INVENTORY BALANCE (#445.1) file stores the
beginning monthly balances for the items stored in the inventory points,
GENERIC INVENTORY (#445) file. ABOVE PAR checks determines whether the
inventory item balance is available and will create the balance record if the
item has no balance record.", "", "", "2018/12/07"], ["6859", "FD DOCUMENT LOG FILE ACCESS", "File", "ENGINEERING", "2017/12/13", "APPROVED", "Active", "Private", "6915.5", "
The FD DOCUMENT LOG (#6915.5) file is referenced by
RPCs DSIYUTL4 FAPCHK CHK FOR FAP and DSIYUTL1 EQUPDT UPDATE EQUIP to determine
if an FP document exists.", "", "", "2022/09/12"], ["6860", "MAG IHE SWITCH FOR HL7 ADT MESSAGES", "File", "IMAGING", "2017/12/19", "", "Under Revision", "Private", "2006.1", "
Radiology requests access to the IMAGING SITE
PARAMETERS file (#2006.1), field IHE PACS HL7 INTERFACE ACTIVE (#3.01) to
determine if the broadcast of ADT messages are permitted at a facility. ADT
messages can be broadcast by running the new RA ADT menu option that will be
available with patch RA*5.0*137.", "", "", "2017/12/21"], ["6861", "GIVE THIS DBIA A BETTER NAME THAN DBIA6861", "", "", "2018/01/12", "", "Pending", "", "", "", "", "", ""], ["6862", "GIVE THIS DBIA A BETTER NAME THAN DBIA6862", "", "", "2018/01/12", "", "Pending", "", "", "", "", "", ""], ["6863", "PSO Medication Profile", "Routine", "OUTPATIENT PHARMACY", "2018/01/16", "APPROVED", "Active", "Private", "", "
Allow ECME routine to access Medication Profile
information from Outpatient Pharmacy.", "", "PSOPMP0", "2018/02/05"], ["6864", "READ ACCESS TO DD(200", "File", "1", "2018/01/17", "APPROVED", "Active", "Private", "200", "
This is a one-time agreement via patch XU*8.0*687 to
clean up a cross reference on two fields, MAIL CODE (#28) and SERVICE/SECTION
(#29) of the NEW PERSON File (#200). This agreement will cover the removal of
the E cross reference on Field 28. The code to remove the cross reference is:\n
N XUHIT,XUOUT,XUERR,XUXREF
S (XUHIT,XUXREF)=0
F S XUXREF=$O(^DD(200,28,1,XUXREF)) Q:('+XUXREF)!(XUHIT) D
. I $P($G(^DD(200,28,1,XUXREF,0)),U,2)="E" D
.. S XUHIT=1
.. D DELIX^DDMOD(200,28,XUXREF,"K","XUOUT","XUERR")
.. ;
.. ; No error, xRef deleted
.. I '$D(XUERR) D MES^XPDUTL("The E cross reference was deleted.") Q
.. ;
.. ; Error encountered, xRef not deleted.
.. D MES^XPDUTL("ERROR encountered deleting the E cross reference.")
;
D:'XUHIT MES^XPDUTL("The E cross reference was not found.")
;
Q", "", "", "2018/02/16"], ["6865", "HLOASUB1", "Routine", "HEALTH LEVEL SEVEN", "2018/01/19", "", "Pending", "Private", "779.2", "
Radiology needs access to clean up radiology entries
from file HLO APPLICATION REGISTRY as KIDS does not have delete logic in place
for the 'Delete at Site' action on this file. A ticket [I18129151FY18] has
been submitted for this issue.\n
HLO Application Registry File access is needed for patch RA*5.0*144.", "", "HLOASUB1", ""], ["6866", "IFCAP API: BACKGROUND BATCH PRINT CODE SHEETS", "Routine", "IFCAP", "2018/01/23", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call ^PRCFACB
when batching code sheets for inventory transactions.", "", "PRCFACB", "2018/11/29"], ["6867", "IFCAP API: BACKGROUND RELEASE OF CODE SHEETS", "Routine", "IFCAP", "2018/01/23", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call ^PRCFACBT to
transmit code sheets.", "", "PRCFACBT", "2018/11/29"], ["6868", "IFCAP API - BUILD AND TRANSMIT CODE SHEET", "Routine", "IFCAP", "2018/01/23", "APPROVED", "Active", "Private", "", "
This integration agreement allows the call ^PRCFACX2
when creating ISMS code sheet - BUILD AND TRANSMIT CODE SHEET when items are
deleted from the Supply Fund Warehouse inventory.", "", "PRCFACX2", "2018/11/29"], ["6869", "ALERT CRITICAL TEXT LOOKUP AND EDIT", "File", "KERNEL", "2018/01/24", "APPROVED", "Active", "Controlled Subscription", "8992.3", "\n
Kernel Alerts do not have any APIs that enable a package to edit its own
Alert Critical text. Therefore, for the purpose of adding/editing alert
critical text, permission is granted to:\n
1. Look up alert critical text using VA FileMan APIs, such as ^DIC or
$$FIND1^DIC.\n
2. Add/edit data in the ALERT CRITICAL TEXT (#8992.3) file using VA
FileMan APIs such as ^DIE, UPDATE^DIE or FILE^DIE.\n\n
NOTICE: Adding an entry with Critical Text will report any Alert
containing that text as critical. Careful analysis is necessary to
confirm changes will not cause malfunction of any VistA alerts. When
creating a new entry in the ALERT CRITICAL TEXT (#8992.3) file, it is
recommended the associated package be indicated in the CREATING PACKAGE
(#.03) field. Inquiries regarding the critical alert text can be
directed to the development team for the respective VistA application,
if a package development team exists for the application. Finally, the
description included in the ALERT CRITICAL TEXT (#8992.3) file
PACKAGE-ID (#.02) field VA FileMan Data Dictionary should be observed
to determine if it must be defined. That field's description indicates
that data in this field can further screen alerts from being reported
as critical. Its use should be understood when adding entries to the
ALERT CRITICAL TEXT (#8992.3) file.", "", "", "2018/02/27"], ["6870", "BILLING ACCESS TO DENTAL HISTORY", "File", "DENTAL", "2018/01/28", "APPROVED", "Active", "Private", "228.1", "
The automated billing routines (IBCD*) need access to
DENTAL HISTORY (#228.1) file to get the necessary information for billing
non-service connected dental work to third party payers via EDI X12 837D
(Dental) transactions.", "", "", "2018/02/21"], ["6871", "BILLING ACCESS TO TREATMENT PLAN TRANSACTION/EXAM", "File", "DENTAL", "2018/01/28", "APPROVED", "Active", "Private", "228.2", "
The automated billing routines (IBCD*) need access to
TREATMENT PLAN TRANSACTION/EXAM (#228.2) file to get the necessary information
for billing non-service connected dental work to third party payers via EDI
X12 837D (Dental) transactions.", "", "", "2018/02/21"], ["6872", "CLV BYPASS PARAMETER", "Routine", "SCHEDULING", "2018/02/04", "", "Withdrawn", "Supported", "", "
This supported DBIA covers an API that will return a
value that indicates whether a patient should be asked for Camp Lejeune
eligibility.\n
The master value is stored in the PARAMETER DEFINITION file (#8989.51) in the
SD CLV BYPASS PARAMETER entry.\n
The business side requirements included a parameter to be installed and
implemented across the board for the Camp Lejeune project. They do not want
ANY package to display Camp Lejeune information AT ALL if this master value is
ON. This IA will allow packages to call this API and determine if the
parameter is enabled.", "", "SDCLVMN", ""], ["6873", "DG OTH ELIGIBILITY PATIENT STATUS", "Routine", "REGISTRATION", "2018/02/13", "APPROVED", "Active", "Private", "", "
The purpose of this API is to return an array of text
for CPRS to display the following information on the CPRS button at the top of
the screen and in the pop-up window associated with this button when the user
clicks on it:\n
- Other Than Honorable discharge (OTH) eligibility status for two categories
of OTH patients - EMERGENT MH OTH and EXTENDED MH OTH in order to display it
in CPRS header. The OTH status is calculated by Registration API based on the
data stored in the PATIENT file (#2) and OTH ELIGIBILITY PATIENT file (#33).\n
- Presumptive Psychosis (PP) status based on the settings in the PATIENT file
(#2) and in the INSURANCE VERIFICATION PROCESSOR file (#355.33)\n
- Inactive Patient Record Flags (PRF) assigned to the patient and a history of
PRF changes.", "", "DGOTHBTN", "2018/05/29"], ["6874", "DGPF DBRS DATA", "Routine", "REGISTRATION", "2018/02/13", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this API is to facilitate the retrieval
of the Disruptive Behavior Reporting System (DBRS) numbers. The DBRS numbers
are stored in VistA in the file PRF ASSIGNMENT FILE (#26.13).", "", "DGPFDBRS", "2018/05/29"], ["6875", "Repoint or Delete Existing File Entry", "Routine", "1", "2018/02/15", "APPROVED", "Active", "Supported", "", "", "", "DITP", "2018/03/05"], ["6876", "Check for Existing Pointers", "Routine", "1", "2018/02/15", "APPROVED", "Active", "Supported", "", "
The CHKPT^DIUTL API will find all entries that point to
a record.", "", "DIUTL", "2018/03/05"], ["6877", "Read access to HL7 Message Text file for capacity planning.", "File", "HEALTH LEVEL SEVEN", "2018/02/22", "APPROVED", "Active", "Private", "772", "
The purpose of this IA is to allow packages to read the
HL7 Message Text (#772) file directly. KMP routines will aggregate message
metrics for analysis and capacity planning.", "", "", "2018/03/08"], ["6878", "Read access to FILE 773 for capacity planning.", "File", "HEALTH LEVEL SEVEN", "2018/02/22", "APPROVED", "Active", "Private", "773", "
The purpose of this IA is to allow packages to read the
HL7 Message Administration (#773) file directly. KMP routines will aggregate
message metrics for analysis and capacity planning.", "", "", "2018/03/08"], ["6879", "CREATE BREAKOUT CODES", "Routine", "IFCAP", "2018/02/26", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition
Tool (APAT) to call BREAK^PRCHFPDS to create BREAKOUT CODE (#442.16)
sub-file entries in the AMOUNT (#442.1) sub-file of the PROCUREMENT &
ACCOUNTING TRANSACTIONS (#442) file.", "", "PRCHFPDS", "2019/06/12"], ["6880", "XUS MVI NEW PERSON GET", "Remote Procedure", "KERNEL", "2018/02/26", "APPROVED", "Active", "Private", "", "
The Master Veteran Index (MVI) team requests permission
to use the following KERNEL Remote Procedure Call (RPC) [XUS MVI NEW PERSON
GET], which will search for and return an existing entry, if it exists, from
the NEW PERSON File (#200) to the MVI system. Use of this RPC will provide MVI
with an immediate path to move forward to view the Identity Access Management
(IAM) data in VistA to support 2 Factor Authentication (2FA) until future
technologies become available in the production VistA environments.", "XUS MVI NEW PERSON GET", "", "2018/03/28"], ["6881", "XUS MVI NEW PERSON UPDATE", "Remote Procedure", "KERNEL", "2018/02/26", "APPROVED", "Active", "Private", "", "
The Master Veteran Index (MVI) team requests permission
to use the following KERNEL Remote Procedure Call (RPC) [XUS MVI NEW PERSON
UPDATE], which will update select fields to correct issues for an existing
entry in the NEW PERSON File (#200) from the MVI system. Use of this RPC will
provide MVI with an immediate path to move forward to manage the Identity
Access Management (IAM) data in VistA to support 2 Factor Authentication (2FA)
until future technologies become available in the production VistA
environments.", "XUS MVI NEW PERSON UPDATE", "", "2018/03/28"], ["6882", "Read access to HLO Message Body file for capacity planning", "File", "HEALTH LEVEL SEVEN", "2018/02/26", "APPROVED", "Active", "Private", "777", "
The purpose of this IA is to allow subscribing packages
to read the HLO Message Body (#777) file directly. KMP routines will
aggregate message metrics for analysis and capacity planning.", "", "", "2018/03/09"], ["6883", "Read access to HLO Messages file for capacity planning", "File", "HEALTH LEVEL SEVEN", "2018/02/26", "APPROVED", "Active", "Private", "778", "
The purpose of this IA is to allow subscribing packages
to read the HLO Messages (#778) file directly. KMP routines will aggregate
message metrics for analysis and capacity planning.", "", "", "2018/03/09"], ["6884", "GMRC UPDATE TO THE APPLICATION PARAMETERS FILE", "File", "HEALTH LEVEL SEVEN", "2018/03/05", "", "Withdrawn", "Private", "771", "
GMRC is requesting a one time update to set the site
number in the HL7's table for the Application Parameter entry in the HL7
APPLICATION PARAMETER FILE (#771) during the post install of patch
GMRC*3.0*99.", "", "GMRCPOST99", ""], ["6885", "GMRC UPDATE TO THE HL LOGICAL LINK FILE", "File", "HEALTH LEVEL SEVEN", "2018/03/05", "", "Pending", "Private", "870", "
GMRC requests a one time update as part of the patch
GMRC*3.0*99 post install to make an update to the HL LOGICAL LINK FILE (#870)
to add the INSTITUTION (#.02), DNS DOMAIN (#.08), AUTO START (#4.5), TCP/IP
ADDRESS (#400.01), TCP/IP PORT (#400.02) to the GMRCHCP Link entry.", "", "", ""], ["6886", "GMRC UPDATE TO THE PROTOCOL FILE", "File", "KERNEL", "2018/03/05", "", "Withdrawn", "Private", "101", "
GMRC requests a one time update to the PROTOCOL FILE
(#101) to edit the GMRC EVSEND OR Protocol to add the GMRC CONSULTS TO HCP
Protocol as an Item.", "", "", ""], ["6887", "UNIT OF ISSUE FILE ACCESS (#420.5)", "File", "IFCAP", "2018/03/05", "APPROVED", "Active", "Private", "420.5", "
Allow direct read of file 420.5, UNIT OF ISSUE.", "", "", "2018/03/07"], ["6888", "NPIUSED", "Routine", "KERNEL", "2018/03/13", "APPROVED", "Active", "Controlled Subscription", "", "", "", "XUSNPI1", "2018/03/14"], ["6889", "NEW PERSON PHARMACY FIELDS", "File", "KERNEL", "2018/03/14", "APPROVED", "Active", "Private", "200", "
In support of the Veterans Access, Choice, and
Accountability Act of 2014 (VACAA) and to address Patient Safety concerns for
non-VA providers whose affiliation is not currently available to CPRS,
Outpatient Pharmacy requests permission to populate via VA FileMan APIs the
following fields which are not currently populated by the $$VACAA^XUESSO4()
API that created the entries.\n
If the NEW PERSON (#200) file entries need to be backed out, the Non-VA
Provider Inactivate [PSO NON-VA PROVIDER INACTIVATE] option may be used. This
option will populate the DISUSER (#7) field with "YES". The INACTIVE DATE
(#53.4) and TERMINATION DATE (#9.2) fields will be populated with the previous
day's date so that the providers will be immediately inactive. The REMARKS
(#53.9) field will contain a comment that the entry was inactivated by this
option.", "", "", "2018/04/23"], ["6890", "OR EVSEND DVBA", "Other", "ORDER ENTRY/RESULTS REPORTING", "2018/03/15", "", "Pending", "Private", "", "", "", "", ""], ["6891", "MVAH Insurance", "File", "INTEGRATED BILLING", "2018/03/21", "", "Pending", "Controlled Subscription", "355.33", "
This IA is for the mobilehealth package to be able to
submit insurance information to the insurance buffer for processing\n", "", "", ""], ["6892", "VISTA RADIOLOGY UPDATES DD (CROSS REFERENCE #)", "File", "1", "2018/03/21", "APPROVED", "Active", "Private", "75.1", "
What follows is a VA FileMan index print for the 'DATE
DESIRED (Not guaranteed)' (75.1,21) field of the RAD/NUC MED ORDERS file.\n
There are two "AP" subscripted indices with the same set/kill logic: one
traditional, one new-style. The traditional index was left after RA*5.0*130
created the new-style "AP" index.\n
The traditional index, named "AC", should have been deleted. It was not.
RA*5.0*124 will correct this oversight.\n
Radiology is requesting a one-time Integration Agreement to walk down the
cross-reference number subscript to find the aforementioned cross- reference
number identifying the "AC" index.\n
Once the correct cross-reference number is identified Radiology will use the
supported Application Programmer Interface (API) DELIX^DDMOD to delete the
"AC" cross-reference.", "", "", "2018/03/22"], ["6893", "Updating DD 'VR' and 'VRPK' Nodes", "File", "1", "2018/03/22", "APPROVED", "Active", "Private", "200", "
IB*2.0*582 sent the entire data dictionary for the NEW
PERSON (#200) file. This caused the 'VR' node to be changed from "8.0" to
"2.0" and the 'VRPK' node to be changed from "XU" to "IB" in the data
dictionary.\n
This ICR is a onetime only request for patch XU*8.0*687 to restore the fields
to their orignal state of "8.0" for 'VR' and "XU" for 'VRPK'. This will be
done via a direct set:\n
S ^DD(200,0,"VR")="8.0"
S ^DD(200,0,"VRPK")="XU"", "", "", "2018/04/02"], ["6894", "HDI COLLECT SDOS", "Routine", "HEALTH DATA & INFORMATICS", "2018/03/27", "APPROVED", "Active", "Controlled Subscription", "", "
API for collecting Standards Development Organization
(SDO) codes from Laboratory based on items in the ORDERABLE ITEMS File
(#101.43)", "", "HDISDOC", "2018/10/30"], ["6895", "HDI READ ORDERABLE ITEMS File (#101.43)", "File", "ORDER ENTRY/RESULTS REPORTING", "2018/03/27", "APPROVED", "Active", "Private", "101.43", "
Allows Health Data & Informatics (HDI) to read the
following fields in the ORDERABLE ITEMS File (#101.43) in support of the HDI
SDO API effort.", "", "", "2018/10/29"], ["6896", "HDI READ PHARMACY ORDERABLE ITEM FILE (#50.7)", "File", "PHARMACY DATA MANAGEMENT", "2018/03/27", "", "Pending", "Private", "50.7", "
Allows Health Data & Informatics (HDI) to read the
following fields in the PHARMACY ORDERABLE ITEM File (#50.7) in support of the
HDI SDO API effort.", "", "", ""], ["6897", "HDI READ PHARMACY DOSAGE FORM FILE (#50.606)", "File", "PHARMACY DATA MANAGEMENT", "2018/03/27", "", "Pending", "Private", "50.606", "
Allows Health Data & Informatics (HDI) to read the
following fields in the PHARMACY DOSAGE FORM File (#50.606) in support of the
HDI SDO API effort.", "", "", ""], ["6898", "HDI READ PHARMACY MASTER DOSAGE FORM FILE (#50.60699)", "File", "PHARMACY DATA MANAGEMENT", "2018/03/27", "", "Pending", "Private", "50.60699", "
Allows Health Data & Informatics (HDI) to read the
following fields in the PHARMACY MASTER DOSAGE FORM File (#50.60699) in
support of the HDI SDO API effort.", "", "", ""], ["6899", "HDI READ PHARMACY DRUG FILE (#50)", "File", "PHARMACY DATA MANAGEMENT", "2018/03/27", "", "Pending", "Private", "50", "
Allows Health Data & Informatics (HDI) to read the
following fields in the PHARMACY DRUG File (#50) in support of the HDI SDO API
effort.", "", "", ""], ["6900", "HDI READ PHARMACY VA PRODUCT FILE (#50.68)", "File", "NATIONAL DRUG FILE", "2018/03/27", "", "Pending", "Private", "50.68", "
Allows Health Data & Informatics (HDI) to read the
following fields in the PHARMACY VA PRODUCT File (#50.68) in support of the
HDI SDO API effort.", "", "", ""], ["6901", "HDI READ LABORATORY SERVICE LABORATORY TEST FILE (#60)", "File", "LAB SERVICE", "2018/03/27", "APPROVED", "Active", "Private", "60", "
Allows Health Data & Informatics (HDI) to read the
following fields in the LABORATORY SERVICE LABORATORY TEST File (#60) in
support of the HDI SDO API effort.", "", "", "2018/05/01"], ["6902", "HDI READ MASTER LABORATORY TEST FILE (#66.3)", "File", "LAB SERVICE", "2018/03/27", "APPROVED", "Active", "Private", "66.3", "
Allows Health Data & Informatics to read (HDI) the
following fields in the LABORATORY SERVICE MASTER LABORATORY TEST File (#66.3)
in support of the HDI SDO API effort.", "", "", "2018/05/01"], ["6903", "PCE USAGE OF FILE 409.4", "Routine", "SCHEDULING", "2018/03/29", "", "Pending", "Controlled Subscription", "409.4", "
The Patient Care Encounter (PCE) has authority to use
the BYPASS ACTION REQUIRED LOG file (# 409.4).\n
An API is used to call routine BYPASS^SDCLVMN(PXUPAT,PXUHLOC,PXUDT,PXUTLVST)
to file the data into the BYPASS ACTION REQUIRED LOG file #409.4.", "", "SDCLVMN", ""], ["6904", "DBIA6904", "File", "PCE PATIENT CARE ENCOUNTER", "2018/04/09", "", "Pending", "Private", "9999999.64", "
This integration agreement authorizes global reference
to the zeroith node of the following file for purposes of retrieving pieces
1-11 and usage of the "B" cross reference.", "", "", ""], ["6905", "Option DG G&L CHANGES VIEW used on external menus", "Other", "REGISTRATION", "2018/04/10", "APPROVED", "Active", "Private", "", "
Allow the G&L view changes option (DG G&L CHANGES VIEW)
to be assigned to menus on namespaces outside of DG.", "", "", "2018/05/29"], ["6906", "DBIA 6906", "File", "INTEGRATED BILLING", "2018/04/10", "", "Pending", "Private", "19625", "
This ICR is used to file new insurance data fields from
ICB to the DSIV ICB AUDIT (#19625) file that are not part of the INSURANCE
BUFFER (#355.33) file so that they may be updated as part of buffer processing
by insurance verifiers.", "", "", ""], ["6907", "IB FM ACCESS TO PSRX FOR SHRPE", "File", "OUTPATIENT PHARMACY", "2018/04/10", "", "Withdrawn", "Controlled Subscription", "52", "
Read w/Fileman", "", "", ""], ["6908", "MAILMAN SET FROM", "Routine", "MAILMAN", "2018/04/18", "", "Pending", "Private", "", "
This integration agreement allows Enterprise
Manager/Watchdog to call SETFROM in routine XMD to verify and define the FROM
User prior to calling to send the message.
Code reference D SETFROM^XMD(.DSIWFROM,.DSIWXMIN)", "", "XMD", ""], ["6909", "HL LOWER LEVEL PROTOCOL TYPE", "File", "HEALTH LEVEL SEVEN", "2018/04/18", "", "Pending", "Private", "869.1", "
This IA allows WATCHDOG to verify the HL LOWER LEVEL
PROTOCOL TYPE prior to submitting the Protocol to taskman. The IA will access
the BACKGROUND ROUTINE and ENVIRONMENT CHECK ROUTINE in order to verify the
processing routine and run the environment check routine prior to submitted
the task.", "", "", ""], ["6910", "BUILD VI HL7 ORM MESSAGE FOR CP CHECK-IN OR CANCELLATION", "Routine", "IMAGING", "2018/04/30", "", "Pending", "Private", "", "
VistA Imaging's (MAG) CLINPROC^MAGDHOWP is called by
MDHL7BH to build and broadcast VistA Imaging HL7 ORM (order) messages for a
check-in or cancellation events in the Clinical Procedure (MD) application.", "", "MAGDHOWP", ""], ["6911", "SWAP CP INSTRUMENT ORDER # w/ IMAGING CONSULT ACCESSION #", "Routine", "IMAGING", "2018/04/30", "", "Pending", "Private", "", "
VistA Imaging software has been enhanced to replace the
CP Instrument Order Number with the VistA Imaging consults Accession Number.
This greatly improves interoperability between Clinical Procedures and VistA
Imaging CPRS Consult Request Tracking.", "", "MAGDFCNV", ""], ["6912", "READ ACCESS TO DIC(13", "File", "REGISTRATION", "2018/05/03", "APPROVED", "Active", "Private", "13", "
Income Verification Match (IVM) Version 2.0 uses the
"C" cross reference of the RELIGION file (#13) with the following code:
$O(^DIC(13,"C",code,0)) to obtain the internal entry number of the religion
code for storage.\n", "", "", "2018/12/03"], ["6913", "READ ACCESS TO THE DIC(11", "File", "REGISTRATION", "2018/05/03", "APPROVED", "Active", "Private", "11", "
Income Verification Match (IVM) Version 2.0 uses the
"B" cross of the MARITAL STATUS file (#11) to get the internal entry number of
the marital status with the following code: $O(^DIC(11,"B",IVMFLD,0)) where
variable IVMFLD is the marital status name.\n", "", "", "2018/12/03"], ["6914", "Lab References to Alert Tracking File", "File", "KERNEL", "2018/05/09", "APPROVED", "Active", "Private", "8992.1", "
Lab will search the Alert Tracking file to determine if
an alert was sent for a Lab case after it was verified by a pathologist.", "", "", "2018/05/14"], ["6915", "Parameter Definition File Access", "File", "TOOLKIT", "2018/05/04", "APPROVED", "Active", "Private", "8989.51", "
Permission requested for initial release of DSSO 2.0\n
Due to namespace conversion of the Advanced Prosthetics Acquisition Tool
(APAT) product from DSIVA to DSSO, it is necessary to convert the existing
DSIVA-namespaced parameter definitions to the new DSSO namespace.\n
For this, there will be a one-time installation routine which will utilize the
"B" cross-reference of the PARAMETER DEFINITION FILE (#8989.51) to loop
through each instance of a DSIVA-namespaced parameter. In this loop, each
parameter NAME and DISPLAY NAME will have DSIVA replaced with DSSO using
FileMan API FILE^DIE.\n
To prepare for the need to back out, there is also a one-time routine which
will utilize the "B" cross-reference of the PARAMETER DEFINITION FILE
(#8989.51) to loop through each instance of a DSSO-namespaced parameter. In
this loop, each parameter NAME and DISPLAY NAME will have DSSO replaced with
DSIVA using FileMan API FILE^DIE.", "", "", "2018/06/05"], ["6916", "APAT READ/WRITE ACCESS TO NEW PERSON FILE", "File", "KERNEL", "2018/05/15", "APPROVED", "Active", "Private", "200", "
This is a one-time request for the initial release of
DSSO 2.0.\n
The Advanced Prosthetics Acquisition Tool (APAT) must migrate from namespace
DSIVA to namespace DSSO. Because of this, the Primary and Secondary menu
options have been renamed.\n
The post-installation routine will search for users that have PRIMARY MENU
OPTION set to DSIVA APAT and will change the PRIMARY MENU OPTION to DSSO APAT.
Also, if a user has DSIVA APAT in the SECONDARY MENU OPTIONS multiple, then
DSSO APAT will be added to that multiple.\n
APAT requests permission to use FileMan API FIND^DIC with index AP to identify
those users with PRIMARY MENU OPTION set to DSIVA APAT. FileMan API FILE^DIE
will be used to change the PRIMARY MENU OPTION to DSSO APAT.\n
APAT requests permission to use FileMan API FIND^DIC with index AD to identify
those users with DSIVA APAT in the SECONDARY MENU OPTIONS multiple. FileMan
API FILE^DIE will be used to add DSSO APAT to the SECONDARY MENU OPTIONS
multiple.\n
In a future build, FileMan API FIND^DIC using index AD will be used to
identify all users with secondary menu option DSIVA APAT, and this secondary
menu option will be deleted from the SECONDARY MENU OPTIONS multiple of each
identified user using FileMan API FILE^DIE.\n
If back-out is needed, APAT requests permission to change the PRIMARY MENU
OPTION to DSIVA APAT if a user's PRIMARY MENU OPTION is DSSO APAT. This will
be accomplished in a similar manner using FileMan APIs FIND^DIC and FILE^DIE.", "", "", "2018/05/31"], ["6917", "CCR&A USE OF VAFHLIN1", "Routine", "REGISTRATION", "2018/06/04", "APPROVED", "Active", "Controlled Subscription", "", "
The Community Care Referral and Authorizations (CCR&A)
calls the EN^VAFHLIN1 API in order to retrieve a patient's insurance
information and format it in HL7 format. This data is transmitted with the
CCR&A consult request for billing purposes.", "", "VAFHLIN1", "2018/08/14"], ["6918", "PSS50P66", "Routine", "PHARMACY DATA MANAGEMENT", "2018/05/29", "", "Pending", "Supported", "", "
The purpose of this ICR is to grant the ability to
return information related to the DOSAGE FORM file (#50.606).", "", "PSS50P66", "2018/12/27"], ["6919", "OPTION FILE ACCESS", "File", "KERNEL", "2018/05/30", "APPROVED", "Active", "Private", "19", "
This is a one-time request for the initial release of
DSSO 2.0.\n
The Advanced Prosthetics Acquisition Tool (APAT) must migrate from namespace
DSIVA to namespace DSSO. Because of this, the post-installation routine must
verify the existence of both options "DSIVA APAT" and "DSSO APAT" in the
OPTION FILE (#19) when adding option "DSSO APAT" to users who currently have
the "DSIVA APAT" option as a PRIMARY MENU OPTION or SECONDARY MENU OPTIONS in
the NEW PERSON FILE (#200). To accomplish this, direct global reads through
the "B" cross-reference using $ORDER are used for each Option NAME.", "", "", "2018/05/31"], ["6920", "DBIA1052-D", "Routine", "1", "2018/06/05", "APPROVED", "Active", "Private", "", "
KIDS needs to call the VA FileMan DIFROM Server
routines and Compiler routines. These calls are used to update the Data
Dictionaries, Templates, Forums, and Functions at a site during the
installation of a package.", "", "DIFROMSR", "2018/06/05"], ["6921", "INQUIRE OPTION FOR MENU MAN", "Routine", "1", "2018/06/05", "APPROVED", "Active", "Private", "", "
Allows Inquire type option for Menu Man", "", "DIP1", "2019/03/08"], ["6922", "GIVE THIS DBIA A BETTER NAME THAN DBIA6922", "File", "REGISTRATION", "2018/06/08", "", "Pending", "Private", "", "", "", "", ""], ["6923", "CAMP LEJEUNE STATUS INDICATOR", "Routine", "REGISTRATION", "2018/06/12", "", "Withdrawn", "Supported", "", "
This supported DBIA covers an API that will return a
value that indicates whether the patient has Camp Lejeune exposure.", "", "DGUTL3", ""], ["6924", "UPDATE TECHNICAL FIELDS FOR CLINICAL PROCEDURES", "File", "TEXT INTEGRATION UTILITIES", "2018/06/13", "APPROVED", "Active", "Private", "8925.1", "
Clinical Procedures requires TIU DOCUMENT DEFINITION
(#8925.1) fields COMMIT ACTION (#4.1) and POST-SIGNATURE CODE (#4.9) be set
when a clinical procedure is configured for High Volume. Local staff do not
have access to edit these fields through the normal TIU Document Definitions
menu options as programmer access is required.\n
Clinical Procedures will verify the title is inactive before updating the two
fields with a value of 'Q' (or remove the 'Q'). Local staff will be required
to INACTIVATE the title and REACTIVATE the title as needed.", "", "", "2018/06/13"], ["6925", "HLO SUBSCRIPTION REGISTRY (#779.4) READ NAME (#.01) FIELD", "File", "HEALTH LEVEL SEVEN", "2018/06/14", "APPROVED", "Active", "Controlled Subscription", "779.4", "
With the release of MAG*3.0*208 the VistA Imaging
application requests the permission to read the name of the HLO SUBSCRIPTION
REGISTRY record.", "", "", "2018/06/14"], ["6926", "GMRC PROCEDURE - CP UTILITY", "File", "CONSULT/REQUEST TRACKING", "2018/06/14", "APPROVED", "Active", "Private", "123.3", "
Clinical Procedures package will do a lookup on the
GMRC PROCEDURE file (#123.3) for the consult procedure to clinical procedure
conversion utility. Clinical Procedures will set the CLINICAL PROCEDURE field
(#.04) as part of the conversion.", "", "", "2018/06/19"], ["6927", "REQUEST SERVICES LOOKUP FOR CP UTILITIES", "File", "CONSULT/REQUEST TRACKING", "2018/06/14", "APPROVED", "Active", "Private", "123.5", "
CLINICAL PROCEDURES will do a lookup on the REQUEST
SERVICES file (#123.3) for the consult to clinical procedure conversion
utilities.", "", "", "2018/06/19"], ["6928", "CP DICOM INTEROPERABILITY", "File", "CLINICAL PROCEDURES", "2018/06/15", "APPROVED", "Active", "Private", "702.09", "", "", "", "2018/06/15"], ["6929", "CP DICOM INTEROPERABILITY TRANSACTIONS", "File", "CLINICAL PROCEDURES", "2018/06/15", "APPROVED", "Active", "Private", "702", "", "", "", "2018/06/15"], ["6930", "CP DICOM INTEROPERABILITY DEFINITIONS", "File", "CLINICAL PROCEDURES", "2018/06/15", "APPROVED", "Active", "Private", "702.01", "", "", "", "2018/06/15"], ["6931", "CP DICOM INTEROPERABILITY RETURN SSAN FOR CLIN SPEC", "Routine", "IMAGING", "2018/06/15", "APPROVED", "Active", "Private", "", "
This extrinsic function will return a site-specific
accession number for clinical specialties. GMRCIEN is the CPRS Consult Request
Tracking GMRC IEN from the REQUEST/CONSULTATION file (#123).", "", "MAGDFCNV", "2018/06/15"], ["6932", "CP DICOM INTEROPERABILITY BUILD HL7 MESSAGE", "Routine", "IMAGING", "2018/06/15", "APPROVED", "Active", "Private", "", "
This API builds the VistA Imaging procedure HL7 ORM
(order) message using the VistA Imaging formatted accession number. The API
may conditionally return the HL7 ORM message body for Clinical Procedures'
use.", "", "MAGDHOWP", "2018/06/15"], ["6933", "TIU LINK SECONDARY VISIT", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2018/06/18", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU LINK SECONDARY VISIT", "", "2018/06/19"], ["6934", "ENCOUNTER FILE XREF BY PATIENT/DATE", "File", "SCHEDULING", "2018/06/19", "APPROVED", "Active", "Controlled Subscription", "409.68", "
This integration agreement is needed to determine
whether an appointment made using the mobile scheduling application by either
the veteran or staff is considered a follow-up appointment.", "", "", "2018/06/20"], ["6935", "CLINICAL REMINDER TEXT FORMATTING APIs", "Routine", "CLINICAL REMINDERS", "2018/06/22", "APPROVED", "Active", "Controlled Subscription", "", "
Clinical Reminders has a set of text formatting APIs,
this ICR allows other packages to use that functionality.\n
Revision History:
05/08/2024 Added the component FORMAT, available with PXRM*2.0*67. ORDER
ENTRY/RESULTS REPORTING was added as a subscriber, effective with
OR*3.0*508.", "", "PXRMTEXT", "2018/06/26"], ["6936", "REMINDER SPONSOR", "File", "CLINICAL REMINDERS", "2018/06/26", "APPROVED", "Active", "Private", "811.6", "
Specifying who the "owner" is of a PCE data type
facilitates the maintenance and management of the data type. When there are
questions about the data type's definition or usage, the owner can provide the
answers. The Reminder Sponsor file, #811.6, was created for this purpose and
because it is common for the owner of Clinical Reminders content (definitions,
terms, etc.) to also be the owner of the related PCE data types, allowing PCE
to point to and read from file #811.6 provides a consistent mechanism for
managing ownership.\n
This ICR allows PCE to point to file #811.6 and read the following fields:\n", "", "", "2018/06/26"], ["6937", "VACAA NON-VA PROVIDER BULK LOAD", "Routine", "KERNEL", "2018/06/29", "", "Pending", "Private", "", "
Bulk-load non-VA entities and providers to be
identified in VistA when documenting patient care.\n
On August 7, 2014, the President signed into law PL 113-146, the Veterans
Access, Choice, and Accountability Act of 2014 (VACAA). The law offers an
additional authority for VHA to expand current capacity and ensure that
Veterans have timely access to high-quality care. The law creates a new
paradigm for providing health care, set forth in the Veterans Choice program
provisions within Title I Section 101 of VACAA. VA is utilizing a Contractor
to provide health care and third party administrative (TPA) services set forth
through VACAA Section 101. As a result of this law, VA must upload a list of
non-VA medical care providers into the VistA system in order to maintain an
accurate and updated list of non-VA providers in the Choice program.", "", "XUSNPI", ""], ["6938", "Add Additional NCPDP Fields to a Claim", "Routine", "E CLAIMS MGMT ENGINE", "2018/07/03", "APPROVED", "Active", "Private", "", "
BPSRES1 allows the user to add to a claim NCPDP fields
not already on the payer sheet.", "", "BPSRES1", "2018/07/26"], ["6939", "Billing Related Functions", "Routine", "E CLAIMS MGMT ENGINE", "2018/07/03", "APPROVED", "Active", "Private", "", "
BPSPRRX5 contains subroutines related to secondary
billing.", "", "BPSPRRX5", "2018/07/26"], ["6940", "CODING COMPLETED", "File", "VENDOR - DOCUMENT STORAGE SYS", "2018/07/10", "", "Pending", "Private", "19610.5", "
This agreement allows Integrated Billing (IB) to
determine if coding has completed for an entry in the VEJD PFCS LINKAGE DATA
(#19610.5) file.\n
IB will use the VISIT # to perform a look up into this file to get the CCM
CODING STATUS (#20) field.", "", "", ""], ["6941", "PSSUTIL HAZ", "Routine", "PHARMACY DATA MANAGEMENT", "2018/07/11", "", "Pending", "Supported", "", "
This IA is provided by PDM (Pharmacy Data Management)
as an API Function to return Hazardous To Handle and Hazardous To Dispose
indication flags per a drug in the DRUG file (#50) or Orderable Item in the
PHARMACY ORDERABLE ITEM file (#50.7).\n
Note: Hazardous indications are fields stored in the PSNDF file VA PRODUCT
file (#50.68).\n
If any drug has a Hazardous to Handle or Dispose indication, then
the Pharmacy Orderable Item (OI) and any drugs pointing to that same
OI will be considered Hazardous for the same indications.", "", "PSSUTIL", ""], ["6942", "PSSUTIL HAZWARNG", "Routine", "PHARMACY DATA MANAGEMENT", "2018/07/11", "", "Pending", "Supported", "", "
This DBIA is provided by PDM (Pharmacy Data Management)
as an API to return the Hazardous To Handle and Hazardous To Dispose alert
text generated for a specific drug in the DRUG file (#50) appropriate for the
package that is calling it.\n
Note: Hazardous indications are fields stored in the PSNDF file VA PRODUCT
file (#50.68).\n
If any drug has a Hazardous to Handle or Dispose indication, then
the Pharmacy Orderable Item (OI) and any drugs pointing to that same
OI will be considered Hazardous for the same indications.", "", "PSSUTIL", ""], ["6943", "CODER COMMENTS", "File", "VENDOR - DOCUMENT STORAGE SYS", "2018/07/11", "", "Pending", "Private", "19640.32", "
This agreement allows Integrated Billing (IB) to
determine if there are any entries in the DSIP CODER COMMENT HISTORY
(#19640.32) file for a VISIT IFN (#.01) field which is a pointer to the VISIT
(#9000010) file.", "", "", ""], ["6944", "ENG SITE PARAMETERS", "File", "ENGINEERING", "2018/07/19", "APPROVED", "Active", "Private", "6910", "
Above Par requests permission to read the ENG INIT
PARAMETERS FILE #6910 to retrieve Engineering site parameters for view and use
in Barcode printing, determining Shop Key value, and Station Number value.\n
Above PAR's Adhoc Reporting module includes ENG INIT PARAMETERS FILE (#6910)
in the list of files and fields accesible from user defined reports.", "", "", "2018/08/16"], ["6945", "LOOKUP USING B CROSS REFERENCE", "File", "KERNEL", "2018/07/27", "", "Pending", "Private", "200", "
The Virtual Patient Record (VPR) application needs to
be able to return the Internal Entry Number (IEN) of a user to the consuming
applications (such as Joint Legacy Viewer). VPR has the user name, but not the
IEN. This ICR will grant them access to do a lookup on the 'B' cross
reference of the NEW PERSON (#200) file.", "", "", ""], ["6946", "SDMXCORE", "Routine", "SCHEDULING", "2018/07/27", "", "Pending", "Private", "", "
Core tags for MASS project.", "", "SDMXCORE", ""], ["6947", "SDMXERRO", "Routine", "SCHEDULING", "2018/07/27", "", "Pending", "Private", "", "
Outgoing Error Interface tags.", "", "SDMXERRO", ""], ["6948", "DGMXVLD", "Routine", "REGISTRATION", "2018/08/01", "", "Pending", "Private", "", "
Incoming HL7 message PID validation tags.", "", "DGMXVLD", ""], ["6949", "DGMXHL7", "Routine", "REGISTRATION", "2018/08/01", "", "Pending", "Private", "", "
Tags for building HL7 messages to send to MASS.", "", "DGMXHL7", ""], ["6950", "SDMXLKRQ", "Routine", "SCHEDULING", "2018/08/01", "", "Pending", "Private", "", "
Locking and Resequencing Tags.", "", "SDMXLKRQ", ""], ["6951", "ORMXFMT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2018/08/01", "", "Pending", "Private", "", "
Order formatting.", "", "ORMXFMT", ""], ["6952", "ORMXTR", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2018/08/01", "", "Pending", "Private", "", "
HL7 order message triggering.", "", "ORMXTR", ""], ["6953", "PROVIDER NARRATIVE API", "Routine", "PCE PATIENT CARE ENCOUNTER", "2018/08/03", "APPROVED", "Active", "Private", "", "", "", "PXAPI", "2018/08/06"], ["6954", "DBIA 6954", "File", "PCE PATIENT CARE ENCOUNTER", "2018/08/10", "", "Pending", "Private", "9000010", "
VIA requests the ability to update the DATA SOURCE
field (#81203) of the VISIT file (#9000010).\n
A CPRS RPC is used to create and sign a new note which defines the data source
as TIU. Then an update is sent to add note information with the actual data
source as part of the data. PCE keeps the original data source unless there is
a change in the patient's location. VIA requests to update the DATA SOURCE
field with the calling application at the time the update to the note is sent.\n", "", "", ""], ["6955", "DBIA 6955", "Routine", "PCE PATIENT CARE ENCOUNTER", "2018/08/10", "", "Pending", "Private", "", "
VIA requests this ICR to utilize SOURCE^PXAPIUTL to add
a new source if not previously defined.\n
As part of adding progress notes, a CPRS RPC is used to create and sign a new
note which defines the data source as TIU. Then an update is sent to add note
information with the actual data source as part of the data. PCE keeps the
original data source unless there is a change in the patient's location. VIA
requests to call SOURCE^PXAPIUTL to add a new source if update to the note is
sent.\n
This ICR will be utilized in conjunction with DBIA 6954.", "", "PXAPIUTL", ""], ["6956", "Security Key Description", "File", "KERNEL", "2018/08/15", "", "Pending", "Private", "19.1", "
The ORDER ENTRY/RESULTS REPORTING package requests read
access to the Description field of the Security Key file.", "", "", ""], ["6957", "NEED TO SIGN DOCUMENT?", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2018/08/20", "", "Pending", "Private", "", "
This RPC checks to see if the current user needs to
sign the passed-in document IEN.", "", "", ""], ["6958", "RETREIVE NEXT COUNTER NUMBER FILE 422.2", "Routine", "IFCAP", "2018/08/31", "APPROVED", "Active", "Private", "", "
This integration agreement allows the ABOVE PAR
package to call COUNTER^PRCFACP to retrieve next Counter number from file
COUNTER (422.2).", "", "PRCFACP", "2018/11/01"], ["6959", "CP CONVERSION UTILITY", "File", "IMAGING", "2018/09/07", "APPROVED", "Active", "Private", "2006.5831", "
Clinical Procedures requires read access to the
CLINICAL SPECIALTY DICOM & HL7 file (#2006.5831) to screen for consults or
procedures setup in DICOM. The screen is on the interactive lookup for
consults or procedures that are being selected to convert to Clinical
Procedures.", "", "", "2018/12/03"], ["6960", "ENG SOFTWARE OPTIONS", "File", "ENGINEERING", "2018/09/11", "", "Pending", "Private", "6910.2", "
Above Par requests permission to read the ENG SOFTWARE
OPTIONS (#6910.2) to retrieve information governing the performance of
options.\n
Above PAR's Adhoc Reporting module includes ENG SOFTWARE OPTIONS (#6910.2) in
the list of files and fields accessible from user defined reports.", "", "", ""], ["6961", "XU EPCS ADD DEA", "Remote Procedure", "KERNEL", "2018/09/12", "", "Pending", "Controlled Subscription", "", "
This RPC is designed to work with the EPCS GUI
application for editing provider DEA information for pharmacy. It will accept
inputs of a IEN for the NEW PERSON FILE #200 and a "^" delimited line of text
to be recorded.", "XU EPCS ADD DEA", "", ""], ["6962", "XU EPCS DEADOJ", "Remote Procedure", "KERNEL", "2018/09/12", "", "Pending", "Controlled Subscription", "", "
This RPC call, accepts a DEA Number as input. It calls
the DOJ/DEA Web Service to get the most recent information for the provider
which is returned to the calling program in a single string with "^" delimited
data. The values in the string are:
1 - PROVIDER NAME
2 - ADDRESS 1
3 - ADDRESS 2
4 - ADDRESS 3
5 - CITY
6 - STATE
7 - STATE POINTER
8 - ZIP CODE
9 - ACTIVITY CODE
10 - TYPE
11 - DEA NUMBER
12 - EXPIRATION DATE
13 - PROCESSED DATE
14 - DETOX NUMBER
15 - SCHDEULE II NARCOTIC
16 - SCHEDULE II NON-NARCOTIC
17 - SCHEDULE III NARCOTIC
18 - SCHEDULE III NON-NARCOTIC
19 - SCHEDULE IV
20 - SCHEDULE V", "XU EPCS DEADOJ", "", ""], ["6963", "XU EPCS REMOVE DEA", "Remote Procedure", "KERNEL", "2018/09/12", "", "Pending", "Controlled Subscription", "", "\n
Functionality to remove a DEA multiple from file #200, Field 53.21
INPUT: NPIEN - NEW PERSON FILE #200 INTERNAL ENTRY NUMBER
DEATXT - PROPERLY FORMATTED DEA NUMBER
OUTPUT: RET - 1 for SUCCESS, 0 for UNSUCCESSFUL", "XU EPCS REMOVE DEA", "", ""], ["6964", "XU EPCS DEA DUP CHECK", "Remote Procedure", "KERNEL", "2018/09/12", "", "Pending", "Controlled Subscription", "", "\n
This RPC will accept a DEA in text format, and an institutional suffix if
available. It will perform checking to determine if the DEA is being used by
another user.", "XU EPCS DEA DUP CHECK", "", ""], ["6965", "Access to ACTIVITY LOG of File 53.1", "Routine", "INPATIENT MEDICATIONS", "2018/09/14", "", "Withdrawn", "Controlled Subscription", "", "
When a unique IEN into File #53.1 (NON-VERIFIED ORDERS)
is sent into this API, then it should return a local array which holds all of
the ACTIVITY LOG information for the associated record.", "", "PSJHL5", ""], ["6966", "XU EPCS MBM", "Remote Procedure", "KERNEL", "2018/09/19", "", "Pending", "Controlled Subscription", "", "
This RPC is provided to ePCS GUI to check if the site
is setup for Meds by Mail service.", "XU EPCS MBM", "", ""], ["6967", "ORDEA ZIP", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2018/09/19", "", "Pending", "Controlled Subscription", "", "
This remote procedure call will confirm if the patient
has a valid zip code entered. This information is being verified before a
provider is able to prescribe a controlled substance.", "ORDEA ZIP", "", ""], ["6968", "XU EPCS DEALIST", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2018/09/19", "", "Pending", "Controlled Subscription", "", "
This remote procedure call will provide a list of
active DEA #s for a provider during Outpatient Pharmacy controlled substances
order entry. If there is more than one then the provider will be presented
with the list to select one, which will be associated to that order.", "XU EPCS DEALIST", "", ""], ["6969", "XUEPCSME", "Routine", "KERNEL", "2018/09/19", "", "Pending", "Controlled Subscription", "", "
The XUEPCSME routine provides functionality to retrieve
information from the DOJ/DEA web service and use a ListMan screen to enable
the Pharmacy to edit the information and link it to a provider in the NEW
PERSON FILE #200 and save the information to the DEA NUMBERS FILE #8991.9.", "", "XUEPCSME", ""], ["6970", "XUEPCSUT", "Routine", "KERNEL", "2018/09/19", "", "Pending", "Controlled Subscription", "", "
An algorithm to validate that the DEA number is
formatted correctly.", "", "XUEPCSUT", ""], ["6971", "XUEPCSED", "Routine", "KERNEL", "2018/09/19", "", "Pending", "Controlled Subscription", "", "
Returns a value in the RET variable indicating the
Meds-by-Mail System setting.", "", "XUEPCSED", ""], ["6972", "GIVE THIS DBIA A BETTER NAME THAN DBIA6972", "", "", "2018/09/19", "", "Pending", "", "", "", "", "", ""], ["6973", "PATIENT ALLERGIES file data", "File", "ADVERSE REACTION TRACKING", "2018/09/26", "APPROVED", "Active", "Private", "120.8", "
This documents data that VPR is reading from the
Patient Allergies file #120.8, in addition to the use of other supported
api's.", "", "", "2018/09/28"], ["6974", "GMR ALLERGIES CODING SYSTEMS", "File", "ADVERSE REACTION TRACKING", "2018/09/26", "APPROVED", "Active", "Private", "120.82", "
This agreement allows access to the national codes
pushed out to the GMR Allergies file #120.82 by the Native Domain
Standardization (NDS) team.", "", "", "2018/09/28"], ["6975", "SIGNS/SYMPTOMS CODING SYSTEMS", "File", "ADVERSE REACTION TRACKING", "2018/09/26", "APPROVED", "Active", "Private", "120.83", "
This agreement allows access to the national codes
pushed out to the Sign/Symptoms file #120.83 by the Native Domain
Standardization (NDS) team.", "", "", "2018/09/28"], ["6976", "DELETION OF INPUT TEMPLATES", "File", "1", "2018/09/27", "", "Pending", "Controlled Subscription", ".402", "
This integration agreement covers the deletion of input
templates used with patch DG*5.3*914 for Camp Lejeune. The pre-init routine
DGPR914 will loop through a list of input templates used for the project Camp
Lejeune and delete them. Upon installation of patch DG*5.3*914, all input
templates will be automatically recompiled.\n
Deletion of input templates will involve the following:\n
1. Using $$FIND1^DIC(.402,"","MX","INPUT TEMPLATE NAME") to get the Input
Template IEN from file #.402.\n
2. Using ^DIK to delete the input template from file #.402.", "", "", ""], ["6977", "XUS MVI NEW PERSON DATA", "Remote Procedure", "KERNEL", "2018/10/10", "APPROVED", "Active", "Private", "", "
The Master Veteran Index (MVI) team requests permission
to use the following KERNEL Remote Procedure Call (RPC) [XUS MVI NEW PERSON
DATA], which will allow the MVI system to retrieve the following '^' delimited
aggregated data for Active and/or Non-Active NEW PERSON file (#200) entries
from a 'specific' or 'all' active VistA site(s) if requested:\n
- Number of ALL Record types found
- Number of Non-Active Records
- Number of Active Records
- Number of Active Records containing a SECID
- Number of Active Records containing an Email
- Number of Active Records containing an Network Username
- Number of Visitor Records\n", "XUS MVI NEW PERSON DATA", "", "2018/10/11"], ["6978", "VPR ACCESS TO APPOINTMENTS", "File", "SCHEDULING", "2018/10/22", "APPROVED", "Active", "Private", "2.98", "
This agreement allows VPR to access fields in the
APPOINTMENT sub-file #2.98 that are not provided by the supported Scheduling
APIs.", "", "", "2018/10/26"], ["6979", "VENDOR EDIT FILE ACCESS", "File", "IFCAP", "2018/10/22", "APPROVED", "Active", "Private", "440.3", "
Consistent with IFCAP, Above PAR calls XY^%RCR to
back-up the current Vendor entry in file (#440) into a corresponding entry in
file (#440.3) so that if the user decides to cancel the update, the original
values can be restored.\n
Above PAR deletes the VENDOR EDIT entry when the user confirms that a
verification needs to be sent to Austin.", "", "", "2019/06/07"], ["6980", "TITRATION API", "Routine", "OUTPATIENT PHARMACY", "2018/10/23", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PSOUTL", "2019/02/11"], ["6981", "RESPONSES MULTIPLE", "File", "ORDER ENTRY/RESULTS REPORTING", "2018/10/24", "APPROVED", "Active", "Controlled Subscription", "100.045", "
This agreement documents VPR access to the Responses
multiple of the Orders file #100.", "", "", "2018/11/19"], ["6982", "VPR USE OF DISPLAY GROUPS", "File", "ORDER ENTRY/RESULTS REPORTING", "2018/10/24", "APPROVED", "Active", "Private", "100.98", "
This agreements document VPR access to the Display
Group file #100.98.", "", "", "2018/11/19"], ["6983", "TEXT XU REM", "Routine", "KERNEL", "2018/10/24", "", "Pending", "Private", "", "
This is just for test.", "", "", ""], ["6984", "PATIENT FILE", "File", "REGISTRATION", "2018/10/25", "APPROVED", "Active", "Private", "2", "
BAR CODE MED ADMIN package (namespace PSB) would like
to request Direct Global read access to cross reference 'CN' in the Patient
file (#2) for reporting purposes. Basically the use is to $O through the 'CN'
cross reference to get patients and wards to be displayed via a report in the
patch PSB*3.0*103.", "", "", "2018/11/13"], ["6985", "CP TRANSACTIONS DATA", "File", "CLINICAL PROCEDURES", "2018/10/26", "APPROVED", "Active", "Private", "702", "
This agreement documents VPR access to fields in the CP
Transactions file #702 that are not available via other api's.", "", "", "2018/10/31"], ["6986", "GMRA ASSESSMENT CHANGE", "Other", "ADVERSE REACTION TRACKING", "2018/10/29", "APPROVED", "Active", "Controlled Subscription", "", "
This extended action protocol is activated whenever
there is a change in a patient's adverse reaction assessment. The following
variable is defined when the protocol is activated:\n
GMRAL = Internal Entry Number (IEN) in the ADVERSE REACTION
ASSESSMENT file (#120.86)
GMRAL(0) = Contents of the FileMan X(order#) array in the new-style
AHDR cross-reference, flattened. Each caret piece number of
this node is populated from the corresponding subscript in
the X(order#) array. For example, piece 1 is populated from
the X(1) node and piece 4 is populated from the X(4) node.
Note: Reference the data dictionary for the ADVERSE
REACTION ASSESSMENT file (#120.86) for a listing of the
fields included in the AHDR cross-reference. Note that all
pieces are in internal format.", "", "", "2018/11/05"], ["6987", "PHARMACY PATIENT (#55) FILE", "File", "PHARMACY DATA MANAGEMENT", "2018/11/08", "", "Pending", "Controlled Subscription", "55", "
The Outpatient Pharmacy and CMOP packages request full
access to the PHARMACY PATIENT (#55) file. This file is used extensively
throughout our routines. Therefore, we request read and write access to the
entire file and cross references through Fileman utilities and direct
reads/writes.\n
This integration agreement replaces IA #2228.", "", "", ""], ["6988", "STATUS Portion of ORCSAVE2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2018/11/14", "", "Withdrawn", "Private", "", "
The purpose of this ICR is to grant the Outpatient
Pharmacy and CMOP packages access to the STATUS update code in ORCSAVE2.\n
Replaced by 5903.", "", "ORCSAVE2", ""], ["6989", "READ ACCESS TO ALLERGY'S DRUG INGREDIENTS", "File", "ADVERSE REACTION TRACKING", "2018/11/20", "APPROVED", "Active", "Private", "120.82", "
This integration agreement allows subscribers to read
the entries in the DRUG INGREDIENTS multiple (#4) in the GMR ALLERGIES file
(#120.82).", "", "", "2018/11/30"], ["6990", "RMIM DRIVER", "Other", "FUNCTIONAL INDEPENDENCE", "2018/11/20", "APPROVED", "Active", "Controlled Subscription", "", "
The RMIM DRIVER protocol is used to send HL7 messages
to the Functional Status and Outcomes Database (FSOD) at the Austin Automation
Center (AAC). See the FIM Technical Manual for the HL7 message
specifications.\n
This documents the protocols allowed to subscribe to this event. Supported HL7
utilities may be used to read the attached message; the message itself and HL7
application variables may not be altered.", "", "", "2018/11/29"], ["6991", "PREVIOUS ENCOUNTER DIAGNOSIS API", "Routine", "CLINICAL REMINDERS", "2018/11/27", "APPROVED", "Active", "Controlled Subscription", "", "
This API searches the V POV file for previous encounter
diagnoses for a patient using the Clinical Reminders Index.\n", "", "PXRMPDX", "2018/12/03"], ["6992", "IMMUNIZATION API FOR CLINICAL REMINDERS", "Routine", "PCE PATIENT CARE ENCOUNTER", "2018/11/27", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXPXRM1", "2018/12/03"], ["6993", "NFS CALLS REASON ORWDXC", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2018/11/30", "APPROVED", "Active", "Private", "", "
NUTRITION AND FOOD SERVICES CALLS REASON^ORWDXC TO
RETRIEVE A LIST OF REASONS TO OVERRIDE AN ORDER CHECK. THIS IS FOR TUBE
FEEDING ORDERS.\n\n", "", "ORWDXC", "2018/11/30"], ["6994", "CHKTF FHSELA1 API", "Routine", "DIETETICS", "2018/11/30", "APPROVED", "Active", "Private", "", "
CPRS CALLS $$CHKTF^FHSELA1 TO PERFORM TUBE FEEDING
ORDER CHECKS.\n", "", "FHSELA1", "2018/11/30"], ["6995", "MHV Pharmacy Data", "Routine", "MYHEALTHEVET", "2019/01/24", "", "Pending", "Controlled Subscription", "", "
This api is used to gather prescription information to
display in My HealtheVet from Prescription file #52, Pharmacy Patient file #55
and Pending Outpatient Order file #52.41.", "", "MHV52API", ""], ["6996", "File 52", "File", "OUTPATIENT PHARMACY", "2018/12/01", "", "Pending", "Private", "52", "
This is the replacement agreement for DBIA #824. It
gives permission to read various fields in the PRESCRIPTION File (#52).", "", "", ""], ["6997", "File 53", "File", "OUTPATIENT PHARMACY", "2018/12/01", "", "Pending", "Controlled Subscription", "53", "
This is the replacement agreement for DBIA 1975. It
gives permission to read various fields in the RX PATIENT STATUS File (#53).", "", "", ""], ["6998", "File 59", "File", "OUTPATIENT PHARMACY", "2018/12/01", "", "Pending", "Controlled Subscription", "59", "
This is the replacement agreement for DBIA 1976. It
gives permission for other packages to directly read and read with FileMan all
fields in the OUTPATIENT SITE File (#59).", "", "", ""], ["6999", "File 59", "File", "OUTPATIENT PHARMACY", "2018/12/01", "", "Pending", "Private", "59", "
This is the replacement agreement for DBIA #2621. It
gives permission to read various fields in the OUTPATIENT SITE File (#59).", "", "", ""], ["7000", "NEW DEA MULTIPLE", "File", "KERNEL", "2018/12/04", "APPROVED", "Active", "Private", "200", "
Outpatient Pharmacy is granted permission to
enter/edit/delete the following fields.\n
Field # Node;Piece Field Name
53.21 PS4 NEW DEA #'S Multiple #200.5321 200.5321,.01
0;1 DEA NUMBER 200.5321,.02 0;2 INDIVIDUAL DEA
SUFFIX 200.5321,.03 0;3 DEA POINTER", "", "", "2022/01/25"], ["7001", "DEA BUSINESS ACTIVITY CODES", "File", "KERNEL", "2018/12/04", "APPROVED", "Active", "Private", "8991.8", "\n
Outpatient Pharmacy is granted permission to enter/edit the following
fields.\n
Field # Node;Piece Field Name
.01 0;1 FULL BUSINESS ACTIVITY CODE
.02 0;2 BUSINESS ACTIVITY
.03 0;3 BUSINESS ACTIVITY SUB-CODE
1 1;1 BUSINESS ACTIVITY DESCRIPTION", "", "", "2022/01/25"], ["7002", "DEA NUMBERS FILE", "File", "KERNEL", "2018/12/04", "APPROVED", "Active", "Private", "8991.9", "\n
Outpatient Pharmacy is granted permission to enter/edit/delete the
following fields.\n
Field # Node;Piece Field Name
.01 0;1 DEA NUMBER
.02 0;2 BUSINESS ACTIVITY CODE
.03 0;3 DETOX NUMBER
.04 0;4 EXPIRATION DATE
.06 0;6 USE FOR INPATIENT ORDERS?
.07 0;7 TYPE
1.1 1;1 NAME (PROVIDER OR INSTITUTION)
1.2 1;2 STREET ADDRESS 1
1.3 1;3 STREET ADDRESS 2
1.4 1;4 STREET ADDRESS 3
1.5 1;5 CITY
1.6 1;6 STATE
1.7 1;7 ZIP CODE
2.1 2;1 SCHEDULE II NARCOTIC?
2.2 2;2 SCHEDULE II NON-NARCOTIC?
2.3 2;3 SCHEDULE III NARCOTIC?
2.4 2;4 SCHEDULE III NON-NARCOTIC?
2.5 2;5 SCHEDULE IV?
2.6 2;6 SCHEDULE V?
10.1 10;1 LAST UPDATED BY
10.2 10;2 LAST UPDATED DATE/TIME
10.3 10;3 LAST DOJ UPDATE DATE/TIME", "", "", "2022/01/24"], ["7003", "MPI ICN BUILD MANAGMENT FILE - LEGAL NAME FLAG", "File", "MASTER PATIENT INDEX VISTA", "2018/12/11", "", "Withdrawn", "Private", "984.8", "
The REGISTRATION package requests permission to access
the MPI ICN BUILD MANAGEMENT (#984.8) file using a direct global read. This
file contains a 'Flag' that is needed to determine how to process the
collection of an individual's legal name (or Alias) which can now exceed
VistA's limitation of 30 characters.", "", "", ""], ["7004", "MPIFNAMC - LEGAL NAME FLAG", "Routine", "MASTER PATIENT INDEX VISTA", "2018/12/11", "APPROVED", "Active", "Private", "", "
The REGISTRATION and CLINICAL INFO RESOURCE NETWORK
packages request permission to access the Application Programming Interface
(API) to retrieve the value of the 'Name Components' flag which will be used
to determine how an individual's legal name (or Alias), which can now exceed
VistA's limitation of 30 characters, is processed.", "", "MPIFNAMC", "2019/04/25"], ["7005", "TIU ANCILLARY PACKAGE MESSAGE", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2018/12/17", "APPROVED", "Active", "Controlled Subscription", "", "", "TIU ANCILLARY PACKAGE MESSAGE", "", "2019/01/29"], ["7006", "TEST", "", "AUTOMATED MED INFO EXCHANGE", "2018/12/26", "", "Withdrawn", "Controlled Subscription", "", "", "", "", ""], ["7007", "IBR TO RELEASE CHARGES FROM ACCOUNTS RECEIVABLE", "Routine", "INTEGRATED BILLING", "2019/01/17", "", "Pending", "Private", "", "
The IB routine ^IBR can be used to release "ON HOLD"
charges to ACCOUNTS RECEIVABLE (AR). E-Payments nightly process needs to use
this call as part of the first party auto-decrease logic, so that first party
charges can be released then auto-decreased when the matching third party bill
is received.", "", "IBR", "2020/03/17"], ["7008", "Entity mapping APIs", "Routine", "1", "2019/01/24", "APPROVED", "Active", "Supported", "", "
APIs that can be used with the ENTITY file (#1.5) to
retrieve data from VA FileMan files and format them in either XML or JSON.", "", "DDE", "2019/03/08"], ["7009", "DGPF PRF EVENT", "Other", "REGISTRATION", "2019/01/24", "APPROVED", "Active", "Controlled Subscription", "", "
The DGPF PRF EVENT protocol is an event protocol that
will notify subscribers when Patient Record Flags are assigned or modified.
This agreement documents the protocols allowed to subscribe to this event.\n
The following data is available to subscribers:\n
DGIEN = PRF ASSIGNMENT (#26.13) file ien
DGPRF = Output array containing assignment record field values
Subscript Field# Data
-------------- ------- ---------------------
"DFN" .01 internal^external
"FLAG" .02 internal^external
"STATUS" .03 internal^external
"OWNER" .04 internal^external
"ORIGSITE" .05 internal^external
"REVIEWDT" .06 internal^external
"NARR",line#,0 1 character string
"DBRS#",line# 2;.01 internal^external
"DBRS OTHER",line# 2;.02 internal^external
"DBRS DATE",line# 2;.03 internal^external
"DBRS SITE",line# 2;.04 internal^external", "", "", "2021/08/19"], ["7010", "IBCN NEW INSURANCE", "Other", "INTEGRATED BILLING", "2019/01/24", "", "Pending", "Controlled Subscription", "", "
The IBCN NEW INSURANCE event driver will be invoked
whenever a new insurance type entry is created in the patient file, so that
necessary actions can take place when a new insurance policy is added for a
patient.\n
This agreement documents the protocols allowed to subscribe to this event.
Supported HL7 utilities may be used to read the attached message; the message
itself and HL7 application variables may not be altered.", "", "", ""], ["7011", "LR7O AP EVSEND OR", "Other", "LAB SERVICE", "2019/01/24", "APPROVED", "Active", "Controlled Subscription", "", "
The LR7O AP EVSEND OR protocol is used to pass
pathology orders and results from Lab to CPRS and other packages.\n
This agreement documents the protocols allowed to subscribe to this event.
Supported HL7 utilities may be used to read the attached message; the message
itself and HL7 application variables may not be altered.", "", "", "2019/02/05"], ["7012", "SCMC PATIENT TEAM CHANGES", "Other", "SCHEDULING", "2019/01/24", "APPROVED", "Active", "Controlled Subscription", "", "
The SCMC PATIENT TEAM CHANGES protocol is fired off
whenever the Patient Team Assignment File (#404.42) is updated.\n
This agreement documents the protocols allowed to subscribe to this event.
Supported HL7 utilities may be used to read the attached message; the message
itself and HL7 application variables may not be altered.", "", "", "2021/08/26"], ["7013", "SCMC PATIENT TEAM POSITION CHANGES", "Other", "SCHEDULING", "2019/01/24", "APPROVED", "Active", "Controlled Subscription", "", "
The SCMC PATIENT TEAM POSITION CHANGES protocol is
fired off whenever the Patient Team Position Assignment file (#404.43) is
updated.\n
This agreement documents the protocols allowed to subscribe to this event.
Supported HL7 utilities may be used to read the attached message; the message
itself and HL7 application variables may not be altered.", "", "", "2019/02/04"], ["7014", "Entity File Cross Reference", "File", "1", "2019/01/30", "APPROVED", "Active", "Controlled Subscription", "1.5", "
The ENTITY file (#1.5) has two cross reference that
will be available to approved applications. These cross references allows an
application to lookup a record by DATA MODEL field (#.06), DISPLAY NAME field
(#.1), and DEFAULT FILE NUMBER field (#.02). Currently, there is only two
Data Models: FHIR and SDA. The cross reference will look like:\n
^DDE("FHIR",display name, file number, ien)=""
^DDE("SDA", display name, file number, ien)=""", "", "", "2019/03/08"], ["7015", "XUEPCS DATA FILE", "File", "KERNEL", "2019/02/01", "", "Pending", "Private", "8991.6", "
Outpatient Pharmacy is granted permission to enter the
following fields.\n
Field # Node;Piece Field Name
.01 0;1 NAME
.02 0;2 EDITED BY
.03 0;3 FIELD EDITED
.04 0;4 ORIGINAL DATA
.05 0;5 EDITED DATA
.06 0;6 DATE/TIME EDITED", "", "", ""], ["7016", "XUEPCS PSDRPH AUDIT FILE", "File", "KERNEL", "2019/02/01", "APPROVED", "Active", "Private", "8991.7", "
Outpatient Pharmacy is granted permission to enter the
following fields.\n
Field # Node;Piece Field Name
.01 0;1 NAME
.02 0;2 EDITED BY
.03 0;3 ALLOCATION STATUS
.04 0;4 DATE/TIME EDITED\n
Revision History -
10/16/24 The WebVRAM and Outpatient Pharmacy development teams are working
together on the release of the RPC and the WebVRAM GUI changes to invoke the
RPC. The Pharmacy patch is PSO*7*732 and the WEBG patch is WEBG*3*21. The ICR
that authorizes Pharmacy's reference to file 8991.7 is #7016. This RPC
performs the same function as the Allocate/De-Allocate of PSDRPH Key (Audited)
[PSO EPCS PSDRPH KEY]. WebVRAM's subscription is valid only as long as ICR
7492 is active.", "", "", "2024/10/16"], ["7017", "ERA DETAIL", "File", "INTEGRATED BILLING", "2019/02/07", "APPROVED", "Active", "Controlled Subscription", "361.1", "
This IA will allow read and write access to the ERA
DETAIL field (#104) in the EXPLANATION OF BENEFITS file (#361.1). This field
is to be used to track Explanation of Benefits (EOB) data.\n
The field label:\n
ERA DETAIL 361.1,104 FREE TEXT\n
Enter the ERA detail reference in the form nn,nnnnn,", "", "", "2020/03/17"], ["7018", "GIVE THIS DBIA A BETTER NAME THAN DBIA7018", "", "", "2019/02/13", "", "Pending", "", "", "", "", "", ""], ["7019", "Scheduling access to address data", "File", "REGISTRATION", "2019/02/26", "APPROVED", "Active", "Controlled Subscription", "2", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "", "2019/05/21"], ["7020", "Scheduling access to patient flags (local)", "File", "REGISTRATION", "2019/02/26", "APPROVED", "Active", "Private", "26.11", "
VS GUI displays patient flags to schedulers. It
requires FileMan read access to the following fields:\n
.01 Name .02 Status", "", "", "2019/04/17"], ["7021", "VS GUI access to Patient flags (national)", "File", "REGISTRATION", "2019/02/26", "APPROVED", "Active", "Private", "26.15", "
VS GUI displays patient flags to schedulers. It
requires FileMan read access to the following fields:\n
.01 Name .02 Status", "", "", "2019/04/17"], ["7022", "VS GUI access to Patient Flag Assignment", "File", "REGISTRATION", "2019/02/26", "APPROVED", "Active", "Private", "26.13", "
VS GUI displays patient flags to schedulers. It
requires FileMan read access to the following fields:\n
.03 Status", "", "", "2019/05/21"], ["7023", "VS GUI access to patient enrollment data", "File", "REGISTRATION", "2019/02/26", "APPROVED", "Active", "Private", "27.11", "", "", "", "2019/04/17"], ["7024", "VS GUI access to Medical Center Division fields", "File", "REGISTRATION", "2019/02/26", "APPROVED", "Active", "Controlled Subscription", "40.8", "
VS GUI uses data from file #40.8 - Medical Center
Division. It requires FileMan and direct global read access to the following
fields:\n
.01 Name
.07 Institution
1 Facility Number 30.01 Address Location on Letters", "", "", "2023/11/15"], ["7025", "VS GUI access to MAS Parameters (#43) file", "File", "REGISTRATION", "2019/02/27", "APPROVED", "Active", "Private", "43", "", "", "", "2019/04/17"], ["7026", "VS GUI access to Protocol (#101) fields", "File", "ORDER ENTRY/RESULTS REPORTING", "2019/02/27", "", "Pending", "Private", "101", "
VS GUI uses data from file #101 - Protocol. It
requires FileMan and direct global read access to the following fields:\n
.01 Name
1.1 Synonym multiple
.01 Synonym", "", "", ""], ["7027", "VS GUI access to Visit Tracking Parameters (#150.9)", "File", "PCE PATIENT CARE ENCOUNTER", "2019/02/27", "", "Pending", "Private", "150.9", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "", ""], ["7028", "VS GUI access to Patient's next of kin and employer fields", "File", "REGISTRATION", "2019/02/27", "APPROVED", "Active", "Private", "2", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "", "2019/05/28"], ["7029", "VS GUI access to Patient's eligibility information", "File", "REGISTRATION", "2019/02/27", "APPROVED", "Active", "Private", "2", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "", "2019/05/28"], ["7030", "VS GUI access to patient appointment data", "File", "REGISTRATION", "2019/02/28", "APPROVED", "Active", "Private", "2.98", "", "", "", "2019/04/17"], ["7031", "VS GUI access to AMIE Site Parameters (#396.1)", "File", "AUTOMATED MED INFO EXCHANGE", "2019/02/28", "APPROVED", "Active", "Private", "396.1", "", "", "", "2019/05/21"], ["7032", "VS GUI access to routine AUPNPAT", "Routine", "PCE PATIENT CARE ENCOUNTER", "2019/02/28", "", "Withdrawn", "Private", "", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "AUPNPAT", ""], ["7033", "VS GUI access to routine AUPNVSIT", "Routine", "PCE PATIENT CARE ENCOUNTER", "2019/02/28", "", "Pending", "Private", "", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************\n
VSIT01 validates the date of visit so that it is not in the future, after the
patient's death or before the patient's birth.", "", "AUPNVSIT", ""], ["7034", "VS GUI access to routine DGNFUNC", "Routine", "REGISTRATION", "2019/02/28", "APPROVED", "Active", "Private", "", "
$$FML^DGNFUNC returns the patient's name formatted in
'First Middle Last Suffix' format.", "", "DGNFUNC", "2019/04/17"], ["7035", "VS GUI access to DGPMV10 routine", "Routine", "REGISTRATION", "2019/03/11", "", "Pending", "Private", "", "", "", "DGPMV10", ""], ["7036", "VS GUI access to DGSEC4 routine", "Routine", "REGISTRATION", "2019/03/12", "APPROVED", "Active", "Private", "", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "DGSEC4", "2019/05/21"], ["7037", "VS GUI access to routine DGUTL3", "Routine", "REGISTRATION", "2019/03/12", "", "Pending", "Private", "", "", "", "DGUTL3", ""], ["7038", "VS GUI access to routine DVBCCNNS", "Routine", "AUTOMATED MED INFO EXCHANGE", "2019/03/13", "APPROVED", "Active", "Private", "", "", "", "DVBCCNNS", "2019/05/21"], ["7039", "VS GUI access to routine DVBCMKLK", "Routine", "AUTOMATED MED INFO EXCHANGE", "2019/03/13", "APPROVED", "Active", "Private", "", "", "", "DVBCMKLK", "2019/05/21"], ["7040", "VS GUI access to routine DVBCUTA3", "Routine", "AUTOMATED MED INFO EXCHANGE", "2019/03/13", "APPROVED", "Active", "Private", "", "", "", "DVBCUTA3", "2019/05/21"], ["7041", "VS GUI access to routine DVBCUTA4", "Routine", "AUTOMATED MED INFO EXCHANGE", "2019/03/13", "APPROVED", "Active", "Private", "", "", "", "DVBCUTA4", "2019/05/28"], ["7042", "VS GUI access to routine DVBCUTL5", "Routine", "AUTOMATED MED INFO EXCHANGE", "2019/03/13", "APPROVED", "Active", "Private", "", "", "", "DVBCUTL5", "2019/05/28"], ["7043", "VS GUI access to extrinsic function in routine MPIF001", "Routine", "MASTER PATIENT INDEX VISTA", "2019/03/13", "", "Withdrawn", "Private", "", "", "", "MPIF001", ""], ["7044", "VS GUI access to 2507 Request file (#396.3)", "File", "AUTOMATED MED INFO EXCHANGE", "2019/03/14", "APPROVED", "Active", "Private", "396.3", "", "", "", "2019/05/28"], ["7045", "VS GUI access to AMIE C&P Exam Tracking (#396.95)", "File", "AUTOMATED MED INFO EXCHANGE", "2019/03/14", "APPROVED", "Active", "Private", "396.95", "
This ICR request results from an ICR audit of
production VS GUI code.\n
No new code was introduced into the system.", "", "", "2019/04/17"], ["7046", "VS GUI access to routine VSITVID", "Routine", "PCE PATIENT CARE ENCOUNTER", "2019/03/14", "", "Withdrawn", "Private", "", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "VSITVID", ""], ["7047", "VS GUI access to routine ORWPT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2019/03/18", "APPROVED", "Active", "Private", "", "", "", "ORWPT", "2019/04/18"], ["7048", "VS GUI access to file #9000001", "File", "PCE PATIENT CARE ENCOUNTER", "2019/03/18", "", "Withdrawn", "Private", "9000001", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "", ""], ["7049", "VS GUI access to Patient Movement (#405) file.", "File", "REGISTRATION", "2019/03/20", "APPROVED", "Active", "Private", "405", "", "", "", "2019/05/28"], ["7050", "VS GUI access to Eligibility Code file (#8)", "File", "REGISTRATION", "2019/03/22", "APPROVED", "Active", "Private", "8", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "", "2019/05/28"], ["7051", "VS GUI Access fields in file #123", "File", "CONSULT/REQUEST TRACKING", "2019/03/25", "", "Pending", "Private", "123", "", "", "", ""], ["7052", "VS GUI access to MAS Eligibility Code (#8.1)", "File", "REGISTRATION", "2019/04/01", "APPROVED", "Active", "Private", "8.1", "\n
************************************************************************
* *
* This is a temporary ICR for the production VistA Scheduling (VS) * *
GUI software. * * The
need for this ICR was identified from the VS Sustainment Team * * reviewing
the VistA Scheduling Enhancement (VSE) software that was * * released
nationally without approved ICRs. This temporary ICR * * represents the
situation, where the Custodian package experts * * requested changes to
the production software to use approved * * APIs, which requires a
future VS patch. This temporary ICR will * * expire when the production
code is modified to the use approved * * APIs
*
* *
************************************************************************", "", "", "2019/05/28"], ["7053", "FIELD LABEL CHECK", "File", "1", "2019/04/04", "", "Pending", "Controlled Subscription", "0", "\n\n
VistA Laboratory requests permission to read ^DD(63.04 in order to check for
Field Label inconsistencies which have potential for causing downstream
issues.\n
Patch LR*5.2*519 will check all subscripts in the "B" cross reference of
^DD(63.04 and send a MailMan message to the "LMI" MailMan group if the
following issues are found:\n
1. A Field Label subscript in the "B" cross reference does not match the
field label of the corresponding internal entry number (IEN) in the
first "^" data piece of ^DD(63.04,IEN,0).\n
Example - Correct:\n
^DD(63.04,"B","ABC",100)=""
^DD(63.04,100,0)="ABC^FJ222^^RF;2^K:$L(X)>222!($L(X)<1) X"\n
Example - Incorrect:\n
^DD(63.04,"B","ABC",100)=""
^DD(63.04,100,0)="XYZ^FJ222^^RF;2^K:$L(X)>222!($L(X)<1) X"\n
And/Or:\n
2. A Field Label subscript in the "B" cross reference points to more
than one IEN at ^DD(63.04,IEN,0).\n
Example - Correct - Only one entry at the "B" cross reference\n
^DD(63.04,"B","ABC",100)=""\n
Example - Incorrect - More than one entry at the "B" cross reference\n
^DD(63.04,"B","ABC",100)=""
^DD(63.04,"B","ABC",200)=""", "", "", ""], ["7054", "WRITE ACCESS TO SUB-FILE 200.051", "File", "KERNEL", "2019/04/08", "APPROVED", "Active", "Controlled Subscription", "200.051", "
Outpatient Pharmacy is given permission by Kernel for
write access with Fileman to the KEY field (#.01) of the KEYS SUB-FILE
(#200.051).", "", "", "2025/06/03"], ["7055", "VAFC MVI MGRTD FACILITIES UPDT", "Remote Procedure", "REGISTRATION", "2019/04/10", "APPROVED", "Active", "Private", "", "
The Master Patient Index (MPI) team requests permission
for the MPI system to utilize the following REGISTRATION Remote Procedure Call
(RPC) [VAFC MVI MGRTD FACILITIES UPDT] to remotely maintain the EHRM MIGRATED
FACILITIES (#391.919) file, which allows the site to know which facilities
have migrated to/implemented the CERNER application in support of the
Electronic Health Record Modernization (EHRM).", "VAFC MVI MGRTD FACILITIES UPDT", "", "2019/05/15"], ["7056", "VIAB USE OF SAVE ORWDXA", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2019/04/19", "", "Pending", "Private", "", "
VIA Requests usage of routine SAVE^ORWDX to process
orders. This routine will be called from remote procedure VIABDX SAVE.", "", "ORWDX", ""], ["7057", "ORWDPS2 OISLCT", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2019/04/24", "", "Pending", "Controlled Subscription", "", "
Returns defaults for pharmacy orderable item needed for
clients currently in the field.", "ORWDPS2 OISLCT", "", ""], ["7058", "Make Appointment API", "Routine", "SCHEDULING", "2019/04/25", "APPROVED", "Active", "Controlled Subscription", "", "
Making an appointment impacts several files in all
cases (e.g., Patient, Location, SDEC Appointment) and others in specific cases
(e.g., Consult). This ICR describes the scheduling API that can be used by
non-scheduling applications to make appointments.\n
Note: Subscribing applications that want to invoke this API using the SDEC
APPADD RPC can subscribe to the appropriate controlled ICR (#7059).", "", "SDEC07", "2022/11/23"], ["7059", "SDEC APPADD", "Remote Procedure", "SCHEDULING", "2019/04/25", "", "Under Revision", "Controlled Subscription", "", "
RPC used to add a new appointment for a patient.\n
For further information including a description of the inputs and outputs, see
ICR #7058.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC APPADD", "", "2022/11/23"], ["7060", "DELETE FILES AND SUB-FILES TO BACKOUT PRCA313 FROM IOC", "Routine", "1", "2019/04/30", "APPROVED", "Active", "Private", "", "
The project for PRCA*4.5*313 is being cancelled, and
since the patch is already in production at three IOC sites, the patch needs
to be backed out of those three sites. This integration agreement is to allow
use of a supported fileman API to delete files and sub-files so that they may
be restored to their pre-patch condition. This API will be used in the
pre-install routine PRCA313P.\n
FileMan API being used:\n
Deleting Files and Sub-files EN^DIU2: Delete Data Dictionary Reference Type:
Supported Category: Classic VA FileMan ICR#: 10014", "", "DIU2", "2019/05/14"], ["7061", "DELETE FIELDS TO BACKOUT PRCA313 FROM IOC", "Routine", "1", "2019/04/30", "APPROVED", "Active", "Private", "", "
The project for PRCA*4.5*313 is being cancelled, and
since the patch is already in production at three IOC sites, the patch needs
to be backed out of those three sites. This integration agreement is to allow
use of a supported fileman API to delete fields so that they may be restored
to their pre-patch condition. This API will be used in the pre-install
routine PRCA313P.\n
FileMan API being used:\n
Deleting Fields ^DIK: Delete Data Dictionary Reference Type: Supported
Category: Classic VA FileMan ICR#: 10014", "", "DIK", "2019/05/14"], ["7062", "XUS MVI ENRICH NEW PERSON", "Remote Procedure", "KERNEL", "2019/05/01", "APPROVED", "Active", "Private", "", "
In support of the Provider Profile Management System
(PPMS) / Provider Integration Engine (PIE) for Mission Act, the Master Veteran
Index (MVI) team requests permission to exclusively use the following
restricted KERNEL Remote Procedure Call (RPC) [XUS MVI ENRICH NEW PERSON],
which will allow MVI to either add a new National Provider type entry to the
NEW PERSON File (#200) or update select fields with enriched data for an
existing user entry, identified by their Nation Provider Identifier (NPI)
value, in the NEW PERSON File (#200) and associated DEA NUMBERS File (#8991.9)
from the MVI system. See the RPC for a complete list of fields to be updated.", "XUS MVI ENRICH NEW PERSON", "", "2019/05/14"], ["7063", "OE/RR Reference to Alert Tracking File (8992.1)", "File", "KERNEL", "2019/05/06", "APPROVED", "Active", "Private", "8992.1", "
OE/RR utilizes the Alert Tracking File (#8992.1) to
obtain alert information for OR and TIU alerts for a specified date range
included with patch OR*3.0*500 Alert Enhancements.\n
Revision History:\n
Added 7/26/24: Effective with OR*3*561, the following 2 global references were
added:
^XTV(8992.1,D0,20,D1,3)
3 SURROGATE FOR 3;0 Direct Global Read & w/Fileman
^XTV(8992.1,D0,20,'B')
.01 RECIPIENT 0;1 Direct Global Read & w/Fileman", "", "", "2019/05/06"], ["7064", "Cancel Appointment API", "Routine", "SCHEDULING", "2019/05/06", "APPROVED", "Active", "Controlled Subscription", "", "
Cancelling an appointment impacts several files in all
cases (e.g., Patient, Location, SDEC Appointment) and others in specific cases
(e.g., Consult). This ICR describes the scheduling API that can be used by
non-scheduling applications to cancel appointments.\n
Note: Subscribing applications that want to invoke this API using the SDEC
APPDEL RPC can subscribe to the appropriate controlled ICR (#7065).", "", "SDEC08", "2020/05/04"], ["7065", "SDEC APPDEL", "Remote Procedure", "SCHEDULING", "2019/05/06", "", "Under Revision", "Controlled Subscription", "", "
RPC used to cancel an appointment for a patient.\n
For further information including a description of the inputs and outputs, see
ICR #7064.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC APPDEL", "", "2021/11/01"], ["7066", "Check-In API", "Routine", "SCHEDULING", "2019/05/07", "APPROVED", "Active", "Controlled Subscription", "", "
Checking in an appointment impacts several files -
Location, SDEC Appointment. This ICR describes the scheduling API that can be
used by non-scheduling applications to check in appointments.\n
Note: Subscribing applications that want to invoke this API using the SDEC
CHECKIN RPC can subscribe to the appropriate controlled ICR (#7067).", "", "SDEC25", "2021/11/01"], ["7067", "SDEC CHECKIN", "Remote Procedure", "SCHEDULING", "2019/05/07", "", "Under Revision", "Controlled Subscription", "", "
RPC used to check an appointment in.\n
For further information including a description of the inputs and outputs, see
ICR #7066.", "SDEC CHECKIN", "", "2021/11/01"], ["7068", "Check out appointment", "Routine", "SCHEDULING", "2019/05/08", "", "Withdrawn", "Controlled Subscription", "", "
Checking a patient out for an appointment impacts
several files - Location, SDEC Appointment. This ICR describes the scheduling
API that can be used by non-scheduling applications to check out appointments.\n
Note: Subscribing applications that want to invoke this API using the SDEC
CHECKOUT RPC can subscribe to the appropriate controlled ICR (#7069).", "", "SDEC25", ""], ["7069", "SDEC CHECKOUT", "Remote Procedure", "SCHEDULING", "2019/05/08", "", "Withdrawn", "Controlled Subscription", "", "
RPC used to check out an appointment.\n
For further information including a description of the inputs and outputs, see
ICR #7068.", "SDEC CHECKOUT", "", ""], ["7070", "Available Slots API", "Routine", "SCHEDULING", "2019/05/08", "", "Pending", "Controlled Subscription", "", "
Returns list of slots set up for a clinic for a date
range along with their availability.", "", "SDEC57", ""], ["7071", "SDEC APPSLOTS", "Remote Procedure", "SCHEDULING", "2019/05/08", "APPROVED", "Active", "Controlled Subscription", "", "
RPC used to return list of appointment slots for a
clinic associated with a resource. For a list of inputs and outputs, see ICR
#7070.", "SDEC APPSLOTS", "", "2019/09/13"], ["7072", "Cancel Appointment Check-Out API", "Routine", "SCHEDULING", "2019/05/08", "", "Withdrawn", "Controlled Subscription", "", "
Cancels appointment check-out and updates the
appropriate scheduling files.", "", "SDEC25", ""], ["7073", "SDEC CANCKOUT", "Remote Procedure", "SCHEDULING", "2019/05/08", "", "Withdrawn", "Controlled Subscription", "", "
RPC used to cancel check out for an appointment. For a
list of inputs and outputs, see ICR #7072.", "SDEC CANCKOUT", "", ""], ["7074", "No-Show Appointment API", "Routine", "SCHEDULING", "2019/05/09", "APPROVED", "Active", "Controlled Subscription", "", "
Marks appointment as no show or cancels no show and
updates the relevant files. Also executes the event triggers.", "", "SDEC31", "2022/11/17"], ["7075", "SDEC NOSHOW", "Remote Procedure", "SCHEDULING", "2019/05/09", "APPROVED", "Active", "Controlled Subscription", "", "
RPC used to no show an appointment.\n
See ICR #7074 for a description of the input and output parameters.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC NOSHOW", "", "2022/11/23"], ["7076", "Clinic schedule API", "Routine", "SCHEDULING", "2019/05/15", "", "Pending", "Controlled Subscription", "", "
Returns appointments scheduled for a set of resources.", "", "SDEC02", ""], ["7077", "SDEC CRSCHED", "Remote Procedure", "SCHEDULING", "2019/05/15", "", "Pending", "Controlled Subscription", "", "
RPC that returns appointments scheduled for a set of
resources. See ICR #7076 for a list of inputs and outputs.", "SDEC CRSCHED", "", ""], ["7078", "RA TAKE AWAY ALL ACCESS TO A (RIS) FILE", "Routine", "KERNEL", "2019/05/16", "APPROVED", "Active", "Private", "", "
VistA Radiology requests the privilege to use the
XUFILE1 routine to take away all access from all users to the RAD/NUC MED
REASON [#75.2] file. This is a one-time request and will be included in the
routine: RAIPS160.\n
RAIPS160 will be a post-install routine released as a component of RA*5.0*160.\n", "", "XUFILE1", "2019/05/31"], ["7079", "SOCIAL WORK FILE DELETION", "File", "1", "2019/06/03", "APPROVED", "Active", "Private", "", "
Social Work patch SOW*3.0*65 contains post install
routine SOW3P65, which will use the VA FileMan API, EN^DIU2, to completely
remove all SOW files, data, and related data dictionary entries.\n
The following files will be removed:\n
-SOCIAL WORK CASE (#650)\n
-SOCIAL WORK SITE PARAMETERS (#650.1)\n
-COST DISTRIBUTION CENTER (#651)\n
-RCH (#652)\n
-RESOURCES/REFERRALS (#653)\n
-SOCIAL WORK PATIENT (#655)\n
-SWS ASSESSMENT DATA BASE (#655.2)\n
-PSYCHO-SOCIAL PROBLEMS (#655.201)\n
-DIRECT SERVICE CATEGORIES (#655.202)\n
-PSYCHO-SOCIAL OUTCOMES (#655.203)\n
-SWS RESOURCES (#656)\n
The following code from SOW3P65 will be used to remove the files:\n
S DIU(0)="DST" ;flags to delete data, subfile and templates
F SOWFILE=650,650.1,651:1:653,655,655.2:.001:655.203,656 D ;loop through
known social work files
.S DIU=$$ROOT^DILFD(SOWFILE),SOWNODE=$$CREF^DILF(DIU) ;set diu=file root and
sownode=closed file root
.I '$$VFILE^DILFD(SOWFILE) Q ;verify file exists
.D EN^DIU2 ;delete file and data in diu", "", "", "2019/06/03"], ["7080", "Appointment List for a Patient API", "Routine", "SCHEDULING", "2019/05/22", "", "Pending", "Controlled Subscription", "", "
Returns a list of appointments for a patient for a date
range. List may be all or only ancillary (Lab, X-ray, EKG) appointments.", "", "SDEC50", ""], ["7081", "SDEC FAPPTGET", "Remote Procedure", "SCHEDULING", "2019/05/22", "", "Pending", "Controlled Subscription", "", "
RPC that returns a list of appointments for a patient
for a date range. See ICR #7080 for a list of inputs and outputs.", "SDEC FAPPTGET", "", ""], ["7082", "Clinic Schedule - Slot Availability API", "Routine", "SCHEDULING", "2019/05/30", "", "Pending", "Controlled Subscription", "", "
Returns the slot counts for the clinic associated with
a resource for a date range.", "", "SDEC57", ""], ["7083", "SDEC APPSLOTS", "Remote Procedure", "SCHEDULING", "2019/05/30", "", "Pending", "Controlled Subscription", "", "
Returns the slot counts for the clinic associated with
a resource for a date range.\n
See ICR #7082 for a list of inputs and outputs.", "SDEC APPSLOTS", "", ""], ["7084", "Electronically Billable Indicator", "Routine", "OUTPATIENT PHARMACY", "2019/06/05", "APPROVED", "Active", "Private", "", "
The $$ECME^PSOBPSUT call returns one of two values. An
'e' is returned if the last fill of the prescription is electronically
billable, else null is returned.", "", "PSOBPSUT", "2019/06/06"], ["7085", "XUS MVI NEW PERSON BULK GET", "Remote Procedure", "KERNEL", "2019/06/26", "APPROVED", "Active", "Private", "", "
In support of the Electronic Health Record
Modernization (EHRM), the Master Veteran Index (MVI) team requests permission
to exclusively use the following restricted KERNEL Remote Procedure Call (RPC)
[XUS MVI NEW PERSON BULK GET], to allow retrieval of 'Active' NEW PERSON file
(#200) data in bulk (large chunks) transfers from each VistA site to the MVI.
When all 'Active' NEW PERSON file (#200) data has been retrieved for a site,
MVI will export the results to a flat text file where it will then be imported
by the Person Service Identity Management (PSIM) system so that it can be
further evaluated.", "XUS MVI NEW PERSON BULK GET", "", "2019/08/02"], ["7086", "MAIL GROUP REMOTE MEMBER AND DESCRIPTION", "File", "MAILMAN", "2019/07/01", "", "Withdrawn", "Private", "3.8", "
Accounts Receivable needs a ONE-TIME ONLY Integration
Agreement to allow manuipulation of the data in a mail group entry to add an
Outlook mailing list as a remote member and update the mail group's
description to warn users not to send PII/PHI to this mail group. Since no
utility exists to add a remote member to or edit the description of an entry
in the mail group file, the following access is requested:\n
1. The ability to add a remote member to a mail group. This would be done
once, in the Post-Install routine RCP349.\n
2. The ability to edit the description of a mail group to add text warning
users not to send PII/PHI to this mail group.\n
The following code would be used to accomplish both tasks:\n
N FDA,IEN,I,WPDATA
D BMES^XPDUTL("Add Outlook email group to RCDPE PAYMENTS EXCEPTIONS mail
group")
S IEN=$$FIND1^DIC(3.8,,"X","RCDPE PAYMENTS EXCEPTIONS")
I 'IEN D Q
. D BMES^XPDUTL("Warning: Could not find RCDPE PAYMENTS EXCEPTIONS mail
group. Addresses not added.")
; IA TBD
S FDA(3.812,"?+"_I_","_IEN_",",.01)="DNSpayerinquiry@DNS"
D UPDATE^DIE(,"FDA")
; Update mail group description to warn against sending PII/PHI
S WPDATA(1,0)="*** DO NOT SEND PII/PHI! This Mail Group sends to an Outlook
email address and"
S WPDATA(2,0)="should not be used to send data containing PII/PHI ***"
D WP^DIE(3.8,IEN_",",3,"A","WPDATA")", "", "", ""], ["7087", "VIA USE OF LOCK AND UNLOCK ORWDX", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2019/07/09", "", "Pending", "Private", "", "
The Vista Integration Adapter (VIA) calls the
LOCK^ORWDX and UNLOCK^ORWDX APIs to lock and unlock a patient record as a new
order is entered for the patient.", "", "ORWDX", ""], ["7088", "DGMTU4 - Annual means test date determination", "Routine", "REGISTRATION", "2019/07/11", "APPROVED", "Active", "Controlled Subscription", "", "
This function evaluates a means test date that is
passed in, and checks if the date of the annual means test is greater or equal
to one year prior to the VFA Start Date of January 1, 2013. The VFA Start Date
is referenced from MAS PARAMETERS (#43) file in the VFA START DATE (#1205)
field. This Date is checked against the Discontinue Annual Means Test Renewal
Point Forward Date.", "", "DGMTU4", "2019/07/19"], ["7089", "GIVE THIS DBIA A BETTER NAME THAN DBIA7089", "", "", "2019/07/12", "", "Pending", "", "", "", "", "", ""], ["7090", "GET SPECIALTY COMMANDS FOR BARCODE PRINT", "File", "IFCAP", "2019/07/16", "APPROVED", "Active", "Private", "446.6", "
Above PAR requests permission to read the Specialty
Commands file in order to print Barcode labels with the command lines After
Open, Before Each Label, and After Each Label.", "", "", "2019/07/29"], ["7091", "ORWUX SYMTAB", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2019/07/29", "APPROVED", "Active", "Private", "", "
Although unusual, the purpose of this agreement is to
grant the Provider Role Change Graphical User Interface (GUI) access to the
remote procedure call (RPC) ORWUX SYMTAB. Even though the routine is in the
same namespace as the Provider Role Change GUI, it is a separate Delphi
application.", "ORWUX SYMTAB", "", "2019/08/02"], ["7092", "IB CLAIM REJECT REVIEW INCOMPLETE", "Routine", "INTEGRATED BILLING", "2019/08/01", "", "Pending", "Private", "", "
This function checks file #361 and returns a flag that
indicates whether the bill has a reject message, where the review status is
not complete.", "", "IBJTU6", ""], ["7093", "GIVE THIS DBIA A BETTER NAME THAN DBIA7093", "", "", "2019/08/23", "", "Pending", "", "", "", "", "", ""], ["7094", "GIVE THIS DBIA A BETTER NAME THAN DBIA7094", "", "", "2019/08/23", "", "Pending", "", "", "", "", "", ""], ["7095", "IMAGING SCANS THE REQUEST/CONSULTATION FILE FOR IMAGES", "File", "CONSULT/REQUEST TRACKING", "2019/09/05", "", "Pending", "Private", "123.3", "
The Consult/Request Tracking package provides an
efficient way for clinicians to order consultations and procedures from other
providers or services within the VHA system, at their own facility or another
facility. It also provides a framework for tracking consults and procedures
and reporting the results. It uses a patient's computerized patient record to
store information about consult and procedure requests and results.", "", "", ""], ["7096", "XOBE ESIG GET DATA", "Remote Procedure", "ELECTRONIC SIGNATURE", "2019/09/13", "APPROVED", "Active", "Private", "", "
The WebVRAM package needs access to the XOBE ESIG GET
DATA RPC. This RPC returns electronic signature block-related fields from File
200 from the home facility tracked by the WebVRAM administrative tools.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XOBE ESIG GET DATA", "", "2019/09/20"], ["7097", "XOBE ESIG IS DEFINED", "Remote Procedure", "ELECTRONIC SIGNATURE", "2019/09/13", "APPROVED", "Active", "Private", "", "
The WebVRAM package needs access to the XOBE ESIG IS
DEFINED RPC. This RPC will support WebVRAM electronic signature processing
that checks if the electronic signature is defined for the user/visitor.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XOBE ESIG IS DEFINED", "", "2019/09/20"], ["7098", "XOBE ESIG SET CODE", "Remote Procedure", "ELECTRONIC SIGNATURE", "2019/09/13", "APPROVED", "Active", "Private", "", "
The WebVRAM package needs to access the XOBE ESIG SET
CODE RPC to support saving the electronic signature code on VistA systems that
the visitor is authorized to access.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XOBE ESIG SET CODE", "", "2019/09/20"], ["7099", "XOBE ESIG SET DATA", "Remote Procedure", "ELECTRONIC SIGNATURE", "2019/09/13", "APPROVED", "Active", "Private", "", "
The WebVRAM package needs access to the XOBE ESIG SET
DATA RPC. This RPC will support saving the electronic signature block on the
VistA systems that the user/visitor is authorized to access. The signature
block comes from the home facility's electronic signature block and is
propagated by WebVRAM.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XOBE ESIG SET DATA", "", "2019/09/20"], ["7100", "XU REBUILD MENU TREE", "Remote Procedure", "KERNEL", "2019/09/13", "APPROVED", "Active", "Private", "", "
The WebVRAM package needs access to the XU REBUILD MENU
TREE RPC. This RPC will be used to rebuild the menu tree for the WebVRAM
visitor added to a VistA facility.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XU REBUILD MENU TREE", "", "2019/09/20"], ["7101", "XWB GET BROKER INFO", "Remote Procedure", "RPC BROKER", "2019/09/16", "APPROVED", "Active", "Private", "", "
The WebVRAM package needs to get the details of the RPC
broker for use in the web applications used by WebVRAM users and WebVRAM
administrative users.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XWB GET BROKER INFO", "", "2019/09/20"], ["7102", "XUS GET CCOW TOKEN", "Remote Procedure", "KERNEL", "2019/09/16", "APPROVED", "Active", "Private", "", "
The WebVRAM package needs to access the XUS GET CCOW
TOKEN RPC to get a CCOW token.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XUS GET CCOW TOKEN", "", "2019/09/20"], ["7103", "XUS CCOW VAULT PARAM", "Remote Procedure", "KERNEL", "2019/09/16", "APPROVED", "Active", "Private", "", "
The WebVRAM package need to access the XUS CCOW VAULT
PARAM RPC to get the CCOW vault parameters.\n
"Kernel understands this ICR was created to track which application is using
the Kernel resource. The WebVRAM team has been working with IAM and the
Kernel team for future official alternatives."", "XUS CCOW VAULT PARAM", "", "2019/09/20"], ["7104", "External Format of Subgroup", "Routine", "REGISTRATION", "2019/10/02", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Control Registration is
to grant Order Entry/Results Reporting access to DGENU for the purposes of
converting the internal format of the ENROLLMENT SUBGROUP field (#.12) from
the PATIENT ENROLLMENT file (#27.11) to its external value for display
purposes.", "", "DGENU", "2019/10/02"], ["7105", "FIXDATE TIUSRVLO API", "Routine", "TEXT INTEGRATION UTILITIES", "2019/10/09", "", "Active", "Private", "", "
FIXDATE^TIUSRVLO changes the array data in the TIUY
parameter. It relies on the "INDX" index and data structure created by such
APIs as CONTEXT^TIUSRVLO and GETCSLT^ORQQCN1 to already exist in the array
named by the TIUY parameter. The PARENT parameter is piece 14 of the child
note, and the CDATE is the date of the child document. If the parent document
exists, and the child date is more recent than the parent documents date, it
moves the parent documents date stored in piece 3 to piece 17, and stores the
child's date in piece 3. It then recursively calls FIXDATE again on the
parent of the parent, to propogate the most recent child date to the top of
the tree structure.", "", "TIUSRVLO", ""], ["7106", "ORWU VERSRV", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2019/10/15", "APPROVED", "Active", "Private", "", "
ORWU VERSRV ICR #7106 is used by WebVRAM to lookup the
OR CPRS GUI CHART option to get the CPRSChart version on a particular VistA
System.", "ORWU VERSRV", "", "2019/10/17"], ["7107", "DGPFAA", "Routine", "REGISTRATION", "2019/11/14", "APPROVED", "Active", "Controlled Subscription", "", "
This documents the use of tags in routine DGPFAA to
retrieve patient record flags.", "", "DGPFAA", "2019/11/22"], ["7108", "DGPFAAH", "Routine", "REGISTRATION", "2019/11/14", "APPROVED", "Active", "Controlled Subscription", "", "
This documents the use of tags in routine DGPFAAH to
retrieve patient record flag activity.", "", "DGPFAAH", "2019/11/22"], ["7109", "VADPT", "Routine", "REGISTRATION", "2019/11/26", "APPROVED", "Active", "Supported", "", "
VADPT is a utility routine designed to provide a
central point where a programmer can obtain information concerning a patient's
record. Supported entry points are provided which will return demographics,
inpatient status, eligibility information, etc. This ICR is in addition to ICR
10061, it does not replace 10061.\n
Access to patient information is not limited to using the supported entry
points in VADPT. Integration agreements can be established through the DBA
between REGISTRATION and other packages to reference information.\n
This integration agreement does not document the input and output variables
for any of the components of VADPT. That documentation is located in the PIMS
technical manual, section 12.2 CALLABLE ENTRY POINTS IN VADPT, i.e.
DEMUPD^VADPT.", "", "VADPT", ""], ["7110", "EDIT SDAM PCE EVENT PROTOCOL", "Other", "SCHEDULING", "2019/11/27", "APPROVED", "Active", "Private", "", "", "", "", "2024/08/21"], ["7111", "RA RETURN COMPUTED FIELD DATA FROM RADIOLOGY RPTS", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2019/12/04", "", "Pending", "Private", "", "", "", "RARTFLDS", ""], ["7112", "RA SUPERVISOR MENU W/VISTA IMAGING ITEMS ATTACHED", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "2019/12/04", "", "Pending", "Private", "", "", "", "", ""], ["7113", "PIP Stock Issue Update Utility Access", "Routine", "PROSTHETICS", "2019/12/05", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call PROSTHETICS routine RMPRPIU6 that
issues stock to a patient from the Prosthetics Inventory Package (PIP).", "", "RMPRPIU6", "2020/01/13"], ["7114", "PIP Scan Barcode Access", "Routine", "PROSTHETICS", "2019/12/05", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call PROSTHETICS routine RMPRPIUA to
scan a Prosthetics Inventory Package (PIP) item's barcode and locate the
record in the PROSTHETIC CURRENT STOCK (#661.7) file.", "", "RMPRPIUA", "2020/01/13"], ["7115", "Get Current Stock for Vendors Access", "Routine", "PROSTHETICS", "2019/12/05", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call PROSTHETICS routine RMPRPIUV to
access an array containing vendors, quantity on hand, and unit cost for a
specified station, location, HCPCS, and item.", "", "RMPRPIUV", "2020/01/13"], ["7116", "PIP HCPCS Item File API Access", "Routine", "PROSTHETICS", "2019/12/06", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call several entry points in
PROSTHETICS routine RMPRPIX1 when creating a Prosthetics Inventory Package
(PIP) stock issue.", "", "RMPRPIX1", "2020/01/13"], ["7117", "PIP APIs for Patient 2319 Access", "Routine", "PROSTHETICS", "2019/12/06", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call PROSTHETICS routine RMPRPIX2 to
update the AMIS GROUPER (#7) in the PROSTHETIC SITE PARAMETERS file (#669.9).", "", "RMPRPIX2", "2020/01/13"], ["7118", "PIP PROS INVENTORY TRANSACTIONS API ACCESS", "Routine", "PROSTHETICS", "2019/12/06", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call PROSTHETICS routine RMPRPIX6 to
retrieve information about a specific vendor.", "", "RMPRPIX6", "2020/01/13"], ["7119", "PIP PROSTHETIC CURRENT STOCK APIS ACCESS", "Routine", "PROSTHETICS", "2019/12/06", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call PROSTHETICS routine RMPRPIX7 to
read the fields and calculate the total quantity on hand in the PROSTHETIC
CURRENT STOCK file (#661.7).", "", "RMPRPIX7", "2020/01/13"], ["7120", "PROSTHETIC STOCK LOCATION FILE ACCESS", "File", "PROSTHETICS", "2019/12/06", "APPROVED", "Active", "Private", "661.5", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) read access to all fields of the
PROSTHETIC STOCK LOCATION file (#661.5) when creating a Prosthetics Inventory
Package (PIP) stock issue.", "", "", "2020/01/13"], ["7121", "PROSTHETIC CURRENT STOCK FILE ACCESS", "File", "PROSTHETICS", "2019/12/06", "APPROVED", "Active", "Private", "661.7", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) read access to all fields of the
PROSTHETIC CURRENT STOCK file (#661.7) when creating a Prosthetics Inventory
Package (PIP) stock issue.", "", "", "2020/01/13"], ["7122", "XUJFST1", "Routine", "KERNEL", "2019/12/20", "", "Active", "Controlled Subscription", "", "
This Integration Control Registration describes
Controlled Subscription use of Application Program Interfaces to access data
in Kernel files.", "", "XUJFST1", ""], ["7123", "PSOCLO1", "Routine", "OUTPATIENT PHARMACY", "2020/01/08", "APPROVED", "Active", "Private", "", "
This routine performs Clozapine Order checks. It also
grants permission to dispense a clozapine marked drug to an eligible clozapine
patient.\n", "", "PSOCLO1", "2020/01/24"], ["7124", "Call GMRCCERN from RAO7ROXX - Cerner integration at Spokane", "Routine", "CONSULT/REQUEST TRACKING", "2020/02/03", "APPROVED", "Active", "Private", "", "
****** NOTE: This ICR is temporary and will be
cancelled when the HL7 adaptor is no longer in use at any site. *****\n
Until the Cerner Camm7 app is complete, Cerner EHRM will utilize VistA Imaging
to display clinical images. To implement this scheme, it is necessary for
Cerner to transmit HL7 orders to VistA so they can be processed onto modality
worklists. These orders will flow through the VistA multi-threaded listener
and be picked up by routine RAO7ROXX. That routine will triage the order
messages and process those that are for Radiology but will send the remainder
(Cardiology, Dental, Dermatology, Eye Care) to routine GMRCCERN for
processing.", "", "GMRCCERN", "2020/08/20"], ["7125", "DSS APPLICATION ACCESS TO PATIENT FLAG ASSIGNMENT", "File", "REGISTRATION", "2020/02/04", "APPROVED", "Active", "Private", "26.13", "
The following applications pre-read the PRF assignments
for workflow analysis:
Comprehensive Care Coordination (C3)
Consult Tracking Manager (CTM)
Order Tracking Manager (OTM)
Patient Case Manager (PCM)
Patient Flow Suite (PFS)
Suicide Prevention Manager (SCM).\n
In order for this process to work efficiently, reading the global directly is
necessary. Utilizing the FileMan reads are not a viable option when
considering the type and amount of data that these several RPCs are attempting
to retrieve. Because of this, direct read access is requested for field:\n
STATUS (#.03) of the PRF ASSIGNMENT (#26.13) file.", "", "", "2022/07/25"], ["7126", "DD 95.3 modification", "File", "1", "2020/02/09", "APPROVED", "Active", "Private", "95.3", "
Temporary KILL and reset ~DD(95.3,0,"ID",80). Temporary
KILL and reset ~DD(95.3,0,"SCR"). Temporary reset $P(^LAB(95.3,0),U,3) to
95.3I or 95.3Is This is a work around for the way KIDS looks up a record
during the Install Process. The problem is KIDS uses the .01 field and the
Identifiers to match an existing record and the incoming record has a
different value for the Identifier. The solution is to send the DD with no
Identifiers and to delete the Identifiers during the Pre-Install process and
to set the Identifiers back during the Post-Install process. The same is for
File Filter set into SCR node.", "", "", "2020/02/18"], ["7127", "DD 64.061 modification", "File", "1", "2020/02/09", "APPROVED", "Active", "Private", "64.061", "
Temporary KILL and reset ~DD(64.061,"ID",8). This is a
work around for the way KIDS looks up a record during the Install Process. The
problem is KIDS uses the .01 field and the Identifiers to match an existing
record and the incoming record has a different value for the
Identifier. The solution is to send the DD with no Identifiers and to delete
the Identifiers during the Pre-Install process and to set the Identifiers back
during the Post-Install process.", "", "", "2020/02/18"], ["7128", "DD 95.3 modification", "File", "LAB SERVICE", "2020/02/09", "", "Pending", "Private", "95.3", "
Temporary KILL and reset ~DD(95.3,0,"SCR")", "", "", ""], ["7129", "WRITE ACCESS TO WEB SERVER FILE", "File", "WEB SERVICES CLIENT", "2020/02/19", "APPROVED", "Active", "Private", "18.12", "
The CPRS (ORDER ENTRY/RESULTS REPORTING) team requests
read/write access to the WEB SERVER (#18.12) file to add a new entry during
the OR*3*519 post-install process. The post-install routine process will
create the new server record entry using UPDATE^DIE and will also create a new
entry to the AUTHORIZED WEB SERVICES (#100) multiple, WEB SERVICE (#.01)
field.\n
NOTE: This processing is done programmatically to avoid having sites manually
configure HWSC using the Web Server Manager. This will ensure all sites have
the same configuration installed correctly.", "", "", "2020/03/20"], ["7130", "ORDERABLE ITEM RADIOLOGY SPECIFIC AND SET FIELD XREF", "File", "ORDER ENTRY/RESULTS REPORTING", "2020/02/25", "APPROVED", "Active", "Private", "101.43", "
Radiology patch RA*5*165 needs temporary read access to
the Orderable Item file (#101.43) to resynchronize radiology procedures and
orderable items. Patch RA*5*165 will traverse the set field's S.XRAY cross
reference and compare key fields with their counterparts in the RAD/NUC MED
PROCEDURE file (#71). If they do not match, the OI entry will be updated via
existing Orderable Item update protocols.", "", "", "2020/04/10"], ["7131", "RMPR GMRC IFC EHRM UPDATE", "File", "PROSTHETICS", "2020/03/03", "APPROVED", "Active", "Private", "668", "
Vista Prosthetics is permitting Consults Request
Tracking (CRT) to update the PROSTHETICS SUSPENSE file (#668) for incoming
EHRM PROSTHETICS IFC suspense orders.
Revision History:
4/30/25-Added ACTION DATE multiple and its associated fields to store
comments.", "", "", "2020/03/12"], ["7132", "RMPRFC4", "Routine", "PROSTHETICS", "2020/03/03", "APPROVED", "Active", "Private", "", "
EHRM Prosthetics implements a new routine, GMRCRFC0, to
process incoming Prosthetics Interfacility Consults (IFC) suspense requests.
This routine is invoked by IFC inbound HL7 processor IN^GMRCIMSG.\n
For Discontinue (DC) EHRM actions received, new routine GMRCIFC0 process the
incoming HL7 message into the PROSTHETIC SUSPENSE file (#668).\n
For New (NW) EHRM Prosthetics actions received, new routine GMRCIFC0 invokes
existing New Order processing routine RMPRFC4 to re-use existing code. This
Integration Control Registration documents the invocation of ^RMPRFC4
directly, where previously it was only invoked through calls to ^RMPRFC3.", "", "RMPRFC4", "2020/03/12"], ["7133", "GETPAT MPIFRES", "Routine", "MASTER PATIENT INDEX VISTA", "2020/03/05", "APPROVED", "Active", "Controlled Subscription", "", "
This Application Programmer Interface (API) allows
subscribers to retrieve patient demographic data for a specific DFN.", "", "MPIFRES", "2020/06/02"], ["7134", "GETICN MPIFXMLI", "Routine", "MASTER PATIENT INDEX VISTA", "2020/03/05", "APPROVED", "Active", "Controlled Subscription", "", "
This Application Programmer Interface (API) allows
subscribers to perform an explicit VistA-Side creation of patients.", "", "MPIFXMLI", "2020/06/02"], ["7135", "VPR GET PATIENT DATA XML", "Routine", "VIRTUAL PATIENT RECORD", "2020/03/09", "APPROVED", "Active", "Private", "", "
This ICR provides the ability to pull patient data from
VistA by directly calling GET^VPRD. Please refer to the VPR Technical Manual
for details about input parameters and output data elements. These line tags
retrieve the requested data from VistA and return it in ^TMP("VPR",$J,n) as
XML.", "", "VPRD", "2020/03/19"], ["7136", "VPR GET PATIENT DATA JSON", "Routine", "VIRTUAL PATIENT RECORD", "2020/03/09", "APPROVED", "Active", "Private", "", "
This ICR provides the ability to pull patient data from
VistA by directly calling GET^VPRDJ. Please refer to the VPR Technical Manual
for details about input parameters and output data elements. These line tags
retrieve the requested data from VistA and return it in ^TMP("VPR",$J,n) as
JSON.", "", "VPRDJ", "2020/03/19"], ["7137", "SEND WEIGHT CHANGE NOTIFICATION TO DIETICIAN", "Routine", "DIETETICS", "2020/03/09", "APPROVED", "Active", "Private", "", "
The purpose of this ICR is to grant the Vitals package
privileges to call FHGMVQAL to queue an alert (notification) to the Dietician
assigned to a Nutrition Location.", "", "FHGMVQAL", "2020/03/10"], ["7138", "DIRECT READ OF ERROR LOG FILE", "File", "KERNEL", "2020/03/10", "APPROVED", "Active", "Private", "3.075", "
This ICR provides the ability to directly read the
ERROR LOG file and its sub-files.", "", "", "2020/03/19"], ["7139", "DIRECT READ OF ERROR TRAP SUMMARY FILE", "File", "KERNEL", "2020/03/10", "APPROVED", "Active", "Private", "3.077", "
This ICR provides the ability to directly read from the
ERROR TRAP SUMMARY file.", "", "", "2020/03/19"], ["7140", "VIA use of EDIS data (#7140/#7141)", "File", "EMERGENCY DEPARTMENT", "2020/03/11", "", "Pending", "Private", "230", "", "", "", ""], ["7141", "VIA use of EDIS data (#7140/#7141)", "File", "EMERGENCY DEPARTMENT", "2020/03/11", "", "Pending", "Private", "233.1", "", "", "", ""], ["7142", "TIU RE-INDEX VISIT FIELD TRIGGER", "File", "TEXT INTEGRATION UTILITIES", "2020/03/18", "APPROVED", "Active", "Private", "8925", "
This ICR provides read access to the "V" cross
reference in the TIU DOCUMENT (#8925) file and file access to re-index the
trigger cross reference of the VISIT (#.03) field of the TIU DOCUMENT (#8925)
file to update the VISIT ID (#15001) field.", "", "", "2020/04/08"], ["7143", "ADUPN", "File", "KERNEL", "2020/03/19", "APPROVED", "Active", "Private", "200", "
The CPRS (ORDER ENTRY/RESULTS REPORTING) team requests
read access to the ADUPN field in the New Person (#200) file. The ADUPN field
(which stores the users' va.gov email address) will be used in the query to
identify the user initiating the query.", "", "", "2020/03/20"], ["7144", "PDMP HEALTH SUMMARY EXTRACT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2020/03/23", "APPROVED", "Active", "Controlled Subscription", "", "
The Health Summary Package desires to set up an
integration agreement with the Order Entry/Results Reporting Package to
retrieve Prescription Drug Monitoring Program (PDMP) data.", "", "ORPDMPHS", "2020/04/14"], ["7145", "DD GLOBAL READ ACCESS", "File", "1", "2020/04/01", "", "Pending", "Private", "", "
Above PAR requests permission to perform direct reads
from the FILE Attribute file. Including all the fields as well as the 'GL' &
'IX' indexes.\n
The 'IX' cross reference index is used to return information faster by using
the cross references when searching for specific data.
^DD(File#, 0, "IX", Reference, File#, Field#)\n
The 'GL' index is used to step through data using the global layout.
^DD(File#, "GL", node, piece, Field#)\n\n
Global File & Field may be read and traversed by direct means.\n
^DD(File#, Field#,0)
.01 LABEL 0;1 Direct Read & Fileman Read
.2 SPECIFIER 0;2 Direct Read & Fileman Read
.3 POINTER 0;3 Direct Read & Fileman Read
.4 GLOBAL SUBSCRIPT LOCATION 0;4 Direct Read & Fileman Read
INPUT TRANSFORM 0;5 Direct Read & Fileman Read\n
^DD(File#, Field#,1,SEQ CROSS-REFERENCE ^DD(File#, Field#,1,SEQ,0)
File 0;1 Direct Read & Fileman Read
INDEX 0;2 Direct Read & Fileman Read\n
^DD(File#, Field#,1,SEQ,1,1)
SET STATEMENT Direct Read & Fileman Read
^DD(File#, Field#,1,SEQ,1,2)
KILL STATEMENT Direct Read & Fileman Read
^DD(File#, Field#,1,SEQ,1,3)
NO DELETE MESSAGE Direct Read & Fileman Read
^DD(File#, Field#,1,SEQ,1,"DT")
DATE UPDATED Direct Read & Fileman Read
^DD(File#, Field#,1,SEQ,1,"%D")
DESCRIPTION Direct Read & Fileman Read\n
^DD(File#, Field#,3)
.01 'HELP'-PROMPT 0;1 Direct Read & Fileman Read\n
^DD(File#, Field#,21)
.01 DATE LAST UPDATED 0;1 Direct Read & Fileman Read\n
^DD(File#, Field#,"DT")
.01 DATE LAST UPDATED 0;1 Direct Read & Fileman Read\n
Global Location may be read and traversed by direct means.
^DD(File#, "GL", Node, Piece, Field#)\n
Global Indexes may be read and traversed by direct means.
^DD(File#, 0, "IX", Reference, File#, Field#)", "", "", ""], ["7146", "CPRS BANNER REMINDER API", "Routine", "CLINICAL REMINDERS", "2020/04/09", "APPROVED", "Active", "Controlled Subscription", "", "
This API returns the status of reminder to be use by
the CPRS banner and the CPRS information panel functionalities.\n
Revision History
3/26/25: ICR updated with PXRMBANNER routine with the comment below. The new
routine will be released with patch PXRM*2.0*87 this is part of the CPRS 33con
bundle of patches.\n
4/16/24: CPRS33 deprecates PXRMCOVID19 routine, replacing it with
PXRMBANNER. The only difference between the Routines is the possible
error message will not contain the word COVID19.", "", "PXRMBANNER", "2025/03/26"], ["7147", "ORQOR DETAIL", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2020/04/15", "", "Withdrawn", "Private", "", "
VistA Scheduling Enhancement (VSE) has a need to
provide the detailed information for a patient's consult orders to VS GUI. VS
GUI will pass the order IEN and patient DFN as parameters to retrieve the
order details.\n\n
Input: ORDIEN ; order identifier
DFN ; patient identifier", "ORQOR DETAIL", "", ""], ["7148", "IFCAP API: WORK ORDER XREF UPDATE", "Routine", "IFCAP", "2020/04/23", "", "Pending", "Private", "", "
This integration agreement allows the call to
ST^ENWOINV associated with Generate PMI Worklists which creates or finds work
orders for a specified PM worklist and then makes calls to print that
document.\n
ST component will update the Work Order.", "", "ENWOINV", ""], ["7149", "IFCAP API: PMWO WORK ORDER LIST", "Routine", "IFCAP", "2020/04/23", "", "Pending", "Private", "", "
This integration agreement allows the call to
LST2^ENEQPMS2 to identify Work Orders associated with specified PM Work Order.\n", "", "ENEQPMS2", ""], ["7150", "IFCAP API: PMWO WORK ORDER COMPLETED", "Routine", "IFCAP", "2020/04/23", "", "Pending", "Private", "", "
This integration agreement allows the call to
TEST^ENWOCOMP to check if the Work Orders can be marked completed.", "", "ENWOCOMP", ""], ["7151", "IFCAP API: FRCMR GENERATE FR DOC", "Routine", "IFCAP", "2020/04/23", "", "Pending", "Private", "", "
This integration agreement allows the call to
$$$$FRCMR^ENFAEIL, used to generate FR Documents without user interaction.
It's called when a batch of FR Documents are being sent due to a change of CMR
name or EIL cost center.", "", "ENFAEIL", ""], ["7152", "DELETE CERNER FIELD FROM THE INSTITUTION FILE", "Routine", "1", "2020/04/27", "APPROVED", "Active", "Private", "", "
CERNER field in the INSTITUTION file is no longer used
and it needs to be removed from the file. This integration agreement is to
allow use of a supported Fileman API to delete the field . This API will be
used in the post-install routine XU8P729.\n
FileMan API being used:
Deleting Fields ^DIK: Delete Data Dictionary Reference Type: Supported
Category: Classic VA FileMan ICR#: 10014", "", "", "2020/05/04"], ["7153", "HL7 adaptor error messaging (RAO7ROXV)", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2020/04/27", "APPROVED", "Active", "Private", "", "
****** NOTE: This ICR is temporary and will be
cancelled when the HL7 adaptor is no longer in use at any site. *****\n\n
HL7 adaptor stores error messages about HL7 messages from Cerner in file
#79.99 via calls to RAO7ROXV.", "", "RAO7ROXV", "2020/08/20"], ["7154", "GIVE THIS DBIA A BETTER NAME THAN DBIA7154", "", "", "2020/04/28", "", "Pending", "", "", "", "", "", ""], ["7155", "PXRMDESCAPI returns reminder item descriptions", "Routine", "CLINICAL REMINDERS", "2020/04/29", "", "Pending", "Controlled Subscription", "", "", "", "PXRMDESCAPI", ""], ["7156", "FileMan access to file #100, field #5 (STATUS)", "File", "ORDER ENTRY/RESULTS REPORTING", "2020/04/29", "APPROVED", "Active", "Private", "100", "", "", "", "2020/05/04"], ["7157", "Use of routine ORMSD to close RTCs", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2020/04/29", "", "Withdrawn", "Private", "", "", "", "ORMSD", ""], ["7158", "ERT - CONTROL POINT ACTIVITY", "File", "IFCAP", "2020/05/08", "", "Withdrawn", "Private", "410.2", "
Enterprise Reporting Tool (ERT) requests read access to
Control Point Activity (#410.2) field NAME (#.01).", "", "", ""], ["7159", "ERT - CALM/LOG CODE SHEET", "File", "IFCAP", "2020/05/08", "", "Withdrawn", "Private", "423", "
Enterprise Reporting Tool (ERT) requests read access to
Calm/Log Code Sheet (#423) field ID# (#.01).", "", "", ""], ["7160", "ERT - MANUFACTURER LIST FILE", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6912", "
Enterprise Reporting Tool (ERT) requests read access to
Manufacturer List File (#6912) field MFG/DIV (#.01).", "", "", ""], ["7161", "ERT - WORK ORDER", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Controlled Subscription", "6920", "
Enterprise Reporting Tool (ERT) requests read access to
Work Order # File (#6929) field WORK ORDER # (#.01).", "", "", ""], ["7162", "ERT - EQUIPMENT CATEGORY", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6911", "
Enterprise Reporting Tool (ERT) requests read access to
EQUIPMENT CATEGORY (#6911) field NAME (#.01).", "", "", ""], ["7163", "ERT - CMR", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6914.1", "
Enterprise Reporting Tool (ERT) requests read access to
CMR (#6914.1) field NAME (#.01).", "", "", ""], ["7164", "ERT - NX SGL", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6914.3", "
Enterprise Reporting Tool (ERT) requests read access to
NX SGL (#6914.3) field ACCOUNT (#.01).", "", "", ""], ["7165", "ERT - NX BOC", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6914.4", "
Enterprise Reporting Tool (ERT) requests read access to
NX BOC (#6914.4) field CAPITALIZED BUDGET OBJECT CODE (#.01).", "", "", ""], ["7166", "ERT - NX FUND", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6914.6", "
Enterprise Reporting Tool (ERT) requests read access to
NX FUND (#6914.6) field NX FUND CODE (#.01).", "", "", ""], ["7167", "ERT - CATEGORY STOCK NUMBER", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6917", "
Enterprise Reporting Tool (ERT) requests read access to
CATEGORY STOCK NUMBER (#6917) field NAME (#.01).", "", "", ""], ["7168", "ERT - UTILITY SYSTEMS", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6018.1", "\n
Enterprise Reporting Tool (ERT) requests read access to UTILITY SYSTEMS
(#6918.1) field NAME (#.01).", "", "", ""], ["7169", "ERT - ENGINEERING SECTION LIST", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6922", "\n
Enterprise Reporting Tool (ERT) requests read access to ENGINEERING SECTION
LIST (#6922) field ENGINEERING SECTION (#.01).", "", "", ""], ["7170", "ERT - ENG SPACE", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6928", "
Enterprise Reporting Tool (ERT) requests read access to
ENG SPACE (#6928) field ROOM NUMBER (#.01).", "", "", ""], ["7171", "ERT - ENG EMPLOYEE", "File", "ENGINEERING", "2020/05/08", "", "Withdrawn", "Private", "6929", "
Enterprise Reporting Tool (ERT) requests read access to
ENG EMPLOYEE (#6929) field NAME (#.01).", "", "", ""], ["7172", "ERT - PURCHASE ORDER STATUS", "File", "IFCAP", "2020/05/08", "", "Withdrawn", "Private", "442.3", "
Enterprise Reporting Tool (ERT) requests read access to
PURCHASE ORDER STATUS (#442.3) fields NAME (#.01), SUPPLY STATUS ORDER (#.02),
and FISCAL STATUS ORDER (#.03).", "", "", ""], ["7173", "ERT - DD READ ACCESS", "File", "1", "2020/05/08", "", "Pending", "Private", "0", "
Enterprise Reporting Tool (ERT) requests read access to
Data Dictionary file attributes.\n
Global File & Field may be read and traversed by direct means.\n
^DD(File#, Field#,0)
.01 LABEL 0;1 Direct Read & Fileman Read
.2 SPECIFIER 0;2 Direct Read & Fileman Read
.3 POINTER 0;3 Direct Read & Fileman Read
.4 GLOBAL SUBSCRIPT LOCATION 0;4 Direct Read & Fileman Read
INPUT TRANSFORM 0;5 Direct Read & Fileman Read\n
^DD(PFile#,.01)
Pfile pointer FILE# from .3 POINTER
.01 LABEL 0;1 Direct Read & Fileman Read
.2 SPECIFIER 0;2 Direct Read & Fileman Read", "", "", ""], ["7174", "TEAM POSITION PROVIDER CHANGES", "File", "SCHEDULING", "2020/05/11", "APPROVED", "Active", "Private", "404.52", "
Patch VPR*1*28 will use CREIXN^DDMOD to add a new
regular 'ADP' index to the POSITION ASSIGNMENT HISTORY (#404.52) file, to sort
assignments by Effective Date and Team Position. This cross reference will be
used by VPR to track PCMM team position provider changes to keep VPR and PCMM
synchronized.\n
This agreement permits the VPR application to create the new index and use it
in a nightly job to find position assignments that have changed that day.", "", "", "2021/12/09"], ["7175", "YSCL UPDATE PHARMACY PATIENT CLOZAPINE", "Routine", "OUTPATIENT PHARMACY", "2020/05/13", "APPROVED", "Active", "Private", "", "
Mental Health (YS) Clozapine software invokes
Outpatient Pharmacy (PSO) API to update the CLOZAPINE REGISTRATION NUMBER
field (#53) and the CLOZAPINE STATUS field (#54) in the PHARMACY PATIENT file
(#55) when a new entry is filed in the CLOZAPINE PATIENT LIST file (#603.01)
via a database trigger x-ref.", "", "PSOCLADD", "2020/06/16"], ["7176", "PSJCLOZ CLOZAPINE UTILITIES", "Routine", "INPATIENT MEDICATIONS", "2020/05/26", "APPROVED", "Active", "Controlled Subscription", "", "
API $$ISCLOZ^PSJCLOZ is used to determine if a pharmacy
order is considered a clozapine order. Clozapine orders require special
processing as determined by the National Clozapine Coordinating Center (NCCC).\n", "", "PSJCLOZ", "2020/06/16"], ["7177", "PENDING NEW PERSON FIELD UPDATES", "File", "KERNEL", "2020/06/01", "APPROVED", "Active", "Private", "8933.1", "
The CLINICAL INFO RESOURCE NETWORK (CIRN) package has a
monitoring process in routine RGMTMONT that examines/displays the number of
messages received, messages processed, messages needing transmission, messages
transmitted and the current state of the CIRN links, as well as showing the
number of incoming and outgoing filers running. CIRN will augment this monitor
processing to also include information on the pending NEW PERSON (#200) field
updates by looping through and counting the number of pending entries stored
in the "ACXMIT" X-REF in the NEW PERSON FIELD MONITOR (#8933.1) file that need
to be transmitted at the time the monitoring process is executed.\n
NOTE: "ACXMIT" X-REF entries in file #8933.1 are deleted upon
successful transmission of the NEW PERSON (#200) field
updates to the Person Service Identity Management (PSIM)
system.\n
As another aspect of the 'Monitoring' process, CIRN has incorporated a process
to count the number of outdated and no longer needed NEW PERSON FIELD MONITOR
(#8933.1) records that will be purged from the file. This process requires
access to the "B" X-REF on the NEW PERSON FIELD MONITOR (#8933.1) file and the
USER (#.02) field, which allows CIRN to ensure there are no pending
transmissions ("ACXMIT" X-REF check) for that User prior to including in the
'Purge' count.\n
Therefore CIRN requests 'Direct Global Read & w/Fileman' for the entire NEW
PERSON FIELD MONITOR (#8933.1) file to aid in this monitoring process.", "", "", "2020/06/17"], ["7178", "DVBAB REPORTS", "Remote Procedure", "AUTOMATED MED INFO EXCHANGE", "2020/06/03", "APPROVED", "Active", "Private", "", "", "DVBAB REPORTS", "", "2020/06/03"], ["7179", "Create TIU Document Definitions", "Routine", "TEXT INTEGRATION UTILITIES", "2020/06/10", "APPROVED", "Active", "Controlled Subscription", "", "
This API may be used by non-TIU packages to add entries
to the TIU DOCUMENT DEFINITIONS File # 8925.1.\n
Entries allowed are CLASSES, DOCUMENT CLASSES, and TITLES. This API does not
support the creation of OBJECTS or COMPONENTS.\n
This API is an EXTRINSIC function and returns the IEN of the new entry or
0^<description of error>.", "", "TIUCRDD", "2020/06/11"], ["7180", "VPR use of EDP LOG", "File", "EMERGENCY DEPARTMENT", "2020/06/15", "APPROVED", "Active", "Private", "230", "
This IA documents the use of the EDP LOG file by the
Virtual Patient Record (VPR) application. VPR extracts patient data from VistA
for sharing with external care partners via InterSystems' HealthShare
platform.", "", "", "2020/07/17"], ["7181", "AVPR index on EDP LOG", "File", "EMERGENCY DEPARTMENT", "2020/06/16", "APPROVED", "Active", "Private", "230", "
The Virtual Patient Record (VPR) would like to create
an action index on the EDP LOG (#230) file that would call a VPR API in
routine VPRENC when a record in the file is closed. The FileMan utility
CREIXN^DDMOD would be used in a post-init for patch VPR*1*20 to create the
AVPR index instead of exporting the data dictionary.\n
The fields listed here are included in the index for purposes of triggering
the action. No actual cross reference nodes are created.\n
Amended 5/31/22, by adding DISPOSTION Field 1.2 effective with VPR*1*29.", "", "", "2020/07/17"], ["7182", "ALLOW IB TO READ ENROLLMENT FIELDS IN THE PATIENT FILE", "File", "REGISTRATION", "2020/06/18", "", "Pending", "Controlled Subscription", "2", "
To support the MISSION ACT of 2018, global access to
the PATIENT file (#2) is requested in order to assist in determining whether a
veteran is eligible to receive a free Urgent Care visit. Patient Records will
be identified by the internal entry number (DFN) in file #2, and read using
standard FileMan's APIs.\n
Integrated Billing needs access to the following
PATIENT file (#2) fields:
.3012 SC AWARD DATE .3;12
.3014 EFF. DATE COMBINED SC% EVAL. .3;14
.3612 ELIGIBILITY STATUS DATE .361;2", "", "", ""], ["7183", "NEW PERSON FIELD MONITOR PURGE", "File", "KERNEL", "2020/06/25", "APPROVED", "Active", "Private", "8989.3", "
The CLINICAL INFO RESOURCE NETWORK (CIRN) package has a
monitoring process on the NEW PERSON FIELD MONITOR (#8933.1) file to ensure
that NEW PERSON (#200) updates are being transmitted to the Person Service
Identity Management (PSIM) system as part of the Enterprise User Identity
functionality. As part of this monitoring process, CIRN will need to retrieve
the NEW PERSON FIELD MONITOR PURGE (#875) value from the KERNEL SYSTEM
PARAMETERS (#8989.3) file to determine if the NEW PERSON FIELD MONITOR
(#8933.1) record has exceeded the timeframe so that it can be purged/deleted
from the file. This will ensure that the NEW PERSON FIELD MONITOR (#8933.1)
file is maintained at an acceptable size level.", "", "", "2020/09/17"], ["7184", "RPA NEW PERSON USER ADD", "File", "KERNEL", "2020/07/10", "", "Pending", "Private", "200", "
IB Revenue Operations requires the creation of VistA
user accounts nationally for bot software access to selected IB options for
automating certain repetitive tasks. These accounts will be created in the NEW
PERSON file (#200) by Integrated Billing patch IB*2*680 using Supported VA
FileMan database server APIs.", "", "", ""], ["7185", "DBIA7185", "Routine", "REGISTRATION", "2020/07/16", "APPROVED", "Active", "Private", "", "
Below fields from patient file are getting retrieved
and populated in ZCE segment:\n
2.191,.01 CCP LAST UPDATED DATE 2.191,1 COMMUNITY CARE PROGRAM
CODE 2.191,2 EFFECTIVE DATE 2.191,3 END DATE", "", "VAFHLZCE", "2020/12/01"], ["7186", "CONNECT RADIOLOGY EXAM TO VISIT", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2020/07/20", "APPROVED", "Active", "Private", "70", "", "", "", "2020/07/21"], ["7187", "DG ACCESS TO DD(9000001,0,'PT'", "File", "PCE PATIENT CARE ENCOUNTER", "2020/07/22", "APPROVED", "Active", "Private", "9000001", "
The REGISTRATION package is requesting approval to
access the list of Files that point to the PATIENT/IHS File by examining
entries in ^DD(9000001,0,"PT"). The purpose is to identify Patient-related
Files for the VistA Security Remediation Audit Solution (VAS) in order to
determine which AUDIT (#1.1) records should be sent to the external archive.", "", "", "2020/08/13"], ["7188", "DBIA7188", "Routine", "MENTAL HEALTH", "2020/07/27", "APPROVED", "Active", "Controlled Subscription", "", "
This agreement provides the calling program to build
inpatient clozapine data for transmission. This ICR is created to document a
call to INPSND^YSCLRST5, which was released in patch PSJ*5*327.", "", "YSCLTST5", "2020/08/24"], ["7189", "DG MENU OPTIONS FOR BILLING USERS", "Other", "REGISTRATION", "2020/08/04", "APPROVED", "Active", "Private", "", "
The billing users of the [IB OUTPUT PATIENT REPORT
MENU] menu need access to REGISTRATION menu options [DG OTH FSM ELIG. CHANGE
REPORT] and [DG OTH FSM DETAIL REPORT]. These reports are developed in DG
namespace patch DG*5.3*1025. This is to identify patients treated under Other
Than Honorable authority and get detailed information about these patients.\n
Integrated Billing is requesting permission to export the option [DG OTH FSM
ELIG. CHANGE REPORT] and [DG OTH FSM DETAIL REPORT] in their menu option [IB
OUTPUT PATIENT REPORT MENU] in patch IB*2*685 and will be using the option.\n
This Integration Agreement grants permission to make these REGISTRATION
options included in the [IB OUTPUT PATIENT REPORT MENU] menu.", "", "", "2020/09/04"], ["7190", "READ ACCESS TO THE WEB SERVICE FILE 18.02", "File", "WEB SERVICES CLIENT", "2020/08/05", "APPROVED", "Active", "Private", "18.02", "
This request is for a one time use in patch DG*5.3*1014
post installation processing.\n
Registration requests read access to the WEB SERVICE (#18.02) file. The
post-install routine creates a WEB SERVICE record using the supported
REGREST^XOBWLIB API, then reads the WEB SERVICE file with the $$GET1^DIQ
FileMan API to get the IEN of the WEB SERVICE record. Then in further
processing (reference pending ICR-7191) updates the WEB SERVER (#18.12) file,
AUTHORIZED WEB SERVICES (#100) multiple.\n
This processing is done programmatically to avoid having sites manually
configure HWSC using the Web Server Manager.", "", "", "2020/10/19"], ["7191", "READ/WRITE ACCESS TO WEB SERVER FILE 18.12", "File", "WEB SERVICES CLIENT", "2020/08/05", "APPROVED", "Active", "Private", "18.12", "
The VistA REE (Registration, Eligibility and
Enrollment) team requests read/write access to the WEB SERVER (#18.12) file
to add a new entry during the DG*5.3*1014 post-install process. The
post-install routine process will create the new server record entry using
UPDATE^DIE and will also create a new entry to the AUTHORIZED WEB SERVICES
(#100) multiple, WEB SERVICE (#.01) field.\n
NOTE: This processing is done programmatically to avoid having sites manually
configure HWSC using the Web Server Manager. This will ensure all sites have
the same configuration installed correctly.", "", "", "2020/10/19"], ["7192", "DETERMINE FOLLOW-UP", "Routine", "SCHEDULING", "2020/08/31", "", "Pending", "Private", "", "
The DSS Electronic Dental Record Manager (EDRM)
application is creating Dental appointments for the Cerner Millennium
integration. Millennium sends an SIU^S14 HL7 message when a Veteran checks in
to the Dental Clinic. The HL7 message allows Dental users to select a VistA
appointment that matches the Millennium Encounter. The HL7 message also
contains necessary encounter data to be returned to Millennium when filing
vital signs, notes and encounter procedures/diagnoses so that the records are
applied to the correct Millennium encounter.\n
The PTFU API returns the follow-up visit indicator to be filed into the
FOLLOW-UP VISIT (#28) field of the APPOINTMENT (#2.98) subfile of the PATIENT
(#2) file.", "", "SDM0", ""], ["7193", "NEW APPOINTMENT STATUS", "Routine", "SCHEDULING", "2020/08/31", "", "Pending", "Private", "", "
The DSS Electronic Dental Record Manager (EDRM)
application is creating Dental appointments for the Cerner Millennium
integration. Millennium sends an SIU^S14 HL7 message when a Veteran checks in
to the Dental Clinic. The HL7 message allows Dental users to select a VistA
appointment that matches the Millennium Encounter. The HL7 message also
contains necessary encounter data to be returned to Millennium when filing
vital signs, notes and encounter procedures/diagnoses so that the records are
applied to the correct Millennium Encounter.\n
The STATUS API determines the status for the new appointments to be fild into
the STATUS (#3) field of the APPOINTMENT (#2.98) subfile of the PATIENT (#2)
file when creating an appointment.", "", "SDM1A", ""], ["7194", "TIU DENTAL NOTES", "File", "TEXT INTEGRATION UTILITIES", "2020/08/31", "", "Pending", "Private", "8925", "
The Electronic Dental Record Manager (EDRM) application
is creating MDM^T02 HL7 messages for the Cerner Millennium integration. These
messages contain signed Dental TIU Notes. Dental is requesting to read
discreet data from the TIU DOCUMENT (#8925) file to create the HL7 message.", "", "", ""], ["7195", "TIU ADDITIONAL SIGNERS", "File", "TEXT INTEGRATION UTILITIES", "2020/08/31", "", "Pending", "Private", "8925.7", "
The Electronic Dental Record Manager (EDRM) application
is creating MDM^T02 HL7 messages for the Cerner Millennium integration. These
messages contain signed Dental TIU Notes. Dental is requesting to read
discreet data from the TIU MULTIPLE SIGNATURE (#8925.7) file to add signature,
cosignature, and additional signature information to the HL7 message.", "", "", ""], ["7196", "LOOK UP REQUEST/CONSULTATION DATA", "File", "CONSULT/REQUEST TRACKING", "2020/09/02", "", "Pending", "Private", "123", "
The Centralized Scheduling Solution (CSS) project, part
of the larger EHRM project, requests permission to read data from file #123 as
detailed below. Patch OR*3.0*520 will be using this ICR.", "", "", ""], ["7197", "UPDATE CONSULT ORDER STATUS FROM SCHEDULING", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2020/09/03", "", "Pending", "Private", "", "
This agreement allows the new Scheduling routine
SDMCMAKE (SD*5.3*738) to call the new Order Entry routine ORMCTR (OR*3.0*520)
at the entry point TRUPDMSG and pass a consult order IEN. The variable CONSID
is the IEN of a consult order created inside Scheduling and is used to trigger
an status update via an HLO message for an order from the Centralized
Scheduling Solution (CSS). This ICR will be used in patch SD*5.3*738.", "", "ORMCTR", ""], ["7198", "VDIF access to VA MPI FTL", "Other", "REGISTRATION", "2020/09/03", "", "Pending", "Private", "", "
VDIF needs to access the FTL (Facility Treatment List)
for a patient from VA MPI.\n
VA MPI note: The only approved business process to use VDIF Patient Registry
is Cerner HIE. External VistA apps should be coming to VA MPI directly (not
proxying through VDIF) and VistA apps should be using the local VAFC LOCAL
GETCORRESPONDINGIDS RPC.\n
This ICR cannot be used by other packages trying to proxy access through VDIF.
It is not VDIF data to expose and/or approve exposure to. It is VA MPI and
more importantly IAM IPT technical and business owners to approve the FTL
access.", "", "", ""], ["7199", "WOMEN VET API FOR VPR", "Routine", "WOMEN'S HEALTH", "2020/09/04", "APPROVED", "Active", "Controlled Subscription", "", "
Allow subscriber access for Virtual Patient Record
(VPR) to the routine BASELINE^WVRPCVPR so that VPR may retrieve preganancy
status for a patient.", "", "WVRPCVPR", "2020/09/29"], ["7200", "WOMEN VET PROTOCOL FOR VPR", "Other", "WOMEN'S HEALTH", "2020/09/04", "APPROVED", "Active", "Controlled Subscription", "", "
To document Virtual Patient Record's (VPR) use of the
WV PREGNANCY STATUS CHANGE EVENT protocol.", "", "", "2020/09/29"], ["7201", "APPT CANCELLATION REASON TYPE", "Routine", "SCHEDULING", "2020/09/04", "", "Pending", "Private", "", "
This agreement allows the routine ORMCCORE to call the
routine SDMCGAPT to obtain the cancellation reason and type (in external and
internal format) for a given patient appointment.", "", "SDMCGAPT", ""], ["7202", "BILLING STATUS API", "Routine", "INTEGRATED BILLING", "2020/09/17", "APPROVED", "Active", "Private", "", "
This DBIA is for allowing the REGISTRATION package to
call the EN^IBEFSMUT(DFN,BEGDT,ENDDT,LIST) entry point to return requested
data elements stored in the INTEGRATED BILLING application. Listed below are
the details on accessing this entry point and the data that should be
returned.", "", "IBEFSMUT", "2021/02/18"], ["7203", "DBIA3879-D", "Routine", "VBECS", "2020/09/21", "", "Pending", "Controlled Subscription", "", "
The entry point EN^VBECRPT is provided by the Blood
Bank package to return Blood Bank patient related data for use by CPRS. This
data will be used to populate the Blood Bank Report listed under the Reports
tab.", "", "VBECRPT", ""], ["7204", "READ WRITE ACCESS TO WEB SERVER FILE", "File", "WEB SERVICES CLIENT", "2020/10/01", "APPROVED", "Active", "Controlled Subscription", "18.12", "
This request is for a one time use in patch
GMRC*3.0*124 post installation processing.\n
GMRC (Consults Decision Support Tool) requests read and write access to the
WEB SERVER (#18.12) file. The post-install routine checks if the server
record exists, then either creates or updates the record using either the
UPDATE^DIE or FILE^DIE FileMan API calls, respectively. In addition it adds
an entry (if it doesn't exist) to the AUTHORIZED WEB SERVICES (#100) multiple,
WEB SERVICE (#.01) field using the UPDATE^DIE FileMan API.\n
This processing is done programmatically to avoid having sites manually
configure.\n
Revision History:
- Added 3/20/25 - This request is for a one time write access in patch
DVBA*2.7*255 post installation processing.\n
CAPRI (Compensation and Pension Record Interchange) requests read and write
access to the WEB SERVER (#18.12) file. The post-install routine checks if
the server record exists, then creates the record using the FILE^DICN FileMan
API call. In addition it adds an entry (if it doesn't exist) to the AUTHORIZED
WEB SERVICES (#100) multiple, WEB SERVICE (#.01) field using the UPDATE^DIE
FileMan API.\n
This processing is done programmatically to avoid having sites manually
configure.\n
The CAPRI routine that uses the HealtheVet Web Service Client uses
FIND1^DIC FileMan API to check the web server was installed before
proceeding.", "", "", "2023/11/20"], ["7205", "READ WRITE ACCESS TO THE WEB SERVICE FILE", "File", "WEB SERVICES CLIENT", "2020/10/01", "APPROVED", "Active", "Controlled Subscription", "18.02", "
This request is for a one time use in patch
GMRC*3.0*124 post installation processing.\n
GMRC (Consult Decision Support Tool) requests read and write access to the WEB
SERVICE (#18.02) file. The post-install routine creates a WEB SERVICE record.
Then in further processing (reference ICR-7204) updates the WEB SERVER
(#18.12) file, AUTHORIZED WEB SERVICES (#100) multiple.\n
This processing is done programmatically to avoid having sites manually
configure.\n
Revision History:
- Added 3/20/25:
This request is for a one time write access in patch DVBA*2.7*255 post
installation processing. CAPRI (Compensation and Pension Record Interchange)
requests read and write access to the WEB SERVICE (#18.02) file. The
post-install routine creates a WEB SERVICE record. Then in further processing
(reference ICR- 7204) updates the WEB SERVER (#18.12) file, AUTHORIZED WEB
SERVICES (#100) multiple.
This processing is done programmatically to avoid having sites manually
configure.
The CAPRI routine that uses the HealtheVet Web Service Client uses
FIND1^DIC FileMan API to check the web service was installed before
proceeding.", "", "", "2023/11/21"], ["7206", "Clozapine Inpatient Reference", "File", "PHARMACY DATA MANAGEMENT", "2020/10/21", "", "Pending", "Private", "55.06", "
The MENTAL HEALTH (YS) Clozapine module has a need to
read the DATE VERIFIED BY PHARMACIST field (#19) in the UNIT DOSE multiple
(#62) (sub-file 55.06) in the PHARMACY PATIENT file (#55) via FileMan.\n
This field is not included in the PHARMACY DATA MANAGEMENT (PDM) API's. When
the field becomes available via PDM API, the FileMan reference should be
converted to API call and this ICR should be retired.", "", "", ""], ["7207", "CLOZAPINE OVERRIDES", "File", "OUTPATIENT PHARMACY", "2020/10/21", "", "Pending", "Private", "52.52", "
The MENTAL HEALTH (YS) Clozapine module has a need to
read the SECOND APPROVING TEAM MEMBER field (#6) in the CLOZAPINE PRESCRIPTION
OVERRIDES file (#52.52) via FileMan.\n
The MENTAL HEALTH (YS) package formerly had access to the file via expired ICR
DBIA273-D, which was replaced by Pharmacy Data Management API PSO5252. The
PSO5252 API does not include this field.\n
When the field becomes available via Pharmacy API, the FileMan reference
should be converted to API call and this ICR should be retired.", "", "", ""], ["7208", "RETRIEVE ENROLLMENT STATUS", "Routine", "REGISTRATION", "2020/10/23", "APPROVED", "Active", "Controlled Subscription", "", "
This API will be used to determine if the Patient is
known to Enrollment System or not by calling E&E Web Service.", "", "DGREGEEWS", "2021/03/03"], ["7209", "AMPL USER IDENTIFICATION", "File", "KERNEL", "2020/10/26", "", "Pending", "Private", "200", "
The Advanced Medication Platform (AMPL) application
requests access the internal entry number of all entries of the NEW PERSON
File (#200) to use in supported API calls.", "", "", ""], ["7210", "LAB DATA RELEASING SITE", "File", "LAB SERVICE", "2020/11/05", "APPROVED", "Active", "Private", "63", "
This integration agreement grants the subscriber read
access to all the RELEASING SITE fields in the LAB DATA file.", "", "", "2020/11/23"], ["7211", "ORB3USER APIS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2020/11/30", "", "Active", "Controlled Subscription", "", "
For CPRS v32a development, the GMRA package needs
access to verify a user is able to receive an alert for a specific
notification.", "", "ORB3USER", ""], ["7212", "PSOBPSU4", "Routine", "OUTPATIENT PHARMACY", "2020/12/07", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains a subroutine associated with the
Bypass 3/4 Day Supply Logic flags in the Prescription file (52) and the Refill
subfile (52.1) of the Prescription file (52).", "", "PSOBPSU4", "2021/05/05"], ["7213", "PSOSULB2", "Routine", "OUTPATIENT PHARMACY", "2020/12/30", "APPROVED", "Active", "Controlled Subscription", "", "
This routine contains a function, $$EBILLABLE, which
checks whether a prescription is ebillable (i.e. can be electronically billed
to a third party payer).", "", "PSOSULB2", "2021/01/04"], ["7214", "DGPFAAH", "Routine", "REGISTRATION", "2021/01/11", "APPROVED", "Active", "Controlled Subscription", "", "
Retrieve list of history IENs for an assignment.", "", "DGPFAAH", "2021/02/02"], ["7215", "LR7OAPKM", "Routine", "LAB SERVICE", "2021/01/12", "APPROVED", "Active", "Controlled Subscription", "", "", "", "LR7OAPKM", "2021/01/13"], ["7216", "LR AP DIALOG CONFIG", "File", "LAB SERVICE", "2021/01/12", "", "Expired", "Private", "69.73", "
OE/RR reads and writes from the LR AP DIALOG CONFIG
file (#69.73) to configure the Delphi forms for CPRS.", "", "", "2021/01/13"], ["7217", "DBIA7217", "File", "INTEGRATED BILLING", "2021/01/22", "APPROVED", "Active", "Private", "399", "
This integration agreement allows access to the
following cross-reference within file 399:\n
^DGCR(399,"C" use of the "C" cross-reference for patient look-up\n
and FileMan access to the fields listed below.", "", "", "2021/01/22"], ["7218", "DBIA7218", "File", "INTEGRATED BILLING", "2021/01/22", "APPROVED", "Active", "Private", "350", "
This integration agreement allows FileMan access to the
fields listed below.", "", "", "2021/01/22"], ["7219", "GIVE THIS DBIA A BETTER NAME THAN DBIA7219", "", "", "2021/01/24", "", "Pending", "", "", "", "", "", ""], ["7220", "ORDER FILE READ BY CAPRI GUI", "File", "ORDER ENTRY/RESULTS REPORTING", "2021/01/24", "", "Pending", "Private", "100", "
CAPRI GUI has the need to read File 100 for upgrade to
the Order Builder option within the GUI to display information for Patient
Orders", "", "", ""], ["7221", "IB ACCESS TO AR REPAYMENT PLAN FILE", "File", "ACCOUNTS RECEIVABLE", "2021/01/28", "APPROVED", "Active", "Private", "340.5", "
This ICR allows Integrated Billing to access data in
the AR REPAYMENT PLAN file (#340.5) for the following reports:\n
1. First Party Follow-up Report [IBJD FOLLOW-UP FIRST PARTY]\n
2. Repayment Plan Follow-up Report [IBJD FOLLOW-UP REPAYMENT PLAN]", "", "", "2021/05/05"], ["7222", "PSOERXU9", "Routine", "OUTPATIENT PHARMACY", "2021/02/02", "APPROVED", "Active", "Private", "", "
The routine PSOERXU9 has entry points to return a
pointer to the ERX HOLDING QUEUE file (#52.49) based on a PRESCRIPTION IEN or
PENDING OUTPATIENT ORDER IEN, return a pointer to the ERX HOLDING QUEUE file
(#52.49) based on an ORDER IEN, and return data from the ERX HOLDING QUEUE
file (#52.49) based on the ERX HOLDING QUEUE IEN.", "", "PSOERXU9", "2021/02/16"], ["7223", "TIU CALLS TO GMRCGUIB", "Routine", "CONSULT/REQUEST TRACKING", "2021/02/04", "APPROVED", "Active", "Controlled Subscription", "", "
The Community Care Referrals and Authorization (CCRA)
project is sending clinical notes that are to filed with a community care
consult request. When the notes are filed, a comment is being added to the
activity log in the consult.", "", "GMRCGUIB", "2021/03/03"], ["7224", "TIU CALL TO GMRCP", "Routine", "CONSULT/REQUEST TRACKING", "2021/02/04", "APPROVED", "Active", "Controlled Subscription", "", "
The Community Care Referrals and Authorization (CCRA)
project is sending clinical notes that are to filed with a community care
consult request. When the notes are filed, the CPRS STATUS of the consult is
reset.", "", "GMRCP", "2021/03/03"], ["7225", "Calls to TIUPREF", "Routine", "TEXT INTEGRATION UTILITIES", "2021/02/11", "APPROVED", "Active", "Private", "", "
This DBIA documents calls to TIUPREF.", "", "TIUPREF", "2021/02/19"], ["7226", "OR OTH Button Add/Edit Local Message", "Other", "ORDER ENTRY/RESULTS REPORTING", "2021/02/11", "", "Pending", "Private", "", "
Add/Edit Local Messge for OTH Button in CPRS GUI", "", "", ""], ["7227", "PSOSIG", "Routine", "OUTPATIENT PHARMACY", "2021/02/12", "APPROVED", "Active", "Private", "", "
This call, provided by Outpatient Pharmacy, will return
the expanded version of an ADMINISTRATION SCHEDULE. For example, a schedule of
BID will return TWICE A DAY or a schedule TU will return TUESDAY.", "", "PSOSIG", "2021/06/07"], ["7228", "SHRPE ACTIVATION DATE", "File", "INTEGRATED BILLING", "2021/02/17", "APPROVED", "Active", "Private", "350.9", "
Accounts Receivable application needs to read the SHRPE
activation date stored in the Integrated Billing file (#350.9) to determine
when copays exemption rules and prorated RX copay amounts for patients with
the High Risk for Suicide flag become applicable.", "", "", "2021/03/09"], ["7229", "DBIA7229", "File", "REGISTRATION", "2021/02/24", "APPROVED", "Active", "Controlled Subscription", "26.13", "
^DGPF(26.13,"C" use of the "C" cross-reference for
patient look-up.", "", "", "2021/03/12"], ["7230", "REPAYMENT PLAN STATUS REPORT", "Routine", "ACCOUNTS RECEIVABLE", "2021/02/25", "", "Pending", "Private", "", "
Integrated Billing needs access to the new Repayment
Plan Status report [PRCAC PLAN STATUS REPORT] in the Diagnostic Measures
Follow-up Reports Menu as a replacement to the retired (as of PRCA*4.5*378)
REPAYMENT PLAN FOLLOW-UP REPORT [IBJD FOLLOW-UP REPAYMENT PLAN].", "", "RCRPSTR", ""], ["7231", "CERNER NAK ERROR LOG", "Routine", "ELECTRONIC HEALTH MODERNIZATION", "2021/02/26", "", "Under Revision", "Supported", "", "
This integration agreement allows other packages to
call the supported routine ADD2LOG^EHMUHLV. If any interface that is sending
messages to/from Cerner receives a NAK, this API will need to be called in
order to send an email back to Cerner users stating what error occurred.\n
Six possible parameters need to be passed in to the API:\n
ADD2LOG(TYPE,INTERFACE,MESSAGE,SEVERITY,CIDNUM,SOURCE)\n
TYPE (Required) = Severity of the log entry
'E' FOR ERROR Record could not be processed
'W' FOR WARNING Record was processed but should be reviewed
'D' FOR DATA DEFAULTED A default value was substituted before processing
the record\n
INTERFACE (Required) = Interface that generated the log entry\n
MESSAGE (Required) = Reason for log entry
(may refer to a segment or field)\n
SEVERITY (Required) = Severity of the error
'H' FOR HIGH failure requires immediate attention
'M' FOR MEDIUM failure is important, but not critical
'L' FOR LOW log entry can be researched over time
'I' FOR EH log entry is informational only\n
CIDNUM (Required) = Cerner ID Number\n
SOURCE (Optional) = Source of log entry. Should contain HL7 full message if
needed", "", "EHMUHLV", "2021/03/03"], ["7232", "SCHEDULED ADMISSIONS FILE ENTRY NOTIFIER", "Other", "REGISTRATION", "2021/03/04", "APPROVED", "Active", "Controlled Subscription", "", "
The DG SA FILE ENTRY NOTIFIER protocol will notify
subscribers when an entry in the SCHEDULED ADMISSION (#41.1) file is created,
modified, or deleted. The protocol is fired by a FileMan cross-reference on
the SCHEDULED ADMISSION file. End-user options that ultimately invoke this
protocol include:
DG SCHED ADMIT CANCEL
DG SCHED ADMIT ENTRY
DG SCHED ADMIT PURGE\n
The following data is available to subscribers:\n
^TMP("DG SA FILE ENTRY NOTIFIER",$J","ACTION")=ACTION
ACTION: The action that was taken on the entry. Possible values are
"CREATED", "MODIFIED" and "DELETED".\n
^TMP("DG SA FILE ENTRY NOTIFIER",$J,"DATE")=DATE
DATE: FileMan date/time (internal format) of when the activity occurred.\n
^TMP("DG SA FILE ENTRY NOTIFIER",$J,"DFN","CURRENT")=DFN
DFN: Internal Entry Number (IEN) of the patient in the PATIENT file
(#2). This is the patient the entry points to after the change.\n
^TMP("DG SA FILE ENTRY NOTIFIER",$J,"DFN","OLD")=DFN
DFN: Internal Entry Number (IEN) of the patient in the PATIENT file
(#2). This is the patient the entry pointed to before the change.\n
^TMP("DG SA FILE ENTRY NOTIFIER",$J,"FIELDS",NAME)=""
NAME: When the ACTION is "MODIFIED", the "FIELDS" subscript is
created. Nodes descendant from the "FIELDS" subscript are the
field number of the field(s) that were edited.\n
^TMP("DG SA FILE ENTRY NOTIFIER",$J,"IEN")=IEN
IEN: Internal Entry Number (IEN) of the affected entry.", "", "", "2021/08/25"], ["7233", "VAFC LOCAL GETCORRESPONDINGIDS", "Routine", "REGISTRATION", "2021/03/15", "", "Withdrawn", "Private", "", "
Community Care Referrals and Authorization (CCRA)
project has been tasked with sending the EDIPI with consult requests
transmitted to the HealthShare Referral Manager.\n
These patient ids will be displayed by HSRM and some, including the EDIPI,
will be displayed on the printed offline referral form generated by HSRM. They
are used by community care staff to look-up veteran information on other
systems.", "", "VAFCTFU2", ""], ["7234", "BARCODE PRINT SITE DEFINED LABEL", "Other", "ENGINEERING", "2021/03/19", "APPROVED", "Active", "Private", "", "
Above PAR requests permission to perform the site
specific label print as defined in ENGINEERING COMPUTER PORT FILE ACCESS
(#6910.1) fields;
BAR CODE EQUIPMENT FORMAT (#3)
BAR CODE LOCATION FORMAT (#4)
BAR CODE EQUIPMENT DATA (#5)
BAR CODE LOCATION DATA (#6)\n
The label routines defined in these four fields require that standard
processing variables be defined prior to running the routine. The variables
would be those defined in ENLBL3 and/or ENLBL7. These variables include;
DA Equipment IEN (#6914)
ENEQBC Label Data
ENEQLM Size Limit
ENEQSTA Station
ENEQSTAN Station Name
ENELBLBOT Label Bottom
ENLBLHD Label Header
ENBCIO IO Device (Printer)
ENBCIOS Device File (#3.5) IEN
ENEQBY Label Format\n
Example of Equipment custom label print
BAR CODE EQUIPMENT FORMAT - D FORMAT2^ADBWLBL7
BAR CODE EQUIPMENT DATA - D FULL^ADBWLBL7", "", "", "2021/03/31"], ["7235", "ET DDA Segments for PC Charge and PC Order", "Routine", "IFCAP", "2021/03/22", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call IFCAP APIs for building the DDA
segment for the Purchase Card Charge and the DDA for the Purchase Card Order.
The DDAs are then compared to determine if an ET transaction needs to be
generated to correct the accounting string for the charge's expense in FMS.", "", "PRCH0A", "2021/04/20"], ["7236", "AUTO-GENERATE FMS ET-DOCUMENTS", "Routine", "IFCAP", "2021/03/22", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call IFCAP routine PRCH8A to
auto-generate a Financial Management System (FMS) Expenditure Transfer
(ET)-document.", "", "PRCH8A", "2021/04/21"], ["7237", "PRCD FUND/APPROPRIATION CODE FILE ACCESS", "File", "IFCAP", "2021/03/22", "APPROVED", "Active", "Private", "420.3", "
The Advanced Prosthetics Acquisition Tool (APAT)
requests permission to read the PRCD FUND/APPROPRIATION CODE FILE (#420.3)
file when reconciling purchase card orders. APAT will look up the Fund entry
in file #420.3 using the "B" cross reference in order to determine if the fund
is a revolving fund based on the entry's value in the YES/NO field REVOLVING
FUND (#7).", "", "", "2021/04/20"], ["7238", "IB BILLING CLERK MENU Option", "Other", "INTEGRATED BILLING", "2021/04/01", "", "Pending", "Private", "", "
Communication ICR: The RPA Revenue Operations Project
developers have created a Robotic solution to replace a specific set of IB
Clerk option steps to determine whether a patient should be billed. The RPA
BOT project was written to utilize exact prompts available to a clerk,
starting with the IB BILLING CLERK MENU option, which is the target option for
this ICR.\n
Background for project: The RPA Revenue Operations Project was approved by
upper management for two bots to run a script to login (through WebVRAM) and
then go to specific sites and run a couple IB and Accounts Receivable
reporting options. The output of the first report is stored in a cloud and
converted to excel as part of the bot processing from the first report run.
Then the second option script is run, using the patients in the first report
output to correct the billing status based on the Service Connected
information.\n
This ICR is a request for IB package developers to communicate with the RPA
Project Manager (PM) when a patch that changes prompts related to the IB
BILLING CLERK MENU option is within a month from going to IOC. This
communication will help the RPA PM plan actions to minimize the impact on the
RPA robotic functionality implemented at a site. The IB developers do not need
to hold up the IB Agile development (IOC and release) to wait for the RPA BOT
project to make software changes.\n
The IB developers agree to provide the RPA BOT project manager with details
about what has changed so the RPA BOT Team can assess impact and plan to
coordinate changes to their product.", "", "", ""], ["7239", "IB CANCEL/EDIT/ADD CHARGES Option", "Other", "INTEGRATED BILLING", "2021/04/01", "", "Pending", "Private", "", "
duplicate from 7238", "", "", ""], ["7240", "RCDMCR6 50-100SC EXMPT RPT Option", "Other", "ACCOUNTS RECEIVABLE", "2021/04/01", "", "Pending", "Private", "", "", "", "", ""], ["7241", "RCDMCR7 10-40% COPAY RPT Option", "Other", "ACCOUNTS RECEIVABLE", "2021/04/01", "", "Pending", "Private", "", "", "", "", ""], ["7242", "GIVE THIS DBIA A BETTER NAME THAN DBIA7242", "", "", "2021/04/06", "", "Pending", "", "", "", "", "", ""], ["7243", "ACCESS TO THE OTH REPORT", "Routine", "REGISTRATION", "2021/04/07", "APPROVED", "Active", "Private", "", "
The INTEGRATED BILLING package needs to run the
REGISTRATION report implemented as MAIN^DGOTHFSM modified in the patch
DG*5.3*1047 to display information for INTEGRATED BILLING (IB) users. This
report identifies Former Service Members whose Primary Eligibility changed
from EXPANDED MH CARE NON-ENROLLEE to a new Primary Eligibility with a
VERIFIED eligibility status. These patients are no longer treated under the
Other Than Honorable (OTH) authority (VHA Directive 1601A.02).\n
This agreement grants the IB menu option Former OTH Patient Eligibility Change
Report [IB OTH FSM ELIG. CHANGE REPORT] a permission to run MAIN^DGOTHFSM
entry point that allows IB users to see additional information related to MST
(Military Sexual Trauma) screening results.\n
The new IB menu option Former OTH Patient Eligibility Change Report [IB OTH
FSM ELIG. CHANGE REPORT] is introduced by the patch IB*2.0*701.", "", "DGOTHFSM", "2021/04/15"], ["7244", "XUS MVI NEW PERSON RMTE AUDIT", "Remote Procedure", "KERNEL", "2021/04/08", "APPROVED", "Active", "Private", "", "
In support of the ongoing work of implementing
Enterprise User Identity, the Master Veteran Index (MVI) team requests
permission to exclusively use the following restricted KERNEL Remote Procedure
Call (RPC) [XUS MVI NEW PERSON RMTE AUDIT] to allow retrieval of the audit
history for a specific user's record in the NEW PERSON (#200) file at the
specified facility for viewing. This retrieved audit information will be used
to assist in troubleshooting issues with a user's account and for determining
how/when and ultimately why the record was changed if needed. This restricted
RPC is to be used exclusively by the Master Veteran Index (MVI) to
review/display the requested audit history of a user's record in the NEW
PERSON (#200) file at a specific facility.\n
TAG: AUDIT ROUTINE: XURNPAUD\n
Parameters:
PARAM("SourceSystemID") [Required] - Facility Station Number
PARAM("SourceID") [Required] - Individual's DUZ
PARAM("BegDate") [Optional] - Earliest date of Audit records
to return
PARAM("EndDate") [Optional] - Last date of Audit records to
return\n", "XUS MVI NEW PERSON RMTE AUDIT", "", "2021/04/09"], ["7245", "Retrieve XQADATA from an alert", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2021/04/13", "", "Pending", "Controlled Subscription", "", "
Returns XQADATA for a given alert XQAID", "", "ORWORB", ""], ["7246", "GET RADIOLOGY CASE INFO FROM WOMEN'S HEALTH", "Routine", "WOMEN'S HEALTH", "2021/04/13", "APPROVED", "Active", "Private", "", "
This API returns the following information for a given
IEN from file 790.1.\n
Primary Diagnosis Code from Radiology IENS to link to the Radiology entry from
file 70 that links to the report entry. Report IEN from file 74 Secondary
Diagnosis is an array of secondary diagnosis entered when verifying a
radiology report.", "", "WVALERTR", "2021/04/13"], ["7247", "PXRMEUT", "Routine", "CLINICAL REMINDERS", "2021/04/16", "APPROVED", "Active", "Private", "", "
The purpose of this Integration Control Registration is
to grant Order Entry/Results Reporting access to the ASKYN linetag in the
routine PXRMEUT.", "", "PXRMEUT", "2021/11/09"], ["7248", "EDIT 2237 RUNNING BALANCE FIELDS", "Routine", "IFCAP", "2021/04/19", "APPROVED", "Active", "Private", "", "
This integration agreement allows the Advanced
Prosthetics Acquisition Tool (APAT) to call IFCAP routine PRC0G during
purchase card order reconciliation and during the removal of a reconciliation
to edit RUNNING BALANCE QUARTER DATE (#449) and RUNNING BALANCE STATUS (#450),
if necessary, in the CONTROL POINT ACTIVITY #410 file.", "", "PRC0G", "2021/05/14"], ["7249", "CAREGIVER RELATIONSHIPS", "Routine", "REGISTRATION", "2021/04/30", "APPROVED", "Active", "Supported", "", "
The purpose of this Integration Control Registration is
to grant packages the ability to retrieve patient caregiver relationship
information.", "", "VAFCREL", "2022/01/27"], ["7250", "CPRS GUI (OR) SIGN-ON LOG LOOKUP", "File", "KERNEL", "2021/05/03", "", "Pending", "Private", "3.081", "
The CPRS GUI requests the ability to do a lookup on the
SIGN-ON LOG for a current user's SIGN-ON LOG IEN and Field #3 (SIGNOFF TIME).\n
To lookup the current SIGN-ON LOG for the user's active CPRS session using the
following screen based on the user's UCI, Job#, & IP Address:\n
S SCR="I $P(^(0),U,8)=UCI,$P(^(0),U,3)=$J,$P(^(0),U,11)=$G(IO(""IP""))" with
$$FIND1^DIC("3.081","","Q",DUZ,"CUR",SCR,"ERR").\n
To lookup the SIGNOFF TIME (Field #3) for a given session:
$$GET1^DIQ("3.081",<IEN>,3,"I")", "", "", ""], ["7251", "OEHRM Imaging Migration - access to file #123", "File", "CONSULT/REQUEST TRACKING", "2021/05/04", "APPROVED", "Active", "Private", "123", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", "2022/04/19"], ["7252", "OEHRM Imaging Migration - use of GMRCIAC2", "Routine", "CONSULT/REQUEST TRACKING", "2021/05/04", "", "Pending", "Private", "", "
When consults are resulted, the GMRC EVSEND OR protocol
executes. A new protocol - EHM CONSULTS - will be added to this parent
protocol to add or update records in the Imaging Migration database. This new
protocol needs to call GETDA^GMRIAC2 to extract the IEN of file #123 from the
incoming HL7 message.", "", "GMRCIAC2", ""], ["7253", "OEHRM Imaging Migration - Access to file #2006.5839", "File", "IMAGING", "2021/05/04", "", "Pending", "Private", "2006.5839", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", ""], ["7254", "OEHRM Imaging Migration - Access to file #2005", "File", "IMAGING", "2021/05/04", "APPROVED", "Active", "Private", "2005", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.\n
Note: The patch - EHM*1*2 - will not be installed nationally. It will be
installed only at sites that are being converted to Cerner.", "", "", "2021/06/15"], ["7255", "OEHRM Imaging Migration - Access to file #2005.61", "File", "IMAGING", "2021/05/04", "", "Pending", "Private", "2005.61", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", ""], ["7256", "OEHRM Imaging Migration - Access to file #70", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2021/05/04", "APPROVED", "Active", "Private", "70", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", "2022/04/21"], ["7257", "OEHRM Imaging Migration - Access to file #74", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2021/05/04", "", "Under Revision", "Private", "74", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", "2021/06/08"], ["7258", "CHECK SMART ALERTS", "Routine", "CLINICAL REMINDERS", "2021/05/06", "APPROVED", "Active", "Private", "", "
The purpose of this integration agreement is to grant
access to use PXRMCALT to perform special processing for the SMART alerts.
CPRS v31B released the System for Mammography Results Tracking (SMART) NSR
20100701 functionality. As part of the changes involved with this NSR, a call
to ALTDATA^PXRMCALT was implemented in OE/RR functionality released in
OR*3*377 and PXRM*2*45. Documentation is being added in OR*3*535 for ICR 7258
as part of an ICR clean-up effort.", "", "PXRMCALT", "2023/06/22"], ["7259", "AbandonedDGSEC4 routine", "Routine", "REGISTRATION", "2021/05/10", "", "Withdrawn", "Private", "", "", "", "", ""], ["7260", "YTQRRPC SELECT", "Remote Procedure", "MENTAL HEALTH", "2021/05/11", "APPROVED", "Active", "Private", "", "
RPC for Mental Health Check Up Calls for Instrument
Selection.", "YTQRRPC SELECT", "", "2021/05/11"], ["7261", "GIVE THIS DBIA A BETTER NAME THAN DBIA7261", "", "", "2021/05/11", "", "Pending", "", "", "", "", "", ""], ["7262", "PROVIDER CLASS (#53.5) field in the NEW PERSON (#200) file", "File", "OUTPATIENT PHARMACY", "2021/05/15", "APPROVED", "Active", "Controlled Subscription", "200", "
The Home Based Primary Care (HBPC - formerly known as
Hospital Based Home Care) package displays the PROVIDER CLASS (#53.5) field
from the NEW PERSON (#200) file in the option "Provider File Data Entry". The
display aids users in ensuring the correct entry is being added as a provider
for HBPC.", "", "", "2021/06/08"], ["7263", "DOC ONLY - COPY OF 2237", "File", "SURGERY", "2021/05/21", "", "Pending", "Private", "133", "
This is a DOCUMENT ONLY ICR for Class 3 package, MSCJ
namespace, for the PICIS interface. The PICIS/VistA interface is for incoming
HL7 Surgery requests coming from the PICIS COTS Surgery Scheduling
application. MSCJ falls under the Medsphere Systems Corporation package in
the MSC namespace. MSCJ sub-package has permission to execute direct global
reads of the SITE field (#.01) (0;1) and the 'B' Cross Reference on the
SURGERY SITE file (#133).", "", "", ""], ["7264", "DOC ONLY - Access to SROXR1", "Routine", "SURGERY", "2021/05/21", "", "Pending", "Private", "", "
DOCUMENT ONLY: PICIS Surgery Scheduling Interface is a
subpackage (MSCJ namespace) within Medshere Systems Corporation (MSC
namespace). This is a Class 3 ICR for the MSCJ MEDSPHERE PICIS APPLICATIONS
Package, patch MSCJ*n*n for use of the APIs in the ^SROXR1 routine to
facilitate scheduling surgeries from the PICIS Surgery Scheduling package.
The Routine MSCJSR01 calls the SROXR1 API's to add and delete surgery
schedules from the PICIS interface. API components, AR and KAR in the ^SROXR1
routine, are used for creating and deleting the "AR" cross references in the
SURGERY, #130, file for the DATE OF OPERATION, #.09, field.", "", "SROXR1", ""], ["7265", "OEHRM Imaging Migration - Access to file #8925.91", "File", "TEXT INTEGRATION UTILITIES", "2021/05/28", "APPROVED", "Active", "Private", "8925.91", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", "2021/06/09"], ["7266", "OEHRM Image Migration - access to file #391.91", "File", "REGISTRATION", "2021/06/01", "", "Pending", "Private", "391.91", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", ""], ["7267", "OEHRM Imaging Migration - Access to file #2005.62", "File", "IMAGING", "2021/06/01", "", "Pending", "Private", "2005.62", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.\n
Note: The patch - EHM*1*2 - will not be installed nationally. It will be
installed on at sites that are being converted to Cerner.", "", "", ""], ["7268", "OEHRM - Subscribe to RA RPT 2.3", "Other", "RADIOLOGY/NUCLEAR MEDICINE", "2021/06/01", "", "Pending", "Private", "", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.\n
Note: The patch - EHM*1*2 - will not be installed nationally. It will be
installed on at sites that are being converted to Cerner.", "", "", ""], ["7269", "PRCA FP VETERAN CHRG RPT ADD TO DVBA HRC MENUS", "Other", "ACCOUNTS RECEIVABLE", "2021/06/07", "APPROVED", "Active", "Private", "", "
HRC is requesting the addition of the FIRST PARTY
VETERAN CHARGE REPORT [PRCA FP VETERAN CHRG RPT] OPTION to the following
DVBA/HRC menus:\n
DVBA HRC MENU PHARMACY\n
DVBA HRC MENU PHARMACY CC\n
DVBA HRC MENU EXTENDED SVCS", "", "", "2021/06/15"], ["7270", "OEHRM Imaging Migration - Access to file #2005.63", "File", "IMAGING", "2021/06/15", "", "Pending", "Private", "2005.63", "
OEHRM is creating Imaging Migration software to
facilitate the transfer of images from VistA to Millennium. The software will
build a central accession number database that identifies all image-holding
entities - consults and Radiology procedures - and will maintain that file
throughout the conversion period.", "", "", ""], ["7271", "Copy of ICR 103 with Document Only fields", "File", "SURGERY", "2021/06/15", "", "Pending", "Private", "130", "
This ICR is created for Document Only purposes to allow
MSCJ MEDSPHERE PICIS APPLICATIONS Package to be compliant with SAC standards
requiring FileMan read/write access. The routine MSCJSR01 performs reads and
writes to the SURGERY, #130, file using FileMan. The following FileMan fields
are accessed in a read/write manner using FileMan APIs.\n
The following indented fields (.01, .011, .02, .09. .14, .164, 17, and 50
would have been covered in ICR 103, but the Surgery Custodian POC requested
this Class 3 product's access be defined in it's own ICR. The fields not
indented would have needed to be added to 103, which was a concern for the
POC.\n\n
.01 - PATIENT
.011 - IN/OUT-PATIENT STATUS
.0155 - CLASSIFICATION ENTERED (Y/N)
.02 - OPERATING ROOM
.03 - MAJOR/MINOR
.035 - CASE SCHEDULE TYPE
.05 - REQ CLEAN OR CONTAMINATED
.09 - DATE OF OPERATION
.13 - RESTR & POSITION AIDS
.14 - SURGEON
.15 - FIRST ASST
.16 - SECOND ASST
.164 - ATTEND SURG
.42 - OTHER PROCEDURES
1.098 - DATE/TIME R REQUEST MADE
1.099 - SURG SCHED PERSON
10 - SCHEDULED START TIME
11 - SCHEDULED END TIME
17 - CANCEL DATE
26 - PRINCIPAL PROCEDURE
27 - PLANNED PRIN PROCEDURE CODE
36 - REQUESTED
37 - ESTIMATED CASE LENGTH
38 - REQUEST BLOOD AVAILABILITY
50 - DIVISION
55 - INDICATIONS FOR OPERATIONS
56 - PRE-ADMISSION TESTING", "", "", "2021/06/15"], ["7272", "RECORD OF PROS APPLIANCE/REPAIR FILE 660 FILEMAN READS", "File", "PROSTHETICS", "2021/06/24", "", "Pending", "Private", "660", "
Generic database integration agreement for doing
Fileman READS for ALL fields into Prosthetics file# 660 - RECORD OF PROS
APPLIANCE/REPAIR. Use of Fileman APIs $$GET1^DIQ and GETS^DIQ for all fields
in file 660 and all fields in all subfiles of file 660.", "", "", ""], ["7273", "SDEC APPSDGET", "Remote Procedure", "SCHEDULING", "2021/07/15", "APPROVED", "Active", "Private", "", "
VTEX will use this as part of the CHECK-IN/KIOSK
replacement project. VSIP is the Veteran Scheduling InteroPerability web-based
solution. The SDEC APPSDGET will be used to get the veterans appointments.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC APPSDGET", "", "2021/07/15"], ["7274", "VPS GET DFN", "Remote Procedure", "VA POINT OF SERVICE (KIOSKS)", "2021/07/20", "APPROVED", "Active", "Private", "", "
VTEX (VEText) is working with OCTO/OVAC to replace
Kiosk Hardware as part of the Checkin/VSIP project. VEText is a web-based
application that will use this RPC as part of the solution being developed
called VSIP. VEText will use the RPC VPS GET DFN to get information about the
patient.", "VPS GET DFN", "", "2021/08/31"], ["7275", "VPS GET2 PATIENT DEMOGRAPHIC", "Remote Procedure", "VA POINT OF SERVICE (KIOSKS)", "2021/07/20", "APPROVED", "Active", "Private", "", "
VEText is working with OCTO/OVAC to on a project to
replace VPS Kisk HArdware with a new mobile expierence. VEText needs to use
VPS GET2 PATIENT DEMOGRAPHIC to get patient information as part of the new
VSIP project.", "VPS GET2 PATIENT DEMOGRAPHIC", "", "2021/09/02"], ["7276", "COMPACT ACT ELIGIBLE", "Routine", "REGISTRATION", "2021/07/23", "", "Pending", "Supported", "", "
Returns the COMPACT Act Indicator.\n
The indicator is '1' (for TRUE) if either of the following conditions is true:\n
- Enrollment Category from the patient's current enrollment record is
"ENROLLED".
- The patient record contains the "COMPACT ACT ELIGIBLE" eligibility
code.", "", "DGENELA", ""], ["7277", "READ PENSION INFORMATION", "File", "REGISTRATION", "2021/08/06", "APPROVED", "Active", "Private", "2", "
Accounts Receivable (AR) needs access to the following
fields in the Patient file via FileMan Utilities in order to determine if any
outstanding First Party (i.e. copay) debt can be cancelled due to a Pension
Award in patch PRCA*4.5*384.\n
The fields AR will use are:\n
Patient File (#2) fields:\n
.3851 - PENSION AWARD EFFECTIVE DATE
.3853 - PENSION TERMINATED DATE", "", "", "2022/03/18"], ["7278", "PROSTHETICS ORDERS REPORT", "File", "CONSULT/REQUEST TRACKING", "2021/08/16", "APPROVED", "Active", "Private", "123", "", "", "", "2021/08/17"], ["7279", "XU EPCS ADD DEA", "Remote Procedure", "OUTPATIENT PHARMACY", "2021/08/17", "", "Pending", "Controlled Subscription", "", "
TESTING", "XU EPCS ADD DEA", "", ""], ["7280", "WEBG ADD/EDIT/DELETE ORDER DIALOG", "Remote Procedure", "WEB VISTA REMOTE ACCESS MANAGEMENT", "2021/08/26", "", "Pending", "Private", "", "
Allows the WebVRAM GUI application to add new entry,
edit and delete entry from the Order Dialog file #101.41\n
NAME: WEBG ADD ORDLG TAG: ORDADD ROUTINE: WEBGORUT
RETURN VALUE TYPE: SINGLE VALUE AVAILABILITY: RESTRICTED DESCRIPTION:
The ICR is still in progress.
Allows the WebVRAM application to add new entry to the Order Dialog file
#101.41 INPUT PARAMETER: ORDLGDATA PARAMETER TYPE: LITERAL
REQUIRED: YES
DESCRIPTION:
These are the data fields that need to be set into the Order Dialog file
#101.41. Contains the following "^" piece delimited structure:\n
ORDLGDATA=p1^p2^p3
where:
p1 := [required] The external value from the Order Dialog name
(#101.41,.01)
p2 := [optional] Display Text (101.41,2)
p3 := [optional] Type
If not passed in, the routine will default the type to
"D"ialog\n
Example:
ORDLGDATA=WEBG OR NEW ORDER DIALOG^Sample Display Text^D\n
RETURN PARAMETER DESCRIPTION:
Returns a single value in the following format:\n
If the adding of entry is successful:
RESULT= IEN from the Order Dialog file #101.41^message\n
Otherwise,
RESULT=-1^error_message\n\n\n
NAME: WEBG EDIT ORDLG TAG: EDITORD ROUTINE: WEBGORUT
RETURN VALUE TYPE: SINGLE VALUE DESCRIPTION:
The ICR is still need to be requested.
Allows the WebVRAM application to add new entry to the Order Dialog file
#101.41 INPUT PARAMETER: ORDLGDATA PARAMETER TYPE: LITERAL
REQUIRED: YES
DESCRIPTION:
These are the data fields that need to be set into the Order Dialog file
#101.41. Contains the following "^" piece delimited structure:\n
ORDLGDATA=p1^p2^p3
where:
p1 := [required] The external value from the Order Dialog name
(#101.41,.01)
p2 := [optional] Display Text (101.41,2)
p3 := [optional] Type
Example:
ORDLGDATA=WEBG OR NEW ORDER DIALOG^Sample Display Text^D\n
RETURN PARAMETER DESCRIPTION:
Return a single value in the following format:\n
If the adding of entry is successful:
RESULT=1^message\n
Otherwise,
RESULT=-1^error_message\n\n
NAME: WEBG DELETE ORDLG TAG: DELORD ROUTINE:
WEBGORUT RETURN VALUE TYPE: SINGLE VALUE AVAILABILITY: RESTRICTED
DESCRIPTION:
The ICR still need to be requested.
Allows WebVRAM application to delete/remove an entry from the Order
Dialog file #101.41 INPUT PARAMETER: ORDNAME PARAMETER TYPE:
LITERAL
REQUIRED: YES
DESCRIPTION:
This is the external value from the Order Dialog file #101.41,.01\n
RETURN PARAMETER DESCRIPTION:
Return a single value in the following format:\n
If successful:
RESULT=1^message\n
Othwerwise,
RESULT=-1^error_message", "", "", ""], ["7281", "TIU LOINC SERVICE", "File", "TEXT INTEGRATION UTILITIES", "2021/09/01", "APPROVED", "Active", "Private", "8926.5", "
The Release of Information (ROI) team would like
FILEMAN read access to the .01 field of file TIU LOINC SERVICE (#8926.5) to
determine which Compensation and Pension service is being pointed to by the
.07 field of file VHA ENTERPRISE STANDARD TITLE (# 8926.1)", "", "", "2021/09/20"], ["7282", "PXVRPC1", "Routine", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXVRPC1", "2021/10/13"], ["7283", "PXVRPC2", "Routine", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXVRPC2", "2021/10/13"], ["7284", "PXVRPC4", "Routine", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXVRPC4", "2021/10/13"], ["7285", "PXVRPC5", "Routine", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXVRPC5", "2021/10/13"], ["7286", "PXVRPC8", "Routine", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXVRPC8", "2021/10/13"], ["7287", "PXVIMM IMM SHORT LIST", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM IMM SHORT LIST TAG: IMMSHORT
ROUTINE: PXVRPC4 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns a short list of immunizations. INPUT PARAMETER: FILTER
PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 1
DESCRIPTION:
Filter (Optional; Defaults to "B")
Possible values are: ;
"A": Only return active entries
"H": Only return entries marked as Selectable for Historic
"B": Return both active entries and those marked as Selectable for
Historic INPUT PARAMETER: PXDATE PARAMETER TYPE:
LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION:
Date (optional; defaults to TODAY)
Used for determining immunization status (both for filtering and for
return value) INPUT PARAMETER: OREXCLUDE PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 3
DESCRIPTION:
Should entries defined in ORWPCE EXCLUDE IMMUNIZATIONS be excluded? INPUT
PARAMETER: LOCATION PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 4
DESCRIPTION:
Used when excluding entried listed in ORWPCE EXCLUDE IMMUNIZATIONS. This
is the location used when getting the paramater value at the Location
level.
RETURN PARAMETER DESCRIPTION:
PXRTRN(x)
Note: Status (in the 5th piece) is determined as follows:
- If PXDATE is today, the status is based off the Inactive Flag
(#.07)
- If PXDATE is different than today, we will look when an update was
last made to the Immunization file (based off the Audits). If there
have not been any changes since PXDATE, we will get the status
based off the Inactive Flag, otherwise, we will get the status for
that date by calling GETSTAT^XTID.
1: "IMM"
2: #9999999.14 IEN
3: Name (#.01)
4: CVX Code (#.03)
5: Status (1: Active; 0: Inactive)
6: Selectable for Historic (#8803)
7: Mnemonic (#8801)
8: Acronym (#8802)
9: Active Lot linked to this Immunization? (1:Yes; 0:No)
PXRTRN(x)
1: "CDC"
2: CDC Product Name (#9999999.145, #.01)
PXRTRN(x)
1: "GROUP"
2: Vaccine Group Name (#9999999.147, #.01)", "PXVIMM IMM SHORT LIST", "", "2021/10/21"], ["7288", "PXVIMM IMM DETAILED", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM IMM DETAILED TAG: IMMRPC
ROUTINE: PXVRPC4 RETURN VALUE TYPE: GLOBAL ARRAY
WORD WRAP ON: TRUE
DESCRIPTION:
Returns a detailed Immunization record INPUT PARAMETER: PXIMM
PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
Pointer to #9999999.14 (Required) INPUT PARAMETER: PXDATE
PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION:
Immunization status and Codes will be based off this date
(Optional; Defaults to NOW) INPUT PARAMETER: PXLOC PARAMETER
TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 3
DESCRIPTION:
Used to determine Institution, when filtering Lot and Defaults (Optional).
Possible values are:
"I:X": Institution (#4) IEN #X
"V:X": Visit (#9000010) IEN #X
"L:X": Hopital Location (#44) IEN #X\n
If PXLOC is not passed in OR could not make determination based off input,
then default to DUZ(2), and if DUZ(2) is not defined, default to Default
Institution.
RETURN PARAMETER DESCRIPTION:
^TMP("PXVIMMRPC",$J,0)
1: 1 - Immunization was found. The "1" node will be returned, but the
other nodes are optional.
-1 - Immunization was not found; no other nodes will be returned
^TMP("PXVIMMRPC",$J,1)
Note: Status (in the 5th piece) is determined as follows:
- If PXDATE is today, the status is based off the Inactive Flag
(#.07)
- If PXDATE is different than today, we will look when an update was
last made to the Immunization file (based off the Audits). If there
have not been any changes since PXDATE, we will get the status
based off the Inactive Flag, otherwise, we will get the status for
that date by calling GETSTAT^XTID.
1: "IMM"
2: #9999999.14 IEN
3: Name (#.01)
4: CVX Code (#.03)
5: Status (1: Active; 0: Inactive)
6: Selectable for Historic (#8803)
7: Mnemonic (#8801)
8: Acronym (#8802)
9: Max # In Series (#.05)
10: Combination Immunization (Y/N) (#.2)
11: Reading Required (#.51)
12: Series Required (calculated)
^TMP("PXVIMMRPC",$J,x)
1: "VIS"
2: #920 IEN
3: Name (#920,#.01)
4: Edition Date (#920,#.02)
5: Edition Status (#920,#.03)
6: Language (#920, #.04)
7: 2D Bar Code (#100)
8: VIS URL (#101)
^TMP("PXVIMMRPC",$J,x)
1: "CDC"
2: CDC Product Name (#9999999.145, #.01)
^TMP("PXVIMMRPC",$J,x)
1: "GROUP"
2: Vaccine Group Name (#9999999.147, #.01)
^TMP("PXVIMMRPC",$J,x)
1: "SYNONYM"
2: Synonym (#9999999.141, #.01)
^TMP("PXVIMMRPC",$J,x)
Note: Only active codes (based off PXDATE) are returned.
1: "CS"
2: Coding System (#9999999.143, #.01)
3: Code (#9999999.1431,#.01)
4: Variable pointer. e.g., IEN;ICPT(
5: Short Description
^TMP("PXVIMMRPC",$J,x)
Note: Only active lots for the given division are returned.
Also, the Expiration date must be >= PXDATE
1: "LOT"
2: #9999999.41 IEN
3: Lot Number (#9999999.41, #.01)
4: Manufacturer (#9999999.04, #.01)
5: Expiration Date (#9999999.41, #.09)
6: Doses Unused (#9999999.41, #.12)
7: Low Supply Alert (#9999999.41, #.15)
8: NDC Code (#9999999.41, #.18)
^TMP("PXVIMMRPC",$J,x)
Note: Only active contraindications are returned
1: "CONTRA"
2: #920.4 variable pointer: IEN;PXV(920.4,
3: Name (#920.4, #.01)
4: Status (1:Active, 0:Inactive)
5: Code|Coding System (#920.4, #.02 and .05)
6: NIP004 (#920.4, #.04)
7: Contraindication/Precaution (#920.4, #.06)
8: Allergy-Related (1:Yes, 0:No)
9: Default Warn Until Date ("Forever" means it should be forever)
^TMP("PXVIMMRPC",$J,x)
1: "DEF"
2: Default Route (#920.051, #1302)
3: Default Site (#920.051, #1303)
4: Default Dose (#920.051, #1312)
5: Default Dose Units (#920.051, #1313)
6: Default Dose Units (external format) (#920.051, #1313)
7: Default Non-Standard Dose Units (#920.051, #1314)
^TMP("PXVIMMRPC",$J,x)
1: "DEFC"
2: Default Comments (#920.051, #81101)", "PXVIMM IMM DETAILED", "", "2021/10/21"], ["7289", "PXVIMM ADMIN SITE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM ADMIN SITE TAG: IMMSITE
ROUTINE: PXVRPC2 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns entries from the IMM ADMINISTRATION SITE (BODY) file (920.3). INPUT
PARAMETER: FILTER PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 1
DESCRIPTION:
Filter. Possible values are:
R:XXX - Return entry with IEN XXX.
H:XXX - Return entry with HL7 Code XXX.
N:XXX - Return entry with #.01 field equal to XXX
S:X - Return all entries with a status of X.
Possible values of X:
A - Active Entries
I - Inactive Entries
B - Both active and inactive entries\n
Defaults to "S:B".
RETURN PARAMETER DESCRIPTION:
Returns:
PXVRSLT(0)=Count of elements returned (0 if nothing found)
PXVRSLT(n)=IEN^Name^HL7 Code^Status (1:Active, 0:Inactive)\n
When filtering based off IEN, HL7 Code, or #.01 field, only one entry will
be returned in PXVRSLT(1).\n
When filtering based off status, multiple entries can be returned. The
first entry will be returned in subscript 1, and subscripts will be
incremented by 1 for further entries. Entries will be sorted
alphabetically.\n
If no entries are found based off the filtering criteria, PXVRSLT(0) will
equal 0, and there will be no data returned in the subsequent subscripts.", "PXVIMM ADMIN SITE", "", "2021/10/21"], ["7290", "PXVIMM ICR LIST", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM ICR LIST TAG: GETICR
ROUTINE: PXVRPC5 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns entries from the IMM CONTRAINDICATION REASONS (#920.4) and IMM
REFUSAL REASONS (#920.5) files. INPUT PARAMETER: PXFILE
PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 1
DESCRIPTION:
Which file to pull from.
(Optional; Leave this null to pull entries from both files)
Possible values are:
"920.4" - Only return entries from IMM CONTRAINDICATION REASONS
(#920.4)
"920.5" - Only return entries from IMM REFUSAL REASONS (#920.5) INPUT
PARAMETER: FILTER PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION:
Filter (Optional; Defaults to "S:A")
Possible values are:
R:X - Return entry with IEN X (PXFILE must be passed in with this
option).
C:X^Y - Return entry with Concept Code^Coding System X^Y (used only for
#920.4).
H:X - Return entry with HL7 Code X (used only for #920.5).
N:X - Return entry with #.01 field equal to X
I:X - Return all active entries that are selectable for Immunization
IEN X.
S:A - Return all active entries.
S:I - Return all inactive entries.
S:B - Return all entries (both active and inactive). INPUT PARAMETER:
INST PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 3
DESCRIPTION:
Institution IEN INPUT PARAMETER: LOC PARAMETER TYPE:
LITERAL
SEQUENCE NUMBER: 4
DESCRIPTION:
Location IEN (If Institution IEN is not passed in, the loc will be used
to get the institution).
RETURN PARAMETER DESCRIPTION:
PXRSLT(0)=Count of elements returned (0 if nothing found)
For 920.4 Entry:
PXRSLT(n)=IEN;PXV(920.4,^Name^Status (1:Active, 0:Inactive)^Code|Coding
System^NIP004^Contraindication/Precaution^Allergy-Related
(1:Yes, 0:No)^Default Warn Until Date ("Forever" means it
should be forever)
For 920.5 Entry:
PXRSLT(n)=IEN;PXV(920.5,^Name^Status (1:Active, 0:Inactive)^HL7
Code^Default Warn Until Date ("Forever" means it should be
forever)", "PXVIMM ICR LIST", "", "2021/10/21"], ["7291", "PXVIMM INFO SOURCE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM INFO SOURCE TAG: IMMSRC
ROUTINE: PXVRPC2 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns entries from the IMMUNIZATION INFO SOURCE file (920.1). INPUT
PARAMETER: FILTER PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 1
DESCRIPTION:
Filter. Possible values are:
R:XXX - Return entry with IEN XXX.
H:XXX - Return entry with HL7 Code XXX.
N:XXX - Return entry with #.01 field equal to XXX
S:X - Return all entries with a status of X.
Possible values of X:
A - Active Entries
I - Inactive Entries
B - Both active and inactive entries\n
Defaults to "S:B".
RETURN PARAMETER DESCRIPTION:
Returns:
PXVRSLT(0)=Count of elements returned (0 if nothing found)
PXVRSLT(n)=IEN^Name^HL7 Code^Status (1:Active, 0:Inactive)\n
When filtering based off IEN, HL7 Code, or #.01 field, only one entry will
be returned in PXVRSLT(1).\n
When filtering based off status, multiple entries can be returned. The
first entry will be returned in subscript 1, and subscripts will be
incremented by 1 for further entries. Entries will be sorted
alphabetically.\n
If no entries are found based off the filtering criteria, PXVRSLT(0) will
equal 0, and there will be no data returned in the subsequent subscripts.", "PXVIMM INFO SOURCE", "", "2021/10/21"], ["7292", "PXVIMM VICR EVENTS", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM VICR EVENTS TAG: GETVICR
ROUTINE: PXVRPC5 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns "active" entries from the V IMM CONTRA/REFUSAL EVENTS file
(#9000010.707) that are related to the given patient and immunization.
"Active" is defined as entries where the Event Date and Time is <=
PXDATE@24 and the Warn Until Date is null or>= PXDATE. INPUT PARAMETER: DFN
PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
Pointer to file #2. INPUT PARAMETER: PXVIMM PARAMETER TYPE:
LITERAL
REQUIRED: YES SEQUENCE NUMBER: 2
DESCRIPTION:
Pointer to #9999999.14. INPUT PARAMETER: PXDATE PARAMETER
TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 3
DESCRIPTION:
Used to determine if entry is "active" (Optional; Defaults to TODAY)
Possible values are:
"L": Return a caret-delimited list of entries.
"W": Returns a warning message. INPUT PARAMETER: PXFORMAT
PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 4
DESCRIPTION:
Format that return array should be returned (Optional; Defaults to "L")
Possible values are:
"L": Return a caret-delimited list of entries.
"W": Returns a warning message.
RETURN PARAMETER DESCRIPTION:
PXRSLT(0)=Count of elements returned (0 if nothing found)
If PXFORMAT="L":
PXRSLT(n)="VICR" ^ V IMM Contra/Refusal Events IEN ^ Visit IEN ^
Contra/Refusal variable pointer | Contra/Refusal Name ^
Immunization IEN | Name ^ Warn Until Date ^ D/T Recorded ^
Event D/T ^ Encounter Provider IEN | Name
PXRSLT(n)="COM" ^ Comments
If PXFORMAT["W":
PXRSLT(n)=Warning text", "PXVIMM VICR EVENTS", "", "2021/10/21"], ["7293", "PXVIMM IMM MAN", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM IMM MAN TAG: IMAN
ROUTINE: PXVRPC1 RETURN VALUE TYPE: GLOBAL ARRAY
WORD WRAP ON: TRUE
DESCRIPTION:
This RPC returns information from the IMM MANUFACTURER file
(#9999999.04). INPUT PARAMETER: FILTER PARAMETER TYPE:
LITERAL
MAXIMUM DATA LENGTH: 80 REQUIRED: NO
SEQUENCE NUMBER: 1
DESCRIPTION:
This input parameter is used to specify the IMMUNIZATION LOT file
records to be returned. Possible values:
R:XXX - return entry with ien XXX
M:XXX - return entry with MVX code XXX
N:XXX - return entry with imm manufacturer name XXX
S:A - return list of all active manufacturers
S:I - return list of all inactive manufacturers
S:B - return list of all manufacturers, active and inactive\n
If this parameter is null, it defaults to "S:B". INPUT PARAMETER: PXVDATE
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 7 REQUIRED: NO
SEQUENCE NUMBER: 2
DESCRIPTION:
This optional input parameter is used in determining status. Input
should be in VA FileMan date format. The default value is the current
date. INPUT PARAMETER: PXVI PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 1 REQUIRED: NO
SEQUENCE NUMBER: 3
DESCRIPTION:
This optional input parameter is used to return an alternate array with
record data in a caret delimited string. If this parameter is null or 0,
the return defaults to the other array.
1 - return alternate array with internal values in delimited string
RETURN PARAMETER DESCRIPTION:
Returns with PXVI not equal to 1:
PXVRETRN - returned information is stored in ^TMP("PXVLST",$J))
- return info format: Data Element Name^Data Element Value
- error format: -1^error message\n
For each record returned in the global array, the top value returned will
indicate the record number in the array and the total number of records
returned, e.g., "RECORD^1 OF 3".\n
This RPC returns the internal entry number (IEN) of the record and data
in external format from the following data fields in the IMM
MANUFACTURER file:
- NAME (#.01)
- MVX (#.02)
- INACTIVE FLAG (#.03)
- CDC NOTES (#201)
- STATUS (computed by Data Standardization utility)\n
Example Global Array Returned:
^TMP("PXVLST",$J,"WYETH-AYERST 1",0)="RECORD^1 OF 1"
.001)="IEN^55"
.01)="NAME^WYETH-AYERST"
.02)="MVX CODE^WA"
.03)="INACTIVE FLAG^INACTIVE"
201)="CDC NOTES^became WAL, now owned by
Pfizer"
"STATUS")="STATUS^INACTIVE"\n
Example Global Array Returned if No Records Found:
^TMP("PXVLST",$J,0)="0 RECORDS"\n
Example error messages:
^TMP("PXVLST",$J,0)="-1^Invalid input value"
^TMP("PXVLST",$J,0)="-1^Invalid input for manufacturer IEN"
^TMP("PXVLST",$J,0)="-1^Invalid input for MVX code"
^TMP("PXVLST",$J,0)="-1^Invalid input for manufacturer name"\n
Returns with PXVI equal to 1:
PXVRETRN - returned information is stored in ^TMP("PXVLST",$J))\n
Each record is a caret-delimited list of values. Within the
caret-delimited list, for fields with different internal and external
values, both the internal and external values are included, delimited
by a tilde (~) as indicated below:
Piece# Field# Field Name
------ ------ ----------
1 IEN
2 .01 NAME
3 .02 MVX CODE
4 .03 INACTIVE FLAG (Internal~External)
5 201 CDC NOTES
6 STATUS (computed by Data Standardization utility)", "PXVIMM IMM MAN", "", "2021/10/21"], ["7294", "PXVIMM ADMIN ROUTE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM ADMIN ROUTE TAG: IMMROUTE
ROUTINE: PXVRPC2 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns entries from the IMM ADMINISTRATION ROUTE file (920.2). INPUT
PARAMETER: FILTER PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 1
DESCRIPTION:
Filter. Possible values are:
R:XXX - Return entry with IEN XXX.
H:XXX - Return entry with HL7 Code XXX.
N:XXX - Return entry with #.01 field equal to XXX
S:X - Return all entries with a status of X.
Possible values of X:
A - Active Entries
I - Inactive Entries
B - Both active and inactive entries\n
Defaults to "S:B". INPUT PARAMETER: PXVSITES PARAMETER TYPE:
LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION:
Controls if the available sites for a give route are returned.
RETURN PARAMETER DESCRIPTION:
PXVRSLT(0)=Count of elements returned (0 if nothing found)
PXVRSLT(n)=IEN^Name^HL7 Code^Status (1:Active, 0:Inactive)\n
If PXVSITES=1, the sites for a given route will also be returned.
o If only a subset of sites are selectable for a route, that list will
be returned in:
PXVRSLT(n+1)=SITE^Site IEN 1
PXVRSLT(n+2)=SITE^Site IEN 2
PXVRSLT(n+x)=SITE^Site IEN x
o If all sites are selectable for a route, the RPC will return:
PXVRSLT(n+1)=SITE^ALL
o If no sites are selectable for a route, the RPC will return:
PXVRSLT(n+1)=SITE^NONE
equal 0, and there will be no data returned in the subsequent subscripts.", "PXVIMM ADMIN ROUTE", "", "2021/10/21"], ["7295", "PXVSK DEF SITES", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVSK DEF SITES TAG: SKSITES
ROUTINE: PXVRPC8 RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION
DESCRIPTION:
Returns a list of default administration sites for skin tests.
RETURN PARAMETER DESCRIPTION:
(0)=Count of elements returned (0 if nothing found)
(n)=IEN^NAME", "PXVSK DEF SITES", "", "2021/10/21"], ["7296", "PXVSK SKIN SHORT LIST", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVSK SKIN SHORT LIST TAG: SKSHORT
ROUTINE: PXVRPC8 RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION
DESCRIPTION:
Returns one or more entries from the Skin Test file. INPUT PARAMETER: DATE
PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 1
DESCRIPTION:
Used for determining skin test status. (Defaults to TODAY). INPUT PARAMETER:
FILTER PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION:
Used to filter entries. (Optional; Defaults to "S:A").\n
Possible values are:
R:X - Return entry with IEN X.
N:X - Return entry with #.01 field equal to X
S:A - Return all active entries.
S:I - Return all inactive entries.
S:B - Return all entries (both active and inactive). INPUT PARAMETER:
OREXCLUDE PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 3
DESCRIPTION:
Should entries defined in ORWPCE EXCLUDE SKIN TESTS be excluded? (Used
when PXFLTR is set to S:x). INPUT PARAMETER: LOCATION
PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 4
DESCRIPTION:
Used when excluding entried listed in ORWPCE EXCLUDE SKIN TESTS. This
is the location used when getting the paramater value at the Location
level.
RETURN PARAMETER DESCRIPTION:
(0)=Count of elements returned (0 if nothing found)
(n)=SK^IEN^NAME^PRINT NAME
(n)=CS^Coding System^Code^Variable pointer^Short Description", "PXVSK SKIN SHORT LIST", "", "2021/10/21"], ["7297", "PXVSK V SKIN TEST LIST", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVSK V SKIN TEST LIST TAG: SKLIST
ROUTINE: PXVRPC8 RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION
DESCRIPTION:
Returns a list of V Skin Test entries that have been placed within the
last x days. The number of days to look back is defined in the PXV SK DAYS
BACK parameter. INPUT PARAMETER: DFN PARAMETER TYPE:
LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
Only V Skin Test entries for this patient will be returned. INPUT PARAMETER:
SKINTEST PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION:
Skin Test IEN. If passed in, only V Skin Test entries for this Skin Test
will be returned. If not passed in, all V Skin Tests entries will be
returned. INPUT PARAMETER: DATE PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 3
DESCRIPTION:
The system will search back x number of days from this date. Defaults to
TODAY. INPUT PARAMETER: MAX PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 4
DESCRIPTION:
The max number of entries to return per skin test.
RETURN PARAMETER DESCRIPTION:
(0)=Count of elements returned (0 if nothing found)
(1)=DATERANGE^Start Date^Stop Date
(n)=PLACEMENT^V Skin Test IEN^Skin Test IEN^Skin Test Name^Date/Time of
Placement", "PXVSK V SKIN TEST LIST", "", "2021/10/21"], ["7298", "PXVIMM ADMIN CODES", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "APPROVED", "Active", "Controlled Subscription", "", "\n
NAME: PXVIMM ADMIN CODES TAG:
IMMADMCODES
ROUTINE: PXVRPC4 RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns immunization administration CPT codes. INPUT PARAMETER: VISIT
PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 1 INPUT PARAMETER: PCELIST PARAMETER TYPE:
LIST
REQUIRED: YES SEQUENCE NUMBER: 2 INPUT PARAMETER:
RETCPTDEL PARAMETER TYPE: LITERAL
SEQUENCE NUMBER: 3
RETURN PARAMETER DESCRIPTION:
PXRSLT(n) = Array of CPT codes to add/delete from Visit in format passed
to PX SAVE DATA rpc.", "PXVIMM ADMIN CODES", "", "2021/10/21"], ["7299", "PX ICE WEB", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/09/03", "", "Pending", "Controlled Subscription", "", "\n
NAME: PX ICE WEB TAG: RPC
ROUTINE: PXVWICE RETURN VALUE TYPE: GLOBAL ARRAY
AVAILABILITY: SUBSCRIPTION WORD WRAP ON: TRUE
DESCRIPTION:
Call the ICE web service to get the list of recommended immunizations for
a given patient.
The RPC takes one parameter, the Patient IEN (DFN).
See the RETURN PARAMETER DESCRIPTION for the details on the format of the
returned array.
There must be at least one entry defined in File 920.75, PX ICE WEB
SERVER. If there is more than one entry, then the Site Parameter, PX ICE
WEB DEFAULT SERVER, specifies which entry is to be used. INPUT PARAMETER:
DFN PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
Patient DFN INPUT PARAMETER: CACHE PARAMETER TYPE: LITERAL
REQUIRED: NO SEQUENCE NUMBER: 2
DESCRIPTION:
Use cache? 1=Yes; 0=No (default: 1).
RETURN PARAMETER DESCRIPTION:
If Unsuccessful:
0) = -X^Error Message
Note: -X can be one of the following values:
-1: Invalid input
-2: Could not make SOAP call (e.g., URL not populated in
920.75, etc.)
-3: HTTP call returned unsuccessful status code (i.e.,
Server returned status code other than 200)
-4: Unable to process incoming message from ICE
n) = If SOAP call was unsuccessful, this will be the message returned
by the ICE server.\n
If Successful:
0) = 1 ^ Number of Lines
n) = GRP ^ Vaccine Group Name ^ Group/CVX Code Recommended ^ Group/CVX
Display Name ^ Earliest Recommended Date ^ Overdue Date ^ Recommend
Code ^ Recommend Display Name ^ Doses Remaining
1: GRP
2: Vaccine Group Name - This is the vaccine group for this
recommendation
3: Group/CVX Code Recommended - Vaccine or vaccine group
recommended. If a specific vaccine is recommended, this will
be the CVX code, in the format C:CVX_Code. More commonly, this
will be populated with the vaccine group, in the format
G:Group_Name
4: Group/CVX Display Name - Display Name for CVX/Group in piece
#3.
5: Earliest Recommended Date
6: Overdue Date
7: Recommend Code (currently either RECOMMENDED,
FUTURE_RECOMMENDED, CONDITIONALLY_RECOMMENDED, or
NOT_RECOMMENDED)
8: Recommend Display Name
9: Doses Remaining
n) = RSN ^ Reason Code ^ Reason Display Name
Note: This is the reason(s) for the recommendation above.
1: RSN
2: Reason Code
3: Reason Display Name
n) = HIST ^ V Immunization IEN ^ Immunization Name ^ Administered CVX
Code ^ Admin date/time ^ Dose Number ^ Component CVX Code ^ CVX
Display Name ^ Validity Code ^ Validity Display Name
1: HIST
2: V Immunization IEN (#9000010.11 IEN)
3: Immunization Name (#9999999.14, #.01)
4: Administered CVX Code (#9999999.14, #.03)
5: Admin date/time
6: Dose Number
7: Component CVX Code (for combination vaccines, this can defer
from the CVX administered)
8: CVX Display Name
9: Validity Code
10: Validity Display Name
n) = RSN ^ Reason Code ^ Reason Display Name
Note: This is the reason(s) why the vaccine is valid, invalid or
accepted.
1: RSN
2: Reason Code
3: Reason Display Name", "PX ICE WEB", "", ""], ["7300", "INDIAN SELF IDENTIFICATION CHANGE", "File", "REGISTRATION", "2021/09/16", "APPROVED", "Active", "Private", "2", "
Integrated Billing (IB) requires read-only access to
the following cross-reference in the PATIENT (#2) file. It will be used to
identify any changes in Indian Attestation in order to identify which
Veteran's need to have their accounts reviewed for the possible cancellation
of 1st party copayment charges per their Indian Attestation:\n
AINC REGULAR
Field: INDIAN SELF IDENT CHANGE DT/TM (2,.575)
Description: (Reference ICR#7300)
1)= S ^DPT("AINC",$E(X,1,30),DA)=""
2)= K ^DPT("AINC",$E(X,1,30),DA)", "", "", "2021/12/08"], ["7301", "GMRA EDIT VERIFIED DATA", "Other", "ADVERSE REACTION TRACKING", "2021/09/21", "APPROVED", "Active", "Controlled Subscription", "", "
This ICR covers the use of the GMRA EDIT VERIFIED DATA
extended action protocol, effective with GMRA*4*68. This protocol is triggered
by Adverse Reaction Tracking when a clinical user with the GMRA-ALLERGY VERIFY
key edits a previously verified adverse reaction.", "", "", "2021/09/21"], ["7302", "ENTERED IN ERROR", "", "ORDER ENTRY/RESULTS REPORTING", "", "", "Pending", "", "", "", "", "", ""], ["7303", "LIGHTHOUSE INSURANCE COMPANY ICR", "File", "INTEGRATED BILLING", "2021/10/15", "", "Withdrawn", "Private", "36", "
Lighthouse requires access to the INSURANCE COMPANY
file #36 to support the AMCMS/WellHive Insurance Capture initiative.", "", "", ""], ["7304", "LIGHTHOUSE GROUP INSURANCE PLAN ICR", "File", "INTEGRATED BILLING", "2021/10/15", "", "Withdrawn", "Private", "355.3", "
Lighthouse requires access to the GROUP INSURANCE PLAN
file #355.3 to support the AMCMS/WellHive Insurance Capture initiative.", "", "", ""], ["7305", "LIGHTHOUSE PLAN COVERAGE LIMITATIONS ICR", "File", "INTEGRATED BILLING", "2021/10/15", "", "Withdrawn", "Private", "355.32", "
Lighthouse requires access to the PLAN COVERAGE
LIMITATIONS file #355.32 to support the AMCMS/WellHive Insurance Capture
initiative.", "", "", ""], ["7306", "LIGHTHOUSE PAYER FILE ICR", "File", "INTEGRATED BILLING", "2021/10/15", "", "Withdrawn", "Private", "365.12", "
Lighthouse requires access to the PAYER file #365.12 to
support the AMCMS/WellHive Insurance Capture initiative.", "", "", ""], ["7307", "LIGHTHOUSE PATIENT INSURANCE TYPE SUBFILE ICR", "File", "INTEGRATED BILLING", "2021/10/15", "", "Withdrawn", "Private", "2.312", "
Lighthouse requires access to the Patient Insurance
Type sub-file #2.312 to support the AMCMS/WellHive Insurance Capture
initiative.", "", "", ""], ["7308", "LIGHTHOUSE IIV RESPONSE FILE ICR", "File", "INTEGRATED BILLING", "2021/10/15", "", "Withdrawn", "Private", "365", "
Lighthouse requires access to the IIV RESPONSE file
#365 to support the AMCMS/WellHive Insurance Capture initiative.", "", "", ""], ["7309", "GENERIC CODE SHEET BATCH TYPE LOOKUP", "File", "GENERIC CODE SHEET", "2021/10/19", "APPROVED", "Active", "Private", "2101.1", "
IFCAP wants to use VA FileMan API $$FIND1^DIC() to look
up the FINANCIAL MANAGEMENT BATCH TYPE, look up the RECEIVING USER 'XXX' and
then use $$GET1^DIQ() to get the value of the DOMAIN MAIL ROUTER to ensure
that while testing in mirror/test accounts, FMS transactions are sent to the
test queue Q-FMT.DNS, rather than the production queue Q-FMS.DNS.", "", "", "2021/10/29"], ["7310", "Proxy user for Scheduling/Telehealth", "Routine", "KERNEL", "2021/10/20", "", "Pending", "Controlled Subscription", "200", "
The Scheduling/Telehealth Product Line can establish a
proxy user "VSE,ACHERON". The user will be used by Telehealth Schedulers. The
user will not have access or verify code.", "", "XUSAP", ""], ["7311", "RESULTS MANAGEMENT RULES ENGINE", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2021/11/04", "", "Pending", "Controlled Subscription", "", "
This integration agreement allows the subscriber to
call the Results Management Rules Engine. The engine evaluates data specified
by a set of Clinical Reminders terms and reminder definitions within a rule
and if it determines that a rule is applicable, will execute the action(s)
specified by the rule.", "", "ORJ", ""], ["7312", "REMINDER ORDER CHECK RULE STATUS CHECK", "Routine", "CLINICAL REMINDERS", "2021/11/08", "", "Pending", "Private", "", "
This integration agreement allows the subscribing
package to determine if two reminder definition statuses match. For example,
the statuses "APPLICABLE" and "DUE SOON" match.", "", "PXRMORCH", ""], ["7313", "PSO VCC REFILL", "Remote Procedure", "OUTPATIENT PHARMACY", "2021/11/09", "APPROVED", "Active", "Controlled Subscription", "", "
The purpose of this agreement is to provide Outpatient
Medication Prescription Refill support for client systems such as the Veteran
Contact Center (VCC).\n
The PSO VCC REFILL remote procedure was delivered originally with patch
PSO*7*642, and has been modified, effective with PSO*7*679, to include the
REFILL SOURCE from which the REFILL request originated (e.g., VCC, and VSE).
This modified RPC will support new functionality in Scheduling and Lighthouse
package. CHIP web services will be exposing the refill RPC as an endpoint for
use by the VistA Scheduling Enhancements (VSE) GUI for Clinical Staff. Patch
PSO*7*679 will support that implementation.\n
PSO VCC REFILL remote procedure capture:\n
The RPC: PSO VCC REFILL performs a refill on an outpatient pharmacy order
request. In addition, the RPC will provide the ability in Outpatient Pharmacy
to store the source of a refill request (eg. VCC, Computerized Patient Record
System (CPRS), Outpatient Pharmacy) as well as the person making the request -
if the name is known.\n
OUTPUT: ARRAY
Depending on the value of the Return Flag input parameter, either a single
code is returned or a code and free text description of the code.\n
When the Return Flag input parameter equals 1, then the code and text
description will be returned.
Exception condition when attempting to refill the prescription:
ARRAY(0)=0
ARRAY(1)=error text on why the prescription was not filled The
following is an example of one of several types of exceptions that could be
returned: ARRAY(0)=0
ARRAY(1)=" Cannot
refill Rx # 2769331 Rx is in SUSPENDED status"\n
Successful refill:
ARRAY(0)="1 - Prescription successfully refilled"\n
Data validation error which will be one of the following:
ARRAY(0)="-3 - Missing or Invalid Prescription Number"
ARRAY(0)="-4 - Missing or Invalid Patient ID"
ARRAY(0)="-5 - Prescription Number does not match to the Patient"
ARRAY(0)="-6 - Patient is not assigned an ICN" (note: code -6
will only be generated when the RETURN FLAG is equal 1)\n
When the Return Flag is equal null, then only the code will be returned.
Exception condition when attempting to refill the prescription:
ARRAY(0)=0\n
Successful refill:
ARRAY(0)=1\n
Data Validation error which will be one of the following:
ARRAY(0)=-3
ARRAY(0)=-4
ARRAY(0)=-5\n
INPUT:
DFN [REQUIRED] - Internal Entry Number of the patient record
for the PATIENT file (#2)\n
RX# [REQUIRED] - the external representation of the
prescription number from the PRESCRIPTION
file (#52,.01).\n
USER[OPTIONAL] - USER requesting the refill (free text value)\n
REFILL SOURCE [OPTIONAL] - the source system from which the
REFILL request Originated (e.g., VCC, VSE CS,
AUDIOCARE). If this value is not sent by the
client, the REFILL SOURCE will be reported as
"UNKNOWN".\n
RETURN FLAG [OPTIONAL] - Value will be 1 or null.
If = 1 then the RPC will return the numeric
code with text describing the code.
If = null then the RPC will only return the
numeric code (-5, -4, -3, 0, 1)", "PSO VCC REFILL", "", "2022/07/07"], ["7314", "PSOCLUTL", "Routine", "OUTPATIENT PHARMACY", "2021/11/24", "APPROVED", "Active", "Private", "", "
The Mental Health package needs to call
$$GETREGYS^PSOCLUTL(DFN) to get use frequency from registered cloz auth
number, otherwise most recently assigned cloz number.\n
The Mental Health routine, YSCLTST2, was released in May 2020, effective with
YS*5.01*166. This is an after-the-fact ICR documentation.", "", "PSOCLUTL", "2021/11/26"], ["7315", "PXRPC SAVE2", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2021/12/13", "APPROVED", "Active", "Controlled Subscription", "", "
PXRPC SAVE2 was included in PX*1*217 and distributed
with CPRS v32b. This RPC PXRPC SAVE2 is encouraged to be used instead of PX
SAVE DATA, because it is a more complete solution which includes warnings and
error information.\n
NAME: PXRPC SAVE2 TAG: SAVE2
ROUTINE: PXRPC RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION DESCRIPTION:
This is similar to PX SAVE DATA, except this RPC returns error
information. INPUT PARAMETER: PCELIST PARAMETER TYPE: LIST
MAXIMUM DATA LENGTH: 10000 REQUIRED: YES
SEQUENCE NUMBER: 1 DESCRIPTION:
See PX SAVE DATA. INPUT PARAMETER: PKGNAME PARAMETER TYPE:
LITERAL
MAXIMUM DATA LENGTH: 60 REQUIRED: YES
SEQUENCE NUMBER: 2 DESCRIPTION:
See PX SAVE DATA. INPUT PARAMETER: SRC PARAMETER TYPE:
LITERAL
MAXIMUM DATA LENGTH: 60 REQUIRED: YES
SEQUENCE NUMBER: 3 DESCRIPTION:
See PX SAVE DATA. INPUT PARAMETER: VISIT PARAMETER TYPE:
LITERAL
MAXIMUM DATA LENGTH: 30 REQUIRED: NO
SEQUENCE NUMBER: 4 DESCRIPTION:
See PX SAVE DATA. RETURN PARAMETER DESCRIPTION:
See PX SAVE DATA.", "PXRPC SAVE2", "", "2024/08/30"], ["7316", "DGCN(391.91 - GET EDIPI FOR DFN", "File", "REGISTRATION", "2021/12/16", "", "Withdrawn", "Private", "391.91", "
Treating Facility List where patients have had
treatment.", "", "", ""], ["7317", "ADD ENTRY TO WEB SERVER FILE (#18.12)", "File", "WEB SERVICES CLIENT", "2021/12/16", "APPROVED", "Active", "Private", "", "\n
The Registration VAS team requests read/write access to the WEB
SERVER (#18.12) file to add a new entry during the DG*5.3*964
post-install process. The post-install routine process will create the
new server record entry using UPDATE^DIE and will also create a new entry
to the AUTHORIZED WEB SERVICES (#100) multiple, WEB SERVICE (#.01) field.\n
NOTE: This processing is done programmatically to avoid having sites
manually configure HWSC using the Web Server Manager. This will ensure
all sites have the same configuration installed correctly.
^XOB(18.12,D0
.01 NAME 0;1 Both R/W w/Fileman
.04 SERVER 0;4 Both R/W w/Fileman
.06 STATUS 0;6 Both R/W w/Fileman
.07 DEFAULT HTTP TIMEOUT 0;7 Both R/W w/Fileman
1.01 LOGIN REQUIRED 1;1 Both R/W w/Fileman
3.01 SSL ENABLED 3;1 Both R/W w/Fileman
3.02 SSL CONFIGURATION 3;2 Both R/W w/Fileman
3.03 SSL PORT 3;3 Both R/W w/Fileman
200 USERNAME 200;1 Both R/W w/Fileman
300 PASSWORD 300;1 Both R/W w/Fileman
^XOB(18.12,D0,100,D1
.01 NAME 0;1 Both R/W w/Fileman
.06 STATUS 0;6 Both R/W w/Fileman", "", "", "2022/02/04"], ["7318", "LIGHTHOUSE INSURANCE VERIFICATION PROCESSOR ICR", "File", "INTEGRATED BILLING", "2021/12/23", "", "Withdrawn", "Private", "355.33", "
Lighthouse requires access to the INSURANCE
VERIFICATION PROCESSOR file #355.33 to support the AMCMS/WellHive Insurance
Capture initiative.", "", "", ""], ["7319", "GIVE THIS DBIA A BETTER NAME THAN DBIA7319", "", "", "2022/01/12", "", "Pending", "", "", "", "", "", ""], ["7320", "XOBV TEST UPDATE SECID", "Remote Procedure", "VISTALINK", "2022/01/12", "APPROVED", "Active", "Controlled Subscription", "", "
Allow an external application to pass a NEW PERSON IEN
(file #200) and a secID (file 200, field #205.1) for a given tester to the
VistA test system. When invoked, the RPC will apply the passed secID to the
tester with the IEN that has been passed.\n
REMOTE PROCEDURE NAME: XOBV TEST UPDATE SECID
TAG: CHGSECID ROUTINE: XOBVSECI
RETURN VALUE TYPE: SINGLE VALUE AVAILABILITY: PUBLIC
INACTIVE: ACTIVE
DESCRIPTION:
This RPC allows the SECID for a given tester to be changed.
This will only run in a test account.\n
INPUT PARAMETER: XOBVNPIEN PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 18 REQUIRED: YES
SEQUENCE NUMBER: 1
DESCRIPTION: The IEN of the person in the NEW PERSON (#200) file for
whom the SECID will be changed.\n
INPUT PARAMETER: XOBVSECID PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 30 REQUIRED: YES
SEQUENCE NUMBER: 2
DESCRIPTION: This is the new SECID that will be assigned to the person
specified by the XOBVNPIEN parameter.\n
RETURN PARAMETER DESCRIPTION:
A string:
0_"^"_205 node of ^VA(200,XOBVNPIEN)
- includes fields
- SECID (#205.1) and UNIQUE USER ID (#205.4)
or
-1_"^"_error message\n\n", "XOBV TEST UPDATE SECID", "", "2022/01/27"], ["7321", "PRCA AR SUSPENSION TYPE", "File", "ACCOUNTS RECEIVABLE", "2022/01/13", "", "Pending", "Controlled Subscription", "433.001", "
Allow external packages access to the fields in the AR
SUSPENSION TYPE file, #433.001 for reporting filters in Integrated Billing.", "", "", ""], ["7322", "SD READ ACCESS TO THE REQUEST SERVICES FILE", "File", "CONSULT/REQUEST TRACKING", "2022/01/21", "APPROVED", "Active", "Controlled Subscription", "123.5", "
The Scheduling package needs to access the RELATED
HOSPITAL LOCATION (#123.4) multiple in the REQUEST SERVICES FILE (#123.5) in
order to make an appointment for a community care consult in the correct
clinic.", "", "", "2022/01/24"], ["7323", "VAFCAPI", "Routine", "REGISTRATION", "2022/01/28", "APPROVED", "Active", "Private", "", "
The Master Veteran Index (MVI) team has created this
Application Programming Interface (API) which will allows the adding/updating
or validation of Sexual Orientation (SO) and Gender Identity Traits of a
patient's record in the PATIENT (#2) file.\n
Currently the Sexual Orientation (#.025) field multiple and the Sexual
Orientation Description (#.0251) field in the PATIENT (#2) file can be
added/updated or validated with this API.", "", "VAFCAPI", "2022/02/08"], ["7324", "REQUEST WORKSHEET FILE ACCESS", "File", "IFCAP", "2022/01/31", "APPROVED", "Active", "Controlled Subscription", "443", "
Above PAR requests permission to read from the REQUEST
WORKSHEET FILE #443 to validate the WORKSHEET REQUEST has a VALIDATION CODE
field (#3).\n
Above PAR Ad-Hoc Reporting includes the REQUEST WORKSHEET file #443. Ad-Hoc
functionality provides the ability to select fields from the file for display
on user-defined reports. Ad-Hoc offers only FileMan read access and only if
the user has permission to view the file.", "", "", "2022/02/17"], ["7325", "DUPLICATE INSURANCE CHECK", "Routine", "INTEGRATED BILLING", "2022/02/02", "", "Withdrawn", "Private", "", "
This routine provides a duplicate insurance check that
is used by Lighthouse prior to writing potentially new insurance coverage to
the Insurance Verification Processor file #355.33.", "", "IBLHS1", ""], ["7326", "TESTING READ ONLY", "File", "ORDER ENTRY/RESULTS REPORTING", "2022/02/17", "", "Pending", "Private", "100", "", "", "", ""], ["7327", "COMPACT ACT", "Routine", "PCE PATIENT CARE ENCOUNTER", "2023/12/04", "APPROVED", "Active", "Controlled Subscription", "", "
Patches DG*5.3*1104 and PX*1.0*240 will allow
Registration to make decisions on when to prompt for COMPACT Act clinical
information. For this decision-making process Registration needs to call the
entry point ASC^PXCOMPACT to determine if the patient is currently in an Acute
Suicidal Crisis.\n
Registration also needs to be able to add a new entry to the COMPACT ACT
EPISODE OF CARE file (#818) for a patient and this is allowed by a call made
to the ADMIT^PXCOMPACT entry point.\n
Other displays needed during the registration process are determined by the
entry point DISPLAY^PXCOMPACT.\n
Registration also needs to be able to use the entry point VISIT^PXCOMPACT to
set the Episode of Care (EOC) pointer to the PTF file.\n
If a new EOC needs to be opened or reopened during a patient transfer, or if
an EOC needs to be retracted during editing or deletion of a movement,
Registration needs to determine the appropriate EOC using $$GETEOC^PXCOMPACT
and $$GETEOCSEQ^PXCOMPACT, use SETENDDT to close an open outpatient episode,
and use NEWEOC^PXCOMPACT to create a new episode.\n
During an admission, Registration needs to access $$GETIPDT^PXCOMPACT and
$$GETSTDT^PXCOMPACT to determine benefit start and end dates.\n
Upon a discharge, Registration must use CHGTYPSTAT^PXCOMPACT to change the
COMPACT Act benefit from Inpatient to Outpatient.\n
During a transfer, Registration must call REOPNEOC^PXCOMPACT to reopen an
episode of care for a PTF that is already associated with an episode.\n\n
Revision History
5/7/24 - Removed FILEMANERR component (moved to new routine)
4/25/24 - Removed $$ADMIN Component and hence removed Scheduling package as
subscriber, since Scheduling only used the $$ADMIN component.
7/17/24 - Added $$GETEOC component effective with patches PX*1.0*240 and
DG*5.3*1104
9/24/24 - Added SETENDDT component effective with patches PX*1.0*240 and
DG*5.3*1104
10/22/24 - Added RESET component effective with patches PX*1.0*241 and
DG*5.3*1117", "", "PXCOMPACT", "2024/10/24"], ["7328", "VENDOR UEI VALIDATION", "Routine", "IFCAP", "2022/03/04", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement grants permission to invoke
IFCAP APIs used to validate the GSA SAM UEI (Unique Entity Identifier) field
(#55) in the Vendor file (#440).\n
The UEI is a 12-character field. The 12th character is the check digit.
The UEI cannot contain the letter O or I and cannot begin with digit 0.", "", "PRCHEUI", "2022/08/17"], ["7329", "OUTPATIENT PHARMACY MEDICATION RECONCILIATION", "File", "OUTPATIENT PHARMACY", "2022/03/14", "", "Active", "Controlled Subscription", "52", "
This ICR is to support the medication reconciliation
feature in COMPREHENSIVE CARE COORDINATION. Reading from file 52 will allow
COMPREHENSIVE CARE COORDINATION to display order details for verified
outpatient orders.", "", "", "2022/04/07"], ["7330", "INPATIENT PHARMACY MEDICATION RECONCILIATION", "File", "PHARMACY DATA MANAGEMENT", "2022/03/14", "", "Pending", "Controlled Subscription", "55", "
This ICR supports the medication reconciliation feature
in COMPREHENSIVE CARE COORDINATION. Reading from file 55 will allow
COMPREHENSIVE CARE COORDINATION to display order details for verified Unit
Dose, verified IV medications, and Non-VA medications.", "", "", ""], ["7331", "Setup Rad/Nuc Med HL7 Variable Definition for OE", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2022/03/16", "APPROVED", "Active", "Controlled Subscription", "", "", "", "RAO7UTL", "2022/03/16"], ["7332", "Rad/Nuc Med Order File Entry Creation", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2022/03/16", "APPROVED", "Active", "Controlled Subscription", "", "", "", "RAO7NEW", "2022/03/16"], ["7333", "Rad/Nuc Med Case Number Utility", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2022/03/16", "APPROVED", "Active", "Controlled Subscription", "", "
Function $$CASENUM^RAMAG03D() obtains a case number for
an exam. Usage of this function will allow new exams to be filed upon receipt
of an HL7 message from a commercial image manager for patients on whom imaging
has been performed by an outside community provider without an order having
previously been entered into VistA.", "", "RAMAG03D", "2022/03/16"], ["7334", "OR VIMM MENU", "Other", "ORDER ENTRY/RESULTS REPORTING", "2022/04/01", "APPROVED", "Active", "Private", "", "
The PCE package requests the following options to be
added to the Immunization/Skin Test Data Entry parameters [OR VIMM MENU] menu:\n
Edit Sequence for Immunization Forms [PXV EDIT SEQUENCE]\n
Immunization Default Responses Enter/Edit [PXV EDIT DEFAULT RESPONSES]\n
Edit Skin Test Reading CPT Code [PXV SKIN TEST READING CPT]\n
VIMM functionality crosses multiple namespaces, including the OR and PX
namespaces. This change provides one menu that has all the options a CAC will
need to configure VIMM, instead of having to go to multiple places.\n
The PCE options will be added to the OR VIMM MENU during the OR*3*405 post
installation processing.", "", "", "2022/04/12"], ["7335", "OR INDICATION USAGE REPORT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/04/18", "APPROVED", "Active", "Private", "", "
Pharmacy Data Management (PDM) requests to make a call
to EN^ORINDRP that generates Indication Usage Report. This report is mostly
used by Pharmacists to manage the use of Indications by the provder. A new
option, Indication Usage Report [PSS INDICATION USAGE REPORT] will provide the
Pharmacists the option of generating the Indication Usage Report in the PSS
namespace.", "", "ORINDRP", "2022/04/21"], ["7336", "EHRM IO Order Resubmission - GMRCIEVT", "Routine", "CONSULT/REQUEST TRACKING", "2022/04/21", "", "Withdrawn", "Private", "", "", "", "GMRCIEVT", ""], ["7337", "EHRM IO Order Resubmission - file #123", "File", "CONSULT/REQUEST TRACKING", "2022/04/21", "", "Withdrawn", "Private", "123", "", "", "", ""], ["7338", "Radiology/Nuclear Medicine Report Completion Utility", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2022/04/28", "", "Active", "Controlled Subscription", "", "
Function $$COMPLETE^RAMAG06() files report information
onto a Radiology / Nuclear Medicine examination record and sets the exam
status to Complete. Usage of this function will allow new exams to be filed
upon receipt of an HL7 message from a commercial image manager for patients on
whom imaging has been performed by an outside community provider without an
order having previously been entered into VistA.", "", "RAMAG06", ""], ["7339", "LRAPDLG", "Routine", "LAB SERVICE", "2022/05/16", "APPROVED", "Active", "Private", "", "
The Order Entry/Results Reporting package desires to
set up an integration agreement with the Lab Service package to utilize APIs
related to Anatomic Pathology (AP) Order Dialogs.", "", "LRAPDLG", "2022/05/16"], ["7340", "SDESUTIL", "File", "EVENT CAPTURE", "2022/07/01", "APPROVED", "Active", "Controlled Subscription", "728.44", "
The Scheduling package requests permission to look at
the CLINICS AND STOP CODES (#728.44) file to get the NATIONAL CODE (#7) field.\n
The $$CHAR4 function was deployed in Scheduling routine, SDESUTIL, with patch
SD*5.3*820 and will utilize FileMan calls to retrieve the external value of
the NATIONAL CODE (#7) field.\n
COMPONENT: $$CHAR4
Utility to return the external format of the NATIONAL CODE (#7)
field from the CLINICS AND STOP CODES (#728.44) file.\n
Variables: Input NAME (#.01) field from the HOSPITAL LOCATION (#44) file.\n
Variables: Output NATIONAL CODE (#7) field from the CLINICS AND STOP
CODES (#728.44) file in external format.", "", "", "2022/07/21"], ["7341", "PMI WORKLISTS - EQUIPMENT NOTES", "Routine", "ENGINEERING", "2022/07/05", "APPROVED", "Active", "Private", "", "
Above Par requests permission to call NOTES^ENWOD2 to
check an Equipment entry's flag situations for display on the PMI Worksheet
print.\n
Returns ENX array and the Number of lines returned.", "", "ENWOD2", "2022/07/11"], ["7342", "CCRA READ ACCESS TO THE REQUEST CONSULTATION FILE", "File", "CONSULT/REQUEST TRACKING", "2022/07/19", "APPROVED", "Active", "Private", "123", "
The Community Care Referrals and Authorization (CCRA)
project wants to use a FileMan read to the FROM Field (2) in the REQUEST
CONSULTATION FILE (#123). This location will be used to link a CCRA Text
Integration Utility (TIU) Note's location to the visit location.", "", "", "2022/07/21"], ["7343", "PSJSTSTP", "Routine", "INPATIENT MEDICATIONS", "2022/07/20", "APPROVED", "Active", "Private", "", "
INPATIENT MEDICATIONS application provides two APIs
implemented in PSJSTSTP routine:\n
STRSTP - calculate standard start date/time, duration, expected first dose,
stop date/time and to provide information in regards to overriding the stop
dates by providers if this was set for the orderable item on the system (site)
level. Data returned by this API is used for purposes of editing quick orders
and using them in CPRS.\n
LIMITS - return system (site) level default 'DAY (nD) or DOSE (nL) LIMIT'
value of the orderable item in the PHARMACY ORDERABLE ITEM FILE #50.7.", "", "PSJSTSTP", "2022/08/01"], ["7344", "EXCLUDE ONETIME SCHEDULE PARAMETERS", "Other", "PHARMACY DATA MANAGEMENT", "2022/07/20", "APPROVED", "Active", "Private", "", "
Provide read-only access to the 'PSS EXCLUDE 1TIME
STRSTP MODS' parameter entries in the PARAMETER file (#8989.5).", "", "", "2022/07/29"], ["7345", "Calls to PSJHLU - use 2945 instead", "Routine", "INPATIENT MEDICATIONS", "2022/07/22", "", "Withdrawn", "Controlled Subscription", "", "
*The Inpatient Medications developer requested this ICR
be withdrawn, and use 2945 instead*\n
This DBIA documents calls to PSJHLU.", "", "PSJHLU", ""], ["7346", "VAFCCRNR", "Routine", "REGISTRATION", "2022/07/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "VAFCCRNR", "2022/11/03"], ["7347", "PSSEXLST", "Routine", "PHARMACY DATA MANAGEMENT", "2022/07/25", "APPROVED", "Active", "Private", "", "
API to check if the ONE-TIME prescription admin
schedule is excluded from start/stop dates modifications.", "", "PSSEXLST", "2022/08/30"], ["7348", "SDTMPUTL", "File", "EVENT CAPTURE", "2022/08/04", "APPROVED", "Active", "Controlled Subscription", "728.441", "
The Scheduling package requests permission to look at
the NATIONAL CLINIC FILE (#728.441) file to get the SHORT DESCRIPTION (#1)
field.\n
The $$CHAR4DSC function was deployed in Telehealth Management Platform (TMP)
Scheduling routine, SDTMPUTL, with patch SD*5.3*821 and will utilize FileMan
calls to retrieve the external value of the SHORT DESCRIPTION (#1) field.", "", "SDTMPUTL", "2022/08/16"], ["7349", "ORQOUTL", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/08/16", "APPROVED", "Active", "Controlled Subscription", "101.41", "
The original API was released with CPRS 31B and
modified a little bit in 32B for real time utilities that are using it. The
31B and 32B structures are as follows:\n
FINDQO(RESULT,INPUT,SUB,RETMENU,RETSTRCT) 31B version of the code
FINDQO(RESULT,INPUT,SUB,RETMENU,RETSTRCT,SPINNER,SKIPDIS) 32B version of the
code.", "", "ORQOUTL", "2022/08/26"], ["7350", "DG TEMPORARY ADDRESS UPDATE", "Routine", "REGISTRATION", "2022/08/18", "", "Pending", "Supported", "", "
Use API $$UPD^DGENDBS to update the following temporary
address fields ln the PATIENT (#2) file.\n
TEMPORARY STREET [LINE 1] (#.1211) TEMPORARY STREET [LINE 2] (#.1212)
TEMPORARY STREET [LINE 3] (#.1213) TEMPORARY CITY (#.1214)
TEMPORARY STATE (#.1215) TEMPORARY ZIP CODE (#.1216)
TEMPORARY ADDRESS START DATE (#.1217) TEMPORARY ADDRESS END DATE (#.1218)
TEMPORARY ADDRESS ACTIVE? (#.12105) TEMPORARY ZIP+4 (#.12112)
TEMPORARY ADDRESS COUNTY (#.12111) TEMPORARY ADDRESS PROVINCE (#.1221)
TEMPORARY ADDRESS POSTAL CODE (#.1222) TEMPORARY ADDRESS COUNTRY (#.1223)\n\n", "", "DGENDBS", ""], ["7351", "PSXRPPL1", "Routine", "CMOP", "2022/08/24", "APPROVED", "Active", "Controlled Subscription", "", "
The MCCF EDI TAS project needs to access the $$TRICVANB
component in PSXRPPL1, effective with PSO*7.0*681.", "", "PSXRPPL1", "2022/09/28"], ["7352", "PSXRPPL2", "Routine", "CMOP", "2022/08/24", "APPROVED", "Active", "Controlled Subscription", "", "
The MCCF EDI TAS project needs to access the $$ECETREJ
component in PSXRPPL2, effective with PSO*7.0*681.", "", "PSXRPPL2", "2022/09/28"], ["7353", "GET MAGNITUDE AND UCUM CODE FOR ENTRY", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/08/29", "", "Pending", "Private", "", "
Provide a way to return if a record for a file contains
a possible magnitude range and ucum code.", "", "ORWPCE5", ""], ["7354", "DG PTF ICD PROCEDURE NOTIFIER", "Other", "REGISTRATION", "2022/08/31", "APPROVED", "Active", "Controlled Subscription", "", "
The DG PTF ICD PROCEDURE NOTIFIER protocol notifies
subscribers when an International Classification of Diseases (ICD) procedure
code is added, modified or removed for entries within the PTF file (#45).\n
The following data is available to subscribers:\n
^TMP("DG PTF ICD OP NOTIFIER",$J,"DATE")=DATE
DATE: FileMan date/time (internal format) of when the activity occurred.\n
^TMP("DG PTF ICD OP NOTIFIER",$J,"DFN")=DFN
DFN: internal entry number of the patient in the PATIENT file (#2).\n
^TMP("DG PTF ICD OP NOTIFIER",$J,TYPE,"IENS")=IENS
TYPE: The activity type; possible values are "DISCHARGE", "PROCEDURE",
and "SURGERY". "DISCHARGE" codes are from the PROCEDURE series of
fields on the 401P node in the PTF (#45) file.
"PROCEDURE" codes are from the PROCEDURE CODE series of fields
in the 601 sub-file (#45.05) of the PTF file (#45). "SURGERY" codes
are from the OPERATION CODE series of fields in the 401 sub-file
(#45.01) of the PTF (#45) file.
IENS: The internal entry number string identifying the record in which
the associated codes are stored.\n
^TMP("DG PTF ICD OP NOTIFIER",$J,TYPE,FIELD,"OLD")=ICDP
This is how the field appeared in the file before the change was made.
FIELD: This is an abbreviation denoting which field the code came from.
The following table should assist in determining which field a
code came from:
TYPE FIELD Field Name
-----------------------------------------------------
DISCHARGE OPCnn PROCEDURE nn (nn is a whole number)
PROCEDURE OPCnn PROCEDURE CODE nn (nn is a whole number)
SURGERY OPCnn OPERATION CODE nn (nn is a whole number)
ICDP: Internal entry number of the procedure code in the ICD OPERATION/
PROCEDURE file (#80.1).\n
^TMP("DG PTF ICD OP NOTIFIER",$J,TYPE,FIELD,"NEW")=ICDP
This is how the field appeared in the file after the change was made.\n
When a code is added, the "OLD" value will be blank and the "NEW" value will
not be. When a code is deleted, the "OLD" value will not be blank and the
"NEW" value will be. When a code is changed, both the "OLD" and "NEW" values
will not be blank.", "", "", "2022/08/31"], ["7355", "CLINICAL REMINDERS INPUT TRANSFORMS", "Routine", "CLINICAL REMINDERS", "2022/09/02", "", "Pending", "Private", "", "
This integration agreement allows the subscribing
package to validate that data entered by the user conforms to Clinical
Reminders standards and formats.", "", "PXRMINTR", ""], ["7356", "ORACCESS API", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/09/14", "APPROVED", "Active", "Private", "", "
ICR 7356 was created to grant access to TIU and PXRM to
be able to get information regarding whether or not a site was converted to a
new EHRM, effective with patches OR*3*588, TIU*1*353, PXRM*2*82.", "", "ORACCESS", "2023/03/23"], ["7357", "TIU CALLS TO ISCLORD API", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/09/20", "APPROVED", "Active", "Private", "", "
TIU is calling $$ISCLORD^ORUTL when building the list
of patient medications for the TIU medication objects. The call determines if
a given medication is a "clinic order". Clinic orders are in the CLINIC
MEDICATIONS or CLINIC INFUSIONS display groups.", "", "ORUTL", "2022/09/20"], ["7358", "TIU FILEMAN READ ACCESS TO THE REQUEST/CONSULTATION FILE", "File", "CONSULT/REQUEST TRACKING", "2022/10/12", "", "Pending", "Controlled Subscription", "123", "
The Community Care Referrals and Authorization (CCRA)
project wants to use a FileMan read to the CPRS STATUS field (#8) in the
REQUEST/CONSULTATION FILE (#123). This field is used to reset the status to
it's original state once a CCRA note is filed with the consult.", "", "", ""], ["7359", "CLINICAL REMINDERS PATIENT LIST HELP TEXT", "Routine", "CLINICAL REMINDERS", "2022/10/17", "", "Pending", "Private", "", "
This integration agreement allows the subscribing
package to display the help text that Clinical Reminders displays when
requested by the user while building a patient list.", "", "PXRMLCR", ""], ["7360", "CERNER CERT and MOCK API", "Routine", "REGISTRATION", "2022/10/27", "APPROVED", "Active", "Controlled Subscription", "", "
Two new APIs were created, by the MPI Team, to support
multiple CERNER / HealthShare Enterprise Platform (HSEP) CERT and MOCK
accounts that require multiple station numbers to exist in the Software
Quality Assurance (SQA) environment. Patch XWB*1.1*75 and OR*3.0*587 will
require access to these APIs to appropriately determine to which Cerner domain
the current VistA instance is connected.", "", "VAFCCRNR", "2022/10/31"], ["7361", "MHV VistA Service account using SSOi SAML token", "Other", "KERNEL", "2022/11/02", "APPROVED", "Active", "Private", "", "
This ICR is to document the agreement for MHV to use a
VistA Service account (NPE - Non Person Entity) using SSOi SAML token until
MHV can transition to the SSOe implementation in VistA.\n
Background MHV needs to migrate from VIA to VDIF, due to VIA being
decommissioned in fall 2022.\n
The VistA Infrastructure Shared Services (VISS) team, MHV package, and VistA
Office Review Board have established steps to accomplish the migration:\n
1) Migrate MHV from VIA to VDIF: The goal is to safely tranition from VIA to
VDIF in a timely manner. To accomplish ths, MHV will temporarily use a VistA
Service account (NPE) using a SSOi SAML token.\n
2) VISS Implement VisA SSOe: The VISS team will enhance the SSOe
implementation in VistA to support secure patient login.\n
3)MHV Activates the SSOe: MHV Team will switch from the temporary VistA
service account to the SSOe implementation in VistA.\n
4) VISS Deactivates the temporary VistA service account.", "", "", "2022/12/01"], ["7362", "SDEC ARCLOSE", "Remote Procedure", "SCHEDULING", "2022/11/15", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC is due to be deprecated in April of 2023. All
consumers will need to transition to the appropriate Enterprise Appointment
Service (EAS) web service to replace this functionality by that time\n
Remove a Patient from the Appointment Requested by setting the STATUS to
CLOSED and updating the DISPOSITION fields.", "SDEC ARCLOSE", "", "2022/12/19"], ["7363", "SDEC APPTYPES", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "\n
Return all active Appointment types from the APPOINTMENT TYPE file 409.1
RETURN PARAMETER DESCRIPTION:
Dataset with columns APPTTYPE_IEN and APPTTYPE_NAME\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC APPTYPES", "", "2022/11/23"], ["7364", "SDEC ARGET", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC retrieves appointment requests.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC ARGET", "", "2022/12/09"], ["7365", "SDEC AROPEN", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC is to re-open an appointment request.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC AROPEN", "", "2022/12/09"], ["7366", "SDEC ARSET", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC is to add a new appointment request or update
an appointment request.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC ARSET", "", "2022/12/09"], ["7367", "SDEC CANCMT", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC Returns list of cancellation comments (hash
tag, type and text) from the SDEC CANCELLATION COMMENT file (#409.88).\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC CANCMT", "", "2022/12/09"], ["7368", "SDEC CANREAS", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC return entries from the CANCELLATION REASONS
file.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC CANREAS", "", "2022/12/09"], ["7369", "SDEC CLINSET", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC Returns CLINIC SETUP PARAMETERS for clinics
that are active in the HOSPITAL LOCATION file.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "", "", "2022/12/09"], ["7370", "SDEC CSLOTSCH", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC retrieves Assigned Appointment Slot Schedule
for a resource.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC CSLOTSCH", "", "2022/12/14"], ["7371", "SDEC EDITAPPT", "Remote Procedure", "SCHEDULING", "2022/11/17", "", "Under Revision", "Controlled Subscription", "", "
This RPC will Edit an appointment (only 'note text' and
appointment length can be edited)\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC EDITAPPT", "", "2022/12/09"], ["7372", "SDEC EP EVENT LOG", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC Provides Scheduling Expanded Entry Appointment
Event Log to VSE for displaying in the GUI the VS Gui.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC EP EVENT LOG", "", "2022/12/09"], ["7373", "SDEC GETPRER", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC RETURNS ALL ENTRIES IN THE PREREQUISITE
MULTIPLE FROM THE SDEC APPT REQUEST FILE\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC GETPRER", "", "2022/12/09"], ["7374", "SDEC NEWPERS", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC return entries from the NEW PERSON table 200
that are 'active' AND have PROVIDER CLASS defined.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC NEWPERS", "", "2022/12/09"], ["7375", "SDEC PCSTGET", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC GET patient clinic status for a clinic stop
for a given time frame - has the patient been seen by the given Clinic Stop
code in the past 24 months\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC PCSTGET", "", "2022/12/09"], ["7376", "SDEC REP1GET", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC will GET clinic data for report.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC REP1GET", "", "2022/12/09"], ["7377", "SDEC RESCE", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC Returns all active Clinics/Scheduling
resources\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC RESCE", "", "2022/12/09"], ["7378", "SDEC RESOURCE", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC Returns Recordset with ALL RESOURCE names.
Inactive RESOURCES are NOT filtered out.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC RESOURCE", "", "2022/12/09"], ["7379", "SDEC RESGPUSR", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
PC Returns ADO Recordset with all ACTIVE GROUP/RESOURCE
combinations to which user has access based on entries in SDEC RESOURCE USER
file If SDECDUZ=0 then returns all ACTIVE GROUP/RESOURCE combinations for
current DUZ If user SDECDUZ possesses the key SDECZMGR then ALL ACTIVE
resource group names are returned.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC RESGPUSR", "", ""], ["7380", "SDEC VVC_APPT", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
If an appointment is for a VVC clinic, return the URL
of the VVC Web app. The NATIONAL entry in the SDEC Settings file (#409.98)
stores the stop code that identifies a VVC clinic in field #5 (VVC Clinic Stop
Code). If the stop code for the clinic associated with the resource scheduled
for the appointment equals this stop code, the RPC returns the value in field
#6 VVC APP URL of the NATIONAL entry in the SDEC Settings file.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC VVC_APPT", "", "2022/12/09"], ["7381", "SDEC VVS DELETE ID", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC deletes the Video Visit ID from the SDEC
APPOINTMENT (#409.84) file.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC VVS DELETE ID", "", "2022/12/09"], ["7382", "SDEC VVS GET ID", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC returns the Video Visit Service (VVS) ID.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC VVS GET ID", "", "2022/12/09"], ["7383", "SDEC VVS SAVE ID", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC saves the VVS appointment ID in the SDEC
APPOINTMENT (#409.84), field (#2).\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC VVS SAVE ID", "", "2022/12/09"], ["7384", "SDECLK LOCK", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC attempts to lock a request record. Request
records are in one of these files:
SDEC APPT REQUEST
REQUEST/CONSULTATION
SD WAIT LIST
RECALL REMINDERS\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDECLK LOCK", "", "2022/12/09"], ["7385", "SDECLK UNLOCK", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC unlocks the request record that was locked
using SDECLK LOCK.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDECLK UNLOCK", "", "2022/12/09"], ["7386", "SDEC57 OBM", "Remote Procedure", "SCHEDULING", "2022/11/17", "APPROVED", "Active", "Controlled Subscription", "", "
This RPC will GET overbook status and return message.\n
This RPC is due to be deprecated in April of 2023. All consumers will need to
transition to the appropriate Enterprise Appointment Service (EAS) web service
to replace this functionality by that time.", "SDEC57 OBM", "", "2022/12/09"], ["7387", "WORLD TIMEZONES FILE", "File", "1", "2022/12/07", "APPROVED", "Active", "Supported", "1.71", "
All fields in the WORLD TIMEZONES file (#1.71) are
available for read access using VA FileMan.", "", "", "2022/12/07"], ["7388", "API for ORPARAM OVER DATELINE", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/12/09", "APPROVED", "Active", "Controlled Subscription", "", "
PX*1*233 needs access to OVERDL^ORWU", "", "ORWU", "2022/12/14"], ["7389", "ORIMO IMOOD", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/12/14", "APPROVED", "Active", "Controlled Subscription", "", "
This call will return a 1 if the CPRS order is a Clinic
Order (formerly referred to as Inpatient Medication Orders for Outpatient),
IMO for short.", "", "ORIMO", "2022/12/15"], ["7390", "PXRMFLST", "Routine", "CLINICAL REMINDERS", "2022/12/15", "APPROVED", "Active", "Private", "", "
The routine ORVIMM makes a call to DEF^PXRMFLST to look
for information on the Findings multiple from the Clinical Reminders file. The
called routine was released to the field in a patch prior to Patch OR*3.0*561.
This is an "after the fact" clean-up of missing ICR documentation in routines.\n", "", "PXRMFLST", "2022/12/29"], ["7391", "PXRMLDR", "Routine", "CLINICAL REMINDERS", "2022/12/15", "APPROVED", "Active", "Private", "", "
The routine ORVIMM makes a call to DEF^PXRMLDR to look
for information on the Findings multiple from the Clinical Reminders file. The
called routine was released to the field in a patch prior to Patch OR*3.0*561.
This is an "after the fact" clean-up of missing ICR documentation in routines.\n", "", "PXRMLDR", "2023/01/03"], ["7392", "ORWPS COVER", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/12/16", "APPROVED", "Active", "Controlled Subscription", "", "
Returns a list of medications for a patient to display
on the CPRS Health Summary, Essential Medication List for Review report.", "", "ORWPS", "2022/12/20"], ["7393", "PXAPI", "Routine", "CLINICAL REMINDERS", "2022/12/18", "APPROVED", "Active", "Private", "", "
The routine ORWPCE5 makes a call to GMPARAMS^PXAPI to
look for information on Measurement parameters from the EDUCATION TOPICS FILE
or the EXAM FILE or the HEALTH FACTORS FILE. The called routine was released
to the field in a patch prior to Patch OR*3.0*561. This is an "after the fact"
clean-up of missing ICR documentation in routines.", "", "PXAPI", "2023/01/10"], ["7394", "PXRMTAXI", "Routine", "CLINICAL REMINDERS", "2022/12/18", "APPROVED", "Active", "Private", "", "
The routine ORWPCE5 makes a call to TAXLIST^PXRMTAXI to
look for information on all the defined Taxonomies from the REMINDER TAXONOMY
FILE. The called routine was released to the field in a patch prior to Patch
OR*3.0*561. This is an "after the fact" clean-up of missing ICR documentation
in routines.\n
The routine ORWPCE5 makes a call to CODELIST^PXRMTAXI to look for information
on the codes related to a Taxonomy from the REMINDER TAXONOMY FILE. The called
routine was released to the field in a patch prior to Patch OR*3.0*561. This
is an "after the fact" clean-up of missing ICR documentation in routines\n", "", "PXRMTAXI", "2023/01/10"], ["7395", "PXRMDTAX", "Routine", "CLINICAL REMINDERS", "2022/12/18", "APPROVED", "Active", "Private", "", "
The routine ORWPCE5 makes a call to GMPARAMS^PXRMDTAX
to look for information on the codes related to a Taxonomy from the REMINDER
TAXONOMY FILE. The called routine was released to the field in a patch prior
to Patch OR*3.0*561. This is an "after the fact" clean-up of missing ICR
documentation in routines.", "", "PXRMDTAX", "2022/12/29"], ["7396", "PXRMTXCS", "Routine", "CLINICAL REMINDERS", "2022/12/19", "APPROVED", "Active", "Private", "", "
The routine ORWPCE5 makes a call to UIDSEARCH^PXRMTXCS
to look for information on all Taxonomies that have a coding system code pair
marked as UID and return all the active, on the encounter date, UID codes from
that coding system that are marked as UID in those Taxonomies from the
REMINDER TAXONOMY FILE. The called routine was released to the field in a
patch prior to Patch OR*3.0*561. This is an "after the fact" clean-up of
missing ICR documentation in routines.", "", "PXRMTXCS", "2023/01/10"], ["7397", "CPRS UPDATE MENU TEXT", "File", "KERNEL", "2022/12/20", "APPROVED", "Active", "Private", "19", "
The Computerized Patient Record System (CPRS)
application needs to be able to update the server version number information
during patch post installation. There are times when CPRS prefers to not
export the entire menu option but rather to only update the version number.\n
The purpose of this ICR is to grant CPRS the ability to use FileMan to update
that version number.", "", "", "2022/12/20"], ["7398", "PXVUTIL", "Routine", "PCE PATIENT CARE ENCOUNTER", "2022/12/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXVUTIL", "2022/12/23"], ["7399", "ORWPCE2", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2022/12/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "ORWPCE2", "2022/12/27"], ["7400", "GIVE THIS DBIA A BETTER NAME THAN DBIA7400", "", "", "2023/01/03", "", "Pending", "", "", "", "", "", ""], ["7401", "DBS RAERR FUNCTION", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2023/01/03", "APPROVED", "Active", "Private", "", "
ISI IMAGING provides a Report Entry function within the
ISI Rad radiology workstation client application. When the case of interest
is selected, Fileman calls are used for fetching exam and report details for
display in the application; the $$DBS^RAERR function is used to check for
errors after the calls are made.", "", "RAERR", "2023/01/10"], ["7402", "EXAM LOCK CHECK", "Routine", "ISI IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "", "
The ISI Rad Client application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging Server software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI Server software uses many of the same subroutines and files in the
same manner as VistARad; session initialization; fetching exam info and image
info; exam locking; exam list data management; etc.\n
ISI Rad ISI*1.1*110 provides a Report Entry Function within the ISI Rad
radiology workstation client application. When the case of interest is
selected, the program must determine the current lock status of the exam to
allow or deny access to report updating by the current user.\n
Revision: Added 11/16/23: This ICR was originally set-up for ISI IMAGING to be
a subscriber to an IMAGING Routine. MAGJ is now excluded from the IMAGING
package and has been added to the ISI IMAGING package as an additional prefix.
As a result ISI IMAGING is both the Custodian and Subscriber. Though this ICR
is no longer needed, the decision was made to leave the ICR in place for
historical purposes.", "", "MAGJLS2B", "2023/03/03"], ["7403", "SAVE EXAM LIST DATA", "Routine", "ISI IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "", "
The ISI Rad Client application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging Server software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI Server software uses many of the same subroutines and files in the
same manner as VistARad; session initialization; fetching exam info and image
info; exam locking, exam list data management; etc.\n
ISI Rad ISI*1.1*110 provides exams list functions within the ISI Rad radiology
workstation client application--Favorites exams, and a dynamic query exams
list. When compiling these lists, this subroutine call is used to save output
data.\n
Revision: Added 11/16/23: This ICR was originally set-up for ISI IMAGING to be
a subscriber to an IMAGING Routine. MAGJ is now excluded from the IMAGING
package and has been added to the ISI IMAGING package as an additional prefix.
As a result ISI IMAGING is both the Custodian and Subscriber. Though this ICR
is no longer needed, the decision was made to leave the ICR in place for
historical purposes.", "", "MAGJLS3", "2023/03/08"], ["7404", "GET EXAM DATA", "Routine", "ISI IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "", "
The ISI Rad CLIENT application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging SERVER software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI SERVER software uses many of the same subroutines and files in the
same manner as VistARad: session initialization; fetching Exam info and Image
info; Exam Locking; Exam List data management; etc.\n
ISI Rad ISI*1.1*110 provides features including Report Entry, Notes entry, and
Exams List functions within the ISI Rad radiology workstation client
application. Whenever an exam of interest is being processed for any of these
functions, this subroutine is called to retrieve all data required to perform
said function.\n
Revision: Added 11/16/23: This ICR was originally set-up for ISI IMAGING to be
a subscriber to an IMAGING Routine. MAGJ is now excluded from the IMAGING
package and has been added to the ISI IMAGING package as an additional prefix.
As a result ISI IMAGING is both the Custodian and Subscriber. Though this ICR
is no longer needed, the decision was made to leave the ICR in place for
historical purposes.", "", "MAGJUTL1", "2023/03/07"], ["7405", "IMAGE INFORMATION", "Routine", "ISI IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "", "
The ISI Rad CLIENT application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging SERVER software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI SERVER software uses many of the same subroutines and files in the
same manner as VistARad: session initialization; fetching Exam info and Image
info; Exam Locking; Exam List data management; etc.\n
ISI Rad ISI*1.1*110 provides a Favorites exams list function within the ISI
Rad radiology workstation client application. When compiling the lists for
output, this subroutine is called to fetch # of images for the exam, and the
Date/Time of Image capture for displaying in the list.\n
Revision: Added 11/16/23: This ICR was originally set-up for ISI IMAGING to be
a subscriber to an IMAGING Routine. MAGJ is now excluded from the IMAGING
package and has been added to the ISI IMAGING package as an additional prefix.
As a result ISI IMAGING is both the Custodian and Subscriber. Though this ICR
is no longer needed, the decision was made to leave the ICR in place for
historical purposes.", "", "MAGJUTL2", "2023/03/03"], ["7406", "INITIALIZE MAGJOB ARRAY", "Routine", "ISI IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "", "
The ISI Rad CLIENT application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging SERVER software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI SERVER software uses many of the same subroutines and files in the
same manner as VistARad: session initialization; fetching Exam info and Image
info; Exam Locking; Exam List data management; etc.\n
ISI Rad ISI*1.1*110 provides a feature for Notes entry and display within the
ISI Rad radiology workstation client application; the Notes display is
implemented as a subroutine call within the Display radiology Report or
Requisition functions. These functions may be called by other Imaging
applications (i.e., not VistARad nor ISI Rad). If a non-ISI Rad application
calls Display radiology Report or Requisition, the program must initialize the
MAGJOB array.\n
Revision: Added 11/16/23: This ICR was originally set-up for ISI IMAGING to be
a subscriber to an IMAGING Routine. MAGJ is now excluded from the IMAGING
package and has been added to the ISI IMAGING package as an additional prefix.
As a result ISI IMAGING is both the Custodian and Subscriber. Though this ICR
is no longer needed, the decision was made to leave the ICR in place for
historical purposes.", "", "MAGJUTL3", "2023/03/07"], ["7407", "GET PRINTSET STATUS", "Routine", "ISI IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "", "
The ISI Rad CLIENT application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging SERVER software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI SERVER software uses many of the same subroutines and files in the
same manner as VistARad: session initialization; fetching Exam info and Image
info; Exam Locking; Exam List data management; etc.\n\n
ISI IMAGING ISI*1.1*110 provides a Report Entry function within the ISI Rad
radiology workstation client application. When the case of interest is
selected, the program must retrieve the correct Accession number to use for
the exam, resolved per the PRINTSET status, with the associated accession
numbers per the PRINTSET status, so that the report entry session processes
correctly for all related exams.\n
Revision: Added 11/16/23: This ICR was originally set-up for ISI IMAGING to be
a subscriber to an IMAGING Routine. MAGJ is now excluded from the IMAGING
package and has been added to the ISI IMAGING package as an additional prefix.
As a result ISI IMAGING is both the Custodian and Subscriber. Though this ICR
is no longer needed, the decision was made to leave the ICR in place for
historical purposes.", "", "MAGJUTL6", "2023/03/07"], ["7408", "MAG RAD LIST DATA ELEMENTS (#2006.63)", "File", "IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "2006.63", "
The ISI Rad CLIENT application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging SERVER software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI SERVER software uses many of the same subroutines and files in the
same manner as VistARad: session initialization; fetching Exam info and Image
info; Exam Locking; Exam List data management; etc.\n
VistA Imaging gives permission to ISI Rad to read and update file MAG RAD LIST
DATA ELEMENTS (#2006.63), which contains data necessary for the exam list
subsystem used by VistARad.", "", "", "2023/03/07"], ["7409", "MAG RAD LISTS DEFINITION (#2006.631)", "File", "IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "2006.631", "
The ISI Rad CLIENT application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging SERVER software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI SERVER software uses many of the same subroutines and files in the
same manner as VistARad: session initialization; fetching Exam info and Image
info; Exam Locking; Exam List data management; etc.\n
VistA Imaging gives permission to ISI Imaging to read and update file MAG RAD
LISTS DEFINITION (#2006.631), which contains Exams List specification data for
the exam list subsystem used by VistARad.", "", "", "2023/03/07"], ["7410", "MAG VISTARAD SITE PARAMETERS (#2006.69)", "File", "IMAGING", "2023/01/05", "APPROVED", "Active", "Private", "2006.69", "
The ISI Rad CLIENT application is a plug-in replacement
for VistA Imaging's VistARad client. ISI Rad uses all of the existing VistA
Imaging SERVER software (RPC calls, routines, files, etc.) in the same way as
VistARad. In some cases, to support new features that VistARad does not have,
new ISI SERVER software uses many of the same subroutines and files in the
same manner as VistARad: session initialization; fetching Exam info and Image
info; Exam Locking; Exam List data management; etc.\n\n
VistA Imaging gives permission to ISI Imaging to read and update file MAG
VISTARAD SITE PARAMETERS (#2006.69), which contains control data for managing
various logic switches in VistARad (e.g., enable/disable a feature).", "", "", "2023/03/07"], ["7411", "MANUFACTURER File Access", "File", "IFCAP", "2023/01/10", "APPROVED", "Active", "Private", "440.4", "
The ADVANCED PROSTHETICS ACQUISITION TOOL (APAT)
requests FileMan read access to the MANUFACTURER (#440.4) file to determine if
a manufacturer is active or inactive. Navigation to the MANUFACTURER file
will use ITEM MASTER (#441) field MANUFACTURER (#25) which points to file
440.4.", "", "", "2023/01/10"], ["7412", "PSO VDEF RDS O13 OP PHARM PPAR VS", "Other", "OUTPATIENT PHARMACY", "2023/01/18", "APPROVED", "Active", "Private", "", "
The PSO VDEF RDS O13 OP PHARM PPAR VS protocol is used
to send HL7 messages to the Health Data Repository (HDR). See the Outpatient
Pharmacy Technical Manual for message specifications.\n
This documents the protocols allowed to subscribe to this event. Supported HL7
utilities may be used to read the attached message; the message itself and HL7
application variables may not be altered.", "", "", "2023/01/23"], ["7413", "PSO VDEF RDS O13 OP PHARM PREF VS", "Other", "OUTPATIENT PHARMACY", "2023/01/18", "APPROVED", "Active", "Private", "", "
The PSO VDEF RDS O13 OP PHARM PREF VS protocol is used
to send HL7 messages to the Health Data Repository (HDR). See the Outpatient
Pharmacy Technical Manual for message specifications.\n
This documents the protocols allowed to subscribe to this event. Supported HL7
utilities may be used to read the attached message; the message itself and HL7
application variables may not be altered.", "", "", "2023/01/23"], ["7414", "WEB SERVER File (#18.12) access", "File", "WEB SERVICES CLIENT", "2023/01/20", "APPROVED", "Active", "Private", "18.12", "", "", "", "2023/01/24"], ["7415", "REMOTE ALLERGY COMMENT FILE", "File", "ADVERSE REACTION TRACKING", "2023/01/25", "APPROVED", "Active", "Private", "120.88", "
The REMOTE ALLERGY COMMENT file contains locally
entered comments relating to allergies entered for a patient at a separate
(remote) facility which OE/RR displays to providers. There will be a direct
global read of ^GMR(120.88,'PR' to find the last comment, if one exists.", "", "", "2023/05/31"], ["7416", "IA#7416", "File", "TEXT INTEGRATION UTILITIES", "2023/02/22", "APPROVED", "Active", "Private", "8925.7", "
The Virtual Patient Record (VPR) would like to create
an action index on the TIU MULTIPLE SIGNATURE (#8925.7) file that would call a
VPR API in routine VPREVNT when a signer in the file is updated. The FileMan
utility CREIXN^DDMOD would be used in a post-init for patch VPR*1*31 to create
the AVPR index instead of exporting the data dictionary.\n
In addition to retrieving additional signers, the fields listed here are
included in the index for purposes of triggering the action. No actual cross
reference nodes are created.", "", "", "2023/03/06"], ["7417", "IMMUNIZATION HL7 CODE LOOKUP", "Routine", "PCE PATIENT CARE ENCOUNTER", "2023/02/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXRPC", "2023/02/22"], ["7418", "YTQ VERSRV", "Remote Procedure", "MENTAL HEALTH", "2023/03/10", "APPROVED", "Active", "Private", "", "
YTQ VERSRV ICR #7418 is used by WebVRAM to lookup the
YS BROKER1 option to get the MENTAL HEALTH CR DLL VERSION on a particular
VistA system.\n
The following is a capture of the YTQ VERSRV Remote Procedure definition:\n
NAME: YTQ VERSRV TAG: VERSRV
ROUTINE: YTQAPI7 RETURN VALUE TYPE: ARRAY
AVAILABILITY: SUBSCRIPTION DESCRIPTION:
This procedure allows version checking by using the Option (19) menu
text.\n
Input: YSB as option name to be checked. Output: [DATA] vs [ERROR]
2= mha3 version
3= CR dll version
4= mh dll version", "YTQ VERSRV", "", "2023/03/16"], ["7419", "MAILMAN TIME ZONE FILE ACCESS", "File", "MAILMAN", "2023/03/22", "APPROVED", "Active", "Private", "4.4", "\n
The Advanced Prosthetics Acquisition Tool (APAT) requests access to
the MAILMAN TIME ZONE (#4.4) FILE to read CODE and TIME ZONE NAME for the
purpose of documenting the accurate timing of local events.", "", "", "2023/03/29"], ["7420", "EPCS BROKER MENU UPDATE", "File", "KERNEL", "2023/04/07", "APPROVED", "Active", "Private", "200", "\n
This is a onetime agreement via patch PSO*7.0*545.\n
This is for PSO*7*545 only, and will expire when it is released.\n
Post install processing looks for users that have a secondary menu option
of XU EPCS EDIT DATA (legacy ePCS GUI broker menu) and changes it to
PSO EPCS GUI CONTEXT (ePCS GUI 2.0 broker menu).\n
Outpatient Pharmacy requests read access to the NEW PERSON (#200) file to
search for the option XU EPCS EDIT DATA in the SECONDARY MENU OPTIONS
(#200.03) multiple using $$LKOPT^XPDMENU. If the secondary menu XU EPCS
EDIT DATA is found in the user's secondary menus, a call is made to
$$ACCESS^XQCHK to determine the user's status. If the user is active,
then we request write access to change the XU EPCS EDIT DATA secondary
menu to PSO EPCS GUI CONTEXT using FileMan API FILE^DIE.", "", "", "2023/04/18"], ["7421", "DGPROSAD", "Routine", "REGISTRATION", "2023/04/10", "APPROVED", "Active", "Controlled Subscription", "", "
The Master Patient Index (MPI) team has created this
Application Programming Interface (API) which will allow the creation of a new
patient record in the PATIENT (#2) file for a known Integration Control Number
(ICN) or Department of Defense (DoD) Electronic Data Interchange Personal
Identifier (EDIPI) combination.", "", "DGPROSAD", "2023/04/12"], ["7422", "FILE NUMBER FROM FILE NAME", "File", "1", "2023/04/12", "APPROVED", "Active", "Controlled Subscription", "1", "
There is no supported FileMan API to determine the file
number from the file name. This ICR allows the use the FileMan API $$FIND1^DIC
to determine the file number.", "", "", "2023/04/12"], ["7423", "Add NPE user to NEW PERSON (#200) file", "File", "KERNEL", "2023/04/13", "APPROVED", "Active", "Private", "200", "
This ICR allows VDIF to create new non-person entity
(NPE) entries in the NEW PERSON file.", "", "", "2023/04/24"], ["7424", "HL7 MESSAGE REPOSITORY (EHRM HL7 Message #1609)", "Routine", "ELECTRONIC HEALTH MODERNIZATION", "2023/05/02", "APPROVED", "Active", "Controlled Subscription", "", "
Effective with patch EHM*1*10, a repository (EHRM HL7
Message file (#1609)) exists to store HL7 messages that can be used to
research production issues. The repository is intended to store only
Inter-Facility Consult (IFC) and Patient Record Flags (PRF) HL7 messages
exchanged between non-converted VistA sites and Cerner Millennium. This
ensures that the size of the repository is small relative to the total number
of HL7 messages on any individual VistA.\n
In addition to the repository, EHM*1*10 creates Application Programming
Interfaces (API) callable by subscribing packages to populate the repository.
The patch also supplies options to inquire into the repository and to purge
records.\n
Effective with patch GMRC*3*189, when an IFC is initiated by or received on a
non-converted VistA site, the order message and all follow-up messages are
added to the HL7 Message Repository.\n
Effective with patch DG*5.3*1091, when a PRF is initiated by or received on a
non-converted VistA site, the message is added to the HL7 Message Repository.\n
Note: EHM*1*10, GMRC*3*189, DG*5.3*1091 and TIU*1*350 are combined in the IFC
ORDER/ADDENDUM UPDATES 1.0 build released in IFC_ORDER_ADDENDUM_UPDATES.KID.\n
Effective with EHM*1*16, the repository also stores Prosthetics (PSAS) HL7
messages exchanged between non-converted VistA sites and Cerner Millennium.", "", "EHMHL7", "2025/04/23"], ["7425", "ADDENDUM RETRACTION HL7 MESSAGING TO CERNER", "Routine", "CONSULT/REQUEST TRACKING", "2023/05/05", "", "Pending", "Controlled Subscription", "", "
When an addendum belonging to an Inter-Facility Consult
involving Cerner is deleted, HL7 notification of that event is not transmitted
to Cerner. Patch GMRC*3*189 creates a mechanism to correct this. The patch
provides an API that can be called which will produce the HL7 message and
transmit it to Cerner.", "", "GMRCIEHM", ""], ["7426", "API to determine if an IFC involves Cerner", "Routine", "CONSULT/REQUEST TRACKING", "2023/05/05", "", "Pending", "Controlled Subscription", "", "
When an addendum belonging to an Inter-Facility Consult
involving Cerner is deleted, HL7 notification of that event is not transmitted
to Cerner. Patch GMRC*3*189 creates a mechanism to correct this. A GMRC
function provides an API that can be called to determine if a consult is an
IFC involving Cerner.", "", "GMRCIEVT", ""], ["7427", "PXRMRPCG", "Routine", "CLINICAL REMINDERS", "2023/05/16", "APPROVED", "Active", "Private", "", "
This integration agreement allows subscribing packages
to call the GETFIND^PXRMRPCG routine returning Reminder Dialog entry data.", "", "PXRMRPCG", "2023/05/17"], ["7428", "PSOPRKA", "Routine", "OUTPATIENT PHARMACY", "2023/06/07", "APPROVED", "Active", "Private", "", "
ORDER ENTRY/RESULTS REPORTING (OE/RR) is allowed to
utilize the UNPARK^PSOPRKA api in order to complete the unparking of a
prescription functionality introduced with CPRSv32B and the following patch of
PSO*7*712 which will make it available for activation.", "", "PSOPRKA", "2023/10/16"], ["7429", "Insurance Import Enabled Switch", "File", "INTEGRATED BILLING", "2023/07/13", "APPROVED", "Active", "Controlled Subscription", "350.9", "
The Insurance Import Enabled switch lets the background
job know whether the site is currently allowing insurance to be imported from
other sites.", "", "", "2023/07/17"], ["7430", "LIFETIME OF A VERIFY CODE", "File", "KERNEL", "2023/07/25", "APPROVED", "Active", "Private", "8989.3", "
The WebVRAM team would like FileMan read access to the
LIFETIME OF VERIFY CODE (#214) field of the KERNEL SITE PARAMETERS (#8989.3)
file to be used in conjunction with the DATE VERIFY CODE LAST CHANGED (#11.2)
field of the NEW PERSON (#200) file to determine the correct date for when a
WebVRAM user's VERIFY CODE is set to expire at their home VistA account.\n
A new RPC will be released in WEBG*3.0*14 to implement this functionality.", "", "", "2023/08/10"], ["7431", "GET AN ORDER STATUS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2023/08/08", "APPROVED", "Active", "Private", "", "
This ICR allows Clinical Reminders to retrieve an order
status name.", "", "ORQ12", "2023/08/10"], ["7432", "WVAPI routine", "Routine", "WOMEN'S HEALTH", "2023/08/08", "", "Under Revision", "Controlled Subscription", "", "
This ICR allows access to the entry points in routine
WVAPI, effective with PXRM*2.0*81 and WV*1.0*31", "", "WVAPI", "2023/08/10"], ["7433", "RETURN THE INSTITUTION ENTRY FOR AN LOCATION", "Routine", "PCE PATIENT CARE ENCOUNTER", "2023/08/08", "APPROVED", "Active", "Private", "", "
This API returns the corresponding file 4 IEN for the
passed in location IEN from file 44.", "", "VSITCK1", "2023/08/14"], ["7434", "DELETE LANG NODES", "File", "1", "2023/08/15", "APPROVED", "Active", "Private", "399.047", "
The following nodes will be deleted in patch
IB*2.0*742.\n
VALUE K ^DD(399.047,.02,.009,1,0)\n
On a previous patch, IB*2.0*727, the VALUE field was given specific detailed
executable help depending on the corresponding VALUE CODE. Extraneous data
nodes in DD's at some sites display a generic message that contradicts the
executable help.\n
(ENTER FROM 1 TO 10 CHARACTERS OF FREE TEXT)\n
This patch contains a one-time cleanup in the post install routine IBY742PO.", "", "", "2023/08/16"], ["7435", "Enhanced PCE Encounter Lookup", "Routine", "PCE PATIENT CARE ENCOUNTER", "2023/08/22", "APPROVED", "Active", "Controlled Subscription", "", "", "", "PXUTLVST", "2023/08/23"], ["7436", "OE/RR SURGERY (#130) FILE ACCESS", "File", "SURGERY", "2023/09/11", "APPROVED", "Active", "Private", "130", "
ORDER ENTRY/RESULTS REPORTING IS ACCESSING THE SURGERY
(#130) FILE TO GATHER THE ORDER NUMBER (#100) FIELD IN ORDER TO DETERMINE THE
ORDERING PROVIDER FOR NOTIFICATIONS DISPLAYED IN CPRS (COMPUTERIZED PATIENT
RECORD SYSTEM).", "", "", "2023/09/12"], ["7437", "GMVBMI", "Routine", "GEN. MED. REC. - VITALS", "2023/09/07", "APPROVED", "Active", "Private", "", "
The CALBMI entry point provides a consistent and
accurate calculation of the BMI value for an associated weight measurement.", "", "GMVBMI", "2023/09/08"], ["7438", "COMPACT ACT EOC EDIT ACCESS", "Other", "PCE PATIENT CARE ENCOUNTER", "2023/10/05", "APPROVED", "Active", "Private", "", "
The COMPACT Act EOC Edit [PX COMPACT ACT EOC EDIT]
option and the COMPACT Act EOC Inpatient Retraction [PX COMPACT EOC IP
RETRACTION] option will be added to the Supervisor ADT Menu [DG SUPERVISOR
MENU]. REGISTRATION admissions will need the ability to edit the start and/or
end date(s) of the Acute Suicidal Crisis from the new COMPACT Act EOC Edit
option so that this date will be captured per VA policy. The new COMPACT Act
EOC Inpatient Retraction option will allow an Episode of Care to be retracted
if a patient was entered in error or the wrong codes were used. These edits
will be made based on supporting documentation from the Provider.", "", "", "2023/10/16"], ["7439", "ORDER BUILD AND SAVE ORDER TEXT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2023/10/13", "", "Pending", "Private", "", "
ORDTEXT^ORCSAVE1 - Build and save ORDER TEXT from
ORDIALOG() into ORDER file.\n
ORTX^ORCSAVE1 - Build ORDER text from ORDIALOG() to ORTX() array. Does not
update ORDER.", "", "ORCSAVE1", ""], ["7440", "ORDER BUILD AND SAVE ORDER TEXT", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2023/10/13", "APPROVED", "Active", "Private", "", "
ORTX^ORCSAVE1 - Build ORDER text from ORDIALOG() to
ORTX() array. Does not update ORDER.", "", "ORCSAVE1", "2023/10/13"], ["7441", "NATURE OF ORDER FILE ACCESS", "File", "ORDER ENTRY/RESULTS REPORTING", "2023/10/17", "APPROVED", "Active", "Private", "100.02", "\n
INPATIENT MEDICATIONS requests one time permission to read the
NATURE OF ORDER FILE (#100.02). INPATIENT MEDICATIONS will look up
the nature of order in file #100.02 using the "B" cross reference
in order to set an order to 'CHANGED' based on the value in the cross
reference.\n
This is for one time use.\n
^ORD(100.02,'B'
'B' cross reference - used to look up the file #100.02 entry", "", "", "2023/10/19"], ["7442", "ORDER REASON FILE ACCESS", "File", "ORDER ENTRY/RESULTS REPORTING", "2023/10/17", "APPROVED", "Active", "Private", "100.03", "\n
INPATIENT MEDICATIONS requests one time permission to read the
ORDER REASON FILE (#100.03). INPATIENT MEDICATIONS will look up
the nature of order in file #100.03 using the "B" cross reference
in order to set a discontinued order to 'Entered in Error' based on
the value in the cross reference.\n
This is for one time use.\n
^ORD(100.03,'B'
'B' cross reference - used to look up the file #100.03 entry", "", "", "2023/10/19"], ["7443", "ORWPT GET FULL ICN", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2023/10/19", "APPROVED", "Active", "Controlled Subscription", "", "
Following are the details of the ORWPT GET FULL ICN:\n
NAME: ORWPT GET FULL ICN TAG: GETFICN
ROUTINE: ORWPT RETURN VALUE TYPE: SINGLE VALUE
APP PROXY ALLOWED: Yes DESCRIPTION:
RPC to return the ICN plus checksum for a given DFN. INPUT PARAMETER: DFN
PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1 DESCRIPTION:
The patient's internal entry number (IEN) in the PATIENT file (#2). RETURN
PARAMETER DESCRIPTION:
ORWRSLT is either the patient ICN or, in the event of an error, p1^p2 where
p1=-1 and p2=the error text. Possible return values for error conditions are
either -1^UNKNOWN ERROR or the error messages returned by $$GETICN^MPIF001.", "", "", "2023/10/26"], ["7444", "ORWDRA32 LOCTYPE", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2023/10/26", "APPROVED", "Active", "Private", "", "", "ORWDRA32 LOCTYPE", "", "2023/11/14"], ["7445", "MMRSIPC Routine", "Routine", "MRSA INITIATIVE REPORTS", "2023/11/03", "APPROVED", "Active", "Private", "", "
The MMRS package provides MRSA data reporting for use
in IPEC reports. Bitscopic has developed a feature in the VEHB BITSCOPIC
package, VEHB*1.4*1 patch, to extract the MRSA transmission numbers for use in
advanced alerting to improve the IPEC reporting process. This functionality
will be used by staff at Palo Alto and Greater Los Angeles to improve MRSA
transmission surveillance.\n
VEHB BITSCOPIC uses the following components:
CLEAN^MMRSIPC: The routine VEHBIPEC uses this component to kill the ^TMP
globals used by subsequent calls to ensure there is no data carryover from
earlier report executions.
GETPARAM^MMRSIPC: The routine VEHBIPEC uses this component to load the MMRS
site parameters into the ^TMP global.
PATDAYS^MMRSIPC:The routine VEHBIPEC uses this component to get patient days
of care and store them in the ^TMP global.", "", "MMRSIPC", "2023/11/20"], ["7446", "MMRSIPC2 Routine", "Routine", "MRSA INITIATIVE REPORTS", "2023/11/03", "APPROVED", "Active", "Private", "", "
The MMRS package provides MRSA data reporting for use
in IPEC reports. Bitscopic has developed a feature in the VEHB BITSCOPIC
package, VEHB*1.4*1 patch, to extract the MRSA transmission numbers for use in
advanced alerting to improve the IPEC reporting process. This functionality
will be used by staff at Palo Alto and Greater Los Angeles to improve MRSA
transmission surveillance.\n
VEHB BITSCOPIC uses the following component:
GETMOVE^MMRSIPC2: The routine VEHBIPEC uses this component to get patient
movements and store them in the ^TMP global.", "", "MMRSIPC2", "2023/11/20"], ["7447", "MMRSIPC3 Routine", "Routine", "MRSA INITIATIVE REPORTS", "2023/11/03", "APPROVED", "Active", "Private", "", "
The MMRS package provides MRSA data reporting for use
in IPEC reports. Bitscopic has developed a feature in the VEHB BITSCOPIC
package, VEHB*1.4*1 patch, to extract the MRSA transmission numbers for use in
advanced alerting to improve the IPEC reporting process. This functionality
will be used by staff at Palo Alto and Greater Los Angeles to improve MRSA
transmission surveillance.\n
VEHB BITSCOPIC uses the following component:
GETLABS^MMRSIPC3: The routine VEHBIPEC uses this component to get the
swabbing rates and MRSA history for the site and store them in the ^TMP
global.", "", "MMRSIPC3", "2023/11/20"], ["7448", "MDRO SITE PARAMETERS FILE", "File", "MRSA INITIATIVE REPORTS", "2023/11/03", "APPROVED", "Active", "Private", "104", "
The MMRS package provides MRSA data reporting for use
in IPEC reports. Bitscopic has developed a feature in the VEHB BITSCOPIC
package, VEHB*1.4*1 patch, to extract the MRSA transmission numbers for use in
advanced alerting to improve the IPEC reporting process. This functionality
will be used by staff at Palo Alto and Greater Los Angeles to improve MRSA
transmission surveillance.\n
VEHB BITSCOPIC needs acces to file 104, field .01 to support enhanced MRSA
transmission surveillance reporting.\n
The routine VEHBIPEC uses FileMan to access site configuration data in order
to identify which locations to associate the information accumulated via calls
made to MMRS package routines.\n
Description for File 104 This file holds the set of parameters which modify
the operation of the MRSA Program Tools to suit the needs of your site. For
multi-divisional facilities, each division should have a separate entry in
this file.", "", "", "2023/11/20"], ["7449", "MDRO WARD MAPPINGS FILE", "File", "MRSA INITIATIVE REPORTS", "2023/11/03", "APPROVED", "Active", "Private", "104.3", "
The MMRS package provides MRSA data reporting for use
in IPEC reports. Bitscopic has developed a feature in the VEHB BITSCOPIC
package, VEHB*1.4*1 patch, to extract the MRSA transmission numbers for use in
advanced alerting to improve the IPEC reporting process. This functionality
will be used by staff at Palo Alto and Greater Los Angeles to improve MRSA
transmission surveillance.\n
VEHB BITSCOPIC needs acces to file 104.3, fields .01,1,3 4 to support enhanced
MRSA transmission surveillance reporting.\n
The routine VEHBIPEC uses FileMan to access site configuration data in order
to identify which locations to associate the information accumulated via calls
made to MMRS package routines.\n
Description for File 104.3 This file contains the Ward Mappings for the MDRO
Program Tools software. Here you will create 'Geographical Units' which
consist of one or more Ward Locations (from file 42). For purposes of the MDRO
Program Tools software all Ward Locations belonging to the same Geographical
unit are one - and any interward transfers between wards belonging to the same
geographical unit will be ignored.", "", "", "2023/11/20"], ["7450", "READ ACCESS TO PXRMINDX", "File", "CLINICAL REMINDERS", "2024/01/05", "", "Pending", "Controlled Subscription", "", "
The purpose of this Integration Control Registration
(ICR) is to grant read-only access to the Clinical Reminders Index.", "", "", ""], ["7451", "GIVE THIS DBIA A BETTER NAME THAN DBIA7451", "", "", "2024/01/09", "", "Pending", "", "", "", "", "", ""], ["7452", "SDEC APPADD", "Remote Procedure", "SCHEDULING", "2024/01/17", "", "Pending", "Private", "", "
The SwitchLane Periopt application is calling the code
for the SDEC APPADD RPC in order to schedule dental appointments.", "SDEC APPADD", "", ""], ["7453", "SDEC APPDEL", "Remote Procedure", "SCHEDULING", "2024/01/17", "", "Pending", "Private", "", "", "SDEC APPDEL", "", ""], ["7454", "ACCESS COMPACT ACT DATA FOR HL7 TRANSMISSION", "Routine", "PCE PATIENT CARE ENCOUNTER", "2024/02/01", "APPROVED", "Active", "Private", "", "
Effective with PX*1.0*241 from the COMPACT OHI project,
to share critical changes to the COMPACT ACT EPISODE OF CARE File #818 to VES
via a new HL7 segment, ZCA, added to the existing IVM Background Job Full Z07
HL7 message.", "", "PXCOMPACTHL7", "2024/10/10"], ["7455", "CHANGE LOG/EDIT HISTORY APIs", "Routine", "CLINICAL REMINDERS", "2024/03/25", "APPROVED", "Active", "Private", "", "", "", "PXRMCLEH", "2025/03/17"], ["7456", "PATCH 31 POST-INSTALL", "Routine", "WOMEN'S HEALTH", "2024/03/25", "APPROVED", "Active", "Private", "", "
This integration agreement allows the subscribing
package to execute the post-install code for patch WV*1*31. This code is
called when a site determines to move ahead with implementing the
functionality contained in this patch.", "", "WV1031L", "2024/03/26"], ["7457", "REMINDER MANAGEMENT MAIL GROUP API", "Routine", "CLINICAL REMINDERS", "2024/03/25", "APPROVED", "Active", "Private", "", "", "", "PXRMMSG", "2024/08/14"], ["7458", "CLINICAL REMINDER SPONSOR IEN API", "Routine", "CLINICAL REMINDERS", "2024/03/25", "APPROVED", "Active", "Private", "", "", "", "PXRMSPED", "2024/08/14"], ["7459", "Display Service Connected info on ACC Worklists", "File", "REGISTRATION", "2025/03/24", "APPROVED", "Active", "Private", "2", "
This ICR allows the Automated Community Care (ACC)
claims initiative to display Service Connected/Special Authority information
for the purpose of routing claims to the proper worklist. The ACC worklists
are implemented with IB*2.0*770.", "", "", "2025/03/24"], ["7460", "PCE NATIONAL CONTENT UPDATE", "Routine", "CLINICAL REMINDERS", "2024/03/26", "APPROVED", "Active", "Private", "", "", "", "PXRMP67NCUPD", "2024/05/28"], ["7461", "TIU OBJECT CREATION", "Routine", "TEXT INTEGRATION UTILITIES", "2024/04/11", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement enables subscribing packages
to create both TIU objects as well as the TIU half of TIU/Health Summary
objects (it DOES NOT create the Health Summary half of TIU/Health Summary
objects).", "", "TIUCROBJ", "2024/04/12"], ["7462", "COMPACT ACT Administrative Eligibility", "Routine", "REGISTRATION", "2024/04/15", "APPROVED", "Active", "Controlled Subscription", "", "
Patches DG*5.3*1104 and PX*1.0*240 will allow PCE and
Scheduling to make decisions on when to prompt for COMPACT Act clinical
information. For this decision-making process, PCE or Scheduling needs to
call the entry point ELIG^DGCOMPACTELIG to get and display the patient's
COMPACT Act administrative eligibility status.", "", "DGCOMPACTELIG", "2024/05/07"], ["7463", "COMPACT Act Treatment Related to Flag in PTF", "Routine", "REGISTRATION", "2024/04/15", "APPROVED", "Active", "Private", "", "
During certain COMPACT Act processing, such as creation
or retraction of an Episode of Care (EOC), the EOC processing routines in PCE
sometimes need to access the DGCOMPACT routine to set "Treatment Related To"
flags in the PTF file (#45).", "", "DGCOMPACT", "2024/04/23"], ["7464", "COMPACT ACT Retract Episode of Care", "Routine", "PCE PATIENT CARE ENCOUNTER", "2024/04/15", "APPROVED", "Active", "Private", "", "
Registration needs to be able to retract a COMPACT Act
Episode of Care when a patient was entered with the wrong codes or the wrong
patient was entered.", "", "PXCOMPACTEOC", "2024/04/24"], ["7465", "COORDINATE UPDATES TO CPRS INFORMATION PANELS", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2024/04/16", "", "Pending", "Private", "", "
This ICR allows Clinical Reminder Exchange to notify
the CPRS Information Panels functionality, when Reminder Exchange is
installing updates to the National CPRS Information Panels.", "", "ORITUL", ""], ["7466", "PXRM APIS FOR CPRS INFORMATION PANELS", "Routine", "CLINICAL REMINDERS", "2024/04/16", "APPROVED", "Active", "Private", "", "
This ICR allows OERR to call into the Clinical Reminder
Package for data that is needed to support the CPRS Information Panels
functionality.", "", "PXRMAPI", "2025/03/14"], ["7467", "DGSEC", "Routine", "REGISTRATION", "2024/04/19", "APPROVED", "Active", "Controlled Subscription", "", "
Call to routine DGSEC linetag SETLOG1. This allows the
Scheduling package to pass in DUZ and DFN; which is needed so that the proxy
user is not recorded as the user of record.", "", "DGSEC", "2025/04/09"], ["7468", "INSTALL/UPDATE HEALTH SUMMARY TYPES & OBJECTS", "Routine", "HEALTH SUMMARY", "2024/04/22", "", "Pending", "Private", "", "
This integration agreement allows the subscribing
package to install and/or update Health Summary Types and Objects.", "", "GMTSXPD6", ""], ["7469", "COMPACT ACT ERROR LOGGING", "Routine", "PCE PATIENT CARE ENCOUNTER", "2024/05/07", "APPROVED", "Active", "Private", "", "
Patches DG*5.3*1104 and PX*1.0*240 will allow
Registration to log calls to the EE Web Service in the COMPACT ACT TRANSACTION
LOG File (#33.3). Registration needs to access the entry point
FILEMANERR^PXCOMPACT1 to log any data errors during this process.", "", "PXCOMPACT1", "2024/05/20"], ["7470", "sens dgsec4", "", "REGISTRATION", "2024/05/14", "", "Pending", "Controlled Subscription", "", "", "", "", ""], ["7471", "TIU Highlighting Preferences", "File", "TEXT INTEGRATION UTILITIES", "2024/05/23", "APPROVED", "Active", "Private", "8926", "
The Dental Record Manager Plus (DRM Plus) application
is requesting access to TIU preferences fields related to highlighting of
required fields. This is to retain consistent behavior and appearance between
CPRS and the DRM Plus application as it pertains to provider notes.", "", "", "2024/05/23"], ["7472", "COMPACT ACT API for IB", "Routine", "PCE PATIENT CARE ENCOUNTER", "2024/05/23", "APPROVED", "Active", "Private", "", "
During COMPACT Act processing, Integrated Billing (IB)
needs to determine whether a given encounter, admission, or patient movement
is treatment for an acute suicidal crisis. This API allows IB to call PCE for
this information.", "", "PXCOMPACTIB", "2024/08/12"], ["7473", "Import Insurance with CBOC Move", "Routine", "INTEGRATED BILLING", "2024/06/03", "APPROVED", "Active", "Private", "", "
Will initiate a %ZTLOAD call to BACKGND^IBCNRDV to
retrieve insurance data from sites of record for brunswick cboc patients moved
from Dublin to Charleston. This move will take place in Oct 2024. This ICR
should expire 12/31/24.", "", "IBCNRDV", "2024/09/05"], ["7474", "NPI AND EFFECTIVE DATE/TIME", "File", "KERNEL", "2024/06/03", "APPROVED", "Active", "Controlled Subscription", "200", "
The IAM group agrees to conditional approval of this
ICR request. The condition is that WebVRAM commits in the future to further
integration with IAM APIs to perform create and update of the remote sites NEW
PERSON (#200) file record.\n
Approval granted pending use of IAM APIs in the future: WebVRAM is requesting
an ICR to modify the contents of VistA file #200.042 and field #41.99 from
file #200 with FileMan.\n
WebVRAM is a TELEHEALTH application that assists its users with accessing
VistA areas outside of the main VistA area the user is associated with.
WebVRAM copies user profile information from the user's Home VistA area to the
Remote VistA area they are attempting to access. A WebVRAM user may only use
the application to access VistA areas they have been assigned to by their
business unit.\n
The WebVRAM product team was approached by the Pharmacists group in Tennessee
about the need to use the PDMP Query in CPRS to maintain reporting compliance
for controlled substances. In order to use the PDMP Query in CPRS the
pharmacist / provider is required to have a combination of a valid NPI, NPI
effective date, and person class. WebVRAM currently has the ability to
update the person class at the remote VistA area and would need to update
field #41.99 from file #200 and file #200.042 to provide the effective date
for the NPI. WebVRAM would use the DDR FILER RPC to modify the file contents.\n", "", "", "2024/07/11"], ["7475", "GIVE THIS DBIA A BETTER NAME THAN DBIA7475", "", "", "2024/06/05", "", "Pending", "", "", "", "", "", ""], ["7476", "GIVE THIS DBIA A BETTER NAME THAN DBIA7476", "", "", "2024/06/07", "", "Pending", "", "", "", "", "", ""], ["7477", "GIVE THIS DBIA A BETTER NAME THAN DBIA7477", "", "", "2024/06/07", "", "Pending", "", "", "", "", "", ""], ["7478", "GIVE THIS DBIA A BETTER NAME THAN DBIA7478", "", "", "2024/06/07", "", "Pending", "", "", "", "", "", ""], ["7479", "Determine if sensitive record", "Routine", "REGISTRATION", "2024/06/12", "APPROVED", "Active", "Controlled Subscription", "", "
Call to routine SENS^DGSEC4 om order to help determine
the sensitivity level of a record. Will use this API in order to check if
record is sensitive, and if user holds DG SENSITIVITY key In order to
appropriately determine if user request is a sensitive record check.", "", "DGSEC4", "2024/07/01"], ["7480", "Audit patient records at selection", "Routine", "REGISTRATION", "2024/06/12", "APPROVED", "Active", "Controlled Subscription", "", "
Call to routine SELAUD^DGAUDIT2 to allow VistA Web
Service Layer (VWSL) to audit patient records at their selection. If request
from VWSL has user reviewing a patient record, will use this API as
appropriate to audit the records during selection.", "", "DGAUDIT2", "2024/10/24"], ["7481", "LHS CHECK OPTION ACCESS RPC", "Remote Procedure", "LIGHTHOUSE", "2024/06/20", "APPROVED", "Active", "Private", "", "
The Clinical Decision Support Platform (CDSP) requires
access to the LHS CHECK OPTION ACCESS Remote Procedure to determine if a user
has access to a particular option. This access is supported by Shared Support
Services of CDSP.\n
The following is the LHS CHECK OPTION ACCESS Remote Procedure definition:\n
NAME: LHS CHECK OPTION ACCESS TAG: OPT
ROUTINE: LHSRPC RETURN VALUE TYPE: SINGLE VALUE
AVAILABILITY: RESTRICTED APP PROXY ALLOWED: Yes DESCRIPTION:
This RPC uses the Kernel supported API $$ACCESS^XQCHK to verify if a
VistA user has access to an option or not. INPUT PARAMETER: USER
PARAMETER TYPE: LITERAL
MAXIMUM DATA LENGTH: 20 REQUIRED: YES
SEQUENCE NUMBER: 1 DESCRIPTION:
This is the user DUZ being checked for option access. INPUT PARAMETER:
OPTION PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 2 DESCRIPTION:
This is either the IEN or the NAME of an option in the OPTION file #19.
RETURN PARAMETER DESCRIPTION:
The return data is the same as the Kernel API $$ACCESS^XQCHK supported
through ICR #10078.\n
-1:no such user in the New Person File
-2: User terminated or has no access code
-3: no such option in the Option File
0: no access found in any menu tree the user owns\n
All other cases return a 4-piece string stating
access ^ menu tree IEN ^ a set of codes ^ key\n
O^tree^codes^key: No access because of locks (see XQCODES below)
where 'tree' is the menu where access WOULD be allowed
and 'key' is the key preventing access
1^OpIEN^^: Access allowed through Primary Menu
2^OpIEN^codes^: Access found in the Common Options
3^OpIEN^codes^: Access found in top level of secondary option
4^OpIEN^codes^: Access through a the secondary menu tree OpIEN.\n
XQCODES can contain:
N=No Primary Menu in the User File (warning only)
L=Locked and the user does not have the key (forces 0 in first piece)
R=Reverse lock and user has the key (forces 0 in first piece)", "", "", "2024/10/07"], ["7482", "Attach OR option to PSJU Reports menu", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2024/06/25", "APPROVED", "Active", "Private", "", "
This ICR enables the Opioid Treatment Program (OTP)
Medication Dispense Report to be available in the Pharmacy package. It is
called from Unit Dose Medications > Reports > OTP Dispense Report.", "", "ORDOTP", "2024/08/26"], ["7483", "PSJ FILE ACCESS 8927", "File", "TEXT INTEGRATION UTILITIES", "2024/07/22", "APPROVED", "Active", "Private", "8927", "
Inpatient Medications will need to obtain read access
to the B cross reference Name field and Boilerplate Text Field in Template
File (8927). This read access will help determine if the Template Title in
provider comments exist in the Template File and if it matches the Boilerplate
Text.", "", "", "2024/07/22"], ["7484", "TRT FOR ACUTE SUICIDAL CRISIS field in PTF", "File", "REGISTRATION", "2024/08/07", "", "Withdrawn", "Private", "45", "
In order to process a request from Integrated Billing
(IB) via the $$REQUEST^PXCOMPACTIB API (Please see ICR #7472), PATIENT CARE
ENCOUNTER (PCE) needs to be able to check the TRT FOR ACUTE SUICIDAL CRISIS
field (#79.33) in the PTF file (#45).", "", "", ""], ["7485", "PATIENT MOVEMENT POINTER FIELDS", "File", "REGISTRATION", "2024/08/09", "", "Withdrawn", "Private", "405", "
In order to process a request from Integrated Billing
(IB) via the $$REQUEST^PXCOMPACTIB API (Please see ICR #7472), PATIENT CARE
ENCOUNTER (PCE) needs to be able to check certain fields in the PATIENT
MOVEMENT file (#405).", "", "", ""], ["7486", "XUS ESSO VALIDATE JWT", "Remote Procedure", "KERNEL", "2024/08/12", "", "Pending", "Private", "", "
This API/RPC uses either VA Identity and Access
Management (IAM) or Microsoft EntraID JSON Web Token (JWT) payload attributes
to authenticate a user. The type of JSON Web Token (JWT) must be a
"transparent" token, meaning it must contain a readable header, payload, and
signature. This API/RPC will validate the contents and signature of the JSON
Web Token (JWT). In addition, the issuer within the JWT payload must match an
issuer in the TOKEN VALIDATION DATA (#8981) file on the VistA system which
contains valid Identity Providers (IdPs) that are authorized to issue JSON Web
Tokens (JWTs).", "XUS ESSO VALIDATE JWT", "", ""], ["7487", "INVOKE DUZ-XUP Non-HL7", "Routine", "KERNEL", "2024/08/19", "APPROVED", "Active", "Private", "", "
Temporary solution for Scheduling application, as there
exists a gap in the RPC Broker and VistALink that cannot meet Scheduling
needs. A POAM has been created to track this risk.\n
RISK: The risk being that Kernel is not part of the validation of user
credentials when changing the identity of the user when invoking DUZ-XUP.\n
GAP: The gap is the need for Scheduling to share a single connection session,
initially owned by an approved IAM Service account (non-person, Remote
Application), with different Scheduling users (persons), by being able to
change both the user and the Broker context.", "", "XUP", "2025/03/19"], ["7488", "ORWPT ID INFO", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2024/08/29", "", "Pending", "", "", "
The CDS Platform provides a base infrastructure with
scalability for other applications to develop on. Teams can build clinical
applications and register them on the existing SMART on FHIR (SoF) container
to launch and deploy to VA sites. The platform has several capabilities that
facilitate the seamless transfer of patient data between EHR and applications.
For each application on the platform, the SoF container will launch a SMART on
FHIR application via URL, sync clinical context with CPRS and handle
authentication and authorization of users.", "ORWPT ID INFO", "", ""], ["7489", "ORWTPT ATEAMS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2024/08/30", "APPROVED", "Active", "Private", "", "
The CDS Platform provides a base infrastructure with
scalability for other applications to develop on. Teams can build clinical
applications and register them on the existing SMART on FHIR (SoF) container
to launch and deploy to VA sites. The platform has several capabilities that
facilitate the seamless transfer of patient data between EHR and applications.
For each application on the platform, the SoF container will launch a SMART on
FHIR application via URL, sync clinical context with CPRS and handle
authentication and authorization of users.", "ORWTPT ATEAMS", "", "2025/02/14"], ["7490", "ORWTPT GETTEAM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2024/08/30", "APPROVED", "Active", "Private", "", "
The CDS Platform provides a base infrastructure with
scalability for other applications to develop on. Teams can build clinical
applications and register them on the existing SMART on FHIR (SoF) container
to launch and deploy to VA sites. The platform has several capabilities that
facilitate the seamless transfer of patient data between EHR and applications.
For each application on the platform, the SoF container will launch a SMART on
FHIR application via URL, sync clinical context with CPRS and handle
authentication and authorization of users.", "ORWTPT GETTEAM", "", "2025/02/14"], ["7491", "ORQPT TEAM PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2024/08/30", "", "Pending", "", "", "
The CDS Platform provides a base infrastructure with
scalability for other applications to develop on. Teams can build clinical
applications and register them on the existing SMART on FHIR (SoF) container
to launch and deploy to VA sites. The platform has several capabilities that
facilitate the seamless transfer of patient data between EHR and applications.
For each application on the platform, the SoF container will launch a SMART on
FHIR application via URL, sync clinical context with CPRS and handle
authentication and authorization of users.", "ORQPT TEAM PATIENTS", "", ""], ["7492", "PSO EPCS PSDRPH FILER", "Remote Procedure", "OUTPATIENT PHARMACY", "2024/09/09", "APPROVED", "Active", "Private", "", "
The Web Veteran's Health Information Systems and
Technology Architecture (VistA) Remote Access Management (WebVRAM) application
requires a Remote Procedure Call (RPC) that allocates and deallocates the
PSDRPH key to a specific user and logs the event in the XUEPCS PSDRPH AUDIT
file (#8991.7). The PSO EPCS PSDRPH FILER RPC has been created to allocate and
de-allocate and audit the assignment/unassignment of the PSDRPH key.\n
Remote Procedure: PSO EPCS PSDRPH FILER
---------------------------------------
ROUTINE: PSOEPUT2 COMPONENT: PSDKEY\n
DESCRIPTION: The PSDKEY entry point is invoked by the PSO EPCS PSDRPH FILER
Remote Procedure Call (RPC) to perform allocation and deallocation of the
PSDRPH key, and log the event in the XUEPCS PSDRPH AUDIT file (#8991.7).\n
VARIABLES: PSOSUBJ (Input) The NEW PERSON (#200) file Internal Entry Number
(IEN) of the user to whom the PSDRPH key is being allocated or deallocated.\n
VARIABLES: PSOACTOR (Input) The NEW PERSON (#200) file Internal Entry Number
(IEN) of the user performing the allocation or deallocation of the PSDRPH key.\n
VARIABLES: PSOACTION (Input) A flag indicating the type of action to be taken,
either "A" to allocate the PSDRPH key, or "D" to deallocate the PSDRPH key.\n
VARIABLES: RESULTS (Output) The return value is 1 if the allocation or
deallocation was successful. The return value is 0^Error Message Text if the
allocation or deallocation was unsuccessful.\n
Revision History -
10/16/24 The WebVRAM and Outpatient Pharmacy development teams are working
together on the release of the RPC and the WebVRAM GUI changes to invoke the
RPC. The Pharmacy patch is PSO*7*732 and the WEBG patch is WEBG*3*21. The ICR
that authorizes Pharmacy's reference to file 8991.7 is #7016. This RPC
performs the same function as the Allocate/De-Allocate of PSDRPH Key (Audited)
[PSO EPCS PSDRPH KEY]. WebVRAM's subscription to ICR 7016 is valid only as
long as ICR 7492 is active.", "", "PSOEPUT2", "2024/10/16"], ["7493", "READ/WRITE ACCESS TO OTP MEDICATION DISPENSE FILE", "File", "ORDER ENTRY/RESULTS REPORTING", "2024/09/13", "", "Pending", "Private", "101.22", "
The Text Integration Utilities (TIU) Package needs
read/write access to the OTP Medication Dispense File (#101.22) in support of
the Methadone Dispense Tracking project.", "", "", ""], ["7494", "READ V STANDARD CODES DATA", "File", "PCE PATIENT CARE ENCOUNTER", "2024/09/16", "APPROVED", "Active", "Controlled Subscription", "9000010.71", "", "", "", "2024/09/16"], ["7495", "CDSP REQUESTING ACCESS TO LHS CHECK OPTION ACCESS RPC", "Remote Procedure", "LIGHTHOUSE", "2024/09/18", "", "Pending", "", "", "
Clinical Decision Support Platform is requesting access
to the Lighthouse RPC LHS CHECK OPTION ACCESS. The CDSP Platform team is
reuesting this RPC be added to the menu option CDSP RPC CONTEXT to determine
is a particular user has access to a specific VistA menuu option.\n
The Platform team is requesting this access to support future APPs that may
use the common Clinical Decision Support Platform as a shared service. This
will also support enhancements to current APPs in the CDS group of APPs such
as MedPic, MecCalc, Lung Cancer Screening v2", "", "", ""], ["7496", "GIVE THIS DBIA A BETTER NAME THAN DBIA7496", "", "", "2024/09/27", "", "Pending", "", "", "", "", "", ""], ["7497", "Call MAGT7MA For LAB Data From File 63", "Routine", "IMAGING", "2024/09/27", "", "Active", "Controlled Subscription", "", "
MEDICOM TECHNOLOGIES requests to call $$GETFILE^MAGT7MA
to get LABORATORY TEST file (#60) data, determine the error status of the lab
and return FILE("FIELD") fields for the LAB DATA file (#63).", "", "MAGT7MA", ""], ["7498", "GIVE THIS DBIA A BETTER NAME THAN DBIA7498", "", "", "2024/10/03", "", "Pending", "", "", "", "", "", ""], ["7499", "GIVE THIS DBIA A BETTER NAME THAN DBIA7499", "", "", "", "", "Pending", "", "", "", "", "", ""], ["7500", "TIU CALL TO OTP FILER", "Routine", "ORDER ENTRY/RESULTS REPORTING", "2024/10/03", "APPROVED", "Active", "Private", "", "
ORDOTP1 is an API that will update file (#101.22) with
dispense data from an opioid clinic. ICR 7500 was created to support the
METHADON DISPENSE TRACKING project, effective with TIU*1.0*360 and
ORD*3.0*618.", "", "ORDOTP1", "2025/03/12"], ["7501", "Get Lab Test Data", "Routine", "IMAGING", "2024/10/10", "", "Active", "Controlled Subscription", "", "
The routine creates the OBR segment for HL7 message to
DPS and provides a lookup for Lab Test", "", "MAGT7SB", ""], ["7502", "ORQQVI METRIC FIRST PARAMETER", "Other", "ORDER ENTRY/RESULTS REPORTING", "2024/10/11", "APPROVED", "Active", "Private", "", "
This integration agreement allows the subscribing
package to retrieve the value(s) stored in the ORQQVI METRIC FIRST parameter
via supported calls to the appropriate KERNEL API.", "", "", "2024/10/16"], ["7503", "READ ACCESS ONLY TO BPS RESPONSES FILE", "File", "E CLAIMS MGMT ENGINE", "2024/10/22", "APPROVED", "Active", "Private", "9002313.03", "
E CLAIMS MGMT ENGINE grants INSURANCE CAPTURE BUFFER
FileMan Read access to all fields and cross references in the BPS RESPONSES
(#9002313.03) file. Direct global read access of all cross-references is
allowed.", "", "", "2024/10/22"], ["7504", "DICOM Patient Lookup", "Routine", "IMAGING", "2024/10/22", "", "Active", "Controlled Subscription", "", "
API's and RPC'S for VistA PATIENT lookup routine", "", "MAGDSTA3", ""], ["7505", "Setup Rad/Nuc Med HL7 Output Array Separators", "Routine", "IMAGING", "2024/11/04", "", "Active", "Controlled Subscription", "", "
Patch MECH*1.0*1 gathers patient cases to send to the
ImageX Application via HL7 messages. This patch calls $$OUTSEP^MAGVIM01 and
$$STATSEP^MAGVIM01 to get the correct separators for the HL7 messages.", "", "MAGVIM01", ""], ["7506", "SPECIAL AUTHORITIES", "Routine", "PCE PATIENT CARE ENCOUNTER", "2024/11/07", "APPROVED", "Active", "Controlled Subscription", "", "
Patch PX*1*244 will release a new SPECIAL AUTHORITIES
FILE #(820) and a routine of API calls to retrieve information about all the
special authorities. This Controlled ICR allows subscribers to call these
APIs.\n
The Special Authorities file will define all the currently known Special
Authorities. This file will facilitate future growth and help minimize
elaborate software enhancements when adding a new special authority. This file
contains the business rules for each special authority, e.g. name, code,
disabled, abbreviation, sequence, default, disabled, visible, Package -
disabled?, Linked authority behavior rules, Linked Authority, When value is,
Actions to take.\n
See the individual component entries for descriptions and examples of how to
call the API and what it returns.", "", "PXSPECAUTH", "2025/04/28"], ["7507", "GIVE THIS DBIA A BETTER NAME THAN DBIA7507", "", "", "2025/01/03", "", "Pending", "", "", "", "", "", ""], ["7508", "TIU Progress Note Build", "Routine", "TEXT INTEGRATION UTILITIES", "2025/01/03", "", "Pending", "Supported", "", "
This utility will be used to do a db cleanup of
Boston's production system.", "", "ORY618F", ""], ["7509", "GIVE THIS DBIA A BETTER NAME THAN DBIA7509", "", "", "2025/01/16", "", "Pending", "", "", "", "", "", ""], ["7510", "GIVE THIS DBIA A BETTER NAME THAN DBIA7510", "", "", "2025/01/16", "", "Pending", "", "", "", "", "", ""], ["7511", "IAM AUTHORIZED REMOTE APPLICATION INTERFACE", "Remote Procedure", "KERNEL", "2025/01/16", "", "Pending", "Private", "", "
This ICR supports control and security for remote
applications accessing VistA systems, ensuring that they are approved and
authorized by the VistA Review Board and managed by Identity and Access
Management (IAM) Service.", "", "", ""], ["7512", "GIVE THIS DBIA A BETTER NAME THAN DBIA7512", "", "", "2025/01/16", "", "Pending", "", "", "", "", "", ""], ["7513", "RADIOLOGY ORDER INFORMATION (READ ONLY)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2025/01/16", "", "Active", "Controlled Subscription", "75.1", "
This file contains the Radiology order information.
This is different and contains information not found in the Order file (#100).\n
Read only from file 75.1", "", "", ""], ["7514", "RADIOLOGY ORDER INFORMATION (WRITE)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2025/01/16", "", "Pending", "Controlled Subscription", "75.1", "", "", "", ""], ["7515", "RADIOLOGY PATIENT FILE (READ)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2025/01/16", "", "Active", "Controlled Subscription", "70", "\n
RADPT file #70, is the RAD/NUC MED Patient file. In order to interface
the VistA Radiology system with any external system, it is necessary
to be able to read from to this file.", "", "", ""], ["7516", "RADIOLOGY PATIENT FILE (WRITE)", "File", "RADIOLOGY/NUCLEAR MEDICINE", "2025/01/16", "", "Pending", "Controlled Subscription", "70", "", "", "", ""], ["7517", "GMPLSPECAUTH SPECAUTHDEF", "Remote Procedure", "PROBLEM LIST", "2025/02/24", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call this remote procedure to receive a Problem's Special Authorities rules
and values.", "GMPLSPECAUTH SPECAUTHDEF", "", "2025/03/12"], ["7518", "GMPLSPECAUTH SAFORPROBLEMS", "Remote Procedure", "PROBLEM LIST", "2025/02/24", "APPROVED", "Active", "Controlled Subscription", "", "
This integration agreement allows subscribing packages
to call this remote procedure to receive a Problem's Special Authority (SA)
user answered values and save to the ORDER file (#100) SPECIAL AUTHORITIES
multiple file (#100.112).\n
REMOTE PROCEDURE: Returns an array with JSON elements string for Special
Authorities (SA).\n
Following are the details of the GMPLSPECAUTH SAFORPROBLEMS:\n
NAME: GMPLSPECAUTH SAFORPROBLEMS TAG: SAFORPROBLEMS
ROUTINE: GMPLSPECAUTH RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Handle RPC calls and retrieves Special Authorities per patient Problem.
INPUT PARAMETER: JSONIN PARAMETER TYPE: LITERAL
REQUIRED: YES SEQUENCE NUMBER: 1
DESCRIPTION:
JSON string passed back for order(s) to save SA answers.\n
JSON elements:
patientId = patient unique numeric DFN
RETURN PARAMETER DESCRIPTION:
JSON return string elements:\n
"success" = was value saved? true/false\n
Example:\n
{
"success": true
}", "", "", "2025/03/12"], ["7519", "PXSPECAUTH SPECAUTHDEF", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2025/02/24", "", "Pending", "Controlled Subscription", "", "
Patch PX*1.0*244 will release a new SPECIAL AUTHORITIES
FILE #(820) and a routine of API calls to retrieve information about all the
special authorities. This Controlled ICR allows subscribers to call these APIs
to retrieve information from the new file.\n
Special Authorities file will define all the previously known as Environmental
Indicators in a file to allow future growth and to help minimize elaborate
software enhancements when needing to add a new authority. This file contains
the business rules behind each authority, e.g. Name, code, disabled,
abbreviation, sequence, default, disabled, visible, Package - disabled?,
Linked authority behavior rules, Linked Authority, When value is, Actions to
take.\n
See individual Component Entry for description and examples of call and
returned results.", "", "", ""], ["7520", "RADIOLOGY EXAM ORDER API", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2025/02/27", "", "Pending", "Controlled Subscription", "", "
This ICR provides APIs for the Radiology exam process.
It includes logic to create a new order, register an exam and complete the
exam.", "", "RAMAGRP1", ""], ["7521", "CONSULT PROCEDURE ORDER", "File", "CONSULT/REQUEST TRACKING", "2025/03/11", "", "Active", "Controlled Subscription", "123", "
Provide access to the order information in
REQUEST/CONSULTATION File #123.", "", "", ""], ["7522", "RADIOLOGY EXAM STATUS REQUIREMENTS", "Routine", "RADIOLOGY/NUCLEAR MEDICINE", "2025/03/12", "", "Active", "Controlled Subscription", "", "
This ICR provides APIs for the Radiology exam process.
It includes logic to register an exam, create a new order, register an exam,
and complete the exam.", "", "RAMAGRP2", ""], ["7523", "CLINICAL REMINDER TEXT UTILITY API FOR TEXT WITH OBJECTS", "Routine", "CLINICAL REMINDERS", "2025/03/17", "APPROVED", "Active", "Private", "", "
OE/RR request the ability to display word processing
field that contains a TIU Patient Data Object in a formatted output.", "", "PXRMFNFT", "2025/03/17"], ["7524", "PDM ACCESS FOR PGX ORDER CHECKS VIA CPRS", "Routine", "PHARMACY DATA MANAGEMENT", "2025/03/17", "APPROVED", "Active", "Private", "", "
With the implementation of Pharmacogenomic (PGx) order
checks in MOCHA 3.0, the Computerized Patient Record System (CPRS) will use
this API to retrieve PGx order check data from both the Health Data Repository
(HDR) and First Data Bank (FDB) during the medication order entry process
using a specified internal entry number (IEN) from the DRUG (#50) file for a
selected patient.", "", "PSSPGXOR", "2025/03/20"], ["7525", "ACCESS TO VETERAN THIRD PARTY CHARGE REPORT", "Other", "INTEGRATED BILLING", "2025/03/18", "APPROVED", "Active", "Private", "", "
Allow access to the Veteran Third Party Charge Report
[IB TP VETERAN CHRG RPT].", "", "", "2025/03/20"], ["7526", "PGX GENETIC TEST RESULTS FROM HDR FOR PGX ORDER CHECKS", "Routine", "PHARMACY DATA MANAGEMENT", "2025/03/19", "APPROVED", "Active", "Private", "", "
Pharmacogenomics findings for Inpatient Medications,
Outpatient Pharmacy, and Order Entry/Results Reporting (CPRS).\n
For full input and output details, see the VistA to MOCHA Version 3.0
Interface Document, located under the "Pharm: Data Management (PDM)" section
within the "Clinical" section of the VA Software Document Library (VDL).", "", "PSSPGX", "2025/04/21"], ["7527", "PSO MED ORDER PROFILE FOR PGX SUPPRESSION", "Routine", "OUTPATIENT PHARMACY", "2025/03/19", "APPROVED", "Active", "Private", "", "
Builds a profile of an Outpatient's medication orders
to be used for PGx Order Checks suppression logic.", "", "PSOOCPGX", "2025/04/21"], ["7528", "NATURE OF ORDER FILE ACCESS", "File", "ORDER ENTRY/RESULTS REPORTING", "2025/03/24", "", "Pending", "Private", "100.02", "
sSTEST4S Test 3 TEST 4 This a test", "", "", ""], ["7529", "NATURE OF ORDER FILE ACCESS", "File", "ORDER ENTRY/RESULTS REPORTING", "2025/03/24", "", "Pending", "Private", "100.02", "
Retrieves all data in global ORD(100.02 or Fileman
100.02 custodial package ORDER ENTRY/RESULTS REPORTING via VETRANS DATA
INTERGRATION AND FEDERATION VDI", "", "", ""], ["7530", "Add New Disability Conditions", "File", "SCHEDULING", "2025/03/25", "APPROVED", "Active", "Private", "31", "
This ICR allows new diagnosis codes (DX CODE) and NAME
fields to be added to the Disability Condition (#31) file. Implementation of
patch DG*5.3*1138, provides a mechanism to update the Disability Conditions
(#31) file. When disability conditions (NAME and DX CODE) are encountered
while parsing inbound HL7 messages, but the codes are missing from the
Disability Conditions (#31) file, then Registration is authorized to add those
disability conditions and diagnosis codes to the Disability Conditions (#31)
file.", "", "", "2025/03/25"], ["7531", "Private", "File", "ORDER ENTRY/RESULTS REPORTING", "2025/03/26", "", "Pending", "Private", "100.02", "
Retrieves all data in global ORD(100.02 or Fileman
100.02 custodial package ORDER ENTRY/RESULTS REPORTING via VETRANS DATA
INTERGRATION AND FEDERATION VDI", "", "", ""], ["7532", "WITHDRAWN ICR", "", "REGISTRATION", "2025/03/31", "", "Withdrawn", "", "", "", "", "", ""], ["7533", "VCRS", "File", "OUTPATIENT PHARMACY", "2025/03/31", "", "Pending", "Private", "59", "
VDIF API call to retrive all field data from outpatient
site file 59", "", "", ""], ["7534", "OERR VIEW INSTALL VERSION IN FILE 57.23", "File", "NATIONAL DRUG FILE", "2025/04/11", "APPROVED", "Active", "Private", "57.23", "
ORDER ENTRY/RESULTS REPORTING (OERR) wants to access
the INSTALL VERSION (#2) field of the PPS-N UPDATE CONTROL (#57.23) file as
part of its Order Check changes in patch OR*3*630. OERR is adding a new ORDER
CHECK NATIONAL TERM (#860.9) entry to store the VA PRODUCT (#50.68) file
entries containing a Metformin ingredient. To facilitate maintenance of this
National Term entry, OERR wants to automate this process. By utilizing a
scheduled task, OERR wishes to inquire to the INSTALL VERSION of the PPS-N
UPDATE CONTROL file in order to know when updates have occurred in the drug
files and thus OERR can run a process to search for new VA PRODUCT entries
with a Metformin ingredient to add to the National Term.", "", "", "2025/04/11"], ["7535", "Access REQUEST SERVICES file (#123.5)", "File", "CONSULT/REQUEST TRACKING", "2025/04/14", "APPROVED", "Active", "Private", "123.5", "
Effective with patch RMPR*3*217, when a Prosthetics
order is received at a converted VistA from CERNER, the service name is
extracted from the 4th field of the OBR segment (OBR-4) and needs to be
validated against the REQUEST SERVICES file (#123.5).", "", "", "2025/04/21"], ["7536", "Populate REQUEST/CONSULTATION file (#123)", "File", "CONSULT/REQUEST TRACKING", "2025/04/15", "APPROVED", "Active", "Private", "123", "
Patch RMPR*3*217 implements a Prosthetics orders
interface separate from the IFC interface to receive and process orders
entered in Cerner. VistA supports Prosthetics operations on converted sites.
The new interface creates the files used by VistA Prosthetics and its GUI
counterparts (e.g., Advanced Prosthetics Acquisition Tool (APAT)). These
files include the REQUEST/CONSULTATION file.", "", "", "2025/04/30"], ["7537", "GETLSEQ", "Routine", "CLINICAL REMINDERS", "2025/04/15", "APPROVED", "Active", "Private", "", "
Returns a list of sequences that should be updated when
the LINK is applied to the Reminder Dialog.", "", "PXRMDLLB", "2025/04/21"], ["7538", "PROSTHETICS CURRENT STOCK FILE (WRITE ACCESS)", "File", "PROSTHETICS", "2025/04/17", "", "Active", "Controlled Subscription", "661.7", "
This integration agreement allows the PROSTHETICS
VISION 4 SIGHT II read and write access to all fields of the PROSTHETIC
CURRENT STOCK file (#661.7) when creating a Prosthetics Inventory Package
(PIP) stock issue.", "", "", ""], ["7539", "API FOR RMPRPCED", "Routine", "PROSTHETICS", "2025/04/17", "", "Active", "Controlled Subscription", "", "
This ICR supports the ability to process eyeglass
orders.", "", "RMPRPCED", ""], ["7540", "API FOR RMPRPIYF", "Routine", "PROSTHETICS", "2025/04/17", "", "Active", "Controlled Subscription", "", "
This ICR supports the ability to process eyeglass
orders.", "", "RMPRPIYF", ""], ["7541", "Access to the HCPCS INVENTORY FILE #661.4", "File", "PROSTHETICS", "2025/04/17", "", "Active", "Controlled Subscription", "661.4", "
This ICR supports the ability to process eyeglass
orders.", "", "", ""], ["7542", "API FOR RMPRPIFD", "Routine", "PROSTHETICS", "2025/04/17", "", "Active", "Controlled Subscription", "", "
This ICR supports the ability to process eyeglass
orders.", "", "RMPRPIFD", ""], ["7543", "API Call to RMPRCPTU", "Routine", "PROSTHETICS", "2025/04/21", "", "Active", "Controlled Subscription", "", "\n
eyeglass orders.", "", "RMPRCPTU", ""], ["7544", "API FOR RMPRPIYI", "Routine", "PROSTHETICS", "2025/04/22", "", "Active", "Controlled Subscription", "", "
This ICR supports the ability to process eyeglass
orders.", "", "RMPRPIYI", ""], ["7545", "API For RMPR21", "Routine", "PROSTHETICS", "2025/04/25", "", "Active", "Controlled Subscription", "", "
This integration agreement allows PROSTHETICS VISION 4
SIGHT to reference routine RMPR21 with the understanding that usage of the
functionality contained in RMPR21 is not granted.", "", "RMPR21", ""], ["7546", "READ/WRITE DISCHARGED TO CERNER FIELD", "File", "REGISTRATION", "2025/04/22", "APPROVED", "Active", "Private", "2", "", "", "", "2025/04/23"], ["7547", "GENERIC INVENTORY FILE ACCESS", "File", "IFCAP", "2025/04/22", "", "Active", "Controlled Subscription", "445", "
Provides ability to read the GENERIC INVENTORY FILE
#445 to display the Inventory Point.", "", "", ""], ["7548", "Field # 100.2 Mail Exemption", "File", "OUTPATIENT PHARMACY", "2025/04/25", "APPROVED", "Active", "Private", "52", "
Read FM for PRESCRIPTION (#52) FILE Mail Exemption
FIELD 100.2", "", "", "2025/04/25"], ["7549", "XMVSM APIs", "Routine", "MAILMAN", "2025/04/28", "APPROVED", "Active", "Private", "", "
The purpose of this Routine is to provide read-only
APIs returning MailMan operational status.\n
The VistA System Monitor (VSM) will use this data to display this operational
state data in a real-time VistA Operations Dashboard. VSM functionality
consuming these APIs will initially be deployed via patch KMP*4.0*5.", "", "XMVSM", "2025/04/29"], ["7550", "XUVSM APIs", "Routine", "KERNEL", "2025/04/28", "APPROVED", "Active", "Private", "", "
The purpose of this Routine is to provide read-only
APIs returning KERNEL operational states.\n
The VistA System Monitor (VSM) will use this data to display this operational
state data in a real-time VistA Operations Dashboard. VSM functionality
consuming these APIs will initially be deployed via patch KMP*4.0*5.", "", "XUVSM", "2025/04/29"], ["7551", "HLVSM APIs", "Routine", "HEALTH LEVEL SEVEN", "2025/04/28", "APPROVED", "Active", "Private", "", "
The purpose of this routine is to provide read-only
APIs returning HL7 operational status.\n
The VistA System Monitor (VSM) will use this data to display this operational
state data in a real-time VistA Operations Dashboard. VSM functionality
consuming these APIs will initially be deployed via patch KMP*4.0*5.", "", "HLVSM", "2025/04/29"], ["7552", "Error Trap Summary", "File", "KERNEL", "2025/04/28", "APPROVED", "Active", "Private", "3.077", "
The purpose of this ICR is to provide error trap
summary information to the VistA System Monitor. This data will be stored
centrally and be available via Dashboards and by specific request to those
monitoring and managing VistA sites.\n
Functionality within the VistA System Monitor consuming this data will be
released in patch KMP*4.0*5.", "", "", "2025/04/29"], ["7553", "API Call to RMPRD1", "Routine", "PROSTHETICS", "2025/04/30", "", "Active", "Controlled Subscription", "", "
This integration agreement allows access to routine
RMPRD1 to obtain the display date, patient, item, and cost from file 660 for
eyeglass ordering.", "", "RMPRD1", ""], ["7554", "API FOR RMPRPIYY", "Routine", "PROSTHETICS", "2025/05/02", "", "Active", "Controlled Subscription", "", "
This integration agreement allows call PROSTHETICS
routine PORD^RMPRPIYY to provide prompts and barcodes; it will allow users to
get barcodes for eyeglass ordering.", "", "RMPRPIYY", ""], ["7555", "API FOR RMPRPIY1", "Routine", "PROSTHETICS", "2025/05/02", "", "Active", "Controlled Subscription", "", "
This integration agreement allows to call PROSTHETICS
routine HCPCS3^RMPRPIY1 to display HCPCS and inventory information for
eyeglass ordering.", "", "RMPRPIY1", ""], ["7556", "API CALL TO RMPRAINQ", "Routine", "PROSTHETICS", "2025/05/02", "", "Active", "Controlled Subscription", "", "
Access to RMPRAINQ to display vehicle of record
history.", "", "RMPRAINQ", ""], ["7557", "API TO CALL RMPRPAT0", "Routine", "PROSTHETICS", "2025/05/02", "", "Active", "Controlled Subscription", "", "
This integration agreement provides the ability to
display additional demographic data, last movements, clinic enrollments, and
pending appointments for a patient.", "", "RMPRPAT0", ""], ["7558", "API TO CALL RMPRPAT1", "Routine", "PROSTHETICS", "2025/05/02", "", "Active", "Controlled Subscription", "", "
This integration agreement allows calls to the routine
RMPRPAT1.", "", "RMPRPAT1", ""], ["7559", "API TO CALL RMPRPIYK", "Routine", "PROSTHETICS", "2025/05/05", "", "Active", "Controlled Subscription", "", "
This integration agreement allows call PROSTHETICS
routine RMPRPIYK to display an issue from a stock item.", "", "RMPRPIYK", ""], ["7560", "API TO CALL RMPOBIL2", "Routine", "PROSTHETICS", "2025/05/05", "", "Active", "Controlled Subscription", "", "
This ICR provides access to the routine RMPOBIL2 for
Home Oxygen Billing Transaction.", "", "RMPOBIL2", ""], ["7561", "API CALL TO RMPRPAT", "Routine", "PROSTHETICS", "2025/05/05", "", "Active", "Controlled Subscription", "", "
This integration agreement allows a call to routine
RMPRPAT to display the first page of a patient's 2319.", "", "RMPRPAT", ""], ["7562", "API CALL TO RMPRPIYE", "Routine", "PROSTHETICS", "2025/05/05", "", "Active", "Controlled Subscription", "", "
This ICR provides access to the routine RMPRPIYE to
pull inventory information for eyeglass ordering.", "", "RMPRPIYE", ""], ["7563", "API TO CALL RMPRPAT2", "Routine", "PROSTHETICS", "2025/05/05", "", "Active", "Controlled Subscription", "", "
This integration agreement allows a call to PROSTHETICS
routine RMPRPAT2 to populate the Appliance Transaction display of a patient's
10-2319.", "", "RMPRPAT2", ""], ["7564", "API TO CALL RMPRPIU8", "Routine", "PROSTHETICS", "2025/05/06", "", "Active", "Controlled Subscription", "", "
This integration agreement allows call PROSTHETICS
routine RMPRPIU8 to provide the ability to create a Stock Receipt Transaction
when processing eyeglass orders.", "", "RMPRPIU8", ""], ["7565", "API TO CALL RMPRDP", "Routine", "PROSTHETICS", "2025/05/06", "", "Active", "Controlled Subscription", "", "
This integration agreement allows a call routine RMPRDP
to provide access to Record Pickup and Delivery Charges functionality.", "", "RMPRDP", ""], ["7566", "VCRS", "", "PHARMACY DATA MANAGEMENT", "", "", "Withdrawn", "", "", "", "", "", ""], ["7567", "API TO CALL RMPRPAT5", "Routine", "PROSTHETICS", "2025/05/08", "", "Active", "Controlled Subscription", "", "
This integration agreement allows a call to PROSTHETICS
routine RMPRPAT5 to display critical comments and disability codes on the
patient's 10-2319.", "", "RMPRPAT5", ""], ["7568", "API TO CALL RMPRE29", "Routine", "PROSTHETICS", "2025/05/08", "", "Active", "Controlled Subscription", "", "
This integration agreement allows a call to PROSTHETICS
routine RMPRE29 to edit A 2319 entry.", "", "RMPRE29", ""], ["7569", "DATE PATIENT TURNS A SPECIFIC AGE", "Routine", "CLINICAL REMINDERS", "2025/05/15", "APPROVED", "Active", "Private", "", "", "", "PXRMPDEM", "2025/05/15"], ["7570", "Add/Update NKA", "Routine", "ADVERSE REACTION TRACKING", "2025/06/04", "", "Pending", "Supported", "", "
VDIF Custom Writeback Service, VCRS, needs an API to
safely update the Reaction Assessment field in file 120.86 where appropriate.", "", "", ""], ["7571", "DSIV X12 FILE 365.013 ACCESS", "File", "INTEGRATED BILLING", "2025/07/01", "", "Active", "Private", "365.013", "
This agreement allows INSURANCE CAPTURE BUFFER to read
via FileMan fields needed to be displayed in a list to the user as well as
filter out entries which are marked as INACTIVE?.", "", "", ""], ["7572", "INCOMING FILER TASK NUMBERS", "File", "HEALTH LEVEL SEVEN", "2025/07/21", "", "Active", "Private", "869.3", "", "", "", ""], ["7573", "USER Starting Task", "File", "KERNEL", "2025/07/21", "", "Active", "Private", "14.4", "", "", "", ""], ["7574", "Kernel - Add Digital Signature Validation APIs", "Routine", "KERNEL", "2025/07/23", "", "Active", "Supported", "", "
These Kernel APIs validate XML digital signatures.", "", "XUDSIGVALIDATE", ""], ["7575", "GIVE THIS DBIA A BETTER NAME THAN DBIA7575", "", "", "2025/07/23", "", "Pending", "", "", "", "", "", ""], ["7576", "GIVE THIS DBIA A BETTER NAME THAN DBIA7576", "", "", "2025/07/23", "", "Pending", "", "", "", "", "", ""], ["7577", "SPECIAL AUTHORITIES READ VIA CODE FIELD", "File", "PCE PATIENT CARE ENCOUNTER", "2025/08/12", "", "Pending", "Controlled Subscription", "820", "
This integration agreement allows subscribing packages
to lookup entries in the SPECIAL AUTHORITIES file (#820) via the CODE field
(#2) C cross-reference and access certain fields for each entry.", "", "", ""], ["7578", "ORWTPT GETPTEAM", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2025/08/28", "", "Active", "Private", "", "
Function returns members of a PCMM team. The record
number (IEN) from the TEAM (#404.51) file. RETURN PARAMETER DESCRIPTION:
Array of PCMM team members in the format: member id (IEN of #200 file)^member
name", "ORWTPT GETPTEAM", "", ""], ["7579", "ORQPT PTEAMPR", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2025/08/28", "", "Active", "Private", "", "
Function returns a list of PCMM teams for a specific
provider. The provider number from the NEW PERSON (#200) file. Uses DUZ if
not passed in.", "ORQPT PTEAMPR", "", ""], ["7580", "ORQPT PTEAM PATIENTS", "Remote Procedure", "ORDER ENTRY/RESULTS REPORTING", "2025/08/28", "", "Active", "Private", "", "
Function returns an array of patients on a PCMM team.
The record number from the TEAM (#404.51) file.", "ORQPT PTEAM PATIENTS", "", ""], ["7581", "PSORPC", "Remote Procedure", "OUTPATIENT PHARMACY", "2025/08/28", "", "Active", "Private", "", "
This RPC evaluates the passed option parameter to take
the associated action on a given prescription or drug.\n
RPC^PSORPC01(RESULTS,OPTION,P1,P2,P3,P4,P5,P6) RESULTS: Indicates if the
option is allowable on the order or drug. OPTION: PARK, UNPARK, PARKDRG,
PARKORD P1: IEN of Order or Drug P2: Pickup value (Mail, Clinic, Window) P3:
Patient DFN P4: Encounter provider P5: Encounter location P6: <reserved>\n
PARK: Place this prescription in a Parked state. UNPARK: Remove this
prescription from a Parked state. PARKDRG: Check if this drug is unable to be
Parked. PARKORD: Check if the drug associated with a supplied order number is
unable to be Parked.\n\n
PSORPC was introduced via PSO*7.0*441 as part of the CPRS GUI v32b combined
build, CPRS_V32B_COMBINED_BUILD_1_0.KID. At this time, PSORPC was added to the
OR CPRS GUI CHART context option. The need for this ICR was discovered during
ICR review of the OR CPRS GUI CHART context option for CPRS GUI v33CON,
OR*3.0*508.", "PSORPC", "PSORPC01", ""], ["7582", "SPECIAL AUTHORITIES STRUCTURE", "Remote Procedure", "PCE PATIENT CARE ENCOUNTER", "2025/08/29", "", "Pending", "Controlled Subscription", "", "
Patch PX*1.0*244 will release a new SPECIAL AUTHORITIES
FILE #(820) and a routine of API calls to retrieve information about all the
special authorities (previously known as Environmental Indicators). This
Controlled ICR allows subscribers to call these APIs to retrieve information
from the new file.\n
The Special Authorities file allows future growth and to help minimize
elaborate software enhancements when needing to add a new authority. This file
contains the business rules behind each authority, e.g. Name, code, disabled,
abbreviation, sequence, default, disabled, visible, Package - disabled?,
Linked authority behavior rules, Linked Authority, When value is, Actions to
take.\n
See individual Component Entry for description and examples of call and
returned results.", "", "", ""], ["7583", "TIU CAN PRINT WORK/CHART COPY", "Remote Procedure", "TEXT INTEGRATION UTILITIES", "2025/08/29", "", "Pending", "Controlled Subscription", "", "
This RPC evaluates whether a user can print a Document,
and if so, whether the user can print only a Work Copy or may print EITHER a
Work Copy or a Chart Copy. Authorization to print is determined by ASU
Business Rules, and what type of copy by TIU Document Parameter ALLOW CHART
PRINT OUTSIDE MAS. A user is "in MAS" if they are a member of ASU User Class
MEDICAL INFORMATION SECTION.", "TIU CAN PRINT WORK/CHART COPY", "", ""], ["10000", "Classic FileMan API: Date/Time Manipulation", "Routine", "1", "1994/04/08", "APPROVED", "Active", "Supported", "", "
Date and Time manipulation and Number formating.", "", "%DTC", ""], ["10001", "Classic FileMan API: Internal to External Date", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
This entry point takes an internal date in the variable
Y and writes out its external form.", "", "DIO2", ""], ["10002", "Classic FileMan API: Input Template Compilation", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Input template compilation for inproved performance.", "", "DIEZ", ""], ["10003", "Classic FileMan API: Date/Time Input & Conversion", "Routine", "1", "1998/11/13", "APPROVED", "Active", "Supported", "", "
Validate date/time input and convert it to VA FileMan's
conventional internal format:"YYYMMDD.HHMMSS", where: YYY = number of years
since 1700 MM = Month number DD = Day number HH = Hour number MM = Minute
number SS = Seconds number\n", "", "%DT", "2015/09/29"], ["10004", "Classic FileMan API: Data Display", "Routine", "1", "1998/11/16", "APPROVED", "Active", "Supported", "", "
Provides ways to display data from file entries and
ways to convert data from one format to another.", "", "DIQ", ""], ["10005", "Classic FileMan API: Required Variables", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Sets up the required variables of VA FileMan.", "", "DICRW", ""], ["10006", "Classic FileMan API: File Lookup/Add New Entries", "Routine", "1", "1998/11/18", "APPROVED", "Active", "Supported", "", "
Entry point DIC is for general file lookups. Entry
point IX if for a single cross reference lookups.", "", "DIC", ""], ["10007", "Classic FileMan API: Custom Lookup & File Info. Setup", "Routine", "1", "1998/11/18", "APPROVED", "Active", "Supported", "", "
Entry point DO sets up certain file information. Entry
point MIX does multi-index nonstandard order lookup.", "", "DIC1", ""], ["10008", "Classic FileMan API: Entry Display For Lookups", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Displays the list of entries in a file a user can see.", "", "DICQ", ""], ["10009", "Classic FileMan API: Adding New Entries & YES/NO Prompt", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Can be used for adding new entries to a file. Or for
YES/NO prompts.", "", "DICN", ""], ["10010", "Classic FileMan API: Print Data", "Routine", "1", "1995/01/12", "APPROVED", "Active", "Supported", "", "
Use EN1^DIP to print a range of entries, in columnar
format.", "", "DIP", ""], ["10011", "Classic FileMan API: Word Processing", "Routine", "1", "1998/11/16", "APPROVED", "Active", "Supported", "", "
Call ^DIWP to format and (optionally) output any group
of text lines.", "", "DIWP", ""], ["10012", "Classic FileMan API: Form Document Print", "Routine", "1", "1998/11/16", "APPROVED", "Active", "Supported", "", "
Designed to use the contents of a word processing field
as a target document into which data can be inserted at print time.", "", "DIWF", ""], ["10013", "Classic FileMan API: Entry Deletion & File Reindexing", "Routine", "1", "2001/12/04", "APPROVED", "Active", "Supported", "", "
Multiple entry points to support entry deletion and
file reindexing.", "", "DIK", ""], ["10014", "Classic FileMan API: Data Dictionary Deletion", "Routine", "1", "1998/11/16", "APPROVED", "Active", "Supported", "", "
Used to delete a file's data dictionary and its entry
in ^DIC in order to properly update a running system.", "", "DIU2", ""], ["10015", "Classic FileMan API: Data Retrieval", "Routine", "1", "1998/11/16", "APPROVED", "Active", "Supported", "", "
This entry point retrieves data from a file for a
particular entry.", "", "DIQ1", ""], ["10016", "Classic FileMan API: MUMPS Code Validation", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Checks that code conforms to the 1995 ANSI Standard and
is also checked against aspects of VHA's Programming Standards and Conventions
(SAC).", "", "DIM", ""], ["10017", "DD DATE FORMATER", "File", "1", "", "APPROVED", "Active", "Supported", "", "", "", "", ""], ["10018", "Classic FileMan API: Edit Data", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
This routine handles input of selected data elements
for a given file entry.", "", "DIE", ""], ["10019", "Classic FileMan API: Print Template Compilation", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Print templates can be compiled into MUMPS routines.
The purpose of this DIPZ code generation is simply to improve overall system
throughput.", "", "DIPZ", ""], ["10020", "Classic FileMan API: Print/Sort Template Display", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "", "", "DIPT", ""], ["10021", "Classic FileMan API: Data Dictionary Listing", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Print/display a file's data dictionary listing.", "", "DID", ""], ["10022", "Classic FileMan API: Array Moving", "Routine", "1", "1998/11/13", "APPROVED", "Active", "Supported", "", "
This entry point can be used to move arrays from one
location to another. The location can be local or global.", "", "%RCR", ""], ["10023", "Classic FileMan API: User Controlled Editing", "Routine", "1", "1998/11/18", "APPROVED", "Active", "Supported", "", "
Invokes the Enter or Edit File Entries option of VA
FileMan to edit records in a given file, allowing the user to select which
fields to edit.", "", "DIB", ""], ["10024", "Classic FileMan API: Wait Messages", "Routine", "1", "1998/11/18", "APPROVED", "Active", "Supported", "", "
Displays standard wait messages.", "", "DICD", ""], ["10025", "Classic FileMan API: Cross Reference Compilation", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Compiles cross references into MUMPS routines.", "", "DIKZ", ""], ["10026", "Classic FileMan API: Reader", "Routine", "1", "1998/11/20", "APPROVED", "Active", "Supported", "", "
DIR is a general purpose response reader that can be
used to issue a prompt, read input interactively, perform syntax checking on
the input, issue error messages or help text, and return input in a processed
form. Its use is recommended to standardize user dialogue and to eliminate
repetitive coding.", "", "DIR", ""], ["10027", "Classic FileMan API: Search File Entries", "Routine", "1", "1998/11/16", "APPROVED", "Active", "Supported", "", "
Search option for a specified file.", "", "DIS", ""], ["10028", "Classic FileMan API: Text Editing", "Routine", "1", "1994/04/28", "APPROVED", "Active", "Supported", "", "
This routine is used to edit word processing text using
VA FileMan's editors.", "", "DIWE", ""], ["10029", "Classic FileMan API: Output Last Line of Text", "Routine", "1", "1998/11/16", "APPROVED", "Active", "Supported", "", "
Use ^DIWW to output the remaining text left in
^UTILITY($J,"W") by ^DIWP to the current device. The ^DIWW entry point is
designed to be used in conjunction with the ^DIWP entry point.", "", "DIWW", ""], ["10030", "DD VERSION NODE", "File", "1", "", "APPROVED", "Active", "Supported", "", "", "", "", ""], ["10031", "ScreenMan API: Form Processor", "Routine", "1", "1998/11/18", "APPROVED", "Active", "Supported", "", "
You can call this entry point directly from a MUMPS
routine to invoke the specified form.", "", "DDS", ""], ["10032", "Classic FileMan API: File Access Determination", "Routine", "1", "1998/11/13", "APPROVED", "Active", "Supported", "", "
Used to determine if a user has access to a file.", "", "DIAC", ""], ["10033", "Other API: Filegram", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Generates a filegram.", "", "DIFGG", ""], ["10034", "Other API: Filegram", "Routine", "1", "1998/11/17", "APPROVED", "Active", "Supported", "", "
Used to to install filegrams.", "", "DIFG", ""], ["10035", "PATIENT FILE", "File", "REGISTRATION", "2017/09/13", "APPROVED", "Active", "Supported", "2", "
Any nationally released cross-reference on the
supported fields in this Integration Agreement are "open/supported" for direct
global reference (as well as reference through VA FileMan).", "", "", "2023/01/25"], ["10036", "DGPMLOS", "Routine", "REGISTRATION", "1994/03/07", "APPROVED", "Active", "Supported", "", "
Obtain length of stay by admission.", "", "DGPMLOS", ""], ["10037", "DGRPD", "Routine", "REGISTRATION", "1999/11/16", "APPROVED", "Active", "Supported", "", "
Patient Inquiry.", "", "DGRPD", ""], ["10038", "HOLIDAY FILE", "File", "KERNEL", "1994/10/28", "APPROVED", "Active", "Supported", "40.5", "", "", "", ""], ["10039", "WARD LOCATION FILE", "File", "REGISTRATION", "1994/10/28", "APPROVED", "Active", "Supported", "42", "", "", "", "2009/06/29"], ["10040", "HOSPITAL LOCATION FILE", "File", "SCHEDULING", "", "APPROVED", "Active", "Supported", "44", "", "", "", ""], ["10041", "SDACS", "Routine", "SCHEDULING", "2003/04/03", "", "Retired", "Controlled Subscription", "", "", "", "SDACS", ""], ["10042", "SDM", "Routine", "SCHEDULING", "", "APPROVED", "Active", "Supported", "", "", "", "SDM", ""], ["10043", "DRUG FILE", "File", "PHARMACY DATA MANAGEMENT", "2005/06/08", "", "Retired", "Supported", "50", "
This agreement will be retired on 6/1/2006. Please do
not add any additional code that utilizes this Integration Agreement. APIs
have been created that can be used in place of any code needing to make use of
this agreement. These APIs were released with patch PSS*1*91. Documentation
information can be found in the patch description. In addition, any code that
currently utilizes this Integration Agreement must be converted to use the new
API's. If any part of this Integration Agreement cannot be satisfied with the
APIs, please contact the PRE development team mail group at EMAIL GROUP DEV
using Microsoft Outlook.\n
This DBIA retirement only applies to non-pharmacy packages. Pharmacy packages
are still allowed to utilize this agreement past the expiration date of June
1, 2006.", "", "", ""], ["10044", "XUS", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XUS", ""], ["10045", "XUSHSHP", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XUSHSHP", ""], ["10046", "XUWORKDY", "Routine", "KERNEL", "2018/04/05", "APPROVED", "Active", "Supported", "", "
Several extrinsic functions for workdays. To use any
of the XUWORKDY extrinsic functions, you must make sure that the HOLIDAY file
(#40.5) is populated with each year's holidays. This file is distributed
without data. Only enter holidays that fall on weekdays.", "", "XUWORKDY", ""], ["10047", "USER FILE", "File", "KERNEL", "", "APPROVED", "Active", "Supported", "3", "", "", "", ""], ["10048", "PACKAGE FILE", "File", "KERNEL", "1994/10/24", "APPROVED", "Active", "Supported", "9.4", "", "", "", ""], ["10049", "PERSON FILE", "File", "KERNEL", "", "", "Retired", "Supported", "16", "", "", "", ""], ["10050", "XUSESIG", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XUSESIG", ""], ["10051", "XUVERIFY", "Routine", "KERNEL", "2003/07/29", "APPROVED", "Active", "Supported", "", "
Utilities to check access and verify codes.", "", "XUVERIFY", ""], ["10052", "XUSCLEAN", "Routine", "KERNEL", "2011/02/08", "APPROVED", "Active", "Supported", "", "", "", "XUSCLEAN", ""], ["10053", "XUSERNEW", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XUSERNEW", ""], ["10054", "LABORATORY TEST FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "60", "", "", "", ""], ["10055", "TOPOGRAPHY FIELD FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "61", "", "", "", ""], ["10056", "STATE FILE", "File", "KERNEL", "", "APPROVED", "Active", "Supported", "5", "", "", "", ""], ["10057", "COUNTY FILE", "File", "VETERANS ADMINISTRATION", "", "APPROVED", "Active", "Supported", "5.1", "", "", "", ""], ["10058", "ZIP CODE FILE", "File", "VETERANS ADMINISTRATION", "", "APPROVED", "Active", "Supported", "5.11", "", "", "", ""], ["10059", "PROVIDER FILE", "File", "VETERANS ADMINISTRATION", "2003/06/10", "", "Retired", "Supported", "6", "", "", "", ""], ["10060", "NEW PERSON FILE", "File", "KERNEL", "2020/11/09", "APPROVED", "Active", "Supported", "200", "
Allows Read access to the NEW PERSON file (#200).
Access is only given to those fields by Kernel. The following range of fields
are owned by other packages and can only be accessed by that package:\n
Fields 12-12.9 for HL7 Nodes/X-ref 12
Fields 41.97-42 for NPI Nodes/X-ref 'NPI*'
Fields 53-59.9 for Pharmacy Nodes/X-ref 'PS*', 'TPB'
Fields 70-79.9 for Radiology Nodes/X-ref 'RA*'
Fields 100-101.9 for Order Entry Nodes/X-ref 'ORD*', 101
Fields 125-125.9 for Problem List Nodes/X-ref 125
Fields 400-450.9 for IFCAP Nodes/X-ref 400, 450
Fields 500-500.9 for Mailman Nodes/X-ref 'XM*', 'AXM*', 500
Fields 654-654.9 for Social Work Nodes/X-ref 'SW*', 654
Fields 720-725 for DSSM Nodes/X-ref 'EC*', 'AEC*'
Fields 740-749.9 for QA Nodes/X-ref 'QA*'
Fields 910-910.9.9 for Police Nodes/X-ref 'ESP'", "", "", ""], ["10061", "VADPT", "Routine", "REGISTRATION", "1994/03/07", "APPROVED", "Active", "Supported", "", "
VADPT is a utility routine designed to provide a
central point where a programmer can obtain information concerning a patient's
record. Supported entry points are provided which will return demographics,
inpatient status, eligibility information, etc.\n
Access to patient information is not limited to using the supported entry
points in VADPT. Integration agreements can be established through the DBA
between REGISTRATION and other packages to reference information.\n
This integration agreement does not document the input and output variables
for any of the components of VADPT except SVC. That documentation is located
in the PIMS technical manual, section 12.2 CALLABLE ENTRY POINTS IN VADPT.\n
Revision History:
7/18/24: Added VASV(16) and VASV(17) variables to the SVC component,
effective with DG*5.3*1121.
3/26/24: Added "; otherwise a ^UNKNOWN is returned)" to the end of
VASV(15).
8/23/24: Effective with DG*5.3*1121, changed the variable help text for
the VAHOW Variable. Included additional examples of how the data
will be returned when VAHOW is set to 1.", "", "VADPT", "2024/08/26"], ["10062", "VADPT6", "Routine", "VETERANS ADMINISTRATION", "", "APPROVED", "Active", "Supported", "", "", "", "VADPT6", ""], ["10063", "%ZTLOAD", "Routine", "KERNEL", "1998/04/20", "APPROVED", "Active", "Supported", "", "
This routine provides several API's into a task.", "", "%ZTLOAD", "2009/07/08"], ["10064", "PROGRAMMER API", "Routine", "MAILMAN", "1995/01/31", "APPROVED", "Active", "Supported", "", "
^XM contains these programmer entry points:\n
^XM is the normal routine programmers invoke to use MailMan directly. No menu
item leads to ^XM. KILL^XUSCLEAN is invoked so only basic Kernel parameters
survive call.\n
EN^XM is the entry action for the top-level interactive MailMan option. It
invokes INIT^XMVVITAE to set up the user's MailMan environment. It invokes
HEADER^XM to greet the user and inform the user of new messages. It is
normally used only in top-level options; other types of uses should invoke the
individual entry points directly.\n
CHECKIN^XM is the entry action for subordinate interactive MailMan options.\n
CHECKOUT^XM is the exit action for all interactive MailMan options.\n
HEADER^XM greets the user and informs of new messages.\n
KILL^XM kills MailMan variables.\n
$$NU^XM Returns the number of new messages a user has and may display the
message: "You have # new messages."\n
N1^XM and NEW^XM create a mailbox for a user.", "", "XM", ""], ["10065", "DELETE/SAVE MESSAGE API", "Routine", "MAILMAN", "1995/01/31", "APPROVED", "Active", "Supported", "", "
These APIs let you delete a message from a basket
and/or save it to a basket:
- KL^XMA1B delete a message from a basket (presumes S2 used later)
- KLQ^XMA1B delete a message from a basket and put it in .5=WASTE
- S2^XMA1B save a message to a basket", "", "XMA1B", ""], ["10066", "CREATE A MESSAGE STUB API", "Routine", "MAILMAN", "1994/11/02", "APPROVED", "Active", "Supported", "", "
The API in this routine is the first step in sending a
message, when the message text will be loaded directly into the mail global by
the calling application (rather than being copied from a temporary "build
site" as with ^XMD).\n
This first step is to create a message stub, which is an entry in the Message
file (3.9), with no text or recipients.\n
The next step is to add the text into the text field of the message (DBIA
10113).\n
Optionally, the next step is to set any special handling fields:
S DIE=3.9,DA=XMZ,DR="<field #>////<value>" D ^DIE\n
Field # Value Causes message to be
------- ----- --------------------
1.7 P Priority
1.95 y Closed
1.96 y Confidential
1.97 y Information only\n
Example: To force message 100213 to be priority and closed:
S DIE=3.9,DA=100213,DR="1.7////P;1.95////y" D ^DIE\n
The final step is to address and send the message, using ENT1^XMD or ENT2^XMD
(DBIA 10070).", "", "XMA2", ""], ["10067", "ADDRESSING API", "Routine", "MAILMAN", "1995/02/07", "APPROVED", "Active", "Supported", "", "
This routine has four APIs to perform address lookup.
They are generally used to address messages and bulletins. Compare them to
TOWHOM^XMXAPI (DBIA 2729) and TOWHOM^XMXAPIU (DBIA 2774).\n
DEST^XMA21 Perform an interactive recipient lookup showing XMDUN
as the default for the FIRST recipient\n
DES^XMA21 Perform an interactive recipient lookup showing XMMG
as the default for the NEXT recipient\n
WHO^XMA21 Perform a non-interactive recipient lookup if X is a
local name or network address.\n
INST^XMA21 Same as WHO^XMA21.\n
This one has nothing to do with addressing:\n
CHK^XMA21 Check to see if a user is a member of a mail group.", "", "XMA21", ""], ["10068", "START BACKGROUND DELIVERY TASK", "Routine", "MAILMAN", "1995/02/07", "APPROVED", "Active", "Supported", "", "
This routine starts the background mail filer for local
mail delivery.", "", "XMADGO", ""], ["10069", "SEND A BULLETIN API", "Routine", "MAILMAN", "1995/02/08", "APPROVED", "Active", "Supported", "", "
This API sends bulletins and has the following entry
points:\n
^XMB - Create and send a bulletin in the background (task).
EN^XMB - Create and send a bulletin in the foreground (while you wait).
BULL^XMB - Interactively select a bulletin, define its parameters,
and send it.\n
See the MailMan Programmer Manual, Appendix D, Setting up Bulletins, for
information on bulletins, how to set them up, and how to create a bulletin
cross reference.", "", "XMB", ""], ["10070", "SEND / FORWARD A MESSAGE API", "Routine", "MAILMAN", "1995/02/19", "APPROVED", "Active", "Supported", "", "
Contains the following APIs related to creating,
sending, and/or forwarding messages:\n
^XMD create, address, and send a message
EN1^XMD add text to a message, address it, and send it
ENL^XMD add text to a message
ENT^XMD interactive create, address, and send a message
ENT1^XMD forward a message
ENT2^XMD forward a message and prompt user for more recipients\n
See the MailMan Programmer Manual, Appendix B, Efficient Use of the API, for
some suggestions on how to efficiently create huge messages used for data
transfer.\n
I/O variables for the various APIs:\n
DUZ (in, optional) User's DUZ. This is who is actually sending the
message. If DUZ is not defined, it defaults to the Postmaster (.5).\n
XMDUZ (in, optional) User's DUZ or free text. This is from whom the message
will appear to be. If it is not defined, it defaults to DUZ. If it is free
text, it must not be more than 70 characters.\n
XMSUB (in) Subject of the message. Must be from 3 to 65 characters long.
If it is less than 3 characters, then "..." will be appended to it. If it is
more than 65 characters, it will be truncated.\n
XMTEXT (in) The root of the array, in open format, which contains the text of
the message. The array may be a local or global variable, and it must be in a
format acceptable to FileMan word-processing APIs.\n
XMSTRIP (in, optional) Characters that should be stripped from the text of the
message. Default is none.\n
XMDF (in, optional) If $D(XMDF), addressing restrictions are waived:
- ignore 'domain closed'
- ignore 'keys required for domain'
- ignore 'may not forward to domain'
- ignore 'may not forward priority mail to mail groups'
- ignore 'message length restrictions to remote addressees'\n
XMMG (in, optional) If XMY is not supplied and the process is not queued,
XMMG may be used as the default for the first 'send to:' prompt.
(out) Contains an error message if an error occurs. Otherwise,
undefined.\n
XMZ (in) Message IEN in MESSAGE file (3.9) of message to be forwarded or
altered.
(out) Message IEN in Message file (3.9) of message created/sent.\n
XMY( (in) Addressee array. May contain any of the following:
User's DUZ, or enough of user's name for a positive ID
eg: XMY(1301)="" or XMY("lastname,firs")=""
G.group name (enough for positive ID)
eg: XMY("G.MY GROUP")=""
S.server name (enough for positive ID)
eg: XMY("S.YOUR SERVER OPTION")=""
D.device name (enough for positive ID)
eg: XMY("D.MY PRINTER")=""\n
You may prefix each addressee (except devices and servers) by:
I: for 'information only' recipient (may not reply)
eg: XMY("I:1301")="" or XMY("I:lastname,firs")=""
C: for 'copy' recipient (not expected to reply)
eg: XMY("C:1301")="" or XMY("C:lastname,firs")=""
L@datetime: for when (in future) to send to this recipient (datetime may be
anything accepted by FileMan)
eg: XMY("L@25 DEC@0500:1301")="" or XMY("L@1 JAN:lastname,firs")=""
or XMY("L@2981225.05:1301")=""
(may combine IL@datetime: or CL@datetime:)\n
To delete recipient, prefix with -
eg: XMY(-1301)="" or XMY("-lastname,firs")=""\n
Append "@<sitename>" for any addressees at another site:
eg: XMY("I:G.group@site.DNS")=""
or XMY("lastname,firs@site.DNS")=""
or XMY("6102@site.DNS")=""\n
If the sender (XMDUZ) is a recipient, you may specify the basket in the
sender's mailbox to which the message should be delivered.
eg: XMY(XMDUZ,0)=5 (basket IEN)
or XMY(XMDUZ,0)="MY BASKET" (full basket name)\n
If SHARED,MAIL is a recipient, you may specify the basket in SHARED,MAIL's
mailbox to which the message should be delivered.
eg: XMY(.6,0)=5 (basket IEN)
or XMY(.6,0)="MY BASKET" (full basket name)\n
If SHARED,MAIL is a recipient, you may specify the date on which the message
should be deleted from SHARED,MAIL's mailbox,
eg: XMY(.6,"D")=<date> (any date recognized by FileMan)\n
Sample XMY entries:\n
XMY("USER,LOCAL")="" Addressed to a local user, whose name is
USER,LOCAL.\n
XMY("G.MAIL_GROUP)="" Addressed to a local mail group, whose name is in
the MAIL GROUP file.\n
XMY("LAST,FIRST@domain_name")="" Addressed to a user, at the site named
domain_name. LAST,FIRST must be in the NEW PERSON file at that site. If the
local system domain name is domain_name, it will be a local recipient.\n
XMY("G.MAIL_GROUP@domain_name")="" Addressed to a mail group, at the
site named domain_name. MAIL_GROUP must be found in the MAIL GROUP file at
that site.\n
XMY("D.DEVICE@domain_name")="" Addressed to a device, at the site named
domain_name. DEVICE must be found in the DEVICE file at that site.\n
XMY("S.OPTION@domain_name")="" Addressed to an option, at the site
named domain_name. OPTION must be found in the OPTION file at that site.\n
XMY("INFO:MAIL_GROUP@domain_name")="" Addressed to a mail group at a
remote site. The message will be delivered "information only" to that group,
meaning that they will not be able to reply to it.", "", "XMD", ""], ["10071", "GLOBAL PACKMAN MESSAGE API", "Routine", "MAILMAN", "1995/02/19", "APPROVED", "Active", "Supported", "", "
This routine contains the following API:\n
ENT^XMPG - Create and send a PackMan message with globals", "", "XMPG", ""], ["10072", "SERVER MESSAGE API", "Routine", "MAILMAN", "1995/02/06", "APPROVED", "Active", "Supported", "", "
This API deals with server messages:
- REMSBMSG^XMA1C remove a message from a server basket
- SETSB^XMA1C put a message into a server basket\n
Server messages are usually placed in one of the Postmaster's server baskets
(using SETSB^XMA1C) upon receipt of the message, and deleted from the basket
(using REMSBMSG^XMA1C) upon successful processing of the message by the
application to which the server belongs. See the Kernel Systems Manual for
more information on servers.", "", "XMA1C", ""], ["10073", "MAILMAN: Message Body Access, including Servers", "Routine", "MAILMAN", "1995/02/19", "APPROVED", "Active", "Supported", "", "
^XMS3 contains the following application programmer
entry point:\n
REC^XMS3 to obtain the next line in a message", "", "XMS3", ""], ["10074", "XQH", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XQH", ""], ["10075", "OPTION FILE", "File", "KERNEL", "2011/03/01", "APPROVED", "Active", "Supported", "19", "", "", "", "2011/03/01"], ["10076", "XUSEC GLOBAL", "File", "KERNEL", "1994/12/08", "APPROVED", "Active", "Supported", "200", "", "", "", ""], ["10077", "XQ92", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XQ92", ""], ["10078", "XQCHK", "Routine", "KERNEL", "1999/02/03", "APPROVED", "Active", "Supported", "", "", "", "XQCHK", ""], ["10079", "XQDATE", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XQDATE", ""], ["10080", "XQH4", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XQH4", ""], ["10081", "XQALERT", "Routine", "KERNEL", "1999/12/08", "APPROVED", "Active", "Supported", "", "", "", "XQALERT", ""], ["10082", "ICD DIAGNOSIS FILE", "File", "DRG GROUPER", "1996/08/07", "", "Retired", "Supported", "80", "
This will enable access to all fields on the 0-node,
and the description of the ICD Diagnosis codes.\n
Read access is permitted via FileMan and Direct Reads. The entire 0-node of
the ^ICD9(D0 may be read into a local variable.\n
Also, the "BA" cross-reference on field .01 may be used to find the code
reference.\n
Direct read of the "ACT" cross-reference will also be permitted.", "", "", ""], ["10083", "ICD OPERATION/PROCEDURE FILE", "File", "DRG GROUPER", "1996/08/07", "", "Retired", "Supported", "80.1", "
This will enable users to read the 0- and 1- nodes
directly, reading the main fields of the ICD OPERATION/PROCEDURE FILE. The
0-node may be read in its entirety into a local variable. The fields may be
accessed by direct reads of the global, or by FileMan reads.\n
Also, the "BA" cross-reference may be used to find the code reference.\n
Direct read of the "ACT" cross-reference will also be permitted.", "", "", ""], ["10084", "CPT FILE", "File", "CPT/HCPCS CODES", "2003/04/01", "", "Retired", "Supported", "81", "\n
***Note: This reference has been replaced by the Supported calls
*** found in DBIAs 1995, 1996, 1997.\n
*** THIS WILL BE INACTIVATED AS OF 6/1/2000, AND SHOULD NOT BE USED.
*** ALL DIRECT REFERENCES TO THE CPT (#81) FILE MUST BE REPLACED
*** WITH THE SUPPORTED CALLS NOTED ABOVE.\n\n
This will enable users to directly read the 0-node of the CPT file (^ICPT)
into a local variable, for access to all fields therein.\n
Direct reference of the "B" cross-reference will also be permitted.\n
Direct read of the "ACT" cross-reference will also be permitted.\n
In addition, the "D"-nodes may be directly read, for access to the
description.\n
Access is available by direct read or FileMan read, as well as by retrieval of
the 0-node, for CPT information retrieval.\n\n
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n
N O T I C E !!!!!!!!\n
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n
This IA will be retired as of June 2000 ! Use instead: IAs 2815 and 2816", "", "", ""], ["10085", "PRCPUSA", "Routine", "IFCAP", "", "APPROVED", "Active", "Supported", "", "", "", "PRCPUSA", ""], ["10086", "%ZIS", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "%ZIS", ""], ["10087", "%ZIS9", "Routine", "KERNEL", "", "", "Retired", "Supported", "", "", "", "%ZIS9", ""], ["10088", "%ZISS", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "%ZISS", ""], ["10089", "%ZISC", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "%ZISC", ""], ["10090", "INSTITUTION FILE", "File", "KERNEL", "1994/10/24", "APPROVED", "Active", "Supported", "4", "", "", "", ""], ["10091", "MAILMAN SITE PARAMETERS", "File", "MAILMAN", "1999/06/23", "APPROVED", "Active", "Supported", "4.3", "", "", "", ""], ["10092", "Routine", "Routine", "ORDER ENTRY/RESULTS REPORTING", "", "APPROVED", "Active", "Supported", "", "", "", "Routine", ""], ["10093", "SERVICE/SECTION FILE", "File", "KERNEL", "", "APPROVED", "Active", "Supported", "49", "", "", "", ""], ["10094", "XTFN", "Routine", "TOOLKIT", "", "APPROVED", "Active", "Supported", "", "", "", "XTFN", ""], ["10095", "XTKERMIT", "Routine", "TOOLKIT", "", "APPROVED", "Active", "Supported", "", "", "", "XTKERMIT", ""], ["10096", "Z OPERATING SYSTEM FILE", "File", "KERNEL", "", "APPROVED", "Active", "Supported", "", "
All nodes exported by Kernel are useable.", "", "", ""], ["10097", "%ZOSV", "Routine", "KERNEL", "1999/06/29", "APPROVED", "Active", "Supported", "", "
This routine is OS specific, and provides a interface
to OS functions.", "", "%ZOSV", ""], ["10098", "see Veterans Administration", "Other", "NEW PERSON", "", "APPROVED", "Active", "Supported", "", "", "", "", ""], ["10099", "GMRADPT", "Routine", "ADVERSE REACTION TRACKING", "1996/02/08", "APPROVED", "Active", "Supported", "", "
This integration agreement documents a data extract
utility which allows other packages to gather adverse reaction data about a
patient for use in the calling package.", "", "GMRADPT", "2019/05/20"], ["10100", "NATIONAL SERVICE FILE", "File", "EVENT CAPTURE", "", "APPROVED", "Active", "Supported", "730", "", "", "", ""], ["10101", "XQOR", "Routine", "KERNEL", "1994/03/07", "APPROVED", "Active", "Supported", "", "", "", "XQOR", ""], ["10102", "XQORM1", "Routine", "KERNEL", "1994/03/07", "APPROVED", "Active", "Supported", "", "", "", "XQORM1", ""], ["10103", "XLFDT", "Routine", "KERNEL", "2000/11/27", "APPROVED", "Active", "Supported", "", "
Several date/time API's.", "", "XLFDT", ""], ["10104", "XLFSTR", "Routine", "KERNEL", "2001/07/30", "APPROVED", "Active", "Supported", "", "", "", "XLFSTR", ""], ["10105", "XLFMTH", "Routine", "KERNEL", "", "APPROVED", "Active", "Supported", "", "", "", "XLFMTH", ""], ["10106", "HLFNC", "Routine", "HEALTH LEVEL SEVEN", "", "APPROVED", "Active", "Supported", "", "", "", "HLFNC", ""], ["10107", "HLFNC1", "Routine", "HEALTH LEVEL SEVEN", "", "APPROVED", "Active", "Supported", "", "", "", "HLFNC1", ""], ["10108", "HLTF", "Routine", "HEALTH LEVEL SEVEN", "2001/10/05", "APPROVED", "Active", "Supported", "", "", "", "HLTF", ""], ["10109", "HLTRANS", "Routine", "HEALTH LEVEL SEVEN", "", "APPROVED", "Active", "Supported", "", "", "", "HLTRANS", ""], ["10110", "HL7 NON-DHCP APPLICATION PARAMETER", "File", "HEALTH LEVEL SEVEN", "", "APPROVED", "Active", "Supported", "770", "
File 770 may be accessed only during package post
initialization. The creation of new entries must be cleared through the HL7
development team. New entries may be added with a call to FILE^DICN and a
call to IX1^DIK.", "", "", ""], ["10111", "MAILMAN: Maintenance of Mail Groups", "File", "MAILMAN", "1995/01/23", "APPROVED", "Active", "Supported", "3.8", "", "", "", ""], ["10112", "VASITE", "Routine", "REGISTRATION", "1994/03/07", "APPROVED", "Active", "Supported", "", "
See in routine documentation.", "", "VASITE", ""], ["10113", "MAILMAN: Message Text - Direct Entry", "File", "MAILMAN", "1995/02/20", "APPROVED", "Active", "Supported", "3.9", "
Summary\n
Sites complain about the way their machines seems to slow down considerably
when Austin DPC transmissions are created. Large messages may be created in a
more efficient way than is being used by most applications. Since all DHCP
sites are mandated to migrate to Kernel 7.1 by 12/01/93, all applications can
now use this method of creating a message.\n\n
Technical Background\n
The simplest approach is probably the one people are using. It is pretty
straight forward:\n
Load the text of a message into an array
Set a couple of variables
D ^XMD\n
With short messages, this is also fairly efficient if a local array is used.
However, when a large message is built, it usually must be stored in a global
array. Then, MailMan must read it and re-write it. This effectively doubles
the amount of work the system must do to compile the text of the message. The
killing of the temporary global array built to store the data passed to the
MailMan programmer interface eats up additional resources.\n
So why not write the text of the message (the data) directly into the message,
especially now that it is possible and that all the entry points have been
made available and are documented? Examine the examples on the following
lines.
Example\n
The following steps assume that the standard variables already exist in the
partition from either Log-on or because the job is a TaskMan task.\n
Step 1 -- Create a Message with No Text\n
S XMSUB="LARGE DATA TRANSMISSION"; Initialize Subject S XMDUZ="Application
X" ; Sender D GET^XMA2 ; Call Create
Message Module
See Note 1 below! I
XMZ<1 G RETRY ; Abort or retry, if returned value <1\n\n
Step 2 -- Put Text into Message
F L=1:1 S X=$$data^routine Q:X="stop value" S ^XMB(3.9,XMZ,2,L,0)=X
S ^XMB(3.9,XMZ,2,0)="^3.92^"_L_"^"_L_"^"_DT\n\n
Step 3 -- Deliver Message to Recipients\n
S XMDUN="SENDER,LARGEMESSAGE"; A Sender can be free text or you can
; Leave the variable undefined and the
; message will appear to be from the
; user who was logged on. S XMY
("XXX@Q-AUSTIN_'Q'_DOMAIN")="" ; Remote Recipient S XMY(234567)=""
; Individual as a recipient S XMY(234567)="basket name" ; Individual as
a recipient in a basket .
.
.
D ENT^XMD ; Call for MailMan Delivery\n
The message will now be delivered. This may not happen immediately because
the job of delivery the message is passed off to a 'background filer'.\n
------------------------------------------------------------------------\n
Note 1: In versions of MailMan previous to Kernel Version 7, Step 1 may
occasionally fail! The interface, upon failing, will cause the job to halt.
Because some applications require that a message be created as a result of a
background task, a new entry point has been created for Kernel 7 that will not
cause the process to be halted. It will instead pass back to the caller an
indication of success (XMZ>0) or failure (XMZ<1). The use of this new entry
point is illustrated below. IT IS RECOMMENDED that all applications that use
the GET^XMA2entry point migrate to the XMZ^XMA2 entry point unless the
developers (being aware of the potential problem) decide otherwise. If XMZ=-1
condition is not checked, this large message creation technique will stuff
data into ^XMTS(3.9,-1. This may lead to other problems later on!\n\n
Note 2: There is a way to tell MailMan to run silently via remote
domain when ENT1^XMD is called with the XMY("XXX@DOMAIN") set. If the XMCHAN
or ZTQUEUED variables are set, MailMan is usually silent. MailMan is silent
when ZTQUEUED is present because it is a background job. However, DO NOT set
the ZTQUEUED variable yourself! If anyone other than TaskMan ever sets
ZTQUEUED, the whole intent of the variable is lost. Callers to the MailMan
API functions and callable entry points should set XMCHAN to ensure silent
operation. Be sure to kill XMCHAN when completed.", "", "", ""], ["10114", "DEVICE FILE", "File", "KERNEL", "2020/08/04", "", "Under Revision", "Supported", "3.5", "", "", "", ""], ["10115", "LIST MANAGER", "Other", "VETERANS ADMINISTRATION", "", "APPROVED", "Active", "Supported", "", "", "", "LIST MANAGER", ""], ["10116", "VALM1", "Routine", "VETERANS ADMINISTRATION", "2021/09/21", "APPROVED", "Active", "Supported", "", "", "", "VALM1", ""], ["10117", "VALM10", "Routine", "VETERANS ADMINISTRATION", "", "APPROVED", "Active", "Supported", "", "", "", "VALM10", ""], ["10118", "VALM", "Routine", "LIST MANAGER", "", "APPROVED", "Active", "Supported", "", "", "", "VALM", ""], ["10119", "VALM2", "Routine", "VETERANS ADMINISTRATION", "", "APPROVED", "Active", "Supported", "", "", "", "VALM2", ""], ["10120", "VALM4", "Routine", "LIST MANAGER", "", "APPROVED", "Active", "Supported", "", "", "", "VALM4", ""], ["10122", "XTLKKWL", "Routine", "TOOLKIT", "", "APPROVED", "Active", "Supported", "", "", "", "XTLKKWL", ""], ["10123", "CWAD", "Other", "TEXT INTEGRATION UTILITIES", "1994/05/10", "APPROVED", "Active", "Supported", "", "
The following information is from patch GMRP*2.5*22,
which describes how this supported reference is used.\n
A letter from the Regional Director, Western Region, dated January 25, 1994,
subject: Use of Electronic Mail for Patient Flagging System Among VA
Facilities, requested a utility for flagging and disseminating critical
patient information. This patch is to inform all sites that such a mechanism
is available within DHCP. This patch corrects the problem of the (A)llergy
warning being indicated in the CWAD display when the patient has 'No Known
Allergies'. The variable GMRPHOLD (Supported Reference #10123) will now be
supported by Progress Notes. If set, this variable will force the user to
enter a carriage return after the CWAD display. This is designed to be used
when an application clears the screen after a patient lookup.\n
In response to: E3R #3056 dtd Oct 5, 1993
NOIS: PROG DEN CWAD dtd Mar 3, 1994\n
Through the Progress Notes Application, sites are able to implement a warning
system which notifies users of specific patient conditions. The system is
called CWAD. The acronym stands for:\n
"C" RISIS NOTES
CLINICAL "W"ARNINGS
"A"LLERGIES
ADVANCED "D"IRECTIVES\n
To Implement the CWAD Warning System:
************************************
To implement the CWAD alert system, the variable "GMRPEN" must be set as an
Entry Action for a particular option. It may not be appropriate for the CWAD
alerts to be displayed for certain applications. Which options the CWAD is
implemented with is entirely at the sites' discretion. The following example
uses the MAS Registration Menu. This is not to say your site must implement
the CWAD for this option; this is for demonstration purposes only. It will
work with any menu or option your site deems appropriate.\n
D P^DI\n
Select OPTION: 1 ENTER OR EDIT FILE ENTRIES\n
INPUT TO WHAT FILE: OPTION// EDIT WHICH FIELD:ALL//ENTRY ACTION THEN EDIT
FIELD:EXIT ACTION\n
Select OPTION NAME: DG REGISTRATION MENU Registration Menu ENTRY ACTION: S
(GMRPEN,GMRPHOLD)=1 EXIT ACTION: K GMRPEN,GMRPHOLD Select OPTION NAME: Select
OPTION:
>
Once the variable is initialized the Warnings will be displayed upon patient
look-up.\n
Select PATIENT NAME: HOOD,ROBIN 03-04-33 112233444 ACTIVE DUTY\n
C: 07/01/93 11:53
W: 07/11/93 10:57
A: Known allergies
D: 10/09/93 10:18\n
Types of Warnings:
*****************\n
The following are for illustration purposes only.\n
CRISIS CAUTION: Patient may be homicidal.\n
CLINICAL WARNING Patient is HIV positive.\n
ALLERGY/ADVERSE REACTION Allergy/Reaction: Ampicillin\n
ADVANCE DIRECTIVE DO NOT RESUSCITATE: Patient has
Advanced Directive filed in Volume
6 of his medical record.\n
To Enter Warnings into the CWAD System:
**************************************\n
With the exception of Allergies, Warnings are entered directly through the
Progress Notes application.\n
1. In order for a progress note to be recognized as a Warning, the TITLE of a
note must be linked to one of the following notes types.\n
a. CRISIS
b. CLINICAL WARNING
c. ADVANCED DIRECTIVES (IMPLEMENTATION OF)\n
The TITLE narrative is at the discretion of the site. The important thing to
understand is that the TITLE must be tied to one of the above TYPES. TITLES
with the same name as the above TYPES were exported with Progress Notes 2.5
already linked together but since the TITLE file is controlled by the site it
is possible your site may have them configured differently.\n
*NOTE: Allergy information should be entered through the Allergy Tracking
System.\n
2. Once the TITLE is linked with the a warning TYPE, the user may then enter
the Progress Note Option. Using the Entry of Progress Note option, select the
appropriate title and proceed to enter the warning. The note must then be
signed.\n
3. After signature, the note becomes active on the CWAD Warning System.\n
How to Access the CWAD Warnings:
*******************************\n
1. If the user is assigned the Progress Notes User Menu, the Patient Warning
(CWAD) Display option [GMRPNCW] may be accessed from that menu. If the user
is not assigned this menu it may be assigned as a secondary menu option. It
would be convenient to the user to make the synonym CWAD.\n
2. When a Warning(s) is displayed, review of the warning can be done by
entering CWAD at any option select prompt. A review screen will be displayed
from which the user can select the warning(s) they wish to view.\n
After implementation of the CWAD display you may find that the display flashes
by before the user can read it. This can be corrected by setting the variable
GMRPHOLD, in addition to GMRPEN, in the entry action of the desired
menu/option. GMRPHOLD must also be killed in the exit action. WARNING: Do
not arbitrarily set the variable GMRPHOLD in the entry action without first
checking to see if the option clears does clear the screen after the patient
lookup. The user may be inconvenienced with an unecessary carriage return.\n", "", "", ""], ["10130", "MORPHOLOGY FIELD FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "61.1", "", "", "", ""], ["10131", "ETIOLOGY FIELD FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "61.2", "", "", "", ""], ["10132", "FUNCTION FIELD FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "61.3", "", "", "", ""], ["10133", "DISEASE FIELD FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "61.4", "", "", "", ""], ["10134", "PROCEDURE FIELD FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "61.5", "", "", "", ""], ["10135", "OCCUPATION FIELD FILE", "File", "LAB SERVICE", "", "APPROVED", "Active", "Supported", "61.6", "", "", "", ""], ["10136", "HL7 APPLICATION PARAMETER", "File", "HEALTH LEVEL SEVEN", "2025/03/19", "APPROVED", "Active", "Supported", "771", "
The creation of new entries must be cleared through
Technical Integration by sending review materials to icrs@va.gov. New entries
may be exported using KIDS.", "", "", "2025/03/19"], ["10137", "HL7 SEGMENT NAME FILE", "File", "HEALTH LEVEL SEVEN", "", "APPROVED", "Active", "Supported", "771.3", "
File 771.3 may be accessed only during package post
initialization. The creation of new entries must be cleared through the HL7
development team. New entries may be added with a call to FILE^DICN and a
call to IX1^DIK.", "", "", ""], ["10138", "HL7 TRANSMISSION FILE", "File", "HEALTH LEVEL SEVEN", "", "APPROVED", "Active", "Supported", "772", "
Files 770, 771, and 771.3 may be accessed only during
package post initialization. The creation of new entries must be cleared
through the HL7 development team. New entries may be added with a call to
FILE^DICN and a call to IX1^DIK.", "", "", ""], ["10139", "VAFADDR", "Routine", "VETERANS ADMINISTRATION", "1994/03/07", "APPROVED", "Active", "Supported", "", "
See in routine documentation.", "", "VAFADDR", ""], ["10140", "XQORM", "Routine", "KERNEL", "1994/03/07", "APPROVED", "Active", "Supported", "", "", "", "XQORM", ""], ["10141", "XPDUTL", "Routine", "KERNEL", "1994/04/11", "APPROVED", "Active", "Supported", "", "
The routine XPDUTL contains multiple calls to support
the Kernel Installation and Distribution System. All of the calls can only be
used in the context of the KIDS software, during the installation of software,
unless noted differently in the describitions that follow.\n
The following calls can be used anywhere during the install process:
$$VERSION(X) ;X=package name or package namespace
;Returns the current Version number
** This call can be used outside of KIDs **\n
$$VER(X) ;X=Build name from Build file or Install file
;Returns version number\n
$$PKG(X) ;X=Build name from Build file or Install file
;Returns package name\n
$$PATCH(X) ;X=Patch from Install file, (aaaa*nn.nn*nnn)
;Return 1 if patch X was installed, 0 if not installed
** This call can be used outside of KIDs **\n
$$LAST(X,Y,Z) ;X=Package name or namespace, Y=Version (optional, current if
not supplied), Z=1 released patch (optional, last released patch)
;Returns Last Patch and Date applied to a package
;PATCH will include Seq # if a released patch is last
;PATCH #^DATE, ("nnn^yyymmdd" or "nnn Seq #nn^yyymmdd")
;-1 will be returned if either Package or Version do not exist
; or No patches have been applied
** This call can be used outside of KIDs **\n
$$INSTALDT(X,.Y) ;X=Name from Install file, variable passed by reference
;Returns all installs for X in Install file
;Return array in Y, Y=number of records in array
;Y(internal date/time) = TEST # ^ SEQ #
** This call can be used outside of KIDs **\n
The following function can only be used in the Environment Check Routine
$$RTNUP(X,Y) ;X=routine name, Y= 1-delete, 2-skip
;changes the install action of a routine to delete or skip
;Returns 1 if successfull, 0 for failure\n\n
The following calls can be used during the Pre-Install or Post-Install
routines: $$PRODE(XPDN,XPD) ;XPDN=protocol name, XPD=1-enable, 0-disable
;enable/disable protocols
;Returns 1 if successfull, 0 for failure\n
$$OPTDE(XPDN,XPD) ;XPDN=option name, XPD=1-enable, 0-disable
;enable/disable options
;Returns 1 if successfull, 0 for failure\n
MES(X) ;X=message or an array passed by reference
;write message to Install file\n
BMES(X) ;X=message or an array passed by reference
;add blank line before writing message to Install file\n
$$NEWCP(XPD,XPDC,XPDP) ;XPD=check point name, XPDC=call back, XPDP=parameters
;create new check point
;Returns ien of check point, 0 for error\n
$$UPCP(XPD,XPDP) ;XPD=check point name or ien, XPDP=parameters
;update check point
;Returns ien of check point, 0 for error\n
$$COMCP(XPD) ;XPD=check point name or ien
;complete check point
;Returns date/time of completion, 0 for error\n
$$VERCP(XPD) ;XPD=check point name or ien
;verify check point, returns 1=completed, 0=not
;Returns 1 for completed, 0 for not completed, -1 for doesn't exist\n
$$PARCP(XPD,XPDF) ;XPD=check point name or ien, XPDF="PRE" if you want a
;Pre-Install check point while your in the Post-Install routine
;Returns parameters of check point\n
$$CURCP(XPDF) ;XPDF flag - 0=externel, 1=internal
;Returns current check point\n\n", "", "XPDUTL", "2013/05/23"], ["10142", "Classic FileMan API: Loader", "Routine", "1", "1994/04/11", "APPROVED", "Active", "Supported", "", "
Designed as a replacement for simple WRITE statements
in any part of the data dictionary that has a programming 'hook', such as
executable help.", "", "DDIOL", ""], ["10143", "XLFMSMT", "Routine", "TOOLKIT", "1994/04/11", "APPROVED", "Active", "Supported", "", "", "", "XLFMSMT", ""], ["10144", "XLFHYPER", "Routine", "TOOLKIT", "1994/04/11", "APPROVED", "Active", "Supported", "", "", "", "XLFHYPER", ""], ["10145", "IBCNS1", "Routine", "INTEGRATED BILLING", "1994/04/12", "", "Retired", "Supported", "", "", "", "IBCNS1", ""], ["10146", "IBCNS", "Routine", "INTEGRATED BILLING", "1994/04/12", "", "Retired", "Supported", "", "", "", "IBCNS", ""], ["10147", "IBARXEU", "Routine", "INTEGRATED BILLING", "1994/04/12", "APPROVED", "Active", "Supported", "", "", "", "IBARXEU", ""], ["10148", "GMPTU", "Routine", "LEXICON UTILITY", "2004/11/22", "", "Retired", "Supported", "", "", "", "GMPTU", ""], ["10149", "ScreenMan API: Form Utilities", "Routine", "1", "1994/06/24", "APPROVED", "Active", "Supported", "", "
$$GET - This extrinsic function retrieves data from a
data dictionary field. PUT - Stuffs data into form-only fields.", "", "DDSVAL", ""], ["10150", "ScreenMan API: Form Utilities", "Routine", "1", "1994/06/24", "APPROVED", "Active", "Supported", "", "
Help Messages: HLP, MSG; Refresh Screen: REFRESH;
Run-Time Field Status: REQ, UNED Utilities.", "", "DDSUTL", ""], ["10151", "Extract Tool API", "Routine", "1", "1994/06/24", "APPROVED", "Active", "Supported", "", "
The Extract Tool lets you move or copy records from one
VA FileMan file to another; a typical use is to archive records.", "", "DIAXU", ""], ["10152", "DD('ROU')", "File", "1", "1994/12/23", "APPROVED", "Active", "Supported", "", "
^DD("ROU") - the default maximum routine size used by
FileMan when compiling input and print templates, and cross-references.", "", "", ""], ["10153", "MTLU LOOKUPS/FILE MANAGEMENT", "Routine", "TOOLKIT", "1995/01/11", "APPROVED", "Active", "Supported", "", "
Procedure calls for MTLU.", "", "XTLKMGR", ""], ["10154", "DESCRIPTOR BLOCK", "File", "1", "1997/12/17", "APPROVED", "Active", "Supported", "0", "
The 2nd piece of ^DD(filenumber,fieldnumber,0) is used
in the "File Header" piece 2. This may be referenced since no FM APIs exist
yet to return this information.", "", "", ""], ["10155", "SET OF CODES", "File", "1", "1998/02/03", "APPROVED", "Active", "Supported", "0", "
The 3rd piece of ^DD(filenumber,fieldnumber,0) is used
in the call to Y^DIQ. This may be referenced since no FM APIs exist yet to
return this field for input to the supported call Y^DIQ.", "", "", ""], ["10156", "OPTION FILE", "File", "KERNEL", "2006/05/31", "APPROVED", "Active", "Supported", "19", "
Exporting, deleting, updating Options by Namespace via
KIDS is permitted. Linking menu options from other packages requires IAs
between the packages whose options are being "linked".", "", "", ""]]}