Versions Compared

Old Version 3

changes.mady.by.user Erik Sundvall

Saved on

compared with

New Version 4

changes.mady.by.user Erik Sundvall

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Online archetype and template tools

...

Erik Sundvall is responsible for arranging a first draft wikipage (this one) and an initial online meeting, but not necessarily the one coordinating the rest of the project. (An organization/person that can dedicate project leader time for some months would be welcome to volunteer.

A "doodle" where you can select time-preferences for a first (and possibly a second) 1-hour meeting is available at: http://doodle.com/gm456xavg3fcgvw5 (date alternatives ranging between Oct 14 to Oct 27) If we find two fairly suitable times within this timespan, then we can pick two of the dates so that we get one start and one followup meeting. Please respond before October 14.

Fallback online meeting mechanism if other things fail is the slightly lagging, but very scalable Adobe Connect meeting room at https://connect.sunet.se/openEHR. Please try it out before meetings so that you have audio (and possibly video) working properly.

Having a physical meeting was also suggested and that will hopefully be possible later for at least some participants. But we start online to be better prepared for physical meetings. Online participation possibilities during parts of physical meetings will be seriously considered.

...

Possible mailing list discussions regarding this project should initially be directed to the openEHR implementers list (if the wiki comments comment system below are is not useful enough). Major questions, events and news will should be announced on the openEHR implementers list (since we do not expect everybody to monitor the wiki).  If If traffic gets to intense there consider separate list.

Actors/developers and their interests/contributions

Please add specific interests och  full names, specific interests, possible contributions under your organisation/namename and correct misunderstandings and other mistakes.

Actors that reported participation interest during the roadmap meeting:

...

  • Ocean - Thomas Beale, Seref Arikan, Sebastian

    • ...

  • Marand - Bostjan, Borut, Marko

  • Code24 - Sebastian Iancu

    • ...

  • DIPS - TBD (contact Bjorn Naess)

    • ...

  • RaySearch - TBD

    • Interested in parser implementations using Javascript*

    • ...

  • Linköping University and the County Council of Östergötland: Erik Sundvall (openEHR software program coordinator)

    • Drafting first wikipage, setting up first online meeting, 

    • Announcing project news via mailinglist(s)

    • Help research and test "Operational Transformation" possibilities/frameworks (for undo/redo and collaboration)

    • Interest in helping out with GUI considerations (not lead GUI development)

    • Interest in pedagogical RM-visualization (at some later stage of project when more important things already work..

  • Did we forget any interested people from the meeting?

...

  • HTML5+Javascript based user interface (should work nicely in full screen mode too).

  • Possibly server-side components (using various implementation technologies) for model conversion, validation and other things that are already (fully or partly) implemented. Existing components that already support ADL 2.0 are of course extra interesting... For offline use on not-locked-down-computers such "server components" can of course run locally.

  • Angular JS for GUI to model mapping + Bootstrap for CSS, some components etc

  • Operational Transformation (see explanations below) could provide both robust undo/redo/history functionality (and in the long run synchronus multi-user/multi-device editing).

  • These tools might be desirable to integrate with different vendor solutions, so modular design and configurable appearance (via CSS?) is preferred.

  • Use Apache 2 licence (default for new openEHR foundation hosted projects)

Proper modularisation will makes make it easier for different developers to work on (or replace) separate parts. Suggest modules and/or APIs below

Potential API:s/interfaces between modules

  • directory that exposes/lists/fetches/saves archetypes/templates from/to CKM, Github or other sources
  • a parsed modifiable tree-representation of AOM objects

    • probably as a tree of Javascript or JSON "objects"

      a way for different implementations of

      (TODO: What kind of trees/datamodels will parsers generate? Would a (partly handcoded?) Javascript-implementaton of the AOM be needed?)

    • a way for different implementations of validator functions to flag/annotate branches of the tree as valid/conformant or not.
    • a way to add/modify manually entered comments and discussions to branches (including things that may not get serialized in a final published archetype).
    • some kind of root tree or branch that in addition to proper AOM objects can hold yet unstructured ideas or semi-structured notes (mindmaps, bullet lists etc) that can later be converted (manually with some automation help) to proper AOM structures. 
    • it would be nice if this whole tree could be versioned /(and later shared) via OT (Operational Transformation)
    • a way to subscribe to change-notification of nodes
      (TODO: Does Angular JS or OT-libraries already provide what is needed for thischange-notification subscriptions?)

...

  • ...

Potential modules

    • Clinician-friendly GUI-representations of the tree-parts (for example similar to different panes, subtrees and widgets in the current archetype editing tools)
    • Clinician-friendly form-generators that show something similar to what an entry form using the archetype/template will look like for an EHR end user.
    • Nerd-friendly GUI-representations of the tree (for example similar to some views in the current ADL workbench) 
    • Nerd-friendly text-representations of the tree (ADL, JSON, YAML, whatever...)
      • There are a lot of open source highly configurable text editor components out there, many support syntax-highlighting etc out of the box. Suggest examples and describe interesting features
    • Serializers
    • Parsers
      • of open source, highly configurable, text editor components out there, many support syntax-highlighting etc out of the box.
        Suggest editor examples and describe interesting features:
        • The inline editor widgets in http://brackets.io/ (for example color selectors) make an interesting hybrid between text-based and GUI-based editing
        • ...
    • Serializers
    • Parsers
    • Terminology binding tools
    • ...

Suggestions/ideas hard to classify/separate as above

...

Use case background for online collaboration

[2014-note: online collaboration is not a priority in the initial phase above]

The current archetype editors are downloadable off-line applications and collaboration is done by editing offline, then sharing/uploading and discussing online (e.g. using products like Ocean Informatics CKM).

The situation above works and can be compared with collaborative editing of word processor documents. Document writing can be done in off-line applications and then shared and discussed online, or in mail sent back and forth. Versioning and conflict resolution of parallel edits (merging etc) requires skill, time and patience. Compared to this, it is often a lot easier to collaborate using online realtime multi-user editor environments like https://drive.google.com/, https://writer.zoho.com/, and http://en.wikipedia.org/wiki/Etherpad 

Many of the realtime environmants include some kind of comment/discussion mechanisms (e.g. the google drive apps) and history/playback/revisioning mechanisms that also sho who did what when. (Try “Time slider” at the etherpad-based http://piratepad.net/vDW7YbIMKv document and feel free to edit/experiment).

Just creating yet another archetype editor would not be such an interesting contribution to the world, but creating a new online collaborative archetype editor that has comments and timeline/playback functions would be a nice contribution!

When Google Wave (now Apache Wave) was active, the openEHR community tried different uses for it. Follow the threads around the message http://www.openehr.org/mailarchives/openehr-clinical/msg01615.html, and read http://omowizard.wordpress.com/2009/11/17/google-wave-and-health/ (Maybe also read some search results: https://www.google.se/search?q=openehr+google+wave) These links indicate that the real-time collaboration was appreciated for capturing knowledge in pre-editing phase of archetype creation.

Google wave was extendable with collaborative gadgets/widgets for mindmapping voting etc. There were open APIs that allowed you to add your own widgets (and server side “robots”). By combining client side gadgets/widgets with server-side robots, fairly sophisticated applications could be created.

At IMT, LiU Daniel Karlsson and Erik Sundvall supervised a student project that experimented with taking the archetyping discussions in Wave a bit closer to real archetype editing by creating widgets and robots that handled real partial archetype structures. The parts that got implemented in the limited timespan worked as expected. The editing process was automatically saved in the wave and could be played back using the wave playback function. Comments and discussion threads could be mixed in between the archetype editing widgets. During the project Google announced that it would shut down Wave, and the student project prototype was not continued by any follow-up projects.

...

Many real-time multi-user online collaboration tools like the ones above are based on “operational transformation” (OT). A pedagogical description of OT is available at http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation

Some interesting OT-implementation links and discussions:

Operational transformation can be used on text as described above, but also data structurs like on XML (as was the case in Google Wave) and JSON (e.g. as described at https://github.com/josephg/ShareJS/wiki/JSON-Operations).

The openEHR AM can of course be represented as XML or JSON. The java-ref-impl provides XML import/export but JSON could be added (Erik S started experimenting with http://jackson.codehaus.org/ to provide AM/RM conversions to JSON)

...

A master thesis project or similar effort create (or explore how to create) a real-time collaborative  online archetype editor. Ideally it should be possible to run the editor both in independent/freestanding mode and embedded in other collaborative environments (e.g. Google Hangouts https://developers.google.com/+/hangouts/ or similar platforms).

The broad idea is to host both pre-archetyping discussions and actual archetyping in the same (OT-based collaborative) environment that would take over most of what is done in off-line archetype editors today, a lot of what is done in the pre-editing phase, and some steps of what is done in the CKM today.

...

  • Offline capacity in browser based applications is possible in modern browsers, see e.g. http://www.html5rocks.com/en/features/offline This could be used to have (all or some selected) archetypes and discussions available (read-only) when offline (e.g. when travelling). If implemented cleverly it will use HTML5 features for updating and downloading changes when reconnected.

  • HTML5 offline features combined with a local instance of the server-side archetype-validation features (e.g. a small java-based server app) could be used to reduce or eliminate online server calls when editing archetypes alone. Collaborating with others that do parallel edits to the same archetype will of course re-introduce the same merging and conflict resolution problems as the off-line approach of today has.

...