Support searching and returning of docStatus in DocumentReference (not just status)

[gcangioli]

Background
The DocumentReference resource includes a status element, describing the status of the document reference. and the docStatus which captures the status of the underlying document.

The IHE MHD MinimalDocumentReference profile sets the docStatus element to 0..0.

A common requirement is to know not only whether the DocumentReference is “current” (meaning the reference is valid) but also whether the document itself is preliminary/final/deprecated, etc. and potentially filter the request according to that information

Proposal

• Remove from the MinimalDocumentReference the constraint 0..0 for docStatus
• allow to use doc-status as search parameter

[JohnMoehrke]

There is no equivalence in XDS/XCA; so this would leave those environments with ambiguity and conflict. MHD keeps to the fundamentals of Document Sharing. If you have an environment that is beyond Document Sharing, then you would simply not be using MHD. John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security ***@***.*** | M +1 920-564-2067 Consulting: https://MoehrkeResearch.com Blog: https://healthcaresecprivacy.blogspot.com

…

On Wed, Nov 19, 2025 at 8:29 AM Giorgio Cangioli ***@***.***> wrote: *gcangioli* created an issue (IHE/ITI.MHD#260) <#260> *Background* The DocumentReference resource includes a *status* element, describing the status of the document reference. and the *docStatus* which captures the status of the underlying document. The IHE MHD MinimalDocumentReference profile sets the *docStatus* element to 0..0. A common requirement is to know not only whether the DocumentReference is “current” (meaning the reference is valid) but also whether the document itself is preliminary/final/deprecated, etc. and potentially filter the request according to that information *Proposal* - Remove from the MinimalDocumentReference the constraint 0..0 for docStatus - allow to use doc-status <https://hl7.org/fhir/R5/documentreference-search.html#DocumentReference-doc-status> as search parameter — Reply to this email directly, view it on GitHub <#260>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHBWC53GXJLVV5YZ5YFO7C335R5FJAVCNFSM6AAAAACMSSN7KOVHI2DSMVQWIX3LMV43ASLTON2WKOZTGY2DEOJZG43TEMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JohnMoehrke]

Further note. There is no use of the DocumentReference profiles in the ITI-67; so you are actually free to return this element. Many MHD Document Consumers may not look at it.

[gcangioli]

Not clear to me the last point .. ITI-67 is is realized by a Document Consumer actor.
If I intepret correctly the associated capability statement https://profiles.ihe.net/ITI/MHD/CapabilityStatement-IHE.MHD.DocumentConsumer.html I understand that search and read are made on DocumentReference compling with the https://profiles.ihe.net/ITI/MHD/StructureDefinition/IHE.MHD.Minimal.DocumentReference profile

In that profile docStatus is set to 0..0

[gcangioli]

If the actors are not forced to satisfy the IHE.MHD.Minimal.DocumentReference profile - but it should made more clear :-) - then following the statement "The Document Responder must implement the parameters described below. The Document Responder may choose to support additional query parameters beyond the subset listed below. Any additional query parameters supported shall be supported according to the core FHIR specification." satisfy my expectation; and a jurisdiction could agree to optionally support also the docStatus

[JohnMoehrke]

Ah, that is where you are seeing the binding to MHD Minimal. Thank you for being specific about the problem you see.

I had not considered that a limit, but rather a specification of the extensions to expect. I guess a new profile might be called for that has no limits but does have the extensions, so as to align with the text of ITI-67. The intent has always been that ITI-67 does not restrict elements that can be returned. Or, I guess the Document Consumer and DocumentResponder capabilityStatement should not reference MHD profiles at all, as that is what the text does.

[JohnMoehrke]

or, the MHD profiles should be listed as rest.resource.supportedProfile rather than .profile. It seems this is what MHD intends. Possibly this move should be done for all CS, not just search side?

https://build.fhir.org/profiling.html#profile-uses

[JohnMoehrke]

yes, you can support more search parameters.

[JohnMoehrke]

Given discussion on zulip
https://chat.fhir.org/#narrow/channel/179280-fhir.2Finfrastructure-wg/topic/CapabilityStatement.20resource.2Eprofile.20meaning/with/564121891

It seems moving away from .profile to .supportedProfile is appropriate.

Note that many other IHE Profiles have possibly made this mistake as they are using .profile and not .supportedProfile, including: Appendix Z., mCSD, PIXm, PDQm, BALP, PMIR, DSUBm, NPFS, ITI Scheduling, QEDm, mXDE -- and also PCC, QRPH, Pharmacy, and Radiology.

[JohnMoehrke]

Discussed December 18, 2025 in ITI committee. John Will submit a CP to change the receive side MHD CapabilityStatements to use .supportedProfile rather than .profile as that was the original intention.

[JohnMoehrke]

Note: The FindDocumentReferencesResponse profile should also be relaxed to simply unprofiled DocumentReference. FindListsResponse should be changed from a closed slicing to an open slicing, keeping the profiles as informative about the difference between SubmissionSet and Folder, but not restricting the output to only these.

[JohnMoehrke]

Please see CP-ITI-1327 -- in Ballot 66.