Differences

This shows you the differences between two versions of the page.

--- en:dev:brainstorming [2017/10/14 00:16] – [Must-Haves] correction nerdoc
+++ en:dev:brainstorming [2018/03/18 12:36] (current) – [FHIR] fhir-parser addition nerdoc
@@ Line 11: / Line 11: @@
   * Data access auditing: every database access must be logged: user, access target, timestamp, action.
   * Fast user switching
-Must-Deleting ob DB objects must be a "soft deleting", see e.g. [[https://medium.com/@adriennedomingus/soft-deletion-in-django-e4882581c340|SoftDeletionModel]]
+  * 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, etc.
+  * 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.
@@ Line 27: / Line 27: @@
   * 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 =====
@@ Line 42: / Line 46: @@
 === SQL ===
+  * [[https://postgresql.org|PostgreSQL]]
-  * [[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
@@ Line 60: / Line 63: @@
   * [[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]]
+  * [[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]]
@@ Line 77: / Line 93: @@
   * [[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 ====
@@ Line 87: / Line 103: @@
       * [[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]]
+  * Web clients (also possible on desktop using [[https://electron.atom.io/|Electron]])
-    * [[https://angularjs.org|AngularJs]], by Google, MIT License
+    * [[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
@@ Line 98: / Line 114: @@
 ==== Plugin frameworks ====
-As MedUX needs to be completely modular, we need a plugin framework that has some capabilities:
+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
-  * **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 [[http://wehart.blogspot.co.at/2009/01/python-plugin-frameworks.html|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:
-  * [[http://yapsy.sourceforge.net|Yapsy]]
+==== LOINC ====
-  * [[https://software.sandia.gov/trac/pyutilib|PyUtilib]] - I would use just the plugin framework core. Documentation of the "Component Architecture" is [[https://software.sandia.gov/trac/pyutilib/export/1831/pyutilib.component.doc/trunk/doc/plugin/pca.pdf|here]]
-  * [[https://github.com/mitsuhiko/pluginbase|Pluginbase]] - stability??
+All Data regarding lab results should be saved, or at least be interchangeable by the worldwide used [[https://loinc.org|LOINC]] format.