Add RESTful Query and Feed to ATNA

From IHE Wiki
Revision as of 05:56, 27 February 2018 by Gcanal (talk | contribs) (→‎Search File)
Jump to navigation Jump to search

Add RESTful Query to ATNA

Introduction

Event logging is a system facility that is used by healthcare applications and other applications. This supplement updates the Audit Trail and Node Authentication (ATNA) Profile. ATNA defines a standardized way to create and send audit records; however, it does not identify a standardized way to retrieve audit records collected by an Audit Record Repository. This supplement adds Retrieve capabilities to the Audit Record Repository (ARR). This profile defines a new actor, the Audit Consumer, and two new transactions:

  1. The Retrieve ATNA Audit Event [ITI-81] transaction allows an Audit Consumer to retrieve ATNA Audit Events stored within a target Audit Record Repository. This transaction is based on a FHIR RESTful search operation on AuditEvent resources.
  2. The Retrieve Syslog Event [ITI-82] transaction allows an Audit Consumer to search syslog messages stored in an Audit Record Repository. This transaction is defined as a 130 RESTful operation. The search parameters are based on syslog metadata.

Note that ATNA Audit Events are syslog events, so the Retrieve Syslog Event [ITI-82] transaction enables search of ATNA events based on syslog metadata values.

Actors and Transactions

Actros.PNG

Actors

Audit Record Repository

The Audit Record Repository receives event audit reports and stores them. It may be part of a federated network of repositories. It is expected to have analysis and reporting capabilities, but those capabilities are not specified as part of this profile. This profile does not specify the capacity of an Audit Record Repository, because the variety of deployment needs makes it impractical to set requirements for the event report volume or capacity needed. The Audit Repository shall support:

  1. Both audit transport mechanisms specified in ITI TF-2a: 3.20.
  2. Receipt of all IHE-specified audit message formats. Note that the message format is extensible to include both future IHE specifications (e.g., audit requirements for new IHE transactions) and private extensions.
  3. Local security and privacy service protections and user access controls.
  4. All messages complying with the Syslog RFCs shall be accepted. The Audit Repository may ignore or process messages in non-IHE message formats. This may be for backwards compatibility or other reasons.

Optionally the Audit Record Repository supports search capabilities as defined in ITI TF2c: 3.81 and ITI TF-2c: 3.82.

Audit Consumer

The Audit Consumer queries an Audit Record Repository for syslog and ATNA audit records using Syslog metadata and ATNA audit record content. Subsequent processing of the query result is not defined in this profile.

Transactions

Retrieve ATNA Audit Event

This transaction supports the retrieval of ATNA audit record from the Audit Record Repository in accordance with a set of search parameters that determine the retrieved event reports. This transaction enables an Audit Consumer to search audit events that an Audit Record Repository created via the Record Audit Event [ITI-20] transaction. This transaction is a profiling of a standard FHIR search of the AuditEvent resource.

Retrieve Syslog Event

This transaction supports the retrieval of syslog messages from the Audit Record Repository subject to parameters that limit the retrieval.

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

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

Retrieved from "http://wiki.ihe.net/index.php?title=Add_RESTful_Query_and_Feed_to_ATNA&oldid=107728"