> Would it make sense to go one step further and bet on the future being the cloud - and start supporting existing cloud solution like Google Healthcare (FHIR) API (and others) as storage layers?
Oh for sure - to clarify, we're open-source, but we definitely have a managed cloud solution. For our backend, we currently self-host the OSS version of HAPI FHIR on AWS: https://github.com/metriport/fhir-server. It works pretty well for our purposes, and we'd prefer to not use a managed solution like the Google FHIR storage for this. Mainly for customizability, control, and to keep things OSS.
With that being said, people using Metriport can store the FHIR data and raw docs coming from our API in whatever solution they wish - including the Google FHIR storage! Everything is standardized to FHIR R4, so syncing to another backend is straightforward.
In fact, a customer of ours recently used this OSS solution to sync Metriport data to their Google cloud: https://github.com/google/fhir-data-pipes
Great. What I was trying to say is that there may be some value for larger customers if your company were building and managing something like it (basically a Fivetran for FHIR).
Consider someone who is misdiagnosed and switching doctors because they can't get the medical staff to believe them. They would be served by a fresh set of data and if re-diagnosed, so be it.
Under HIPAA, patients do have the legal right to correct errors in their medical records.
https://www.hhs.gov/hipaa/for-individuals/medical-records/in...
Glad Metriport is addressing this! I hope you will drive a new level of standardization on an open and modern data exchange protocol.
One question: at the product level, would it make sense to go one step further and bet on the future being the cloud - and start supporting existing cloud solution like Google Healthcare (FHIR) API (and others) as storage layers?