MedUX

OpenSource EMR

User Tools

Site Tools

Trace:
en:dev:modules:core

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 [2017/10/13 23:39] – [Description] deleted half sentence nerdocen:dev:modules:core [2018/07/29 10:16] (current) – ==== User stories ==== nerdoc
Line 1: Line 1:
 ====== Core module ====== ====== Core module ======
 ===== Description ===== ===== Description =====
-The core module handles everything that is needed for accessing patient's data, managing users, groups and permissions.+The core module handles everything that is needed for accessing patient's data, managing users, groups and permissions, and a API for saving and reading settings. 
 +It keeps a versioning scheme that directs all other modules so they can depend on "Medux Core version 2.0" to have a consistent API structure.
  
-==== Settings API ==== +Have a look at the [[en:dev:modules:core:draft|Draft]] page to see the current ideas.
-The Core module provides an API for other modules to register their settings (during the module installation routine). +
-Settings can have different levels: +
-  * global +
-  * client specific (e.g. only client "Dr.Hyde") +
-  * role specific (e.g. only doctors) +
-  * user specific (e.g. only user "alice") +
-  * device specific (e.g. a certain computer)+
  
-To consider: which setting should have higher priority: user, global or group? permission or deny? +==== User stories ====
- +
-==== User management ==== +
-possibly 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) +
-    * Dr.Jekyll +
-    * Nurse 1 +
-    * Practice helper 1 +
-    * Practice helper 2 +
-  * Client B (Practice Dr.Hyde) +
-    * Dr.Hyde +
-    * Nurse 2 +
-    * Practice helper 1 +
- +
-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. +
- +
-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'' +
- +
-==== 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]] +
-  * Context Based Access Control: [[http://yet-another-dev.blogspot.co.at/2009/11/is-role-based-access-control-dead.html]] +
- +
-==== 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) +
-  * Hospitals +
-  * Hospital departments +
-  * Laboratories +
-  * Insurances: GKK, BVA, SVA etc. ([[en:dev:modules:accounting|-> 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) +
- +
-=== Helpers === +
-There should be database tables for auto-suggestions or auto-fill functionality: +
-  * States +
-  * Countries +
-  * Cities +
-  * ZIP codes <-> cities +
-  * 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''. +
- +
-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. +
- +
-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. +
- +
-==== 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. +
-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: +
-  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. +
- +
-==== 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". +
-  * Allergies +
-  * Intolerances +
- +
-There are some data to add to the Cave objects: +
-  * Evidence of the data: +
-    * patient told us he has an allergy +
-    * we have a medical report with a confirmed allergy +
-  * Last updated state (timestamp) +
- +
-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 ==== +
-It must be able to merge patients. This functionality must expose a plugin API for other modules that need to merge data as well.+
  
 ===== Links ===== ===== Links =====
en/dev/modules/core.1507930764.txt.gz · Last modified: 2017/10/13 23:39 by nerdoc