Versions Compared

Old Version 23

changes.mady.by.user Thomas Beale

Saved on

compared with

New Version 24

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

...

Not everybody can fit the same time into their calendars so there will be are two options to choose from this week (or both if you want and have time). 

We 'll have had a second short meeting (30 min?) now during Tuesday, Swedish time starting at 12:00 Tuesday October 21. Notes and chat available at http://www.worldtimeserver.com/convert_time_in_SE.aspx?y=2014&mo=10&d=21&h=12&mn=0 (primarily for those not able to join the third meeting on Thursday)openehr.org/wiki/x/DoAiAw The sections "Roadmap" and "Actors/developers and their interests/contributions" were updated as a result of the meeting.


We'll have a third meeting meeting (45+ min?) two days later, during Thursday, Swedish time starting at 12:00 http://www.worldtimeserver.com/convert_time_in_SE.aspx?y=2014&mo=10&d=23&h=12&mn=0
The main agenda points for both meetings meeting 2 and 3 are:
- Define your main participation-interests for the project as a whole and suggest starting points where you would like to contribute initially. Those with limited time can of course monitor/review/comment work items as they evolve (instead of developing them), but then please tell us a bit about what items/subjects you want to focus on.
- How do we best make this a joint effort with e.g. the CIMI and 13606 communities?

Instead of attending meeting 2 or 3 you can add the above requested participation-interest-information (and your name if missing) to this wikipage.
I hope that we after these first meetings (1-3) can start seeing clusters of interests/components that we can focus smaller teams and meetings around and then reduce the frequency of big general-purpose meetings. Small meetings with fewer participants are also easier to host in Google Hangouts and similar systems.

...

A "doodle" where you can select time-preferences for 1-hour meetings is available at: http://doodle.com/gm456xavg3fcgvw5 (date alternatives ranging between Oct 14 to Oct 27) A first meeting is already finished. We might pick other times among these for followup meetings. 

Based on the doodle above (read on october 16) the most likely follow-up meeting time could be October 21 and/or October 23, the time would be the same both dates, at 12:00-13:00 Swedish (lunch) time (smile)

...

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

Roadmap

  • We should try to have AE & TD replacements within 12 months (e.g. end 2015)
  • (Seref Arikan) I'd like to see a bottom up roadmap. Some model driven core components, parsers, AOM etc. First get a rough componentization up and running (modifyable AOM-tree datastructure)
    • something that can output ADL as one of the first serialization formats in order to feed that into a backend/serverside conversion chain (based on the ADL workbench to begin with)
    • as a start it is good if the tool can read from (and write to) Git repositories
    • make sure the solution is modular and extendable so that people can build different tools, UI on top of it.
      • Seref Arikan explaind it well in the chat: I'd like to see a bottom up roadmap. Some model driven core components, parsers, AOM etc. UI and functionality can go into 100 different directions

...

  • We should try to have AE & TD replacements by the end of 2015. Get a framework with basic editing capabilities up and running before November 2015 (hopefully a lot sooner) otherwise consider ending this project and hope that other actors step in.
  • Develop ADL 1.4 migration strategy for implementers.

Actors/developers and their interests/contributions

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

  • Ocean Informatics - Thomas Beale, Seref Arikan, Sebastian

    • Component architecture of new tooling

    , Sebastian

  • FreshEhr (Ian McNicoll)
    • Help validate ADL2.0 -> 1.4.OPT generation
    • repository managementExplore optimal repository organisation including integration with git/githib

  • 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..

  • University of Auckland - Koray Atalag & Aleksandar Zivaljevic

    • Annotation tools - formal "GUI Directives" (see details below)
    • ...
  • Samuel Frade
    • Transformations e.g. OPT -> HTML etc (both HTML trees structures and more "clinically friendly" ones)
    • ...

Initial/potential approaches identified as interesting during & after the roadmap meeting

...

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.

...