[HN Gopher] Launch HN: Medplum (YC S22) - Open-Source Firebase f...
___________________________________________________________________
Launch HN: Medplum (YC S22) - Open-Source Firebase for Healthcare
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!
Author : brown
Score : 155 points
Date : 2022-11-08 17:23 UTC (5 hours ago)
| imnotjames wrote:
| 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.
| brown wrote:
| Thanks!
| fabk wrote:
| 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.
| brown wrote:
| Awesome, thanks for the pointer. I just added it to our backlog
| for investigation.
| yawnxyz wrote:
| 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!!
| jjnoakes wrote:
| Congrats!
|
| What kind of dependency vetting and monitoring is required for
| something like this where compliance is part of the picture?
| brown wrote:
| 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.
| [deleted]
| xenospn wrote:
| 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.
| jahsome wrote:
| 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.
| brown wrote:
| Thanks! We all have our HL7 v2 pipe delimited scar tissue.
| blueyes wrote:
| 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.
| xcskier56 wrote:
| 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?
| brown wrote:
| 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://gi
| thub.com/medplum/medplum/blob/main/packages/defini...).
| xcskier56 wrote:
| 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!
| brown wrote:
| Thanks. You might be the first person outside of the
| Medplum team to look at that file, happy to hear a positive
| review.
| xcskier56 wrote:
| 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.
| xcskier56 wrote:
| Another question that I can't quite figure out from your docs
| is if your bots functionality works with non-AWS hosting?
| brown wrote:
| 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.
| rman666 wrote:
| This sounds really great. Checking things out today :-)
| syllableai wrote:
| Hi, is your CDR storing clinical data as FHIR objects natively?
| maxthegeek1 wrote:
| Congrats! You all have a really great product and team.
| mberg wrote:
| 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.
| brown wrote:
| 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!
| dtran wrote:
| 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?
| brown wrote:
| 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!
| yz_coding wrote:
| 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!
| brown wrote:
| Thanks! It means a lot from someone in the space. There is a
| ton of duplicated effort out there.
| w10-1 wrote:
| 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?
| reshmakh wrote:
| 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
| dwiner wrote:
| Congrats Medplum team!
| reshmakh wrote:
| Thank you!
| greazy wrote:
| 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.
| reshmakh wrote:
| 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.
| midislack wrote:
| 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.
| vxNsr wrote:
| Can't tell if you're joking...
| rahul_agarwal wrote:
| 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
| jahsome wrote:
| 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?
| dang wrote:
| 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.
| ijustwanttovote wrote:
| congrats guys
| poulpi wrote:
| Congrats team!
| TruthWillHurt wrote:
| "Medplum aims to provide a well-known technology to a very
| buzzwordy sector, thus mooching off government funds."
| dang wrote:
| " _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.
| brown wrote:
| I understand the cynicism. We do believe that providing a high
| quality open source offering can contribute to solving the
| problem.
| gowings97 wrote:
| 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!
| noelsusman wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-08 23:00 UTC)