Hacker News new | ask | show | jobs
by brown 1318 days ago
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!

1 comments

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!