- Transaction is designed to create resources in e-Health.
- 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 _id inside.
- All resources are saved to DB separately , but saved all together and in the data storage, as the are signed with one DSthere is no rout to get or update transactionsaddition 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.
Transaction validations
- Validate access_token
- Validate scope
- validate DS;
- 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:
| Child pages (Children Display) |
|---|
| 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. |