Clinical Domain Models

Clinical Domain Models are product-facing shapes Medblocks builds on top of connected healthcare data. They let your application work with clinical ideas such as medications, labs, conditions, allergies, visits, and documents without forcing every screen or workflow to understand every source-specific representation.

Why models matter

FHIR is the transport format, but source data still varies. The same product question can cross several resources, code systems, units, references, and document formats.

Clinical Domain Models give your product a domain vocabulary for concepts such as medications, labs, conditions, allergies, visits, and documents while preserving the source context you need for auditability.

For example, your app might ask for the latest BMI for a patient or the latest HbA1c for a cohort. The model has to know which patients are in scope, which clinical concept is being resolved, which FHIR resources and coded fields can contain that concept, how to normalize units and codes, and whether the result should use the latest value, an average, a minimum, or another rule.

That lets Medblocks return a product-friendly answer while still showing how the answer was resolved.

[
  {
    "subject": "Patient/1",
    "code": "bmi",
    "value": 24.6,
    "unit": "kg/m2",
    "status": "hasValue",
    "resolved_by": "direct",
    "provenance": [
      {
        "reference": "Observation/bmi-1",
        "system": "epic-org-a",
        "performer": "Clinic A",
        "effective": "2024-01-10",
        "value": 24.1,
        "coding": { "system": "LOINC", "code": "39156-5" }
      },
      {
        "reference": "Observation/bmi-2",
        "system": "epic-org-a",
        "performer": "Clinic A",
        "effective": "2024-05-02",
        "value": 25.1,
        "coding": { "system": "LOINC", "code": "39156-5" }
      }
    ]
  }
]

In that shape, value is what your product can render, and provenance is what lets a reviewer trace the answer back to the original source records.

What a model gives you

A useful model is more than a cleaned-up JSON shape.

• Clinical meaning. A medication, lab, diagnosis, or document is represented as the thing your product cares about, not just the FHIR resource it arrived in.
• Queryable fields. Common filters and display fields are lifted into a consistent shape.
• Source awareness. The model keeps enough source context to explain where the fact came from.
• Provenance. Medblocks preserves source identity, resource references, timestamps, and supporting context so downstream systems can audit the chain back to the original record.

What they are for

Use Clinical Domain Models when your product needs to render patient-facing or clinician-facing summaries, search and filter by clinical concepts, or power workflows that should not care which source produced the raw record.

Raw records still matter

Domain models do not replace the original record trail. They sit on top of it. Medblocks keeps the connected source data and provenance so your team can inspect the original context whenever precision, auditability, or clinical review requires it.

For record delivery today, use Data out. For source setup, start with Sources and connections.

See also