MyHealtheVet PHR FHIR API
0.3.5 - trial-use United States of America flag

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

Vista Mapping

Page standards status: Informative

MyHealtheVet acts as a FHIR Server. It receives information from many sources and produces a given set of FHIR Resourrces

sourcefhirutilHDRVIAHL7v2AllergyIntoleranceImmunizationConditionDiagnosticReportVIA-- labHDR-- chem-- hemSpecimen()Observation()DocumentReferenceProgress NoteDischarge SummaryECG ReportImaging ReportObservationBLOOD PRESSUREHEIGHTWEIGHTPULSEPAINRESPIRATIONTEMPERATUREMedicationRequestMedicationDispensePatientMHV PatientPractitionerLocationOrganizationFHIR API
Data flow


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.

mapping Clinical Resources

This section is dedicated to instructions on how MHV will transition the data we receive into FHIR format. The priority order is:

  1. Allergy
  2. Immunization
  3. Notes
  4. Radiology Report
  5. Vitals
  6. Conditions
  7. Chem-Hem
  8. Micro / Path Lab Reports
  9. EKG/ECG - not likely to continue as no longer get useful reports

Allergy

Allergy and Intolerance Mapping Notes

Chem-Hem

Chem-Hem (CH) Diagnostic Report Mapping Notes

Condition

Conditions Mapping Notes

ECG

ECG Mapping Notes

Immunization

Immunization Mapping Notes

LabReport

LabReport including Microbiology and Pathology Mapping Notes

Notes

Notes Mapping Notes

Radiology

Radiology Mapping Notes

Vital-Sign

General Vital-Signs Mapping Notes

in progress

  • Medications
    • See Medication Request notes
    • 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

  1. Our FHIR database will assign id value naturally using normal HAPI method (likely UUID)
  2. Our FHIR database will put external identifiers (e.g. Those from the Vista id such as ImmunizationTO.id) into the .identifier element
  3. Our FHIR database should have one Organization resource… or are there multiple?
  4. 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.
  5. 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

Update mhv-fhir-phrtriggered by API request for a given Patientread data VIA(VPR) and HDRreceive a multiple entry SOAP messagewith current informationlookup Patient byicnto getPatient/idfound?yesnoupdate if neededcreate newmay use MHV-PHR Patient contentconvert dataconvert VIA.idto FHIR.identifierAdd to FHIR Bundlemore data?yesSubmit Transaction Bundle to FHIRFHIR server will match each entry on.identifier and update or create newmore domains?yesnono
General Processing flow


  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. Index-Update-and-Delete: This model:
    1. pulls current FHIR resource .identifier values (use _elements parameter to limit results to just identifiers, id),
    2. When updating the new VIA feed data, remember the .identifier that were refreshed.
    3. At the end, we can know which .identifier values were not updated. (most of the time there will be no unrefreshed data)
    4. We can delete those that were not updated
    5. – Note: Does not require moving to new HAPI Server.
  2. Index-Update-and-Expunge: This model:
    1. pulls current FHIR resource .identifier values (use _elements parameter to limit results to just identifiers, id, status),
    2. When updating the new VIA feed data, remember the .identifier that were refreshed.
    3. At the end, we can know which .identifier values were not updated. (most of the time there will be no unrefreshed data)
    4. We can patch those that were not updated, by .id, status to entered-in-error,
    5. – Note: Patch is not supported in our current HAPI server.
  3. 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.
  4. 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
  5. Get VIA updated
  6. Get VDIF to expose their data
  7. Get VDIF to expose their data in FHIR form
  8. Use Lighthouse FHIR, and thus have the 24 hour problem
  9. 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).
  10. Use HDR
  11. Use CDW somehow
  12. new event service? slack #ves-event-bus
  13. 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:

Vista Model