# Embedded FHIR validation: a bounded example

Executed 28 September 2026 with Node.js 22.18.0, @records-fhir/validator 0.7.0 and hl7.fhir.r4.core 4.0.1. Use an empty directory:

```sh
npm init -y
npm install --ignore-scripts --save-exact @records-fhir/validator@0.7.0
mkdir -p 'profiles/hl7.fhir.r4.core#4.0.1'
curl --fail --location https://packages.fhir.org/hl7.fhir.r4.core/4.0.1 -o core.tgz
tar -xzf core.tgz -C 'profiles/hl7.fhir.r4.core#4.0.1'
curl --fail --location https://medvertical.com/blog-examples/records-typescript-2026-09/check.mts -o check.mts
node check.mts
```

The broken synthetic Patient must produce one error, `structural-primitive-type-mismatch` at `Patient.active`. Changing the string `yes` to the boolean `true` must remove the blocking finding. The script asserts both outcomes and prints every remaining finding. The recorded run retained six informational findings in both cases.

- [Script](https://medvertical.com/blog-examples/records-typescript-2026-09/check.mts)
- [Recorded output](https://medvertical.com/blog-examples/records-typescript-2026-09/result.json)
- [Versions and SHA-256 hashes](https://medvertical.com/blog-examples/records-typescript-2026-09/verification.json)

Keep the generated npm lockfile with your integration. An initial direct validateStructure probe without configured profiles returned no findings for either input; the explicit source and negative-control assertion are essential to this example.

This is one primitive-type check. It does not test IG or terminology coverage, certify a release, or retest the separate Records CLI. No FHIR server, clinical data or Records workspace was used.