Examples on Simplifier

The guide explains the clinical context; FHIR examples are maintained as resources in the Simplifier project. The referral example contains just one ServiceRequest; the other examples are complete clinical collections. Open an example below directly in Simplifier's JSON view, where you can inspect, copy or download it.

Example Demonstrates Open on Simplifier
From recall to treatment Two visits with recall, findings, measurements, contact notes and treatment View JSON ↗
Planning with care responsibility Request, booking and contact linked to EpisodeOfCare View JSON ↗
Planning without an episode The same clinical links without EpisodeOfCare View JSON ↗
Referral request (ServiceRequest) One referral: requested service, patient, referrer, intended provider and clinical references View JSON ↗
Optional: all records behind the referral

The complete referral collection contains the referenced patient, care actors, finding, letter and contact note. Use it only when you need to inspect those records or the documentation of sending.

For a guided reading, use the example scenario. Its Record details panel shows individual records from the recall-to-treatment case. Measured and unavailable results are included in that case; see Observation guidance. The referral guidance explains the referral example.

The recall-to-treatment case uses Jonas Moen, a synthetic NHN SyntPop patient supplied for this guide. The care actors and their national identifiers are illustrative example values. Other example files use local identifiers. Clinical narratives use English. Example dates describe the case, not the guide's publication or review status.

Validation scope and limitations

Validation scope

The standalone referral ServiceRequest has 0 errors and 0 warnings in structural validation against 0.6.4. Its references point to the same records as the complete referral collection; only readable reference labels were added. Terminology validation was disabled.

The four complete collections have no errors in the recorded structural validation against their declared DigiDOT profile versions and the loaded national dependencies. The two Observation excerpts are checked inside the two-visit case, where their references resolve. Warnings and terminology limitations are retained in the validation evidence; this is not a claim of full clinical approval.

The four collections were rechecked with HL7 FHIR Validator 6.10.4 against their declared profile versions after the latest draft version adjustments. The recall-to-treatment case has 0 errors, 9 warnings and 48 information messages; each planning collection has 0 errors, 2 warnings and 6 information messages. The separate 11-resource referral collection has 0 errors, 4 warnings and 20 information messages. The seven profile definitions whose versions changed also have no structural errors in this check. These checks used no-basis 2.2.2 and no terminology server. Warnings include unavailable terminology checks and multiple matching national/base profiles; dependency snapshot-loading diagnostics are retained in the evidence. The version adjustments do not change the clinical example data.

Checks include reference resolution, patient consistency, the two actual contacts, recall/treatment status, measurement timing, current Coding IDs and matching anatomy inputs in SCTextended and bodySite. The terminology service accepts the SNOMED CT codes and expressions in the two-visit case for the stated edition release. Full MRCM/template, normal-form and clinical-equivalence validation have not been established by these checks.

Profile versions are declared in each resource's meta.profile; use those versions when repeating validation. A successful JSON parse or an old validation result alone is not sufficient.

Earlier checks revalidated the clinical case against Procedure 0.5.5 after two explanatory corrections, with the same 0 errors, 9 warnings and 48 information messages. The Procedure definition and three focused procedure collections also have no structural errors in their retained review checks. Their clinical expression templates remain under review; the older anatomy helper does not establish equivalence for the current single-SCTextended form.

The referral example additionally demonstrates a retained letter and narrative documentation of actual sending. Removing its required treatment code is rejected by the current request invariants. This does not establish terminology/template acceptance, receipt, supplier integration or legal approval. The referral assessment selected reuse of the existing ServiceRequest profile; the profile itself remains In review.

Other files in the project

Older pilot files, large patient bundles and earlier workflow variants remain in the project during review. They are not the recommended starting set. Some use earlier profile revisions, incomplete reference context or local Observation codes that do not meet the current SNOMED-only constraints.

In particular, the old DMFT, pain-score and radiographic-assessment examples need a governed terminology mapping or a separately agreed representation. They have not been silently replaced with approximate SNOMED concepts. Use the files listed above as the starting set.

These results apply to the versions declared in the example resources; they are not evidence for every later profile revision. Examples do not define a server API or import policy.