MedUX

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Brainstorming ======

===== Must-Haves =====

  * 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. [[https://medium.com/@adriennedomingus/soft-deletion-in-django-e4882581c340|SoftDeletionModel]]

===== Nice-To-Haves =====

  * 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. [[https://www.w3.org/TR/activitypub/|ActivityPub]] would be an option.

===== Links =====
  * 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: [[https://de.wikipedia.org/wiki/Problemorientierte_Dokumentation|Problemorientierte Dokumentation]] (German)
===== Technical considerations =====

==== Database & DB abstraction ====

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

[[http://www.aminus.org/blogs/index.php/2007/08/18/storm_sqlalchemy_and_geniusql?blog=2|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.

=== SQL ===

  * [[https://postgresql.org|PostgreSQL]]
  * [[http://www.sqlalchemy.org/|SQL-Alchemy]] - well-established, DB agnostic Object Relational Mapper
  * [[https://sqlalchemy-continuum.readthedocs.org/en/latest|SQL-Alchemy-Continuum]] - versioning for SQL-Alchemy
  * [[https://storm.canonical.com|Storm]] - easy, fast, but seems to have problems with object inheritance, only managable through a "workaround"
  * [[https://peewee.readthedocs.org/en/latest|peewee]]

=== NoSQL ===

  * [[http://api.mongodb.org/python/current|PyMongo]] - Python bindings for MongoDB (see the [[https://stackoverflow.com/questions/23860611/pyqt-custom-mongodb-model#23860896|MongoDB Qt data model]])
  * [[http://mongoengine.org|MongoEngine]] - "ORM" for MongoDB. Maps Python objects to MongoDB documents. Seems a good one to me.
  * [[https://motorengine.readthedocs.io/en/latest|MotorEngine]] - MongoEngine Port with non-blocking/asynchronous operations using tornado
  * [[http://www.mongoalchemy.org|MongoAlchemy]] - looks nice, and mimics the SQLAlchemy API
  * [[https://github.com/namlook/mongokit|MongoKit]] - nice, but supposed dead.
  * [[https://www.rethinkdb.com|RethinkDB]] - JSON database with builtin "reactiveness"
  * [[https://couchdb.apache.org|CouchDB]] - good at offline replication - maybe useable for mobile devices on a patient visit
  * [[https://crate.io|CrateDB]] - extremely fast and scalable object database, but accessible using SQL; Uses Elasticsearch for fulltext searching.
  * [[http://basho.com/products/|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

==== Client/Server architecture / Backend ====

  * [[https://www.djangoproject.com/|Django]], maybe using [[https://github.com/jazzband/django-ddp|django-ddp]] or [[http://www.django-rest-framework.org/|django-rest-framework]] or [[https://www.apollodata.com/|Apollo]] with [[http://docs.graphene-python.org/projects/django/en/latest/|graphene]]
  * [[https://www.meteor.com/|Meteor]]

==== Microservices / Communication ====

  * [[https://crossbar.io|Crossbar.io]] / Autobahn
  * [[http://www.tornadoweb.org|Tornado]]
  * [[https://nameko.readthedocs.io/en/stable|Nameko]]
  * [[http://www.grpc.io/docs/quickstart/python.html|gRPC]]
  * [[https://pythonhosted.org/Pyro4/|Pyro4]]
  * [[https://zeroc.com/products/ice|ICE]]
  * [[http://www.zerorpc.io|ZeroRPC]]
  * [[http://zeromq.org|ZeroMQ]] (ØMQ)
  * [[http://docs.openstack.org/developer/oslo.messaging|Oslo.messaging]] (von OpenStack)
  * [[https://developers.google.com/protocol-buffers/|Protocol buffers]] (Google protobuf)
==== Frontend ====

  * Native clients
    * [[https://www.qt.io|Qt5]], LGPL and Commercial License, C++/QML - really excellent framework, very good Python bindings:
      * [[http://www.riverbankcomputing.co.uk/software/pyqt/intro|PyQt5]]: mature, GPLv3/commercial license.
      * [[http://pyqt.sourceforge.net/Docs/PyQt5/qml.html|QtQuick]] - maybe we think about it. Using with Python is not that mature.
      * [[https://github.com/PySide/PySide|PySide]]: Dead. Not really an option, as last code update was in 2012 :-(
      * [[https://wiki.qt.io/PySide2|PySide2]]: Seems to be actively developed again by [[https://www.qt.io/|The Qt Company]] - maybe another option instead of PyQt5
    * [[http://kivy.org|Kivy]] - seems to be nice for games/2d stuff; but DB driven UI? ...not.
  * Web clients (also possible on desktop using [[https://electron.atom.io/|Electron]])
    * [[https://angularjs.org|AngularJs]], MIT License
    * [[https://www.sencha.com/products/extjs|ExtJs]], GPLv3 and Commercial License
    * [[https://www.meteor.com|Meteor/Blaze]], MIT License

==== Code documentation ====

[[http://sphinx-doc.org|Sphinx]]

==== Plugin frameworks ====

This meanwhile is worth an [[en:dev:drafts:plugins|own draft page]].

==== FHIR ====
[[https://www.hl7.org/fhir|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.

== Links ==

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



==== LOINC ====

All Data regarding lab results should be saved, or at least be interchangeable by the worldwide used [[https://loinc.org|LOINC]] format.