Application for pulling real-time health records from VistA and returning them in a FHIR compliant format.
The Alternate Patient IDs feature supports testing in lower environments. In lower environments it is difficult (impossible) to have a set of patient IDs that work across the different systems, i.e. authentication, VistA, MPI, or Data Query. To enable testing, VFQ's Alternate Patient IDs feature allows a public ID to mapped to a private ID for interacting with VistA.
- Public IDs are known to the caller and systems in the interaction hierarchy before VFQ, such as authentication systems. For example, well known test patient
1011537977V693883
is a good public ID. - Private IDs are know to systems in the interaction hierarchy after VFQ, such as VistA. For example, Lighthouse QA VistA patient
5000000347
is a good private ID.
Here's how it works:
- VFQ is configured to enable Alternate Patient IDs and provide a mapping between public and private IDs. See AlternatePatientIdProperties.
- On each request, VFQ will check to see if the requested patient has been mapped as a Alternate Patient ID. If so, VFQ temporarily swaps the request public patient ID with a mapped private patient ID. The private ID is known to the VistA instances configured for a specific environment, e.g. QA.
- On each response, VFQ checks paging links and Patient references. If a private patient ID is found, it is replaced with a public ID. By separating response processing from request processing, this ensures the IDs emitted are always public regardless of the request. For example, an Observation read request would not have a patient ID as part of the request. However, patient references would still be updated with their public ID equivalents.
For example,
Observation?patient=1011537977V693883
is receivedVPR GET PATIENT DATA
RPC is invoked for patient5000000347
- Links and references in results are modified from
5000000347
to1011537977V693883
AlternatePatientIds
is the interface that allows public and private IDs to be swapped. There are two implementations.DisabledAlternatePatientIds
andMappedAlternatePatientIds
. Upon start up, theAlternatePatientIdConfig
will add oneAlternatePatientIds
implementation to the Spring context based on theAlternatePatientIdsProperties
. TheDisabledAlternatePatientIds
provides a no-op implementation and keeps if/then logic out of the other components.- The
AlternatePatientIdFilter
is an HTTP servlet filter that is applied to FHIR endpoints. It will update theHttpServletRequest
object with a modified patient ID type HTTP parameters, swapping public and private IDs. The HTTP parameters that are eligible for swapping are configured via application properties. - The
R4Bundler
is responsible for producing page links. It must perform the inverse operation of theAlternatePatientIdFilter
to emit page links in terms of public patient IDs. - The
WitnessProtectionAdvice
is responsible for producing resource reference links. Like, theR4Bundler
, it must perform the inverse operation of theAlternatePatientIdFilter
. - The
R4Bundler
andWitnessProtectionAdvice
are invoked in every FHIR response, regardless of the request type and whether theAlternatePatientIdFilter
has participated in the request.
- Execute
src/scripts/make-configs.sh
(requiressecrets.conf
from a team member)
vista-fhir-query-tests
provides the integration test suite that can be ran locally. It will automatically start Mock services.
Some tests are require connectivity to authentication services and can be enabled by setting additional system properties.
Additionally, this secrets can be defined in the file vista-fhir-query-tests/config/secrets.properties
, for example:
access-token=not-used
system-oauth-robot.aud=https://deptva-eval.okta.com/oauth2/1234567890/v1/token
system-oauth-robot.token-url=https://sandbox-api.va.gov/oauth2/health-insurance/v1/token
system-oauth-robot.client-id=1234567890
system-oauth-robot.client-secret=SECRETSECRETIVEGOTASECRET