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 [email protected] +44.789.988.5068 (UK) +353.89.457.6011 (Ireland) On 18 February 2018 at 15:55, Thomas Beale <[email protected]> wrote: > > On 18/02/2018 11:16, Erik Sundvall wrote: > > > When designing this, perhaps some (2-5) existing currently popular GUI > frameworks could be initial targets for output from the process, and the > selection could be updated over time. Perhaps for example > https://angular.io/ and https://reactjs.org/ are two starting candidates > for experimentation? (Both have partially declarative design, but other > suggestions are of course welcome) Then mechanisms in those platforms could > be reused rather than reinvented. > > > yes - this is the sort of thing I have in mind. The tool would function as > follows: > > - represent UI forms and ?other UI behaviours (some screen workflow) > as archetypes+templates of classes that generically represent such things > - use one or a set of templates to represent an application > - generate the OPTs of these templates, as ADL2 or JSON, YAML, > whatever is convenient > - perform OPT => GUI transform, injecting some UI styling profile > info, to get directly consumable artefacts for the UI framework. > > experts on the UI side will be able to help refine the details of this. > > THe 'smart split' of data / UI semantics will be the key to making this > workable. > > - thomas > > > Also looking at the things done in the format used/shared by Marand and > DIPS is an interesting input for gathering requirements. > > //Erik Sundvall > > > -- > Thomas Beale > Principal, Ars Semantica <http://www.arssemantica.com> > Consultant, ABD Team, Intermountain Healthcare > <https://intermountainhealthcare.org/> > Management Board, Specifications Program Lead, openEHR Foundation > <http://www.openehr.org> > Chartered IT Professional Fellow, BCS, British Computer Society > <http://www.bcs.org/category/6044> > Health IT blog <http://wolandscat.net/> | Culture blog > <http://wolandsothercat.net/> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
