iCure. eHealth Solutions
  • Developer Documentation
  • iCure Software Modules
  • Get Started
    • Create your own Database
      • Receive an invitation
      • Create new User
      • Create a new Healthcare Party
    • Structure your Database
    • Access your database
    • Use the Console
  • Data Stack Module
    • The Data Stack
      • Install iCure
      • Get Started with a Database
    • iCure Data Model
      • Overview
      • User
        • Permission
      • Healthcare Party
      • Patient
        • Insurability
        • Relationship
        • Patient Hcp care period
          • Referral period
      • Contact
        • Service
          • Content
            • Medication
              • Regimen item
            • Measure
        • SubContact
      • Healthcare Element
        • Care team member
        • Healthcare approach
      • Form
      • Additional Classes
        • AccessLog
        • Address
          • Telecom
        • Message
        • Document
        • FilterChain
          • Filter
          • Predicate
        • Group
        • Insurance
        • Invoice
          • Invoicing code
        • Tarification
          • Valorisation
    • Hybrid Cloud Storage
    • Mobile/Web SDKs
      • JavaScript/Typescript
        • Setting up your environment
        • Logging in
        • Managing patients
        • iCure for MedTech: Getting Started
          • Exchange data using FHIR model
          • Exchange data using iCure SDK
      • Java/Kotlin
      • Swift/Objective C
    • REST API calls
      • User
      • Patient
      • HealthcareParty
      • Contact
      • HealthcareElement
      • Form
      • Document
      • Message
      • Invoice
      • Additional endpoints
        • AccessLog
        • Authentication
        • Codification
        • Document template
        • Entity reference
        • Entity template
        • Insurance
        • Receipt
        • Tarification
    • Access Rights management
    • End-to-End-Encryption
    • ATNA Audit Records
  • Interoperability Module
    • IHE XDS calls
      • The XDS Concept
      • ITI-18 get associations api call
      • ITI-41 provide and register document set api call
      • Iti-42 register document set api call
    • IHE IPS call
      • The IPS Concept
    • FHIR API Data Exchange
      • The FHIR Concept
    • Freehealth Connector 🇧🇪
    • Encrypted Data Exchange
      • Internal
      • External
  • Customizable Features Module
    • Input Forms
    • Medical Records
    • Data Dashboards
    • Custom Connectors
    • Secure Log-in App
  • Support
    • Download
    • Contact Us
  • Advanced topics
    • Healthcare Data
      • Business intelligence
      • Anonymized Data
    • Encryption Key Creation and Storage
    • Multi-Master database replication
    • Cross Databases Sharing
    • Complex queries
Powered by GitBook
On this page

Was this helpful?

  1. Data Stack Module
  2. iCure Data Model
  3. Additional Classes

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

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.

PreviousInsuranceNextInvoicing code

Last updated 3 years ago

Was this helpful?

String
String
Long
Long
String
String
String
List
List
Long
Long
Long
Long
Long
List
Map
String
String
String
String
String
String
String
String
String
String
String
String
Double
List
String
String
String
String
String
Integer
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
Integer
Integer
String
String
Boolean
String
IdentityDocumentReader
String
Long
Map
List
Map
Map
Map
String