This context contains 2 LISTS that introduce new Visimage users to the HBOC/Amisys member and member-span files.  They also introduce our MACROs, Selection Criteria logic, If/Else logic and automatic SORT and SUMMARY options.   Their selection criteria is representative of how to focus on a Member-SPAN record that was in effect on a given date,  perhaps today's date.

This example introduces the information in Code-Detail to new users.  Many of the codes in the database have their description defined in this dataset.  LINKS will always be necessary to obtain these descriptions when starting from other topics.

This example provides a good introduction into the power and flexibility of Visimage's REPORT task.  While LIST is often sufficient for quickly printing and downloading data, REPORT has additional presentation and computing advantages.  This report will do page breaks on PCP Providers, and under each provider you will find the name/address/relationship of each member.  An introduction to GLOBAL Variables, REPORT Variables and their computations are found in this example.

This context uses the !RANGE command to search all service records and list the service providers that had no valid affiliation span record on the date the service was performed.  A second report can then be run to print the span history in an attempt to locate the problem.  This report uses the new macro called valid-affiliation.

This context uses the !RANGE command to search all service records and list the members that had no valid member span record on the date the service was performed.  A second report can then be run to print the span history in an attempt to locate the problem.  This report uses logic similar to MissAff and uses the new macro valid-member-span.

This context expands upon the LIST logic found in the MEMLIST example.  It summarizes each GROUP by the number of members in each of your designated AGE categories. While the LIST logic is powerful and easy to understand, the time to design it and execute is not efficient.  This REPORT example will give you a meaningful introduction into ARRAY VARIABLES.  Once they are understood, they are much faster to implement on your design screen, and will run more efficiently as well.

This context contains two variations of a report pertaining to the multiple TYPES of addresses that a provider might have in his address tables.   In the address topic, you can find mailing address, billing addresses, default addresses etc.  To be able to access ALL types of addresses, we prefer to use a generic (addr-who) link between the provider and the address sets.
Then, using either SORT logic (1^st version) or simple array logic (2^nd version), we 'break out' and identify the TYPES of addresses and position them in an appropriate spot on the report.  The selection criteria reminds us that AFFILIATION and ADDRESS are both spanned sets and so we focus on retrieving only the current span with no voided records.

This context show how to create labels that are destined for an HP spooled printer.  It requires an array logic that can be modified for any number of labels across a page.  This output is appropriate for situations where a large number of labels are required, and to print them at a PC printer would be tedious and time consuming.   It is also appropriate when frequent, redundant mailings are commonplace and to setup Visimage job streams with prompts is much more efficient than mail-merging  and printing files from a PC.

This example not only demonstrates multiple pass reporting with Visimage, but also reveals the power of its computational logic.  In determining if a member has been 'contiguous' between his spans, Visimage will retain the 'YMDEND' date of one record long enough to compare it to the 'YMDEFF' of the subsequent span record.   This can be done in a single pass, but we have added 3 passes to this report. The first pass will build a file of all the members ACTIVE as of a given date.  (Note: If you already have an ACTIVE-MEMBER file, built with Suprtool or other process,  you can skip this pass and make that file the primary topic for your second pass.) The second pass takes that file of active members and determines if they have been contiguous since a specified starting date.  A grace period of 'n' days is part of the contiguous logic.   The report could stop here.  However, in a third pass, we link the contiguous members of the second pass to the ADDRESS file, providing the opportunity to demonstrate a 'link on the fly'.  This pass also uses macros that convert the member's contiguous start-date and end-date into a more meaningful format of  '# Years and  # Months'.

Similar in logic to the Contiguous Membership report, this context determines which members elected (or were forced) to terminate their coverage, and then double checks to ensure they did not return under a different plan within a specified number of 'GRACE' days.  The selection criteria in this context will probably require some analysis as to what determines a 'termed' member, and how your database 'codes' those reasons for termination.  Each site configuration could be different and the logic used for this report may not be correct or sufficient for your particular environment.
Note on the above contexts:   Both the ContigM report (2^nd pass) and the MemTermd report involve passes where the member spans are NOT limited to the one span record which was active on a given date.  These examples show the rare cases when we need to select and analyze a collective history of span information in order to gain more insight into the member's longterm coverage.

The logic in this context serves as an example for all the times when you asked to look for claims which contain a specific piece of information (certain procedure, certain specialist, certain diagnosis etc) and then you asked to go re-evaluate all the OTHER line items on those claims for additional information.   This type of logic requires 'multipass' reporting, because the specific piece of information you must address initially is not usually on every line item in the claim.  So, you run one pass to find the claim numbers with the specific criteria, then, in a second pass you re-open the service lines (for just those claims) and do your additional analysis.   In the ProcSrch context, the goal is to find which claims have BOTH of the procedure groups requested.  If only one procedure group is found, it is of no consequence.  However, if both procedure groups appear on the same claim, it may signal a billing error, an data entry error, or something more critical.

This context has 5 passes (yours may require fewer) that will retrieve all the claim numbers for a given purpose and time, allow you to input the total number of claims needed for the audit, select that number of claims at calculated intervals, and then link the claim back to its service lines and other associated data sets for the specific information an auditor might request.  It is all done in list, and presumes you will put the information in a spreadsheet or other file structure at the conclusion.   It also demonstrates the use of some Vital Soft's more powerful macros.