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
id *
The Id of the Invoice. We encourage using either a v4 UUID or a HL7 Id.
rev
The revision of the invoice in the database, used for conflict management / optimistic locking.
created
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.
modified
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.
author
The id of the User that has created this entity, will be filled automatically if missing. Not enforced by the application server.
responsible
The id of the HealthcareParty that is responsible for this entity, will be filled automatically if missing. Not enforced by the application server.
medicalLocationId
The id of the medical location where this entity was created.
tags *
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.
codes *
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
endOfLife
Soft delete (unix epoch in ms) timestamp of the object. format: int64.
deletionDate
hard delete (unix epoch in ms) timestamp of the object. Filled automatically when deletePatient is called. format: int64.
invoiceDate
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.
sentDate
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.
printedDate
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.
invoicingCodes *
receipts *
recipientType
The type of user that receives the invoice, a patient or a healthcare party
recipientId
Id of the recipient of the invoice. For healthcare party and insurance, patient link happens through secretForeignKeys
invoiceReference
thirdPartyReference
thirdPartyPaymentJustification
thirdPartyPaymentReason
reason
invoiceType
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
sentMediumType
Medium of the invoice: CD ROM, Email, paper, etc. Values: cdrom, eattest, efact, email, mediprima, paper
interventionType
Values: total, userfees
groupId
paymentType
Type of payment, ex: cash, wired, insurance, debit card, etc. Values: cash, wired, insurance, creditcard, debitcard, paypal, bitcoin, other
paid
format: double.
payments
gnotionNihii
gnotionSsin
gnotionLastName
gnotionFirstName
gnotionCdHcParty
invoicePeriod
format: int32.
careProviderType
internshipNihii
internshipSsin
internshipLastName
internshipFirstName
internshipCdHcParty
internshipCbe
supervisorNihii
supervisorSsin
supervisorLastName
supervisorFirstName
supervisorCdHcParty
supervisorCbe
error
encounterLocationName
encounterLocationNihii
encounterLocationNorm
format: int32.
longDelayJustification
format: int32.
correctiveInvoiceId
correctedInvoiceId
creditNote
creditNoteRelatedInvoiceId
idDocument
cancelReason
cancelDate
format: int64.
options *
secretForeignKeys *
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.
cryptedForeignKeys *
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.
delegations *
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
encryptionKeys *
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
encryptedSelf
The base64 encoded data of this object, formatted as JSON and encrypted in AES using the random master key from encryptionKeys.
Last updated