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”)
• group 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?

possibly in own module?

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

• 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

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. (-> Accounting module?)
• Insurance groups: employed, self-employed, unemployed, retired, etc. (-> Accounting module?)
• Companies (Pharma, Medical industry contacts for deliveries, etc.)
• (Private persons)

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.

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:

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

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.

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

Considerations: does the core module really need to know about allergies?? Doesn't fit that better into the diagnoses module?

It must be able to merge patients. This functionality must expose a plugin API for other modules that need to merge data as well.