Version-specific location in MHD ITI-65 response message

[Ernst Lawende]

Hi,

 

While using the NIST FHIR toolkit to test my MHD Document Recipient implementation, I encountered an issue with the DocumentReplace test (in Server/MHDv410_DocumentRecipient_minimal) which I think is an issue with the test script.

 

When the test script reads back the original document it expects the status to be changed to “superseded”. It however uses a version-specific URL (which I suspect is taken from entry.response.location in the Provide Document Bundle response message) and fails because is sees a status of “current”. It does not see that the status is “superseded” in the latest version of the resource.

 

The test runs fine when I return a Location header value which is not specific to a version. However, according to the FHIR specification “the Location header should be as specific as possible - if the server understands versioning, the version is included.” (FHIR R4 3.1.0.8).

 

To dig deeper, the MHD spec says that “if a DocumentReference will be replaced, the to be replaced DocumentReference needs to be added and updated to status superseded within the transaction bundle” (IHE MHD 2:3.65.4.1.2.3). I assume this means that an update interaction is performed on the to be replaced DocumentReference, for which FHIR specifies that if the server supports versioning, a new versionId should be generated (see FHIR R4 3.1.0.4). The specification says that “there is no way to update or delete past versions of the record, except that the metadata can be modified” (FHIR R4 3.1.0.12). The “status” field in a DocumentReference resource is not part of the metadata, so updating the status field should generate a new version and leave the old version untouched.

 

Am I right that this is an issue in the test script?

 

kind regards,

 

Ernst Lawende | Software Engineer | Bastion 365

Lange Voorhout 92, 2514 EJ The Hague | The Netherlands

www.bastion365.nl | ern...@bastion365.nl

 

[John Moehrke]

It sounds like the test script does not recognize the updated MHD that has a  UpdateDocumentRefs slice that is used to change the superseded DocumentReference status.    Sorry, but the test scripts are behind the specification. This is not the only case. You should report this through the Gazelle reporting mechanism.

Note that the committee last week approved a patch release for MHD where this was one of the things made more clear in the narrative, where as current release of MHD just has this in an example. You can see the CI build with the fixes that will be in the upcoming v4.2.2 release of MHD. Hope to get this release out in a few weeks.

https://build.fhir.org/ig/IHE/ITI.MHD/branches/master/ITI-65.html

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

--
You received this message because you are subscribed to the Google Groups "IHE MHD Implementors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-mhd-implemen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-mhd-implementors/GV1P190MB1922E4F21DFC9F5A9706A38698E22%40GV1P190MB1922.EURP190.PROD.OUTLOOK.COM.

[Ernst Lawende]

Hi John,

 

Thanks for your reply!

 

I wonder, if the UpdateDocumentRefs slice is missing in the ITI-65 message, would you still expect the status field of a replaced DocumentReference to be updated (based on the value of relatesTo in the replacement)? Based on the R4 / RESTful API spec I’d say no, but this is what the test script does and validates (there is no PATCH request in the transaction Bundle, just POST requests for the replacement DocumentReference, Binary and List).

 

kind regards,

 

Ernst Lawende

[John Moehrke]

The updated MHD that has that slice is fixing a bad assumption we made in earlier versions of MHD.

If MHD is being used as an API to XDS, the XDS registry will likely do the right thing without this additional slice. This was our original use-case, and thus why we didn't include this slice originally.

The slice was added to support MHDS environments where the registry should not be expected to do any magic, it should just be a FHIR Server. Thus the slice is needed to update a MHDS Registry properly.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com