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 [2017/10/25 00:02] – tools headline bigger 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. +==== Audits ====
- +
-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 +
-==== 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 either implemented as a simple function like:  This could be either implemented as a simple function like: 
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.1508882536.txt.gz · Last modified: 2017/10/25 00:02 by nerdoc