Brainstorming

• 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, Matrix, 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.
• Communication with other MedUX instances via Internet. Interchange of Patient data. ActivityPub would be an option.

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

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

Within the database there could be some kind of “namespaces”, Gnumed does this in a very clean way:

• dem - demographic data
• clin - all medical data (except documents)
• blobs - documents - could be saved in an external, document-based database
• ref - referenced data
• cfg - configuration data
• audit - the auditing system
• bill - accounting data
• mdx - MedUX-internal data
• i18n/l10n - translation data ?
• tmp - temporal data

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

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

• 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, MIT License
  • ExtJs, GPLv3 and Commercial License
  • Meteor/Blaze, MIT License

Sphinx

This meanwhile is worth an own draft page.

FHIR (pronounced like “fire”) should be an integral part of MedUX from the start. It is an international attempt to consolidate health data of patient data in a structured manner. One possibility could be to create a FHIR implementation using Django, and pointing the frontend (Angular, native?) directly to that REST API.

• SMART-ON-FHIR, by https://smarthealthit.org, a collection of FHIR tools using Js, Swift and Python
  • fhir-parser, a FHIR specparser and Python class generator
  • client-py, a Python FHIR client, for e.g. use on a PyQt5 frontend.
• django-fhir, a Django app with a pluggable backend as FHIR API

All Data regarding lab results should be saved, or at least be interchangeable by the worldwide used LOINC format.