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