Idea: better support for non-static (FHIR) schemas

·Oct 27, 2026 09:02 PM(edited)·

Idea: better support for non-static (FHIR) schemas I work in healthcare integration as an architect, in healthcare HL7 FHIR is the standard for data exchange. It’s required in the US, and it’s the basis for the European Health Data Space and the national programs here in the Netherlands. The catch is that FHIR types are extendable. A schema is therefore a bit dynamic, but not unstructured: it’s just a superset of possible structures. Two systems can both send a Patient with different (valid) shapes. Workato schemas are static, so I either lose data (unknown extensions get dropped) or lose structure (generic object, parse by hand, no datapills). Small example (hl7.org/fhir/R4/patient.html): json

{
  "resourceType": "Patient",
  "extension": [
    { "url": "http://example.org/fhir/StructureDefinition/preferred-contact-moment",
      "valueString": "weekday mornings" }
  ],
  "deceasedBoolean": false
}

deceased[x] is a choice type: the key changes with the type (deceasedBoolean or deceasedDateTime)
the extension is local to one implementation and identified by its URL

What I’d like to see:

1.
Choice types as a union, with ducktyping/contract (like a python Protocol) support
2.
“Open” schemas: known core fields, unknown extensions pass through instead of being dropped

That means less custom parsing and no data loss, which will make this tool so much more powerfull for us!

🙌1