OZO FHIR implementation guide
0.9.0 - ci-build
OZO FHIR implementation guide - Local Development build (v0.9.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
All notable changes to the OZO FHIR Implementation Guide will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Adopts RFC - Team Messaging Model (0.8.4) as a compatibility release. The three changes alter the CommunicationRequest, Task, Communication and AuditEvent contracts, but 0.9.0 accepts the 0.8.x shape of each resource next to the new one: the duplicate recipient is a validation warning, the acting-team extensions are inferred when absent, and per-member Tasks remain a supported server mode. The 0.9.0 package can therefore be installed under the 0.8.x AAA proxy without behaviour change, and 0.8.x clients keep working while the proxy switches behaviours per environment behind configuration flags. The strict cut-over is the release after 0.9.0. Implementation steps are on the new page AAA Proxy - Changes for 0.9.0.
SearchParameter/ozo-communicationrequest-participant) - Reference search parameter on CommunicationRequest with a union expression over recipient and extension[senderCareTeam], so one parameter matches every thread party. The AAA proxy scopes threads with participant= and messages with part-of:CommunicationRequest.participant=. Same construction as the base R4 Observation.combo-code. Advertised in the OZO-Client and OZO-System CapabilityStatements. HAPI needs a one-off reindex of CommunicationRequest after installation.ozo-agent-careteam) - Extension on AuditEvent.agent with Reference(OZOOrganizationalCareTeam): the team on whose behalf the agent acted. A read receipt names the team whose Task the OZO FHIR Api completes. FHIR R4 agent.who does not allow CareTeam.owner set to the CareTeam, replacing the per-member Tasks in the team messaging walkthrough. The initiating team's Task starts completed.agent.extension[careTeam]; one with the CommunicationRequest entity only (no message yet), one with the viewed Communication as second entity.ProfileInjector, content validation, response validation, ReadListService), proposed configuration properties, the three data migrations (duplicate recipients, team Tasks, stored Subscription criteria), the client checklist and a verification checklist.recipient. The invariant ozo-cr-sender-careteam-in-recipient (0.8.0, error) is replaced by ozo-cr-sender-careteam-not-in-recipient with severity warning: the 0.8.x shape (team in both places) is deprecated but still accepted, and the duplicate has no effect because the thread parties are the set union of recipient and the extension. The severity becomes error in the release after 0.9.0. The 0.8.0 duplicate existed because the proxy could not OR across recipient and sender-careteam; the union participant parameter removes that need. Element descriptions updated.CommunicationRequest and Communication (was unspecified, defaulting to Element). Description covers both uses.extension[senderCareTeam] (0..1, OZOSenderCareTeam), the organizational team on whose behalf the message is sent. When present it must reference an organizational team of the thread the sender participates in (the proxy rejects it with 422 otherwise). It becomes required in the release after 0.9.0 for senders who participate in an organizational team of the thread; in 0.9.0 a missing extension is accepted and the team is inferred (one candidate) or handled as in 0.8.x (all candidates, with a proxy warning).agent.extension[careTeam] (0..1, OZOAgentCareTeam), same rule and same transition for read receipts.owner allows Reference(OZOPractitioner or OZORelatedPerson or OZOPatient or OZOOrganizationalCareTeam) (additive). The OZO FHIR Api gains a team-Task mode, one Task per organizational team with owner = the CareTeam, next to the per-member mode of 0.8.x; an environment switches when its clients accept a CareTeam as Task.owner. Per-member Tasks for organizational teams are removed in the release after 0.9.0. One Task per member of a patient care team or individually addressed person stays in both modes. OZOPatient resolves the gap left by 0.7.8 (self-reliant patients in their own care team already received Tasks the profile did not allow).recipient lists Clinic-B only; Pharmacy-A is in extension[senderCareTeam].extension[senderCareTeam] (Clinic-B and Pharmacy-A).participant search parameter added; resource documentation describes the new scoping and the extension rules.participant, shared inbox by Task.owner), updated sequence diagram and example list. Page changelog row added.CommunicationRequest, Communication, Task field tables and the team-level messaging section updated; new examples listed. Messaging data model diagram updated (Communication.partOf, Task.owner, AuditEvent.agent.extension[careTeam]).participant), content validation (extension rules, 422), response validation (thread parties, team Tasks), event table (Task per party, acting team, transition), new "Request rejected with 422" troubleshooting section, "Task subscription not firing" updated. The 0.8.x recipient injection is documented as removed.agent.extension[careTeam] documented; team read receipt examples listed.participant as name; reuse OZOSenderCareTeam on Communication plus new ozo-agent-careteam; one-release transition without rejections; OZOPatient added to Task.owner; decoupled rollout behind proxy flags), a sixth decision on compatibility with 0.8.x implementations, and one correction: the proxy's response validation must include extension[senderCareTeam] among the thread parties, which the RFC had understated.Accepted in 0.9.0, removed in the release after 0.9.0:
CommunicationRequest.recipient next to extension[senderCareTeam] (the 0.8.0 shape). Validation warning ozo-cr-sender-careteam-not-in-recipient.Communication and read receipt AuditEvent resources in team threads without the acting-team extension. The OZO FHIR Api infers the team meanwhile.Task per member of an organizational team. The per-member engine mode stays available for one release.CommunicationRequest afterwards. The AAA proxy ships with three flags (participant scoping, team Tasks, acting-team inference) and is deployed with 0.8.x-compatible defaults. Switch scoping after the reindex and rewrite stored CommunicationRequest/Communication subscription criteria from recipient to participant; remove duplicate recipients from existing team threads only after that switch. Switch to team Tasks per environment together with the Task recomputation (member Tasks become cancelled). Details on the AAA Proxy 0.9.0 page.extension[senderCareTeam] or agent.extension[careTeam] is accepted; the proxy infers the team when the person is in exactly one organizational team of the thread and falls back to the 0.8.x behaviour (all of the person's teams in the thread) otherwise. An extension that names a wrong team is rejected with 422. The extensions become required in the release after 0.9.0.CommunicationRequest.recipient (access scoping moves to a union SearchParameter over recipient and extension[senderCareTeam]), one Task per organizational team with Task.owner set to the CareTeam, and an explicit team on every team-side action (extension[senderCareTeam] on Communication, an agent extension on the read receipt AuditEvent). Not normative until adopted; the current messaging pages stay authoritative.criteria changed from Communication?id and CommunicationRequest?id to Communication? and CommunicationRequest?. id is not a FHIR search parameter (the resource id parameter is _id). HAPI accepted the old form only because MatchUrlService.translateMatchUrl drops parameters without a value, so Task?id behaved as Task?; with a value it would have been rejected as an unknown parameter. HAPI does require the ?: a bare Task fails Subscription validation with "must be in the form {Resource Type}?[params]", so the empty form is the minimal valid criteria. Raised in the proxy team's review.Task? for read receipt detection) and in the "Task subscription not firing" entry, plus a note explaining the criteria form.make build failed on the dead fhir.nl.gf download - install-dependencies still depended on install-nl-gf, which fetched the NL Generic Functions package from build.fhir.org. That dependency was dropped in 0.7.0 and the CI build URL now returns 404, so every make build and make build-minimal (local and GitHub Actions) stopped at tar: Error is not recoverable. The target is removed.OZOOrganizationalCareTeam, no subject) and list the sender as a participant count; the OZO FHIR Api distinguishes the two CareTeam types by the presence of subject. A patient care team (OZOCareTeam) is never the sender's team, so a reply or read receipt in a patient network does not mark the message read for the other members. Also documented that extension[senderCareTeam] must be an organizational team the requester participates in; the thread is rejected otherwise. Raised by the proxy implementation: the previous wording ("any recipient CareTeam in which the sender is a participant") left connecting platforms asking whether patient teams count.CommunicationRequest now lists the sender check and the extension[senderCareTeam] check (an organizational CareTeam the authenticated user is a participant of). The event table describes team-wide read for organizational teams.requested and that clients should subscribe to Communication instead. The proxy patches Task.focus on every new message (documented on the messaging pages since 0.7.5), so Task?status=requested fires every time and is the only subscription a client needs. Both texts rewritten; the troubleshooting entry now lists the real causes (Task without owner, subscriber is the sender or in the sender's team, outdated proxy). Removed the readlist.force-task-update configuration row: the option was dropped from the proxy together with the Task.focus change.Communication.inResponseTo is now described as optional. The reply steps on the team messaging page read as if it were always set. It is the FHIR quote-reply link to one specific earlier message; the OZO thread model links messages to the thread via partOf and the OZO FHIR Api does not use inResponseTo for Task handling. Platforms without a reply-to-message concept can leave it out. The profile was already unconstrained (FHIR R4 base, 0..*).entity.what field has two values" replaced by "two entity entries, each with one what", which is what the profile allows (entity 0..*, entity.what 0..1) and what the examples show. Documented that the CommunicationRequest entity is required (the OZO FHIR Api finds the Task through it and ignores receipts without it) and that the Communication entity is optional but recommended (the OZO FHIR Api only completes the Task when it is the newest message in the thread; it also records which message was viewed).Task and only the OZO FHIR Api changes it; clients have read-only access to Task and no AuditEvent type sets a Task back to requested. A platform offering "mark as unread" keeps that state locally.input-cache/txcache) across runs with actions/cache, so repeated validations never hit the network.TX_OPTS Makefile variable is passed to the IG Publisher. CI builds main with -resetTxErrors (retry previously failed terminology calls, keep cached successes) and feature branches with -tx n/a (no terminology validation, fast feedback). build_with_image.sh passes TX_OPTS through for local builds, e.g. TX_OPTS="-tx n/a" sh build_with_image.sh.SearchParameter/ozo-communicationrequest-sender-careteam) - Reference search parameter on CommunicationRequest.extension[senderCareTeam]. GET /CommunicationRequest?sender-careteam=CareTeam/Pharmacy-A returns the threads a team initiated. Advertised in the OZO-Client and OZO-System CapabilityStatements. Replaces the invalid _has:Extension:url=... query that the team messaging page used to show.offline_access at login, stores the IdP refresh token per practitioner, mints a fresh id_token via the refresh grant, wraps it in a new NutsEmployeeCredential, and requests a new access token through its NUTS node. Lists the conditions under which OZO accepts assertions obtained through a refresh grant (trusted IdP, assertion validity, maximum authentication age via auth_time, audit attribution to the practitioner).extension[senderCareTeam]) must now also be listed in recipient. The new invariant ozo-cr-sender-careteam-in-recipient enforces this. Rationale: the AAA proxy scopes access to threads, messages and Tasks on recipient, and HAPI cannot OR across search parameters (_filter is blocked), so without this entry the members of the initiating team could not see the thread they started and the Task engine had no way to address them.iso-21089-lifecycle#access to the required type ValueSet. This is the type clients use for read receipts and the only type the OZO FHIR Api recognises when completing Tasks; the profile previously rejected it.Clinic-B (addressed team) and Pharmacy-A (initiating team) as recipient.type = rest with subtype = read to type = iso-21089-lifecycle|access without subtype, matching what the messaging pages prescribe and what the OZO FHIR Api and the clients actually use. Titles and descriptions now identify them as read receipts.Communication links to its thread via partOf, so the searches use part-of (was based-on, a different element). Documented that recipient lists both teams, how the OZO FHIR Api determines the sender's team for Task handling (team-wide read), and the read-receipt AuditEvent type. Sequence diagram updated accordingly.SearchParameter in supported_resource_types and the reindex step.StructureDefinition-OZOAuditEvent.html) while the IG Publisher names the page after the profile Id (StructureDefinition-ozo-auditevent.html).Audit-driven addition of Severity: #error invariants on every OZO profile field where listing the same FHIR Reference twice has no semantic meaning. Triggered by a staging incident on CareTeam.participant.member (see below); the audit found the same data-integrity class of bug latent across four other fields. AuditEvent's agent and entity are intentionally excluded — same actor in different agent.type (e.g. user + system) is a legitimate audit-chain pattern and would be falsely rejected.
ozo-careteam-unique-members on participant.member.reference. A staging CareTeam was found with the same Practitioner/<uuid> referenced from two different participant entries, which made FHIR Patch delete operations fail with HAPI-1267: Multiple elements found ... when deleting (per spec, delete requires the FHIRPath to return a single element).ozo-communicationrequest-unique-recipients on recipient.reference. Threads with the same recipient listed twice are semantically empty noise.ozo-communication-unique-recipients on recipient.reference and ozo-communication-unique-partof on partOf.reference. Same shape as CommunicationRequest plus thread-linkage symmetry. (recipient is documented as unused in OZO; the invariant is defensive against accidental misuse.)ozo-task-unique-basedon on basedOn.reference. Linking the same thread twice is meaningless.All invariants follow the pattern <field>.reference.distinct().count() = <field>.reference.count() — comparing literal reference strings. Logical references via identifier are not de-duplicated. If OZO ever needs to differentiate by role/period (CareTeam) or other discriminators, the invariants must be relaxed accordingly.
Deploy order matters: existing resources that already violate any of these invariants become non-updatable until cleaned up (HAPI validates write-side, not read-side). A pre-deploy scan on staging found exactly one offending CareTeam — already patched in this iteration (142de2d6-9f32-4f7b-9e98-5ecb92af05e1, v4 → v5, 4 → 3 unique participants). Rollback: revert to the previous IG version in ozo-cloud-deployment; no schema or data migration involved.
Validation requires meta.profile to be set on the resource (HAPI is configured with DECLARED mode on staging/production). The OZO Matrix bridge already sets meta.profile = OZOCareTeam/OZOCommunication/etc. on its writes, so bridge-originated data is covered.
OZOPatient to allowed types on participant.member. Self-reliant patients ("zelfredzame cliënten") can now participate in their own care network directly as Patient, without needing a separate RelatedPerson record.category from 1..* to 0..*. The SNOMED CT practice setting list lacks coverage for primary care and the social domain, making it impractical to require a coded category for all team types. Category is now optional — teams can provide any code system (SNOMED CT, Dutch organization type list urn:oid:2.16.840.1.113883.2.4.15.1060, or plain text).Task.focus being updated on every new Communication, Task?status=requested is now sufficient as the primary subscription for both unread tracking and new-message notification. Both messaging pages updated to:
Task?status=requested as the only required subscriptionCommunication?id as optional (only needed to see own sent messages)CommunicationRequest?id as optional (only needed for thread lifecycle events)Task.focus updates solve itTask?id is only needed when the platform also wants to detect read receipts (REQUESTED → COMPLETED transitions)focus field (0..1, Reference(OZOCommunication)) to point to the latest Communication in the thread. When a new message arrives, the OZO FHIR Api updates Task.focus to reference the new Communication. This ensures Task subscriptions fire even when the status value doesn't change (the resource content genuinely changes), and gives clients a direct pointer to the most recent unread message.requested (correct for examples showing what a client would create). The HAPI activation issue is solved by the minimal package stripping examples.status from requested to off to prevent HAPI from activating example subscriptions with unreachable endpoints on server restart. Changed endpoint URLs from example.nl to example.com.source.observer in AuditEvents. Resolves HAPI HAPI-0575 validation error where a plain Device resource was rejected because it didn't conform to any of the installed Nictiz Device profiles (medical devices only). The proxy can now upsert a Device with meta.profile = OZODevice and it will be accepted.source.observer no longer constrained to Reference(Device). Now accepts any reference type with logical identifiers (system/value) — no Device resource needs to exist on the server.entity.what from 1..1 to 0..1. Empty search results are access attempts that must be logged for NEN7510 but don't reference a specific resource — the search query in entity.query serves as the audit trail. Aligns with FHIR R4 base.https://www.ozoverbindzorg.nl/namingsystem/{type} without ozo/ or ozo-connect/ prefixes: .../person, .../professional, .../organization, .../team, .../network-relation, .../email, .../devicesource.observer changed from literal Reference(Device/ozo-aaa-proxy-001) to logical identifier with system = .../device, value = aaa-proxy-001https://www.ozoverbindzorg.nl/namingsystem/device)fhir.nl.gf references from configuration, dependency table, troubleshooting, and complete exampleTask?id note on both messaging pages: needed for read-list tracking (REQUESTED → COMPLETED transitions)fhir.nl.gf (NL Generic Functions) dependency. OZOPractitioner and OZOOrganization no longer extend NL-GF profiles — they now extend base FHIR R4 Practitioner and Organization directly. This eliminates the AssignedId slice, the HAPI-0574 workaround, and the dependency on an unpublished package.0..* MS with open slicing. No named slices, no invariants. Any identifier system accepted.0..* MS with open slicing. Removed all 5 named slices and invariant.NlGfPractitioner to Practitioner. Simplified identifiers to 0..* MS with open slicing. Removed AssignedId slice and invariant.NlGfOrganization to Organization. Simplified identifiers to 0..* MS with open slicing. Removed AssignedId and URA slices.ozoverbindzorg.nl/namingsystem/professionalozoverbindzorg.nl/namingsystem/organizationoverview.md identifier tables for all resource typesinteraction-network.md identifier requirements sectionOZOPatient to allowed sender types. Production data shows Patient resources are used as senders (4 out of 192 Communications).OZOPatient to allowed requester and sender types. Production data shows Patient resources are used as requester/sender (2 out of 33 CommunicationRequests).Patient/$expunge is supported for AVG/GDPR right-to-erasure. Includes status mapping per resource type, security labels, and proxy enforcement guidance.entity.what references to version-specific format ({ResourceType}/{id}/_history/{version}). NEN7510 requires audit events to reference the exact version of the resource accessed, not the mutable current version.entity.what must use version-specific references for NEN7510 compliance. Non-versioned references become broken links when resources are deleted, undermining the legal audit trail.status field, and AuditEvent entity references not version-specific.recipient from 1..* to 0..*. Thread participants are defined on CommunicationRequest.recipient — individual messages do not have separate addressing. The field is kept from the parent profile for FHIR compliance but documented as unused in the OZO messaging model. Matches production data where no Communication resources have a recipient.recipient from all Communication examples (Reply-Manu-to-Kees, Reply-Kees-to-Netwerk, Clinic-Response-to-Pharmacy, Pharmacy-Followup-by-Pieter)recipient 0..* as unusedrecipient is not set on Communicationspart-of:CommunicationRequest.recipient instead of Communication.recipientchannel.payload as required in Dutch healthcare). Covers new message detection, unread tracking, and thread lifecycle.inResponseTo reference (was pointing to deleted Pharmacy-Initial-Message; this is now the first reply in the thread, responding to the CommunicationRequest payload)Notify-Manu-van-Weel, Notify-Mark-Benson, Notify-Kees-Groot - Changed Task examples from #completed to #requested (initial state when created by the OZO FHIR Api). Added Title and Description.
Task?id to Task?status=requested to avoid subscription storms and scope via AAA proxyCommunication subscription is the primary mechanism for new-message detection, not TaskTask notifications detect new messages — Task is a read/unread indicator onlysubject 0..0 — organizational teams have no patientmanagingOrganization 1..1 — required link to the owning Organizationcategory 1..* — required SNOMED CT coded team typename 1..1 — team display name requiredparticipant.member restricted to OZOPractitioner only (no RelatedPerson in org teams)interaction-messaging-team.md) with stepwise walkthrough of team-to-team messaging flows, including thread creation, replies from both teams, follow-up by different team members, and read receiptsOZOOrganizationalCareTeam. participant.member now also allows OZOOrganizationalCareTeam for nested team references (fixes existing conformance bug where Netwerk-Jan-de-Hoop referenced Department-Thuiszorg as CareTeam participant but the profile did not allow it)recipient now also allows OZOOrganizationalCareTeam in addition to existing typesrecipient now also allows OZOOrganizationalCareTeam. OZOSenderCareTeam extension tightened from Reference(CareTeam) to Reference(OZOOrganizationalCareTeam) (formalizes existing practice)OZOCareTeam to OZOOrganizationalCareTeam profile. Removed fake Patient/example-unassigned subject references that were a workaround for the previous subject 1..1 constraintOZOOrganizationalCareTeam profile and canonical URLsenderCareTeam extension pattern (sender field is always an individual, extension provides CareTeam reply-to address)Cache-Control header requirements for FHIR requests (no-cache vs no-store), pagination with _count and Bundle next links, and the OZO proxy Warning: 199 header for no-store detectionCT-, Msg-, Tsk-, AE-) that caused ugly doubled page URLs (e.g., CareTeam-CT-H-de-Boer.html). The IG Publisher already prepends the resource type to page URLs, making prefixes redundant.
CT-H-de-Boer → Netwerk-H-de-Boer, CT-Jan-de-Hoop → Netwerk-Jan-de-Hoop, CT-Department-Thuiszorg → Department-Thuiszorg, CT-Clinic-B → Clinic-B, CT-Pharmacy-A → Pharmacy-AMsg-RelatedPerson-to-CareTeam → Reply-Kees-to-Netwerk, Msg-Team-Reply-1-Initial-Message → Pharmacy-Initial-Message, Msg-Team-Reply-2-Clinic-Response → Clinic-Response-to-Pharmacy, Msg-Team-Reply-3-Pharmacy-Followup → Pharmacy-Followup-by-PieterTsk-Practitioner-Manu-Example → Notify-Manu-van-Weel, Tsk-Practitioner-Mark-Example → Notify-Mark-Benson, Tsk-RelatedPerson-Example → Notify-Kees-GrootAE-System-Access → System-Read, AE-Practitioner-Manu-Access → Manu-Read-Messages, AE-Practitioner-Mark-Access → Mark-Read-Messages, AE-RelatedPerson-Access → Kees-Read-Messages, AE-REST-Create-Example → REST-Create, AE-REST-Search-Example → REST-Search, AE-REST-Update-Failure → REST-Update-DeniedMsg-Practitioner-to-Practitioner example (which had sender = recipient = same person and wrong payload text)HAPI-0574: Slicing cannot be evaluated: Could not match discriminator ($this) for slice Practitioner.identifier:AssignedId:
^patternIdentifier.system to the AssignedId slice on both profilesAssignedId slice (inherited from NL-GF parent profiles) uses a value:$this discriminator but lacked a top-level patternIdentifier, preventing HAPI from matching identifiers to the slicehttps://ozo.headease.nl/practitionershttps://ozo.headease.nl/organizationsoverview.md, interaction-messaging.md, interaction-network.md, and auditevent-nen7510.md to match new Instance namesfetchDependencies: true approach with explicit dependency listing — transitive dependencies pull in hl7.fhir.r4.core and hl7.fhir.uv.extensions.r4 which contain R5-only SearchParameters (DeviceUsage, DomainResource) that crash HAPI R4hl7.fhir.uv.extensions.r4 as STORE_ONLY entry to satisfy dependency resolution without installing problematic SearchParametersnictiz.fhir.nl.r4.zib2020 and nictiz.fhir.nl.r4.nl-core entries as STORE_AND_INSTALLfhir.nl.gf as a separate implementation guide entry (with direct packageUrl to CI build)install_transitive_ig_dependencies: false to prevent recursive dependency installationHAPI-1684: Unknown resource name "DeviceUsage" / "DomainResource" (R5-only SearchParameters)HAPI-1301: Unable to locate package fhir.nl.gf#0.3.0security tool on macOS^version overrides (values like "0.2.1", "1.0.0", "2.0.0") that were misleading. The IG Publisher sets StructureDefinition.version to the IG package version from sushi-config.yaml, making per-profile version overrides redundant. All profiles now consistently report the IG version.fhir.nl.gf v0.3.0 to the package dependencies table with manual installation noteImplementationGuide and StructureDefinition to the recommended supported_resource_types configurationimplementationGuide field{ResourceType}-{id}.html. Previously, Instance names like Patient-H-de-Boer produced page URLs like Patient-Patient-H-de-Boer.html (doubled prefix), causing 404 errors from documentation linksPatient- prefix (e.g., Patient-H-de-Boer → H-de-Boer)Practitioner- prefix (e.g., Practitioner-Manu-van-Weel → Manu-van-Weel)RelatedPerson- prefix (e.g., RelatedPerson-Kees-Groot → Kees-Groot)Organization- prefix (e.g., Organization-Ziekenhuis-Amsterdam → Ziekenhuis-Amsterdam)CareTeam- with CT- prefix (e.g., CareTeam-H-de-Boer → CT-H-de-Boer)CommunicationRequest- prefix (e.g., CommunicationRequest-Thread-Example → Thread-Example)Communication- with Msg- prefix (e.g., Communication-RelatedPerson-to-CareTeam → Msg-RelatedPerson-to-CareTeam)Task- with Tsk- prefix (e.g., Task-RelatedPerson-Example → Tsk-RelatedPerson-Example)AuditEvent- with AE- prefix (e.g., AuditEvent-System-Access → AE-System-Access)* id overrides from 13 instances that had numeric IDs (e.g., * id = "1209") — the Instance name now serves as the id"Practitioner/1208") to FSH Reference() syntax (e.g., Reference(Marijke-van-der-Berg)) in CareTeam and RelatedPerson examplesoverview.md, interaction-network.md, interaction-messaging.md, and auditevent-nen7510.md to match new Instance names and generated page URLsPractitioner to NlGfPractitioner (nl-gf-practitioner):
nl-core-HealthProfessional-Practitioner via nl-gf-practitionerAssignedId identifier requirement (1..1) with assigner pattern linking practitioners to their employing organizationvalue:$this slicing discriminator. OZO identifiers are still validated via ozo-practitioner-has-professional-id invariant and supported through open slicingAssignedId identifier with https://ozo.headease.nl/practitioners system, practitioner slug as value, and employing organization's URA as assignerfhir.nl.gf v0.3.0) - Added as a dependency to support care services directory compliance and IHE mCSD alignmentcare-services-directory.plantuml)Organization to NlGfOrganization (nl-gf-organization):
nl-gf-organization via nl-core-HealthcareProvider-Organization)AssignedId identifier requirement (1..1) with assigner patternura-identifier-or-partof invariant: organizations must have a URA identifier or be partOf another organizationAssignedId identifier, type (V4 Ziekenhuis), updated URA system to canonical URLAssignedId identifier, type (V4 Ziekenhuis), updated URA system to canonical URLAssignedId identifier, type (Z3 Huisartspraktijk), updated URA system to canonical URLAssignedId identifier, type (G2 Apotheek), updated URA system to canonical URLinstall-nl-gf Makefile target to download fhir.nl.gf package from CI build (package is not published on FHIR registry)scripts/get_dependencies.py to parse sushi-config.yaml dependencies for automated installationOZO/Person → https://www.ozoverbindzorg.nl/namingsystem/ozo/personOZO-CONNECT/Person → https://www.ozoverbindzorg.nl/namingsystem/ozo-connect/personOZO/Professional → https://www.ozoverbindzorg.nl/namingsystem/ozo/professionalOZO-CONNECT/Professional → https://www.ozoverbindzorg.nl/namingsystem/ozo-connect/professionalOZO/Team → https://www.ozoverbindzorg.nl/namingsystem/ozo/teamOZO-CONNECT/Team → https://www.ozoverbindzorg.nl/namingsystem/ozo-connect/teamOZO/NetworkRelation → https://www.ozoverbindzorg.nl/namingsystem/ozo/network-relationemail → https://www.ozoverbindzorg.nl/namingsystem/email (temporary - should migrate to telecom)ura → http://fhir.nl/fhir/NamingSystem/ura (Nictiz standard)did_web → urn:ietf:rfc:3986 (value is itself a URI)build_with_image.sh to use ghcr.io imageoverview.md and interaction-network.md with new identifier URI patternsCommunicationRequest.sender does not allow CareTeam referencesOZOSenderCareTeam extension to support team-level messaging where a CareTeam needs to be the reply-to addresscopy-changelog Makefile target copies CHANGELOG.md to history.md during buildsender field constraint allowing OZOPractitioner, OZORelatedPerson, or OZOCareTeamsender serves as the reply-to address for team-level messaging and provides team-level authorizationrequester remains restricted to individuals (OZOPractitioner or OZORelatedPerson) to preserve auditabilitybuild-minimal and build-ig-minimal Makefile targetsscripts/convert_ig_to_package.py - Converts ImplementationGuide to package.json formatscripts/create_index.py - Creates .index.json for FHIR package structurescripts/strip_narratives.py - Strips narratives and mappings while preserving snapshots-minimal suffix)fhir-package-full) and minimal (fhir-package-minimal) builds.gitignore to exclude /output-minimal/ and additional build artifactsOZOPatient, OZOPractitioner, and OZORelatedPerson profiles:
OZO/Person, OZO-CONNECT/Person, OZO-MOBILE/Person, OZO-WEB/Person)ozoProfessionalId to ozoConnectProfessionalId for identifiers using the OZO-CONNECT/Professional system^url, ^name, and ^description metadata elements to all OZO FHIR profiles for improved canonical URL support and HAPI FHIR server compatibility:
OZOAuditEvent - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOAuditEventOZOCareTeam - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOCareTeamOZOCommunication - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOCommunicationOZOCommunicationRequest - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOCommunicationRequestOZOOrganization - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOOrganizationOZOPatient - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOPatientOZOPractitioner - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOPractitionerOZORelatedPerson - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZORelatedPersonOZOTask - http://ozoverbindzorg.nl/fhir/StructureDefinition/OZOTaskinput/fsh/input/fsh/instances/ to input/fsh/examples/ for improved organization and clarityaliases.fsh from input/fsh/input/fsh/ to input/fsh/ (root level)input/fsh/input/fsh/profiles/ to input/fsh/profiles/OZOPatient - Patient profile for the OZO platform with OZO Person identifier and BSN supportOZOPractitioner - Practitioner profile with OZO Professional identifier and email slicingOZORelatedPerson - RelatedPerson profile for informal caregivers with OZO Person and NetworkRelation identifiersOZOOrganization - Organization profile with URA and OZO Organization identifiersOZOCareTeam - CareTeam profile representing care networks with practitioners and related personsOZOCommunication - Communication profile for messages with thread linking via partOfOZOCommunicationRequest - CommunicationRequest profile for message threadsOZOTask - Task profile for work assignments and referrals with thread linking via basedOnOZOAuditEvent - AuditEvent profile for NEN7510 compliance with W3C Trace Context extensionsaliases.fsh with common system and profile aliases