Differences

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

--- en:dev:modules:core:draft [2016/01/12 01:20] – [CAVE entries] allergies update nerdoc
+++ en:dev:modules:core:draft [2018/07/22 19:19] (current) – move datapacks into own module nerdoc
@@ Line 1: / Line 1: @@
-The core module handles everything that is needed for accessing patient's data, managing users, groups and permissions, and providing an API for
+===== Core Module Draft =====
+==== Settings API ====
-====== Settings API ======
 The Core module provides an API for other modules to register their settings (during the module installation routine).
 Settings can have different levels:
-  * global
+  * global (defaults)
   * client specific (e.g. only client "Dr.Hyde")
   * role specific (e.g. only doctors)
@@ Line 12: / Line 11: @@
 To consider: which setting should have higher priority: user, global or group? permission or deny?
-====== User management ======
+==== Patients ====
-possibly in own module?
-===== ACL system =====
+  * To manage Patient identities, Gnumed has a [[http://publicdb.gnumed.de/~ncq/gnumed/schema/release/gnumed-entire_schema.html#dem.table.identity|very good statement]] here. MedUX should provide a **Portable Unique Person Identification Code**, a char(24) field, as seen in the [[http://wiki.gnumed.de/bin/view/Gnumed/PatientIdentity|Gnumed Patient ID talks]] for all patients.
+  * DOB (date of birth)
+  * COB (country of birth, 2 character ISO code)
+  * gender
+  * DOD (date of death/decease)
+  * title
+  * emergency_contact + link to another person
+==== User management ====
+FIXME in own module?
+==== ACL system ====
 MedUX must have ''client'' support. A ''client'' e.g. is a doctor in a team practice - he could have some doctors working for him "under his supervision", each having their own user logins. A user can work under more than one clients.
   * Client A (Practice Dr.Jekyll)
@@ Line 29: / Line 38: @@
 Mind that ''Practice helper 1'' is working under both clients. This must be possible in the ACL system. So a login always must be: client, username, password.
-It must be possible that single patients (VIP, relatives, etc.) can be "protected" for certain user groups.
+It must be possible that single patients (VIP, relatives, etc.) can be "protected" for certain user groups, so that only that group has access to their data.
 Fast user switching must be possible, without having to restart the whole application (Fingerprint, Card reader, RFID, etc.)
-Objects should be: ''User'', ''Group'', ''Role'', ''Permission'', ''Object''
+Objects should be: ''User'', ''Group'', ''Role'', ''Permission'', ''Object'', where ''Object'' in most cases will match either a database table, or (better) a row.
-===== Plugin permissions =====
+==== Plugin permissions ====
 We could implement a "plugin perission system", like the one used in Android, but which gets the permissions automatically.
@@ Line 50: / Line 59: @@
 The permission should be checked automatically by the plugin system, and must not be interferred with custom code during the plugin hook call. If the current user has no grant for a specific permission, the Interface/ExtensionPoint checks that and does not load the implementations.
-==== Links ====
+=== Links ===
   * Role Based Access Control (RBAC): [[http://de.wikipedia.org/wiki/Role_Based_Access_Control]]
   * Context Based Access Control: [[http://yet-another-dev.blogspot.co.at/2009/11/is-role-based-access-control-dead.html]]
-====== Master data management ======
+==== Master data management ====
 MedUX Core should provide easy access to central data that is used widely in the application.
 Generic master data:
   * Patients
-  * Doctors (für referrals)
+  * Doctors (for referrals)
   * Hospitals
   * Hospital departments
   * Laboratories
-  * Insurances: GKK, BVA, SVA etc. ([[en:dev:modules:accounting:draft|-> Accounting module?]])
+  * Insurances: GKK, BVA, SVA etc. ([[en:dev:modules:accounting|-> Accounting module?]])
-  * Insurance groups: employed, self-employed, unemployed, retired, etc. ([[en:dev:modules:accounting:draft|-> Accounting module?]])
+  * Insurance groups: employed, self-employed, unemployed, retired, etc. ([[en:dev:modules:accounting|-> Accounting module?]])
   * Companies (Pharma, Medical industry contacts for deliveries, etc.)
   * (Private persons)
@@ Line 70: / Line 80: @@
 === Helpers ===
 There should be database tables for auto-suggestions or auto-fill functionality:
-  * States
+  * States/Countries <-> Languages
-  * Countries
+  * ZIP codes <-> Cities
-  * Cities
+  * Given names -> sex
-  * ZIP codes <-> cities
+  * sex -> salutation
-  * Given names <-> sex
-  * sex <-> salutation (really a db table needed?)
-  * Languages
-E.g. if a new patient is created, and "Andreas" is entered as ''first name'', ''sex'' should be auto-filled to ''male''.
+E.g.:
+  * if a new patient is created, and "Andreas" is entered as ''first name'', ''sex'' should be auto-filled to ''male'', and "Mr" should be suggested as salutation.
+  * If "5020" is entered as ZIP code, "Salzburg" should be auto-filled as City (and vice versa!)
+  * 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 updateable 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.
+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.
+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 fownloading/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.
-A possible datapack could be e.g.:
-  Datapack {
-    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:
+==== Audits ====
-  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:
+This could be either implemented as a simple function like:
-  medux.core.audit.auditLog(user, action)
+''  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 ======
+==== 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 148: / 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?
-====== Tools ======
+==== 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 =====
 ==== 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.