Basic Audit Log Patterns (BALP)
1.1.3 - Trial-Implementation International flag

This page is part of the IHE Basic Audit Log Patterns (BALP) (v1.1.3: Publication) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Resource Profile: Basic AuditEvent for a successful Query with Patient

Official URL: https://profiles.ihe.net/ITI/BALP/StructureDefinition/IHE.BasicAudit.PatientQuery Version: 1.1.3
Active as of 2024-02-14 Computable Name: PatientQuery

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

Usage:

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from Query

NameFlagsCard.TypeDescription & Constraintsdoco
.. AuditEvent 0..*QueryEvent record kept for security purposes
... entity 2..*BackboneElementData or objects used
... entity:patient 1..1BackboneElementData or objects used
.... what 1..1Reference(Patient)Specific instance of resource
.... type 1..1CodingType of entity involved
Required Pattern: At least the following
..... system1..1uriIdentity of the terminology system
Fixed Value: http://terminology.hl7.org/CodeSystem/audit-entity-type
..... code1..1codeSymbol in syntax defined by the system
Fixed Value: 1
.... role 1..1CodingWhat role the entity played
Required Pattern: At least the following
..... system1..1uriIdentity of the terminology system
Fixed Value: http://terminology.hl7.org/CodeSystem/object-role
..... code1..1codeSymbol in syntax defined by the system
Fixed Value: 1

doco Documentation for this format

 

Other representations of profile: CSV, Excel, Schematron