First draft of openEHR software programme web pages

Implementers (archive)
1

Hi openEHR software community!

I am working on a first draft of openEHR software programme web pages in a fork at…
https://github.com/ErikSundvall/openehr-website/tree/master/programs/software
…that will later end up at:
http://www.openehr.org/new-ws/site/programs/software/programhome
…and sometime (even later) after that will go live in the new openEHR website

The following pages contain most of the info (and are included in HTML-rendered form by the end of this mail).
https://github.com/ErikSundvall/openehr-website/blob/master/programs/software/programhome.php
https://github.com/ErikSundvall/openehr-website/blob/master/programs/software/governance.php

I have chosen to list software projects in the wiki (project space) instead of on the web to start with, so that the list can be easily corrected and maintained by you (including project owners). So if you are involved in a project, check the info at http://www.openehr.org/wiki/display/projects/ and add to it or correct it.

Please understand that the suggested governance etc has not been approved by the openEHR foundation board yet, so it may change considerably. Consider this as a first discussion draft only.

Have a look at the texts, suggest improvements and try to spot errors. Also try to spot risks for programme/process “kidnapping” or deadlocks.

Everything is open for discussion!

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

Software Program

The openEHR software program aims to support software development based on, or related to, the openEHR specifications.

Current Activities

Most current openEHR related software projects are self-governed and self-funded by various organisations doing research or commercial services/product development. The openEHR Software Program is an arena for sharing experience and ideas between projects. Most such sharing is currently done via the software focused mailing lists and partly also the specification focused mailing lists.

The program also coordinates hosting of some software projects that have donated code to openEHR or previously have requested openEHR hosting. More outspoken rules for what is required to host a project under the openEHR “umbrella” and/or to “brand” it as an openEHR project is under discussion in the community. A suggestion is to reuse the project experiences from the Apache Foundation, including some incubation process etc. (See also: license preferences.)

The program strives to increase awareness of available openEHR implementations. A wiki page lists known openEHR-related software projects. Other implementation related information can be found at the developer related wiki-pages

Potential future activities

The future direction of the software programme is always open for community discussion (primarily using the openehr-implementers mail list). Some initial suggestions are:

  • Conformance and interoperability test tools - to be designed and developed together with the openEHR Specifications Programme.
  • Clarification of procedures for openEHR hosting and “branding” of open software projects
  • Start and maintain a list of “project suggestions” as a service to e.g. educational or commercial actors wanting to explore unfulfilled openEHR software needs.
  • …

Governance & Members

Most current openEHR-related software projects are self-governed sparate entities. The principles below only govern the common openEHR Software Programme itself and it’s provided resources (sometimes including code donated to the openEHR foundation).

The governance structure of the openEHR software program/group is mosly mail-list based and inspired by the Apache Software Foundation and the way it works. That is combined with the general governance structure of the openEHR foundation that requires both a Program Committee and a list of Program Qualified Members.

Community, including Program Qualified Members

The majority of the work and software decisions should be discussed on the openehr-implementers mailing list where anybody can contribute to the concensus-targeted discussion (no qualified membership required).

If voting is needed then votes from Program Qualified Members will be evaluated using Apache style voting and interpretation.

Qualified Membership should be based on meritocracy and willingness to contribute. Qualified Membership is not time-limited. Qualified Membership can be ended if the member requests to be removed.

If three independent* Qualified Members agree to suggest a new member and presents the candidate (including openEHR related merits), then the Program Committee should discuss and consider if the new member should be: a) approved at present or b) be recommended to first gain more experience in order to get suggested again later.

If thorny vendor/institution-related issues arise that at least three independent* Qualified Members think would benefit from vendor/institution balance, then the issue can be transferred to the program committee instead.

*) Independent in this case refers to not being dependent on the same organisation for salary or other benefits.

Current Program Qualified Members- David Moner

  • Diego Boscá
  • Erik Sundvall (coordinator)
  • Heath Frankel
  • Heather Leslie
  • Koray Atalag
  • Pablo Pazos
  • Ricardo Correia
  • Rong Chen
  • Sam Heard
  • Seref Arikan
  • Sergio Freire
  • Shinji Kobayashi
  • Thomas Beale
  • Tony Shannon

Program Committee

The Program Committee is responsible for reporting to and relating to the openEHR foundation board and it also maintains the official (and incubating) openEHR software project listings and approves new Program Qualified Member suggestions (as described above).

The Program Committee is according to openEHR foundation program rules limited to a maximum of 9 and minimum of 5 Qualified Members. During initial/bootstrap committee formation we have strived to set it up in a way so that no specific company or institution is represented more than once (since the number of seats is limited).

The Program Committee positions should be renewed or changed on a regular basis as decided by the openEHR foundation. The Software Program Qualified Members suggest new and/or renewed positions in the Software Program Committee to the openEHR foundation board that does final approval (or asks the Software Program Qualified Members for a new suggestion).

Current Program Committee Members- Alan James

  • Diego Bosca
  • Erik Sundvall (coordinator)
  • Pablo Pazos
  • Rong Chen
  • Seref Arikan
2

Erik Sundvall wrote:

I am working on a first draft of openEHR software programme web pages ...

Software Program

The openEHR software program ...
The future direction of the software programme ...

Hi Erik,

The spelling of the word "programme" needs to be decided. Is it American ("program") or international English ("programme")?

Also, the meaning of the word in this context is unclear to me. A "software program" usually means something quite different from the apparent intention here (especially if you use the American spelling). To avoid confusion, I wouldn't call this a "software programme".

Peter

3

Thanks for feedback Peter!

I agree that the word “program” is horrible for the openEHR subdivisions, especially the combination “software program”. “Programme” is somewhat better and I know Tom Beale has been pushing for that.

Personally I like the (bottom-up-style) name “software community” (if it works like a community), but perhaps there is some other better “top-down-style” name.

Name suggestions are welcome and I believe that the foundation board would be listening. Speak up everybody! :slight_smile:

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

4

Hi Erik,

It would be nice to gather all openEHR related software projects in the wiki. I think the board will do a request soon to collect updated information about openEHR software around the world (that was discussed this monday @ London).

About project hosting (https://github.com/ErikSundvall/openehr-website/blob/master/programs/software/programhome.php) we need to specify the requirements for a project to be hosted by the foundation (I have a project but I don’t know what to do to get it hosted @ openEHR.org :slight_smile: This could be part of the governance page (?).

I suggest that one requirement should be to define a clear roadmap for the project, with release planing and high level requirements to be implemented, so the community could know when they should expect a certain functionality to be implemented (waiting for functionalities or features to be implemented is the biggest headache for users of open source software). That could also help in inter-project coordination.

Also on that page, IMO conformance & test tools should be a priority for the software programme. That will be a big part of openEHR software certification in the future (and a possible funding way).

“Current Activities”
“… various organisations doing research or commercial services/product development …”

Part of the work of the software programme could be to collect data about those organizations and the kind of work they are doing with openEHR. We are a sparse community and we need to gather all efforts together to give the image and security of a strong community. That is a good caller for new members and could encourage current members to get more involved in software development and other activities/projects like clinical modelling.

Kind regards,
Pablo.

Software ProgramThe openEHR software program aims to support software development based on, or related to, the openEHR specifications.

Current ActivitiesMost current openEHR related software projects are self-governed and self-funded by various organisations doing research or commercial services/product development. The openEHR Software Program is an arena for sharing experience and ideas between projects. Most such sharing is currently done via the software focused mailing lists and partly also the specification focused mailing lists.

The program also coordinates hosting of some software projects that have donated code to openEHR or previously have requested openEHR hosting. More outspoken rules for what is required to host a project under the openEHR “umbrella” and/or to “brand” it as an openEHR project is under discussion in the community. A suggestion is to reuse the project experiences from the Apache Foundation, including some incubation process etc. (See also: license preferences.)
The program strives to increase awareness of available openEHR implementations. A wiki page lists known openEHR-related software projects. Other implementation related information can be found at the developer related wiki-pages

Potential future activitiesThe future direction of the software programme is always open for community discussion (primarily using the openehr-implementers mail list). Some initial suggestions are:

  • Conformance and interoperability test tools - to be designed and developed together with the openEHR Specifications Programme.
  • Clarification of procedures for openEHR hosting and “branding” of open software projects
  • Start and maintain a list of “project suggestions” as a service to e.g. educational or commercial actors wanting to explore unfulfilled openEHR software needs.
  • …

Governance & MembersMost current openEHR-related software projects are self-governed sparate entities. The principles below only govern the common openEHR Software Programme itself and it’s provided resources (sometimes including code donated to the openEHR foundation).

The governance structure of the openEHR software program/group is mosly mail-list based and inspired by the Apache Software Foundation and the way it works. That is combined with the general governance structure of the openEHR foundation that requires both a Program Committee and a list of Program Qualified Members.

Community, including Program Qualified MembersThe majority of the work and software decisions should be discussed on the openehr-implementers mailing list where anybody can contribute to the concensus-targeted discussion (no qualified membership required).

If voting is needed then votes from Program Qualified Members will be evaluated using Apache style voting and interpretation.
Qualified Membership should be based on meritocracy and willingness to contribute. Qualified Membership is not time-limited. Qualified Membership can be ended if the member requests to be removed.
If three independent* Qualified Members agree to suggest a new member and presents the candidate (including openEHR related merits), then the Program Committee should discuss and consider if the new member should be: a) approved at present or b) be recommended to first gain more experience in order to get suggested again later.
If thorny vendor/institution-related issues arise that at least three independent* Qualified Members think would benefit from vendor/institution balance, then the issue can be transferred to the program committee instead.
*) Independent in this case refers to not being dependent on the same organisation for salary or other benefits.

Current Program Qualified Members- David Moner

  • Diego Boscá
  • Erik Sundvall (coordinator)
  • Heath Frankel
  • Heather Leslie
  • Koray Atalag
  • Pablo Pazos
  • Ricardo Correia
  • Rong Chen
  • Sam Heard
  • Seref Arikan
  • Sergio Freire
  • Shinji Kobayashi
  • Thomas Beale
  • Tony Shannon

Program CommitteeThe Program Committee is responsible for reporting to and relating to the openEHR foundation board and it also maintains the official (and incubating) openEHR software project listings and approves new Program Qualified Member suggestions (as described above).

The Program Committee is according to openEHR foundation program rules limited to a maximum of 9 and minimum of 5 Qualified Members. During initial/bootstrap committee formation we have strived to set it up in a way so that no specific company or institution is represented more than once (since the number of seats is limited).
The Program Committee positions should be renewed or changed on a regular basis as decided by the openEHR foundation. The Software Program Qualified Members suggest new and/or renewed positions in the Software Program Committee to the openEHR foundation board that does final approval (or asks the Software Program Qualified Members for a new suggestion).

Current Program Committee Members- Alan James

  • Diego Bosca
  • Erik Sundvall (coordinator)
  • Pablo Pazos
  • Rong Chen
  • Seref Arikan

_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

5

Thanks for valuable feedback Pablo!

It would be nice to gather all openEHR related software projects in the wiki.

Yes, that is the intention of the page http://www.openehr.org/wiki/display/projects/Projects+Home please edit/add info there.

Pablo wrote:

About project hosting (https://github.com/ErikSundvall/openehr-website/blob/master/programs/software/programhome.php) we need to specify the requirements for a project to be hosted by the foundation (I have a project but I don’t know what to do to get it hosted @ openEHR.org :slight_smile: This could be part of the governance page (?).

Yes, I thought we’d might discuss that here in the community on the list before putting into formalized written guidelines. That’s what I meant by:


More outspoken rules for what is required to host a project under the openEHR "umbrella"
and/or to "brand" it as an openEHR project is under discussion in the community. 
A suggestion is to reuse the project experiences from the Apache Foundation,
<a href="[http://www.apache.org/foundation/how-it-works.html#incubator](http://www.apache.org/foundation/how-it-works.html#incubator)">
including some incubation process</a> etc.

Pablo wrote:

I suggest that one requirement should be to define a clear roadmap for the project, with release planing and high level requirements to be implemented, so the community could know when they should expect a certain functionality to be implemented (waiting for functionalities or features to be implemented is the biggest headache for users of open source software). That could also help in inter-project coordination.

A requirement to maintain an updated (hopefully realistic rather than optimistic) roadmap - that is a great idea.

Another requirement I would like (copied from Apache incubation) is to have committers from more than one organisation, motivated by Apache below:

Diversity of committership is important for two main reasons:

  • it gives long term stability to the project development: in fact, with all the developers affiliated to the same entity, the chance of seeing all of them moving away from the project at the same time is much greater than with a community of individuals affiliated to unrelated entities.
  • it gives a greater variety of technical visions: something that guarantees a better adherence to environment and user’s needs, thus a higher change of finding real-life use of the software.

What do you all think of that approach? The openEHR Java Reference implementation is a project that fulfills that already now, not sure about the others.

Also on that page, IMO conformance & test tools should be a priority for the software programme. That will be a big part of openEHR software certification in the future (and a possible funding way).

That is already the first point in the “future activities list” on the page. Is that an OK place to have it until we get started for real? Do you have suggestions for other ways to formulate it?

Please note that the above (roadmap + diversity of committership) discusses what would be required to host/brand an “openEHR project”, all this should not be required to be listed under the “openEHR related open source software projects” on the wikipage. We want a low entrance threshold to that “related”-list.

Part of the work of the software programme could be to collect data about those organizations and the kind of work they are doing with openEHR. We are a sparse community and we need to gather all efforts together to give the image and security of a strong community. That is a good caller for new members and could encourage current members to get more involved in software development and other activities/projects like clinical modelling.

Ah, good addition! Perhaps we can collect links to such “intelligence information” on the wiki project page http://www.openehr.org/wiki/display/projects/Projects+Home. I have now added a heading (and an example of work I am doing right now). Please add your known projects to the list there everybody!

// Erik Sundvall

6

Hi Erik,

Thanks for valuable feedback Pablo!

It would be nice to gather all openEHR related software projects in the wiki.

Yes, that is the intention of the page http://www.openehr.org/wiki/display/projects/Projects+Home please edit/add info there.

What I meant is that we need a more aggresive approach to gather this information, e.g. a group of people dedicated to ask one by one the members of the community to know what they are doing with openEHR and in which state is each of those projects/implementations. Asking on the lists and expecting people to edit the wiki has proved to be an ineffective approach.

Pablo wrote:

About project hosting (https://github.com/ErikSundvall/openehr-website/blob/master/programs/software/programhome.php) we need to specify the requirements for a project to be hosted by the foundation (I have a project but I don’t know what to do to get it hosted @ openEHR.org :slight_smile: This could be part of the governance page (?).

Yes, I thought we’d might discuss that here in the community on the list before putting into formalized written guidelines. That’s what I meant by:


More outspoken rules for what is required to host a project under the openEHR "umbrella"
and/or to "brand" it as an openEHR project is under discussion in the community. 
A suggestion is to reuse the project experiences from the Apache Foundation,
<a href="[http://www.apache.org/foundation/how-it-works.html#incubator](http://www.apache.org/foundation/how-it-works.html#incubator)">
including some incubation process</a> etc.

Just wanted to complement that paragraph.

Pablo wrote:

I suggest that one requirement should be to define a clear roadmap for the project, with release planing and high level requirements to be implemented, so the community could know when they should expect a certain functionality to be implemented (waiting for functionalities or features to be implemented is the biggest headache for users of open source software). That could also help in inter-project coordination.

A requirement to maintain an updated (hopefully realistic rather than optimistic) roadmap - that is a great idea.

Yep, it’s a basic requirement for project governance. Another thing is project management requirements. Here I set a list of items that we could use to create those requirements: http://translate.google.com/translate?sl=es&tl=en&js=n&prev=_t&hl=es&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fopenehr.org.es%2Fcms2%2Fdisplay%2Fgrupos_de_trabajo

I.e. requirements for project proposal, for starting a project, for reporting project status, … and the condition under which a project falls in hibernation or ends.

Another requirement I would like (copied from Apache incubation) is to have committers from more than one organisation, motivated by Apache below:

Diversity of committership is important for two main reasons:

  • it gives long term stability to the project development: in fact, with all the developers affiliated to the same entity, the chance of seeing all of them moving away from the project at the same time is much greater than with a community of individuals affiliated to unrelated entities.
  • it gives a greater variety of technical visions: something that guarantees a better adherence to environment and user’s needs, thus a higher change of finding real-life use of the software.

What do you all think of that approach? The openEHR Java Reference implementation is a project that fulfills that already now, not sure about the others.

+1 right now most projects have 1 or 2 committers from the same organization, and for the users of those projects the implementation of improvements or new requirements is quite slow. Also a project scope statement could be necessary in order to have some document that allows a committer to deny a change request, because is not on the scope of that project.

Also on that page, IMO conformance & test tools should be a priority for the software programme. That will be a big part of openEHR software certification in the future (and a possible funding way).

That is already the first point in the “future activities list” on the page. Is that an OK place to have it until we get started for real? Do you have suggestions for other ways to formulate it?

Maybe we need to put explicitly what the priorities are: e.g. “this activity list is ordered by priority”.

Please note that the above (roadmap + diversity of committership) discusses what would be required to host/brand an “openEHR project”, all this should not be required to be listed under the “openEHR related open source software projects” on the wikipage. We want a low entrance threshold to that “related”-list.

Ok.

Part of the work of the software programme could be to collect data about those organizations and the kind of work they are doing with openEHR. We are a sparse community and we need to gather all efforts together to give the image and security of a strong community. That is a good caller for new members and could encourage current members to get more involved in software development and other activities/projects like clinical modelling.

Ah, good addition! Perhaps we can collect links to such “intelligence information” on the wiki project page http://www.openehr.org/wiki/display/projects/Projects+Home. I have now added a heading (and an example of work I am doing right now). Please add your known projects to the list there everybody!

We need a more aggresive approach to gather this information, we need to do intelligence activities and actualy talk with each member that is doing something with openEHR :slight_smile:
We need to be proactive reaching valuable members and keeping them close to the community. A good start could be to ask the Foundation to send a personalized email to each person registered on the wiki, lists, ckm and google groups, asking for that information.

What do you think?

Kind regards,
Pablo.

// Erik Sundvall

_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

7

Why don't we just drop "Programme" and just use "Specifications" "Software" "Clinical Models" and "Localisation" as headings.
When we are referencing within test we can then use "Programme" or "Stream" etc.

Cheers,

-koray