We’re nearing the end of our tool evaluations and have put together a recommendation argument based on the results.
See the attached first version of this document.
Based on our evaluations, we currently feel that OpenHIM is the best option to move forward with.
Executive Summary
The evaluation of interoperability tools showed that there are a number of open source products that could be adapted to function as an operability layer for OpenHIE, but the tool which fits our use case most closely is OpenHIM. This tool would need to be built out further in order to meet every feature requirement of OpenHIE and build a stronger community around it, but the core architecture design and the fact that it is fully open source, with no important features that are only available commercially, make OpenHIM our interoperability platform of choice.
Any feedback is more than welcome (even if it’s just an affirmation!) and any comments can either be sent to the mailing list, or discussed on our SHR community call.
We will be discussing this topic in depth on our next call taking place on Tues 9 July 2013 4pm CAT / 10am EDT.
Thanks to everyone for their hard work defining requirements and evaluating options.
Personally, I’m not convinced that the requirements we’ve identified call for a HIM at all. I think the process has led us towards the up-front selection of a tool like OpenHIM, when OpenHIE might not be best served by a central ESB-like component at all. Central components that mediate entire systems do not have a good recent track record in producing sustainable and evolvable systems.
As a community, we’ve identified possible needs and been asked to come with a piece of software that satisfies them. There are two potential problems with this: that our requirements aren’t a good reflection of actual system needs, and that a single piece of software is not what will best serve the system’s needs.
If I were part of a software project of similar scale for a client, I would normally imagine the following sequence:
Gather requirements on the whole system based on specific users and use cases
Decide on an initial architectural style and shared protocols and APIs that will mediate communication in the system (Derek has spoken at length about this)
Incrementally select and incorporate components as system requirements call for them
Evolve the shared standards and APIs as we learn more about users’ needs
We’ve skipped ahead to #3, largely because we don’t have visibility on #1 or a forum or mechanism for #2.
My worry is that our selection of OpenHIM, without reference to actual users and prior to us thinking through shared protocols and whole-system architectural style, might bias future work. I realise that as per our last community call, we intend to qualify our recommendation based on potential future revelations, but I’m still very keen that our work thus far doesn’t end up impeding the incrementalist approach I believe has the greatest chance of success.
We’re nearing the end of our tool evaluations and have put together a recommendation argument based on the results.
See the attached first version of this document.
Based on our evaluations, we currently feel that OpenHIM is the best option to move forward with.
Executive Summary
The evaluation of interoperability tools showed that there are a number of open source products that could be adapted to function as an operability layer for OpenHIE, but the tool which fits our use case most closely is OpenHIM. This tool would need to be built out further in order to meet every feature requirement of OpenHIE and build a stronger community around it, but the core architecture design and the fact that it is fully open source, with no important features that are only available commercially, make OpenHIM our interoperability platform of choice.
Any feedback is more than welcome (even if it’s just an affirmation!) and any comments can either be sent to the mailing list, or discussed on our SHR community call.
We will be discussing this topic in depth on our next call taking place on Tues 9 July 2013 4pm CAT / 10am EDT.
Kind Regards
Hannes
– Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
Sorry I couldn’t reply sooner but I have been away on leave. You make some very good points here.
I agree with you that the requirements that we have described do not call for a single central component. Both a single central component or a set of interacting services could play the role of the Interoperability Layer. I agree with you that a central component that mediates an entire system doesn’t have a good track record, however, good ESB-based solution should be made from a number of de-coupled sub-systems (preventing a single point of failure and becoming a monolithic system itself). I believe there is opportunity take the OpenHIM as it is currently built and to more cleanly split it into sub-systems or services that provide the functionality that we identify in the requirements. I don’t think it should be architecture as a single monolithic ESB-like system. I believe that we could modify it to be simpler, more modular and extensible.
That being said, perhaps we should explore how we would build such a system from scratch considering the requirements we have now identified. This may give us some better insight into what the system we are describing in the requirements could look like. We could then see if there are any parallels with the OpenHIM or if, perhaps, we could benefit from drawing from multiple other tools to build a better solution.
I agree with the second part of your email as well. It does seem like we have missed some steps. I think there are 2 reasons for this. Firstly, there hasn’t been a forum for discussing some of these issues with the greater OpenHIE group. Now, that there is architecture list we can start to bring up and talk through these issues. I plan to put down some of my thoughts in that list soon, but please feel free to bring the main issues that we see with the larger group and we can help move that discussion forward. Secondly, much of OpenHIE grew out of the Rwandan health information exchange project and thus some of the whole systems requirements and design decisions have transparently carried through from that project. I don’t think these have been clearly discussed under OpenHIE through and I think we should help make this more clear. Again, I think beginning some of these discussions on the architecture list will help drive this forward. I will add some of my assumptions that carry through from the Rwandan project to the email that I plan to send to ensure we can all be working off the same understanding.
Hopefully this will help us all reason with how the interoperability layer should be designed.
Thanks to everyone for their hard work defining requirements and evaluating options.
Personally, I’m not convinced that the requirements we’ve identified call for a HIM at all. I think the process has led us towards the up-front selection of a tool like OpenHIM, when OpenHIE might not be best served by a central ESB-like component at all. Central components that mediate entire systems do not have a good recent track record in producing sustainable and evolvable systems.
As a community, we’ve identified possible needs and been asked to come with a piece of software that satisfies them. There are two potential problems with this: that our requirements aren’t a good reflection of actual system needs, and that a single piece of software is not what will best serve the system’s needs.
If I were part of a software project of similar scale for a client, I would normally imagine the following sequence:
Gather requirements on the whole system based on specific users and use cases
Decide on an initial architectural style and shared protocols and APIs that will mediate communication in the system (Derek has spoken at length about this)
Incrementally select and incorporate components as system requirements call for them
Evolve the shared standards and APIs as we learn more about users’ needs
We’ve skipped ahead to #3, largely because we don’t have visibility on #1 or a forum or mechanism for #2.
My worry is that our selection of OpenHIM, without reference to actual users and prior to us thinking through shared protocols and whole-system architectural style, might bias future work. I realise that as per our last community call, we intend to qualify our recommendation based on potential future revelations, but I’m still very keen that our work thus far doesn’t end up impeding the incrementalist approach I believe has the greatest chance of success.
Cheers,
Chris
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
We’re nearing the end of our tool evaluations and have put together a recommendation argument based on the results.
See the attached first version of this document.
Based on our evaluations, we currently feel that OpenHIM is the best option to move forward with.
Executive Summary
The evaluation of interoperability tools showed that there are a number of open source products that could be adapted to function as an operability layer for OpenHIE, but the tool which fits our use case most closely is OpenHIM. This tool would need to be built out further in order to meet every feature requirement of OpenHIE and build a stronger community around it, but the core architecture design and the fact that it is fully open source, with no important features that are only available commercially, make OpenHIM our interoperability platform of choice.
Any feedback is more than welcome (even if it’s just an affirmation!) and any comments can either be sent to the mailing list, or discussed on our SHR community call.
We will be discussing this topic in depth on our next call taking place on Tues 9 July 2013 4pm CAT / 10am EDT.
Kind Regards
Hannes
– Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.