Nexus IG releases

Nexus IG 1.25.1

Thu, 10 Sep 2026 00:00:00 +0000

Consent.policyRule is no longer fixed to cric on app consent and item consent; both now require policy.uri instead. consentpolicycodes#cric is 45 CFR 46 -- the United States Common Rule for informed consent in human-subjects research. It is not a communication-preference policy, not a data-sharing policy, and not Canadian, and the code system it belongs to contains no Canadian concept at all: its 27 codes are US federal and state instruments plus three European ones. Rather than substitute another wrong code, both profiles now name the actual governing policy by URI, which satisfies R4's ppc-1 invariant and is jurisdictionally accurate. Consumer action: a writer that emitted the fixed policyRule must emit policy.uri carrying the applicable policy instead; a reader that keyed on cric to recognise a Nexus consent must key on category. Every shipped example is migrated in this release.
Communication.sender and .recipient now admit RelatedPerson. Rights over a record are exercisable by an individual and their substitute decision-makers, and a proxy must not be flattened onto the Patient: where a right is exercised by proxy the record has to show that authority was delegated, because that is what gets examined when the exercise is challenged. Consumer action: a reader that switched exhaustively on the reference target type of sender or recipient will meet a type it has not seen. Widening a reference is breaking for consumers even though it is additive for writers.
Item consent moves its decision from status to provision.type, and stops writing rejected. Provided is now (status = active, provision.type = permit); Declined or withdrawn is (status = active, provision.type = deny). provision moves from 0..1 reserved-and-unused to 1..1 with a required type. Consumer action: a reader that tested status = 'active' for Provided and status = 'rejected' for Declined must read provision.type instead. A reader that treated any non-active status as "not permitted" now sees active on a declined item and will read it as permission unless it changes. Every shipped example is migrated in this release.
App consent moves its decision to the root provision.type. Refusal was a nested provision with type = deny; a grant was the absence of one. Both are now stated on provision.type at the root, which is 1..1. Consumer action: a reader that walked the provision tree looking for a nested deny must read the root provision.type. A writer that expressed a grant by omitting the nested denial must now state permit.
QuestionnaireResponse is now listed in the server capability statement. The profile has declared read-only SMART exposure since the release that gave every scope a reachable permission, but the statement did not list the type, so a scope naming it resolved to nothing and an application asking for it was refused. Read-only: an application that could rewrite a response could rewrite an answer after the fact. Consumer action: none for existing clients. An application that previously had questionnaireresponse:read refused may now be granted it. FHIR-465.
[Consent.category[item]](fhir/StructureDefinition-nexus-emr-core-item-consent.md) moves from 1..1 to 0..1. It is no longer the only way an item consent identifies its item: a clinic-defined item carries no catalogue coding at all, and identifies itself on the new clinicDefined slice instead. The new item-consent-item-is-identified-once invariant (error) keeps exactly one of the two slices present, so no resource is left identifying nothing. Consumer action: a reader that reached straight for category[item] and assumed it was present must handle its absence, and must read the item from category[clinicDefined] -- the tenant coding for the code, and text for the label -- when it is the slice in play. A reader that treated the catalogue coding's absence as malformed will now reject valid item consents. Separately, a consumer that LISTS a patient's items must add http://loinc.org|59284-0 to its category search or every clinic-defined item will read as Not Recorded. Writers are unaffected: a governed item consent is written exactly as before. FHIR-466.
DocumentReference gains a status reason: the new nexus-document-status-reason extension (0..1, free text) is sliced onto the profile as statusReason, carrying why a document was marked superseded or entered-in-error. R4 DocumentReference has no statusReason element, and the code alone cannot say whether a retired consult was replaced by a corrected copy or filed on the wrong chart. The reason rides the version that recorded it -- the store's version history is the audit of who changed the status, when, from what to what, and why
MedicationStatement, MedicationDispense and FamilyMemberHistory now declare salient fields, so all three gain synthesized accessors and a Salient fields tab, and a consumer rendering them into a chart or an LLM context is reading the profile's own statement of what matters rather than the whole envelope. Until now these three declared none: they were reachable and validated, but had no reader surface, so they arrived as bare elements. The sets are medication / status / dosage / effective / asserted / reason_code on MedicationStatement, medication / status / quantity / days_supply / handed_over / dosage on MedicationDispense, and relationship / status / date / condition / deceased on FamilyMemberHistory. The two medication sets deliberately mirror MedicationRequest where they overlap, so one drug vocabulary covers prescribed, reported and dispensed. Additive only -- no element, cardinality or binding changes, and nothing a current consumer reads moves. Two of them collapse a repeating element and say so in their comment: condition is the FIRST recorded condition's code, and deceased reads only the boolean arm of deceased[x], so a relative whose death is recorded as an age or a date leaves it absent. Absent means "not stated in that form", never "no". FHIR-355.
Appointment.participant.type is documented and Must Support, with the participation type each actor carries — PART (Participation) on the patient, PPRF (primary performer) on the provider, both inside the bound encounter-participant-type value set. Consumers outside this ecosystem read the type rather than the referenced resource type, and Ocean drops a patient participant that has none, so an untyped booking never reaches its reminders list. No constraint is tightened: the element stays 0.. on the base extensible binding, and the four appointment examples now carry it. No ticket yet. Every reportable field now has an identity, and this specification is where it lives. Three new code systems: Nexus Field carries 458 concepts, one per reportable field, coded .; Nexus Field Category carries its 21 domains and Nexus Field Subcategory the 73 groups inside them. A field concept declares 26 properties and carries 24: where the field sits in the picker, which element and profile realise it, its data type, cardinality and repeat semantics, the code and the code system that identify it within its resource -- by name in clinicalCodeSystem and by canonical URI in codeSystemUri -- its expected unit, the permission needed to read it, how strongly it identifies a person, whether it is computed rather than stored, and the comparison family a report builder should offer, and -- where the path alone does not identify the field -- which entry of a repeating element it means (selector) and under what condition on the resource (gate). English displays sit beside fr-CA designations. Renamed before release: these three were nexus-reporting-criteria, nexus-reporting-category and nexus-reporting-subcategory when they first landed on main. They never appeared in a cut release, but they were on main for a day and were announced internally under those names, so anything written against them in that window needs re-pointing: the ids and canonical URIs above, and the criteriaCode key in reporting-catalog.json, which is now fieldCode. Codes, concepts, properties and the . shape are unchanged -- only the three system names and that one key moved. The reason is that the concepts are reportable FIELDS: a criterion is a field plus an operator plus a value, and these carry only the field. nexus-reporting-picker-id and its ConceptMap keep their names, because they genuinely are the frozen record of what the report builder's picker shipped. One field's CONTENT changed, and it is not part of the rename. demographics.sociodemographic-equity-set moved from pending to mapped: it gained fhirPath: Observation.value[x] and an elm mapping from a source change already on main, and the regeneration in this release is where that surfaces. It is named here because it was not attributable from the diff, which otherwise reads as a rename touching a generated table. As first generated it projected UNGATED. Observation.value[x] with no code discriminator writes every Observation's value into the equity-set columns -- unlike occupation beside it, which gates on LOINC 11341-5 -- and that is not a narrower value but a value belonging to a different question. The projection now REFUSES it: the columns exist in the marts and stay NULL, with the reason named in the generated header, under the rule that an entry reading Observation.value[x] with no usable code is refused rather than emitted. Making the field project needs a code discriminator stated upstream on the concept; it is not something the projector can decide. codeSystemUri is the machine-readable half of clinicalCodeSystem, and it is deliberately incomplete. A projection that filters on a coded criterion has to emit system and code together; a display name like LOINC or CDS-S CT-012 Phone Number Type cannot be matched against stored data, so a consumer had to keep its own name-to-URI table and every consumer kept a different one. 104 of the 138 concepts that name a code system now carry its canonical. The other 34 do not, because their clinicalCodeSystem names more than one system (CVX / Health Canada DIN, LOINC (observation code); SNOMED CT (value)) or names a table with no established canonical (the CDS-S concept tables, ICD-9-CA, CA Baseline birth sex). A guessed canonical is worse than an absent one -- it produces a query that matches nothing and reports zero rows rather than failing -- so where the system is not certain the property is absent, and absence means "not established", never "none". Before this there was no identifier for a reportable field at all. Consumers keyed on a domain number and a prose name, or on ordinals minted from a design mock, so nothing could be joined and a stored report survived a rename by luck. A code here is permanent. Adding one is routine; removing or renaming one invalidates every stored report and cohort that carries it, so retirement is status = deprecated plus replacedBy, and the release checks refuse a concept-level removal. identifierClass is a first pass and is not yet a masking control. It says whether a field identifies a person directly, narrows a population, or neither, which is what a de-identified export needs to key on. It was assigned by rule and classified up wherever it was arguable. It has not been through privacy review, and nothing should rely on it to mask until it has. The same caution applies to the fr-CA designations: coverage is complete at 458 of 458, but none of it has been through linguistic review, and complete is not the same as correct. That is why these systems ship as draft. Element prose was carrying the wrong things, and 21 profiles were corrected. short is a one-line summary of what an element IS -- the same contract SalientField states for its own prose
A form template can say which of its fillable fields a chart value pre-fills -- the new nexus-form-template-field-mapping extension on DocumentReference (PSD-1594): a list of rules, each naming a fillable field of the template's file by its AcroForm field name, verbatim, and the chart value that fills it, coded from the new nexus-form-chart-value code system (value set: patient.fullName, patient.firstName, patient.lastName, patient.birthDate with its .day / .month / .year parts, patient.gender, patient.phone, patient.address with its .street / .city / .province / .postalCode parts, patient.socialInsuranceNumber, patient.healthNumber with its .number / .versionCode parts, and patient.mrp, the most responsible provider). A form started from a mapped template opens with those fields filled from the chart and every value still editable; an unmapped field, or one whose value cannot be resolved, stays blank. Rules are keyed by field name rather than widget because a name can be drawn on several pages and every widget carrying it is filled. The binding is extensible -- a deployment may carry a key the set does not list yet, and a reader that does not know a key leaves the field blank. Only a template carries the extension: the new nexus-documentreference-field-mapping-only-on-template invariant refuses it on any other document. The system-provisioned WSIB Form 8 template ships mapped; its example carries the full rule list.
The Reviewed extension's context widens to DocumentReference: a document now carries who signed it off and when, on the resource the question is asked about, so a reader renders the checkmark from the document alone rather than joining to the review task. It repeats there — a document is assigned to reviewers individually, and each stamp is one reviewer signing off for themselves. Absent still means unreviewed.
New Resource Note extension: an attributed note on a resource with no note element of its own, anchored at DomainResource so every such resource gets the same thread the same way. Each repeat is one Task Note turn — author and time required, machine authors as identifier-only references — and the thread is append-only, read oldest first by time. First use: the comment thread on a document, riding the DocumentReference itself, so reading the thread is reading the resource. Where a resource defines a native note element, that element remains the home.

Nexus IG 1.25.0

Mon, 31 Aug 2026 00:00:00 +0000

This release contains a breaking change.

The site build is 43% faster and the published site four times smaller, from four Material navigation features -- navigation.prune, navigation.instant, navigation.instant.prefetch and navigation.instant.progress. Measured on this branch with the pre-build hook disabled, so the numbers are mkdocs alone: 24.3s -> 13.9s, and 650 MB -> 158 MB on disk. Once the validator is off the path (publish --fast), the site build is the release cost. The navigation was 61% of every page. Material renders the whole site's nav into all 1,203 pages, so the largest reference page shipped 519 KB of nav and 1,701 links before a byte of its own content. prune emits only the active branch plus its ancestors and siblings; a cousin profile collapses to one link. It touches nav markup and nothing else -- sitemap.xml, the search index and the
of all 1,207 pages are byte-identical to the unpruned build, so no published URL moves and the URL and fragment gates are unaffected. What it costs and what pays it back. A cousin profile becomes a link rather than an in-place expander, so reaching a different profile costs a navigation instead of a free CSS toggle. navigation.instant turns that navigation into an XHR content swap rather than a document reload, .prefetch starts the fetch on hover, and .progress shows a bar past 400ms. Handbook pages render identically either way: what prune strips there is the reference tree that was in the DOM but hidden behind a tab.
A second 29% off the site build by removing an extension and a plugin that did nothing: include-markdown and codehilite. 14.8s -> 10.5s, output byte-identical. Profiling the build rather than guessing is what found them: include-markdown ran on_page_markdown across all 1,203 pages scanning for a directive that appears in no page and never has (the includes in use are pymdownx.snippets --8<-- markers), and codehilite is an alternative to pymdownx.highlight rather than a layer under it, so registering both left the second one inert. Together with the navigation work above, a strict site build is now ~31s -> ~16s end to end.
The site build is stock MkDocs now: no plugins beyond search, no hooks:, no watch:. Navigation moves from the mkdocs-awesome-nav plugin's per-directory .nav.yml files to one ordinary nav:, assembled by bin/gen-nav.ts from an authored src/nav.yml plus the generated reference tree and read through mkdocs' own INHERIT. Rendering docs/fhir/ moves from the pre-build hook into bin/site.ts. Output is byte-identical. We were using none of awesome-nav's features -- no globs, no sort, no flatten, no hide -- only its ability to split the nav across directories, while the reference tree that is 96% of the entries was generated regardless. Removing it produced an identical 1,207-page site. hooks: and awesome-nav were the two things tying this site to MkDocs. Material for MkDocs reaches end of life on 5 November 2026 and its successor, Zensical, supports neither yet. Nothing here commits us to that migration; it removes what would have blocked it, and it costs one dependency and one Python file rather than adding anything. doc/fhir/bin/ is now Python-free. What it costs, named. mkdocs serve no longer re-renders docs/fhir/ when the IG source changes, so a bare mkdocs build is no longer self-sufficient -- npm run site is the entry point, and npm run site-kick restarts the server after an FSH or src/pages edit. Edits under docs/ live-reload as before. INHERIT is resolved at config load, before any hook could run, so the nav could never have been written from a hook anyway; the build gate grew a nav is current check so a stale nav fails loudly instead of publishing pages with no sidebar, which mkdocs reports only as INFO.
check-blast-radius resolves the base branch instead of assuming origin/main. IG releases stack -- 1.23.0 -> 1.24.0 -> 1.25.0, each PR based on the last -- and against main a stacked branch inherits every unmerged parent's diff. This branch measured 1,687 changed files that way, of which 1,295 were a single 1.23.0 commit untracking the rendered pages and only 67 were its own. A reviewer reads a number like that as noise, which is the exact failure the gate exists to prevent. The base now resolves in order: --base, then GITHUB_BASE_REF (set by GitHub Actions on a pull_request event, and authoritative there), then gh pr view for the current branch, then origin/main. Every path is printed, including the fallback, because a wrong base fails silently in both directions -- too far back and the diff drowns, too far forward and real changes stop being counted.
check-blast-radius gains a declared-IG-consumer list, and NativeFHIR/seed-generated.sh is its first entry. That script reads igVersion and sourceContentHash out of the generated meta to decide whether a cached seed dataset is stale -- it is the only one of NativeFHIR's eleven files that reads any of it, and IG releases have legitimately edited it before (1.20.0, and again this release after 1.23.0 deleted the sourceCommit field it had been reading). The test is "does this file read the IG's generated metadata", not who owns it: ownership is what the gate prints so you know who to ask, and it moves. Declared consumers are counted and printed but do not fail the gate, because an exemption nobody can see is one nobody re-examines.
set-version stamps one site it used to miss; sixteen other version stamps were deleted instead. Cutting this candidate found seventeen places still naming 1.24.0: five using Nexus version '' declarations and all twelve measurement-catalog ObservationDefinition-.json resources. Only one of the seventeen turned out to be worth keeping. Neither set was silent by accident. ts/test/cql-model-version.test.ts exists because the using bump "was made four releases running, and the fourth is the one that shipped"; ts/test/measurements.test.ts recorded the catalog stamp being walked by hand through 1.21.0
The measurement catalog drops its version field entirely, and says plainly that it is test data. Twelve ObservationDefinition resources that exist to exercise the CQL engine's unit-vouching -- that a unit-bearing threshold is refused unless something vouches for the convention. Nothing in production consumes them: no service outside TypedFhir imports the module, and every caller of compileToTrigger that passes a catalog is a test or a test-golden generator. Defining measurements for production is expected to be a richer mechanism that has not been designed. The field tracked nothing and was read by nothing -- the catalog keys entries on code|system and never looks at it -- so it was noise with a maintenance cost. measurements.test.ts now asserts the field stays absent, with the reasoning in the test, so it cannot creep back as a stamp. gen-measurements.ts no longer reads igVersion() at all, and the module and generator headers now say what the content is for rather than describing an unbuilt deployment/tenant resolution model as though it existed. See FHIR-102 for the related finding that these resources' canonicals are declared nowhere -- which this reframes: they are test fixtures, so the question is whether they should be in the fhir.apps.health namespace at all.
Two Handbook pages were orphaned from the navigation and are now in it: guide/features/scheduling/converter-contracts and guide/features/scheduling/oscar-template-schema-notes, both FHIR-18/FHIR-19 working notes for the Oscar-side converter owners. A page absent from the nav renders with no sidebar in mkdocs-material, and mkdocs reports that as INFO rather than a warning, so strict: true stayed green while they published unnavigable. Both are still marked Draft.
BREAKING -- TypedFhir's multi-IG selector is gone. If you pass ig: to any ingest entry point, or read igKey / ig_key off a report, remove it. fhirToResources, fhirToResourcesLenient and their Python twins no longer accept an ig argument, DecodeReport no longer carries the key, and DEFAULT_IG / resolveKey / resolve_key / registeredIgKeys are no longer exported. getIg() takes no argument. Callers that never passed a selector -- which is every caller we can find -- need no change. Why. Nothing selected a second IG. The .NET port never implemented the selector at all; no service, no frontend and no generator passed one; and the only non-default consumer in the tree was the synthetic-v1.0.0 fixture, which existed to prove multi-IG selection worked. A capability whose sole user demonstrates that capability is not one. What it was costing. The -v key put the IG version into two hand-maintained registries and two pinned tests, and needed a key-vs-generated-meta agreement check to catch the drift those literals invited. Removing it removes all five.
The IG version is no longer written anywhere by hand. There were nine version sites -- eleven occurrences across prose, worked CQL examples, the two registries and three pinned tests -- each walked forward every release, each having drifted at least once. All nine are gone: ts/codegen/lib/ig-specs.ts derives from the compiled IG via igVersion(); ts/test/ig.test.ts compares IG_META.igVersion to the same source rather than to a literal; the guide's worked criterion declares bare using Nexus, as the DM-01-nexus fixture always did; and README.md no longer pins a version. sushi-config.yaml is the only place a version is written, and the generated stamps are asserted against it.
docs/theme/js/tab-anchors.js, dead since 1.16.0. It activated ancestor content tabs so an inbound #inv- anchor landed on content the reader could actually see; one page per tab made every view separately addressable and dropped the script's extra_javascript entry in that release, leaving the file orphaned and loaded by nothing. Confirmed unnecessary rather than merely unwired: across all 1,204 content pages 26,481 fragment links resolve to visible content, none missing and none inside an unselected tab, and exactly one page in the site -- the hand-written CQL artifacts guide -- still uses a content tab at all.

Nexus IG 1.24.0

Sat, 29 Aug 2026 00:00:00 +0000

A machine-written Task declares WHO produced it, on requester -- two new identifier authorities, NamingSystem/nexus-cds-rule (a decision-support rule) beside the existing NamingSystem/nexus-harness-graph (an AI-harness graph). Both are used the same way, as a logical Device reference: Reference.type = "Device" plus Reference.identifier under the producing registry's namespace, resolving to no Device resource on the server. A consumer telling producers apart now reads ONE declared field. (FHIR-90) Two authorities rather than one, because two separately owned registries mint these values and either could mint the same string. That is not only an attribution problem: producer identifiers feed the business keys below, and a key is SEARCHED and the resource it finds is UPDATED, so a shared namespace lets one producer's re-run overwrite the other producer's work item. The system names the registry that ISSUED the identifier, never the runtime that executed the rule -- a rule invoked as a tool from elsewhere keeps its identifier.
A decision-support rule keys its work under its own namespace: NamingSystem/nexus-cds-key, the exact counterpart of NamingSystem/nexus-harness-key and separate from it for the reason above. Same rule, and the same one way to get it wrong: the value is derived from WHAT THE TASK IS ABOUT (the patient and the gap), never from the evaluation that produced it. CDS Hooks supplies a hookInstance and a card uuid, and both are per-firing values that mint a fresh key every evaluation. (FHIR-90)
An attachment packet is a List: the ordered set of chart items assembled to travel with something going out. New profile StructureDefinition/nexus-attachment-packet with NamingSystem/nexus-attachment-packet for its identity. Membership and order are List.entry, mode is working, subject is the patient. The host points at the packet with a reference element it already has: a letter uses one Composition.section.entry, a referral uses ServiceRequest.supportingInfo. Both are Reference(Resource) in base R4, and ServiceRequest.supportingInfo is what Ontario eReferral profiles for referral attachments, so a packet is legal in each today and what this release adds is the sanction. (SD-175, SD-222) Why a List and not a document. R4 has a resource for exactly this shape -- DocumentManifest, "a collection of documents compiled for a purpose together with metadata that applies to the collection", carrying content, recipient, related and subject -- and it is REMOVED in R5, replaced by List. So the shape is right and the container it would ship in is a dead end. IHE MHD reaches the same place: IHE.MHD.Comprehensive.SubmissionSet constrains List, and MHD's ihe-intendedRecipient extension sits ON THAT LIST rather than on a document -- recipient belongs to the packet prepared for someone, not to the document, which is why DocumentReference gains no recipient element here. Modelling the packet as its host's own sections was the alternative and it does not survive contact with the second host: a ServiceRequest has no sections, so an eReferral would have needed a second design, and so would every other host in the requirement. entry.item is deliberately not type-constrained. Enumerating the kinds shipped today would reintroduce the per-type modelling this profile replaces; a consumer renders the kinds it knows and reports the ones it does not.
A packet member can say which of its pages were left out -- StructureDefinition/nexus-attachment-packet-excluded-page on List.entry, repeating, one occurrence per excluded page, 1-based. IG-defined rather than a house extension because a third-party consumer is a named future reader and can only implement what is published. One occurrence per page rather than a range expression ("2-4,7"): a range is a second syntax this specification would have to define and every reader would have to parse identically to agree on what was sent, where a repeating integer needs no parser and a validator can check each value alone. Page numbers are meaningful only relative to the render they were taken from -- a different renderer may paginate the same member differently -- so they record what the assembler chose, not a durable re-rendering instruction. What the recipient received is the document stored on send.
LOINC 28562-7 "Chart section Set" joins ValueSet/nexus-composition-section, which is what an enclosures section codes to, and a new enclosures code joins CodeSystem/note-block-type so an attachments block renders through the same dispatch as every other block. 28562-7 is SCALE_TYP = Set / CLASS = ATTACH.CLINRPT: a SECTION code. LOINC 11503-0 is the DOCUMENT code for the rendered packet PDF and belongs on DocumentReference.type, never in a section slot -- the distinction this value set's extensible binding exists to catch. (SD-175)
Task.requester is the producer, and the two things it is NOT are now stated on the elements themselves. intent is not a machine marker -- humans raise proposals, and the element says what the owner is being asked to do. groupIdentifier is a DISPLAY GROUPING and nothing more: grouping is available to every producer, since a harness capability proposing several chart entries from one note is one evaluation raising a set exactly as a decision-support card is. A consumer that infers the producer from either, or from the ABSENCE of either, is reading a coincidence of current behaviour. (FHIR-90)
Task.identifier, Task.owner and the Task Note profile name both producer families. owner admits a rule as a logical Device alongside a graph, while the approve/resume undertaking stays the harness's own (assigning a task to a rule promises no resume), and nexus-note-agent-author was widened so a rule-authored turn is held to the same identifier-only shape as a graph-authored one. (FHIR-90)
DocumentReference.context.related is sanctioned as the BACK pointer from a rendered outbound artifact to the packet it renders and the host that packet travelled with. Ontario eReferral profiles this element the same way, so the pattern stays; what changes is that it stops being the ONLY link, now that the host carries a forward reference. Do not discover the relationship by searching it: related is not among the search parameters this server declares for DocumentReference, and an undeclared parameter is dropped silently rather than refused, so a search that appears to work may be returning the whole compartment. Resolve the reference. (SD-175)
NamingSystem/nexus-harness-key drops its documented legacy CDS-connector key shape ({hookInstance}:{cardUuid}:{suggestionIndex}). It was per-firing, so it minted a fresh key on every evaluation and defeated the duplicate suppression the key exists for -- the one shape in that file that broke the file's own derive-from-the-gap rule. CDS keys now live in their own namespace (nexus-cds-key, above). Consumer action: a producer fed by CDS Hooks derives its key from the subject and the gap, never from the firing. (FHIR-90)

Nexus IG 1.23.0

Sat, 29 Aug 2026 00:00:00 +0000

This release contains a breaking change.

The Patient profile gains the Indigenous-profile fields. The Indian Act registration or status number is a Patient.identifier under the Canadian URI Registry's official system (…/ca-indigenous-northern-affairs-number; 9–10-digit value or a data-absent-reason while other card facets are recorded first; the validity period carries the card's issue/expiry, and the new nexus-emr-indian-status-card-type extension on the identifier carries the presented document form — SCIS, CIS, or TCRD). Three optional flat extensions carry the rest: Indian Act registration status (nexus-emr-indian-act-registration-status) and the First Nation registry group and community (nexus-emr-first-nation-registry-group / nexus-emr-first-nation-community), both coded from the curated seed-managed band list (ValueSet/nexus-first-nation-band, code = federal band number). Every field is independently recordable, records what the patient states (never verified against the Indian Register), and a recorded expiry does not imply a registration-status change.
Form documents are marked, and found, by one identifier system — the new NamingSystem/nexus-form (PSD-1230): a DocumentReference carrying an identifier under https://fhir.apps.health/NamingSystem/nexus-form is a form, its value a kebab-case slug naming the form type (wsib-form-8), and a patient's forms are enumerable with the standard identifier search's system-only token — the marker-identifier convention nexus-template established, applied to DocumentReference.
Form templates are marked by a sibling identifier system — the new NamingSystem/nexus-form-template (PSD-1230): a subject-less DocumentReference carrying an identifier under https://fhir.apps.health/NamingSystem/nexus-form-template is the tenant-wide blank of a form type, its value the same slug its filed nexus-form instances carry, and a tenant's templates are enumerable with the same system-only identifier token search.
Form templates are searchable by title (PSD-1230): the server declares the standard DocumentReference description string search, and DocumentReference?identifier=https://fhir.apps.health/NamingSystem/nexus-form-template|&description:contains={text} finds the templates whose title carries the text anywhere, case-insensitively -- so a template picker reads pages of the matches rather than the whole catalogue.
Form templates are uploaded and deleted by a tenant (PSD-1230): an uploaded template is a subject-less DocumentReference created with its PDF inline, description the title as typed, and the nexus-form-template marker's value the kebab-case slug of that title (WSIB Form 8 -> wsib-form-8) -- the form type every form later filled from it carries. A tenant holds one template per form type: an upload whose slug is already marked by a live (not entered-in-error) template is refused, so a client must probe DocumentReference?identifier=https://fhir.apps.health/NamingSystem/nexus-form-template|{slug} before creating. A template is removed with the standard delete interaction unless it carries the readonly tag (https://fhir.apps.health/tags/document-reference/readonly|true, the system-provisioned templates) -- those are never offered for deletion. Forms already filled from a deleted template stay on their charts: they carry the form type by slug and reference no template.
A C# consumer can ask, at runtime, which IG the package was built against. TypedFhir.Facade.Generated.IgMeta carries IgId, IgName, IgVersion, FhirVersion, Canonical, SourceContentHash, ProfileCount, ValueSetCount and InvariantCount. The TypeScript and Python ports have carried the same facts as IG_META for several releases; the .NET package had them only in a generated header comment, where no program could reach them. All three ports are now populated from one derivation, so they cannot disagree about their own provenance. (FHIR-93)
A form template no longer has to name a patient, and every other document still does. DocumentReference.subject relaxes from 1..1 to 0..1, guarded by the new invariant nexus-documentreference-subject-unless-template: a DocumentReference SHALL carry a subject unless it carries an identifier under NamingSystem/nexus-form-template. A template is the tenant-wide blank of a form type and is about no patient, which is the shape the form-template guidance describes, and the profile previously required a subject on it. Read the cardinality with the invariant, not on its own -- for every document that is not a template the requirement is exactly what it was, and it is now stated in evaluable FHIRPath rather than left to a cardinality. A consumer that treated subject as always present must handle the template case. Stated as one invariant rather than a second profile, because a template profile answers the question once per resource type. Both form systems now ship a worked example: a filed WSIB Form 8 and its template. (FHIR-94)
nexus-first-nation-registry-group and nexus-first-nation-community bind required, not extensible. The extensible binding permitted a code from any system while both definitions said a band outside the curated list could not be recorded; required is what the definitions describe. It costs nothing to record a band the list is missing, because ValueSet/nexus-first-nation-band is seed-managed reference data rather than an IG artifact -- membership updates ship as data and need no release, so a closed binding never becomes a release gate on recording a patient. (FHIR-94)
nexus-first-nation-community now states that the band list APPROXIMATES its domain. A band is a registry group; a community is a place and a people. One band may hold several communities and reserves, and a person can affiliate with a community whose band does not hold their registration. Both extensions bind the band list because it is the only curated Indigenous reference data this specification carries. Read a community value as the community the patient named, resolved to a band, and never as a claim about registration. (FHIR-94)
The IG version is no longer stamped into the header comment of every generated file. It has a structured home in each port -- IG_META in TypeScript and Python, IgMeta in C# -- and that is where a consumer reads it. Generated files carrying a version string drop from roughly two hundred to eight: the IG-table modules, Metadata.cs and PatientCompartmentMap.cs, each of which has a better claim to naming its IG than a per-resource facade does. No API moves; the affected lines are banner comments. (FHIR-93)
BREAKING for library consumers: IG_META.sourceCommit is removed from @awaremd/typed-fhir and the Python package. Consumer action: read IG_META.sourceContentHash instead -- a sha256: digest of the IG artifacts the tables were generated from, which is what a provenance stamp is for and which this release does not otherwise change. sourceCommit was derived from the source repository's commit log and was unsatisfiable by construction: it named a commit that did not exist until after the commit carrying it was made, so it could never be correct in a working tree. Nothing in the published surface read it. The field-dictionary manifest, the delta register and the seed-generator manifest move their ig block from sourceCommit to sourceContentHash for the same reason. Named as breaking here rather than signalled by the version number, per this changelog's own rule: versions are sequential, not SemVer, and the entry carries the compatibility contract. The consumer action is one field name. (FHIR-93)

Nexus IG 1.22.0

Wed, 26 Aug 2026 00:00:00 +0000

This release contains a breaking change.

Imaging Modality -- modality on the report, because the withdrawal of ImagingStudy left the requirement with nowhere to go. Modality is an ImagingStudy property in R4, and this guide no longer profiles that resource; the imaging capability that requires it (ON RFP 1.5.4.2) did not go away with it. 0.. MS on DiagnosticReport, repeating so a PET-CT report says two rather than choosing. It describes the DOCUMENT, not an acquisition. Saying a report came from a CT asserts nothing about series, instances or SOP UIDs, and needs no PACS to be honest about -- which is what lets this estate record modality while still declining to model ImagingStudy. DiagnosticReport.code is not a substitute, and that is the objection worth answering. A human reader infers modality from "Chest X-ray"; a results list filtering "show me the CT reports" cannot, without maintaining a procedure-to-modality mapping outside the record and getting it wrong silently. An implied fact every consumer must re-derive is not a recorded fact. Bound extensible to DICOM CID 29 -- the same value set and the same strength R4 binds ImagingStudy.modality to, so a consumer that already knows R4's imaging model needs no second rule, and heritage feeds carrying local modality codes stay conformant.
Nexus Composition Type, for the document kinds LOINC cannot name. Three generated-summary kinds exist in production and a consumer has to tell them apart: nexus-daysheet-summary (written ahead of a clinic for a booked patient), nexus-interval-summary (what happened between two points in time) and nexus-encounter-recap (one encounter, after it). All three are LOINC 34133-9 as a CLASS and none is distinguishable from the others by any LOINC code -- and they are not interchangeable, since a recap asserts that the encounter it covers took place. Plus nexus-letter-template, so the retired http://services.well.com/fhir/categories/letter-template has a home on this guide's base if one is still needed (templates are List as of 1.18.0, so check first).
Meta Updated By, an extension this EMR has been writing undeclared on Resource.meta since before this guide described it. It names the user account that last wrote a version, so a version list can say who touched each row without fetching a Provenance per row. It is a display convenience, not an audit record -- anything reasoning about authorship should read Provenance. The value is an identity-provider subject (auth0|...), NOT a Reference: it names an account, not every writer has a Practitioner, and a dangling reference would be worse than a string a consumer can match on. Like the two note extensions above it publishes at this guide's base while production still writes http://services.well.com/fhir/StructureDefinition/UpdatedBy. This one differs in a way that matters: it rides meta on every version of every resource ever saved, so the old address does not stop appearing when writers move -- it stops appearing on NEW versions, and history keeps it. Readers should plan to see both indefinitely and match on the URL suffix.
First Nation Bands and the First Nation Band CodeSystem behind it -- a canonical this guide bound two extensions to and declared nowhere. The First Nation registry group and community extensions added in 1.21.1 bind https://fhir.apps.health/ValueSet/nexus-first-nation-band, and nothing published it, so a consumer reading either extension could not discover the value domain and the link did not resolve. The canonical is unchanged: it is the one the EMR already writes, declared rather than minted, so no stored Coding moves. The content stays out (content = #not-present). The membership is the Indigenous Services Canada band list, held as seed-managed reference data on the same footing as the curated problem and procedure lists, and it changes on that list's schedule rather than this guide's release schedule. This publishes the system's identity and leaves its content where it lives, so an expansion is available only from a terminology server loaded with that seed. Both bindings are extensible, which is the honest strength: a band absent from the curated list cannot be coded. The code is the federal band number and the display is the band name as registered. Band names beginning with a literal ? are the names as registered, not encoding damage, and sort before "A" under ordinal comparison. The Canadian URI Registry names the same registry for IDENTIFIER use as .../NamingSystem/ca-federal-firstnation-band-id; this system is the CODING view of the same registry, which is why the two URLs differ and both are correct.
Composition Block Type and Composition Block Data, the two extensions a block-authored encounter-note section carries, together with the Note Block Type code system and Note Block Types value set the first of them binds. The note body is authored in a block editor -- an ordered stack of independent pieces, each with its own identity, heading and kind -- and the EMR has been writing that shape undeclared. A block is one Composition.section: section.id is its identity, section.title its heading, section.text its narrative, and R4's own ordering of section carries the sequence. A block raised and left blank is kept, with an empty narrative and an emptyReason of notstarted, because the gap is part of what the author wrote. This is the block surface returning on the terms 1.14.0 set for Composition itself: there is a committed consumer. It is not the shape 1.11.0 withdrew. That one nested sections recursively and carried its kinds in a complex extension whose slicing was among the unevaluable-slicing defects the removal cleared; these are two flat extensions on an ordered, non-recursive section. It does enumerate block kinds as nexus-emr-embedded-section-types did, and the difference is what is enumerated: one kind that has shipped, rather than four that had not. The narrative is authoritative, and that is the invariant to build on. Every block-authored section carries its content in section.text whatever its kind, so a consumer that ignores both extensions reads a correct, complete note. A block kind that puts clinical content in the structured value and nothing in the narrative is malformed however well it round trips. The block-kind vocabulary is extensible, and a reader that meets a kind it does not know must write that kind back unchanged. Every block-authored section declares its kind, text included; a section carrying no kind at all predates the extension and reads as text, which is tolerance for data filed before block authoring existed rather than a default, and is retirable once no such section remains. Note Block Types is how a kind becomes NAMED -- a writer whose kind is listed uses that code rather than a synonym -- but a kind the guide has not named yet is conformant. Rendering an unrecognised kind as text is correct; storing text in its place is data loss. Both extensions are draft, and the vocabulary grows as kinds ship rather than ahead of them. Both extensions publish under this guide's canonical base, https://fhir.apps.health/StructureDefinition/.... They were first minted under http://services.well.com/fhir/..., the hostname three older Composition extensions in the same library already use, and were moved before publication -- the only moment that move was free, since no note carrying either had been filed. Published canonicals are forever, and from this release these are published.
Composition Billing and Composition EHR Share, two extensions this EMR has been writing undeclared. Billing raised at note closeout (the service code, the diagnostic codes supporting it, and units where the fee code is charged per unit), and one record per completed share of a signed note to an EHR outside the practice. Both were live on filed notes while this guide described neither, so a reader saw a Composition profile with no billing concept and no sharing concept at all. These are declared at this guide's canonical base, which is NOT the URL the software writes today. Production emits them under http://services.well.com/fhir/StructureDefinition/...; they publish here under https://fhir.apps.health/.... The block extensions added above could simply be moved, because nothing had been filed against them yet. These have live clinical data behind them and cannot be moved by editing a constant, so the specification states where they belong and the implementation is knowingly behind it on the URL. Writers: write the canonicals declared here. Readers: expect both for as long as filed notes carry the old address. Matching on the URL suffix (composition-billing, composition-ehr-share) reads both; resolving only the canonical silently misses billing and sharing on every note written before the writers move.
Twenty-four conformance rules that the generated validators reported as unverifiable are now CHECKED at runtime, in all three ports. The unverifiable set goes from 36 to 12. Consumer action: a resource that carries one of these defects now raises an error where it previously produced an invariant-unverifiable note. Every one of them was already enforced by the HL7 validator, so a resource that passed a full FHIR validation is unaffected; what changes is that the in-process validator no longer needs a second tool to see them. Callers that cannot absorb a new error use validate() and triage the issues rather than assertValid(). Newly checked: Appointment app-2 / app-3, Basic app-state-system-inv, the nine MedicationRequest tim- dosage-timing rules, Organization org-1, Questionnaire que-1 / que-10 / que-13, QuestionnaireResponse qrs-1, RiskAssessment ras-1, the three "resolves to a contained Bundle" rules this guide states itself -- List nexus-template-entry-is-contained-bundle, Task nexus-sugg-2 and Questionnaire questionnaire-extract-bundle-is-contained -- and the three "that contained Bundle is a transaction" rules beside them: List nexus-template-bundle-is-transaction, Task nexus-sugg-3 and Questionnaire questionnaire-extract-bundle-is-transaction. Also newly checked, and an element rule rather than an invariant: Composition section.text.status, which R4 requires at 1..1 and which nothing here checked -- a section written as {"text": {"div": "..."}} passed this library and failed a full FHIR validation. The profile adds no constraint; it restates the base cardinality so the generated validators can see it. No profile changed. These are the same published rules, checked where they were previously only reported. The compiled FHIRPath subset gained membership (in), union (|), %resource, %ucum, substring(), numeric addition, boolean literals, trace(), (expr).not(), boolean equality, and the ability to evaluate a rule declared on an element below the resource root. What is still not machine-checked, and why, so the remaining gap is a stated one rather than an absence: CareTeam ctm-1 needs reference resolution (resolve()); Questionnaire que-2 and questionnaire-extract-is-bundle-only need a recursive descendants() walk; Observation obs-7, Condition con-3 and the two Patient -instances-clean rules need set algebra over projected values; Questionnaire que-7 and RiskAssessment ras-2 need element-level type tests (is / as against a datatype rather than a resource); Consent.category and Encounter.class bind value sets that cannot be expanded offline; and the DocumentReference attachment-content rule is verified at document assembly rather than per resource. All twelve are still enforced by the HL7 validator and by any conformant external validator, and all twelve are still reported as invariant-unverifiable at runtime rather than silently skipped.
BREAKING: the block-kind binding is extensible, and a reader must write an unknown kind back unchanged. Note Block Types bound required through 1.21.x, and 1.21.1 stated the consequence in as many words: the vocabulary was closed, and a client reading a section whose kind was ahead of its own read and rewrote that section as text, losing the kind. That rule is withdrawn. The binding is now extensible, and Note Block Type carries two more codes beside text -- merge-field-body (the letter composer) and cited-claims (the summary graphs). Why it changed. required made this guide a release gate on the editor: ship a block kind and every note carrying one is nonconformant until the IG cuts a release, which is not a dependency a specification should impose on the software it describes. It also did not protect the record. A reader that cannot represent a kind writes the section back as text, so closing the set converted "a kind this guide has not named" into "a kind the record no longer holds". Consumer action: a reader built to 1.21.1's rule must stop rewriting an unrecognised block kind as text. Render it as text -- there is no widget for a kind you do not know, and section.text is authoritative, so nothing clinical is lost -- then write the code back unchanged. Display and storage are different decisions. A reader that keeps collapsing unknown kinds destroys merge-field-body and cited-claims on every round trip. Rendering an unrecognised kind as text is correct; storing text in its place is data loss. A writer whose kind is named in the value set uses that code rather than a synonym; a writer shipping a kind the guide has not named yet is conformant carrying its own.
The block-type extension is the RENDER axis, not the authoring tool -- and this corrects how 1.22.0 described it earlier in its own development. A section answers three independent questions and each has its own element: what it is clinically (section.code), who produced it (section.author, which already admits Device), and how to render it (composition-block-type). Read the last as "which editor widget wrote this" and a letter and a generated summary have no kind at all, and a consumer is forced to infer rendering from author, which answers a different question. Keeping the three apart is what makes an encounter note, a letter and a summary the same object: a problem-list section is 11450-4 whoever produced it, and a claims section renders identically however it was assembled. No constraint changed -- the definitions did.
composition-block-data carries an Attachment, not a JSON string. contentType makes the envelope readable even where the contents are not described here; a JSON string in a valueString is self-describing to nobody, and no published international IG carries structured state that way. Reach for SDC first: where a render kind is really a form (vitals, diabetes review, flowsheet), a Questionnaire plus a QuestionnaireResponse is the modelled answer and gets section.entry for free. Consumer action: a writer emitting valueString must move to valueAttachment. Nothing is filed against this extension yet. Also states plainly that unreadable is not absent
BREAKING: Composition.type and Composition.category swap roles. type is the CLASS and the element to switch on. type (1..1) binds Composition Classification extensible and carries exactly one of three LOINC codes: 34109-9 "Note", 34133-9 "Summary of episode note", 51852-2 "Letter". category (0..) binds Composition Kind preferred and carries the refinement underneath -- which kind of note (11506-3, 11488-4, 18842-5, 34117-2, 34748-4), which kind of summary (the codes in nexus-composition-type). Composition.section.code binds the new Composition Section extensible, unchanged. Earlier drafts of this release had these two the other way round, and told readers to classify on category. That was wrong, and the reason is structural rather than a matter of taste: type is 1..1 in base R4 and cannot be relaxed, so it is the only element guaranteed present on every Composition. The one question every consumer must be able to answer -- am I rendering clinician-authored content or machine-generated content -- has to live there. category is 0.. and may be absent, which makes it the right home for refinements a producer may or may not know, and the wrong home for the distinction nobody can afford to miss. Consumer action: switch on type, and search on it. A search for every summary a patient has, of every kind, is type=http://loinc.org|34133-9. Reading category alone will miss documents. Producer action: write the class on type and the refinement on category. A progress note is type = 34109-9 with category = [11506-3]. A day-sheet summary is type = 34133-9 with category = [nexus-daysheet-summary]. Converters need remapping: OSCAR sends LOINC 11488-4 "Consult note" on every casemgmt_note whatever the note is, and that is a refinement code -- it belongs on category, with the real class written to type. Repeating the type code on category is allowed and is the ordinary thing to do where a document has no kind finer than its class. The refinement set is a strict superset of the class set so the repeat always validates, and a build gate enforces that nesting rather than leaving it to prose. section.code is bound for the first time, and extensible on purpose. LOINC supplies both document codes and section codes out of one system in one format: 34109-9 ("Note", a document) and 8716-3 ("Vital signs", a section) are indistinguishable as data, so a document code in the section slot is a mistake the format itself cannot prevent and no reader can detect after the fact. Preferred would document the vocabulary and warn on nothing; extensible warns on a code outside the set, which is exactly what a document code there is. A legitimate section kind the set does not yet name will also warn -- accepted, because growing the set is one line and the alternative is catching this by eye forever. The strengths are asymmetric on purpose, and the stronger one sits on the smaller vocabulary. type is extensible because its set enumerates the class axis completely -- note, summary, letter is the whole space -- so a code outside it is nearly always a refinement written into the class slot, which is worth a warning. category is preferred because LOINC's document axis is large and no set here enumerates it: a producer holding a more precise code should use it without being penalised for the precision.
The narrative/structured contract is written down on Composition, and it is the most load-bearing rule in the profile. A section carries its content twice on purpose: the structured data is the display path for this EMR's UI, the narrative is for everyone who is not that UI. A renderer shows the structured data and ignores the narrative -- nothing appears twice. The consequence is that both sides must be complete: anything the UI needs must be structured, and anything clinically meaningful must also be in the narrative, including negatives. "No active problems" is a finding, not filler. Booleans and scalars count -- a value living only inside a structured payload leaves every consumer who is not this UI reading an incomplete document.

Nexus IG 1.21.1

Wed, 26 Aug 2026 00:00:00 +0000

The CQL toolchain is now embeddable from .NET and Python, so the chain this specification documents -- CQL in; validated ELM, a module-definition Library and a manifest out -- runs in-process from all three client languages with no service to deploy. One translator is embedded rather than reimplemented per language: every additional engine that can decide what a criterion means is a new authority on clinical semantics, and such engines diverge exactly where it shows least (null propagation in three-valued logic, interval boundary inclusivity, timezone handling at date boundaries, unit conversion). A divergence of that kind inside a signed clinical rule is a patient-safety problem rather than a bug. The surface is opt-in in every language -- @awaremd/typed-fhir/cql, Well.Services.TypedFhir.Cql, typed-fhir[cql] -- so a consumer who wants a facade, a patient cache or a FHIR query starts no engine and acquires no language runtime. Which of the three are published today is stated in Evaluating one patient; consumers of compiled criteria need none of them and a JSON parser is enough.
Three extensions that let a criteria artifact carry what its ELM cannot say. A module-definition Library says which resources a criterion needs; it does not say which of their elements the logic reads. Criteria Elements Read records one element path per repeat, relative to the resource retrieved. That is finer-grained than dataRequirement, which bounds which resources are fetched rather than which of their fields have to be materialised for the logic to evaluate -- so a consumer projecting a narrow view can size it from the artifact instead of from the CQL. It is a lower bound: derived from retrieves and property accesses, without inference across included libraries, so an absent path is not proof the logic never reads it.
Criteria Relative Date says whether a criterion's membership can go stale on its own. true means the logic is anchored to a moving reference point ("no visit in the last six months"), so membership changes with the clock and a periodic re-evaluation is required; false means it changes only when data changes, so a change feed is sufficient. A consumer deciding whether to schedule re-evaluation reads this rather than inferring it from the logic.
Measurement Rationale, required on every measurement definition, records the specific ambiguity or unit trap that definition prevents. The failures it guards against -- affine unit conversions, off-by-one ordinal scales -- produce numbers that render and validate while being wrong, so a definition that cannot name the failure it prevents is a guess. R4's ObservationDefinition has no narrative element, which is why this is an extension; it retires into description on a move to R5.
The CQL model this specification is authored against, published as an artifact. nexus-cql-modelinfo carries the generated Nexus ModelInfo, so a criteria author writing using Nexus version '' can fetch the model from the specification rather than reconstructing it from the profiles.
CQL is now a documented part of this specification, with a companion page on criteria artifacts covering the boundary that surprises implementers most: you do not need a CQL compiler to consume clinical logic from this specification. Translation happens once, when a criterion is authored. Everything downstream reads JSON.
The Patient profile gains the Indigenous fields. This entry was written when the work merged and was missed when 1.21.1 was cut, so it is recorded here late. The Indian Act registration or status number is a Patient.identifier under the Canadian URI Registry's official system (.../NamingSystem/ca-indigenous-northern-affairs-number): a 9 or 10 digit value, or a data-absent-reason while other card facets are recorded before a number is. The identifier's validity period carries the card's issue and expiry, and the new Indian Status Card Type extension on the identifier carries the presented document form: SCIS, CIS or TCRD. Three optional flat extensions carry the rest: Indian Act Registration Status, and the First Nation Registry Group and First Nation Community affiliations, the latter two coded from the curated seed-managed band list (the code is the federal band number). Every field is independently recordable, and each records what the patient states rather than anything verified against the Indian Register. A recorded expiry does not imply a change of registration status.
Five profiles now declare the element a bare CQL retrieve filters on, via HL7's own cqf-modelInfo-primaryCodePath extension: DocumentReference, ImagingStudy, Invoice, Schedule and Slot. Base R4's own CQL ModelInfo declares no primary code path for these five, and the consequence is not a compile error: [Invoice: "some-code"] compiles, the translator only warns, and the criterion silently filters on nothing while its data-requirements manifest emits a codeFilter with no path -- which violates FHIR's own drq-1 invariant. Authoring against this specification's model makes the natural form correct rather than merely accepted.
Declared the two extensions a block-authored encounter-note section carries — Composition Block Type and Composition Block Data — which the EMR has been writing undeclared, together with the Note Block Type code system and Note Block Types value set the first of them binds. This is the block surface returning on the terms 1.14.0 set for Composition itself: there is a committed consumer. It is not the shape 1.11.0 withdrew — one section per block on R4's own section ordering rather than recursive containment, and two flat extensions rather than the sliced complex one whose slicing was among the unevaluable-slicing defects that removal cleared. It does enumerate block kinds as nexus-emr-embedded-section-types did, and the difference is what is enumerated: one kind that has shipped, rather than four that had not.
The block-kind vocabulary is closed, and a kind outside it is not preserved. The binding is required and every block-authored section declares its kind, text included. A client reading a section whose kind is ahead of its own reads and rewrites it as text: narrative, heading, identity and structured value survive, the kind does not. That is a deliberate trade — a specification that can describe everything the record holds, against forward compatibility with writers that are ahead — and deployments spanning versions should upgrade readers before writers. A section carrying no kind at all predates the extension and reads as text; that is tolerance for legacy data rather than a default, and is retirable once no such section remains.
Both extensions are published under this IG's canonical base, https://fhir.apps.health. They were first drafted at the address the EMR front end already wrote (http://services.well.com/fhir/StructureDefinition/...), on the reasoning that declaring a URL nothing emits would document a fiction. That was settled the other way before publication and the front end moved: published canonical URLs are forever, and reconciling the namespaces was cheapest while no note carrying either extension had been filed. One open question remains, and it is a modelling question rather than a naming one: a block's editor state is carried as a JSON-encoded extension rather than in section.entry.

Nexus IG 1.21.0

Tue, 25 Aug 2026 00:00:00 +0000

This release contains a breaking change.

CodeSystem/nexus-emr-suggestion is deleted. It shipped in 1.20.0; its canonical no longer resolves, and stored Coding.system values pointing at it are now unresolvable. Both its codes moved -- see Removed.
Task.code no longer accepts suggestion. A search for Task?code=...|suggestion returns nothing after this release.
Task.status binds a required subset. requested, received, rejected, failed and entered-in-error are no longer conformant. Every stored task carrying requested needs rewriting to ready.
Every stored template needs reshaping, and so does every stored suggested-resource task: the prototypes move into a contained transaction Bundle.
Every stored form needs the same reshaping, and its per-item templateExtract extensions removed. NexusEmrCoreQuestionnaire now prohibits that spelling -- prototypes are entries of the Bundle named by templateExtractBundle. See Added.
AIAST binds producers and is not retroactive. Nothing backfills it, so an absent label means unknown, not human until every producer applies it. Read it as evidence a machine was involved, never as evidence one was not.
Nine categories for Task.code -- reminder, call, appointment, review-report, prevention, referral, billing, medication, other -- in the new Task Codes value set, bound extensibly. review-report is named for the work rather than the source on purpose: diagnostic imaging and other non-laboratory reports arrive on the same inbound stream, so a category called lab would either exclude them or quietly redefine lab. (FHIR-71)
A required subset of TaskStatus (Clinical Task Statuses): draft, ready, accepted, in-progress, on-hold, completed, cancelled. These are meanings, not a path -- any state may follow any other, and ready straight to completed is an ordinary day's work. on-hold is present for snooze and pause. (FHIR-71)
intent = #option joins the Clinical Task Intent value set, for a proposal that is one of a set of alternatives. Approving one moots its siblings, which are then cancelled with a statusReason recording that they stopped being on offer rather than that anyone declined them. Additive: no existing writer changes. (FHIR-71)
CodeSystem/nexus-task-input-type, giving Task.input.type a published label for the one slot a consumer branches on: suggested-resource, which points at the contained Bundle. The element stays otherwise free-text. (FHIR-71)
A priority below routine, as the priority-detail extension carrying trivial. Task.priority binds required to request-priority, whose floor is routine, and a profile may only strengthen a binding; the element is also a bare code with no second coding slot. So the refinement rides beside it under a rule that makes it safe to ignore: when the extension is present Task.priority shall be routine, so a consumer that does not read it under-states the task rather than mis-sorting it. (FHIR-71)
NamingSystem/nexus-cds-card, the identifier namespace for a decision-support card. One evaluation raises several proposals; each is its own Task, and every member carries the card on groupIdentifier so the set comes back from one Task?group-identifier= search with no parent resource. Values follow the harness key's rule -- derived from the gap the advice addresses, never from the evaluation that produced it. (FHIR-71)

Nexus IG 1.20.0

Mon, 24 Aug 2026 00:00:00 +0000

This release contains a breaking change.

The package id is nexus, not nexus-emr -- one line in your dependency declaration. No canonical in the namespace changed and nothing in stored data moves.
The DIN code system URI moves, and that one IS in stored data, on MedicationRequest.
279 accessors change return type. Audit for .coding / .system / .code / .id reached directly off an accessor named in the table under TypedFhir libraries.
validate() is stricter twice over -- unknown elements now error, and twenty-two base-R4 required bindings are enforced that previously could not be read. Run your corpus through it before upgrading.
A Referral profile -- the IG could not describe a referral, and now can. NexusCoreReferral (https://fhir.apps.health/StructureDefinition/nexus-core-referral) is a new ServiceRequest profile for a request that another clinician or service take the patient on. It is additive: NexusEmrCoreServiceRequest is unchanged in every constraint, so laboratory and imaging orders keep the guarantees they already had. A referral could not claim the order profile, and this was not a near miss. That profile fixes intent = order, binds category (required) to the five-concept base FHIR value set, and requires code 1..1. A referral is intent = proposal -- the referrer asks a receiving service to accept the patient and has no authority over whether it does -- its category is the receiving service or specialty, which that five-concept set cannot express, and the Ontario eReferral contract sends no code element at all. Three constraints, three mismatches. The new profile is a sibling derived from base R4, not a child of the order profile: a derived profile may tighten its parent but never loosen it, so a fixed order and a required binding are not recoverable downstream. intent is fixed to proposal, category is 1.. bound extensibly to the new NexusReferralServiceType value set, code is 0..1 with an invariant requiring code.text when it is present, and requester is required. A second invariant, referral-category-coded, asks for at least one SNOMED coding on category at warning severity rather than error, for the same reason the binding is extensible: destinations do arrive with no usable code, and the right answer for one of those is to carry the text rather than map it to an approximate neighbour, because an approximate destination routes the patient approximately. This aligns with the pan-Canadian and Ontario standards rather than inventing beside them. CA-eReC fixes intent = proposal and requires requester and authoredOn; the Ontario eReferral profile derives from CA-eReC; this IG already carries ca.on.erec.r4 as a pinned dependency. Two divergences are deliberate and documented on the profile itself: performer stays 0.. where CA-eReC requires it (that profile governs electronic messaging, where a destination is definitionally known, while this one also covers referrals recorded in the chart that were never sent electronically), and category does not adopt CA-eReC's binding -- see below.
A NexusReferralServiceType value set for referral destinations, mirroring Canada Health Infoway's active ReferralServiceCategoryCode over SNOMED CT Canadian Edition reference set 379431000087101. It is deliberately not called a specialty value set, and that is not cosmetic. Several destinations a primary-care referral routinely targets exist in SNOMED CT only as service concepts, with no specialty concept at all -- Sports medicine, Sleep medicine, Spinal surgery and Clinical neurophysiology among them. A specialty-only value set cannot describe the destinations this EMR already offers, which is why Infoway's set is a union of healthcare services and provider specialties. Implementers building a destination picker should expect both kinds of concept and must not filter to the specialty hierarchy. CA-eReC's own category binding is not adopted. It binds InterventionCodeSubsetCare, which represents "the care procedures performed by a Provider" -- an intervention taxonomy, which is what code means, not the destination category carries -- and which Infoway retired in April 2026 along with the Primary Health Care EMR Minimum Data Set, marking it "not recommended for continued use". code is therefore left with the base R4 binding until Infoway publishes a replacement. The binding is extensible, not required, and that is load-bearing rather than a hedge: Ocean sends 17561000 |Cardiologist| -- an occupation concept -- in category, and it is not a member of this value set. A required binding would make the referrals actually received non-conformant. Preserve the source coding exactly as received and add the Nexus coding alongside it in the same CodeableConcept; do not rewrite or drop the original. The new handbook page covers the Ocean relationship and the coding guidance in full, and the shipped example demonstrates the dual-coding pattern.
A Questionnaire profile, and forms are now the same mechanism as letter templates. NexusEmrCoreQuestionnaire closes the half of forms the IG never modelled: it profiled the answer set (QuestionnaireResponse) and not the form that produced it, so a response pointed at a definition the spec did not govern. The profile requires url and version -- a response is only interpretable against the version it answered, because the question text, item types and answer options all live in the form -- and binds answers to the chart through item.definition and item.code rather than a private extension. The structural news for implementers is that a form and a template are one mechanism. Both carry contained prototypes of what they produce and are instantiated by cloning them and filling in what the definition could not know; they differ only in what drives the fill (a QuestionnaireResponse, or an instantiation context). The handbook's Templates page now documents that once for both, and each profile page points at it. Named as not settled rather than approximated: approximate dates and durations (a real clinical requirement with no FHIR datatype), body diagrams, note generation, and FHIRPath expressions. SDC extraction is governed by two invariants, and nothing checks them at runtime. (Both were removed in 1.21.0 along with the spelling they governed -- see that release. Named here without links, because the anchors they had are gone.) questionnaire-extract-templates-are-contained requires every sdc-questionnaire-templateExtract to target a prototype contained in the form, and questionnaire-extract-templates-resolve requires that #id to resolve. Both traverse descendants().ofType(Extension), which reaches the root's own extensions, so an extraction at the form root -- the ordinary case -- is examined rather than passing vacuously; and both read the prototype from the complex extension's template sub-extension (extension('template').value.ofType(Reference)). SDC prohibits Extension.value[x] on templateExtract itself, so a form carrying valueReference there is not valid SDC and does not pass. Both are declared #error and both sit on the runtime allowlist, as do base R4's que-1, que-2, que-7, que-10 and que-13: the HL7 validator enforces all seven against this IG's examples and validate() enforces none of them. If you author forms programmatically, run the published validator or check containment yourself. The profile ships with a worked example, and the extraction rules were mutation-tested in both directions -- a stored-resource target and a dangling #id each fail the rule that should catch them, and a conformant root-level and item-level extraction each pass.
Medications now carry drug identity at TWO levels, and all three medication resources carry the same model. MedicationRequest, MedicationStatement and MedicationDispense each slice the medication concept's coding into din, ccdd, atc and aign. A DIN identifies one manufacturer's marketed product; CCDD (http://terminology.hl7.org/CodeSystem/hc-CCDD) and ATC (http://www.whocc.no/atc) identify the ingredient. Every cross-record question is an ingredient-level question -- are these two prescriptions the same drug, is this duplicate therapy, does this medication match a recorded allergy -- and a DIN cannot answer any of them, because the same drug from a second manufacturer carries a different DIN and a change of salt changes it again. Until now the spec offered a DIN slot and nothing else, and only on MedicationRequest; the other two named code systems in prose that constrained nothing. Nothing here is required and nothing existing is invalidated: every slice is 0.., the slicing is open, text remains the only requirement on the concept, and instances carrying no coding, or an unsliced one, stay conformant. Consumer action, if you write these resources: carry the ingredient-level code the source actually has, alongside the DIN rather than instead of it. Do not synthesize one that was not given to you. The aign slice carries Health Canada's DPD active-ingredient group number (http://terminology.hl7.org/CodeSystem/v3-hc-aign, published through HL7 Terminology and resolvable from the hl7.terminology.r4 package this IG already depends on), and it is the one to reach for when there is no CCDD -- in practice most legacy EMR medication lists, where a DIN and a line of free text is all that exists. It gathers products sharing an active-ingredient composition across manufacturer and salt form and covers the whole DIN space, so it is reachable from a DIN when neither CCDD nor ATC is. The number is ten digits and it decomposes, which decides which of two systems a record should carry: [2 digits: how many active ingredients][5 digits: which active-ingredient group][3 digits: which strength group]. The full ten-digit number is therefore strength-specific, which is what a prescription, a dispense and a medication statement mean -- so the medication profiles bind it. AllergyIntolerance binds the five-digit middle portion instead (http://terminology.hl7.org/CodeSystem/v3-hc-aigc), because an allergy is to an ingredient and not to a strength. To match a medication against an allergen, compare positions 3 through 7 of the medication's number to the allergen's code -- they are different systems and different lengths, and comparing them as equal strings never matches.
AllergyIntolerance.code now has a drug-allergen path, via ccdd, atc and aigc slices on code.coding -- the same posture as [Condition.code.coding[icd10ca]](fhir/StructureDefinition-nexus-emr-core-condition-elements-details.md#el-Condition.code.coding-icd10ca) and [Procedure.code.coding[cci]](fhir/StructureDefinition-nexus-emr-core-procedure-elements-details.md#el-Procedure.code.coding-cci), where the IG declares the slot and the system and does not enumerate codes. The element previously required code.text and mandated no system at all, which left no join key between an allergen and a medication: matching meant string comparison over clinician-typed free text. An allergen coded with CCDD, ATC or the DPD active-ingredient group is now matchable against a medication coded the same way -- the three medication profiles slice the same systems, because a join key has to be sliced on both sides or it does nothing. The one exception is the active-ingredient group, where the allergen slice binds the five-digit code (v3-hc-aigc) and the medication slices bind the ten-digit number (v3-hc-aign): an allergy is to an ingredient, not to a strength, and matching the two means comparing positions 3 through 7 of the number to the code rather than comparing the two values directly. There is deliberately no din slice. A patient is not allergic to a marketed product, they are allergic to what is in it; a DIN-to-DIN comparison misses the same drug from another manufacturer and misses a different salt of the same ingredient, so a DIN slot on an allergen would look like a join key while silently failing the cases the join exists for. All three slices are 0.. and the slicing is open, so existing allergy records are unaffected.
Every code system this specification binds now has a page that says what it is. The profiles pin thirty-four system URIs. Some were minted in this specification's own namespace and defined nowhere, so following one reached nothing; the rest were third-party systems with no statement of what they are, who publishes them, or where an implementer gets the codes. Both gaps are closed by nineteen new artifacts, and a pinned .system value on a profile page is now a link to the page describing it rather than a bare URI. Five artifacts define URIs this specification mints: a CodeSystem for the OHIP Schedule of Benefits (.../CodeSystem/on-ohip-schedule-of-benefits, content = not-present -- the system is declared, the Ministry of Health's fee codes are not reproduced), and NamingSystem resources for the OHIP billing number, the Ontario RMA / group billing number, the Ontario Service Location Indicator and the patient MRN. Each says what the identifier is, who assigns it, and what it does not mean -- the MRN page in particular, because an EMR-local chart number is unique only within the deployment that issued it and must not be used to match patients across systems. Thirteen third-party systems get a ValueSet in this specification's namespace (.../ValueSet/all-), each a single include of the whole system with no codes enumerated: LOINC, SNOMED CT, UCUM, ICD-10-CA, CCI, DIN, CCDD, ATC, the two Health Canada active-ingredient group systems, the HL7 identifier-type codes, NullFlavor and data-absent-reason. Each page states what the system is, who publishes it, its canonical URI, where to obtain the codes, and where a licence gates use (ICD-10-CA and CCI are CIHI-licensed; SNOMED CT requires an Affiliate licence). No CodeSystem is published at a canonical this specification does not own -- a second definition of a canonical its publisher already serves is how one identifier acquires several spellings, so these claim no foreign canonical and redistribute nothing. The internal EMR user-account system gets a NamingSystem rather than a value set, because it names an identifier AUTHORITY and not a terminology: there is no concept list to point at and the values are opaque account ids, so "every code in the system" would be a category error. Its page says what the profiles already say -- it is private infrastructure and external consumers must not depend on it. Where the publisher's terms allow it, the page also shows a sample of the codes -- up to 500, spread evenly across the system rather than taken off the front, with the size of the population they came from stated above the table and again below it, so a list that stops at 500 cannot be read as a complete one. Nine systems qualify: LOINC, DIN, the two Health Canada active-ingredient group systems, ATC, UCUM, and the HL7 identifier-type, NullFlavor and data-absent-reason codes. Each carries the attribution its licence requires. The LOINC sample excludes every term carrying a third-party copyright notice -- 7,355 of them, mostly scored assessments and survey instruments whose questions belong to someone other than Regenstrief. The LOINC licence would allow reproducing those provided the notice travelled with them; dropping them instead means no third-party instrument text is republished here at all. Where the terms do not allow it, the page says so and says whose terms decide it. No ICD-10-CA, CCI or SNOMED CT code is reproduced anywhere in this specification, and none will be: rendering codes onto a published page is redistribution, and those are licensed by CIHI and SNOMED International respectively. CCDD is withheld as well, because redistributing its content is a permission separate from the free use it grants. The list of systems whose codes may be reproduced is an explicit allow-list, so a system added to this specification in future publishes nothing until its terms have been read and recorded. This applies to CodeSystem artifacts that declare a system without carrying its content, not only to value sets -- from a reader's point of view they are the same page, so they answer the question the same way. OHIP fee codes are among the ten, on the King's Printer's legal-materials permission: the Schedule of Benefits is incorporated by reference into R.R.O. 1990, Reg. 552 under the Health Insurance Act, and the King's Printer permits anyone to reproduce the text contained in Ontario's regulations without permission or charge, provided the reproduction is accurate and is not represented as an official version. Both conditions are met on the page, which states in terms that it is not an official version and that the Ministry's edition in force governs. The sample omits the 406 codes that carry no published description in any schedule, rather than listing them against their own code.
A value set over one of this specification's OWN code systems now lists its codes in full. Fourteen pages -- appointment modality, clinical roles, province/territory, pay program, task business status and the rest -- said "All codes from this system" and then listed none, which is the least useful thing a page about a five-code vocabulary can do. These are not a licence question at all: the concepts are in this specification's own artifacts, so the page shows every one of them rather than a sample.
The OHIP Schedule of Benefits page now carries the ICD-9 warning about Ontario's DIAGNOSTIC codes. They are a separate Ontario code set with its own system URI, they are ICD-9-LIKE in shape, and they are not a subset of ICD-9 -- so an OHIP diagnostic code must never be derived by truncating an ICD-9 code. The 895-971 range is a parallel Ontario space laid over ICD-9 numbers that mean something unrelated: 970 is Prenatal Care in Ontario and poisoning by CNS stimulants in ICD-9. Measured against the Provincial Health Care Vocabulary Standard, a SNOMED CT to ICD-9 to truncate route reaches 69.4% of cases and 124 of them come out valid and wrong -- nothing downstream rejects them, so they reach a claim and the diagnosis on the record is not the one the clinician made. Eighteen codes carry two unrelated meanings within the Ontario set itself. The warning was in the specification's source and on no page a reader would find.

Nexus IG 1.19.0

Fri, 21 Aug 2026 00:00:00 +0000

This release contains a breaking change.

Two published vocabularies were renamed, and both breaks are in stored data. The suggestion code on Task.code is now suggestion, not ai-suggestion: a search for Task?code=...|ai-suggestion returns nothing after this release, and stored tasks carrying the old code fail nexus-sugg-2 until migrated. The note-classification value set is now nexus-emr-composition-classification: the old canonical is no longer bound by any profile, so rebind. Its page is NOT removed -- ValueSet-nexus-emr-note-classification.md is still published, status: retired, so an old bookmark still resolves and says what replaced it. Neither rename is recoverable by tolerating absence -- both need a migration.
Four elements that were required may now be absent, and readers must tolerate all four. Task.for, Task.identifier, Composition.identifier and NexusEmrCoreCareTeam.subject all relax in this release, each because the profile grew a population the requirement made unrepresentable. A reader that treats absence as malformed will reject valid records; one that lists a patient's care providers without filtering on subject will now show the nursing pool as a clinician. Going the other way, every Task.note turn now REQUIRES author and time, so a writer that emitted unattributed or undated turns must populate both.
A given seed does not reproduce the 1.18.0 dataset. The generator no longer opens a task's thread with a turn restating its description, and a requested follow-up task now emits no turns at all. Regenerate and re-baseline; 1.18.0 stays archived for byte-fidelity.
BREAKING: the suggestion code is suggestion, renamed from ai-suggestion (CodeSystem/nexus-emr-suggestion, used on Task.code). The old name asserted something the code does not carry. What made a suggestion "AI" was never this code — it is Task.requester, a logical Device reference under NamingSystem/nexus-harness-graph naming the graph that produced it. A deterministic CDS rule produces the same Task shape with a different requester, so the old name made every CDS recommendation read as machine-learning output. Consumer action: a search for Task?code=...|ai-suggestion returns nothing after this release; use ...|suggestion. Stored tasks carrying the old code do not match the nexus-sugg-2 invariant and must be migrated. Read Task.requester when the producer matters (AI graph vs CDS service) and Task.code when it does not. An earlier revision of the CodeSystem argued against this rename on the grounds that the code is a stored value — that traded a permanently misleading vocabulary for one migration, and while this specification is pre-release the trade was wrong.
BREAKING: every ClinicalTask.note turn now requires author and time. Each turn is typed to NexusEmrTaskNote, which makes required two elements that are optional in base R4. Consumer action: a writer that emitted unattributed or undated turns must populate both on every note, or the resource no longer validates. This entry used to lead with what did NOT change -- "typed to a profile and stays 0..; the ask is description" -- and put the breaking half in the middle of the paragraph. That is worth correcting rather than quietly rewriting, because the entry's own shape caused the damage. This file's preamble states the contract: a breaking change is named as breaking, in bold, with the consumer action spelled out. A reader skimming bold headlines for what would break saw a reassurance about cardinality and moved on. The note-model fallout in this release traces back here. The cardinality does not change. An earlier revision of this release made note 1.. and declared note[0] the opening ask. That is withdrawn before it ships, and the reasoning is worth recording because it was wrong in a specific way: it treated description as a mere label when description is required on this profile and IS the ask — what is wanted and why the task exists, stable for the life of the task. Requiring a turn on top of it bought nothing and cost every writer a duplicated one, storing the same statement twice and opening the thread with something nobody actually said. note is what has been said since the task was created; a task nobody has commented on carries none, which is the ordinary state of new work. Consumer action: read description to answer "what is this task about" and note to answer "what has been said about it". Render an empty thread as new work, not as a malformed record.
BREAKING (seed data): a given seed no longer reproduces the 1.18.0 dataset. Two generator changes alter what a thread contains, and both follow from the Task.note model above rather than from any new decision: the generator no longer opens a task's thread with a turn that merely restates its description, and a requested follow-up task now emits no turns at all. A task nobody has commented on carries no notes, which is the ordinary state of new work. Consumer action: regenerate and re-baseline anything pinned to generated output -- fixtures, golden files, benchmark stores, screenshots. The change is in the CONTENT for a given seed, not in the generator's determinism: same seed still means same dataset, and test:seed-stability in the generator suite is what holds that. 1.18.0 stays archived for byte-fidelity if you need to diff against the old shape. This was listed among the three things to read before consuming 1.19.0 but had no entry of its own down here, so the detail a reader needed in order to act on it -- which two behaviours changed, and that determinism itself is intact -- existed only as a one-line summary.
TypedFhir (Python) gains a FHIR REST client (Jira PSD-1141, "Writeback of compositions" — not to be confused with GitHub PR #1141, which is the 1.18.0 release this branch is stacked on; the numbers collide by coincidence). typed_fhir.sources.fhir_client.FhirClient ports the frontend's fhir-client.ts API to Python — same operations, snake_case names, same error contract (a failed search returns a Bundle wrapping the OperationOutcome per R4; a failed direct request raises it). This is what makes generated-summary writeback possible: create_resource / update_resource arrive as part of a client rather than as another hand-rolled POST. No third-party FHIR library, deliberately: they all own their own HTTP call, and this package's determinism depends on that not being owned (connectors build requests and parse responses with pure code; only bytes cross the Transport seam, so a run replays against the frozen vectors). Credentials here also resolve per request from context — the harness sets a delegated bearer and tenant per run — which a client that binds authorization at construction cannot express. Both read postures moved onto the client with their measured knowledge intact: the degrading compartment sweep (one broken type must not cost the chart) and the loud single-query load (a truncated inbox is missing work items, not a smaller page), plus next-link rebasing with all three of its hard-won exceptions, the HTTP-200-carrying-a-refusal check, and a page cap that is always reported. Public API unchanged: search_paged, next_link and rebase_next keep their names and import paths. PHI: error messages carry issue.code only — a HAPI OperationOutcome echoes the offending resource into diagnostics, so the text rides on the exception, never in a log-bound message.
BREAKING (TypedFhir Python): the FHIR client's API is brought in line with fhir-client.ts. Its docstring has always said it mirrors the frontend client; it was about 70% true, and the differences were spelling rather than substance. get_resource_by_link now takes (resource_type, url) like the reference (and like every other method here) rather than the reverse; update_resource takes a FhirUpdateOptions bag instead of if_match: str | bool; search_errors and wrap_operation_outcome_in_bundle are instance methods, not @staticmethod; and every search entry point accepts an ordered sequence of pairs, not only a mapping — a date window (date=ge…&date=lt…) was previously expressible in exactly one of the four. Consumer action: update those three call shapes. There were no consumers outside this package's own tests when the change landed, which is why it was made now rather than deprecated.
TypedFhir (Python) gains the write and read surfaces the harness needs, all mirroring the frontend: FhirPreconditionFailedError (a 412 is the one write outcome a caller must handle differently — nothing was written and retrying unchanged will be refused again — and it was previously only recoverable by sniffing a status code); save_resource, routing create-vs-update on id presence; bundle_entries / bundle_entries_or_raise / has_error_issues, mirroring BundleUtils, where the _or_raise form puts the HTTP-200 refusal check in the same call as the entry filter so it is no longer one a caller can forget; get_version / get_history_page / get_history; and FhirDocumentDataClient for attachment bytes, which streams and enforces its size cap while downloading rather than after. save_by_business_key is the AgentWriteFhir contract in one call — search by identifier, then update in place or create — so re-running a capability updates the same Task or Composition instead of piling up a rival. It writes the key onto the resource (a key you searched by and did not store finds nothing next time), carries the stored meta.versionId forward so the read-then-write stays conditional, and refuses when a key matches more than one resource rather than picking a side. FhirClient(base_url) is now the whole call: the transport defaults, and credentials default to the delegated bearer and tenant in the ambient context.
TypedFhir (Python): PatientCache can drive a client, not only be handed a list of resources — search / load_all / count / load / get_or_load / load_by_link / load_version / load_history / save / save_as_global / delete_by_id / upsert / evict / clear, plus on_write / on_read / on_delete listeners. This is the frontend's FhirStoreBase half that had no analogue here. Two things the stores need that it does not: a store registry (one cache holds every type, so an _included resource lands beside the one that included it with no routing) and per-type store classes (the type is an argument and the local query is resources()). A search the server REFUSED raises rather than merging nothing — a tenant refusal arrives as HTTP 200 with an empty searchset, and merging that silently leaves a cache reporting an empty chart.
TypedFhir: starting a resource is a constructor call. Observation.new(status="final", …) and new_resource("Task", …) replace hand-writing {"resourceType": "Observation"} as the entry point to a typed API. Fields pass through the setters, so a code outside its required binding is refused at construction. What comes back is deliberately incomplete — you are still building it — and missing_required() answers "what does this still need", returning the IG path plus the accessor to set it with, read off the profile validator rather than the curated field table so it cannot report "nothing missing" about an element the facade does not happen to type.
TypedFhir: subject and patient are curated. No profile in the IG had a subject accessor — they sat on the generator's global skip list, a rule that only ever held for READING (inside a patient cache the subject is a given). It stopped holding when the facade gained a construction path: a new Observation must carry a subject, and with no accessor the only way to set one was raw JSON. 24 profiles gain a typed subject and 6 a typed patient, in all three ports. identifier stays uncurated — it is reached through save_by_business_key.

Nexus IG 1.18.0

Wed, 19 Aug 2026 00:00:00 +0000

Effective dates CHANGE for Compositions that carry an event. The walker fix below means event.period.start finally wins over date, as 1.17.0 declared it should -- so windowing, recency sorts and anything cached off an effective date will move for exactly the notes where the two dates differ. That is the fix landing, not a regression; recompute rather than reconcile.
A given seed does not reproduce the 1.17.0 dataset. The generator emits the letter template and the clinic-site Location, and profile identities moved. Regenerate and re-baseline; counts and shapes are stable, individual values and ids are not. 1.17.0 remains published and archived if byte-fidelity is needed.
The Template profile's canonical is nexus-template-list, renamed before first publication
Templates are served, validated, and discoverable: List joins the declared surface (FHIR-53, FHIR-52). Three things move together, because the profile's own gate said they must:
typed_fhir.subscriptions: change notifications join the library (PSD-1039). A SubscriptionClient over a transport seam -- the Redis change stream (at-least-once, consumer groups, dead-letter stream) or a real FHIR Subscription rest-hook (FhirSubscriptionTransport + NotificationSink) -- with criteria parsed and validated against the subscriptions CapabilityStatement at construction, so an unsupported criteria raises before the loop starts and never registers as a subscription that quietly matches nothing. Hardened by four review rounds before this entry was written, and the last one matters to consumers: notification Bundles batching several events now deliver EVERY event (not just the first); a bare status ping is never delivered as a clinical event; on the rest-hook transport a failed handler dead-letters immediately (rest-hook cannot redeliver, so "retry by not acking" was a silent drop); criteria follow R4 escaping in full, + is a literal, and identifier matching requires the :identifier modifier (owner:identifier=system|value; keyword form owner__identifier=) -- the plain form is refused at construction because it matched over Redis and matched nothing on a conformant server. Date eq is containment (date=2026-08-14 does not match a resource dated 2026) and string search is case-insensitive-prefix, both per R4, so client-side and server-side evaluation of the same criteria string cannot diverge.
The reference loaders verify instead of trusting, measured against a live store (FHIR-52). The cross-patient searches refuse to present a security refusal as an empty result (the gateway answers a cross-tenant read with a 200 carrying an error OperationOutcome -- that raises now), refuse truncation at the page cap, and gate the inbox loader's client-side fallback on the exact status: 400 falls back, 404 raises, and a 403 -- both NativeFHIR's answer to the unsupported :identifier modifier AND the gateway's insufficient-scope answer
The effective-date walker descends arrays, in all three ports (FHIR-52). The declared precedence event.period.start | date (1.17.0) named the one ARRAY-VALUED path in the table, and no port's path walker could traverse an array -- so the declaration was inert at runtime and every consumer silently windowed on the authoring date, the exact wrong answer it was written to prevent. Found live: a note carrying both dates returned the wrong one. Fixed with an identical first-present-wins array-descent rule in TypeScript, Python and C#, pinned by tests in each.
load_harness_inboxes on the Python source connectors: every AI-harness actor's inbox in one call (FHIR-52). All Task resources owned by a harness graph -- an identifier under the nexus-harness-graph NamingSystem -- plus each Task's basedOn clinical targets and its for Patient, as one flat list of raw FHIR. Because harness actors are LOGICAL Device references (identifier-only, no Device resource on the server), the query is an owner:identifier search, and the connector VERIFIES the modifier was honoured rather than trusting it: a backend that ignored it would answer with every Task in the store, and presenting those as inboxes would be silently wrong, so an all-stray result refuses loudly instead. Only the WellServices FhirGateway connector implements it. The query is cross-patient, so it is not a compartment fetch; every other source raises NotImplementedError naming the connector that can. The returned resources can be wrapped with TypedFhir facades (typed_fhir.facade.generated.wrap) for typed access -- but note that nothing yet takes this FHIR and sorts it into per-actor inboxes for the AI harness; that consumer has not been written.
load_daysheet on the Python source connectors: one practitioner's day, appointment cut only (FHIR-52, SD-201). Appointments for the day, the practitioner's Schedules, and those Schedules' Slots inside the day — three standard R4 searches, paged, results VERIFIED against the practitioner and the day window rather than trusted (a backend that ignores a search parameter answers with everyone's appointments; an all-stray result refuses rather than presenting someone else's day). WellServices FhirGateway only, like the inbox load — the query is cross-patient. This supersedes the TS day-sheet read that 1.17.0 said had "moved to 1.18.0." That prototype tried to make one loader answer both "who is coming" and "what is their story", and hunted an Appointment→Task edge this IG forbids; it will not ship. The corrected model splits the two questions: load_daysheet answers WHO is coming, and opening a patient is a separate fetch_resources(..., since=...) anchored by last_encounter_date (below), per visit, when the chart is opened. Patient depth is deliberately absent from the day sheet.
since on Python patient loading: a history window over date-oriented elements (FHIR-52). fetch_resources / fetch_resources_lenient accept since=; a resource whose IG-declared effective date falls before it is dropped, and a resource whose profile declares NO effective date (Patient, Coverage, Device, ...) is always kept -- undated context is not history. The filter reads effective_date_of, the same event.period.start | date precedence every facade reads, so the window and the facade cannot disagree about when something happened. Precision is handled inclusively: a year-only date the anchor cannot place is kept, because a summary that silently dropped it would misinform where including it merely over-shares. Server-side date windowing was removed from this connector in an earlier release because no caller could supply the anchor. The anchor now exists (below); the filter stays CLIENT-SIDE, where one implementation serves every connector. Bandwidth is not saved; correctness is.
last_encounter_date: the anchor the "since you last saw" window opens from (FHIR-52, SD-189/SD-190). The clinical date of the patient's last SIGNED encounter note -- a Composition whose category carries LOINC 34109-9, dated by event.period.start | date -- strictly before a REQUIRED before anchor. before has no default, deliberately: the window's upper bound is the CURRENT visit (the appointment start at 36h pre-generation, the encounter start on chart load), and "now" is the one anchor that is always wrong during a visit -- the moment this visit's note is signed it would become "the last encounter" and the window would collapse to zero, precisely in the walk-in and chart-load cases the requirements call out (SD-189 03.05/03.06). Ties are excluded: a note dated exactly at the anchor is this visit's note. Returns None on a first visit -- a real answer, not a failure. Feed the result to since=. No TS or C# twins are owed for any of the three, and that is a statement, not an omission: both ports refused a sources layer by design (a host there already has a FHIR client and comes in through the in-memory ingest edge), so the fetch contract lives in Python, whose consumer -- the AI harness -- is the consumer of all three features. The primitive they lean on, effectiveDateOf, already exists in all three ports.
Templates are a first-class shape in the IG: the Template profile on List. A template is a List whose CONTAINED resources are prototypes of what it produces, cloned into ordinary resources when someone uses it. The first consumer is the clinical letter, which produces one Composition, so a one-entry template is the ordinary shape rather than a degenerate one; a template that later produces a letter and a follow-up task gains a prototype and an entry, and needs no new definitions. (FHIR-53)

Nexus IG 1.17.0

Sun, 16 Aug 2026 00:00:00 +0000

This release contains a breaking change.

BREAKING -- Task.focus is typed, and focus vs input now mean different things (FHIR-31). focus was Reference(Resource), which documents nothing: a conformant writer could point it at an Organization and still pass. It is now Reference(QuestionnaireResponse | DocumentReference | Composition | Condition | DiagnosticReport | ServiceRequest | MedicationRequest | Observation), each constrained to this IG's profile of that type. Consumer action. If you write Tasks, focus must now name one of those eight and must satisfy the corresponding Nexus profile; anything else fails validation where it previously passed. If you read Tasks, you gain the thing that was missing: "which chart element is this task on" is answerable from the type alone, so a reader can switch on it rather than resolve the reference to find out what it is. The two elements were competing. input was ALSO an open reference to the chart, so the same fact had two homes and neither was wrong. That is why FHIR-31's question -- where do forms and inbox documents live -- had no answer. The split is now stated on the elements themselves: focus is what the task is about, input is what the task needs (chiefly the contained AI-suggested resource). Where a workflow genuinely spans several elements, focus names the one the task is filed against and the rest ride in input. Why forms are not stored inside the task. It reads as a storage question and is really a boundary question. A task carries the WORK -- who asked (requester), who owns it now (owner), what has been said (note), what happened to it (relevantHistory) -- and not the clinical content. If the form lived inside the task, every consumer that wanted the form would have to understand task workflow to reach it, the form would disappear when the task completed, and a document filed against two tasks would exist twice. So the form is a chart resource in its own right and the task points at it. note is documented as what it actually is: the conversation, oldest first. Annotation carries author and time as well as text, so the repeats ARE the thread that makes a forwarded task intelligible to whoever receives it. It stays deliberately distinct from relevantHistory, which is Provenance and records what HAPPENED rather than what was SAID -- an audit trail must not depend on someone having chosen to comment.
BREAKING for anyone pinning seed data: a given seed no longer produces the 1.16.0 dataset (PSD-417/PSD-412). The synthetic-patient generator was reconciled after PSD-417 was implemented twice, independently, against two different bases. Every change below reshuffles the random stream, so this is stated once, loudly, rather than discovered: regenerate any pinned fixtures. It is deliberately taken as one break in one release rather than three. Lab flags are now derived from the value, against clinical panic thresholds. Previously the flag was rolled and a value synthesized to fit, with "critical" derived from the reference SPAN
The generator is additive again: per-domain random streams (PSD-412). Every emitter used to draw from one shared stream, and uid() consumed 30 values from it per resource, so ANY change moved every value downstream of it -- different medications, different appointment times, different ids on resources nobody touched. A one-line change produced a corpus-wide diff, which is why PSD-412's "same seed, same dataset, reviewable diff" kept failing on the third clause, and how PSD-417 came to be implemented twice without either author seeing the other's effect. Each domain now draws from its own sub-stream, addressed by NAME rather than by position, with the "does this patient get one at all" gate on a separate stream again. So adding a domain perturbs nothing, retuning a prevalence changes which patients have the thing without rewriting what it looks like for the ones that still do, and two people can add generators in separate commits without colliding. Resource ids are hashed from (chart, domain, counter) rather than drawn, which makes them unique by construction rather than by luck. What is NOT promised: isolation is per domain, not per resource. Adding a lab still moves later labs. test/seed-stability.test.ts pins all of this, and prints a per-resource-type fingerprint table so a reviewer can check that an imaging change moved only imaging.
ofType() joins the emittable FHIRPath subset, and two IG rules start being enforced on real data (FHIR-33). value.ofType(CodeableConcept) IS valueCodeableConcept in FHIR JSON, so the type filter is a statically-known key rather than a runtime type test, and it compiles by collapsing two navigation steps into one -- exact, not an approximation. It was the only operator standing between the sociodemographic -absence-exclusive invariants and being checked; everything else in them was already supported. Those two rules -- "if a patient answered Asked-But-Declined, that must be their only answer" -- are now verified by TypedFhir at runtime in all three ports, rather than only by the HL7 validator against this IG's own examples. They are what stops a decline being counted as a demographic on a field whose stated purpose is reporting. The sibling -instances-clean rules (duplicate detection) remain unverifiable: they need select(), & and isDistinct(), which do not reduce to anything the compiler already has. No consumer action -- nothing about the published contract changes; two rules the IG already stated are now actually checked.
The IG now publishes CapabilityStatements (FHIR-35). nexus-emr-server declares the 29 resource types a conformant endpoint exposes and the interactions each honours, derived from the smart-exposed extension the profiles already carry — so "which types can an app reach, and to do what" is answerable from the artifacts instead of by reading 45 profiles. The 14 types this IG models but does not expose are deliberately absent from it: modelling a resource says the estate contains it, exposing it says an application may reach it. General search parameters are not declared yet — that surface varies by backing store, and this IG will not publish a list it has not measured against each one. nexus-emr-subscriptions declares the closed set of types that may appear in a Subscription.criteria and the exact search parameters each permits, so an unsupported criteria can be rejected when the subscription is created rather than matching nothing forever. It also states what the change feed cannot express — transition criteria ("changed into cancelled"), deletes, and unbounded replay — each of which an implementer would otherwise discover by not receiving a notification. Every parameter names a base R4 SearchParameter through definition; none is invented here, and the element each one reads comes from that SearchParameter's own expression rather than from anything this IG restates. That matters because a parameter name does not tell you which element it reads — patient on a DocumentReference reads subject, date on an Appointment reads start, and date on an Observation reads effective[x] in every type the profile permits. The client libraries' criteria vocabulary is generated by resolving those definitions, so a criteria cannot read a different element here than the same query would read on a conformant FHIR server.
Patient self-identification fields for sociodemographic capture (PSD-765): the Patient profile slices REUSE CA Core+'s patient-indigenousIdentity / patient-racializedGroup extensions (ca.infoway.io.core 1.2.0-dft-ballot, newly pinned as a dependency) rather than minting Nexus canonicals — repeatable, one answer per instance. Slice bindings tighten CA Core+'s preferred Infoway ValueSets to pinned enumerated mirrors (extensible) of IndigenousIdentityCode/RacializedGroupCode 1.3.0 — absence concepts are first-class members per the source composition — plus warning-severity exclusivity/cleanliness invariants on the Patient profile.
Composition.event is modelled: the note's CLINICAL date now has a home (FHIR-35). The profile previously offered only date, which R4 defines as the composition editing time -- it MOVES when a note is amended. So a timeline sorted by date re-positions an amended note to the date of its amendment, and no element said when the documented care actually happened. event.period is that element: event.period.start is required when the period is present, event.code says what kind of care it was, event.detail may reference it. Sort a clinical timeline by event.period.start, not by date. Both elements now carry a timing-relationships block and a worked example, matching the treatment DocumentReference already had. The seed corpus deliberately makes the two DISAGREE -- an amended note carries a date a week after its event.period.start -- because a corpus in which they always agree teaches a consumer the opposite of what the profile says. Composition and DocumentReference disagree about where these facts live. That is inherited from base R4, not introduced here, and it is now written on both profiles rather than left to be discovered: | what | Composition | DocumentReference | |---|---|---| | when the care happened | event.period | context.period | | what kind of care | event.code | context.event | | the visit | encounter (top level) | context.encounter (nested) | The same two words nest the opposite way round, and the encounter link sits at a different depth in each. Consumer action: if you learned one of these profiles and assumed the other, check all three rows.
Composition.category becomes the preferred classifier, matching DocumentReference (FHIR-35). The two profiles gave OPPOSITE guidance on the same question: DocumentReference said "use category instead" of type, while Composition said type was the primary classifier and demoted category to optional. Composition now follows DocumentReference. Why category wins, and it is the reasoning DocumentReference already published: category supports multiple classifications per resource, admits clinical and administrative taxonomies side by side, and leaves type free to carry the source EMR's own note type without displacing the field a consumer keys off. Composition.type stays 1..1 because base R4 requires it, not because it is the right thing to classify on. That distinction is not academic. In converted OSCAR data every casemgmt_note arrives with type fixed to LOINC 11488-4 "Consult note" whatever the note actually is, so a consumer keying off type there learns nothing. The seed corpus previously emitted a category that CONTRADICTED its own type -- 11488-4 "Consult note" as the category of a note whose type said 11506-3 "Progress note", two document types competing rather than a general and a specific. Both now read LOINC 34109-9 "Note".
New value set nexus-emr-note-classification, bound preferred on BOTH Composition.type and Composition.category (https://fhir.apps.health/ValueSet/nexus-emr-note-classification) One code: LOINC 34109-9 "Note". That is what the estate stores, and a larger enumeration would be a guess about note taxonomy published as a contract. The same set is on both elements because there is nothing yet to distinguish. category is the preferred classifier (see the entry above); type is 1..1 because base R4 requires it, not because it carries a finer second fact. When note subtypes start being stored -- progress vs telephone vs discharge -- type is the element they belong on, and that is the moment to widen this binding back toward LOINC's document-type space. The type element's prose no longer lists four candidate LOINC codes, which a one-code set contradicted. preferred, not extensible or required, and the reasoning changed late in review, so it is worth stating plainly. required would make converted OSCAR data non-conformant on arrival: every casemgmt_note carries LOINC 11488-4 "Consult note" whatever the note is. extensible looked like the safe middle and is not, once the set is small -- an extensible binding over an enumerable set is a SHALL-unless-nothing-fits, and base R4 only avoided firing on that same data because its value set was a LOINC filter wide enough to contain 11488-4 already. preferred says the thing actually meant: this is the code we store, and yours is still conformant. ⚠ A preferred binding is not silent in TypedFhir today. All three ports grade any binding that is not example at WARNING severity, so a note carrying a document-type code outside this set will warn despite being conformant -- which converted OSCAR data does, on every note. The warning is a tooling artefact, not a conformance statement. Aligning the ports with FHIR's severity ladder (preferred as information) is a three-port behaviour change and is tracked separately rather than folded into a spec release. Carry an unmapped local type in type.text rather than mis-coding it. Two notes for implementers coming from elsewhere. First, base R4 binds Composition.type only preferred; this IG has bound it extensible since before this release, so the tightening is not new here, only the value set is. Second, US Core makes the same split -- coarse classifier on category (a value set of exactly one code, clinical-note), fine slot on type
Published page URLs are now locked by a checked-in manifest (FHIR-35). Since the one-page-per-tab split in 1.16.0, a reference page's filename IS its public URL, and it is derived from the tab's DISPLAY LABEL. Editing a label therefore renamed published pages. Measured rather than hypothesised: renaming one tab label ("Salient fields" -> "Salient elements") moves 67 published URLs. Nothing caught this, and the reason is the interesting part. mkdocs strict: true checks that links RESOLVE, and after such a rename they all still do, because every internal link is regenerated against the new name in the same pass. The site stays perfectly self-consistent while every inbound link from outside it dies. Internally coherent, externally wrong, and green. docs/published-urls.txt now records all 901 page URLs and is compared on every pre-PR run. Additions pass silently -- a new profile or tab is ordinary work, and gating it would make the manifest a chore that gets rubber-stamped, which is how a lock stops being one. Only removals and renames fail, and accepting one is a separate named action (npm run urls:accept) so that moving a public URL is something someone can be seen doing in the diff. What this means for you: the canonical-URLs-are-forever promise this IG makes about its published pages now has something enforcing it. Bookmarks and inbound links to a reference page will not be moved by an editorial change to a tab label.
Task.basedOn and Task.reasonReference are no longer must-support. Both elements remain, both remain typed (base R4 leaves each open to any resource; this profile narrows basedOn to the four request types and reasonReference to Condition / Observation / DiagnosticReport / DocumentReference). What changes is the CLAIM. Must-support says a consumer of this IG will do something meaningful with a populated element. This IG is not yet in a position to say that for either: nothing populates them, and a surface that displays a task reads focus, owner, requester, status, priority and the due date. Advertising support that does not exist has a specific cost, and this release is the demonstration of it. Because both were must-support, the seed generator had to populate them, so it reached for the nearest resource in scope: basedOn got the Encounter and reasonReference got the Patient. "This task is because of the patient" says nothing -- every task is about the patient. Both are fixed above, but the fix people should take away is the demotion, not the patch: an element nobody reads is one producers fill with whatever is to hand. If you populate either today, nothing breaks -- they are still modelled, and the published StructureDefinition still narrows their targets, so a validator that checks reference target profiles will hold you to them. ⚠ TypedFhir is not such a validator. Its IG generator reads type[].profile and never type[].targetProfile, so what reaches the ports for a narrowed reference is the bare datatype (types: ["Reference"]) and nothing enforces the target list in TypeScript, Python or C#. That is true of Task.focus above as well, and it is the reason FHIR-45 exists. Do not read "typed" as "checked by our client libraries" -- today it means "declared in the specification". What would make them must-support again: a consuming surface that reads them. Note the overlap with focus, which is the element to reach for first. focus is the chart element the task is filed AGAINST; reasonReference is why it exists. A task to review an abnormal potassium has that DiagnosticReport as its focus, and the Condition it relates to (if any) as its reasonReference. Must-support coverage in the seed corpus moves 575 -> 573 accordingly. The seed corpus no longer emits either element. Populating them with the nearest resource to hand is what produced the wrong types in the first place, and synthesizing a plausible order or a plausible clinical justification for a task that has neither would put the same fiction back, one type-check better dressed. If you were reading Task.basedOn or Task.reasonReference out of the seed data, they are gone -- they were never carrying real information. Wider question logged as FHIR-47: 20 of this profile's must-support elements are justified in published prose by the same source, and only these two have been examined.
Nearly half of all "normal" lab results sat exactly ON a reference-range boundary. The N tier drew from the wide near-normal sampler and CLAMPED into the reference interval. Because the sampler's spread is deliberately greater than 1 (the general lab path needs out-of-range values), clamping deposited every out-of-range draw exactly on a bound. Measured over 200,000 normal results: 22.4% landed on exactly 3.9 and 22.4% on exactly 5.5 for Glucose. Creatinine put ~17% on each of 60 and 110, about 9x what a flat distribution would give. The distribution was bimodal at the edges, which is the opposite of the mid-clustering the code claimed, and it is visible to anyone who looks at the seed data: a demo chart full of glucoses reading exactly 5.5 does not look like lab data. The N tier now draws a triangular in-band value (mass concentrated mid-range, tapering toward the bounds, no spike on them); the abnormal tiers stay uniform, since there is no clinical reason to prefer the middle of "high" to its edges. Guarded in interpretation-tiers.test.ts by two assertions -- no bound spike, and a modal value in the middle third -- both mutation-tested against the old clamping. This moves lab values for a given seed. It is part of the seed break already declared above.

Nexus IG 1.16.0

Fri, 14 Aug 2026 00:00:00 +0000

This release contains a breaking change.

The reasoning behind a constraint is now published (FHIR-32). definition, comment and requirements are where the WHY of a constraint lives, most of it hand-written in FSH carets, and none of it reached this site: it compiled into package.tgz and rendered only on IG Publisher pages. Elements now have a Details view, every element name in the Differential / Key / Snapshot tables links into it, and an element carrying a comment gets a marker in the description column, because comment is often the most useful prose on an element and it renders in no table. Patient alone gains 169 prose blocks and 199 markers across 102 elements. Salient fields carry short, definition and comment separately rather than one lumped description, so each consumer takes the text written for its audience: the table cell, the generated docstring, and the pydantic schema an LLM reads. 94 of 95 salient fields inherit short and definition with nobody writing a word.
One page per tab in the generated reference (FHIR-32). The tabs were one page carrying every view; each leaf view is now its own page and the tab bar is a strip of links. 273 generated pages become 890. Patient goes from a single 521 KB page to 14 pages, largest 184 KB, median 11 KB. Existing URLs are preserved -- the first leaf keeps StructureDefinition-.md, so every link and bookmark to a profile page still resolves. The reason for the split is that hidden tabs were still in the DOM: a search hit or an inbound anchor could land on content the reader could not see. Every view is now separately addressable, and search results land visible.
The vendored IG snapshot can no longer go stale unnoticed (PSD-848). The chain is doc/fhir -> SUSHI -> vendored snapshot -> the generated tables, facades and patient-compartment map, and every guard sat at or below the snapshot: they regenerate from it, or compare against it. None could see the FIRST link break. Editing the FSH without re-running refresh:ig left the snapshot unmoved, so every guard agreed with every other guard about an IG that no longer matched its own source, and CI stayed green. refresh:ig now stamps an igSourceHash into the manifest -- a content hash of src/fsh, src/examples and sushi-config.yaml, the inputs that determine the vendored artifacts -- and a new test recomputes it. A mismatch means the source has moved since the snapshot was taken, and says so with the command that fixes it. It runs in the npm test chain, so the required CI check enforces it rather than only the owner-track gate. No consumer action. A build-integrity check; nothing about the published contract changes.
Invariants declared on EXTENSIONS are now compiled and enforced (PSD-848). They previously were not, by any mechanism: extension StructureDefinitions never entered TypedFhir's IG model (only kind: "resource" was kept), so their constraints reached no table, no compiler and no gate. Such a rule rendered on its published profile page, read as enforced, and checked nothing -- and the gate that exists to flag an unverifiable invariant could not see it either, because it iterates the invariants the model collects. effective-date-declares-exactly-one was in that state for its whole life; it is now verified against all 45 profiles that carry the extension. Two FHIRPath forms were added to the emittable subset to make it compile as written: xor, and extension('url') as sugar for extension.where(url = '...'). The sugar matters beyond this rule -- it is what an author naturally writes (HL7's own invariants use it), and until now reaching for it silently produced an unverifiable invariant. Extension invariants are now also compiled into the RUNTIME validators. An extension's rules are not in the profile's snapshot -- a sliced extension element carries only ele-1/ext-1 -- so TypedFhir checked none of them on real data, even where the HL7 validator was checking them against our examples. gen-facade now resolves them BY URL, matching how an extension is identified in the data, so a rule applies wherever its extension appears rather than only where a profile happens to slice it. All three ports. Mostly no consumer action -- a rule the IG already stated is now actually checked. The one addition is below.
nexus-attributed-fact requires substantive citations (PSD-848): new invariant attributed-fact-citations-are-substantive -- the statement, and every citation's verbatim quote, must be non-empty. 1..1 requires those elements to be PRESENT; it does not stop them being "", and an empty quote is worse than a missing one: it is a citation that cites no text, passing every structural check while leaving the fact unauditable, which is the one property the extension exists to provide. Error severity. The extension is experimental and unreleased, so no published contract tightens.
BREAKING -- ClinicalTask.intent is no longer fixed to order (PSD-848). It now binds nexus-emr-task-intent (required): order for work already authorized and assigned, proposal for a suggestion that takes effect only once a human accepts it. Consumer action: code asserting intent === 'order', or relying on it being present with that value, must handle proposal. If you were identifying AI suggestions by code, the AIAST security label, or the presence of a contained resource, read intent instead -- those were proxies for it. Task instances already in a store are unaffected: order remains valid and no stored value changes meaning. Why: the fixed value described the population the profile was written for -- inbox items, follow-ups, to-dos, which genuinely are orders -- and prevented a scatter of intents for identical work. Modelling AI suggestions onto the same profile made it wrong: a suggestion awaiting a clinician's approval is exactly what "not proposals or plans" excluded, so intent could not distinguish "assigned to you to do" from "awaiting your approval". The binding is narrowed to two codes rather than reopened to R4's nine, because the order-flavour refinements describe a fulfilment chain this model does not have, and a task whose intent is unknown cannot be triaged at all. The FSH records the accept-or-reject for each of the nine.
Provenance leaves placeholder status (PSD-848): the profile now has a committed job -- attribution for AI-mediated and cross-boundary writes, in two worked shapes (standalone, and contained in an AI-suggestion review Task) -- and is marked experimental = false. No cardinality, type, binding or slicing changed, so nothing that validated before stops validating. One invariant did get real teeth: provenance-ai-action-names-agent was effectively vacuous (agent.exists()) and is now a genuine conditional check. Its severity is still warning, so it fails nothing -- but a producer relying on it never firing will start seeing it fire. Model/token accounting, the meta UpdatedBy relationship, and whether Provenance is written for ordinary human edits remain open and are documented as such.
Attributed facts on Provenance (PSD-848): new nexus-attributed-fact extension carrying, for AI-generated text, each factual statement with its backing verbatim quote(s) and the generating run's chunk label -- a lossless mapping of the harness's fact/citation wire schema, with an optional source reference tying a citation to the Provenance.entity it was drawn from. Sliced into the Provenance profile as attributedFact 0.., with a worked pre-visit-summary example. The AI-suggestion Task example now also carries a CONTAINED Provenance (linked from relevantHistory) citing the passage its contained suggestion was extracted from -- the suggestion and its citation trail travel and are approved or rejected as one unit.
A suggestion's review state belongs on the Task (PSD-848): the ClinicalTask handbook page now states the rule and the contained-suggestion example follows it. A contained suggested resource is written as the clinical fact its citations support, so the example's Condition moves from verificationStatus = unconfirmed to confirmed and gains the required category. Using unconfirmed to mean "not yet approved" reads as clinical doubt to every consumer -- verificationStatus is a modifier element -- and the wrong value survives into the chart on approval, because approving moves Task.status and changes nothing inside the contained resource. The same rule keeps a suggestion promotable: it should already satisfy its profile.

Nexus IG 1.15.1

Wed, 12 Aug 2026 00:00:00 +0000

The tenant stamp is declared: the tenant-id extension (FHIR-29). Every resource stored through the FHIR Gateway carries http://services.well.com/fhir/auth/tenant-id on DomainResource, and the IG did not declare it -- so it appeared on every payload with nothing to resolve and no explanation. It is now a published extension, documented as what it is: the gateway stamps the caller's tenant on every create and update and strips any client-supplied value first, so tenancy follows the token and a client cannot choose it. Both this and the userId identifier are private infrastructure and must not be depended on -- unresolvable URLs, opaque values, no breaking-change guarantee, and deliberately kept off the governed fhir.apps.health host to say so. If you need to know which clinic a resource belongs to, use the modelled Organization / Location references instead. See the Identifiers page in the handbook.
Seven new first-pass profiles close the parallel-efforts modelling gaps (FHIR-29, from the 2026-08-10 gap triage; every one has a named consumer): ImagingStudy (the imaging half of results viewing, PSD-417; DiagnosticReport.imagingStudy now targets it), Coverage (payor context for billing/demo -- the Ontario shape, payor as a logical Organization reference), FamilyMemberHistory and MedicationStatement (the harness's Patient Summary Domains read list), Goal and CarePlan (CDM flowsheets and care gaps; CarePlan also resolves the corpus's no-model-but-generated inverse gap by profiling rather than un-emitting), and RiskAssessment (computed risk scores; replaces the chart-module registry's profileAbsentReason placeholder). ALL seven are CLOSED to SMART apps pending an exposure decision (the FHIR-28 policy for newly profiled types).
Result review state: the nexus-reviewed extension (FHIR-29) on DiagnosticReport and Observation -- who acknowledged a result and when; ABSENT means unreviewed. The Task inbox is the review workflow; this is the queryable state it stamps, so a results viewer needs no Task join. The seed corpus emits a realistic reviewed mix with unreviewed volume on recent results.
ICD-10-CA and CCI get named slots, not content (FHIR-29): system-sliced secondary codings on Condition.code (icd10ca) and Procedure.code (cci). Codes are deliberately NOT enumerated -- both classifications are CIHI-licensed and the licence paperwork is in flight (the prevention-catalog pattern: the IG declares the slot and the system; content governance lives outside).
The seed corpus covers the grown surface: emitters for all seven new types (payor context incl. a cancelled prior plan, family history incl. a health-unknown relative, patient-reported OTC meds incl. a discontinued one, the CDM bundle tying Goal + CarePlan + RiskAssessment to a live chronic Condition, imaging studies with their reports) plus the review-state stamp. Coverage guarantee after the growth: 43/43 profiles, 577/577 must-support, both directions clean with the CarePlan allowlist entry REMOVED.
The seed corpus got the content the parallel demo efforts were missing (FHIR-29). Abnormal/critical lab flags (H/L/HH/LL interpretations on a realistic minority of results, deterministic on the anchors -- PSD-417's ask), ranked encounter diagnoses spread across the record instead of one flat rank-1 (PSD-606), authored Composition notes on ~85% of encounters INCLUDING the GMF follow-up majority, amended-note snapshots (the version CHAIN stays a load-path concern -- a flat corpus cannot carry _history), a meta.tag synthetic marker on every resource (corpus-local URN system; one _tag query finds or purges fixture data), per-patient collection-Bundle output behind --bundles, and OHIP fee-code variety (six schedule entries, occasional add-on line item) instead of a single hardcoded A007.
The coverage guarantee now fails in BOTH directions (FHIR-29). A new inverse check: any resource type the generator EMITS that the IG does not profile fails the guarantee unless it has a documented ALLOWED_UNMODELED entry (same visible-reasoned style as the existing exclusions). The motivating example -- 293 un-modelled CarePlans quietly shipping into benchmark stores -- is now the one allowlisted entry, explicitly flagged as pending the CarePlan modelling ruling rather than resolved.
bin/pre-pr.sh: the mandatory owner-track pre-PR gate (FHIR-29). One entry point chaining SUSHI build -> example conformance -> version-drift check (sushi-config vs ig-specs.ts, automating the hand-bump that trailed a release) -> IG vendoring + code generation for every generated consumer (TS, Python, C#, and the docs tree) -> npm run verify (the WHOLE TS suite, i.e. what CI runs, not a slice of it) -> the data-generator typecheck -> the bidirectional data-generator coverage guarantee -> a git-clean lockstep check on every generated tree. Documented as mandatory in the IG owner release process: regenerating code from the IG and proving data-generation coverage are now ONE event, so the corpus can never again trail the spec the way the note model did. The gate now covers EVERY generated consumer of this IG -- the TypeScript, Python and C# libraries and this documentation site -- and refuses to pass unless all of them regenerate clean from the same FSH. What that buys a consumer: the artifacts published under one version cannot silently be a release apart.
The seed-data generator covers the whole 1.15.0 IG surface again (FHIR-29). The coverage guarantee is green across every dimension (profiles, must-support, bindings, invariants, extensions): the anchors gained the Composition encounter note (the 1.14.0 note switch), both consent shapes (app-consent grant + deny, item-consent provided + declined-with-evidence), the AI-suggestion Task (contained payload, thread-id, logical Device requester), the prevention-status Observation, the boolean app-state, and the heritage-inactive Patient (record-inactive-reason) -- plus a latent app-state extension URL bug fixed. TypedFhir's generated validators are now SIBLING-PROFILE AWARE: a resource declaring a sibling profile of its type via meta.profile (Consent app/item, Device app/emr) is validated against that profile's own rules instead of whichever profile sorted first -- previously every item-consent instance failed app-consent's pinned category, in every port that validates. The dispatch is emitted by all three facade generators, so TypeScript, Python and C# behave identically; a conformant item-consent and a conformant emrdevice are pinned in the cross-language parity corpus (vectors/facade-adversarial.json), so a port that loses the dispatch fails the parity gate rather than silently rejecting valid resources. nexus-sugg-1 was reformulated inside the compilable FHIRPath subset (plain choice access instead of ofType; same semantics), so it is machine-enforced rather than prose. The vendored IG, generated tables, facades (TS + Python + C#) and registries now stand at 1.15.1.
AI suggestions are modelled as resources CONTAINED in their review Task (FHIR-29). A suggested chart entry is never a first-class chart resource pre-approval: it rides Task.contained, referenced from the new pattern-sliced suggestion input (input.type = nexus-suggestion#suggested-resource), with Task.code = ai-suggestion (enforced by the new nexus-sugg-1/2 invariants: the suggestion reference SHALL be local, and a suggestion Task SHALL declare itself). Type-level queries cannot see suggestions by construction -- confirmed empirically on both the WellServices store (MS FHIR Server for Azure) and Medplum. Lifecycle rides Task.status natively (requested -> accepted/completed, or rejected -- rejected Tasks and their payloads are RETAINED as the record of what was declined). New: the nexus-thread-id extension (harness thread traceback), the nexus-suggestion CodeSystem, and a full contained-suggestion example (AIAST-labelled Task carrying a suggested Condition).
AI agent identity: logical Device references, no registration (FHIR-29). An AI graph acting in the EMR is a Device referenced BY IDENTIFIER (the new nexus-harness-graph NamingSystem -- the tree's first declared identifier-kind NamingSystem; Reference.type = "Device"); the identifier points into the harness's graph registry and need not resolve to a Device resource on the server. Granularity is deliberately graph/feature level. Task.requester and Task.owner now admit Device: an AI-created Task names its graph as requester, and REASSIGNING a Task to an agent Device is the approve/resume contract (the harness watches task-assignment changes and resumes the thread named by the thread-id extension).
TypedFhir (Python): since-checkpoint delta fetch + PatientCache.refresh (PSD-731). fetch_resources_delta answers "what changed since this opaque checkpoint" (_lastUpdated-windowed on the WellServices gateway, with an overlap so out-of-order commits are never lost; full-fetch fallback on every other source), and PatientCache.refresh merges the delta in place by (resourceType, id). Checkpoints never advance past a window a covered type failed to sweep; a query built before a refresh raises rather than answering from stale bits. Hard deletes are invisible to FHIR search, so a refresh converges between full loads rather than replacing them. A cross-patient resource inside a delta is treated as an ERROR (backend corruption, dropped + error issue + held checkpoint, so it re-reports every refresh until fixed) -- never as a quiet removal.

Nexus IG 1.15.0

Release 1.15.0 of the Nexus IG.

Nexus IG 1.14.1

Sun, 09 Aug 2026 00:00:00 +0000

SMART on FHIR exposure is now declared per profile (the new smart-exposed extension). Whether a resource type can be reached by a SMART app is an authorization decision, and it is now recorded in the IG rather than inferred from whether the resource happens to be profiled. A profile carrying the extension is reachable, and names the platform permission each operation costs (observation:read, observation:write, observation:delete). A profile without it is not reachable at all, so a newly profiled resource stays closed until someone decides otherwise. 29 resource types are exposed, Composition among them, since an encounter note is core clinical content for an app. The seven experimental profiles (Communication, DetectedIssue, MessageHeader, Provenance, QuestionnaireResponse, Specimen, Subscription) are deliberately left closed. Six of the 29 are exposed read-only — Practitioner, PractitionerRole, Organization, Location, Schedule and Slot — because they are reference and directory data the EMR maintains rather than something a third-party app should rewrite, and a delete there is data loss rather than a workflow step. For app authors this is the answer to "what do I ask for": every resource page now carries a SMART tab listing the scope strings that work against that resource and the permission each one resolves to. The permission tokens are referenced here, not defined: they belong to the EMR's own role model (the same tokens an administrator sees when building a role), and code generation fails if the IG names one that does not exist there. SMART's scope grammar itself (the c r u d s interaction letters, .read/.write folding, wildcard expansion) is deliberately not modelled in the IG: translating it is the gateway's job, and the IG answers only "is this exposed, and what does each operation cost". (FHIR-28)
TypedFhir 0.8.0 surfaces SMART exposure in all three ports and now publishes as a NuGet package. SmartExposedResources, IsSmartExposed() and GetSmartScope() (snake_case in Python) are generated from the smart-exposed extension, so a consumer asks the library what an app may reach rather than transcribing the answer. Generation refuses to emit a table naming a permission the platform does not define, and a test asserts the same on every CI build, which is what keeps the IG's published permission tokens and the EMR's role model from drifting apart. The C# port ships as Well.Services.TypedFhir with an optional Well.Services.TypedFhir.Firely adapter for hosts that hold Firely POCOs; the core takes no Firely dependency. (PSD-721)
effective-date is now a declared extension. 38 profiles stamped https://fhir.apps.health/StructureDefinition/effective-date via the EffectiveDate / NoEffectiveDate RuleSets while nothing defined it, so the canonical resolved to nothing and the IG Publisher objected on every single use. The declaration changes no stamped data; it only makes the URL resolve, and adds the constraint the RuleSets always implied but could not state: a profile declares either which paths carry its date (26 do) or that it deliberately has none (12 do), never both and never neither. Its sibling salient-field was declared all along, which is what made the gap visible. (FHIR-27's open item, closed here alongside the new smart-exposed.)
18 CodeSystem and ValueSet ids no longer contradict their own canonical URLs. Each carried a cs- / vs- prefix its URL did not (cs-nexus-emr-province-state against .../CodeSystem/nexus-emr-province-state), which the IG Publisher rejected three times over per resource — 54 errors. The id was corrected to match the URL, never the reverse: a canonical URL is the published contract and every existing binding and reference points at it, while the id is local and the resource type already disambiguates a CodeSystem from a ValueSet of the same name. No canonical URL changed, so nothing downstream needs updating. (FHIR-28)
A second, dead copy of four FSH files is gone. doc/fhir/input/fsh/ held duplicates of the province-state CodeSystem and the gender-identity, pronouns and province-state ValueSets. The build reads src/fsh/ (staged into .build/ by bin/build.sh), so the copies shipped nothing and nothing referenced them — but they had already silently rotted: their titles were the pre-rename originals, so anyone reading or editing them was working from a stale file that looked authoritative. (FHIR-28)
The Invoice example's practitioner reference resolves. It pointed at Practitioner/dr-navarro where the example's actual id is dr-emil-navarro, so the reference dangled in every validation run. (FHIR-28)

Nexus IG 1.14.0

Sun, 09 Aug 2026 00:00:00 +0000

Item consent (nexus-emr-core-item-consent) — a patient-level Consent profile for the Patient Profile's Consent section: one Consent per (patient, item) for the fixed phase-1 catalogue (email, SMS, AI scribe — the new nexus-consent-item CodeSystem/ValueSet), updated in place with the decision read from status alone (active = provided, rejected = declined, no resource = not recorded) and the full decision history served by FHIR versioning (_history/vread); includes the optional nexus-consent-status-reason extension, evidence via sourceReference to a NexusEmrCoreDocumentReference (the Attachment choice is removed from source[x] so evidence stays behind DocumentReference read permission), examples, and the item-consent feature guide. Unlike its siblings the profile carries no raw-identifier invariant — an item consent is born in the EMR, so there is no source system to point back at and the rule could only ever be satisfied by inventing one — and instead warns (item-consent-status-is-defined, item-consent-performer-is-attributable) where the prose asks for more than cardinality and bindings can express: a status outside the three codes it defines, or a decision with no attributable performer.display. The guide adds the migration caveats this model creates: version history does not survive a bulk export/import and must be replayed per version, and the deterministic identifier embeds the Patient's logical id, so re-keying patients means recomputing every one. (PSD-501, epic PSD-316)
Composition is now the model for authored clinical notes — encounter notes, consult notes, telephone notes: anything an EMR user writes or an AI scribe drafts and a clinician signs. The narrative lives in FHIR as XHTML in section.text, so a note is readable, searchable and diffable without dereferencing a blob, and Composition.status carries the lifecycle (preliminary draft → final signed → amended) instead of an invented extension. Amendments are version history over one resource — edit in place and set status to amended; the business identifier does not change and relatesTo is deliberately left unprofiled so it stays available if a true addendum workflow later appears. A signed note must name its signer (composition-signed-has-attester). author admits a Device, so an AI-drafted note can say so on the resource, while attestation remains the clinician's alone. Two examples ship: a signed progress note, and a scribed telephone note that was signed and then corrected. Decided on the August 2026 SMART-launch review. (FHIR-27) > This re-introduces a profile removed four days earlier, deliberately. bde96cee4 (1.11.0) > deleted an experimental NexusEmrCoreComposition on the grounds that the surface was > "experimental and unused, and publishing it invited implementers to build against a shape the > IG was not committing to." That reasoning was sound and is now spent: there is a committed > consumer. What returns is only the encounter-note subset — not the four-section-type > (text/form/canvas/file) surface with recursive containment and coordinate annotations, whose > removal also cleared two unevaluable-slicing defects. section.code is left unbound for the > same reason: no producer populates it yet. > Known dependency, stated plainly. The amendment model rests on version history, and version > history is server-local — _history does not travel in bundles, $everything, or sync > pipelines. This IG also publishes no CapabilityStatement, so no versioning policy is declared > anywhere, and meta.versionId is server-opaque in R4 and unconstrained here: consumers must > not sort or parse it to determine which version was signed. Reconstructing the as-signed note > is reliable only on the authoring server today. Declaring the version-history contract is > outstanding work and a prerequisite for relying on this across boundaries.
IG HTML publishing is scripted — bin/publish.sh renders the IG to browsable HTML and optionally zips it for sharing (-full / -slim, both labelled so neither can be mistaken for the other or overwrite it). This is release step 6 of the IG Owner Release Process, which until now said only "note the deferral". Also establishes bin/ as the home for IG maintenance scripts, with the conventions written down. (FHIR-27)
DocumentReference narrows to attached binary documents — scans, faxes, external PDFs, Word files, consent forms: content that arrives as bytes. It is no longer the home for textual encounter notes (see Composition above), and the profile now states the boundary rule explicitly: did we author it, and is the content text we control? A consult letter received as a PDF stays here; a consult note typed in the EMR does not. This is a deliberate divergence from US Core, which models clinical notes as DocumentReference; the rationale is recorded on both profiles. (FHIR-27)
DocumentReference content documentation now matches what the gateway actually does. The profile described content as inline-base64-first and claimed external URLs were unsupported — both untrue since the gateway grew document storage, so implementers were reading a contract the runtime no longer honoured. Now documented: submit inline base64 with no url; the gateway stores the bytes and rewrites the attachment (sets url, computes size and SHA-1 hash, clears data), so readers get a URL and no inline data. The URL is an absolute File Storage Service address, not a FHIR Binary reference and not a pre-signed/SAS link — fetching it needs the caller's own bearer token and resolves within the caller's tenant. It is stable for the life of the document and survives updates. Sending data and url together bypasses storage and persists the base64 inline permanently; the profile now warns against it. Client-supplied URLs are host-validated and rejected with a 400 when untrusted. (FHIR-27)
Removed the prose salient accessor from DocumentReference. It decoded content.first().attachment.data and offered it to chart and model readers as long-form text. Wrong on two counts once the scope narrowed: the content is now a PDF or TIFF, so decoding it yields binary rather than prose; and the gateway clears data on write, so it resolved to empty for every gateway-ingested document anyway. Replaced with title and url. The narrative reader surface is Composition.section.text. (FHIR-27)
Dropped the boilerplate "Future Considerations" sections from 16 profile intro pages — speculative "potential enhancements being evaluated" lists that read as commitments the IG had not made. 156 lines removed; no profile, element, or binding changed. (FHIR-27)
The tree is restructured around src/ and a contained build. FSH now lives in src/fsh/ (was input/fsh/), examples in src/examples/, per-profile narrative in src/pages/, and the IG configuration (sushi-config.yaml, ig.ini, ignoreWarnings.txt) in src/ig/. The FHIR toolchain's hard-coded conventions no longer shape the tree: bin/build.sh stages src/ 1:1 into the gitignored .build/ and runs SUSHI (and, at publish time, the IG Publisher) in there, so all generated output and tool scratch (fsh-generated/, temp/, template/, input-cache/, the rendered site) is contained in one disposable directory. conformance/run-conformance.sh folded into bin/conformance.sh — bin/ is the single home for tooling. No profile, example, or canonical URL changed — this is a layout-and-tooling change only. (FHIR-27)
The IG is titled "Nexus IG" (was "Nexus EMR FHIR Implementation Guide") — nothing else in the Nexus ecosystem defines an IG, and the spec serves more than the EMR. The formal title, the site name (which now carries the version, e.g. "Nexus IG 1.14.0"), and site prose all use the short form. Identity is untouched: id: nexus-emr, the canonical base, and all profile slugs are unchanged. This CHANGELOG is now published on the site and linked from the front page. (FHIR-27)
Artifact display titles normalized — three authoring generations of title styles ("X Profile Core", "X Core", "X (Minimal) Core", unprefixed extensions) collapse to one pattern: " Profile" with qualifiers trailing ("Slot Profile (Minimal)"), and no Nexus EMR/Nexus brand prefix (the canonical URL carries the namespace). 53 titles changed. Display-only: no id, URL, name, or element change; meta.profile values and references are unaffected. (FHIR-27)
The human-readable IG is now one MkDocs site, not the IG Publisher's HTML. bin/site.sh builds (or serves, with live reload) the guide plus a FHIR reference generated from the compiled IG — profile pages with differential tables, bindings, invariants and linked examples — by TypedFhir's new ig-docs renderer (@awaremd/typed-fhir/ig-docs). The IG Publisher survives as the package + QA factory (bin/publish.sh): validators and generators consume its package.tgz, published at the site root next to package-list.json; its Jekyll HTML is not published anywhere. Profile pages present the resource as five tabbed views — Differential, Key elements, Snapshot, FSH source, Examples — and example JSON is hyperlinked (references to other examples and canonical URLs are clickable, with "Referenced by" backlinks), so instances browse as a graph. The site carries the Nexus EMR frontend's WELLSTAR Stardust branding (blue-on-clay light, navy-clay dark, IBM Plex, the Nexus mark). Profile pages also carry a Salient fields view (the synthesized-accessor contract: key, type, FHIRPath expression) and a TypedFhir API view with TypeScript / Python / C# sub-tabs showing the generated facade for the profile's resource type. Extensions used by exactly one profile nest under that profile in the sidebar; only shared/cross-cutting ones remain top-level. Also fixed en route: sushi --snapshot . silently dropped the flag (0/51 snapshots) — the staged build now runs sushi build . --snapshot (51/51), which is what TypedFhir's vendored artifacts are regenerated from. (FHIR-27)
Organization references in three Patient examples used a NamingSystem the Organization example does not own (.../cedarbrook-clinic-organization-identifier vs the organization-identifier system the Organization profile's invariant names) — the references were unresolvable as data. Normalized to organization-identifier. (FHIR-27)

Nexus IG 1.12.0

Wed, 05 Aug 2026 00:00:00 +0000

Seven new draft profiles, for the resource types this stack demonstrably reads or writes with no profile behind them — DetectedIssue, Communication, QuestionnaireResponse, MessageHeader, Subscription, Specimen, and Provenance. All are #draft + experimental = true first passes: each declares its identifier contract, its effective date (or NoEffectiveDate), its patient/subject reference, and the constraints load-bearing for the surface already consuming it — and each names inline what it deliberately does not settle, so a reader can tell a decision from a placeholder. Highest-consequence of the set: DetectedIssue (the prescribing override audit trail, previously ungoverned), QuestionnaireResponse (the chart's journey timeline could not date it), and Provenance (a deliberate placeholder for AI-Harness action attribution — token/model accounting and the gateway UpdatedBy reconciliation are explicitly left open). Scope note for IG consumers: profiles are added for observed consumption, not for reachability. Types that are merely granted a SMART app scope, or merely traversed as a containment field, do not get a profile on that basis — the app scope is the thing that should narrow. Specimen qualifies on a narrower basis than the others and says so in its own notes: one real site resolves ServiceRequest.specimen references in eReferral bundles, and nothing reads a Specimen's own fields, so it is governed as a pass-through type. Still deliberately NOT profiled on the same rule: CarePlan, Goal, Coverage, MedicationStatement, ImagingStudy, Media, MedicationAdministration, Medication. (FHIR-25)
Heritage-EMR situations are now documented on the affected element definitions, and flagged as UNRESOLVED — so the caveat travels into the IG pages and the generated typed API rather than living in a reviewer's head. Covered: Patient.address.state / .country (heritage EMRs store province as unvalidated free text, so the new required bindings are an open migration risk — the distribution has not been measured); Specimen.identifier / .accessionIdentifier / .subject (heritage lab results carry an accession and little else, with no cross-lab namespacing for it and a patient link that is inferred rather than asserted); and Communication.identifier / .category (heritage message/inbox history is not FHIR Communication and whether to migrate it at all is undecided — every Communication in this IG is currently either WELL-native or external eReferral, never heritage-migrated). Each note says what is unknown and what would resolve it. (FHIR-25)
Provenance.agent.type is 1..1 — tightened from the base 0..1 to match US Core 9.0.0 us-core-provenance, which also sets it min 1. It is the only element distinguishing a non-human generating agent from the human who accepted its output, which is the whole reason the Provenance placeholder exists; two untyped agents are an ambiguous record. Note this IG deliberately does not adopt US Core's must-support on target.reference — that would require literal references, and the Nexus logical-reference model permits identifier-only. (FHIR-25)
New Patient example for the 1.12.0 identity surface — Patient/rowan-mercier-no-health-card exercises reasonForNoHCN (on the MRN identifier), genderIdentity and pronouns in their correct complex form, name.prefix, and both required address bindings. Added because the new must-support elements previously shipped with no conforming instance, and the complex-extension shape (extension[value].value[x]; the extension root's value[x] is 0..0) is the one contributors get wrong. (FHIR-25)
Reason for no health card number — Ontario's CA-eReC extension, ADOPTED not re-minted — [Patient.identifier.extension[reasonForNoHCN]](fhir/StructureDefinition-nexus-emr-core-patient-elements-details.md#el-Patient.identifier.extension-reasonForNoHCN), using http://fhir.infoway-inforoute.ca/io/CA-eReC/StructureDefinition/CA-eReC-reason-for-no-HCN-EXT. Ontario eReferral requires Patient.identifier to carry either the health card number or a documented reason for its absence; this is the "or" half, and it completes the PHN identifier work begun in #768. New IG dependency: ca.on.erec.r4 pinned at 0.12.6-TU-snapshot1 (exact pre-release pin — Ontario's own artifact is draft 0.10.1 and will move). Two things consumers should know. (1) The context is Patient.identifier, not Patient — so it rides on an identifier the patient does have, in practice the MRN slice, because in exactly the case it describes there is no jurisdictional identifier to attach it to. SUSHI propagates the element to the base identifier and to both the jurisdictional and mrn slices. (2) Ontario's value set holds one clinical code (#no-HC) plus data-absent-reason #not-asked / #asked-declined, so it cannot distinguish newborn-awaiting-registration from refugee-on-IFHP from card-not-presented; carry those specifics in .text, or as an additional coding from a CodeSystem the IG declares. A Nexus-canonical equivalent was drafted and withdrawn in favour of the jurisdictional canonical, so later Ontario/Union-IG conformance is re-badging rather than remodelling. (FHIR-25)
Encounter.appointment is now modelled — the Appointment↔Encounter link, with the primary-care 1:1 expressed as a warning invariant plus prose rather than as cardinality. appointment stays 0..: R4 permits several Encounters to reference one Appointment (a visit that splits into multiple encounters — routine for specialists) and one Encounter to fulfil several Appointments, so tightening the cardinality would foreclose both and have to be unwound. Documents that Encounter is the association anchor for clinical resources, and that R4 has no reverse element on Appointment, so that direction requires a search. (FHIR-25)
Address.state and Address.country are now bound — the only prior statement was non-computable prose ("valid province codes"), and the divergence it permitted is already realized in production: one writer emits ISO alpha-3 while the address UI emits alpha-2, consumers do positional string surgery on the result, and outbound jurisdictional HL7 has been observed carrying "Ca-io" and "CANio". state binds required to the new NexusEmrProvinceStateVS (bare two-letter subdivision codes, 13 CA + 56 US, mirroring the frontend roster); country binds required to iso3166-1-2 (alpha-2), with alpha-3 an edge form only. Both are deliberately required against this IG's usually-lenient posture, because a closed roster is the only thing that makes the corruption fail loudly; patient-address-country-alpha2 (warning) names the observed bug so the diagnostic survives a lenient validator. ⚠ Producers writing spelled-out province names or alpha-3 country codes become non-conformant. ⚠ Migration caveat, carried in both elements' definitions so it reaches the IG pages and the generated typed API: these bindings were validated against the IG's own examples only — legacy inbound source-EMR data has not been surveyed, and source systems emit uncoded free-text on adjacent address fields, so spelled-out province names are plausible in existing records. Implementers migrating a corpus SHOULD profile their state/country distribution before enforcing, and MAY treat the bindings as extensible during migration (the warning invariant still reports the alpha-3 case). The caveat comes out of the definitions once the survey is done. (FHIR-25)
genderIdentity and pronouns now carry bindings — the IG adopted both HL7 extensions and bound neither, leaving real terminology governance in frontend TypeScript on must-support elements. genderIdentity binds required to NexusEmrGenderIdentityVS, deliberately broader than the HL7 value set it inherits: 10 of its 13 SNOMED concepts are Canada Health Infoway namespace (pan-Canadian GSSO) and are not members of hl7.org/fhir/ValueSet/gender-identity. pronouns binds extensible to NexusEmrPronounsVS (LOINC answer list), since pronoun sets are open-ended. Note both are complex extensions: the bindings sit on extension[value].value[x], not on the extension root, whose value[x] is 0..0. Absence reasons remain a data-absent-reason extension on the value and are not value-set members. (FHIR-25)
No generated directory is version-keyed any more, so a release renames nothing. The generated registry subpackage moves from src/ig/generated/nexus_emr_v__/ to src/ig/generated/nexus_emr/ (and the Python twin), finishing what 1.11.0 started when it de-versioned the vendored ig/nexus-emr/ directory. Exactly one version is generated at a time, so the version in the path carried no information the artifacts did not already hold — and it forced a git mv on every release, which made git record a whole-directory delete-plus-add and drowned the real spec diff in a release PR. The registry selector key is unchanged (nexus-emr-v1.12.0); the version still travels in the generated file headers, in IG_META, and in that key. Consumers importing the generated modules by path must update the path once; consumers resolving through the registry are unaffected. (FHIR-25)
Three profiles documented a PractitionerRole requirement their own constraints had already dropped — DocumentReference.authenticator read "Reference must be to a NexusEmrCorePractitionerRole" two lines above a constraint permitting both; DocumentReference.author said authors are "represented by NexusEmrCorePractitionerRole"; Patient.generalPractitioner said it "links to PractitionerRole". The same defect class 1.12.0 fixed in resource-relationships.md, and worse in effect, because these strings are baked into TypedFhir's generated FieldDoc and so mis-teach every consumer of the generated facade. Prose only — no constraint changed. (FHIR-25)
Practitioner is the primary provider identity; the Appointment provider participant is no longer PractitionerRole-shaped — this release relaxed every provider reference element to accept Practitioner alongside PractitionerRole, but Appointment was missed. The invariant appointment-participant-practitionerrole is renamed to appointment-participant-provider and now counts the provider participant regardless of which resource names them. The old rule was vacuous — a Practitioner/-shaped participant scored zero and passed — while reading as though PractitionerRole were required. Appointment.participant's definition and comment, and the createdBy extension's reference-target order and prose, now put Practitioner first. The walk-in example's provider changed from PractitionerRole/dr-navarro-familymed-role to Practitioner/dr-emil-navarro, so a Practitioner-shaped provider finally has a canonical example; the with-slot example deliberately keeps its PractitionerRole provider so both permitted spellings are exemplified. Consumers validating against the old invariant key must update it. (FHIR-25)
Schedule.actor now accepts a raw Practitioner as the provider — Schedule was the only place a PractitionerRole reference was a hard requirement rather than a target-type constraint: schedule-actor-required demanded one of PractitionerRole / Location / HealthcareService, so a Practitioner-shaped Schedule — the shape a primary-care writer would naturally emit — failed outright. The invariant now accepts a provider under either spelling, and schedule-actor-practitionerrole-max is renamed to schedule-actor-provider-max, capping the provider actor at one whichever resource names them. actor's definition documents both. Consumers validating against the old invariant key must update it. (FHIR-25)

Nexus IG 1.11.0

Sun, 02 Aug 2026 00:00:00 +0000

12 examples were never validated against their profiles — their meta.profile named a canonical that does not exist (nexus-emr-emrdevice, nexus-emr-allergyintolerance, nexus-emr-appdevice, nexus-emr-appstate, nexus-emr-clinicalimpression, nexus-emr-diagnosticreport, nexus-emr-documentreference, nexus-emr-medicationdispense, nexus-emr-servicerequest, nexus-emr-document-bundle-core), all missing the -core infix the profile Ids actually carry. The validator cannot resolve an unknown profile, so it silently falls back to base FHIR: those examples reported "0 errors" while never being checked against the profile they advertise. Corrected to the declared Ids, so every example is now checked against the profile it claims. (FHIR-25)
CareTeam, Flag and RelatedPerson now declare an effective date — the EffectiveDate/NoEffectiveDate sweep covered 26 profiles but not the three added alongside it, so consumers fell back to guessing. All three declare NoEffectiveDate: they are parties and administrative assertions, not dated events. Without it, RelatedPerson derived birthDate as its effective date — the exact invented-date failure the ruleset exists to prevent. (FHIR-25)
identifier documentation no longer claims "required" on optional profiles — the FHIR-22 relaxation dropped identifier to 0.. on 26 profiles, but 21 still carried ^short/^definition text saying "at least one business identifier is required" (and DocumentReference documented the deleted invariant as normative: "At least one identifier MUST follow the Nexus EMR naming pattern"). Those strings render on the IG profile pages and travel inside the StructureDefinitions, so implementers saw "required" on an optional element. Reworded to "recommended but not required". ClinicalTask (1..) keeps a floor, so its wording is unchanged. (FHIR-25)
Patient identifier slicing is now evaluable — the jurisdictional and mrn identifier slices now carry a patternCodeableConcept on identifier.type. The slice used a type pattern-discriminator but fixed only type.coding. (grandchildren the matcher does not traverse), so every Patient instance failed slice evaluation in the HL7 validator. No change to what conforms; the slicing now actually validates. (FHIR-25)
Example instances corrected to validate cleanly — fixed pre-existing errors across the example corpus: Task reasonReference cardinality (0..1) + input/output type code systems + a task-code display; MedicationRequest identifier/timing/dose; Consent attachment size/hash; a stray Invoice line-item extension; a double-LOINC BP Observation; and the ROUTINE/WALKIN appointment display names. The full example set now passes the new conformance/run-conformance.sh gate: 50/50 instances, 0 errors. (FHIR-25)
The experimental clinical-document surface is gone — NexusEmrCoreComposition and NexusEmrCoreDocumentBundle are removed from the IG, along with the extensions and value sets that existed only to serve them: nexus-emr-markdown-content, nexus-emr-embedded-section, nexus-emr-embedded-section-answer, nexus-emr-embedded-section-response, nexus-emr-canvas-annotation, nexus-emr-canvas-metadata, nexus-emr-file-metadata, and the nexus-emr-embedded-section-types / nexus-emr-canvas-annotation-types / nexus-emr-coordinate-systems / nexus-emr-file-categories value sets. The clinical-document guide pages and the document-bundle example go with them. The surface was experimental and unused; keeping it published invited implementers to build against a shape the IG was not committing to. Clinical documents remain representable through DocumentReference. Profiles drop 31 → 29, extensions 22 → 15, value sets 17 → 11. (FHIR-25)
NexusEmrCoreRosterPanel (the FHIR Group-based panel profile) and its CPAR-specific panel/submission extensions (PanelFacilities, PanelConfirmationDate, PrimaryProviders, SubmitDuringNextWindow, AutomatedSubmission) — superseded by the primary-care-attachment model above.
The deprecated contained-Medication pattern: the NexusEmrContainedMedicationCore profile and the medicationReference / mandatory contained wiring on MedicationRequest.
The CPAR and CII feature areas (mapping guides + CPAR-specific FSH). These were dependent on the old Polaris estate; they can be reintroduced against the new model if needed.
ClinicalTask input/output remodelled — Task.output is removed; Task.input is now the reference(s) to the chart element(s) the task is about (a report, requisition, prescription, problem, ...), with [input.value[x]](fhir/StructureDefinition-nexus-emr-core-clinical-task-elements-details.md#el-Task.input.value-x) constrained to Reference (any resource). Non-reference input parameters are no longer carried (use note/description for free text). input.type is left as a free-text label for now (no controlled vocabulary bound). This resolves the undefined task-input/output-type code systems the examples had referenced. (FHIR-25)
MedicationRequest: medication is now represented inline via medicationCodeableConcept (text required, DIN coding slice, medicationStrength extension), replacing the mandated contained-Medication pattern.
Encounter: class binding corrected to the canonical ValueSet http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (was a documentation HTML URL).

Nexus IG 1.10.0

Thu, 23 Jul 2026 00:00:00 +0000

conventions.md — PR review checklist / Definition-of-Done, seeded from Ryan Watson's Polaris conventions.md.
Renamed polaris → nexus-emr throughout: profile names (PolarisCore → NexusEmrCore), canonical slugs (polaris-core- → nexus-emr-core-), FSH aliases, invariant ids, file names, and example instances.
Reworked identifier/code enforcement from unevaluable slices to portable FHIRPath invariants (the "evaluable-slicing" convention, inherited from dev/stardust-integration and never released in Polaris): has-raw-identifier required (#error) on all top-level profiles; Appointment raw-code shape invariants for cancelationReason, reasonCode, serviceCategory, and serviceType (provide-what-you-have — codings optional, but code + display required when present).
app-consent: corrected the Consent.category pin from the invalid consentcategorycodes#infa (a code that does not exist) to the valid v3-ActCode#INFA.
Inherited Polaris contributing/governance docs and the "Ask Fira" nav entry, in favour of the lighter maintainer-review + file-a-ticket model.