Non-patient File Sharing (NPFS), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 2.2.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.NPFS/ and changes regularly. See the Directory of published versions

2:3.89 Update DocumentReference [ITI-89]

2:3.89.1 Scope

This transaction allows a File Source to update a DocumentReference Resource previously submitted. The DocumentReference Resource represents metadata for a file that is not associated with a patient.

The File Manager is not required to support FHIR resource versioning (see https://www.hl7.org/fhir/R4/http.html#history).

2:3.89.2 Actor Roles

2:3.89.3 Referenced Standards

HL7 FHIR

HL7 FHIR Release 4.0

2:3.89.4 Messages

2:3.89.4.1 Update DocumentReference Request Message

The File Source uses this message to update a FHIR DocumentReference Resource already stored on the File Manager.

2:3.89.4.1.1 Trigger Events

The File Source needs to update one DocumentReference Resource managed in the File Manager.

Prior to sending the update, the File Source shall discover the id of the existing DocumentReference Resource.

2:3.89.4.1.2 Message Semantics

The File Source shall issue an HTTP request according to requirements defined in HL7^® FHIR^® standard for “update” interaction (http://hl7.org/fhir/R4/http.html#update).

The File Source shall use an HTTP PUT method to submit to the File Manager a DocumentReference Resource. The DocumentReference Resource conveys to the File Manager the update to a file’s metadata.

This message shall convey one DocumentReference Resource. The id of the DocumentReference Resource shall be valued with the id of the DocumentReference Resource to be updated; see Resource Profile: NPFS DocumentReference for other constraints upon the DocumentReference Resource.

The File Source shall submit the DocumentReference Resource in either XML format or JSON format. Values accepted for media-type of the request message are defined in the ITI TF-2: Appendix Z.6 (currently in the Appendix Z on HL7 FHIR Trial Implementation Supplement).

2:3.89.4.1.2.1 Update DocumentReference Request message example

For an example of a Update DocumentReference Request see Example DocumentReference: DocumentReference for Update.

2:3.89.4.1.3 Expected Actions

The File Manager shall support all the media-type listed in ITI TF-2: Appendix Z.6 (currently in the Appendix Z on HL7 FHIR Trial Implementation Supplement).

On receipt of the DocumentReference Update Request, the File Manager shall validate and update the existing resource and respond with one of the HTTP codes defined in Section 3.89.4.2.2 Message Semantics.

2:3.89.4.2 Update DocumentReference Response Message

The File Manager returns a HTTP Status code appropriate to the processing.

2:3.89.4.2.1 Trigger Events

When the File Manager has updated the DocumentReference Resource, the File Manager sends this message to the File Source acknowledging the result of the update request.

2:3.89.4.2.2 Message Semantics

When the File Manager has processed the request, it shall return an HTTP response with an overall status code.

The File Manager returns a HTTP status code appropriate to the processing, conforming to the transaction specification requirements as specified in https://www.hl7.org/fhir/R4/http.html#update.

2:3.89.4.2.3 Expected Actions

The File Source processes the results according to application-defined rules.

2:3.89.4.3 CapabilityStatement Resource

File Managers implementing this transaction shall provide a CapabilityStatement Resource as described in ITI TF-2: Appendix Z.3 indicating the transaction has been implemented.

• Requirements CapabilityStatement for File Consumer implementing Retrieve File
• Requirements CapabilityStatement for File Manager

2:3.89.5 Security Considerations

See NPFS Security Considerations.

The files are not Patient specific, but they may have other needs for security controls, such as business knowledge restrictions. Thus, the use of Security may be applicable. Actors involved in this transaction should be aware that even if the Resources exchanged do not contain PHI or other private information, updating those Resources could compromise patient care or have other legal ramifications. For general security considerations, see ITI TF-2: Appendix Z.8.

2:3.89.5.1 Security Audit Considerations

The File Source when grouped with ATNA Secure Node or Secure Application Actor shall be able to record a Update DocumentReference Source Audit Event Log.

The File Manager when grouped with ATNA Secure Node or Secure Application Actor shall be able to record a Update DocumentReference Manager Audit Event Log.