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).\n\n- Given a RESTful Query \n- And there is a known Patient subject. \n  - The query parameters may have identified a specific patient, or \n  - The data resulting from a query do have a patient subject\n- And OAuth is used to authorize both app and user\n- When an App requests a RESTful Query to retrieve Resource(s) \n- Then the search request is recorded  \n  - 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.\n  - 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.\n\nno results returned\n- Given no Resource(s) are available for a given Patient identity\n- And OAuth is used to authorize both app and user\n- When an App requests a RESTful Query to retrieve Resources(s) for a given single Patient\n- When policy indicates success with an empty bundle should be returned\n- Then an AuditEvent following this profile is recorded for the requested given Patient\n\nmultiple patient results are returned. Note that 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.\n- Given Resource(s) are known associated with multiple subjects \n- And OAuth is used to authorize both app and user\n- When an App requests a RESTful Query to retrieve Resource(s) \n- And when the query resulting search set contains Resources associated with more than one Patient\n- Then an AuditEvent following this profile is recorded for the Patient identified in the search set returned\n\nNote: 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.'
package_name: ihe.iti.balp
derivation: constraint
name: PatientQuery
type: AuditEvent
elements:
  entity:
    array: true
    min: 2
    index: 0
    slicing:
      slices:
        patient:
          match: {}
          schema:
            _required: true
            index: 1
            elements:
              what:
                type: Reference
                refers: ['http://hl7.org/fhir/StructureDefinition/Patient']
                index: 2
              type:
                pattern:
                  type: Coding
                  value: {code: '1', system: 'http://terminology.hl7.org/CodeSystem/audit-entity-type', display: Person}
                index: 3
              role:
                pattern:
                  type: Coding
                  value: {code: '1', system: 'http://terminology.hl7.org/CodeSystem/object-role', display: Patient}
                index: 4
            required: [what, type]
package_version: 1.1.0
class: profile
kind: resource
url: https://profiles.ihe.net/ITI/BALP/StructureDefinition/IHE.BasicAudit.PatientQuery
base: https://profiles.ihe.net/ITI/BALP/StructureDefinition/IHE.BasicAudit.Query
version: 1.1.0