MedUX

OpenSource EMR

User Tools

Site Tools

Trace: • notifications
en:dev:brainstorming

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:dev:brainstorming [2017/10/24 23:09] – [Must-Haves] bullet correction nerdocen:dev:brainstorming [2018/03/18 12:36] (current) – [FHIR] fhir-parser addition nerdoc
Line 15: Line 15:
 ===== Nice-To-Haves ===== ===== 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?   * Maybe patient data sending as well with that?
   * Access to online-documentation: EBM-Guidelines, Arzneitelegamm, Scientific papers etc.   * 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.   * 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.   * 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 ===== ===== Technical considerations =====
  
Line 42: Line 46:
 === SQL === === SQL ===
  
- +  * [[https://postgresql.org|PostgreSQL]]
-  * [[https://postgresql.org|Postgresql]]+
   * [[http://www.sqlalchemy.org/|SQL-Alchemy]] - well-established, DB agnostic Object Relational Mapper   * [[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://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.   * [[https://crate.io|CrateDB]] - extremely fast and scalable object database, but accessible using SQL; Uses Elasticsearch for fulltext searching.
   * [[http://basho.com/products/|Riak]]   * [[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 ==== ==== 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]]   * [[https://www.meteor.com/|Meteor]]
  
Line 77: Line 93:
   * [[http://zeromq.org|ZeroMQ]] (ØMQ)   * [[http://zeromq.org|ZeroMQ]] (ØMQ)
   * [[http://docs.openstack.org/developer/oslo.messaging|Oslo.messaging]] (von OpenStack)   * [[http://docs.openstack.org/developer/oslo.messaging|Oslo.messaging]] (von OpenStack)
 +  * [[https://developers.google.com/protocol-buffers/|Protocol buffers]] (Google protobuf)
 ==== Frontend ==== ==== 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       * [[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.     * [[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.sencha.com/products/extjs|ExtJs]], GPLv3 and Commercial License
     * [[https://www.meteor.com|Meteor/Blaze]], MIT License     * [[https://www.meteor.com|Meteor/Blaze]], MIT License
Line 98: Line 114:
 ==== Plugin frameworks ==== ==== 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.
en/dev/brainstorming.1508879342.txt.gz · Last modified: 2017/10/24 23:09 by nerdoc