[rahul_agarwal]

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.

[neonate]

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

what's an example?

[brown]

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.