• Basic Patient database: name, sex, DOB, social insurance number
• Basic antropometrics over time: size, weight, blood pressure
• Laboratory work: parameters, normal ranges, plausibility ranges, time lines
• Medication handling: drug intake plans, drug prescribing & printing
• Form handling: printing of forms (lab, letter of referral, patient anamnesis forms etc.)
• Accounting: Ledger
• Data access auditing: every database access must be logged: user, access target, timestamp, action.
• Fast user switching
• Deleting ob DB objects must be a “soft deleting”, see e.g. SoftDeletionModel

• Intercommunication with encrypted XMPP/OTR, Qabel, etc.
• Maybe patient data sending as well with that?
• Access to online-documentation: EBM-Guidelines, Arzneitelegamm, Scientific papers etc.
• Management of material logistics (“Ordinationsbedarf”)
• Drug interaction checks
• ICD10/ICPC2 database checking
• Accounting: Cash register (Austrian “Registrierkasse”)
• Social insurance communications:
• e.g. Austrian eCard interface
• Social insurance billing management
• Patient should have a primary, “named doctor” (which can be changed over time). This doctor e.g. gets the external findings in his list to read.
• Referrals should open a “circle” that can be closed by a sent finding.

• There is a nice work done by Graham Walker, how an EMR could look like. I like that: http://healthee.site44.com/home.html

An older, but well-written overview is here: http://www.pythoncentral.io/sqlalchemy-vs-orms

This post says that SQLAlchemy seems to be sluggish and overcomplicated, and prefers Storm or GeniuSQL.

Question is, wether an ORM is wanted/needed anyway or if it would be better to directly access the DB from the server/middleware. The only way *I* can think of implementing a RBAC is using an ORM/ODM - or at least a web interface (REST?) which separates the database (and server side business logic) from the client. Especially in Open Source software this is a must: If the implementation of the RBAC is on the client side, noone can ensure that there has not been tampered with the client code.

• Postgresql
• SQL-Alchemy - well-established, DB agnostic Object Relational Mapper
• SQL-Alchemy-Continuum - versioning for SQL-Alchemy
• Storm - easy, fast, but seems to have problems with object inheritance, only managable through a “workaround”
• peewee

• PyMongo - Python bindings for MongoDB (see the MongoDB Qt data model)
• MongoEngine - “ORM” for MongoDB. Maps Python objects to MongoDB documents. Seems a good one to me.
• MotorEngine - MongoEngine Port with non-blocking/asynchronous operations using tornado
• MongoAlchemy - looks nice, and mimics the SQLAlchemy API
• MongoKit - nice, but supposed dead.
• RethinkDB - JSON database with builtin “reactiveness”
• CouchDB - good at offline replication - maybe useable for mobile devices on a patient visit
• CrateDB - extremely fast and scalable object database, but accessible using SQL; Uses Elasticsearch for fulltext searching.
• Riak

• Django, maybe using django-ddp or django-rest-framework or Apollo
• Meteor

• Crossbar.io / Autobahn
• Tornado
• Nameko
• gRPC
• Pyro4
• ICE
• ZeroRPC
• ZeroMQ (ØMQ)
• Oslo.messaging (von OpenStack)

• Native clients
  • Qt5, LGPL and Commercial License, C++/QML - really excellent framework, very good Python bindings:
    • PyQt5: mature, GPLv3/commercial license.
    • QtQuick - maybe we think about it. Using with Python is not that mature.
    • PySide: Dead. Not really an option, as last code update was in 2012
    • PySide2: Seems to be actively developed again by The Qt Company - maybe another option instead of PyQt5
  • Kivy - seems to be nice for games/2d stuff; but DB driven UI? …not.
• Web clients (also possible on desktop using Electron
  • AngularJs, by Google, MIT License
  • ExtJs, GPLv3 and Commercial License
  • Meteor/Blaze, MIT License

Sphinx

As MedUX needs to be completely modular, we need a plugin framework that has some capabilities:

• it must be easy to understand and use
• it must be maintained. It must be a framework that will not vanish in half a year.
• it must be thread safe: Direct calls are not very nice when trying to make a responsive UI. Ideally based on a loosely-coupled signal/slot mechanism like the one in Qt.
• it should work with PyQt

I have had a glance on many frameworks out there. A good overview is here. I'll leave out all the ones that do not fit here and just list the ones that are taken into consideration for MedUX:

• Yapsy
• PyUtilib - I would use just the plugin framework core. Documentation of the “Component Architecture” is here
• Pluginbase - stability??