Alle Augen auf Alliterationen:

HelfersHelfer HealthcareHackathon


This is a call to arms!

Will you stand beside me?

Codende & Designende, an die IDEs, an die VIs und die DBs!

Beladet die Docker und auf zu neuen Ufern!

Wir sind keine HeadHunter, wir sind HelfersHelfer.

Ihr seid es leid, mit Flexi-Time, Free drinks and snacks, Rewards, Bonuses, Team building days, Fun events und Sabbaticals geködert zu werden, um irgendeinen Mist zu coden?

Ihr braucht nichts, ihr wollt nichts?

Perfekt, bei uns bekommt ihr nichts.

Hier helft ihr einzig und allein, um zu helfen.

Wir versuchen eine kleine schlagkräftige Truppe aufzubauen, die hilft, das Projekt auf die Beine zu stellen und technologisch am Leben zu halten und eventuell mit zum Hackathon kommt.

Feuer gefangen? Melde dich gerne via vernetzt.helfershelfer@gmail.com.


  • am 5./6.Juni 2019 in Mainz (Pre-Event, Formierung von ersten Hackergruppen),
  • am 2./3. September 2019 in Berlin (Hauptevent und Preisvergabe) und
  • am 12./13. September 2019 in Kiel zu einer “After-Hours”-Nachlese top

https://www.healthcare-hackathon.eu

https://twitter.com/healthhackkiel?lang=de

https://www.facebook.com/pages/category/Event/Healthcare-Hackathon-233368800502185/

The Tech Stack …

HelfersHelfer must stay maintainable for years and years by different coders. This leads to some general questions, conclusions and paradigms:

  • We do not want to reinvent the wheel.

  • We do want to stand on the shoulders of giants.

  • We do not want that shiny hipster framework that is en vogue since one week (for one week).

  • KISS is for keep it small and simple

  • Opinionated Frameworks might be the better choice

  • What we use should (likely) be still around and actively maintained in some years


This leads to PHP as language for the API.

Java might be the better language in general, but in Hamburg (and germany?) it is easier to get more inexpensive PHP coders + me and my company are doing a lot with php/symfony/angular. I vote for PHP, because most of the developers that join me at the hackathon work with PHP and symfony at work.

If it is going to be PHP, it has to be symfony as framwework because it is an enterprise scale, non-hipster framework, that is stable and does not come around with breaking changes every few months.

In the frontend there are the two big relevant frameworks react and angular (or maybe - more lightweight - vuejs), this decission should be discussed too. React is a little bit easier to learn, I think (well, I haven’t), but Angular again is an enterprise scale frontend framework, that is opinionated, made for big projects and that uses typescript by default and coding in typescript ist much better, cleaner and leads to more self documenting code. Although angular is not easy to learn, I would vote for angular. But - as said - this must be discussed.

As DB we could use Maria DB or any other RDBMS.

Maybe Elasticsearch could be useful.


Different approaches

  • Symfony 4.2 Skeleton + Angular 7 (+jwt)
  • API Platform - all in one approach, with Symfony for the API + react/vue.js for Backend + frontend, dockerized
  • API Platform for API only + Angular in the frontend / admin-section

Aufbau und Wünsche aus dem Fachbereich

Bei der Suche:

Erste vorgeschaltete Filtermaske

  • Folgende Filter kann jeder Helfer leicht beantworten, daher werden diese zu Beginn separat angezeigt auf einer ansonsten …
  • leeren Seite (marcro white space), aufgeräumt und übersichtlich

Alter

… eher als Altersgruppe, da hier die die Trennschärfe fehlt (Jugendlicher von bis? …)

Wohnort

Postleitzahl, Ort (und Straße). Hausnummer könnte aus Datenschutzgründen (note to myself: JT fragen) problematisch sein.

Geschlecht

Da es Angebote z.B. nur für Frauen gibt, ist dieser Filter relevant.


Nachdem die o.g. Filter ausgewählt wurden (erzwingen?), werden…

  • weitere Filter, die nun noch Sinn ergeben angezeigt und…
  • Im unteren(?) Bereich auch schon Ergebnisse angezeigt, für den Fall, dass es nun eh nur noch n(<=5?) Ergebnisse gibt

Weitere Filter

Generell: weniger ist mehr. Nicht den Nutzer “erschlagen”!

Diagnose-Gruppe (Eigene Entity)

Angelehnt an die ICD-10; vorerst nur die Kategorien eventuell auch Diagnose-Subkategorien (1 zu 0..* ) anlegen als eigene Entity Dann könnte man bei Bedarf beim Anlegen die Kategorie wählen oder die Subkategorien aufklappen und da ins Detail gehen.

Bei der Suche würden man dann beim Wählen der Kategorie automatische alle Subkategorie-Treffer bekommen.

Man könnte auch die Obergruppen “einreihen” und eine Subkategorie mit eigenem Schlüssel oder tatsächlich mit

  • Organische, einschließlich symptomatischer psychischer Störungen

  • Störungen durch psychotrope Substanzen

  • Psychotische Störungen

  • Affektive Störungen

  • Angststörungen

  • Zwangsstörung

  • Trauma- und belastungsbezogene Störungen

  • Disruptive, Impulskontroll- und Sozialverhaltensstörungen

  • Persönlichkeitsstörungen

  • Entwicklungsstörungen ( Autismusspektrumsstörungen, …),

  • Intelligenzminderung

  • Verhaltens- und emotionale Störungen der Kindheit/Jugend

…. Gruppen/Kategorien der (Körper)Behinderungen ??


Themen-Gruppe

  • Arbeit
  • Wiedereingliederung
  • Kinder(erziehung)
  • Einzelgespräche
  • Gruppengespräche
  • (Teilhabe-)Beratung …?

Entitäten

  • Themen-Gruppe
  • Diagnose-Gruppe
  • (Diagnose-Subkategorien)
  • Rolle / Gruppe
  • User
  • Einrichtung
  • Angebot
  • Veranstaltung
  • Termin

Entity Relationship Stuff

entity 1 x to y entity 2
Rolle / User 1 to 0..* User
Kategorie 1 to 0..* Subkategorie?
Einrichtung 1 to 0..1 Angebot /Vearnst.
Veranstaltung 1 to 0..* Termin

Legende:

Multiplicity Cardinality
0..0 Collection must be empty
0..1 No instances or one instance
1..1 Exactly one instance
0..* Zero or more instances
1..* At least one instance
5..5 Exactly 5 instances
m..n At least m but no more than n instances

i18n / Mehrsprachigkeit

Internationalisierung und Mehrsprachigkeit sollte von Anfang an bedacht werden, insbesondere was die ausgegebenen Informationen für den Klienten angeht.