Microsoft/NHS common health interface and openEHR datatypes

Clinical (archive)
1

Dear All

We are beginning to use the Microsoft Common Health Interface controls in our software. I think it would be good to keep this work open and shared so that we get them working with the openEHR datatypes (it is a very good fit at the moment). The first one off the rank will be the datetime control as this is the only one that looks finalised.

Should we keep the source on the openEHR site? I wonder if Tony Shannon or Mike Bainbridge could give us any direction on how to do this most effectively.

Cheers, Sam

2

Sam Heard wrote:

Dear All

We are beginning to use the Microsoft Common Health Interface controls in our
software. I think it would be good to keep this work open and shared so that we
get them working with the openEHR datatypes (it is a very good fit at the
moment). The first one off the rank will be the datetime control as this is the
only one that looks finalised.

Should we keep the source on the openEHR site? I wonder if Tony Shannon or Mike
Bainbridge could give us any direction on how to do this most effectively.

Open-source or just "open"? What are the licensing arrangements for the
Microsoft/NHS Common Health Interface controls? Obviously they depend on
the Microsoft .NET platform (do they also work with Mono?), but are
there additional licensing restrictions or limited access to the Common
Health Interface controls themselves?

Tim C

3

Open-source or just "open"? What are the licensing arrangements for the
Microsoft/NHS Common Health Interface controls? Obviously they depend on
the Microsoft .NET platform (do they also work with Mono?), but are
there additional licensing restrictions or limited access to the Common
Health Interface controls themselves?

This is what I had to sign up to when I registered ages ago.. in brief,
no to open source (3.4.2.3.4) and no to mono (3.4.1) - I presume this
is the same site from which the common control stuff would
come.

https://www.cui.nhs.uk/Pages/NHSCommonUserInterface.aspx

4

With little investigation into this and perhaps opening my mouth
prematurely, it sounds like Microsoft's answer to IBM's Open
Healthcare Framework (OHF) initiative. OHF is GPL I believe.

-- IV

5

Well, in fact OHF is EPL not GPL

http://www.eclipse.org/legal/eplfaq.php

6

In that respect: what was the outcome of the OHF in Germany, in which
an openEHR component proposal should be made?

Cheers,

Stef

7

Hi,

The idea of shared, reusable GUI widgets for data presentation and validation is very good. Ideally it would be platform independent, perhaps web-based.

Regards,
Rong

8

Hi Stef,

I was present in that meeting together with Thomas Beale. The view from the Java community at that time was that the benefit of moving any Java component projects to OHF wasn’t obvious to us. Besides there were some technical considerations, e.g. version control and issue tracking support.

Cheers,
Rong

9

Dear All

We are beginning to use the Microsoft Common Health Interface controls in our software. I think it would be good to keep this work open and shared so that we get them working with the openEHR datatypes (it is a very good fit at the moment). The first one off the rank will be the datetime control as this is the only one that looks finalised.

Sounds very promising. What are the forthcoming CHI controls?

Should we keep the source on the openEHR site? I wonder if Tony Shannon or Mike Bainbridge could give us any direction on how to do this most effectively.

Yes please. Anything that helps the community to speed up the development of usable implementations is very welcome.

Cheers, Sam

Cheers,

Stef

10

Is there any roadmap/guideline to the implementation of graphical components that work with openEHR data types?

Ricardo Correia

11

Yampeku wrote:

Well, in fact OHF is EPL not GPL

http://www.eclipse.org/legal/eplfaq.php

for those interested, we did quite a bit of detailed study on the EPL
last year - it is problematic, as it prevents you from using well-known
bits of other open source code, because it is primarily designed to a)
avoid encumbrance of the code by other licenses of any kind and b)
ensure that changes to code in the Eclipse code base can be done without
reference to anyone else. We couldn't even use it for the openEHR
(GPL'd) java kernel because the latter uses libraries that wouldn't be
allowed by the EPL. The EPL induction process is also painful - it takes
weeks/months to get your code 'reviewed' by Eclipse people to certify it
as 'unencumbered'...meanwhile it will have changed..

I have been told more recently by OHF people that these problem is
recognised and 'something' will be done about them..(probably not in
Eclipse proper, but for the OHF project).

- thomas beale

12

Rong Chen wrote:

Hi Stef,

I was present in that meeting together with Thomas Beale. The view
from the Java community at that time was that the benefit of moving
any Java component projects to OHF wasn't obvious to us. Besides there
were some technical considerations, e.g. version control and issue
tracking support.

to expand: we would have had to move all the code to their servers,
which run CVS and other older tools; currently we are running SVN and
will have Jira and Confluence up and running soon...we hate to go
backwards :wink:

- thomas

13

Rong Chen wrote:

Hi Stef,

I was present in that meeting together with Thomas Beale. The view
from the Java community at that time was that the benefit of moving
any Java component projects to OHF wasn’t obvious to us. Besides there
were some technical considerations, e.g. version control and issue
tracking support.
to expand: we would have had to move all the code to their servers,
which run CVS and other older tools; currently we are running SVN and
will have Jira and Confluence up and running soon…we hate to go
backwards :wink:

Exactly!! We might need Wiki too. =)

/Rong

14

Rong Chen wrote:

15

Hi Ignacio

No, I think this is an effort, with the NHS in the UK, to get a standard user interface for health care - across applications. The “Eclipse Open Health Framework (OHF) is the official open source organization for HL7” and is not, as far as I am aware, an official IBM effort. It is a place to put Java code that might be used by others at the moment. Already there are other Eclipse based efforts in the wind.

The Micorsoft/NHS effort involves things like the patient identification at the top of the screen, how dates are displayed so they look the same in all countries (1/12/2007 will mean very different things in different settings) and how to deal with partial dates (e.g. just the year is known). The source code is available for people to use in their applications with the conditions as in a previous mail. This will suit many software vendors.

So I am interested in these widgets, both for forms and web, as a way of helping the average software provider deal with openEHR data types. There is no reason that I know of why people can’t produce their own widgets that look the same in Java - but these are .Net. Why don’t we build a set of Java equivalents? I think this will be seen as a positive effort and there may already be open source efforts to do this. It should be with Apache 2 I guess if it is to be used widely.

Cheers, Sam

Ignacio Valdes wrote:

16

Thomas Beale wrote:

Rong Chen wrote:

Hi Stef,

I was present in that meeting together with Thomas Beale. The view
from the Java community at that time was that the benefit of moving
any Java component projects to OHF wasn't obvious to us. Besides there
were some technical considerations, e.g. version control and issue
tracking support.

to expand: we would have had to move all the code to their servers,
which run CVS and other older tools; currently we are running SVN and
will have Jira and Confluence up and running soon...we hate to go
backwards :wink:

with respect, the technical considerations were just that: technical.
For instance, eclipse has wiki, and svn, and other things can be hosted.

There were deeper issues to do with community motivation and the way
this relates to licensing and how relationships are built and managed.
The eclipse rules are rather imposing in these regards, and there is
cultural differences between the communities. I still think that
collaboration will make sense, but we are not at this point right
now.

Grahame
OHF project lead.

17

I'm a long way behind, and playing email catch up.

just a technical clarification:

> last year - it is problematic, as it prevents you from using well-known
> bits of other open source code, because it is primarily designed to a)
> avoid encumbrance of the code by other licenses of any kind and b)
> ensure that changes to code in the Eclipse code base can be done without
> reference to anyone else. We couldn't even use it for the openEHR
> (GPL'd) java kernel because the latter uses libraries that wouldn't be
> allowed by the EPL. The EPL induction process is also painful - it takes
> weeks/months to get your code 'reviewed' by Eclipse people to certify it
> as 'unencumbered'...meanwhile it will have changed..

I don't think (a) is a property of the EPL license itself. But
it is certainly exactly how the Eclipse Foundation vets code
that will be posted to the official eclipse cvs.

Grahame

18

Grahame Grieve wrote:

I'm a long way behind, and playing email catch up.

just a technical clarification:

> last year - it is problematic, as it prevents you from using well-known
> bits of other open source code, because it is primarily designed to a)
> avoid encumbrance of the code by other licenses of any kind and b)
> ensure that changes to code in the Eclipse code base can be done without
> reference to anyone else. We couldn't even use it for the openEHR
> (GPL'd) java kernel because the latter uses libraries that wouldn't be
> allowed by the EPL. The EPL induction process is also painful - it takes
> weeks/months to get your code 'reviewed' by Eclipse people to certify it
> as 'unencumbered'...meanwhile it will have changed..

I don't think (a) is a property of the EPL license itself. But
it is certainly exactly how the Eclipse Foundation vets code
that will be posted to the official eclipse cvs.
  

I'm not trying to be critical as such - its just that Rong found code
that we would be prevented from using if we converted the license to EPL.

In the end, I don't think I am really convinced by the need to have a
special license for the Eclipse project; there are clearly some license
that the code can't use, but it seems unrealistic to me to try and make
it one. But prepared to be shown the light....

- thomas

19

Hi Sam and Thomas and others!

Just a quick followup - a while ago you mentioned that you were thinking
of uploading your Microsoft code to the openEHR website.

Are you still considering doing this? I would absolutely like to see
what you have done. Even if you could only upload a few samples to
illustrate what is working well, and what areas are not working so well,
that would be excellent.

Regards

Gunther

20

I don't think (a) is a property of the EPL license itself. But
it is certainly exactly how the Eclipse Foundation vets code
that will be posted to the official eclipse cvs.
  

I'm not trying to be critical as such - its just that Rong found code
that we would be prevented from using if we converted the license to EPL.

yeah, this is not easy. (though as I said, it's not just converting
to EPL, it's subjecting to the full eclipse processes)

In the end, I don't think I am really convinced by the need to have a
special license for the Eclipse project; there are clearly some license
that the code can't use, but it seems unrealistic to me to try and make
it one. But prepared to be shown the light....

well, I look at it this way: eclipse is a reliable proposition for everyone:
no surprises. I doubt that we (kestral) could use the openEHR java kernel corporately
because of GPL issues. I do not have the skills or the time to find out exactly
what I can and cannot do without inadvertantly subjecting my corporate stuff to
GPL. But if I use eclipse code (not just EPL), I know that appropriately skilled
and highly motivated people have done this for me.

So for a project to "become" eclipse, and to actually mean putting the code
up on eclipse, it has to jump these hurdles. Why do this?

pros:
  - will increase target market of the code substantially. however, while in tools
    market, the corporate benefits of eclipse in this regard are well recognised,
    I don't think there's the same brand penetration in the healthcare sector regarding
    Eclipse sanitising your code for you
  - will allow a full engagement between multiple communities, in particular, the
    community that is growing around eclipse

cons:
  - have to jump the hurdle. It can be quite high and painful. The more mature the
    project, the more painful, (and possibly the pros are reduced here too)

If I was you, I wouldn't be making the change right now either. I think that the
correlation of forces will change in the future, and then I will ask you to
re-evaluate.

In the meantime, we are pursuing alternate pathways that will enable community
collaboration with more flexibility about how the price is paid and when. There
should be public announcements soon.

Grahame