- 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.
- All the resources inside transaction bundle and transaction bundle itself should have meta.profile specified. Validation of the resources against SD (VASD) module uses the SD specified in meta.profile for validation.
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. |
| 6. | For each resource created in transaction should we have the metadata of the transaction it was created by (like the id of the transaction)? Should we persist the original transaction in this case? | |
| 7. | Should we post the transaction to the root endpoint as the spec suggests? | |
| 8. | Should we return OperationOutcome in case of failure as the spec suggests? | |
| 9. | Should episode be created with transaction or by itself w/o DS (as it is)? | should be create without transaction. (18.11.2019) |
| 10. | There is a connection of observation with diagnostic report in eHealth, Ukraine though diagnostic_report reference. While there is no such field in fhir, should we implement it in the new observation with SD validation? | No, we'll use partOf reference, instead (21.11.2019) |
| 11. | What should we do with the Visit? | Possible solution would be to use special type of Encounter (i.e. define a profile) for an administrative encounter that is equal to visit. Encounters with the clinical meaning (reasons, diagnosis, etc.) should then reference the administrative encounter in their partOf property. To be confirmed, not decided yet. |