Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MHD_068: Use of PATCH by Document Source to support DocumentReference replace #197

Open
JohnMoehrke opened this issue Oct 7, 2022 · 0 comments
Labels
Open-Issue An open-issue to be considered in the future

Comments

@JohnMoehrke
Copy link
Contributor

In the Improvements 2022, (version 4.2.0) there is added functionality "replace" support added to be used by a Document Source to better support FHIR backends like MHDS.

in section 2:3.65.4.1.2.3 Replace, Transform, Signs, and Append Associations
...
If a DocumentReference will be replaced, the to be replaced DocumentReference needs to be added and updated to status superseded within the transaction bundle.

When a Document Source is submitting a new DocumentReference that is replacing a previous DocumentReference, this "replace" functionality is used only to modify the previous DocumentReference.status to the superseded state. In this way the Document Source simply provides minimal details on the previous DocumentReference using PATCH to change the .status to superseded. The new DocumentReference would continue to need to properly populate the .relatesTo element.

see example: Bundle-ex-comprehensiveProvideDocumentBundleReplace.html

Note that this "replace" feature has always worked with XDS and XDR; as those solutions did support the server side functionality to mark previous as superseded.

This replace fix is important for MHDS based persistence, as use of this new PATCH mechanism is the normal FHIR RESTful method. Prior to this new replace feature a MHDS Document Registry would have had to had special handling of replace to mark the old DocumentReference as superseded.

Comments are welcome. Both for and against this new support. Any concerns should be brought forward.

@JohnMoehrke JohnMoehrke added the Open-Issue An open-issue to be considered in the future label Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Open-Issue An open-issue to be considered in the future
Projects
None yet
Development

No branches or pull requests

1 participant