| Date |
Version |
Description |
| 30 Sep 2026 |
1.3.2 |
- Made
EBookingsEncounter.status advanceable so a hospital can record the progress of the admission through to discharge. The profile previously pinned status to planned (1..1, patternCode), which contradicted its own leading comment — "with the expectation that encounter will be updated as it progresses to completion" — and left the intended code set commented out in the source. status is now bound required to a new EBookingsEncounterStatus value set of planned | arrived | in-progress | finished. The codes carry their FHIR meanings: finished means the admission ended, that is, the patient was discharged. A practice may take a finished encounter to mean that the booked procedure was performed, unless the booking was cancelled. For an inpatient stay, discharge can be days after the operation, so the practice learns of it at discharge. This release has no separate signal for procedure performed. Cancellation is deliberately excluded so that Appointment.status = #cancelled remains the single source of truth for a booking that does not proceed, including one cancelled after admission. period.end (discharge date) stays optional, and now carries a ^comment. Before discharge it may carry the anticipated discharge date, as period.start carries the anticipated admission date/time at booking. When status becomes finished, the hospital sets it to the actual discharge date. A new invariant, ebookings-encounter-finished-end-01 (status = 'finished' implies period.end.exists()), reports a finished encounter without period.end at warning severity, so it does not reject one. Nothing that validated before becomes invalid: planned remains a member of the new value set.
- Clarified that
EBookingsEncounter is the hospital admission for the operation, not the consultation at which the booking was made. This was already implied by the element constraints (class of inpatient / ambulatory / short-stay, period.start as admission date/time, period.end as discharge date, length in inpatient days, location.display as hospital name) but was contradicted by the eBookings search table, which described the Encounter:based-on revinclude as "Encounter that created the appointment". The profile Description now states the distinction and the status lifecycle, and the search table row is corrected.
- Declared
Encounter in the eBookings CapabilityStatement with read, create and update. The resource was profiled and carried in the booking create Bundle but had no entry in the CapabilityStatement at all, so the hospital-updates-status flow had no declared interaction surface. The update interaction documents that the hospital advances status through the admission, and sets finished and period.end when the patient is discharged. Added EBookingsEncounterCompleted ("EBookings Encounter — Discharged") as a worked example of the finished state. It is a one-night stay, so length is 1 day.
- Corrected the definition of
fulfilled on EBookingsAppointment.status. It read "encounter in progress", which is not the FHIR meaning. It now reads "the booked procedure has been performed; not currently used". fulfilled stays in the bound value set but is not used in this release, and nobody sets it. It is kept for later use, when the practice or the platform may set it. The Appointment profile introduction is corrected to match.
- Reparented
GSOrganization, GSPractitioner, GSPractitionerRole and EOrdersPractitionerRoleContact from the AU Core profiles onto the corresponding AU eRequesting 1.0.1 profiles (AUeRequestingOrganization, AUeRequestingPractitioner, AUeRequestingPractitionerRole). Each eRequesting profile is itself derived from the AU Core profile we previously parented, so this inserts the national eRequesting layer into the derivation chain rather than replacing anything. These three were selected because they are the only referenced profiles where AU eRequesting imposes nothing this IG does not already impose: measured against the published snapshots, eRequesting adds no mandatory element over AU Core for any of the three (Organization 1, Practitioner 3, PractitionerRole 2 mandatory elements on both sides), so no instance that validated before can become invalid. Verified in the build made with this change: 0 errors, 0 broken links, and every example still validates. 2 broken links appeared later, with the rewrite of 33 profile descriptions below, and are fixed in this release. The eRequesting layer carries its requirements as obligation extensions (actor-specific SHALL/SHOULD) rather than mustSupport flags, which is the source of the large increase in informational messages — 1,506 of them are obligation|5.3.0 slice notices emitted against the inherited obligations, not findings against Magentus resources. AUeRequestingPractitionerRole also retargets practitioner and organization at the eRequesting profiles; because all three were reparented together, this IG's existing narrowing of those references to GSPractitioner and GSOrganization remains valid. The remaining referenced profiles are not yet safe to reparent: GSPatient would inherit identifier 1..*, EOrdersEncounter would inherit subject 1..1, EOrdersCoverage would inherit a fixed status = active and a different status binding, and EOrdersCopyToPractitionerRole would inherit practitioner 1..1 where this IG deliberately allows 0..1, since a copy-to recipient may be identified by name alone.
- Declared
hl7.fhir.au.ereq 1.0.1 as a dependency, restoring the AU eRequesting dependency that 1.3.1 removed. The 1.0.1 errata (published 10 Sep 2026) repins hl7.fhir.uv.ips from 2.0.0 to 2.0.1 and hl7.fhir.uv.extensions.r4 from 5.2.0 to 5.3.0 together, and moves hl7.terminology.r4 to 7.3.0 — so au.ereq's dependency graph now matches this IG's exactly and only one IPS version loads. That removes the condition behind the 1.3.0 failure, where the IG declared IPS 1.1.0 while au.ereq pulled 2.0.0 and the resolver selected the broken version, writing |2.0.0 into the previously versionless ObservationPregnancyStatusUvIps references. Verified with the declaration alone, before the reparenting above was added in the same change: one IPS version loaded (2.0.1), no IPS canonical pinned anywhere, and the warning count unchanged at 85. On its own, the declaration had no effect on the published artefacts beyond the manifest entry. The 85 figure is from a build with no terminology server (-tx n/a). The 1.3.2 release build, at IG Publisher 2.3.4 against tx.hl7.org.au, gives 58 warnings — see the validation entries below. The release build also confirms that all nine generated ObservationPregnancyStatusUvIps references are versionless. The published package carries 17 occurrences in nine files, because the snapshots repeat them, and all of those are versionless too. The errata is dependency-only: comparing the 1.0.0 and 1.0.1 packages, all 21 profiles are present in both with no differential changed, so no profile analysis based on 1.0.0 is invalidated. The dependency is referenced in this release by the reparenting of GSOrganization, GSPractitioner, GSPractitionerRole and EOrdersPractitionerRoleContact (see the entry above).
- Broadened
Task.output[diagnosticReportOutput] on EOrdersTaskFulfillmentBase to reference the diagnostic report directly — value[x] now accepts GSPathologyReport or GSRadiologyReport as well as the existing GSImagingTaskReportRequest. The link from a diagnostic request to its report is carried by this output; the receiving Task was only ever an indirection to reach the report, and the slice discriminator was already type = DiagnosticReport, so the reference now matches what the slice declares. Tasks continue to document the receiving workflow performed by the consuming system — that is unchanged, and GSImagingTaskReportRequest remains in use from GSImagingReportTransaction.entry[reporttask]. The Task target is retained here only for backward compatibility during transition and will be removed in a later release; new implementations must reference the report. No example populates this slice, so nothing existing breaks.
- Documented the consent document arrangements for theatre bookings in a new introduction on
EBookingsConsent, alongside the three consent approaches (active with an attached form, proposed for consent provided on the day of theatre, draft for no decision made). Added inactive to EBookingsConsentStatus for a withdrawn or revoked consent. The platform does not support it yet, and the IG says so. The platform keeps one Consent per booking, so a change of consent option is a new version of the same resource. When a PMS user removes the form and selects "present on the day", the new version has proposed and no sourceAttachment. That change withdraws the consent on the attached form, but one Consent cannot show both the withdrawal and the new consent expected on the day, so a consumer compares the new version with the previous active one. Also added Current behaviour notes where the platform differs from the intended design: the platform keeps a removed form, but the IG does not guarantee that it stays retrievable; a form from Gentu gets a new URL only when Gentu creates a new attachment; and a form from Gentu is not checked to be a PDF, although contentType is always application/pdf. The value set is bound required and had no status for withdrawal, so a withdrawn consent could not conform. Removing only url would not conform either, because url is 1.. whenever sourceAttachment is present, so the whole sourceAttachment is removed. Adding a code to the value set is a loosening: nothing that validated before becomes invalid. Added invariant ebookings-consent-active-attachment-01 (status = 'active' implies source.ofType(Attachment).exists(), severity error). This is a tightening: an active consent without an attached form was valid before and is now rejected. EBookingsConsentBobSmith, which was active without an attachment, now carries one. The consent examples now use the placeholder origin https://documents.magentus.example, so that they follow the new origin rule. Each environment has its own origin. The profile prohibits sourceAttachment.data, so the signed form is always reached through sourceAttachment.url; the new page records that the repository is hosted by Magentus in AWS, that it is accessed with the same token as FHIR API access (no separate credential, network or firewall arrangement), that the URL is permanent rather than pre-signed or expiring, and that retention follows the standard clinical-data policy. It also sets out custody — the consuming system retrieves the form with the booking and retains its own copy, the repository is not its long-term authoritative store, and the FHIR server is not an audit service — and change handling: a change is detected by the new Consent version (meta.versionId), not by comparing URLs, because the platform does not prevent a change behind an existing URL (by design a replaced form gets a new URL, and that is a hint only), updates and replacements are conveyed as an updated Consent resource rather than by polling the URL, and on withdrawal status becomes inactive and the whole sourceAttachment is removed, after which the document is no longer retrievable. Written from questions raised by an integration partner.
- Added
GSDVANumber (gs-dvanumber), a profile on AU Base AUDVANumber that names Identifier.period.end as the DVA Veteran Card expiry date, and repointed the dva identifier slices on GSPatient and GSCoverage at it. AU Base defines Identifier.period.end explicitly on AUMedicareCardNumber ("Medicare card expiry date") but leaves it untouched on AUDVANumber, so a Veteran Card expiry inherited only the generic Identifier.period wording and implementers had no signal as to what the element meant. Nothing is newly permitted — period and period.end were already available at 0..1 through the base Identifier datatype — and no mustSupport is set, matching AU Base's treatment of the Medicare card expiry, which is likewise descriptive only. Bundle-ERequest-Example now carries a period.end on its DVA identifier to demonstrate the element. Worth raising with HL7 AU as an errata candidate: the asymmetry between the two identifier profiles looks unintentional.
- Added matching
^comment guidance on EBookingsConsent.sourceAttachment.url and .data, and a pointer from the Theatre Booking Content Changes section of the eBookings page to the new consent documentation.
- Restricted where the access token may go when a client retrieves a consent document.
sourceAttachment.url is always HTTPS on the Magentus document repository origin. Before it attaches the FHIR access token, a client SHALL check that the scheme and host exactly match that origin, and SHALL NOT send the token to any other origin. A URL on any other origin is an error and SHALL NOT be retrieved. Without this rule, a changed or malicious URL could send the access token to another host. The rule is in the consent introduction and the url comment. It is not an invariant, so the profile does not fix the repository host.
- Moved
hl7.fhir.uv.ips from 1.1.0 to 2.0.1. 1.3.1 had reverted IPS to 1.1.0 to stop the order-write failures; this release moves it forward to 2.0.1, which fixes the same problem at source. IPS 2.0.0's Patient-uv-ips asks for the individual-genderIdentity and individual-pronouns extensions at version 5.3.0-ballot-tc1, but no package ships that version — IPS 2.0.0 itself only depends on hl7.fhir.uv.extensions.r4 5.2.0. The pinned canonicals therefore never resolve, Patient.extension slicing cannot be evaluated, no Patient can be matched against Patient-uv-ips, and everything referencing the Patient fails with Reference_REF_CantMatchChoice — including Task.focus, which made Smile CDR reject the whole eOrders order bundle with a 422. IPS 2.0.1 pins both extensions at 5.3.0 and moves its own hl7.fhir.uv.extensions.r4 dependency to 5.3.0, which is the version the build resolves, so the canonicals resolve and the failure is addressed at source. The hl7.fhir.au.ereq dependency removed in 1.3.1 returns in this release at 1.0.1 — see the separate entry above. Verified in the build: one IPS version loaded, extensions.r4 resolved to 5.3.0, and all nine generated ObservationPregnancyStatusUvIps references versionless. This also clears the "IPS package out-of-date" advisory raised by the 1.1.0 revert.
- Added SNOMED CT
77386006 "Pregnant" as the first valueCodeableConcept.coding on the three obstetric example instances (ObservationPregnancyStatusUvIps-Inline-3, Bundle-PathologyRequest-Example, EOrdersPathologyRequest-Rule3ExemptionExample), keeping LOINC LA15173-0 "Pregnant" as a second coding. IPS replaced the contents of pregnancy-status-uv-ips between 1.1.0 and 2.0.x: 1.1.0 bound to LOINC answer codes (LA15173-0, LA26683-5, LA4489-6), while 2.0.1 binds to SNOMED CT (77386006, 60001007, 152231000119106, 146799005), so the LOINC codes are no longer in the value set. 2.0.x also relaxed the valueCodeableConcept binding from required to preferred, so this surfaced as five information messages rather than errors — but the examples were carrying only codes the profile no longer recommends, and those would become errors if the binding were ever re-tightened. Carrying both codings satisfies the 2.0.1 binding while remaining readable by consumers still matching on the IPS 1.1.0 LOINC codes; the profile does not slice coding, so the repeat is unconstrained.
- Declared
http://terminology.hl7.org.au/CodeSystem/coverage-selfpay in the special-url IG parameter, clearing the two build errors that republishing it introduced (URL Mismatch / "the canonical URL does not match the URL"). The publisher flags any conformance resource whose canonical falls outside the IG's own canonical base; here that is deliberate, because eOrders sends the AU URL on the wire and re-canonicalising under http://fhir.geniesolutions.io would defeat the resolution the republication restores. Build returns to 0 errors.
- Noted on
AUCoverageSelfPay that payconc is present in the international coverage-selfpay CodeSystem from its version 1.0.1, first shipped in hl7.terminology 6.2.0; earlier editions carry pay only. A terminology load predating THO 6.2.0 therefore resolves pay but not payconc from the international system, which is a further condition to check before revisiting the repoint.
- Rewrote the filler discovery guidance in
requesting.md so that a filler filters Task by the owner resource id and by a positive business-status list. The previous guidance used a chained owner.partof.identifier= in both Subscription.criteria and the poll search. Criteria are matched in memory against each resource as it is written, and Smile CDR does not support chained parameters there, so the previous criteria never matched. A search does support the chain, but it makes the server resolve an Organization for every candidate Task across the whole result set, and that cost grows with order volume. Negated filters such as business-status:not= are expensive for the same reason. Added a Filler Integration Overview and a Discovering Filler Organizations section: resolve the brand Organization resource ids once at start-up with Organization?partof.identifier= or Organization?identifier=, cache them, then use owner=Organization/<id> in the criteria and the search, comma-separated where a filler fulfils for several brands. The poll search now carries the positive business-status list of directed-request, user-cancelled-request and claimed-cancel, plus _sort=_lastUpdated, _count=500 and Bundle.link next paging. _lastUpdated=gt drops from primary filter to optional narrowing, because each of the three codes has a filler-set successor and a Task therefore leaves the result set as soon as the filler updates it. _tag values are now given as full system|code tokens, since a group Task carries both fulfillment-task-group from the eOrders tag code system and fulfilment-task-group from the AU Base resource-tag code system. Also added the same two rules to the EOrdersTaskFulfillmentGroup introduction. The guidance is provider-neutral and no profile changed.
- Added a warning to the filler discovery guidance about paging while updating
Tasks. The guidance said to follow the next link until the pages are exhausted. But each update changes businessStatus and removes the Task from the filtered result set, and offset-based paging then skips later matches. A filler now either collects all pages before it updates any Task, or processes the first page and searches again until the search is empty.
- Corrected
Task:focus to _include:iterate=Task:focus in the filler retrieval example and in the _include / _revinclude table. The revised search matches group Tasks through the fulfillment-task-group tag, and focus is constrained to 0..0 on EOrdersTaskFulfillmentGroup, so a plain _include — which applies only to the primary matches — returned no ServiceRequests. The ServiceRequests belong to the individual Tasks that _revinclude=Task:part-of brings in, which an iterating include reaches. Also corrected the Task:part-of row description, which stated the relationship backwards.
- Split the claimed-order guidance into two documented options, because fillers differ in how fast they can process a discovered order. A claimed order reaches the filler twice:
$claim returns the new group Task in its groupTask output parameter, and the same group Task is written with a status of requested and a businessStatus of claimed-request, so the ordinary discovery path can return it as well. Option A acts on the $claim response and keeps claimed-request out of both the criteria and the search, with the narrowed criteria shown; a filler that leaves the criteria broad still gets a notification, and the search that follows returns nothing new. Option B ignores groupTask and adds claimed-request to the business-status list so that claimed orders arrive on the same path as directed ones. A comparison table covers both, and a warning covers mixing them — the same order then arrives on both paths, and Task.id or Task.groupIdentifier de-duplicates it.
- Corrected the placer
Subscription criteria on the Add Placer Subscription operation, and added a Placer Subscription Criteria section. The example criteria filtered on status=requested,cancelled with a chained owner.partof.identifier=, which was a copy of the filler pattern and wrong on both counts. A placer tracks the statuses the filler sets, so the criteria now filter on received, accepted, in-progress, completed, failed and rejected; requested and cancelled are set by the placer itself and tell it only what it already did. The organization filter is gone from the criteria altogether: the organization parameters of the operation map to brand partitions and every Task in a partition already belongs to that brand, so one Subscription covers every partition. Those brand ids come pre-discovered from $get_brands, and a chained parameter could not have worked in criteria in any case. The _tag is now a full system|code token and the example reason no longer describes the old statuses.
- Declared the searches that the eOrders and eBookings guidance depends on. The guidance used them, but the CapabilityStatements did not declare them, so a conforming server did not have to support them. eOrders
Task now declares business-status (SHALL), which the filler discovery search uses, and its search-type documentation requires _sort on _lastUpdated, which both filler queries use. eOrders Organization now declares search-type (SHALL), identifier (SHALL) and partof (SHOULD), which fillers use to resolve their brand ids. $get_brands stays SHALL, as the path to use where the partof.identifier= chain is not supported. eBookings AppointmentResponse now declares search-type (SHALL), appointment (SHALL) and _lastUpdated (SHALL), with _sort on _lastUpdated, which the placer uses to detect a booking that has stalled at tentative.
- Declared the includes and revincludes that the eOrders order retrieval uses. The eOrders
Task entry now lists Task:focus, which the retrieval uses as _include:iterate, and ServiceRequest:copiesTo as an include, and the revincludes Task:part-of, CommunicationRequest:about and Consent:data. Corrected ServiceRequest:copiesTo in the retrieval example and the table from _revinclude:iterate to _include:iterate. The search parameter goes from the ServiceRequest to the copy-to recipient, so the reverse include searched in the wrong direction and returned no copy-to PractitionerRoles. The existing searchInclude entries on Task and ServiceRequest used dot form, such as Task.for and HealthcareService.providedBy, which is not the FHIR include syntax. They now use the [Resource]:[search parameter] form, such as Task:patient and HealthcareService:organization.
- Declared the includes and revincludes that the eBookings booking retrieval uses. The eBookings
Appointment entry now lists the includes Appointment:supporting-info, Patient:organization, ServiceRequest:requester, PractitionerRole:practitioner and PractitionerRole:organization, and the revincludes Encounter:based-on, Consent:data, ChargeItem:context, Condition:subject, AllergyIntolerance:patient and RelatedPerson:patient. The retrieval used them, so a conforming server could reject it without these declarations. The subscription notification table in bookings.md now limits the empty-POST and PUT rows to subscriptions without the subscription-payload-search-criteria extension, and says to set payload when the extension is used. The GSPractitionerRole description no longer says that practitioners are referenced as PractitionerRole throughout, because some eBookings profiles reference GSPractitioner directly.
- Corrected the Subscription Notification section of
bookings.md and added the worked notification for the Basic Change Subscription. The page described only two delivery forms — an empty POST with no payload, and a PUT to [endpoint]/[ResourceType]/[id] with one — but the IG's own recommended approach uses the Smile CDR subscription-payload-search-criteria extension, which behaves as neither. Verified against the HAPI source (SubscriptionDeliveringRestHookListener.doDelivery routes a non-blank payload search criteria to createDeliveryRequestTransaction, which calls theClient.transaction().withBundle(...); BaseSubscriptionDeliveryListener.createDeliveryBundleForPayloadSearchCriteria builds it with BundleBuilder.addTransactionUpdateEntry) and against Smile CDR's Delivery Options documentation. The notification is an HTTP POST to channel.endpoint carrying a transaction Bundle, not a searchset: there is no total and no link, each entry carries request.method of PUT and a request.url rather than a search.mode, fullUrl is relative because it defaults to the versionless resource id, and matched and _included resources are flattened into one list with nothing marking which is which. The delivery table now covers all three forms, and a new Notification for a Payload Search Criteria Subscription subsection gives a worked example built from the published EBookingDifferenceExample and Appointment artefacts, warns against executing the Bundle as a transaction against the receiver's own store, and notes that ${matched_resource_id} expands to the versionless qualified id (Basic?_id=Basic/<id>).
- Added invariant
ebookings-appointmentresponse-start-end-01 to EBookingsAppointmentResponse (end.exists() implies start.exists(), severity error). AppointmentResponse.end may now only be sent alongside AppointmentResponse.start, leaving three valid combinations: neither element, start alone, or both. Base FHIR R4 places no start/end constraint on AppointmentResponse — unlike Appointment, which carries app-2 — so nothing previously stopped a response carrying an end time with no start. end also gains a ^short and a ^comment setting out the three combinations and why a response may counter-propose a start without committing to an end, which app-2 would forbid on an Appointment. end is deliberately not marked MS, so the Must Support set is unchanged.
- Removed invariant
ebookings-appointment-start-end-01 from EBookingsAppointmentBase, added in 1.3.0. It was redundant: base FHIR R4 Appointment already carries app-2 (start.exists() = end.exists(), severity error), which is symmetric and strictly stronger — it rejects everything the profile invariant rejected, and additionally rejects end without start, which the profile invariant allowed. Its description ("end SHALL be present when start is populated") also misled by implying the rule is one-directional. Nothing validated before becomes invalid. A ^comment on end now records that the rule comes from base FHIR, and notes app-3: only a cancelled booking may omit start and end, because pending, booked and fulfilled fall outside app-3's exempt set of proposed | cancelled | waitlist.
- Replaced 33 profile and extension descriptions that only restated the title, such as "EBookings Appointment Profile", "Genie Patient core profile" and "Payment Date Extension". Each description now says what the resource represents in this IG and what the profile constrains, and links to related pages. The change covers 9 eBookings profiles, 9
gs-* core profiles, 8 payment and invoice extensions, 4 local-identifier profiles and 3 others. The EBookingsAppointment description now states that fulfilled is in the underlying FHIR value set but is not currently used. This is a description-only change. No constraint changed, so nothing a partner sends is affected.
- Corrected four of the rewritten descriptions.
EBookingsProsthesis said that patient links the device to the booking. It identifies the patient only, and the booking reaches the device through Appointment.supportingInformation or containment. GSPractitionerRole implied that organization is required. It is optional, and its display is required only when it is present. GSPayment and its line-item extension called the invoice line item optional. It is 1..1, so the descriptions now say it is required. EBookingsFastingTimeElement linked to the fasting-time extension page. The publisher rebased that link to the canonical URL, where it did not resolve, and these were the 2 broken links. The link is removed, and the release build has 0 broken links. Description only, with no constraint change.
- Removed a claim from the
GSImagingReportTransaction description that each entry is a conditional update, so the transaction can be replayed without duplicates. The profile does not constrain request.method or request.url, and the worked example uses POST for several entries, so a replay can create duplicates. The description also implied that every transaction carries an imaging study. The imagingstudy entry is 0..1, so the description now says it is optional. Description only, with no constraint change.
- Changed how this release is validated. Both the local build (
_genonce.sh) and the publication step (publication.sh) now validate against HL7 Australia's Ontoserver, https://tx.hl7.org.au/fhir, overridable with TX_SERVER. Previously _genonce.sh defaulted to -tx n/a and publication.sh was hard-coded to it, so neither the build nor the published output was checked against a terminology server at all — and an earlier state of publication.sh left txoption unset, which silently fell back to tx.fhir.org. tx.hl7.org.au is the server AU Base, AU Core and AU eRequesting are published against, so this IG is now validated the same way its dependencies are. It does not carry MIMS or MBS item codes, which surface as "unable to check" warnings rather than failures; CSIRO's https://r4.ontoserver.csiro.au/fhir resolves those but runs a -SNAPSHOT build, and the post-merge terminology check pins it for that reason. Expect QA counts to differ from 1.3.1, which was validated with no terminology server.
- Repaired the terminology suppressions in
input/ignoreWarnings.txt. The patterns matched an old publisher wording and no longer matched anything, so every one of them was silently un-suppressed. Each pattern now names the system and the not-found wording, with one pattern for each of the two current wordings: A definition for CodeSystem 'URL' could not be found, so the code cannot be validated, which also contains the older wording, and Unable to check whether the code is in the value set '' because the code system URL was not found. The systems are urn:oid:1.2.36.1.2001.1005.21 (MBS), http://www.mims.com.au/codes, http://pbs.gov.au/code/item and the per-tenant billing-item system in the example, which is listed by its full URL because the matcher cannot put the wording after the variable tenant id. A pattern on the system URL alone was tried and rejected. It also hid messages that are not about a missing code system: measured at IG Publisher 2.3.4 against tx.hl7.org.au, it hid 20 not-found warnings and also 9 information messages about the recommended additional bindings for MIMS codings. It would also hide an invalid-code message if TX_SERVER pointed at a server that resolves MIMS or MBS. The current patterns hide the 20 not-found warnings only.
- Pinned the CI publisher to
2.3.4 in downloadPublisher.sh, up from 2.2.11. CI validated releases with 2.2.11 while _updatePublisher.sh tracks releases/latest locally, so local and CI had drifted apart. The pin stays explicit rather than tracking latest, so a new publisher release cannot change validation output without a commit. QA at 2.3.4 on this IG: 0 errors, 58 warnings, 0 broken links. An earlier build at this version had 2 broken links, from a link in the EBookingsFastingTimeElement description, which is fixed in this release. downloadPublisher.sh also checks the downloaded jar against a pinned SHA-256 before it replaces the existing jar, because a version pin does not stop a release asset being replaced. The hash was confirmed against the GitHub release digest and a separate download. _updatePublisher.sh does not check the jar, which is acceptable for local builds only. downloadPublisher.sh no longer probes tx.fhir.org before the download. This IG does not use that server, but an outage there blocked CI. A failed download now reports the error.
- Aligned the
version of the eOrders and eBookings CapabilityStatements to the IG version, 1.3.2. Both still said 1.3.0, because 1.3.1 did not update them. The eBookings CapabilityStatement also declares the new Encounter interactions in this release, so a 1.3.0 label was misleading.
- Documented what
AppointmentResponse.participantStatus means and what each value does to the booking. The IG listed accepted | declined | tentative | needs-action in four places but never said what tentative was for, and the prose transition table in bookings.md omitted it entirely while the state diagram showed a tentative response returning a booked Appointment to pending — so the two artefacts disagreed. Hospitals triage a booking in two layers: an automated agent checks it against the hospital's own data requirements, which are local to the hospital and neither mandated by this IG nor enforced by the PMS, and answers needs-action on a shortfall; a booking that clears that check waits for a human booking clerk, and the hospital sends tentative to report that it has progressed without an acceptance decision. A new Response Statuses and Hospital Triage section sets this out with a status-to-Appointment.status table, and the transition table gains two tentative rows (pending to pending, and booked to pending where a modified booking re-entered triage). A tentative response can only leave the booking pending.
- Warned that a booking can stall at
tentative. needs-action prompts the placer, so it surfaces by itself; tentative prompts nobody, because the booking is waiting on a hospital clerk and nothing on the placer side asks for attention. A booking can therefore sit at tentative indefinitely for ordinary human reasons — the clerk is away, the queue is long, the item was missed — with no error raised and neither system at fault. A new When a booking stalls at tentative subsection gives the detection condition (Appointment still pending, latest response tentative, older than tolerance), the search to find the latest response, and the advice to measure tolerance against the operation date rather than the response date. A placer must not resolve a tentative on the hospital's behalf; the remedy is to contact the hospital.
- Defined what
AppointmentResponse.start and end mean for each participantStatus, and documented comment on a tentative response. With needs-action, start is a counter-proposed operation time, which is a request to the placer. With accepted, it may echo the booked time for information only, as base FHIR allows ("Time from appointment, or requested new start time"). It should match Appointment.start. If it does not, Appointment.start stays the source of truth and the placer ignores the difference. With tentative or declined, start is not expected. A placer treats start as a proposal only with needs-action. end goes with start and has the same meaning. The existing accepted example, which echoes the booked time, stays valid and matches the rule. Documented rather than enforced by an invariant, because an invariant on the response cannot see Appointment.start. Separately, a comment is encouraged on a tentative response as the best defence against the stall above — it lets the hospital say where the booking sits and when a decision is likely — but unlike a comment accompanying needs-action it is informational only and implies no work for the placer.
- Added a Current behaviour note to Response Statuses and Hospital Triage in
bookings.md. The IG says that a declined response leaves the Appointment unchanged and that the VMO decides whether to cancel. The platform cancels the booking instead: it sets Appointment.status to cancelled and tells the practice. The note tells a consumer to expect this.
- Declared in the eBookings CapabilityStatement the interactions that the platform uses:
patch on Appointment, update on Consent and delete on ChargeItem. Also declared the identifier search on AppointmentResponse at SHOULD, so that a hospital can recover a response that it created. The delete entry tells a consumer to remove the ChargeItems that a later retrieval no longer returns.
- Corrected the container of
GSCoverage in the contained-profiles table in bookings.md. It said that Coverage is contained in EBookingsChargeItem. The profile puts it in EBookingsServiceRequest.contained[coverage], referenced from insurance.
- Corrected the
EBookingsConsent introduction. It said that the booking Appointment references the Consent. The Consent points to the booking ServiceRequest through provision.data.reference, and a booking retrieval returns it through _revinclude:iterate=Consent:data.
- Renamed the
GSPatient invariants au-core-pat-01 and au-core-pat-02 to gs-pat-01 and gs-pat-02. AU Core 2.0.0 uses those keys for different rules (its au-core-pat-01 is about identifiers), so validation messages were misleading. The rules do not change.
|
| 4 Aug 2026 |
1.3.1 |
- Reverted
hl7.fhir.uv.ips from 2.0.0 back to 1.1.0, and removed the hl7.fhir.au.ereq 1.0.0 dependency that 1.3.0 added. IPS 2.0.0's Patient-uv-ips asks for the individual-genderIdentity and individual-pronouns extensions at version 5.3.0-ballot-tc1, but nothing installs that version — IPS itself only depends on hl7.fhir.uv.extensions.r4 5.2.0, and the AU packages use 5.3.0. A package cache can only mark one version of a package as current, so both cannot be satisfied at once. On Smile CDR the extensions therefore never resolve, Patient.extension slicing cannot be evaluated, no Patient can be matched against Patient-uv-ips, and everything referencing the Patient fails with Reference_REF_CantMatchChoice — including Task.focus, which made Smile CDR reject the whole eOrders order bundle with a 422. Reverting IPS on its own was not enough: au.ereq depends on IPS 2.0.0 and pulled it back in, and with two IPS versions in the build SUSHI wrote |2.0.0 into the previously versionless ObservationPregnancyStatusUvIps references on the eOrders request profiles. au.ereq is not referenced by any profile, example or CapabilityStatement — 1.3.0 declared it only so future reparenting would not need a config change — so removing it has no effect on the published artefacts. IPS 1.1.0 pins no extension versions and still provides ObservationPregnancyStatusUvIps, the only IPS profile this IG uses. Its valueCodeableConcept binding is required rather than preferred, which the pregnancy-status codes in use satisfy (LA15173-0, LA26683-5 and LA4489-6 are all in pregnancy-status-uv-ips). This does re-raise the "IPS package out-of-date" advisory that 1.3.0 cleared; that is intentional until IPS stops pinning a pre-release extension version it does not itself depend on.
- Republished the AU
coverage-selfpay CodeSystem (http://terminology.hl7.org.au/CodeSystem/coverage-selfpay, concept payconc) as AUCoverageSelfPay. AU Base 4.1.2-preview defined this CodeSystem; AU Base 6.0.0 dropped it and now points at the international http://terminology.hl7.org/CodeSystem/coverage-selfpay instead. EOrdersCoverageTypeCodes still sources payconc from the AU system and eOrders sends that URL, so after the AU Base upgrade the code could no longer be validated: the contained Coverage failed eorders-coverage, and ServiceRequest.insurance plus everything referencing the ServiceRequest failed with Reference_REF_CantMatchChoice, so concession orders were rejected with a 422. Only concession billing is affected. Repointing EOrdersCoverageTypeCodes at the international system was tried first and did not work — Smile CDR could not resolve payconc there either, and it would also have required a matching change in eOrders. Republished unchanged so the canonical resolves; remove once eOrders moves to the international system or HL7 AU restores this one.
- Verified on the dev Smile CDR: the full eOrders and eBookings integration suites pass against 1.3.1, having failed on 1.3.0 since 31 July.
|
| 9 Jul 2026 |
1.3.0 |
- Made the primary performer mandatory on
EBookingsAppointment: the participant[provider] slice (v3-ParticipationType PPRF "primary performer", VMO/Specialist) cardinality was raised from 0..1 to 1..1, so every appointment must carry exactly one primary-performer participant. The slice's actor was already 1..1. All existing appointment examples already include the provider participant, so no examples required changes.
- Documented
$submit_order operation exceptions: added HTTP 400 (InvalidRequestException), 403 (ForbiddenOperationException), 422 (UnprocessableEntityException), and 200 (OperationOutcome for profile validation failures) exception tables to the operation notes page.
- Bumped IG Publisher version from 2.2.5 to 2.2.6 in
downloadPublisher.sh.
- Cleared six SUSHI
Sliced element Observation.code.coding is being accessed via numeric index warnings on obstetric inline observation instances: replaced coding[+] = $sct#21840007 / $sct#57036006 patterns with the explicit slice names (coding[snomedLastMenstrualPeriod], coding[snomedGestationalAge]) in GSLastMenstrualPeriod-Inline-4.fsh, GSGestationalAge-Inline-5.fsh, EOrdersPathologyRequest-Rule3ExemptionExample.fsh (LMP & GA inlines), and Bundle-PathologyRequest-Example.fsh (LMP & GA inlines). SUSHI warning count dropped from 21 to 15.
- Significant rewrite of
bookings.md: added a Participants reference table (slice → SNOMED / v3-ParticipationType code → actor target → cardinality) covering all participant slices; added an Appointment data dictionary table covering the must-support fields (status, serviceType.text, reasonCode.text, start/end, patientInstruction, basedOn, comment, participant, supportingInformation, extension[lastModified]); added a Supporting Information table covering the three supportingInformation slices (anaesthetic, prosthesis, pdf) with target profiles and contained-vs-referenced semantics; restructured the resource profile tables into three groups (referenced from the booking graph, supportingInformation reference targets including the previously missing EBookingsPDF, and contained resources); promoted the prior prose list of "change of significance" triggers into a normative table on lastModified; added an Appointment:supporting-info row to the _include table and a corresponding example query update; added an If-Match header note and example to the AppointmentResponse PUT guidance; added new sections on Patient Identity Matching (covering the identifier slices on EBookingsPatient and a recommended matching order), Authorization (typical SMART-on-FHIR backend-services / bearer-token patterns; this IG is silent on the specific scheme), and Validation and Error Handling (HTTP status code table separating conformance failures from business-status outcomes carried on Appointment.status / AppointmentResponse.participantStatus); fixed the misleading "Booking Response" alt text on the Information Model diagram; fixed the long-standing HeathcareService typo in the eBookingsTransaction-simple-colour drawio source.
- Expanded the
eBookingsTransaction-simple-colour diagram to cover the full set of EBookingsAppointment linkages. Added: supportingInformation[pdf] as 0..* stacked DocumentReference (EBookingsPDF); supportingInformation[anaesthetic] as a ServiceRequest (EBookingsAnaestheticRequest); supportingInformation[prosthesis] as a Device (EBookingsProsthesis); the assistant / anaesthetist / paediatrician participant slices as stacked PractitionerRole entries. Layout of the surrounding entities was adjusted for readability.
- Added
hl7.fhir.au.ereq 1.0.0 (AU eRequesting) as a dependency. No profiles, examples, or CapabilityStatements reference AU eRequesting yet — the dependency is declared so that future reparenting / cross-profile references are possible without a separate config change. Build totals unchanged after declaring the dependency (0 errors, 50 warnings, 599 info under the HL7 AU dev tx server).
- Bumped
hl7.fhir.uv.ips from 1.1.0 to 2.0.0. Only one IPS profile is referenced from the IG (ObservationPregnancyStatusUvIps); the 2.0.0 differential is looser than 1.1.0 (binding strength on valueCodeableConcept relaxed from required to preferred, effective[x].extension:data-absent-reason slice removed) and existing pregnancy-status example instances validate cleanly. Cleared the prior "IPS package out-of-date" advisory.
- Bumped
hl7.fhir.au.base from 4.1.2-preview to 6.0.0 and hl7.fhir.au.core from 0.2.2-preview to 2.0.0. Fixed five breakages caused by AU Core 2.0.0 / AU Base 6.0.0 profile removals and slicing changes: supportingInfo[observation] on GSReferralRequest now targets base Observation (was AUCoreObservation, removed in AU Core 2.0.0); supportingInfo[procedure] on GSReferralRequest and the ReferralProcedure example now reference AUCoreProcedure (was AUCoreProcedureCore, renamed in AU Core 2.0.0); the pregnantInline inline observation in EOrdersPathologyRequest-Rule3ExemptionExample now uses ObservationPregnancyStatusUvIps (was AUCorePregnancyStatus, removed in AU Core 2.0.0) matching the profile already used for the pregnancystatus slice elsewhere in the IG; the inline's category[socialHistory] slice was changed to an unsliced category assignment because the IPS pregnancy-status profile does not slice category; the four medicationCodeableConcept.coding[pbs/gtin/mimsPackage/amt] Must Support flags on EOrdersMedicationStatement were removed because AU Base 6.0.0 removed those slices from its MedicationStatement.medication[x] structure (AU Core 2.0.0 retains pbs and amt only). Build remains 0-error; new validator warnings under -tx n/a are terminology-resolution noise that resolves under a tx-enabled CI build.
- Switched obstetric observation references on
EOrdersDiagnosticRequestBase and EOrdersDiagnosticRequest from AU Core 0.2.2-preview profiles to the local GS profiles. The supportingInfo and contained slices for gestational age, estimated date of delivery, and last menstrual period now accept only GSGestationalAge / GSEstimatedDateOfDelivery / GSLastMenstrualPeriod; AUCoreGestationalAge / AUCoreEstimatedDateOfDelivery / AUCoreLastMenstrualPeriod are no longer accepted. The GS profiles add a mandatory SNOMED coding slice (LMP 21840007, gestational age 57036006, EDD 161714006) and narrow reference targets to project profiles (GSPatient, EOrdersEncounter, GS practitioner/practitioner-role/organization/patient performers). Existing request, bundle, and Rule 3 exemption examples were repointed to the GS profiles; the three inline observation files were renamed from AUCore*-Inline-*.fsh to GS*-Inline-*.fsh (Instance IDs unchanged). The base profile intro page now lists the GS profiles in its contained / supporting-info tables.
- Restructured Theatre List as a FHIR document. Added two new profiles:
EBookingsTheatreListBundle (Bundle, type = #document) and EBookingsTheatreListComposition (Composition, sectioned per booking). Native Composition fields (status, author, attester, event.period, custodian) replace the four legacy custom extensions on the old List profile. Each Consent is now referenced explicitly from its booking's section.entry, fixing the floating-consent issue and lifting the prior 0..1 consent cardinality. The previous dom-3 orphan-contained suppression for Consent-for-AppointmentEntryExample in ignoreWarnings.txt was retired — the warning the suppression silenced no longer applies under the document model. Added EBookingsCompositionCategoryCodeSys/ValSet (single code theatre-list) and EBookingsTheatreListCompositionStatusValSet (subset of FHIR core composition-status: preliminary | final | amended). Added theatre-list.md pagecontent describing the document shape and per-booking section structure, plus a Theatre Lists cross-reference section in bookings.md. The worked example (TheatreListBundleExample) covers two bookings on the same list with mixed consent states — one #proposed consent (to be obtained on the day) and one #active consent with an attached PDF via sourceAttachment.url (provided prior) — and demonstrates both consent-attachment paths plus an EBookingsPDF admission form via the pdf Bundle slice. Updated ebookings-capability CapabilityStatement: replaced List/EBookingsTheatreList entry with Bundle/EBookingsTheatreListBundle and Composition/EBookingsTheatreListComposition entries.
- Removed the legacy
EBookingsTheatreList List profile and its supporting artefacts: extensions ebookings-theatre-list-hospital-ext, ebookings-theatre-list-vmo-ext, ebookings-theatre-list-period-ext, ebookings-theatre-list-status-ext, and the custom code system / value set ebookings-theatre-list-status-codesys / ebookings-theatre-list-status-valueset. Theatre lists were not yet in production use, so this is a clean replacement (no migration). The legacy draft code maps to preliminary; final maps to final.
- Build hygiene — cleared seven actionable validation warnings: added
^experimental = false to ada-dental-terms-valueset (ShareableValueSet conformance); marked the four inherited MedicationStatement.medication[x].coding slices (pbs, gtin, mimsPackage, amt) as Must Support on EOrdersMedicationStatement to match the parent slicing; added a testList extension to EOrdersOrganizationExamplePathologyLaboratory so the EOrdersOrganizationTestListExt extension has at least one example; suppressed the harmless template-generated expansion-params.xhtml not-included warning in ignoreWarnings.txt.
- Cleared 33
Unknown code 'PGN' validation errors on EOrdersPlacerGroupNumber and every diagnostic request, task, and bundle that carries a placer group number. FHIR R4 core bundles http://terminology.hl7.org/CodeSystem/v2-0203 at version 2.9, which predates the PGN (Placer Group Number) code added in later HL7 Terminology editions, so the validator was rejecting a valid code. Added a system-version parameter (http://terminology.hl7.org/CodeSystem/v2-0203|5.0.0) to input/_resources/exp-params.json to direct the validator to the current edition where the code exists.
- Cleared 2
Unknown code '4.0' validation errors on the EBookingsFastingTime extension. Re-parented it from the UV servicerequest-precondition extension to base Extension (re-adding value[x] only CodeableConcept to preserve the precondition shape) so it no longer inherits that extension's startFhirVersion = "4.0" context metadata. The IG Publisher locks the http://hl7.org/fhir/FHIR-version code system to the IG's FHIR version (4.0.1), so the major-version code 4.0 required by the major-fhir-version value set can never validate and a system-version pin is ignored for that system — removing the inherited metadata was the only fix. Updated EBookingsServiceRequestExample to drop the hardcoded servicerequest-precondition url so the request-fasting-time slice supplies the ebookings-fasting-time url; the extension wire format is unchanged (value remains a CodeableConcept carrying the nested request-fasting-time-element dateTime). The parallel EOrders fasting usage, which references servicerequest-precondition directly, is unaffected.
- Fixed an incorrect constraint on
GSPayment: the payment-id identifier slice constrained Identifier.id (the element id) to 1..1 instead of Identifier.value. Changed to identifier[payment-id].value 1..1 so the mandatory cardinality applies to the payment identifier value as intended.
- Replaced placeholder
note.text = "a clinical note" text in three diagnostic request examples (EOrdersPathologyRequest-Example, EOrdersRadiologyRequest-Example, EOrdersDiagnosticRequest-Example) and the placeholder reasonCode.text = "A clinical note" in EOrdersPathologyRequest-Rule3ExemptionExample with realistic clinical text.
- Suppressed expected external-terminology validation warnings in
ignoreWarnings.txt for code systems the IG deliberately references but cannot resolve against a terminology server: MBS item numbers (urn:oid:1.2.36.1.2001.1005.21), MIMS (http://www.mims.com.au/codes), PBS item codes (http://pbs.gov.au/code/item), per-tenant billing-item systems, and the RadLex Playbook / DICOM SOP-class HTML value-set references on gs-imaging-study. Patterns bind to verbatim message substrings — the matcher compares the text between the % markers literally, including spaces, so a trailing space fails to match messages that continue with punctuation. Online (tx-enabled) build warning count dropped from 19 to 3; the remaining three are a dom-6 best-practice narrative hint on a contained Task and two AU medication value-set (pbs-item / mims) expansion limits.
- Added the
directed-request code to the eOrders Task business-status CodeSystem (eorders-task-business-status-codesystem). It marks a requested Task that has been directed to the filler and is awaiting pickup, distinct from claimed-request (already picked up). The code flows into the eorders-task-business-status ValueSet automatically. This enables the claim-discovery query to use a positive, sargable business-status IN-list in place of the non-sargable business-status:not= negation filters. Documented the code as a requested / directed-request row in the Status and businessStatus Combinations table in requesting.md. (Originally released as 1.2.63.)
- Build/CI: made terminology-server use deterministic.
_genonce.sh now defaults to -tx n/a (overridable via the TX_SERVER environment variable) instead of auto-detecting tx.fhir.org, so blocking PR-validation and release builds no longer hang or vary on external tx availability; publication.sh likewise disables the external tx server for the publish pass. Added a non-blocking terminology_check.yml GitHub Actions workflow that re-validates against Ontoserver post-merge to catch retired or invalid SNOMED/LOINC codes.
- Removed the reference-target constraint on
supportingInfo in EOrdersDiagnosticRequestBase and EOrdersDiagnosticRequest (previously only Reference(Observation | Condition | MedicationStatement | AllergyIntolerance)). The base element now permits any resource type (Reference(Any), the R4 / AU Base default), consistent with its #open slicing — the blanket target restriction had effectively defeated the open slicing by rejecting any extra entry that wasn't one of those four types (e.g. a DocumentReference). The named slices (pregnancystatus, gestationalage, estimateddateofdelivery, lastmenstrualperiod, hrt, med, allergy) still constrain their own targets to specific profiles.
- Broadened
EOrdersCommunicationRequestPatient toward HL7 AU eRequesting 1.0.0 using a broaden-then-narrow migration that keeps existing production data valid: about now accepts the diagnostic-request ServiceRequests (EOrdersDiagnosticRequest / EOrdersPathologyRequest / EOrdersRadiologyRequest — the eReq-aligned form, matching the -provider and -copyto profiles and AUeRequestingCommunicationRequest.about) in addition to the legacy fulfillment Task references (EOrdersTaskFulfillmentGroup / EOrdersTaskFulfillmentRequest) that production systems currently send. Correspondingly, the eorders-communication-medium value set now includes SMSWRIT and EMAILWRIT (the eReq patient-medium codes from au-erequesting-communicationrequest-patientmedium) alongside the retained WRITTEN, and the hardcoded medium.text = "SMS" fixed value was relaxed so email / written media are representable. Both bindings will be narrowed to the eReq-exact forms (ServiceRequest-only about; SMSWRIT | EMAILWRIT medium) once all existing users have transitioned.
- Bumped the IG Publisher pin from 2.2.6 to 2.2.11 in
downloadPublisher.sh. Build re-verified at 0 errors under 2.2.11.
- Removed the
icu and hdu participant slices from EBookingsAppointment.participant (both Location references flagging an ICU / HDU bed requirement, SNOMED 309904001 / 397771005). Neither slice is in production use — no consumer yet sends or reads an ICU/HDU participant — so the removal has no impact on existing integrations. Removed the corresponding participant[icu] / participant[hdu] entries from EBookingsAppointment-Example, the ICU/HDU rows from the participant tables in bookings.md and the appointment profile intro, the "required" prose references, and the ICU Location node from the eBookingsTransaction-simple-colour diagram (source and regenerated PNG).
- Added invariant
ebookings-theatre-list-bundle-01 to EBookingsTheatreListBundle, enforcing that the Bundle contains exactly one Composition and that it is the first entry (entry.first().resource is Composition and entry.resource.where($this is Composition).count() = 1), as required by the FHIR document Bundle structure. Because entry slicing is #open, the entry[composition] slice alone (1..1 EBookingsTheatreListComposition) would not prevent a stray second Composition being placed first; the exactly-one check closes that gap so the first entry is guaranteed to be the theatre-list Composition.
- Added invariant
ebookings-appointment-start-end-01 to EBookingsAppointmentBase (start.exists() implies end.exists(), severity error), enforcing the previously documentation-only rule that Appointment.end is required when Appointment.start is populated. Also corrected the TheatreListBundleExample description (it described "one theatre booking" but the example carries two bookings), aligned three participant actor type values in that example to PractitionerRole (matching the profile's Reference(PractitionerRole) constraint), removed a stray label on the PDF-stack shape in the eBookingsTransaction-simple-colour diagram source, and dropped the hard-coded stale version from the history page title template.
- Added
GSPractitioner to the allowed reference targets of EBookingsTheatreListComposition section[booking].entry (previously GSPractitionerRole only), so a booking section can reference practitioners directly for explicit self-containment. Also fixed a "pregnacy" → "pregnancy" typo in the supportingInfo short on EOrdersDiagnosticRequestBase and EOrdersDiagnosticRequest.
- Clarified the Subscription Notification section of
bookings.md: the rest-hook notification HTTP method (empty POST when no payload; PUT to [endpoint]/[ResourceType]/[id] when a payload is specified, for created/updated resources; DELETE for deletions) is Smile CDR / HAPI rest-hook delivery behaviour rather than a base FHIR R4 requirement. Noted that receivers must accept both POST and PUT on the endpoint. (Confirmed against HAPI SubscriptionDeliveringRestHookListener, which delivers payloads via client.update().)
- Added support for an unknown slot end time on
EOrdersBookingSlot. Slot.end is 1..1 in base FHIR R4 and cannot be made optional in a profile, so a data-absent-reason extension slice (end.extension[dataAbsentReason], 0..1 MS) was added: when the end time is not known at booking time, omit the end value and set end.extension[dataAbsentReason].valueCode = #unknown, keeping end present (required cardinality satisfied) while signalling no end time is available. Added an ^comment on end documenting the approach, re-added the $data-absent-reason alias, and added the EOrdersBookingSlotUnknownEndExample worked example.
- Repo/quality-review cleanups: added explicit
Usage: #example to EBookingsPDFExample and GSImagingStudyExample; removed seven unused aliases from aliases.fsh ($dva-types, $gs-anaesthetictype, $gs-listtype, $m49.htm, $procedureType, $v2-0074, $v2-0136); repointed the orphaned StructureDefinition-gs-imagingreport-entry-task-intro.md narrative to its successor profile gs-imaging-task-report-request (renamed the file so it is no longer silently dropped); and removed the unused, always-empty Impact column from this changelog table.
- Removed the stray
Requirements-fromNarrative.json file from the repository root. It was an incidental, unreferenced, empty shell (no statement entries), sat outside the IG Publisher's scan paths so was never loaded or published, and declared resourceType: Requirements — a resource type that does not exist in FHIR R4 (introduced in R5). No IG content referenced it.
- Added a "Basic Change Subscription" worked example to
bookings.md, demonstrating the recommended theatre-booking change-notification approach: a rest-hook Subscription on the Basic change-tracking resource that carries the Smile CDR subscription-payload-search-criteria extension to _include the related Appointment in the notification payload. Presented as an inline JSON code block under "Registering Subscriptions" (matching the existing Appointment subscription example), with a cross-reference from the option-3 change-notification bullet. Not registered as a validated artifact: the HAPI/Smile CDR payload extension is a runtime extension with no loaded StructureDefinition, so a validated instance would require disabling unknown-extension validation IG-wide. Example channel.header credentials were replaced with obvious placeholders.
|
| 10 Apr 2026 |
1.2.61 |
- Added eBookings CapabilityStatement (
ebookings-capability) declaring all eBookings resource types with SHALL/SHOULD interaction expectations and search parameters.
- Expanded
referrals.md from a stub to a full workflow page: added draft notice, profiles table, workflow description, Task status lifecycle table, supporting clinical information table, and examples table.
- Added profile intro pages for seven high-value profiles:
EOrdersDiagnosticRequestBase (contained resource pattern, extensions, supporting info slices), EOrdersPathologyRequest (RCPA SPIA codes, category, Rule 3 Exemption), EOrdersRadiologyRequest (category, occurrence), EOrdersTaskFulfillmentBase (status lifecycle, output slices, meta tags, active vs disabled invariants), EOrdersTaskFulfillmentGroup (role, directed vs undirected order discovery, sub-task count), EOrdersTaskFulfillmentRequest (relationship to group task, focus, owner), and EBookingsAppointment (status, closed contained slice, all participant slices, lastModified change detection).
- Moved legacy
EOrdersDiagnosticRequest to the bottom of the profiles table in requesting.md with a deprecation notice; added a "new integrations should use Pathology Request or Radiology Request" sentence above the table.
- Restructured the Getting Started section on the index page: primary navigation is now by solution (eRequesting, eBookings, Diagnostic Reporting, eReferrals) with role selection within each solution, replacing a flat role-first table that mixed solutions together.
- Fixed six broken links: four incorrect profile page IDs in new intro files (
copyto-practitionerrole, placergroupnumber, gs-imaging-task-report-request), a broken internal anchor in requesting.md (#task-status-and-business-status), and an incorrect AppointmentResponse example page URL in bookings.md.
- Bumped IG Publisher version to 2.2.5 in
downloadPublisher.sh.
- Fixed spelling and grammar errors in
README.md.
- Fixed apostrophe errors in plural resource names across
bookings.md, requesting.md, and StructureDefinition-ebookings-difference-intro.md (Resource`'s → Resource`s). Fixed subject-verb agreement in reports.md (Below are a list → Below is a list).
- Migrated
magentus-template base dependency from fhir.base.template to fhir2.base.template to address NPM dependency confusion security vulnerability (see HL7 security notice).
- Fixed duplicate instance titles introduced by stricter
fhir2.base.template table-of-contents uniqueness check: appended "Example" to six instance titles that clashed with their parent profile titles, and disambiguated two EOrdersStatusPatch bundle titles to "Set Received" and "Set Accepted".
- Fixed actionable build warnings: added
^experimental = false to PreferredContactMethodVS, PreferredContactMethodCS, CopyToIdentifierCS, and the ADA Dental Terms code system; corrected consent-state-codes#draft display from "Draft" to "Pending"; widened PractitionerRole.telecom to 0..*, EBookingsInfectionRisk Condition.code.coding to 1..*, and EBookingsChargeItem ChargeItem.code.coding to 0..* to match open slicing intent.
- Suppressed template-generated broken links in
ignoreWarnings.txt: fhir2.base.template references definitions.xml.zip, examples.xml.zip (not generated; this IG is JSON-only), and package.tgz (generated as package.r4.tgz).
- Added
identifier[placer] and identifier[filler] slices (AULocalOrderIdentifier) to the legacy EOrdersDiagnosticRequest profile, matching the pattern already defined on EOrdersDiagnosticRequestBase. Updated all legacy ServiceRequest examples (four standalone instances and two bundle inline instances) to use identifier[placer] with a unique GUID and required assigner field.
- Added optional secondary AU eRequesting interoperability tag (
ereq-task) to EOrdersTaskFulfillmentBase, EOrdersTaskFulfillmentRequest, and EOrdersTaskFulfillmentGroup profiles. The new slice uses codes from http://terminology.hl7.org.au/CodeSystem/resource-tag (AU Base), specifically fulfilment-task and fulfilment-task-group, aligning with the AU eRequesting v1.0.0 standard without introducing a dependency on the AU eRequesting IG package. All Task examples updated to show both the eOrders tag and the AU eRequesting tag in parallel.
- Relaxed
owner from 1..1 to 0..1 on EOrdersTaskFulfillmentGroup and EOrdersTaskFulfillmentRequest. The 1..1 constraint incorrectly blocked undirected orders, which are created without an owner and only have owner assigned when a filler calls $claim. The base profile already declared 0..1; the child profiles were over-constraining it. Backwards compatible.
- Fixed three narrative errors in fulfillment task intro pages: corrected FHIR search parameter from
Task?partOf= to Task?part-of=Task/[id]; corrected owner cardinality from 1..1 to 0..1 in eorders-diagnosticrequesttask-intro.md; added ereq-task row to the Meta Tags table in eorders-task-fulfillment-base-intro.md.
- Fixed blank table rows in
requesting.md profiles table: replaced empty spacer rows with a separate Legacy profile sub-heading and table.
|
| 3 Apr 2026 |
1.2.60 |
- Updated
$submit_order operation response model: the single return output parameter type changed from Bundle to Resource so the operation can return either a transaction-response Bundle (directed order success) or an OperationOutcome (error or undirected order). The caller distinguishes between cases by inspecting resourceType.
- Added three
$submit_order response examples: directed order success (transaction-response Bundle), error (OperationOutcome severity error), and undirected order (OperationOutcome severity information). OperationOutcome examples use issue.details (CodeableConcept) rather than issue.diagnostics to support future coded error catalogue.
- Added notes pages for
$submit_order, $claim, $view_request, and $add_placer_subscription operations, surfacing response behaviour, parameters tables, result codes, and examples directly on each operation definition page.
- Updated
requesting.md Submit Order section to document the new response model with a condition/response table and added response examples table.
- Added parameters tables and result codes table to
requesting.md Claim Order section.
- Added parameters table to
requesting.md View Order section and corrected endpoint from POST [base]/$view to POST [base]/Task/$view_request.
- Updated CapabilityStatement: version aligned to IG, date updated, status promoted to
#active. Added all five custom operations: $claim (SHALL) and $view_request (SHOULD) under Task, $get_brands (SHALL) under Organization, $add_placer_subscription (SHALL) under new Subscription resource entry (read + search-type supported), and $submit_order (SHALL) at server level.
- Fixed malformed URL in
request-register.md (http://https:// → https://).
- Fixed grammar in Claim operation description (used create → used to create) and typo in View operation FSH (ciuld → could).
- Fixed four typos in changelog entry for v1.2.33 (seqnecing, teh, numberts, contigious).
- Fixed typos in eOrders profile metadata: disagnostic → diagnostic (
EOrdersCommunicationRequestPatient), Fulillment → Fulfillment (EOrdersCommunicationRequestPatient), Planer → Placer (EOrdersPlacerGroupNumber).
- Standardised eOrders tag code system references: replaced direct
EOrdersTagCodeSystem# references with $eorders-tag# alias throughout all Task instances and profile definitions, consistent with FSH alias conventions.
- Added
owner and _tag search parameter declarations to the Task resource entry in the CapabilityStatement (both SHALL) — these standard FHIR parameters are used in all documented subscription search patterns.
- Declared three custom SearchParameters in the CapabilityStatement:
copiesTo (SHALL) under ServiceRequest, about (SHALL) under CommunicationRequest, and study (SHALL) under a new DiagnosticReport resource entry.
- Populated
patientInstruction in the Pathology, Diagnostic, and Radiology request examples — this element is marked Must Support on the profile but was previously commented out.
- Removed
Bundle-EOrdersPathologyRequestTransaction.fsh — file contained only commented-out code with no explanation and produced no compiled output.
- Resolved consent data meaning uncertainty in both
EOrdersConsentWithdrawl examples: settled on #dependents and removed ambiguity comment referencing the Canadian example.
- Added explanatory NOTE comments to the two disabled task invariants (
task-cancel-detail-1, task-cancel-detail-2) in EOrdersTaskFulfillmentBase explaining why they are disabled and what they are intended to enforce.
- Replaced stale not available in Gentu/Genie comments in
EOrdersDiagnosticRequest with accurate descriptions of why performerType, performer, and reasonCode binding are not constrained.
- Expanded
request-register.md: added Transfer vs Claim Provenance profile table, workflow guidance on when to use each type, and explanation of filler privacy model.
- Corrected clinical error in
EBookingsInfectionRisk: MRSA slice short description incorrectly named Escherichia coli — corrected to Staphylococcus aureus to match SNOMED code 432415000.
- Fixed
ChargeItemDiffExample instance to use EBookingsChargeItem profile instead of the parent GSChargeItem; corrected status from #billed to #planned to conform to the profile's fixed value.
- Fixed typos in eBookings FSH and pagecontent: appintment → appointment (
EBookingsTheatreList), atatchment → attachment (EBookingsAppointment), sould → should (ebookings-difference-intro.md), precedure → procedure (EBookingsConsent).
- Replaced inline URIs with FSH aliases in
EBookingsConsent: $consentscope#treatment and $loinc#59284-0, consistent with FSH alias conventions in aliases.fsh.
- Fixed typos in eBookings narrative: HealthcareServive → HealthcareService and missing backtick around
Organization in bookings.md; mosified → modified and duplicate phrase removed in ebookings-difference-intro.md; invoced → invoiced in ebookings-difference-intro.md.
- Added AppointmentResponse creation workflow to
bookings.md: field reference table, POST and PUT examples, link to example instance.
- Added
Appointment.status transition table to bookings.md (pending → booked → cancelled) and defined what constitutes a 'change of significance' for the lastModified extension.
- Added undirected order lifecycle section to
requesting.md: explains lodging, discovery, claim, and how the placer detects when an undirected order has been claimed.
- Expanded PATCH section in
requesting.md with FHIR Patch (FHIRPath-based) format explanation, field reference table, and two inline examples.
- Added claim error recovery table to
requesting.md with recommended action for each $claim result code.
- Added Getting Started guide and Glossary to
index.md: role-based entry points (placer, filler, hospital, patient portal) and definitions for key terms (placer, filler, brand, directed/undirected order, requisition, group task, VMO).
- Fixed typo in
CapabilityStatement-eorders-capability-intro.md (statatement → statement) and expanded the intro to describe the statement's purpose.
- Fixed typos in
index.md: Interopability → Interoperability, Administative → Administrative.
|
| 1 Apr 2026 |
1.2.59 |
- Allow multiple
reasonCode values (0..*) on EOrdersDiagnosticRequestBase and legacy EOrdersDiagnosticRequest ServiceRequest profiles — aligns with base FHIR R4 and AU Base cardinality; child profiles EOrdersPathologyRequest and EOrdersRadiologyRequest inherit the change
- Update
EOrdersPathologyRequest Rule 3 Exemption example to demonstrate multiple reasonCode entries
|
| 27 Mar 2026 |
1.2.58 |
- Generalise
EBookingsConsent profile: remove fixed Healthscope-specific policy.authority and policy.uri values so any hospital can supply their own consent policy (backwards compatible relaxation)
- Delete Healthscope NamingSystem — hospital-specific NamingSystems should be managed outside the IG
- Update eBookings Consent examples to use RFC-reserved
example.com authority and policy URI
- Update eBookingsTransaction diagram to use generic consent policy label
|
| 18 Mar 2026 |
|
- Removed incorrect
text 1..1 constraint from EOrdersDiagnosticRequestBase and legacy EOrdersDiagnosticRequest ServiceRequest profiles — narrative text requirement applies to supportingInfo resources (EOrdersMedicationStatement, EOrdersAllergyIntolerance), not to ServiceRequest.text
|
| 6 Mar 2026 |
1.2.57 |
- Add
placer-family meta tag to EOrdersDiagnosticRequestBase and legacy EOrdersDiagnosticRequest ServiceRequest profiles
- Add
placer-family meta tag to all ServiceRequest examples (standalone and inline bundle instances)
- Define
consistent-placer-tag invariant on EOrdersSubmitOrderBundle ensuring Task and ServiceRequest placer-family tags match within a transaction bundle
- Update requesting page documentation with Placer Family Tag section and bundle profile notes
|
| 5 Mar 2026 |
1.2.56 |
- Add placer family tag to all Task examples in SubmitOrder bundles
- Add
$get_brands operation definition for Organization
- Add
$submit_order operation definition and EOrdersSubmitOrderBundle transaction bundle profile
- Add
$add_placer_subscription operation definition for Subscription
- Convert existing bundle examples to conform to
EOrdersSubmitOrderBundle profile
- Add Requesting page documentation with Requesting Service, Placer, Filler, and Patient integration sections
|
| 18 Feb 2026 |
1.2.55 |
- Update documentation across various profiles
- Update PATCH examples
- Add digitalonly extension to ServiceRequest for PathologyRequest and RadiologyRequest
- Add filler order to Task output
- Add occurrenceperiod to Task to set fulfilment date
- Make Practitioner optional in PractitionerRole for copyto
|
| 13 Feb 2026 |
1.2.54 |
- Update diagnostic request examples to use practitionerrole details
- Better support for contained practitionerrole details in service requests
- Optional report as Task output should actually reference a Task linked to the report as we need to track receipt
- Loosen organization requirement on practitionerrole to allow for copiesto
|
| 11 Feb 2026 |
1.2.53 |
- Make copy-to PractitionerRole.organization optional
|
| 11 Feb 2026 |
1.2.52 |
- Add details for copies-to PractitionerRole rather than just a name and identifier
- Allow for no selection on eBookings Consent
- Add example of slot/booking for Task.output
|
| 30 Jan 2026 |
1.2.51 |
- Add a slot/booking definition and example for use with eRequest Task.out
- Add medication and allergy ServiceRequest.supportingInfo
|
| 16 Jan 2026 |
1.2.50 |
- Add support for ADA chargeitem coding in ebooking
- Use correct speciality coding for healthcareservice in vmo org
- Add speciality ValueSet
|
| 07 Nov 2025 |
1.2.49 |
- Add contained HealthcareService into VMO practice Organization to carry speciality
- Create new Path and Imaging Organization profiles for eRequesting to support parent brands
- New VMO PractitionerRole and Organization profiles for eBooking to support contained HealthcareService speciality
- Separate tasks in report for receipt and copyto
- Update eBooking documentation with new diagram and search guidance
- Diagnostic reports now expect a separate practice organization resource
|
| 16 Oct 2025 |
1.2.48 |
- Fix to ebookings supportingInformation slicing to be by profile not type
|
| 08 Oct 2025 |
1.2.47 |
- Add an mbscodes alias to IG build
- Include dicom as dependency in sushi to fix publisher errors
- Remove a couple of invalid markdown references in documentation
- move to 2.0.20 version of publisher
- lock down task fulfilment base to get past publisher bug?
|
| 07 Oct 2025 |
1.2.46 |
- Add narrative to supportingInfo examples
- Make HRT have mandatory narrative
- Fix copyto reference to ValueSet
- Fix FAXWRITE code
|
| 01 Oct 2025 |
1.2.45 |
- add fax as an urgent results contact option
- Make note on ServiceRequest Must Support
- Add an HRT Observation to support HRT flag in Genie
- Remove old diagrams not used in IG anymore
- Add an option on an urgent results communication request to have a date by which it is needed
|
| 24 Jul 2025 |
1.2.44 |
- Fix Imaging Report transaction bundle example.
- Make requester and recipient of a CopyTo a PractitionerRole for Imaging Reports.
|
| 23 Jul 2025 |
1.2.43 |
- Make consistent references to ebookings-patient rather than gs-patient in EBookings.
|
| 16 Jul 2025 |
1.2.42 |
- Add $view_request operation to support patient portal access to requests and their fulfilment.
- Add copyto as new eorders task tag for processing reciept of report copies.
- Add employee number as an identifier for eorders PractitionerRole.
- Allow organization to be contained in a radiology request.
- Add CommunicationRequest and a tracking Task to be added into a report transaction to support CopyTo.
- Remove invariants from GSCoverage as erroring when Patient resource not in bundle.
|
| 25 May 2025 |
1.2.41 |
- Add naming system for practice identifiers like GEN/GTU.
- Add infection risk profile to cover HIV, Hep B, Hep C, and MRSA.
- Add adverse reaction profile.
- Add related person to cover next of kin and emergency contact.
- Add paediatrician and ICU as Appointment participants.
- Add extension for fasting time to booking ServiceRequest.
|
| 23 May 2025 |
1.2.40 |
- New diagram to better describe status changes between Appointment and AppointmentResponse for theatre bookings.
- New HealthcareService profile for organisation specialties.
- Updated requesting and booking documentation.
|
| 2 May 2025 |
1.2.39 |
- Modify booking diff to use a separate list for attributes.
- New search parameter for imaging study in DiagnosticReport. It is there in R5.
- Add NamingSystems to define URIs in use in IG.
- Create new businessStatus for claimed-cancel and remove invariants for now that restrict businessStatus claimed use while we transition.
|
| 27 Apr 2025 |
1.2.38 |
- Add new basic resource profile to store theatre booking diff. Note this is likely to fail if strict checking of valid references as a deleted resource, i.e. MBS code/ChargeItem, will be referenced but won't exist.
- Get sushi to structure artefact page rather than use defined groups.
- Add ImagingStudy to DiagnosticReport for imaging to so can store when images were collected. Create example.
- Remove slice on Patient address as fails on non AU address. Replace with Invariant checking for a residential address to be provided. Fix examples.
- Minor updates to fix descriptions and titles on some profiles.
|
| 1 Apr 2025 |
1.2.37 |
- Rename instances within RequestProvenance as had a repeat of names previously.
- Fix claim operation so based on Task not ServiceRequest
- Add cancel-handled in as businessStatus for Task so filler can use to differentiate processed cancelled Status's
- Fix claim example using GET rather than POST
|
| 3 Mar 2025 |
1.2.36 |
- Move to 1.2.36 to match jiang update to main branch structure. Pulls in 1.2.35 changes.
|
| 26 Feb 2025 |
1.2.35 |
- Fix spelling of claim error code of already-fulfiller
- Add more detail in documentation for various things
- Support initial claimed order status of requested rather than accepted
- Add displaySequence example for diagnostic requests
|
| 11 Feb 2025 |
1.2.34 |
- Make background ribbons the Magentus purple
- Some renaming to remove duplicate FHIR artefact names
- Add profile for request provenance which links to the stored request bundles
- Restructure artifacts page so it is grouped by artifact use
|
| 21 Jan 2025 |
1.2.33 |
- Add a sequenceNumber to ServiceRequests to provide sequencing information for tests. These are inherent on the paper form but natively, FHIR ServiceRequests have no explicit or implicit order. This extension adds this sequence information. The relative order of each ServiceRequest sequence number determines the order, from lowest to highest number. The numbers do not need to be contiguous.
|
| 19 Dec 2024 |
1.2.32 |
- Minor changes to titles and comments as they appear in the rendered IG.
- Align the PractitionerRole profile used in Reports with that used in Requests.
|
| 19 Nov 2024 |
1.2.31 |
- Make insurance optional in Diag Req as it is in Path and Rad Request.
- Make rcpa codes preferred rather than extensible in binding strength.
|
| 18 Nov 2024 |
1.2.30 |
- Add Radiology and Pathology Request profiles to work alongside the generic Diagnostic Request. This modifies Task, Consent, and CommunicationRequest profiles.
|
| 13 Nov 2024 |
1.2.29 |
- Fix search documentation for eRequest to include copiesto data.
- Fix display values in instances for various codes.
- Change to use value instead of pattern as slcing discriminator type as pattern is deprecated.
- Move PractitionerRole contact profile into CommuncationRequest for urgent communciation to provider.
- Overwrite comment field in profiles where an invalid html reference is generated (publisher bug but this at least removes issue).
- Update description of CommunicationRequest to restrict SMSs to patient.
|
| 31 Oct 2024 |
1.2.28 |
- Add pathology report example.
- Move to referring to named slices in fsh rather than anonymous slices.
- Use Canonical references rather than explicit references to structure definitions.
- Remove genie local fasting extension and use the published service request precondition extension.
- Add an example of using Appointment.lastModified extension.
- Add ACN as a named organization identifier.
|
| 23 Oct 2024 |
1.2.27 |
|
| 22 Oct 2024 |
1.2.26 |
- Replace GSCoverage use with EOrdersCoverage for requests.
|
| 22 Oct 2024 |
1.2.23 |
- Attempt to use both GSCoverage and EOrdersCoverage.
|
| 22 Oct 2024 |
1.2.22 |
- Add lastModified extension to Appointment.
- Move to AUBaseDiagnosticRequest to avoid R4 publisher warning.
- Add experimental status to various profiles to avoid publisher warnings.
- Introduce local IG pregnancy profiles for future use.
|
