Hi all,
This might be a useful time to briefly explain why we are supporting 3 open source components in our “showcase” stack
EtherCIS - open source implementation of openEHR Clinical Data Repository http://ethercis.org/
QewdJS - nodeJS based middleware for varied purposes - inc microservices between UI & CDR
PulseTile- frontend UX/UI framework for healthcare
A few comments;
Point 1
We know that structured data in an EHR is essential for lots of reasons, inc querying, CDS, workflow etc etc. We also know that most folk who craft their application UI based on their data models end up with an UX application that is horrible & tedious to use at the frontend. (My emergency physician background was witness to that in many many applications.
I also recall leading work by Helma Van Der Linden about the challenges in automatically mapping from openEHR to the UI in a decent to use fashion.. non trivial was my recollection of our discussion.
So our approach has been a very deliberately clinically driven, user centred design approach, which has then driven the openEHR templates that underpin, but the UX is #1 in importance to frontline clinicians, not the data models.
(Still , all the key data is our stack created/updated/persisted in EtherCIS (& Marand) CDR using a RESTful JSON API. )
Point 2
We know that many folk are doing/ do direct mapping from data models to UI eg we could have chosen to feed the UI framework with openEHR JSON API directly
We also know that then raises somewhat of a data migration challenge if you’re sitting on any legacy non openEHR data (which most folk are), hence we use a middleware element (QEWDjs) which handles the mapping from both openEHR & non openEHR sources into the same UI JSON.
We explain the rationale for that in this article, where we describe 5 step wise levels of integration between non openEHR & openEHR systems, that our UX framework accomodates
http://ripple.foundation/2016/02/integrated-care-digital-records-maturity-model/
This key openEHR Jumper technology in QEWD handles the mapping between openEHR/ non openEHR (eg FHIR) and UI side JSON with a simple JSON2JSON mapping tool. as per this video.
https://www.youtube.com/watch?v=iaGGGgJdWvM&index=3&list=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv
(Some of you feel this middleware layer is an unnecessary element in an openEHR environment & I can understand that perspective. All I can tell you is that such a layer is essential in any environment we’re working in where folk have existing data & exploring a move towards openEHR)
Point 3
So the UX framework has then been designed to be pretty simple and generic and reusable for lots of uses.
In particular it aims to support “business/clinical analytics”, “multi patient cohort views” and “single patient that I need to look after who is right in front of me views” , as in my experience these are the key processes we need to support.
This framework is documented here http://docs.pulsetile.com/
and a video cast here gives an overview here
https://www.youtube.com/watch?v=jpfIZ_HWr3w&index=2&list=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv
and for better/worse we have supported in both Angular & React frameworks for now, with a core set of widgets “Tiles” and a plugin approach to extra Tiles.
see here https://github.com/PulseTile
I wont get into the large & evolving range of choice in frontend frameworks, but if you are trying to keep track of them take a look here
https://github.com/gothinkster/realworld
We’ve heard mention of microservices in a recent thread, not to mention the possibility of https://micro-frontends.org/
Lastly a final UI side JSfiddle, to explain direction of travel here
https://jsfiddle.net/tshannon/hgypL94d/
Imagine an open source stack..
openehr CDR pre populated with top 10/20/50 templates for common use +
#middleware with related openEHR_2_UI mapping (or other eg FHIR API) via JSON2JSON mappings (some will argue unnecessary, I refer back to point 2)
#UI framework with top 10/20/50 UI widgets (“Tiles”) with the ability to add your own template. JSON2JSON mapping & UI widget)
.. thats probably the best way to summarise where we are heading with this in 2018
Perhaps to finish, even if your working from openEHR 2 UI directly, please remember the busy clinician at the frontline who has to contend & work with the UI (not the data model).. lets aim to get tools out there that ease their load..
Hope that’s of interest/ helps
Tony
Dr. Tony Shannon
Director, Ripple Foundation ripple.foundation
tony.shannon@ripple.foundation
+44.789.988.5068 (UK)
+353.89.457.6011 (Ireland)