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

From IHE Wiki
Jump to navigation Jump to search
Line 51: Line 51:
  
  
== Use-Case of Reference: Privacy Policies ==
+
== Use-Case of Reference: Patient access to his audit records process flow ==
  
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.
+
During a hospitalization, Mr. Brown was asked to sign a consent to share documents produced during that clinical event with a research facility, so that researchers could analyze the efficiency of the applied treatment. Mr. Brown does not provide this consent because he is worried that his data could be used for marketing purposes. A nurse collects the patient’s consent document, but forgets to record his decision in the HIS system.
 
+
Access to all the data collected during Mr. Brown’s hospitalization by clinicians involved in his care are tracked as “Export” or “Disclosure events for a “Treatment” purpose. An access to the data by the research facility would be tracked as “Export” or “Disclosure” events for a “Research” purpose. Mr. Brown’s healthcare facility provides on-line access to health information. Mr. Brown can use a web app to access this data (shared using XDS or XCA infrastructure). The web app can also display audit information related to those documents/studies. Audit records are collected by many ATNA Audit Record Repositories, but local policies or system configurations allows the web app to identify the right Audit Record Repository system that stores relevant records. Using the document and study identifiers, the web app can query the appropriate ATNA Audit Record Repository.
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 NPFSm 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 web app reports to Mr. Brown that his documents/studies had been disclosed or exported for both treatment and research purposes.
 
 
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===
 
===Process flow===

Revision as of 06:00, 27 February 2018

Non-Patient File Sharing (NPFSm)

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 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:

  • 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 NPFSm 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: Patient access to his audit records process flow

During a hospitalization, Mr. Brown was asked to sign a consent to share documents produced during that clinical event with a research facility, so that researchers could analyze the efficiency of the applied treatment. Mr. Brown does not provide this consent because he is worried that his data could be used for marketing purposes. A nurse collects the patient’s consent document, but forgets to record his decision in the HIS system. Access to all the data collected during Mr. Brown’s hospitalization by clinicians involved in his care are tracked as “Export” or “Disclosure events for a “Treatment” purpose. An access to the data by the research facility would be tracked as “Export” or “Disclosure” events for a “Research” purpose. Mr. Brown’s healthcare facility provides on-line access to health information. Mr. Brown can use a web app to access this data (shared using XDS or XCA infrastructure). The web app can also display audit information related to those documents/studies. Audit records are collected by many ATNA Audit Record Repositories, but local policies or system configurations allows the web app to identify the right Audit Record Repository system that stores relevant records. Using the document and study identifiers, the web app can query the appropriate ATNA Audit Record Repository. The web app reports to Mr. Brown that his documents/studies had been disclosed or exported for both treatment and research purposes.

Process flow

PP.png

Specification

Profile Status: Trial Implementation

Documents: NPFSm 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 published on Simplifier as a set of FHIR conformance resources, that are also registered at https://registry.fhir.org

Note the following links are to current instances maintained in Simplifier. This URL may change over time, which is why the canonical URI is provided. The canonical URI can not be used for browser navigation, but can be used for lookup at registry or simplifier as search capability allows.

Prior conformance resources have been registered, they should now be marked retired

The conformance resources are also available on the Implementation Material folder.