Named transactions #242
Description
Current FHIR/Aidbox transaction endpoint is just bulk API call.
This proposal is about new configurable transactions to capture app business logic.
Motivation
Sometimes application business operations cross the resource border and affect multiple resources.
FHIR/Aidbox provides transaction/batch endpoint to do multiple operations in one request. Problems:
- use one endpoint
POST /- hard to manage access control - Hard to do custom validation for specific operations
- Has semantic of batch REST, not batch data manipulation
Draft
User will be able to define NamedTransaction with meta-resource providing custom validation, pre and post conditions and dedicated REST endpoint:
POST /TransactionDefinition
id: report-lab-results
preCondition:
sql: 'SELECT ... FROM WHERE {{params}}'
postCondition:
sql: 'SELECT ... FROM WHERE {{params}}'
validation:
json-schema, matcho, sql engines, fhirpath
transformation:
jute, clj, ...
schema:
elements:
patient:
provider:
....CRUD in NamedTransaction does not go thro AccessPolicy checks, but expect separate access policy for the transaction.
This makes possible change resources by users, who do not have direct permissions and can be useful for complicated business operations, not fitting CRUD.
To easy address parts of transaction bundle, we can decline from FHIR Bundle resource and make it more (custom) structured:
POST /transactions/report-lab-results
patient: { resourceType: 'Patient' .....}
provider: { resourceType: 'PractitonerRole' ......}
order: { resourceType: 'ServiceRequest', ......}
results: [ Observations .... ]
So validation can be simplified by addressing parts of the transaction with names:
.provider.identifier is required
.results are not empty
Be dry with transformations. For example, linking resources in the same operation - like set the patient reference for all result observations on the server-side.