Really cool project! I'm very bullish on LLMs for structured data.
Curious - why did you decide to open source? It's neat to see a lot new YC open source companies. I'm curious why you thought open-sourcing superglue was strategically advantageous
Thanks! The primary reason is because we want folks to be able to run this locally and contribute to the project / fix issues as they come up. This is much harder when you have a black box tool and rely on our small team for support.
Because of the GNU General Public License, any project/startup that makes use of Superglue is required to open source all their code under the same license? I'm not a license/copyright expert, so I'm a bit fuzzy about how this is supposed to work.
Not quite. The server runs standalone, so you can use it just as you would use linux as part of your project without affecting your own code. The client libraries that become part of your code are MIT licensed. The reason we made this decision is to prevent AWS & co from copying all of our code without contributing to the project.
Medplum (YC S22) | Engineering | SF Onsite | Full-time
We're an healthcare infra company that is untangling the gordian knot that is the U.S. healthcare system. We make an open-source platform that healthcare startups and hospitals alike can build on top of. We take care of the infrastructure, compliance, auth, interop, and data quality, so providers can focus on building amazing patient experiences.
We're a small team of repeat founders, and we've worked at places like Microsoft, One Medical, Palantir, Y Combinator, and Meta.
We're experiencing great customer growth and are hiring user-facing eng roles to keep up with demand:
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.
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.
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
Curious - why did you decide to open source? It's neat to see a lot new YC open source companies. I'm curious why you thought open-sourcing superglue was strategically advantageous