Requirements/use cases for the network module
Quick notes, feel free to elaborate.
Present: Ola, Kristian, Woinshet, Kristoffer, Hans.
The usage of this module, in relation to Import-Export, depends on the stability and strength of the network connection.
- If we have a strong network:
- Would we always do data entry and similar directly to a centralized server?
- Would we still do entry locally and use the network module to upload the data?
- If we have a bad network, file I-E is necessary anyway.
- What if the network connection fails at some point?
- Network module as a redundancy system. Synchronizes data on local and central servers.
- Must sent exports be accepted before it is imported into the receiving system?
- A Windows Update-functionality: Does the server or the client notify the other?
The uniqueness discussion
Quick notes, feel free to elaborate.
Present: Ola, Kristian, Woinshet, Kristoffer, Hans.
We discussed how to ensure unique ids in metadata across different org units.
An idea was to require that org unit ids were unique, and then use that as part of the ids for everything else. Every object would have a global id in addition to the existing id column. The new global id would only be used when importing and exporting data. Assuming that the org unit id is unique, we can use it as part of the orther metadata ids: Assume an org unit with id 1, with two children 2 and 3. Data elements defined by 1 would have global ids 1.1,1.2,...,1.n, data elements defined by org unit 2 would have global ids 2.1,2.2,...,2.n, etc.
There are problems with this solution: The most important is that new org units would have to be approved and given a unique id from the top level org unit. One could do this by e-mail or by a request sent through the system. How to handle breakdowns in this communication?
- What about temporary org units, or units that need to be created fast? An example is a mobile vaccine unit. (Kristian)
- Some org units in some countries don't know what happens below their immediate children. (Kristoffer)
- If all new global ids are unique, we don't need an additional local id column anymore. Global id == local id. (Hans)
- We need to allow for a test/correct phase when creating a new org unit hierarchy, cf Cuba. (Ola)
- Data type of the global id? String? Decimal? Using the decimal point as a separator? Do we ever need to check this?
- Other ways of ensuring unique ids?
- Most new org units are predictable: We know we're building a hospital, and can create the corresponding org unit before data capture is possible.
