Healthcare and FHIR-Oriented Modeling

Healthcare systems are unusually demanding. They combine complex workflows, sensitive data, strict privacy obligations, interoperability requirements, clinical safety concerns, and rapidly changing operational needs. Carrier includes healthcare-oriented language support through healthcare.questionnaire.

A Real Healthcare Service

The fhir-instruments example in the reference repository is small, but it shows the full pattern: a service with FHIR version, a typed healthcare.questionnaire, a derived field, an action that scores it, and a route that wires it together — all in under fifty lines.

service App {
fhir {
version: r4
}
}
 
enum Concern {

low

high

}
 
healthcare.questionnaire SymptomCheck {
fever: Int @range(min: 0, max: 10)
nausea: Bool
concern: Concern
derive triage_score: Int = fever
publish observation "fever_score" from triage_score
}
 
type InstrumentSubmissionResult {
score: Int
concern: Concern
}
 
action score_symptom_check(payload: SymptomCheck) -> InstrumentSubmissionResult {
return {
score: payload.fever
concern: payload.concern
}
}
 
route POST "/fhir/instruments/symptom-check" public -> InstrumentSubmissionResult {
input: SymptomCheck
 
handler {
return score_symptom_check(input)
}
}

Notice what this expresses as architecture: range validation, an enum used as a typed answer, a derived score, and an explicit publish observation clause that ties the questionnaire to a FHIR observation surface. None of this is hidden in framework code or convention — it is in the source, ready to be reviewed by a clinical informaticist or a compliance reviewer.

Reusable Clinical Data Structures

Healthcare systems repeatedly need the same clinical structures in different workflows. A depression screening form may appear in intake, follow-up, population health, and reporting. Reusable questionnaire declarations help prevent each team from inventing slightly different versions of the same clinical concept. For enterprise architects, this supports semantic consistency.

Designing for Interoperability

FHIR-oriented modeling is about more than copying FHIR resource names. It is about designing data so that it can participate in a broader healthcare ecosystem. Architects should consider: which internal models correspond to FHIR resources? which questionnaire responses need external exchange? which identifiers must be preserved? which code systems or value sets apply? The goal is not to force every internal design into FHIR shape, but to make the boundary between internal service design and interoperable healthcare data explicit.

Part Four

Architecture Patterns

Designing services, workflows, and integration at scale

❦