MedUX

OpenSource EMR

User Tools

Site Tools

Trace: • draft
en:dev:modules:core:draft

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:dev:modules:core:draft [2015/04/24 22:58] – [Settings API] rename group -> role nerdocen: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). The Core module provides an API for other modules to register their settings (during the module installation routine).
 Settings can have different levels: Settings can have different levels:
-  * global+  * global (defaults)
   * client specific (e.g. only client "Dr.Hyde")   * client specific (e.g. only client "Dr.Hyde")
   * role specific (e.g. only doctors)   * 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? 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. 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)   * 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. 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.) 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.
  
-==== Links ====+==== Plugin permissions ==== 
 + 
 +We could implement a "plugin perission system", like the one used in Android, but which gets the permissions automatically. 
 +Therefore the plugin system must be modified so that plugin hooks are only loaded if the right permissions are granted. 
 +Plugins must *register* new permissions (like "patients.add" etc.) they introduce using a function, at their initialisation time, like 
 + 
 +    def initialize(): 
 +      register_permission("patients.add") 
 + 
 +Permissions are defined then in the Interface: 
 + 
 +    def CustomPluginHook(Interface): 
 +      permissions = ["patients.add"] 
 + 
 +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 ===
   * Role Based Access Control (RBAC): [[http://de.wikipedia.org/wiki/Role_Based_Access_Control]]   * 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]]   * 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. MedUX Core should provide easy access to central data that is used widely in the application.
  
 Generic master data: Generic master data:
   * Patients   * Patients
-  * Doctors (für referrals)+  * Doctors (for referrals)
   * Hospitals   * Hospitals
   * Hospital departments   * Hospital departments
   * Laboratories   * 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.)   * Companies (Pharma, Medical industry contacts for deliveries, etc.)
   * (Private persons)   * (Private persons)
Line 55: Line 80:
 === Helpers === === Helpers ===
 There should be database tables for auto-suggestions or auto-fill functionality: 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. 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. 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.
  
-====== CAVE entries ======+FIXME: Considerations: move to own module - IMHO not recommended as it should be a real //core// functionality that cannot be switched off.
  
-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".+==== CAVE entries ==== 
 + 
 +The CAVE entry functionality should be provided by the core module, as it is mandatory for all patients.
   * Allergies   * Allergies
   * Intolerances   * Intolerances
  
-Considerations: does the //core// module really need to know about allergies?? Doesn't fit that better into the diagnoses module? +There are some data to add to the CAVE objects: 
-====== Tools ======+  * Evidence of the data: 
 +    * patient told us he has an allergy 
 +    * we have a medical report with a confirmed allergy 
 +  * Last updated state (timestamp) 
 + 
 +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 =====
 ==== Merge Patients ==== ==== 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. It must be able to merge patients. This functionality must expose a plugin API for other modules that need to merge data as well.
- 
en/dev/modules/core/draft.1429909108.txt.gz · Last modified: 2015/04/24 22:58 by nerdoc