Skip to content

Thin-Slice Use-Case First

Intent

Prevent profile-first paralysis by starting with a thin slice of a real workflow demonstrable end-to-end.

Structure

A thin-slice is a small, end-to-end vertical thread from workflow intent → FHIR artifacts → runnable validation. Structurally, you build a minimal set of inputs, constraints, and outputs that can be demonstrated in one sitting.

  • Inputs: a one-page use-case + happy-path sequence that defines actors, trigger, and expected outcome
  • Artifacts: a minimal set of profiles/terminology (or even just base resources at first) plus one coherent example bundle
  • Gates: at least one automated validation run (publisher/validator + terminology checks if relevant)
  • Traceability: lightweight links from the use-case to the artifacts and acceptance tests
  • Outputs: a hosted preview that renders and validates so stakeholders can review the same executable slice

Thin-Slice Use-Case Structure Diagram

Key Components

One-page use-case

  • State the clinical problem and the actors involved
  • Define the trigger and the desired outcome
  • Capture scope boundaries (what’s explicitly out of scope)
  • Note key constraints (jurisdiction, privacy, policy)
  • Link to initial conformance statements and examples

Happy-path sequence

  • Describe the user journey step-by-step (who does what, when)
  • Identify the FHIR interactions (create/read/search/update)
  • Call out preconditions (identity, consent, terminology availability)
  • Mark decision points that will need governance
  • Keep it short enough to fit on one screen

Minimum dataset

  • List the minimum required data elements to make the slice work
  • Tie each element to a purpose in the workflow
  • Prefer existing elements over extensions
  • Note required terminology bindings and must-support expectations
  • Define what ‘good enough’ means for v0.1

Example bundle

  • Provide at least one valid end-to-end example that renders in the IG
  • Include realistic identifiers, dates, and code values
  • Keep examples small and readable; add complexity only when needed
  • Add at least one negative example if the risk is high
  • Treat examples as regression assets (they must keep validating)

Acceptance tests

  • Translate success criteria into testable checks (validator gates, terminology tests)
  • Ensure each MUST/SHALL is backed by at least one test
  • Run tests locally and in CI
  • Record expected outcomes and failure messages
  • Keep a thin smoke suite that runs fast

Behavior

How the thin slice evolves

The thin slice is iterated as a loop: write → compile → validate → review → adjust. The goal is to surface unknowns early and keep decisions reversible.

Thin-Slice Iteration Sequence Diagram

1) Draft the slice

  1. Pick one real workflow scenario and phrase it as: trigger → interactions → outcome.
  2. Identify the smallest set of FHIR interactions needed (create/read/update/search).
  3. Write down the minimum dataset and note any terminology dependencies.

2) Make it executable

  1. Create a minimal example bundle that can be validated and rendered.
  2. Add just enough constraints so the example is meaningful (avoid premature over-profiling).
  3. Run validation locally/CI and capture failures as backlog items.

3) Review and expand carefully

  1. Review the hosted preview with clinical + implementer stakeholders.
  2. Convert feedback into new explicit acceptance tests and conformance statements.
  3. Only expand scope when the slice remains green (rendering + validation).

Benefits

  • Working skeleton in days
  • Hidden assumptions surface early
  • Scope stays honest

Trade-offs

  • May feel too small to some stakeholders
  • Requires discipline against scope creep

References

Example

eReferral minimal slice: Patient + ServiceRequest + PractitionerRole + Organization + one supporting ValueSet.