Invoice
This entity is a root level object. It represents an Invoice. It is serialized in JSON and saved in the underlying iCure CouchDB database.
Properties
Property | Type | Description |
---|---|---|
| The Id of the Invoice. We encourage using either a v4 UUID or a HL7 Id. | |
| The revision of the invoice in the database, used for conflict management / optimistic locking. | |
| The timestamp (unix epoch in ms) of creation of this entity, will be filled automatically if missing. Not enforced by the application server. format: int64. | |
| The date (unix epoch in ms) of the latest modification of this entity, will be filled automatically if missing. Not enforced by the application server. format: int64. | |
| The id of the User that has created this entity, will be filled automatically if missing. Not enforced by the application server. | |
| The id of the HealthcareParty that is responsible for this entity, will be filled automatically if missing. Not enforced by the application server. | |
| The id of the medical location where this entity was created. | |
| A tag is an item from a codification system that qualifies an entity as being member of a certain class, whatever the value it might have taken. If the tag qualifies the content of a field, it means that whatever the content of the field, the tag will always apply. For example, the label of a field is qualified using a tag. LOINC is a codification system typically used for tags. | |
| A code is an item from a codification system that qualifies the content of this entity. SNOMED-CT, ICPC-2 or ICD-10 codifications systems can be used for codes | |
| Soft delete (unix epoch in ms) timestamp of the object. format: int64. | |
| hard delete (unix epoch in ms) timestamp of the object. Filled automatically when deletePatient is called. format: int64. | |
| The timestamp (unix epoch in ms) when the invoice was drafted, will be filled automatically if missing. Not enforced by the application server. format: int64. | |
| The timestamp (unix epoch in ms) when the invoice was sent, will be filled automatically if missing. Not enforced by the application server. format: int64. | |
| The timestamp (unix epoch in ms) when the invoice is printed, will be filled automatically if missing. Not enforced by the application server. format: int64. | |
| ||
| ||
| The type of user that receives the invoice, a patient or a healthcare party | |
| Id of the recipient of the invoice. For healthcare party and insurance, patient link happens through secretForeignKeys | |
| ||
| ||
| ||
| ||
| ||
| The format the invoice should follow based on the recipient which could be a patient, mutual fund or paying agency such as the CPAS Values: patient, mutualfund, payingagency, insurance, efact, other | |
| Medium of the invoice: CD ROM, Email, paper, etc. Values: cdrom, eattest, efact, email, mediprima, paper | |
| Values: total, userfees | |
| ||
| Type of payment, ex: cash, wired, insurance, debit card, etc. Values: cash, wired, insurance, creditcard, debitcard, paypal, bitcoin, other | |
| format: double. | |
| ||
| ||
| ||
| ||
| ||
| ||
| format: int32. | |
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| format: int32. | |
| format: int32. | |
| ||
| ||
| ||
| ||
| ||
| ||
| format: int64. | |
| ||
| The secretForeignKeys are filled at the to many end of a one to many relationship (for example inside Contact for the Patient -> Contacts relationship). Used when we want to find all contacts for a specific patient. These keys are in clear. You can have several to partition the medical document space. | |
| The secretForeignKeys are filled at the to many end of a one to many relationship (for example inside Contact for the Patient -> Contacts relationship). Used when we want to find the patient for a specific contact. These keys are the encrypted id (using the hcParty key for the delegate) that can be found in clear inside the patient. ids encrypted using the hcParty keys. | |
| When a document is created, the responsible generates a cryptographically random master key (never to be used for something else than referencing from other entities). He/she encrypts it using his own AES exchange key and stores it as a delegation. The responsible is thus always in the delegations as well | |
| When a document needs to be encrypted, the responsible generates a cryptographically random master key (different from the delegation key, never to appear in clear anywhere in the db. He/she encrypts it using his own AES exchange key and stores it as a delegation | |
| The base64 encoded data of this object, formatted as JSON and encrypted in AES using the random master key from encryptionKeys. |
Last updated