StructureDefinition-IHE.BasicAudit.PatientQuery

Source

ihe.iti.balp#current:Basic Audit Log Patterns (BALP) (v4.0.1)

resourceType

StructureDefinition

IHE.BasicAudit.PatientQuery

canonical

https://profiles.ihe.net/ITI/BALP/StructureDefinition/IHE.BasicAudit.PatientQuery

version

1.1.2

status

active

publisher

IHE IT Infrastructure Technical Committee

name

PatientQuery

title

Basic AuditEvent for a successful Query with Patient

date

2023-07-28T13:59:05+00:00

description

A basic AuditEvent profile for when a RESTful Query action happens successfully, and where there is an identifiable Patient subject associated with the read Resource(s). - Given a RESTful Query is requested - And the request is for a Patient subject indicated - The requestor includes a Patient id or identifier as a query parameter - The requestor security context is limited to a given Patient identity - And the request is authorized - Authorization failures should follow [FHIR core Access Denied](http://hl7.org/fhir/security.html#AccessDenied) - When successful - Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome - Note success may result in zero or more results. The number of results and the content of the results are not recorded. - Then the AuditEvent recorded will conform - The raw search request is base64 encoded and placed in the .entity[query].query element. The base64 encoding of the raw search request enables preserving exactly what was requested, including possibly malicious patterns. This enables detection of malicious or malformed requests. - The cleaned search may be recorded (not base64) in the .entity[query].description. The cleaned search request would have removed parameters that were not understood/supported. The cleaned search request in the .description element enables more efficient processing. - And When multiple patient results are returned, one AuditEvent is created for every Patient identified in the resulting search set. Note this is true when the search set bundle includes any number of resources that collectively reference multiple Patients. This includes one Resource with multiple subject values, or many Resources with single subject values that are different. Note: the pattern defined in DICOM and IHE have that the client is identified as the Source Role ID, and the server is identified as the Destination Role ID. This may not be so obvious, as the data actually flows the opposite direction. This pattern is established and thus followed here.

jurisdictions

fhirVersion

4.0.1

kind

resource

abstract

false

sdTtype

AuditEvent

derivation

constraint

base

https://profiles.ihe.net/ITI/BALP/StructureDefinition/IHE.BasicAudit.Query

Usages

Audit Event for PIXm Query by the Consumer (derives from)
Audit Event for Find Document References Transaction at Document Consumer (derives from)
IHE BALP Audit Creator (profile)
IHE ATNA Audit Record Repository supporting BALP Content (profile)
Audit Event for Find Document Lists Transaction by the Document Consumer (derives from)
IHE BALP Audit Consumer (profile)
Audit Event for Find Document Lists Transaction at Document Responder (derives from)
Audit Event for PIXm Query by the Manager (derives from)
Audit Event for Find Document References Transaction at Document Responder (derives from)

Name	Card.	Type	Description & Constraints
AuditEvent		Query
entity	2..
entity:patient	1..1
what	1..	Reference ( Patient )
type	1..		Required Pattern: At least the following
system	1..1	uri	Identity of the terminology system Fixed Value: http://terminology.hl7.org/CodeSystem/audit-entity-type
code	1..1	code	Symbol in syntax defined by the system Fixed Value: 1
role			Required Pattern: At least the following
system	1..1	uri	Identity of the terminology system Fixed Value: http://terminology.hl7.org/CodeSystem/object-role
code	1..1	code	Symbol in syntax defined by the system Fixed Value: 1
Documentation for this format

Produced 08 Sep 2023