# Microsoft/NHS common health interface and openEHR datatypes **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2007-07-09 23:07 UTC **Views:** 4 **Replies:** 24 **URL:** https://discourse.openehr.org/t/microsoft-nhs-common-health-interface-and-openehr-datatypes/14653 --- ## Post #1 by @Sam 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 --- ## Post #2 by @Tim_Churches 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 --- ## Post #3 by @Andrew_Patterson > 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 --- ## Post #4 by @Ignacio_Valdes 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 --- ## Post #5 by @yampeku Well, in fact OHF is EPL not GPL http://www.eclipse.org/legal/eplfaq.php --- ## Post #6 by @Stef_Verlinden1 In that respect: what was the outcome of the OHF in Germany, in which an openEHR component proposal should be made? Cheers, Stef --- ## Post #7 by @system 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 --- ## Post #8 by @system 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 --- ## Post #9 by @Stef_Verlinden1 > 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 --- ## Post #10 by @ricardo.jc.correia Is there any roadmap/guideline to the implementation of graphical components that work with openEHR data types? Ricardo Correia --- ## Post #11 by @thomas.beale 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 --- ## Post #12 by @thomas.beale 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 ;\-\) \- thomas --- ## Post #13 by @system > 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 ;-) Exactly!! We might need Wiki too. =) /Rong --- ## Post #14 by @thomas.beale Rong Chen wrote: --- ## Post #15 by @Sam 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: --- ## Post #16 by @grahamegrieve 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 ;\-\) 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\. --- ## Post #17 by @grahamegrieve 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 --- ## Post #18 by @thomas.beale 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 --- ## Post #19 by @Meyer_Gunther 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 --- ## Post #20 by @grahamegrieve >> 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 --- ## Post #21 by @thomas.beale Thanks Grahame, that's a good clear summary\. We certainly look forward to ways of working with the Eclipse effort in the future \- I agree that the 'pros' you list should be attainable at some point; the concrete nature of the costs will become more evident as time goes on\. \- thomas Grahame Grieve wrote: --- ## Post #22 by @system Hi Gabriele I know that some people within the NHS CUI group are absolutely committed to a Java version. We are hoping to work with the team to do a full open source .Net implementation of the controls which should be a good basis for the Java work. I hope someone from that work contacts you via this email but if not let me know. Cheers, Sam gabriele.it wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #23 by @Tim_Cook2 I am not 100% certain on this but after a conversation with some people inside the NHS NPfiT program it does seem that the CUI documentation maybe licensed in such a way as to not allow for open implementation\. This probably needs more legal research before we go off adopting it\. ??? Cheers, Tim --- ## Post #24 by @Ime_Asangansi Hi everybody, I have noticed the 'archetype a day' page on the wiki but apparently it didnt move on to the rest of the community. Or was it invitation-only? I think a periodic webcast might help too for the openehr (just as other communities do eg eclipse, UMLS, etc) ... maybe its funding issues? I noticed that most of the archetypes on the site are in 1.0 I will like to ask: is there any plan to re-edit the archetypes in adl 1.0 to 2.0.? Or does the cost outweigh the benefits? Thanks. rgds, Ime --- ## Post #25 by @system Hi Ime The AOM, internal model of archetypes is 2.0, and so the XML is conformant to this. ADL in use is 1.4 which copes with everything but is a little arcane in some respects. So the XML schema is AOM 2.0 if you want something to get your head around. Cheers, Sam Ime Asangansi wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- **Canonical:** https://discourse.openehr.org/t/microsoft-nhs-common-health-interface-and-openehr-datatypes/14653 **Original content:** https://discourse.openehr.org/t/microsoft-nhs-common-health-interface-and-openehr-datatypes/14653