I found this tutorial deck given at the December 2025 HL7 Europe Meeting by @Ward Weistra https://hl7europe.org/wp-content/uploads/2025/12/202512-Obligations-and-Must-Support-Ward-Weistra-Firely.pdf

@Heath Frankel @Danielle Tavares-Rixon

Regarding obligation extension tutorial, as suggestion for additions to next take on subject, IMHO: it would be super useful to have examples "from the Wild" (even ones from laboratory conditions :wink: would do) for the other definitionally significant sub-extensions beside the most commonly used 'code' and 'actor' it would also be helpful for IG authors new to subject, if current, infamous, tooling generated "anomaly" leading to slicing warnings for each and every instance of obligation used in IG would get a heads up in presentation. And maybe description of the IG rendering rules applied to inherited obligations deserve a short mention too. presentation does not describe inner structure of the FHIR CodeSystem ( http://hl7.org/fhir/CodeSystem/obligation ) used to express 'code' sub-extension; the commonly appearing manifestation of code e.g. "SHALL: populate-if-known" is just the "outer visual layer" from CS that by itself COULD theoretically be used (and further developed as part of being "trial-use") to cover more of obligation space/scope. Jan 2026 WGM seems to have a few related Jiras on agenda, interesting to see where those land note that the official version of obligation extension referred in presentation (5.2.0 - February 2025) is missing the most recent addition (5.3.0-ballot-tc1 - September 2025 Ballot) of 'applicable-number' sub-extension brought up in AU Patient Summary context.

We discussed 2 Obligations discuson Q4 yesterday during the IPS update in Patient Care, Discussion will continue in FHIR-I q2 on Thursday https://confluence.hl7.org/spaces/FHIRI/pages/404100078/FHIR+Infrastructure+WGM+Agenda+202601

FWIW Just my personal opinion. Reading those Jiras (and associated WG meeting minutes) but still, TBH, I can't really figure out how they are, directly at least, solving the core issue these Jiras were brought up for ? Of course, clarification of obligation extension documentation is a Good Thing, but what do those resolutions amount to in practical terms ? And what does (sort-of disclaimer found in both Jiras) "Note that this resolution expects editorial discretion in application" actually mean ?

Just answering the last question as I was on the FHIR-I call. "Note that this resolution expects editorial discretion in application" just means that they may change the final wording used in the clarification from what it's the resolution (but the words in the JIRA represent the main intent). This is done often when there's a large group and a general consensus has been reached on what is attempting to be communicated. Then the editors applying the changes can change a few words here and there to make more readable sentences. We did this with several JIRA issues in 2.0 of IPS and I think it's common elsewehere as well.

Hi Kari, based on the explanation I heard in the Patient Care Q4 on Monday, I think we have some level of understanding around how contextual filtering for summary and relevancy use cases can work in conjunction with obligations, including scenarios where we want to explicitly state at-least-1. Hopefully we can turn this general FHIR-I guidance into guidance in the context of IPS and have it endorsed by FHIR-I. I am hoping we can progress this in this week's call.

BTW how are these mentioned complex obligation extension sub-elements (like the 'usage') rendered in IG ? Any experiences, anybody ? What happens when a profile inherits such obligations ?

Hey! Happy you found my slide deck, here's the video that goes along with it: https://www.youtube.com/watch?v=e2Tk0CG0QKs

@Kari Heinonen Some examples from the wild are here: https://simplifier.net/guide/CA-Core/Index/FHIR-Artifacts/Profiles/Patient-CA-Core.page.md?version=current (look for the O in rendering) https://build.fhir.org/ig/hl7-eu/laboratory/en/obligations.html When making a derived profile these extensions should be inherited, just like Must Support or mappings etc.

@Ward Weistra Well, to be precise, I was really hoping for examples specifically using these more advanced features/sub-extensions . As there are numerous cases around just using the basic obligation_code/actor pairs and even the inherited obligation rendering issue did find (? but maybe are not documented yet ?) some explanation of the applied rules.

These are the once I'm familiar with. It's certainly all quite new and experimental.

Also, there's for many parts of the FHIR spec not a clear definition on how it's inherited :wink: But without any special definition, it will just inherit when creating a derived profile, like any other extension on element.

repasting this here tha I DM to Ward

Hi Ward, yes. We did have discussions where the resolution for two comments was to add guidance to the Obligations extension or the Obligations page. The resolutions themselves were fairly cryptic, so I reviewed the notes and my own recollection and proposed some text. Lloyd felt that my text proposal introduced inaccuracies and pushed back strongly. The key takeaway that @John D'Amore , @Rob Hausam , and I all recall is that ObligationBehavior codes are scoped by the context in which they are used . From an IPS perspective, this is the critical point: while we cannot change the meaning of base obligations, we can provide guidance on how they should be interpreted in the context of a summary document. I’m wondering if you might be willing to take a look and suggest improved, accurate text—at the right level of quality and clarity for analyst readers—that could appropriately be added to the specification. https://jira.hl7.org/browse/FHIR-55398 https://jira.hl7.org/browse/FHIR-55396

I don’t think there’s an difference in the interpretation of the obligations. Any variation in interpretation is driven by the model, not the obligation

What do you mean by "driven by the model,"?

Is this a true statement? "Obligations are defined by FHIR and are model-driven; guidance may clarify how they are applied in practice in specific usage contexts."

I don't think the notions around "relevance" have anything to do with obligations and would be guidance or clarification around obligations. They'd be clarification around the element. Framed differently - imagine that a particular type of system had no obligations around populating a particular element but chose to populate it anyhow. The rules on "what's allowed to go here?" would still be the same for them, even though there were no relevant obligations for them. You wouldn't want someone producing an IPS instance who was somehow unbound by the conformance obligations to include 80 years worth of lab data in the labs section of an IPS. Whether there's no obligation, MAY:populate, SHOULD:populate, or SHALL:populate, the rules on what type of lab data is permitted are the same - and thus orthogonal to the declared obligation(s). There is only one obligation that specifically requires guidance to appear in the IG around its use - and the obligation code specifically calls it out - "process". The specifics of what "process" means are IG defined and all IGs that use that obligation must explain their requirements. It's also possible for IGs to define general requirements around things like storage (e.g. it must be encrypted, data must be retained for 5 years or for no longer than 6 months), UI (must meet certain accessibility standards, certain data must appear on the same screen), etc. But those are handled as SHALL statements in the IG, not as obligations.

FWIW some of my thoughts on defining obligations, mainly from viewpoint of resulting general architecture of Patient Summary (i.e. question of "relevant entries") and assuming 'obligation' -extensions are NOT themselves used to convey the context/scope of the IG. And just more convenient for me to make these comments here than somewhere else, sorry for that. a) should narrative guidance on this topic in IG be more formalized (even if still essentially free text), or better yet, even be somehow computationally useful b) per patient, are we thinking of only single PS coming directly from single source, having multiple PSes from various sources, service aggregating a PS from multiple sources (but maybe not covering all, supplying data either natively or as PS of their own), ... c) what should happen if/when "XYZ PS IG" derived from IPS is used not so much as a summary as intended, but more as a general format for representing patient's general health record data d) processing/handling such "XYZ PS" document relying just to narrative guidance in receiver's "ABC PS IG", technically also derived from IPS and formally complying to "XYZ PS IG", but still having some subtle differences for these repeating elements and how they are selected to be included e) what should happen if/when certain sections/sub-profiles derived from IPS/"XYZ PS IG" are used as components of more specific, narrowly scoped, summary type documents (e.g. use case centric IG like discharge summary or medication overview/plan) where context is clearly different Personally thinking should each PS section carry some explicit, structurally harmonized attestation of their content's scope (i.e. unambiguously expanding on idea of "no-known-X"/DAR mechanism) creating another "kind of obligation", maybe called expectation -extension, mostly for informational purposes but anyway formally, explicitly conveying how the intended scope of IG relates to e.g. PS section content

Obligations never define what's allowed (or not allowed) to appear in an instance. If you want rules to express what's allowed in an instance, you can use invariants, you can embed expected semantics in a code (e.g. Composition.code, List.code) or you can provide free-text guidance. If there's a proposal for some new alternative mechanism for setting rules for what legal content exists, that could be considered, but it should be labeled as something other than 'obligation'