feat(evidence): add live FHIR tutorial support - #703
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d3b9fc07d4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
d3b9fc0 to
0839d09
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0839d09088
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
0839d09 to
d8e4c62
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d8e4c62f22
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
d8e4c62 to
165ada4
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 165ada456c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
render_parameters_schema() emitted a bare empty-object schema with no comment, unlike the other must-edit placeholders in the same draft (posture, authentication). An author had no way to know the file needed replacing until the bundle validator's opaque "schema objects must declare bounded properties" surfaced at compile time, since the closed Version 1 schema subset admits no empty-object schema and a transport: http-json source must declare at least one adapter parameter. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
…osture
The inline route already refuses to guess an authentication posture. The
referenced route did not: a sources/<id>.yaml that never stated one
compiled cleanly and reached the bundle with the posture undecided, so the
author only learned of it when the evidence runtime rejected the bundle, or
at production build time through the general "every production source must
use authenticated HTTPS" refusal. evidencectl now refuses at compile time
and names the source file and the question.
Two shapes are refused, each with its own message so the author can tell
them apart: an absent or null `authentication`, and an `authentication`
that states no usable `kind` (not a mapping, or a mapping whose `kind` is
missing, null, non-string, or blank). `authentication: {}` is the first
absence wearing a mapping, and it previously failed only inside serde's
untagged-enum rejection at runtime.
Security review notes:
- This narrows, never widens, what evidencectl accepts. It refuses only
the two shapes above on an `http-json` referenced source; every stated
kind compiles exactly as before, so no posture becomes acceptable that
was not acceptable already.
- The check settles that a decision was stated, never which one. An
unrecognized but non-blank kind string still passes through to the
runtime, which owns the closed enumeration and the assurance-profile
rules that admit `none` only at a numeric-loopback HTTP origin under
local assurance. No authorization decision moves out of the runtime.
- `sqlite-extract` sources open no network channel and carry no
credential field in the runtime contract, so the check is scoped to the
HTTP transport and leaves them untouched.
- The runtime keeps its own check, and `validate_production_sources` keeps
its production gate. This is an earlier, more actionable refusal beside
them, not a replacement, and nothing under crates/registry-evidence/ or
products/evidence/contracts/ changed.
- Both messages name only the source file, the question id, and the
`authentication:`/`kind:` field names. Neither echoes a stated kind,
a secret reference, or any other credential material.
Tests: absent and null `authentication` are refused with the absent
message; `{}`, a null kind, a non-string kind, a blank kind, and a
non-mapping value are refused with the unnamed-kind message; each leaves
staging empty. `{kind: none}`, `{kind: static-authorization}`, and a kind
this tool does not enumerate all still compile and land in the bundle,
pinning the boundary with the runtime's enum.
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
…orts The standards register said Evidence Gateway accepts FHIR JSON from fixed governed HTTP operations. The frozen fixed-source contract accepts `application/json` and `application/graphql-response+json`, not `application/fhir+json`, and the FHIR request and validation happen in a local read-through adapter the operator writes. The register now says that, matching the limitations page it links to. Adoption metadata follows the same correction. An adapter that is project code is not a Registry Stack surface, so the entry returns to `referenced` and `compares_against` with no owning crate, rather than claiming `registry-evidence` implements a profiled FHIR surface. Generated standards.json reproduced with docs/site/scripts/generate-data.mjs. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
165ada4 to
074024a
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 074024a13c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f93f7f93e2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cb6d6e6559
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Summary
--subjects-fileso sensitive selectors can be supplied from an owner-only file instead of process argumentsWhy
The existing synthetic-server path did not prove that adopters could build against a real FHIR server. This tutorial uses a public R4 demo endpoint, treats its records as changeable synthetic data, discovers suitable records at run time, and derives only claims that the returned resources support. It deliberately does not reinterpret a Practitioner qualification as a professional licence.
The tutorial connects to the real public server through a minimal loopback-only read-through adapter for local authoring. The adapter has no fixtures or seeded responses. Every governed resource read is forwarded live to SMART. It requests and validates
application/fhir+jsonupstream, then exposes the same JSON body asapplication/jsonto Evidence, preserving the frozen Version 1 source and bundle contracts.Security and privacy
0600files and are read with bounded, race-aware handlingValidation
origin/mainat9b0e3f3b0https://r4.smarthealthit.org: live discovery, both authored questions, both HTTP 200 credential requests, and offline verification of both SD-JWT VCs withtruegoverned valuescargo fmt --all -- --checkcargo test --locked -p registry-evidencectlafter the final rebasecargo clippy --locked -p registry-evidencectl --all-targets -- -D warningsnpm run checkbefore the conflict-free rebase: passed, including 41,083 internal linksgit diff --check origin/main...HEAD