Differences

This shows you the differences between two versions of the page.

--- en:dev:modules:core:draft [2017/10/24 23:57] – [User management] nerdoc
+++ en:dev:modules:core:draft [2018/07/22 19:19] (current) – move datapacks into own module nerdoc
@@ Line 90: / Line 90: @@
   * State/Countries/Cities (if entered in the first place) should be auto-completed by a drop-down field.
-All of these database tables should be updatable via [[#DataPacks]]. An update should not destroy user-changed values - ideally show differences and keep the use values per default. Each object therefore has to have a ''user-modified'' flag - or better: a separate table should be created with user-modified content, and it must be possible for the user to set a ''override'' flag - so he wants to have "his" version asvalid, not the "global one from a datapack".
+All of these database tables should be upgradable via [[en:dev:modules:datapacks]]. An update should not destroy user-changed values - ideally show differences and keep the use values per default. Each object therefore has to have a ''user-modified'' flag - or better: a separate table should be created with user-modified content, and it must be possible for the user to set a ''override'' flag - so he wants to have "his" version asvalid, not the "global one from a datapack".
 Considerations: it should be possible for other modules to //add// some master data groups, because the core module cannot/must not know about e.g. financial data, diagnoses etc. - these should be registered at module installation by the specific module itself. So the datapack system should be very flexible.
-==== DataPacks ====
-Provides a central format for downloading/updating data (ICD-10 diagnoses, insurance "positions", banks, doctors, insurances, ZIP codes, etc.). It should be a "meta format", so that other modules can use it for their purposes. XML or JSON should be considered.
-E.g. as source for ZIP codes, countries, cities etc. could be taken geonames.org which provides an excellent web api with XML output.
+==== Audits ====
-A possible datapack could be e.g.:
+Every action that any module takes must have an audit trail. The core module should provide a central API for logging actions, and log actions automatically wherever possible.
-  Datapack {
+This could be either implemented as a simple function like:
-    uid: „5c87644a-5082-426c-ae4a-39e4a245ecf9“
-    label: „zipcodes“
-    description: „ZIP codes for Austria“
-    license: „CC-BY-SA“
-    version: „1.0“
-    created: „2014-03-02 23:10:24“
-    lastUpdated: „2014-03-02 23:10:24“
-    resource: „medux.masterdata.zipcodes“
-    data: {
-      {5020, „Salzburg“},
-      {8010, „Graz“}
-      // ...
-    }
-  }
-The format should be able to handle diffs, so that incremental updates are possible to reduce download and database update time:
+''  medux.core.audit.auditLog(user, action)''
-  DataPackDiff {
-    uid: "f474ed62-8b6c-4758-8f13-b4376d104bf2"
-    datapackUid: "5c87644a-5082-426c-ae4a-39e4a245ecf9“  //refers to original DataPack
-    label: „zipcodes update 2014-04“
-    description: „ZIP codes for Austria - April 2014 update“
-    license: „CC-BY-SA“
-    version: „1.0“
-    created: „2014-04-01 20:12:13“
-    lastUpdated: „2014-04-01 20:12:13“
-    resource: „medux.masterdata.zipcodes“
-    addedData: {
-      {8020, „Graz“}
-    }
-    changedData: {}
-    deletedData {
-      {"5020", "Salzburg"}
-    }
-  }
-Consider: Strings in datapacks should be translateable:
-  * separate files per language
-  * add .po files
-  * add languages in one JSON/XML DataPack
-  *
-==== Audit ====
-Every action that any module takes must have an audit trail. The core module should provide a central API for logging actions, and log actions automatically wherever possible.
-This could be a simple function like:
-  medux.core.audit.auditLog(user, action)
 A timestamp should be added automatically.
-Considerations: move to own module - IMHO not recommended as it should be a real //core// functionality that cannot be switched off.
+This should happen on the server. The client (CAVE: open source!) should have no influence on audit trails - and must not be able to switch them off or bypass them.
+FIXME: Considerations: move to own module - IMHO not recommended as it should be a real //core// functionality that cannot be switched off.
 ==== CAVE entries ====
-The CAVE entry functionality should be provided by the core module, as it is mandatory for all patients. It must somehow work together with the diagnoses module - this could be done by the diagnoses module itself, as the core module does not know anything about "diagnoses".
+The CAVE entry functionality should be provided by the core module, as it is mandatory for all patients.
   * Allergies
   * Intolerances
-There are some data to add to the Cave objects:
+There are some data to add to the CAVE objects:
   * Evidence of the data:
     * patient told us he has an allergy
@@ Line 160: / Line 119: @@
   * Last updated state (timestamp)
-Considerations: does the //core// module really need to know about allergies?? Doesn't fit that better into the diagnoses module?
+FIXME: Considerations: does the //core// module really need to know about allergies?? Doesn't fit that better into the diagnoses module?
 ==== Substance abuse ====
 Another issue to be discussed whether it should be in Core or in [[en:dev:modules:diagnoses|Diagnoses]] is *Substance abuse*, be it alcohol, nicotine, or other drugs. It should be easily possible to enter e.g. PackYears of nicotine abuse, without the hassle of entering exact dates.
-==== Tools ====
+===== Tools =====
 ==== Merge Patients ====
 It must be able to merge patients. This functionality must expose a plugin API for other modules that need to merge data as well.