Next week work

All: work towards the proof of concept on the following part of the model: Patient, Patient_identifier, Patient_address, Concept, Obs, Concept_type

Julie:

• try the serialization mechanism for the proof-of-concept tables what changes are needed
• what are the perf considerations/implications? compare object vs. record level data serialization and access

Anders:

• global ordering of timestaps: review lit and come up with a way to do this (http://en.wikipedia.org/wiki/Lamport_timestamps)

Christian:

• de-id the Rwanda DB and send it/post it for us to load
• model the DB changes needed for the 'history' tables and timestamps

Maros:

• work through the sync alg and address any issues/inconsistencies
• update wiki: we want to use wiki as main place for sharing info amongst us
• follow-up on the 'Conflict resolution/notification clinical requirements' (see bellow): get more feedback from PIH, Burke/Paul, implementers forum if needed

Other discussion points

Table history mechanism and ordered timestamps

• start with separate xxx_audit/history table

Julie and system setup:

• doesn't have encounters and obs, same with forms
• needs to load form entry modules – see wiki modules documentation

Test data and system setup:

• it would be very useful to have 'real' data beyond demo DB
• Christian has data from Rwanda and has ability to de-id it; let's use this for our testing

Three general connectivity use cases based on Christian's experience:

1. strong connection: may be fast/slow but it is readily available

1. intermittent connectivity

1. very intermittent: laptop: daily entry and then comes back to home base

• USB key for transferring data
  • ideally our sync solution would work with this just as well: if we abstract the transport protocol right, this should be easily accomplished

Timestamp synchronization:

• what is the mechanism?
• We can start with simple: each child keeps track of its own clock, when hand-shake occurs child syncs up the clock with parent and then adjusts local entries accordingly
  • what are the end-cases and assumptions? document
  • review available lit. (i.e. Lamport logical clock)

Pull/Push vs. Push/Pull

• Julie/Maros: would like to change to Push/Pull, rationale:
• if there is an issue with connectivity; I want first and foremost get the local data off to parent as parent is a 'master' thus the transfer of child's changeset to the parent (where it can be available for backup, reviews, etc.) is deemed of primary concern
• everyone: seems OK, for now this is a hypothesis

Conflict resolution/notification clinical requirements:

• if we have 'history' records timestamped the actual record-level conflicts may not exist at all, however what is the expected notification/action when changes to the same record occur independently? (see Julie's notes and Maros email for more detail)
• consensus: ability to display "this-is-what-changed-since-you-last-sync-ed" is fundamentally needed
• we need/want to get more validation on this from others with clinical experience

Changesets/DB access:

• do we treat this on 'object' level or do we go down to the record level
• considerations: speed, flexibility, ability to co display/relate record-level changes to users in context of the domain model (i.e . the changelog should be presented in context of user display;not just name/value pairs)
• how should xxx_history tables be represented in the object model?

Design constraints/assumptions

1. Sync is the user-initiated

• for now that is OK
• eventually we want it to be automated: in Rwanda, we are looking for eventual country-wide deployment
  • the servers should kept 'themselves' up to date...
  • what are the challenges of the universal country-wide coverage?

2. Given child server has only one and always the same parent

• OK, we will have

3. multi-tiered topology

• OK to be a tree; not a graph

4. Given patient 'belongs' to a single and always the same parent: a patient may be only served by children nodes that have the same parent

• this is probably OK as initial 'Phase 1' assumption
• however it will have to be relaxed for full country implementation: a patient may be refered to a central 'specialty' clinic outside of the patient's 'normal' parent server: patient's records must be available @ the center
  • perhaps contextual replication ca be used to solve this scenario (i.e. all clinics have their 'normal' set of patients based on location hierarchy for example, in addition all nodes have ability to search the whole network and then 'sync' patient data on demand)
• related to this: how do we reliably ID patient at clinic? Why not just finger-print? Christian's experience with finger-printing:
  • well at single site; a matter of scale - how fast/slow can the lookup be?
  • Resource poor countries: manual labor & fingerprint scanner reliability...
  • should be looked into but certainly not in scope for this project in this phase