-
-
Stream
Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.
-
fhir-server
FHIR server for Metriport - an open-source universal API for healthcare data. (by metriport)
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.
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
-
fhir-data-pipes
A collection of tools for extracting FHIR resources and analytics services on top of that data.
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.
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
-
fasten-onprem
Fasten is an open-source, self-hosted, personal/family electronic medical record aggregator, designed to integrate with 100,000's of insurances/hospitals/clinics
> In the US, this is part of the EHR push, each EHR is supposed to accept any outside application
To be explicit for readers here, outside applications can connect to some EHR systems using SMART on FHIR, but not all (this is what Apple Health supports in their PHR) - and this is separate from HIEs. For reasons OP mentioned, this is impractical for treatment at scale, but is currently the best way to get your health records in your pocket, or to insurance companies, for example.
Fasten is a great OSS project that facilitates this flow for individuals, and I'd suggest you check them out: https://github.com/fastenhealth/fasten-onprem
> getting a hook into the vendor operated HIEs
This is a only part of the equation - for example, one of the biggest networks we connect with is Carequality, and this is more of a framework that's not operated by any vendors. Rather, vendors connect to a shared directory and speak the same language for medical data exchange.
> The evil part of the operation is that now Metriport has proxy access to the data and eventually will get hacked
This just speaks even more volumes to our open source approach - we're not hiding behind obscurity for security.
> and bought by private equity that will sell the data to TransEquirian Insurance Score agencies.
Only if someone wants spend a long time in prison! We can not legally do anything with the data we have proxy access to, except deliver it to the healthcare organizations we work with that are involved with treating the patient - nor would we want to. There are acquisition events with healthcare organizations all the time, and the HIPAA rules protecting the data do not change.
Hopefully you can agree that, especially with us being the only vendor in the space that's open source, there is no evil at play.
-
Best of luck to Metriport. I've worked for years in the healthcare interoperability space and there are still a huge number of unsolved problems impacting cost and patient care.
There actually is a standard for converting C-CDA records to FHIR. It isn't 100% complete but serves as a useful starting point. If you find problems with it you can feed those back into the standards process.
http://hl7.org/fhir/us/ccda/
Microsoft has an open source library which works pretty well and I think implements at least part of that standard, although I haven't used it lately.
https://github.com/microsoft/FHIR-Converter
FHIR also includes unstructured narrative text so it isn't necessarily better than C-CDA in that regard. You'll find that data quality problems come down more to provider systems configuration and charting policies rather than data formats.
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
Related posts
-
Open-source API for integrating with Garmin devices
-
Metriport: Open-source and universal API for health data
-
Show HN: Metriport – Open-source universal API for health data
-
Show HN: Metriport – open-source universal API for health data
-
We just launched an OSS Health Devices API to help developers gain access to their users’ health data from various wearables, RPM devices, and mHealth apps.