Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Medplum (YC S22) – Open-Source Firebase for Healthcare
251 points by brown on Nov 8, 2022 | hide | past | favorite | 64 comments
Hi HN! Cody, Reshma, and Rahul here and we’re building Medplum (https://www.medplum.com), an open-source platform that lets you quickly build complex healthcare applications. We provide a headless EHR (electronic health record) that supports common standards like FHIR, HL7 and more. You build whatever UI and UX you want, and we handle the infrastructure and give you lots of interoperability and automation tools.

The digital healthcare space has been hampered by proprietary tech, walled gardens, and vendor lock-in. Working as healthcare app developers ourselves, we kept seeing organizations developing the same infrastructure over and over. The question “how is this stuff not open source?” came up so often that we finally decided to just build it.

Out of the box, Medplum includes:

- Auth - An end-to-end identity solution for easy user authentication, sign-in, and permissions using OAuth, OpenID, and SMART App Launch

- Clinical Data Repository (CDR) - A back-end server that hosts your healthcare data in a secure, compliant, vendor neutral, and standards based repository

- A FHIR-based API for sending, receiving, and manipulating data

- SDK - Client libraries that simplify the process of interacting with our API or any FHIR server

- A web application where you can view your data, perform basic editing tasks

- UI Component Library - React components designed to help you quickly develop custom healthcare applications

- Medplum Bots - Write and run application logic server-side without needing to set up your own server

Our team has years of experience in healthcare technology. We were the founders of MedXT (YC W13) and have held engineering leadership roles at Box and One Medical.

Our repo is at https://github.com/medplum/medplum and you can see a demo video here: https://youtu.be/nf6OElRWOJ4. There’s a sample app at https://foomedical.com, with code at https://github.com/medplum/foomedical.

Medplum is under the Apache 2.0 license so any developer can use it for free with no strings attached. We make money through enterprise integrations, and by providing a hosted version and support. Compliance is a priority—we are SOC 2 and HIPAA compliant and are pursuing ONC and HITRUST. Our hosted service runs on AWS and uses cloud infrastructure similar to a typical SaaS application. This is also rare in healthcare.

We would love to know what you think - especially any recommendations or ideas you want to share, and would love to hear about your experiences developing healthcare applications!




It's great to see (and to see you have fans here) -- Veeva for EHR?

If/since this is a freemium model, can you talk about the kinds of features you would end up charging for?

The 2019 state of open-source EHR is reported here: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6517630/

It would be interesting if published an assessment of your status and plans using their criteria.

I've seen practices successfully using two of the recommended EHR systems. Technically most seem in the ballpark, but the key seems to be whether there is a robust community validating the code and providing timely support. In that respect, another open-source alternative is not necessarily a good thing. Do you have any community-building hires in mind?

As for clients: the adopters are often medical people who picked up enough technology to wire things together, and do so for their practice employees. They're not super interested in sharing the secret sauce of their practice with consultants who will simply repurpose that knowledge for the competition. The most successful OS EHR's seem to be configurable by these adopters.

But it seems medplum targets developers (not the practice professional). If (since) those developers may have a tough time, do you have designs to pivot to new low-code approaches for end-user?

Conversely, if you stick with the EHR-AAS back end, the trend of the last few years has been for private equity to buy practice groups. I don't see yet the incremental value for the adopter or users of your offering over existing EHR's. But equity would be super eager to buy practices with EHR's ready to audit for due diligence before purchase and ready to integrate after. That could be a selling point for practice managers. Do you have any biz-dev plans to coordinate with the equity groups playing in the medical space, or investments from them, to tide you over the long process of gaining mindshare in a conservative market?


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


Wow, what a coincidence. Yesterday I attended an e-health event in EU and found several business opportunities for small FHIR applications for hospitals. We already have SaaS hospital customers, so I began my research.

We are working with HL7v2 ADT, FHIR seems like a very different more complex beast. Nice that they use JSON, but it reminds me a lot of those XML days with lots of namespaces, you always needed an editor.

There is a fhirbase/fhirbase Docker container that wasn't updated for 3 years, they focus on AidBox now, it's closed source, no public pricing.

There is even an ibmcom/ibm-fhir-server Docker container, 2 months old, but their project page https://ibm.github.io/FHIR is gone.

Then I came across this article from better.care CTO talking about how openEHR and FHIR should be used in a combined system, which seems to make sense. Product seems to be closed source, no public pricing, made in the EU. https://medium.com/@alastairallen/fhir-openehr-2022-53716f83...

There is ehrserver, open source, but not a single word about FHIR https://github.com/ppazos/cabolabs-ehrserver

So there is a lot happening, will check out Medplum, FHIR seems the future :-)


Thanks!


Very cool and impressive work! One question I have is how you think about handling custom data fields. FHIR has the `extension` attribute on all DomainResources that allows you to store any non-standard information, but building code and value sets to properly map this data can be cumbersome and time-consuming.

Do you have any happier/easier paths for extending the core data model to handle custom data?


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...).


Thanks for the thoughts! I agree that FHIR extensions are clunky and very commonly the data you're trying to store can be represented by a FHIR resource. Extensions are clunky, but for some of our projects have been the only way to store a couple pieces of data that we need.


Your use of custom StructureDefinitions for the very non-FHIR models that you need is impressive. I don't think I've seen such a clear example out there of someone extending FHIR to this degree. Well done!


Thanks. You might be the first person outside of the Medplum team to look at that file, happy to hear a positive review.


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


At present, Bots are AWS-only. We have an active enterprise customer who is exploring porting Bots to Google Cloud Functions. Azure Functions are on the longer term roadmap too.


Ok I never thought I'd see the day an open source compliant DB for healthcare would ever see the light of day.

As a solo software engineer on a hospital-based clinical trial and having to build everything from scratch, I'm beyond excited for this product!!


That's fantastic - I just spent 8 months bringing a health-tech startup to market, and the amount of random vendors who have managed to position themselves as a "must have" by building a single API and charging $30k/year for it is insane.


As someone who just got helped get OpenEMR (another OSS EHR) certified via ONC, I don't envy your journey through certification and wish you the very best of luck.

Looking through your documentation what version of FHIR are you targeting? Are you using SMART on FHIR v2? or v1?

What version of USCDI are you using for your data model? Have you decided whether you'll hit US Core 3.1 or are you going to go through the SVAP purpose for ONC?

One of the biggest questions we get all the time from people is lab integration, and e-prescribe. Is this something you are punting to your customers or do you plan on supporting that out of the box?


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.


The OHDSI OMOP CDM (OHDSI Observational Medical Outcomes' Partnership Common Data Model -- https://ohdsi.github.io/TheBookOfOhdsi/CommonDataModel.html) is huge for healthcare observational research and data science. It would be nice if you kept an item on your list to integrate with it (import/export CDM data) at some point.


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


Impressive work! I used to work at a tele-health startup that spent the majority of R&D building in-house EHR. We couldn't find any EHR solution that works out of the box, and is extendable enough to build custom features for our need. We totally would have tried Medplum if you guys launched earlier.

Congrats on the launch!


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


Do you have plans to target other countries in regards to meeting laws (similar to hipaa)? I've heard horror stories in rural hospitals in Australia. They're paying millions for absolutely horrible databases with constant crashes.


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.


We were just discussing how to do this today! How would you say your offering compares to, eg, Redox Engine, in terms of pricing and overall compatibility? Will you be open sourcing the entire stack, or keeping some parts proprietary?


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.


Hi MedPlum team - congrats on the launch! We've been working on the FHIR space pretty heavily for the past two years. Our main focus is building native FHIR apps for Android currently.

I see a lot of value in some of the components you are adding from an ecosystem standpoint. Quick q - are you building a server or focusing on the components on top? I guess I'm trying to understand the value prop vs. a system like HAPI of Google Health API? How robust is your support for data extraction eg. with StructureMaps, etc?

Congrats on the launch! Look forward to digging in more and my reach out.


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!


After having worked with Google's Health API & HAPI FHRI, I really appreciate the "other" features that are baked into this like auth and user management. We ended up proxying all of our FHIR requests through Rails to HAPI so that we could layer on some of the key features you mentioned like fine-grained auth and custom behavior before/after requests. This makes it much easier to pickup and use!


I think you guys hit the exact technical and business intersection where you can carve out some success and federate a challenge to Epic. Great job!


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.


It's so awesome to see the medplum team here!!

Medplum is a truly amazing solution to so many problems of building healthcare apps quickly. Before I had started chatting with the Medplum team it felt like an insurmountable task to experiment in the EHR area - the amount of infra & prep work we'd have to do made it so even for a proof of concept we'd have months before we could see anything useful.

It's really awesome to have so much of the hard part of handling health records done for us - and the depth of knowledge of the Medplum team is bar none when it comes to this area.

Y'all rock, congrats on the launch.


Thanks!


I don't miss HL7 or FHIR one bit. Would have loved a tool like this back when I was doing EHR work.

It's encouraging to see stuff like this moving into the OS realm, and I genuinely hope this type of competition and collaboration will lead to tangible benefits for patients (cost) and providers (ease of use) alike.


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.


Congratulations team medplum. Sounds really neat !


Congrats on the launch! Big fan...

Anyone who believes that healthcare is broken and could be vastly improved should look at Medplum's open-source projects. This is how you accelerate healthcare getting better software and breaking the stagnation that EHR companies have locked us into.


Congrats on the launch Rahul, Cody, and Reshma! A headless EHR sounds so cool! Why did y'all decide to describe it as Firebase, and has that description resonated well with potential users/customers?


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!


Headless EMR resonates best with me because of the parallel to other cms solutions like contentful. I’d spend time making sure you validate your point of view on the persona of the technical decision makers. The EMR decision for an early stage healthtech company is 10x more important than your initial cloud provider.


Surely you must have considered FHIRbase :P


Haha, yes, but someone got there first, with a now abandoned project.


Hi, is your CDR storing clinical data as FHIR objects natively?


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.


> we’ve been continually impressed by how the FHIR spec handles complex real-world use cases

what's an example?


One of the most complex Medplum projects is a large multi-party lab integration. We followed the US Core Lab Profile (https://hl7.org/fhir/us/core/StructureDefinition-us-core-obs...). We not only represented the labs results in FHIR (ServiceRequest, Observation, DiagnosticReport), we also represented the full lab catalog (ObservationDefinition, ActivityDefinition, PlanDefinition).

Time after time, stakeholders would raise new requirements -- how do we model pregnancy status? how do we model multi-step lab tests? how do we model contextualized reference ranges? Time after time, the FHIR schema had a clear answer.

That goes a long way to simplifying and streamlining multi-party integrations, and cuts out a lot of wasted time trying to reinvent everything from scratch.


Can you give me a quick run down on Firebase? I don’t know anything about it so to understand your product a bit more, please clue me in on what Firebase does and how people use Firebase. Thank you. Sounds like Firebase is pretty interesting and popular, I feel kind of like a boomer for not knowing what it is.

Anybody know what Firebase’s competitors are? Help me out here.


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


Thank you!


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?


I appreciate where you're coming from but for HN community purposes I think it's best to be more tolerant of simple questions. For all of us, there exists some popular thing that we're ignorant of. We don't want a culture that punishes people for asking sincere questions, and curiosity is the primary value of the site: https://news.ycombinator.com/newsguidelines.html.


Thank you for the perspective.


Congrats for the launch! I'm currently building FHIR adapter for my startup and this product is making me super excited.


This sounds really great. Checking things out today :-)


Congrats!

What kind of dependency vetting and monitoring is required for something like this where compliance is part of the picture?


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.


Congrats! You all have a really great product and team.


congrats guys


"Medplum aims to provide a well-known technology to a very buzzwordy sector, thus mooching off government funds."


"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.


Congrats Medplum team!


Thank you!


Congrats team!




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: