Schedule a demo.
Or call us, (800) 517-3943.
We're here to help!

VSys can accept simple data imported using the Interactive File Importer. VSys can send data out using the Advanced Exporter. And of course there's the Timeclock module for those types of inbound data feeds.

But what happens when you want to do something interesting? Our Scripted Integration Module provides for:

  • Multiple inbound and outbound data feeds.
  • Conditional processing (inbound and outbound) using a scripting language built into the tool itself.
  • Staged imports with delayed processing.
  • Duplicate record detection.
  • Scheduled processing.
  • Multiple data formats possible (Excel, dBase, tab delimited, comma delimited, etc.)
  • User-configurable properties.

Using the Scripted Integration Module, health screenings, background results, training records, etc. can be scheduled and processed between the two systems to keep both up-to-date with a minimum of manual intervention when those system support any type of flat file data transfers.

Note that integration scripts are not designed or intended to be created by clients. The actual import/export feeds are created and tested by the VSys One team and provided in read-only form for use under the agreed-to terms.

Example: Employee Health (OHM)

This system is configured to send qualifying volunteers, both new and existing, to the employee health system for screening. Data from multiple VSys One databases (this is a multi-hospital system, each operating independently) is sent to OHM. In turn, OHM provides consolidated screening information back to VSys, without OHM understanding that the files will be consumed by multiple, independent VSys systems.

Feed 1: Export of volunteers to OHM

Qualifying volunteers are sent to OHM in a comma-delimited text file if they meet certain criteria pertaining to active status. This file contains:

  • Multiple fixed values, e.g. all volunteers are assigned the same department code.
  • An automatically-created ID code specific to this project. That ID code is generated the first time the volunteer is sent to OHM.
  • A secondary ID code that's a function of the first ID code.
  • Only records which do not match the most previously sent values are included. For example a volunteer who's had a property not tracked by OHM such as Group wont be re-sent unless the data that would be sent to OHM is different from the value last sent.

These files are generated once per weekday in the same format with a common naming structure, and consumed by OHM on its own schedule.

Feed 2: Import of records from OHM

Two files are created by OHM with medical data about a volunteer's TB tests/inoculations and flu shots. These files are dropped into a common folder and consumed by VSys on its own schedule.

VSys imports the entirety of each file, staging it for later validation and processing. The processing script then checks each record, and:

  • Records associated with a different VSys database (another hospital) are skipped.
  • The volunteer is looked up based on the special ID code provided to OHM during the initial transfer and later updates. Any record not corresponding to an active volunteer is flagged for exception handling.
  • VSys uses conditional logic to determine if the incoming record represents a valid (compliant) TB or flu record, and updates or creates the associated certification(s) in each volunteer profiles.
  • Updates and exceptions are logged and delivered to the appropriate parties. Any exception records are available for manual handling.

What can we connect for you?