people and organsations (particularly those working in health care IT) are entitled to be paid for the work they do and are entitled to protect their IP
--- ## Post #6 by @rupertfawdry Open Source is useful but it totally fails to tackle the fundamental dilemma of healthcare IT worldwide i.e. our massive Plain English Inter-operability impasse. Traditional IT tools such as Data Modelling,Coding, Data Dictionaries are of no use in making medical IT systems Inter-operable That will only because “Analysable and linkable Electronic Patient Records (EPRs) will only attain their true potential for improving the quality of patient care and reducing the risk of human error, without excessive data re-entry overload, when, in each speciality and sub-speciality - following intense, open, web-based discussions - bit by bit their detailed, logically and chronologically-arranged, flow-patterned questions and the full range of all allowable answer-options (always including, whenever needed, “Unknown -Free Text” and “Other - Free Text”) - are, by stages, taking into account as many interested parties as possible, individual question by individual question, internationally standardised.” It really does not matter whether a hospital uses open source or proprietary software or whether it uses Snomed or any other code or whether it uses the code called “Plain English” Such matters are almost irrelevant compared for example the need that every IT system which included the Question “Title?” should always insists that the only allowable answers should be for example: “Mr, Mrs, Miss,Other (Free Text) Almost every database everywhere used a different fixed set of answers and not one of these is ever genuinely “Inter-operable" --- ## Post #7 by @stuartabbott They're also entitled to give it away for free if they want to do so. Open Source is a choice. --- ## Post #8 by @clive.spindleyKIS - at the national patient level, name , postcode, dob - no one has asked me for my title for ages, and of course NHS number, as deemed law by the house of lords (forgot his name, but i am sure he won't be offended ;-))
--- ## Post #9 by @clive.spindleyexactly, i might be happy to give some away for free (e.g. on a cataracts PERSON pathway) but probably not other
(e.g. on a testicular cancer PERSON pathway), if organisations are not able to distinguish between the different types of health data,
then shame on them, forget it, but your point is exactly right, it should be our ... choice
--- ## Post #10 by @damienhampton Hi all, Can anyone provide specific examples of where open source options have been overlooked/rejected in favour of non-open source options and where the decision was either because of, or influenced by, a preference of non-open source? I'm interested to find out more in this area and examples would certainly help me. Thanks in advance, Damien --- ## Post #11 by @mayfield.g.kev Do you mean open source as in ripple or endeavour product or the open source projects (tomcat, Java, camel, Spring, etc) it uses. On security, scalability, safety most common solutions use open source projects (inc most commercial offerings). The big difference is the technical knowledge you need. NHS (trusts and smaller) doesn't have many app or systems specialists (except HSCIC) and its security teams are hardware focused. Those app people it does have tend to be front line support and rely on commercial for 3rd line app support. --- ## Post #12 by @rory.davidson It all comes down to the solution and whether it is open source or not should be irrelevant. Whether a solution is open or closed is far from an indication of the quality of software as there are good and bad examples in both worlds. Open or closed software is also not an indication of the cost of implementing the solution either and in my experience costs have been similar. I think that the barriers really come down to the lack of an overall, completely open source solution which meets users and purchasers requirements. And importantly as per the last post, a lack of technical teams locally to support the use of open software. You end up paying for the services whatever you do, so, again, whether it is open or not becomes a moot point. Also worth noting, I have never come across any specific policy of not using open source, and more often than not, there have been policies of prioritising the use of open source over closed. --- ## Post #13 by @mike.buck we see quite a bit of confusion around open source - one area not mentioned above is procurement not being quite sure how to buy something that is essentially free. Other things that we've seen reflect the other comments on security, supportability and the like. There is a lot of comfort in traditional licensed software in that it often comes with maintenance and with committed to roadmaps and the like. Clearly opensource can do that too but it needs the community to focus on it. --- ## Post #14 by @stuartabbott I have had our ICT department chose closed source over open source due to a lack of support for the open source solution. Essentially they like being able to sign a solid support contract with a supplier to ensure they can get things fixed if they go wrong. Whilst this does not exclude open source (and ICT are happy to use open source) it has steered a lot of ICT systems to non open source solutions. --- ## Post #15 by @phillip.rust In my opinion (I seem to have too many of these) i believe the following are a couple of reasons people do not engage with open source solutions (Not Languages or Frameworks): * Service Management - there is a general concern that solutions that are open source will not have good ITIL/ISO Standard service management with reasonable response times. * Change Management - there is concern that change in an open platform is difficult to manage. Feature management and development line merging is a full time job in an open source solution. * Compliance, IG and Legal - there is concern that open source solutions will not have gone through the stringent checks that most "Medical Device" systems would be required to go through. Therefore if there is an incident relating to the solution who is legally responsible. * Code quality & Performance - there are concerns relating to the general quality of the code and how that affects both performance and the users experience. * Longevity & Sustainability - there are concerns that the cadre of developers that came together to develop the original solution may lose interest or may not gain enough interest to fund the key internal management processes required to make the solution viable, thus leaving the consumers of the system without support and maintenance. Just some of my thoughts. --- ## Post #16 by @PhilBarrett Some very interesting patterns emerging within there. Should make for a good report which I'm sure many would want to share wider. --- ## Post #17 by @PhilBarrett Thanks for all the contributions, really helpful. Kevin - I mean Ripple, openeyes, endeavour etc, so OS solutions and platforms rather than projects/components. I personally think there is a lack of trust and understanding of what OS is and a fear that things can wither and die, and then where is the client/trust left. So the underlying business and support models seem key within this. The fact that OS is widely used across other industries as part of solutions but not openly or proactively promoted means generally awareness of OS remains low. I think organisations are often looking for a steer from central government departments to say that going down OS is fine. Whilst the NHSE Open Source programme, C4H are really championing this, I think this also needs a consistent or strong leadership message from all departments to bring OS into the mainstream and normalise it. I also think that the freedom or flexibility OS can provide can also spook people as they are perhaps not used to having a choice, control or say in the solutions. --- ## Post #18 by @phillip.rust Interesting open source comments on FOI. I notice a couple of them refer to mirth(Implied when people say open source TIE) which is quite a mature product that is pretty well managed and you can buy service support from them. Which provides a good financial model for running a business. Other feedback on the FOI is people developing in house "open source code". Which i think is a great way of bringing together health developers and sharing experience, however most trusts would struggle to provide the support / service agreements required to deliver a managed service relating to their open source product. Would be great if someone could work on a framework for organisations on "how to scale up a sustainable open source solutions" --- ## Post #19 by @wolandscat I find there is a bit of a disconnect in the replies here. The big difference between (most) open source and commercial software production is that _open source is a production method_, whereas commercial is a _production and a delivery method_. In other words 'open source' as a team organisation (e.g. many of the projects we have on openEHR) is designed to _create_ software, but not sell it. Selling it means being able to engage in contracting activity and taking legal responsibility for supply and maintenance. A lot of OS groups can't do this. The big ones like Apache are different, because their core devs come from tech giants and work full time. There's no need for a contract, because the product is already being built and maintained in a professional way. Linux is an interesting case. The core is so high quality it's almost a non-contest against closed OSs. But w.r.t. the consumer versions, well it's clear that they don't respond that well to users, witness the regular and ongoing UI/UX wars in Linux land (Unity anyone?). In any case, again, the core devs are full time. And - in these large projects, there is professional project management. It's a lot harder for a small open source project to do what these giant projects do - even if the dedication and professionalism is there (in our openEHR corner of the world, the majority of open source is built by software professionals) - they usually work part time on it; they don't get paid extra if they work more than business hours, so response to problem reports is not guaranteed to be within a time frame or prioritised to a given customer, and so on. In summary: all 'contracted' software is 'commercially' supplied, regardless of the way the source code was developed, or its license. It's perfectly reasonable for a trust to want a legally and technically responsible entity to act as supplier - even if it is the IT department, it has to have a dedicated team that takes responsibility. Without this identifiable responsibility, noone knows who to point to when things go wrong. My mental test: just start with patient safety and work your way back - where does the buck stop? The corollory of this is: if trusts etc want good open source solutions on a contract basis, they have to be prepared to pay properly, and forget the delusion that open source is somehow 'free'. It is free of runtime _licences_, but not maintenance-time _costs_. --- ## Post #20 by @damienhampton Hi Stuart - Are you able to be more specific about what the requirement was and/or what the candidate solutions were, please? (please accept my apologies if the question is inappropriate!) --- ## Post #21 by @ben.sewell82 Lots of proprietry EDMS's have been procured by trusts. This is silly seeing as Alfresco is a big player and leader in the world of EDMS. --- ## Post #22 by @andy totally agree, just being opensource does not make the project right ultimately you need to find a group of people who can do a good job and support the project after its been developed, having avenues available so you are not tied into those people for ever more (if its commercial) is a contractual thing which does not necessary rely on it being opensource. --- ## Post #23 by @malcolm_newbury Come on folks, surely this question needs to move on. The real question is Why don't organisations and suppliers admit that they are using open source and go further and promote the type of open source platforms they are using ? Maybe suppliers might be concerned that the competition will get hold of their secret sauce and maybe do a better job of it? Maybe organisations are concerned that they will be admonished by the closed source supplier community and their commissioning organisations? Putting my white hat on - perhaps its time to introduce inducements tpublicise the wonderful array of open source platforms serving our healthcare market? Putting my black hat on - maybe its time organisations insisted on open source labelling of software so that vulnerabilities in open source platforms can be addressed more urgently? Yes - Why not press for Open Source labelling of software used in healthcare? Malcolm --- ## Post #24 by @mayfield.g.kev couple of comments on the open source I've used: Alfresco Activiti - think this would be really useful to complement our EDMS but have concerns on support ability especially when contractors (in NHS trust) have left. Similar to Phillip comments on trust adoption. Mirth - tends to be used for small integrations. for bigger imlllementations it needs investment in staff and paid for model. I'd prefer to just move over to Apache equivalents which are better supported outside of health (and work well with FHIR) Apache tomcat - introduced by commercial suppliers. See alfresco comment plus it works ok but suppliers expected more know how on NHS side. Apache camel - organisation/people resistance. Works very well but change in technology (and pace) is worrying people --- ## Post #25 by @michael.wray Hi Kevin Interesting you mention activiti. We've been using that for a couple of years now and it forms a major part of our pathway/protocol engine. I'm a big believer in bpm, and it's great to finally have a decent open source option. It gives you compliance, auditing and monitoring all out of the box. And Bpmn is a visual language which everyone can understand; a perfect fit in my opinion. --- ## Post #26 by @mayfield.g.kev Have any trusts used Alfresco? It seems very powerful - BPMN2, googledocs, CIMS integration, libreoffice, etc. It would need development resources for a trust (even with the enterprise version) but that has to be expected with a powerful edms. Also needs more skills with support and network teams (Apache*) but I see that as unavoidable (many commercial products need same skills). I've looked at Afresco Activiti, same comments as above but also would help if project teams move away from flowcharts to BPMN2. --- ## Post #27 by @pacharanero [quote="mayfield.g.kev, post:26, topic:309"] Have any trusts used Alfresco? [/quote] I'm not a trust but we used Alfresco Community Edition for the CCIO Leaders Network as a filestore/document repository, alongside [Discourse](https://www.discourse.org/) for our forum. I found it extremely hard to configure and set up, clunky and slow to use, and underfeatured (for example _even a basic feature like forgotten password recovery required an additional plugin_ - which itself was very buggy). We eventually just retired it. Using it for an EDMS in a hospital setting would (from my experience with it) require so much configuration and development that you are almost as well starting from scratch with a more modern web framework and writing something bespoke. I was left feeling that Alfresco Community Edition was what they I **OSINO** (Open Source In Name Only), meaning it is basically there as bait to get you interested in buying Alfresco Expensive Edition™. During the time we were using Alfresco CE I was besieged by Alfresco's marketing team asking if we wanted any help setting it up, but apart from the marketing calls I couldn't get them to _actually_ help, they were basically just doing a 'wallet biopsy' for how likely we were to buy the paid edition. I never even got to see an installation of the paid edition so I'd love to see whether the OOTB features are better. Maybe I was doing it wrong. I'm certainly not a Java developer. If anyone's got any pointers I'd be interested. M --- ## Post #28 by @mayfield.g.kev Cheers. My gut feeling was the community version would be a none starter, EDMS is so complex you'd need the support of a commercial supplier and the cost of doing it ourselves would be huge (don't mean writing our own version). What version did you use? Had a browse around v5 which seems to have angularJS front end (if it's like activiti, the older version probably used some java product). Don't think the ootb version would be that much different, it's going to need a certain amount of tomcat, spring, etc knowledge. Think we'd be able to use it dev environment to illustrate concepts and ideas. --- ## Post #29 by @paultargett Sorry, I am late to this tread. I think this question is confused by the difference between using open source components in a solution to the overall solution being open sourced. Many of the solutions encountered these days have some open source licensed software in them. Often the overall system providers is respecting and supporting those licensing agreements. So using Python or MySQL is using open sourced components. Many years ago I have had IT Managers refuse to support MySQL over SQLServer. For no reason other than they only understood Microsoft. Now I find that IT Managers are very open to those kind of solutions and are often using software themselves that is open sourced. Then we come to OpenSource applications for health and social care. I think there is a catch here often at the moment. These solutions are frequently only really supported by one company - who is open sourcing the application but is really the only option for configuration and delivery. That's the honest trust at the moment I think. For me a solution that is truly open source can be supported and built on by any company - not just one or two. As an example, we've just installed SuiteCRM for a health care client and that is an open sourced solution that uses open sourced components and can be configured and added to by a number of companies. --- **Canonical:** https://openhealthhub.org/t/what-do-you-think-the-barriers-are-to-adopting-open-source/309 **Original content:** https://openhealthhub.org/t/what-do-you-think-the-barriers-are-to-adopting-open-source/309