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
  • iCure Online/Offline update mode
  • Data Synchronization in iCure
  • Data integrity

Was this helpful?

  1. Advanced topics

Multi-Master database replication

PreviousEncryption Key Creation and StorageNextCross Databases Sharing

Last updated 3 years ago

Was this helpful?

iCure Database is built on Apache CouchDB a web enabled database optimized for use over a network with multiple users, oriented at massively distributed systems with heavy usage that handle "Big Data".

iCure Online/Offline update mode

CouchDB does not store data in a table along with relationships, but uses a B-Tree instead. Each database in every user device is a collection of independent documents that maintain their own data and self-contained schemas. Document metadata contains revision information, so that differences happening while databases were disconnected, may be merged. CouchDB impelements its own version of a Multiversion Concurency Controll system, that supports .

This enables the iCure to implement a fully . Files are not locked during update and they can be updated both online and offline, allowing the iCure to implement a conflict resolution method.

Data Synchronization in iCure

Under normal conditions database synchronization between connected databases take place in less that 300ms.

Data integrity

CAP Theorem dictates that Databases can be optimized for two of the three most requested qualities: Consistency, Availability and Partition Tolerance. While CouchDB has been optimized for Partition Tolerance and Availability, it has the ability to provide local consistency at local databases and through incremental replication eventual consistency in the iCure database.

Other features include document-level semantics with , (incremental) MapReduce, and (incremental) replication.

The has been designed so that it is agnostic to higher level Medical Data conceptual Data Models such as Open EHR and FHIR. It does however make some basic assumptions over the nature of the data, that are to be utilized for. That is in line with the selection of CouchDb. In a healthcare setup one might expect that there are several encryption perimeters and distributed systems, that are to some extend experiencing aberrant disconnections.

ACID
eventual consistency
iCure Data Model
Master-Master replication
Hybrid Cloud Storage
Locking vs "No-Locking" database files during transactions. Source: CouchDb.org
CouchDB vs the CAP Theorem. Source: CouchDb.org
Incremental Replication leads to consistency between Db Nodes Source: CouchDb.org