7.1 Scheduled Job to Build Rollup Data
The installation of the PATS application will set up an Oracle scheduled job named BUILD_ROLLUP_DATA_JOB in the PATS schema of the Oracle database. The job is initially disabled when PATS is installed. The HSI and the VSSC staff (in Austin) will determine the schedule for running this Oracle job to build the data and for running the job at the VSSC to fetch the data from the PATS Oracle database. The job will be run once a week.
This job executes the ROLLUP method from the Package PATS.PKG_ROLLUP_NATL_DATA. This method:
-
Deletes all data from the PATS.PATS_ROLLUP_NATL_DATA table.
-
Selects all entries on the REPORT_OF_CONTACT table that have the ROLLUP_TO_NATL_REPORTS_STATUS flag set to 1, and that have at least one entry from the ROC_ISSUE table referencing the ROC.
-
For each ROC that meets the criteria, creates records on the PATS_ROLLUP_NATL_DATA table.
7.2 VSSC Fetches Rollup Data
Once a week, at a time agreed upon between the HSI and the VSSC (in Austin), a job initiated by the VSSC connects to the PATS database as the PATSROLLUP user. This user has only SELECT access to the PATS_ROLLUP_NATL_ DATA table. The job reads the data and transfers it into the VSSC system to support national reporting. If the password for the PATSROLLUP user is changed, you will need to notify the VSSC.
7.3 Format of Rollup Data Records
The records for a single ROC will be sequenced in the order shown below. There will be at least one of each type of record for every ROC, even if that record contains no data. All fields in each record are separated by a single up-arrow ^, the final field in each record is followed by a single up-arrow ^.
There will be just one ROC record per Report of Contact.
Fields Transferred
|
Format Information
|
Data Type
|
ROC Number
|
New: Station_Number.YYYYNNNNN
|
String (13:16)
|
ROC
|
Literal Value
|
String (3)
|
Date of Contact
|
MMDDYYYY
|
Integer (8 digits)
|
Status
|
O or C (open or closed)
|
Char (1)
|
Resolution Date
|
MMDDYYYY (or null)
|
Integer (8 digits)
|
Fields Transferred
|
Format Information
|
Data Type
|
Treatment Status
|
O (Outpatient), I (Inpatient), E (Long Term Care) or null
|
Char (1)
|
Station Number
|
From SDSADM.STD_INSTITUTION table
|
String (3:7)
|
Days to Resolution
|
Calculated (date_of_contact – date _closed)
|
Integer (between 1-999)
|
VISN Number
|
From SDSADM.STD_INSTITUTION table
|
Integer (between 1-23)
|
Is Clinical Appeal
|
1=true, 0=false
|
Integer (0 or 1)
|
Info Taken By Name
|
Last,First Middle Suffix
|
String (3:60)
|
Congressional Contact
|
|
String (1:30)
|
Was Comp Given
|
1=true, 0=false
|
Integer (1 digit)
|
Comp Name
|
|
String (1:30)
|
7.3.2 Patient Data Records
There will be just one PT record per report of contact.
Fields Transferred
|
Format Information
|
Data Type
|
ROC Number
|
New: Station_Number.YYYYNNNNN
|
String (13:16)
|
PT
|
Literal Value
|
String (2)
|
SSN
|
9 numeric, plus 'P' if pseudo
|
String (9:10)
|
Sex
|
M or F
|
Char (1)
|
DOB
|
MMDDYYYY
|
Integer (8 digits)
|
Period of Service
|
|
String (1:25)
|
Eligibility Status
|
Set to UNK if null
|
String (1:30)
|
Patient ICN
|
Internal Control Number (person identifier)
|
String (1:29)
|
Category
|
Current Means Test when ROC entered
|
String (1:30)
|
Ethnicity
|
|
String (1:30)
|
7.3.3 Issue Multiple Records
There may be more than one ISSC record per report of contact.
Fields Transferred
|
Format Information
|
Data Type
|
ROC Number
|
New: Station_Number.YYYYNNNNN
|
String (13:16)
|
ISSC
|
Literal Value
|
String (4)
|
Issue Code
|
Same as in Patient Rep
|
String (4:5)
|
Issue Category Code
|
First 2 characters of Issue Code
|
String (2)
|
Is Customer Service Standard
|
1=true, 0=false
|
Integer (1)
|
Hospital Location
|
|
String (1:30)
|
Facility Service or Section
|
External Value from PATS
|
String (0:50)
|
7.3.4 Contacting Entity Records
(In Patient Rep this was Contact Made By)
There may be more than one CE record per report of contact.
Fields Transferred
|
Format Information
|
Data Type
|
ROC Number
|
New: Station_Number.YYYYNNNNN
|
String (13:16)
|
CE
|
Literal Value
|
String (2)
|
Contacting Entity
|
RE=Relative
FR=Friend
CO=Congressional
VI=VISN
HQ=Central Office
VO=Veterans Service Organization
AT=Attorney/Legal Guardian/Conservator/Trustee
DI=Director’s Office
ST=Staff – VAMC
OT=Other
VH=VISN/HQ (inactive)
PA=Patient
|
String (2)
|
7.3.5 Method of Contact Records
(In Patient Rep this was Sources of Contact )
There may be more than one MOC record per report of contact.
Fields Transferred
|
Format Information
|
Data Type
|
ROC Number
|
New: Station_Number.YYYYNNNNN
|
String (13:16)
|
MOC
|
Literal Value
|
String (3)
|
Method of Contact
|
P (phone), V (Visit), I (I nternet),
L (letter), S (survey)
|
Char (1)
|
7.3.6 Patient Race Records
There may be more than one RACE record per report of contact.
Fields Transferred
|
Format Information
|
Data Type
|
ROC Number
|
New: Station_Number.YYYYNNNNN
|
String (13:16)
|
RACE
|
Literal Value
|
String (4)
|
Race
|
|
String (1:30)
|
8.0 Troubleshooting PATS Reports
This section covers the following situations:
-
Reports Server fails to generate a report for no apparent reason, or the report server is behaving erratically.
-
A user logs into PATS and is informed that the Reports Server is not available yet it appears to be running; the Windows services and the servers in the console are enabled.
-
A previous instance of a report is missing.
-
After deploying a new report to the Crystal Enterprise repository, verify that the report can be run successfully.
-
The user does not have access to reports in PATS. There are no errors regarding the availability of reports; just the Reports option is not available.
-
The user runs a report and gets results that do not meet the parameter values entered
-
User can generate a report, but most recent data is not showing on the report.
Scenario 1: Reports Server fails to generate a report for no apparent reason or the report server is behaving erratically.
Check
-
Select Start>Control Panel>Administrative tools>Services to verify that all Crystal Reports and Web Intelligence services on the server have a status of started.
-
Log into Central Management Console (CMC) and select the Servers option. Verify that all listed servers have the green arrow () indicating that the server is enabled.
-
In Administrative tools>Services try stopping and restarting the Crystal and Web Intelligence services.
-
In the Central Management Console select the Servers option. Then try disabling and enabling the servers. Select a server by clicking in the Selected box, then click Disable then Enable buttons in the top right part of the screen.
Scenario 2: A user logs into PATS and is informed that the Reports Server is not available yet it appears to be running and the Windows services and the servers in the console are enabled.
Check
-
Log into the Central Management Console. Select the Users option and check that the user appears in the list of users, and that the user is a member of the PATS REPORTS GROUP group.
-
If not, have the user log off the PATS application, then log back on.
Scenario 3: A previous instance of a report is missing. Instance Limits have been set up as described in the Business Objects XI chapter above. If the instance limits are exceeded, the oldest instances of reports are purged automatically. The user may have to re-run the report.
Check
-
You may choose to increase the instance limits in the Central Management Console
-
Or, inform the user that if they want to be sure of saving old copies of reports, they should export them to their own PC.
Scenario 4: After deploying a new report to the Crystal Enterprise repository, verify that the report can be run successfully.
Complete the following tasks:
-
In the Central Management Console, select the newly deployed report.
-
Click the Properties tab and select the Preview option.
-
For each parameter listed in the parameters table set a value for which you know data exists.
-
Click OK to execute the report.
Scenario 5: The user does not have access to reports in PATS. There are no errors regarding the availability of reports, but the reports options do not appear in the main menu of PATS.
Check
-
In order to perform reporting PATS the user must fall into one of three roles: SRCU, NPO or ADUSH.
-
Verify in VistA that the user has one of the roles QACV_SRCU, QACV_NPO or QACV_ADUSH.
-
Check in the CMC to make sure the user exists and has been assigned to the reports group as in Scenario 2.
Scenario 6: The user runs a report and gets results that do not meet the parameter values entered.
Check
-
If default values have been set for the report in the CMC, and no value is selected for a parameter in PATS (for example, running the Employee Contact Totals report leaving the Employee parameter null to get all employees), the default values set in the CMC will be used to generate the report.
-
From the CMC, select the report. From the Process tab, select Parameters. Make sure all of the parameters are set to null (empty). The 508C flag can be set to 0 instead of null.
Scenario 7: User can generate a report, but the data they expected is not showing on the report.
Check
-
Did the user enter the data today? The report data comes from tables whose data is refreshed daily at a time determined by the HSI, so data entered one day will not appear on reports until the following day.
-
Did the user select a Date of Contact date range that was too old? The reports data tables contain data only for the current and previous two fiscal years.
-
Check to see whether the data is in the production tables in the PATS schema, then check to see whether it is in the tables used for reporting in the PATSRPTS schema. If the data is in the reporting tables, first check the user’s input parameters, then see previous scenario.
-
If data is in the production tables but not in the reporting tables, check the scheduled job bld_std_report_data_job to make sure it is still running nightly to refresh the data in the tables that support standard reporting.
-
If data is in the production tables but not in the reporting tables, check the procedure pkg_bld_std_report_data to see whether it needs to be recompiled. If the underlying production data table structures change, this procedure may need to be altered.
-
Check the tables in the PATSRPTS schema. If the structure of the underlying production tables in the PATS schema changes, it is possible that the structure in these tables must also be changed to reflect the new data format.
-
After correcting the problem, you can refresh the data by directly calling the procedure patsrpts.pkg_bld_std_report_data.bldall to refresh the data manually.
-
Monitor the scheduled job for a few days to make sure that the refresh is now working.
Dostları ilə paylaş: |