MedUX

OpenSource EMR

User Tools

Site Tools

Trace:
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 [2017/10/25 00:02] – [Audit] s nerdocen: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.   * 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. 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 ==== 
-FIXME This should go into a separate module. 
  
-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 translatable: 
-  * separate files per language 
-  * add .po files 
-  * add languages in one JSON/XML DataPack 
 ==== Audits ==== ==== Audits ====
 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.
Line 155: Line 109:
 ==== 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   * Allergies
   * Intolerances   * 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:   * Evidence of the data:
     * patient told us he has an allergy     * patient told us he has an allergy
Line 165: Line 119:
   * Last updated state (timestamp)   * 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 ==== ==== Substance abuse ====
en/dev/modules/core/draft.1508882558.txt.gz · Last modified: 2017/10/25 00:02 by nerdoc