Launch HN: Medplum (YC S22) – Open-Source Firebase for Healthcare

Sure! Firebase (https://firebase.google.com/) is what’s known as a Backend-as-a-Service platform. Offers a bunch of server-side services (including database storage, authentication, serverless edge functions, and image/media storage, etc.) hosted in the cloud and accessible via API. That way, application developers can focus on the user-facing experience, and use a standard platform for their backend.

Medplum expands on this concept by adding tools specific to digital health, such as a FHIR data schema for interoperability, EHR integration, and SMART App launching for embedding applications inside legacy EHRs

My experience with Firebase. I worked on AWS, Azure, GCloud and Firebase. I feel Firebase is the easiest way to deploy web application. It provides features like Web-hosting, User-Authentication, Cloud-Functions and Database, Storage. Firebase is popular in mobile app world also. User-Auth is the easiest on Firebase.

Imagine you are new to cloud world and you want to deploy production ready web app (not a toy project). With Firebase you can confidently and quickly make the app with little learning. This confident part is very important, with AWS you have to fight with AWS configuration for months, then also you may have doubts.

Firebase is acquired by Google-Cloud but still exists as a separate entity. For every Firebase project there is a behind the scene Google-Cloud project created.

My main complaint is their databases (they have two db's). RealtimeDB(which I believe will be deprecated) and FirestoreDB. FirestoreDB is proprietary and limited in features. For example there is no way to have a auto-increment(which is often used in many applications). The work-around suggested by Firestore auto-increment is very ugly. Direct editing and modifying the data (not programmatically) in FirestoreDB is a pain. There is no official db-query feature, if you have more data (like more than 1000 elements) their webUI to navigate FirestoreDB data is of no use.

Can’t tell if you’re joking…

Since this thread already has a negative response, I'll share my $0.02: this info is readily available in virtually any format you'd desire, and it just comes across tacky to post a question this inconsequential.

I'm going to guess without even looking there are about 100,000 YouTube videos alone on the topic firebase. Medium and substack will have a heap of articles. Firebase has a website.

You're going to be ignored or worse get hate on hn posting long winded questions that could have been a single-term search on Google. It's quite literally a waste of everyone's time, yours included.

If you're looking for a hn flavored description, that's understandable, but again... Single term search would have taken you less time and effort than your post, and you'd already have the answer.

I pose this rhetorical question with love and respect, but why would anyone want to do (extremely trivial) research for you?

Good question. Custom data is tricky. The first thing we always try to do is dig deep into the FHIR spec to see if the data is truly custom, or if there is an existing FHIR representation that will actually work. In many cases, there are good options, and it's nice to work within the spec.

If not, then falling back to extensions is the next logical step. FHIR extensions can be clunky to work with. Our client libraries provide a bunch of helper utilities to make it easier.

In extreme cases, we have created custom FHIR resources via custom StructureDefinition and SearchParameter resources to represent completely unique data elements (examples: https://github.com/medplum/medplum/blob/main/packages/defini...).

Another question that I can't quite figure out from your docs is if your bots functionality works with non-AWS hosting?

That's a great question. Healthcare tech is a big and diverse space, and we are still honing a product description that speaks to all audiences.

Among technical decision makers (Software Engineers, Architects, etc), the Firebase analogy clicks much faster. Among traditional healthcare administrators, "EHR" or "API first EHR" or "Headless EHR" resonate more.

We're definitely open to suggestions!

Thanks for the kind words!

Our goal is to provide a comprehensive experience that spans both front end and back end. In practice, we're focusing on a rock solid server first. At present, our front end components are best used for rapid prototyping and internal tools. Developers who want to create highly custom and pixel perfect designs will probably opt to use their own front end stack.

We do not currently support the StructureMap $transform operation, but we are actively working on it to support conversion to/from CCDA and other FHIR versions.

We have the utmost respect for HAPI, Google Health API, and all other FHIR servers. We believe that they are all contributing to cleaner and more interoperable data.

One key difference between the Medplum server and other FHIR servers is that it is designed to be use as a complete backend, not just a data store. That includes supplemental API endpoints for end-user auth and account management, automation ("Bots" for "if this, then that" style automation). The goal is that a developer should be able to create a complete digital healthcare experience with only a statically hosted website -- no additional servers required. In our experience, HAPI and Google Health API are used more like a database, where you run additional servers in front. We believe that providing a more comprehensive server lowers the barrier to entry, and reduces the maintenance burden for digital health providers.

Looking forward to hearing from you!

Anything that can be done to reduce developers' direct interaction with any EDI-based workflow -- and I was on the X12 standards committee back in the day -- is god's work, as far as I'm concerned. FHIR and SMART on FHIR are huge leaps forward in usability, but it's still asking a hell of a lot of devs to come up to speed on those standards before they can retrieve or update any data at all.

Thanks! We all have our HL7 v2 pipe delimited scar tissue.

Yes it is! As we’ve worked with users, we’ve been continually impressed by how the FHIR spec handles complex real-world use cases. Because of this flexibility, we made the decision to store FHIR natively, rather than roll a custom schema under the hood and convert to FHIR on the fly.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

See also https://news.ycombinator.com/showhn.html, since Launch HNs are a variation of Show HNs.

I understand the cynicism. We do believe that providing a high quality open source offering can contribute to solving the problem.

Good questions. Some thoughts:

1 The features we charge for are usage based. For example on our hosted service the number of FHIR resources and automations (Bot executions) customers use is tiered. We also charge for compliance related features, like a Business Associate Agreement (BAA).

2 I like the paper you linked to and think it is useful. In terms of the interoperability criteria - this looks very similar to the criteria for ONC certification. Though we are not yet certified, we are working on it and you can see some of our documentation here https://www.medplum.com/docs/compliance/onc

3 Community and support is one of our goals as well and yes, we plan to hire team members explicitly focused on community

4 We do target developers, and not practice professionals. There is value in low-code in specific scenarios, but are focused on the developer because the workflows and data structures are complex enough that programming is preferable to, for example, complex configurations. We do not expect that those who develop on top of us will make their code open source.

5 In terms of consolidation - we do think that having data stored in a standard compliant way (FHIR) and available via well-documented API is useful, both for the consolidation scenario and for other interop use cases. We don't have any plans to coordinate with equity groups at present - but that's an interesting idea

Thanks!

We use FHIR R4. For ONC g.10, we are targeting US Core 5.0.1, USCDI v2, SMART App Launch 2.0.0, and Bulk Data 2.0.0.

Lab integrations and ePrescribe are interesting -- in our experience, the complexity is less technical, and more about getting access to the various systems. We work closely with our early customers on these partnerships. Our ultimate goal is to have turnkey integrations, so it's just a matter of entering connection details and credentials.

Awesome, thanks for the pointer. I just added it to our backlog for investigation.

Thanks! It means a lot from someone in the space. There is a ton of duplicated effort out there.

We definitely take input from the community and are interested to hear from teams about which compliance frameworks they would like to see. We also think open source and self-hosting has a role to play here. For example, some countries have data residency requirements, and we hope that developers would start by using Medplum and building additional features/validating their self-hosted environment up to a local compliance standard.

Redox shines in complex multi-party interoperability projects. They have an impressive number of pre-existing integrations with providers and payers. They also provide professional services to navigate last mile connectivity details. If you need to integrate with a 3rd party immediately, then Redox is a great choice.

Medplum has a number of interoperability features: FHIR and HL7 endpoints, and developer tools to store and manipulate the data as needed. But our integrations are more "DIY" and developer focused.

At this point, everything running in production is 100% open source, and we don't have any plans for proprietary code.

At first glance this doesn't appear to be a competitor to Epic. Their customers would be the software vendors who sell products to Epic customers, not Epic customers themselves. Am I wrong about that?

I work for an Epic customer and I'm struggling to envision my organization purchasing something like this.

Thanks!

Good question. We take this seriously, and try to keep the dependency footprint small (which is a challenge in the node/npm ecosystem). We try to stick with large, battle-tested dependencies (express, react, etc). For less popular projects, we will clone and run and perform our own internal audit.

We also follow best practices with automated tools like Sonar and Dependabot to automatically scan dependencies. We've gone through multiple pen tests. There's no silver bullet though, so it's a constant battle.

Thank you!