The Core module provides an API for other modules to register their settings (during the module installation routine). Settings can have different levels:

• global (defaults)
• 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?

• To manage Patient identities, Gnumed has a very good statement here. MedUX should provide a Portable Unique Person Identification Code, a char(24) field, as seen in the 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

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, 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.)

Objects should be: User, Group, Role, Permission, Object, where Object in most cases will match either a database table, or (better) a row.

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.

• 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 (for 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 ↔ Languages
• ZIP codes ↔ Cities
• Given names → sex
• sex → salutation

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 upgradable 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”.

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.

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:

medux.core.audit.auditLog(user, action)

A timestamp should be added automatically.

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.

: 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.

• 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?

Another issue to be discussed whether it should be in Core or in 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.

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