Skip to main content
Skip table of contents

Integration Hub (iHub)

Intro

The Integration Hub is a collection of existing VA integrations which can be incorporated into products via "widget" or API. We just became aware of it. It offers dozens of APIs into services that we are very interested in surfacing to Veterans, such as appointments, HDR FPDS flags, payment history, enrollment system eligibility info, and dozens more.

Documentation (requires VA network access): https://qacrmdac.np.crm.vrm.vba.va.gov/WebParts/Documentation/Documentation

more background from @charwo here:

ihub basically built an API wrapper on top of a lot of VA backend services (similar to what Vets-api has done). This API wrapper powers the contact center software, so if someone calls and has a question about their upcoming appointment or to change an address or something, the CRM tools the contact center reps have use iHub to get data in and out of back end systems. "Show upcoming appointments" is an API they have and a feature we need

Additional Information

This service is currently only setup in staging and has very little documentation. Development work started on the project, but was blocked at some level bureaucratically. This doc is here for future reference and to doc work that has already started, but not yet completed.

The implementation is in this ticket: https://github.com/department-of-veterans-affairs/vets.gov-team/issues/11588

We only know of one hostname so far: qacrmdac.np.crm.vrm.vba.va.gov

Questions

  • Are these APIs reliable enough to use for a self-service tool? If not, most likely they are not because the underlying VA system they are talking to are not stable / reliable / performant enough.

Suggested approach

Integrate with one new service (appointments?) and present on the dashboard in staging.

Definition of Done

Complete the following discovery

  • [ ] How to determine if an existing service meets our functionality and performance needs

    • What kinds of simplifications would be required when building against this service?

    • Would we need branch logic or conditions?

    • What data is in there beyond what we need (i.e. is it too bloated or complex for what we need)?

    • Is there data we need that's missing?

    • How reliable is it?

    • Are there decent routes available for resolving issues between sources?

  • [ ] How to determine who should create a new service if needed?

    • Is the data underneath changing frequently?

    • For Getting or Posting data, will it have to communicate with more than one system?

    • Is there a lot of logic needed to transform the data into what we need for the product?


JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.