Difference between revisions of "Non-patient File Sharing (NPFS)"

From IHE Wiki
Jump to navigation Jump to search
m (JohnMoehrke moved page Non-patient File Sharing (NPFSm) to Non-patient File Sharing (NPFS) over redirect: remove m)
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=Non-Patient File Sharing (NPFSm) =
+
=Non-Patient File Sharing (NPFS) =
  
  
Line 11: Line 11:
 
There are IHE Profiles that manage documents that are not patient-related; this profile does not require that the actors be able to process the contents of the files being shared. Understanding this profile does not require the knowledge of the files shared.
 
There are IHE Profiles that manage documents that are not patient-related; this profile does not require that the actors be able to process the contents of the files being shared. Understanding this profile does not require the knowledge of the files shared.
  
The NPFSm Profile specifies transactions for the sharing of files. Any file type can be shared using this profile; however specific guidance is given for three types of files:  
+
The NPFS Profile specifies transactions for the sharing of files. Any file type can be shared using this profile; however specific guidance is given for three types of files:  
 
*Workflow Definitions: files which define the processing rules for a specific clinical/administrative workflow (see ITI TF-1: 30.4.1.1 “XDW Workflow Architecture” for additional information).
 
*Workflow Definitions: files which define the processing rules for a specific clinical/administrative workflow (see ITI TF-1: 30.4.1.1 “XDW Workflow Architecture” for additional information).
 
*Privacy Domain Policies: files which describe a specific privacy policy that applies to, or may be agreed by the patient (see ITI TF-1: 19.2 “Creating Patient Privacy Policies” for further details).
 
*Privacy Domain Policies: files which describe a specific privacy policy that applies to, or may be agreed by the patient (see ITI TF-1: 19.2 “Creating Patient Privacy Policies” for further details).
 
*Stylesheets: structured documents used by user-agents (e.g., Web Browsers) to render the content of an XML document.
 
*Stylesheets: structured documents used by user-agents (e.g., Web Browsers) to render the content of an XML document.
Local policies may extend the types of files shared using NPFSm and that can be classified using the metadata model described in this profile.
+
Local policies may extend the types of files shared using NPFS and that can be classified using the metadata model described in this profile.
  
 
=Actors and Transactions=
 
=Actors and Transactions=
Line 22: Line 22:
  
 
==Actors==
 
==Actors==
===Authorization Decisions Manager===
+
===FileManager===
The Authorization Decisions Manager is responsible for the management of access control decisions in the entire XDS domain. From the Access Control point of view, this actor is the unique Policy Decision Point (PDP) of the entire domain for all documents because it may decide on the outcome of an incoming authorization request in order to provide access to specific resources (documents). The Authorization Decisions Manager completes the Authorization Decision creating and storing a security token. This security token does not need to be exposed to other systems, and it certifies the decision made. This actor could implement additional Access Control functionalities required in the specific implementation scenario.
+
The File Manager stores files provided by the File Source and maintains related metadata. The File Manager responds to search and retrieve requests initiated by the File Consumer. The File Manager responds to metadata update requests initiated by the File Source.  
(Refer to the White Paper IHE ITI Access Control White Paper for further information about PDP and Access Control Systems).
+
 
===Authorization Decisions Verifier===
+
===File Consumer===
The Authorization Decisions Verifier is the actor that verifies if the Requester Entity is authorized to access specific resources by querying the Authorization Decisions Verifier. This actor enforces the Access Decision made by the trusted Policy Decision Point, so it acts as a Policy Enforcement Point (PEP). This actor enables the secure exposure of documents, allowing access only to Requester Entities previously authorized by the Policy Decision Point.  
+
The Authorization Decisions Verifier is the actor that verifies if the Requester Entity is authorized to access specific resources by querying the Authorization Decisions Verifier. This actor enforces the Access The File Consumer queries for file metadata meeting certain criteria, and may retrieve selected files.
The Requester Entities (XDS Document Consumer) convey at least the following information to the Authorization Decisions Verifier:
+
 
*Requester Entity that obtains authorization (e.g., using an identity assertion)
+
===File Source===
*The unique ID of the document that can be accessed (within the Retrieve Document Set-b Request)
+
The File Source publishes and updates files produced by either the File Source or by other systems. It is responsible for sending files and related metadata to a File Manager. The File Source can send metadata update requests to the File Manager.  
(Refer to the White Paper IHE ITI Access Control White Paper for further information about PEP and Access Control Systems).
 
  
  
 
==Transactions==
 
==Transactions==
===Authorization Decisions Query===
+
===Submit File===
 +
 
 +
This transaction allows a File Source to publish one or more new files and related metadata. It also enables update of one or more existing files and metadata by publishing a new version.
 +
 
 +
This transaction uses the Create File Request message either when there is no prior file, or when the prior needs to be preserved.
 +
 
 +
This transaction uses the Update File Request message when there is a prior file that doesn’t need to be preserved. (The File Manager is not required to support FHIR resource versioning; see https://www.hl7.org/fhir/STU3/http.html#history.)
 +
 
 +
===Search File===
 +
 
 +
The transaction is used by the File Consumer to find DocumentReference Resources that are stored and managed by a File Manager. Those DocumentReference Resources are not associated with a Patient Resource.
  
This transaction is used by the Authorization Decisions Verifier to query for authorization decisions, granted and managed by the Authorization Decisions Manager. These authorization decisions are created for an entity that is authorized to disclose specific documents.
+
===Update DocumentReference File===
The Authorization Decisions Verifier asks for authorizations based on: the Requester Entity and the requested documents identifiers.
 
  
===Relevant standards:===
+
The File Source uses this message to update just a DocumentReference Resource already stored by the File Manager
  
*OASIS SOAP v1.2
+
== Use-Case of Reference: Privacy Policies ==
*OASIS Security Assertion Markup Language (SAML) v2.0
 
*OASIS eXtensible Access Control Markup Language (XACML) v2.0
 
*OASIS Multiple resource profile of XACML v2.0
 
*OASIS SAML 2.0 profile for XACML v2.0
 
*OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of SAML v2.0 for Healthcare Version 2.0 (not normative)
 
  
 +
A hospital’s privacy office defines a set of Privacy Policies that a patient can agree to. Mr. Blue, a hospital privacy office employee, creates the policy file using the HIS. Using a Submit File [ITI-87] transaction, the application makes it available to all the systems involved in his organization.
  
== Use-Case of Reference: Environment with a centralized Access Decision Manager Use Case Description ==
+
Mrs. Black, a nurse of the Goodcare Hospital, wants to search for the current valid BPPC Privacy Policy files that the admitting patient can agree to. She uses a combined BPPC Content Creator and NPFS File Consumer to issue a query, a Search File [ITI-88] transaction, to search for the current valid Privacy Policy files. Once policies are found, she can retrieve them. The retrieved Privacy Policy files are used, by the Content Creator, in the creation of the consent document that the patient can read and agree to.
  
The XDS Document Repositories are all in the same XDS Affinity Domain, but are unable to perform access decisions. When an entity tries to retrieve some documents from an XDS Repository the XDS Document Repository lacks of the information needed to make an access control decision. The Authorization Decisions Manager can make the decision at the time of the query to the XDS Registry. This decision is enforced by the XDS Document Repository grouped with an Authorization Decisions Verifier.
+
A legal health officer informs the Goodcare Hospital that one of the Privacy Policy files changed. Mr. Blue searches to discover the Privacy Policy and its related metadata (including FHIR resource ids), once they are found he uses an HIS to perform the Submit File [ITI-87] to update the targeted Privacy Policy and related metadata.
For example:
 
Mr. White comes to his GP, Dr. Brown, to show him a Laboratory Report. This Laboratory Report is shared in a XDS infrastructure. Using his EHR, Dr. Brown queries for Mr. White’s Laboratory Reports shared in the XDS infrastructure. The Query Response returns some DocumentEntries to the XDS Document Consumer. Each XDSDocumentEntry in the response is authorized for the retrieval. Dr. Brown uses his XDS Document Consumer to retrieve these documents. XDS Document Repository verifies the authorization for the Requester Entity for each document requested before providing documents.
 
No other access control decisions are needed at this level.
 
Each Authorization Decision has a time slot of validity. Dr. Brown can retrieve documents until the Authorization expires. The Repository discloses only documents requested and authorized.
 
There are conditions where XDS Document Repository might not be providing documents:
 
*The Requester Entity does not have authorization according to the Authorization Decisions Query
 
*The authorization was granted too long ago and the Authorization Decision is expired
 
The user attempting to retrieve from the XDS Document Repository is different from the user that was authorized (there is a mismatch between the user that performs the retrieve and the user that queries for documents).
 
  
 
===Process flow===
 
===Process flow===
[[File:SERusecase.png]]
+
[[File:PP.png]]
 +
 
 +
==Specification==
 +
 
 +
'''Profile Status:''' [[Comments| Trial Implementation]] 
 +
 
 +
'''Documents:'''
 +
[http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_NPFS.pdf NPFS Supplement]
 +
 
 +
'''Additional Supplements:'''
 +
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]
 +
 
 +
'''Underlying Standards:'''
 +
*HL7 FHIR  HL7 FHIR standard STU3 http://hl7.org/fhir/STU3/index.html
 +
** DocumentReference
 +
** OperationOutcome
 +
** Bundle
 +
** Binary
 +
*RFC2616  Hypertext Transfer Protocol – HTTP/1.1
 +
*RFC7540 Hypertext Transfer Protocol – HTTP/2
 +
*RFC3986 Uniform Resource Identifier (URI): Generic Syntax
 +
*RFC6585 Additional HTTP Status Codes
 +
 
 +
==FHIR Implementation Guide==
 +
Informatively this profile is also as a set of FHIR conformance resources, that are also registered at https://registry.fhir.org
 +
 
 +
The conformance resources are available on the [[Implementation Material]] folder.
  
  
Line 68: Line 90:
 
[[Category:Profiles]]
 
[[Category:Profiles]]
 
[[Category:ITI Profile]]
 
[[Category:ITI Profile]]
[[Category:DocShare]]
+
[[Category:FHIR]]
 
[[Category:Security]]
 
[[Category:Security]]

Revision as of 13:25, 18 November 2019

Non-Patient File Sharing (NPFS)

Introduction

This supplement defines how to enable the sharing of non-patient files.

Those files can be created, consumed and updated by many different systems involved in a wide variety of data sharing workflows (clinical workflow definition, domain policies sharing, stylesheets management, etc.). This supplement identifies three actors: File Manager, File Consumer, and File Source. To fulfill use-cases requirements, this profile defines three new transactions (Submit File transaction, Search File transaction and Update DocumentReference transaction) and re-uses an MHD transaction: Retrieve Document [ITI-68].

There are IHE Profiles that manage documents that are not patient-related; this profile does not require that the actors be able to process the contents of the files being shared. Understanding this profile does not require the knowledge of the files shared.

The NPFS Profile specifies transactions for the sharing of files. Any file type can be shared using this profile; however specific guidance is given for three types of files:

  • Workflow Definitions: files which define the processing rules for a specific clinical/administrative workflow (see ITI TF-1: 30.4.1.1 “XDW Workflow Architecture” for additional information).
  • Privacy Domain Policies: files which describe a specific privacy policy that applies to, or may be agreed by the patient (see ITI TF-1: 19.2 “Creating Patient Privacy Policies” for further details).
  • Stylesheets: structured documents used by user-agents (e.g., Web Browsers) to render the content of an XML document.

Local policies may extend the types of files shared using NPFS and that can be classified using the metadata model described in this profile.

Actors and Transactions

Npfsactors.png

Actors

FileManager

The File Manager stores files provided by the File Source and maintains related metadata. The File Manager responds to search and retrieve requests initiated by the File Consumer. The File Manager responds to metadata update requests initiated by the File Source.

File Consumer

The Authorization Decisions Verifier is the actor that verifies if the Requester Entity is authorized to access specific resources by querying the Authorization Decisions Verifier. This actor enforces the Access The File Consumer queries for file metadata meeting certain criteria, and may retrieve selected files.

File Source

The File Source publishes and updates files produced by either the File Source or by other systems. It is responsible for sending files and related metadata to a File Manager. The File Source can send metadata update requests to the File Manager.


Transactions

Submit File

This transaction allows a File Source to publish one or more new files and related metadata. It also enables update of one or more existing files and metadata by publishing a new version.

This transaction uses the Create File Request message either when there is no prior file, or when the prior needs to be preserved.

This transaction uses the Update File Request message when there is a prior file that doesn’t need to be preserved. (The File Manager is not required to support FHIR resource versioning; see https://www.hl7.org/fhir/STU3/http.html#history.)

Search File

The transaction is used by the File Consumer to find DocumentReference Resources that are stored and managed by a File Manager. Those DocumentReference Resources are not associated with a Patient Resource.

Update DocumentReference File

The File Source uses this message to update just a DocumentReference Resource already stored by the File Manager

Use-Case of Reference: Privacy Policies

A hospital’s privacy office defines a set of Privacy Policies that a patient can agree to. Mr. Blue, a hospital privacy office employee, creates the policy file using the HIS. Using a Submit File [ITI-87] transaction, the application makes it available to all the systems involved in his organization.

Mrs. Black, a nurse of the Goodcare Hospital, wants to search for the current valid BPPC Privacy Policy files that the admitting patient can agree to. She uses a combined BPPC Content Creator and NPFS File Consumer to issue a query, a Search File [ITI-88] transaction, to search for the current valid Privacy Policy files. Once policies are found, she can retrieve them. The retrieved Privacy Policy files are used, by the Content Creator, in the creation of the consent document that the patient can read and agree to.

A legal health officer informs the Goodcare Hospital that one of the Privacy Policy files changed. Mr. Blue searches to discover the Privacy Policy and its related metadata (including FHIR resource ids), once they are found he uses an HIS to perform the Submit File [ITI-87] to update the targeted Privacy Policy and related metadata.

Process flow

PP.png

Specification

Profile Status: Trial Implementation

Documents: NPFS Supplement

Additional Supplements: Appendix Z on HL7 FHIR

Underlying Standards:

  • HL7 FHIR HL7 FHIR standard STU3 http://hl7.org/fhir/STU3/index.html
    • DocumentReference
    • OperationOutcome
    • Bundle
    • Binary
  • RFC2616 Hypertext Transfer Protocol – HTTP/1.1
  • RFC7540 Hypertext Transfer Protocol – HTTP/2
  • RFC3986 Uniform Resource Identifier (URI): Generic Syntax
  • RFC6585 Additional HTTP Status Codes

FHIR Implementation Guide

Informatively this profile is also as a set of FHIR conformance resources, that are also registered at https://registry.fhir.org

The conformance resources are available on the Implementation Material folder.