HAPI as persistent storage for FHIR records from external EMR's

[Jason Kulatunga]

Hi,

I'm here on behalf of Fasten Health which an open-source, self-hosted, personal/family electronic medical record aggregator, designed to integrate with 100,000's of insurance companies, healthcare providers and laboratories. It securely connects patient healthcare providers together, creating a personal health record that never leaves the patient's hands without their consent.

We're  considering ripping out Fasten’s direct FHIR processing pipeline and replacing it with a CDR like HAPI, but we have a couple of questions/concerns:

1. Fasten is not the source-of-truth for it’s patient data, so ideally I’m looking for a persistent storage solution that will guarantee that I can retrieve the raw data sent by the healthcare provider — is that possible with HAPI?
2. Building off the previous question, does HAPI have a mechanism for linking together multiple Patient records without merging them together? IE. A user can import their Hospital MyChart records (which has its own Patient ID) and their Clinic Allscripts records (with a different Patient ID), and link them together to their user.

Thanks!

[Blessed Tabvirwa]

Hi there

"... persistent storage solution that will guarantee that I can retrieve the raw data sent by the healthcare provider — is that possible with HAPI?" 

- Yes, 

"...does HAPI have a mechanism for linking together multiple Patient records without merging them together? IE. A user can import their Hospital MyChart records (which has its own Patient ID) and their Clinic Allscripts records (with a different Patient ID), and link them together to their user." 

- Not sure if HAPI has something built-in but I imagine this would be a feature of the FHIR standard i.e. you can use the Patient.identifier for that, however matching records of the same patient from various sources is an interesting problem that requires looking at multiple ways of verifying that is the same patient; thus you may end up having to use more than just Patient.Identifier to group all the various records under one patient. You may benefit from looking into existing health information exchanges to get a sense of how they are currently doing this. Also here are some links that may help:

• https://www.healthit.gov/sites/default/files/page/2019-09/PMAL%20Final%20Report-08162019v2.pdf
  
• https://www.healthit.gov/isa/uscdi-data/patient-social-security-number#:~:text=General%20Comment%3A%20The%20Social%20Security%20Number%20is%20used,of%20the%20FHIR%20Identifier%20data%20type%20of%3A%20http%3A%2F%2Fhl7.org%2Ffhir%2Fsid%2Fus-ssn.
  
• https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7442501/
  
• https://dataladder.com/using-record-linkage-to-resolve-patient-matching-errors/#:~:text=Record%20linkage%20is%20the%20process%20of%20linking%20and,otherwise%20similar%20records%20that%20are%20different%20entities%20altogether. 
  

[Jason Kulatunga]

Hi!

Thanks for the detailed response.

Regarding Q2 ("does HAPI have a mechanism for linking together multiple Patient records without merging them together") I was told to investigate Master Data Management (MDM) and it seems like it should do exactly what we need.

However I was unable to find any information about Q1 ("persistent storage solution that will guarantee that I can retrieve the raw data sent by the healthcare provider"). You answered "yes" it is possible, however I couldn't find any corresponding documentation that mentioned the untouched/raw FHIR data will be available via the API. Could you link me to a reference?

Thanks!

[James Agnew]

I think you would need to define that requirement a bit more before it would be realistic to answer it.

HAPI FHIR's JPA server will by default store exactly what it is sent, and will not modify it in any way. The only exception is that the server won't persist data elements that don't exist in the FHIR standard (e.g. an element named "foo" in the Patient resource would either be ignored or rejected with an error depending on config, but would not be persisted either way. FHIR does not allow undeclared elements outside of the defined extension mechanism.) so unless you have specifically configured the system to make modifications to data before saving, the data won't be modified.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/44c043e2-c4ba-40f7-ba8d-28562696dfcfn%40googlegroups.com.

[Jason Kulatunga]

Straight from the horses mouth! Thanks for confirming James!

Basically one of the promises we'd like to make to our users is that that data in Fasten exactly matches the data provided by their healthcare institution. This guarantee has a number of technical advantages (signature comparison between old/new resources during provider sync, etc) and we're hopeful that we can leverage signatures + Provenance information for trusted patient-contributed data initiatives in the future. 

Thanks again