You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 /TransactionDefinitionid: report-lab-resultspreCondition:
sql: 'SELECT ... FROM WHERE {{params}}'postCondition:
sql: 'SELECT ... FROM WHERE {{params}}'validation:
json-schema, matcho, sql engines, fhirpathtransformation:
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:
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.
This discussion was converted from issue #242 on January 21, 2022 10:24.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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:
POST /
- hard to manage access controlDraft
User will be able to define
NamedTransaction
with meta-resource providing custom validation, pre and post conditions and dedicated REST endpoint: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:
So validation can be simplified by addressing parts of the transaction with names:
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.
Beta Was this translation helpful? Give feedback.
All reactions