- Transaction is designed to create resources in e-Health as a single atomic operation (all or nothing).
- Transactions follow FHIR approach for transactions.
- As for now with the help of transaction could be created all resources that are connected with medical events
- All resources have the reference to patient inside.
- All resources are saved to DB separately and in addition the signed document is stored in a document storage as a whole.
- There is no route to get or update original transaction, but there's a route to get the transaction response.
- Transactions are asynchronous and follow FHIR approach for async processing.
Transaction validations
- Validate access_token;
- Validate scopes. There should be validation for transaction:write and for each resource in the transaction validation should be performed (encounter:write, observation:write, etc.);
- Validate DS.
Validations of:
| Question | Decisions History | |
|---|---|---|
| 1 | Is it allowed for a signed transaction to contain resources produced by other employees (where resource's performer/asserter isn't equal to the given user) | Yes. The transaction is signed by one employee and may contain resources produced by employees from the same legal entity (14.11.2019). |
| 2 | Could transaction consist of resources for different patient or not? | No, currently transaction only support resources for a single patient (14.11.2019). |
| 3 | Is there a limit for resources number in one transaction? | Yes, there should be a limit. The exact amount is TBD (14.11.2019). |
| 4 | Should we persist the person id in the ME DB? | No, it should be a part of a signed content, but shouldn't be persisted. Instead patientId is persisted. |
| 5 | Should only POST methods inside transaction be suppoted? | Yes. |