Congrats on the launch. I work in healthtech and I'm always shocked by how fragmented and siloed the technology is in my industry. Both at the application level (EHR) and data level, leading to general inefficiency, high costs and innovation that do not always benefit the patients.
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?
Thank you - glad to see there are others that are aware of the mess of healthcare data!
> 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.
> 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.
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).
more data does not always mean good data. Health systems have varying level of quality and accuracy and in some cases, wrong information affects patient outcomes. The idea of connecting sparse systems has pros and cons.
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.
In more complex cases, diagnosis is as much art as science. There aren't always evidence-based clinical practice guidelines to follow so clinicians often have to rely on experience and intuition. Subjective judgement is a factor.
Under HIPAA, patients do have the legal right to correct errors in their medical records.
they do, culturally. However, data does influence their decisions. Appropriately diagnosis are probability based and is an art. Its not perfect, but currently it is good
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?