MyHealtheVet PHR FHIR API - Local Development build (v0.3.5) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
MyHealtheVet acts as a FHIR Server. It receives information from many sources and produces a given set of FHIR Resourrces
Utility Resources
Note that these resources are used purely to provide linkage, they are minimally populated based on the information MHV receives. Often that means all that is populated is an identifier.
support API for current feature where VA prescribed medications are displayed and where online dispensing is avail the veteran can request dispense
Note that this is not defined yet what is the source or goal.
I understand that the interface will be using HL7 v2 feed, and CMOP. I note that VIA does have a schema for a MedicationTO.
I have heard that there are questions on how to best fit the FHIR medication concept domain.
Should support Cerner in the future.
non-VA meds is not in scope
PGHD meds is not in scope
Enforcement of Business rules: Today this is enforced as data comes into the PHR, the data that should not be seen is not persisted. This works as the PHR is refreshed often. But with FHIR server we are persisting, and thus the business rule such as a timeframe to wait before showing the patient would need to be enforced on the FHIR API, not on the data feed.
other
Eventually this same API would support data from Cerner. Thus the same API providing comprehensive data from Vista and/or Cerner where ever it is.
Provenance – track where the data has come from, and if from multiple places track all.
Grahame - Intermediaries White Paper – https://confluence.hl7.org/display/FHIR/Intermediaries+White+Paper
HL7 FAST - Exchange Routing – http://hl7.org/fhir/R4/us/exchange-routing/
unknown (FHIR supports the following topics but unclear if this data exists in PHR)
care plan / care team resources
encounter resources
device resources
goal resources
procedure resources
questionnaire / questionnaireResponse resources
related person resources
service request resources
coverage resources
The use of FHIR AuditEvent should be used to track all uses of the FHIR API. This is a base configuration of the HAPI FHIR Server. See IHE Implementation Guide on the use of Basic Audit Log Patterns
Data input processing
General Pattern
Our FHIR database will assign id value naturally using normal HAPI method (likely UUID)
Our FHIR database will put external identifiers (e.g. Those from the Vista id such as ImmunizationTO.id) into the .identifier element
Our FHIR database should have one Organization resource… or are there multiple?
Our FHIR database will have support resources for common resource types: Patient, Practitioner, Location, etc – a Patient resource for each patient within the database, Location for all locations, and Practitioner for all clinicians (Users) - So that clinical resources can point at these resources as appropriate. For example when an Immunization was given at a specific location, we point at a Location resource with the details. Thus all clinical resources that were associated with that location all point at the one instance of Location. Same for Practitioner (Users), and Patients.
Our FHIR database will have Provenance resource indicating each time a resource is created/updated/deleted. This will aid with the management of data changes and provide linkage back to origination and mapping details.
General Processing of clinical resources
given an id value on the data we are given, we look for the corresponding FHIR Resource with an identifier element equal to that id value. Thus the identifier element within our FHIR database is the linkage to original data id value.
When nothing is found, we create a new instance of that clinical resource and populate it with the data we are given. Populating the .identifier element with the id of the data we were given.
When one item is found, we compare the data we have with the data we were given. If no change, then nothing more is done. If there is a difference, then we update our data.
When creating a new instance, or updating an existing instance, create a Provenance instance to track what was imported, from what, to what, when, and given some detail to indicate the translation used.
Entered-in-Error
Before Production use there must be a permanent solution. The solution needs address some update problems (e.g. entered-in-error). The following are potential candidates
Index-Update-and-Delete: This model:
pulls current FHIR resource .identifier values (use _elementsparameter to limit results to just identifiers, id),
When updating the new VIA feed data, remember the .identifier that were refreshed.
At the end, we can know which .identifier values were not updated. (most of the time there will be no unrefreshed data)
We can delete those that were not updated
– Note: Does not require moving to new HAPI Server.
Index-Update-and-Expunge: This model:
pulls current FHIR resource .identifier values (use _elementsparameter to limit results to just identifiers, id, status),
When updating the new VIA feed data, remember the .identifier that were refreshed.
At the end, we can know which .identifier values were not updated. (most of the time there will be no unrefreshed data)
We can patch those that were not updated, by .id, status to entered-in-error,
– Note: Patch is not supported in our current HAPI server.
Update-and-Expunge: This model is made available with an updated HAPI Server (6.10.0) that has the ability to disable history. However with this version we can’t use Wipe-and-Replace as that will result in new id values being assigned at each refresh. So Update-and-Expunge is designed. Each VIA feed we convert to FHIR and request an update, but the HAPI server is smart enough to notice that nothing changed so it will not update the meta.lastUpdated. So we will add to our update the use of the http://hl7.org/fhir/R4/StructureDefinition/lastSourceSync extension, with todays date/time (now). This will force an update. Thus after we have fully processed the VIA feed, we can then look for entries older than now that are still active. This will most of the time return an empty set, but if it does return resources, we will change them to entered-in-error and update them.
Wipe-and-Replace: Delete the patient’s specific Resource (e.g. delete all the Immunizations for this patient) and write using update current data from the VIA refresh – similar to eVault PHR today. The HAPI server notices an update, by business identifier, of a previously deleted resource, so it brings it back to non-deleted. Thus after a VIA refresh, only current resources are not-deleted. The drawback is that this keeps historic versions, with two versions per refresh, and _lastUpdated is always the refresh time. Also, the ones removed are not marked as entered-in-error. – January 2024, decided to abandon this as the database fills to fast with history, and we don’t need this history
Get VIA updated
Get VDIF to expose their data
Get VDIF to expose their data in FHIR form
Use Lighthouse FHIR, and thus have the 24 hour problem
Use Lighthouse FHIR, and use a hack for short-term data. Where we only add vitals seen in VIA in the last 24 hours (or some timeframe).
Use HDR
Use CDW somehow
new event service? slack #ves-event-bus
track updates, and notice when a VIA update does not include a record we previously had. This would be very expensive and memory intensive. Thus might be something we do only occationally at low compute time.
References
Source of data received from VIA using a SOAP xml schema that might be from one of: