Thanks Derek and Ryan and Hannes for the comments and questions. Excited to see the community reviewing and feeding back.
I’m going to do some inline commenting below:
···
On Fri, May 22, 2015 at 9:16 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Derek,
Thanks for the comments. Some responses to your points:
- I agree, we must not sacrifice any of the endpoints that are required by the standards, the OpenSHR must still act like two separate actors, however, they should come in a more convenient package for implementers sake.
- This is a sticky point for me as well. I agree the guideline based alerting is best done in a separate tool such as an ICP processor or such from the work you are currently looking at. However, for some simple clinical alerts it may make sense for the SHR to fire them. Such as a drug interaction. This is always an issue and doesn’t rely on the context of care like the ICP guidelines would. We should determine if this makes sense for the SHR to do this and then we could work with Carl Leitner to see how this could make use of the emerging mACM standard.
- Agreed, this is an important issue for the future of the project. It would be better to fail early than once we have built all this other supporting software.
- This is a tough challenge, I don’t have too many ideas here.
Cheers,
Ryan
Agree with this and both your and Ryan’s points about making it more accessible to the implementer without foregoing our architecture and functionality as per OpenHIE. I think it is also important to note that we need to keep the implementer first and foremost in the project as building for the sake of architecture will create shelfware – building to support implementations (that are informed by and inform the architecture) has a good chance to actually create IMPACT! and we can all agree that is what we are looking for.
I want to caution about over loading the line in the requirements here. I believe that we as a community are respectful and behind supporting more components within the HIE architecture and particularly those of ICP. However there has been a need for the SHR to be able to “trigger” events (aka alerts) from within itself and its data store that could spark off a larger workflow that is more interlinked between OHIE infrastructure components. I.e. “this patient’s weight has dropped by more than 20% in the last 3 months”. I think it would be great to have this discussion on the SHR call in a few weeks time as to ensure that we aren’t duplicating functionality and already underway work and development in other components. I do feel that the SHR does need a simple mechanism of defining trigger rules that can and possibly should be eclipsed by a more fit for purpose alerting component in the long run.
I agree! 100% completely, all in, ek-se! I think, should we agree to take on this OpenSHR product approach, that we prioritise this as a primary design requirement and focus on this at the start!!
I think you have created our “litmus paper” test for design, feature and prioritizatoin of items on the OpenSHR roadmap here. “Is OpenSHR a vaiable SHR for implementers?”, "is it stable and reliable, fast, resource weary (i.e. we don’t have ALL of AMAZONS data centres to operate it and we have to be sparing on the assumptions of “spin up another server”), easily deployable - maintainable and operational?
We should be moving away from the question of “Should we use OpenSHR?” towards the question of “Why shouldn’t we be using OpenSHR if it gives us all of XXXX out of the gate?”
When you refer to the term Vendor are you focusing primarily on other open source tool curators or trying to encourage commercial tools to come to the party? if it is the commercial I believe that this is a broader challenge that the entire OpenHIE community need to take up as our “About Us” is quite focused on “Open Architectures”, “Freely available”, “Open Source” (all phrases from the front page of www.ohie.org). The challenge would be in how to bring on commercial vendors without threatening them or them feeling that there is no role for them in the bigger communities. (I ask that if this is a discussion that is going to come out of this mail that we split the email thread and start a new one not to detract from the OpenSHR discussion). If however the question is more towards encouraging other Open Source tools to become part of the community and strive towards being a viable OHIE compliant SHR then that would be good to discuss and get a list of tools and communities that we may want to approach. (@Shaun: any thoughts from your side?)
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org
On Thu, May 21, 2015 at 5:07 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
These are, indeed, fundamental questions. Here’re a few thoughts that I think we need to take to heart as we talk about productizing the OpenSHR tool. We cannot lose sight of our explicit mandate, as the SHR community, to evolve and curate OpenHIE’s specification regarding shared health record services as well as our implied (not explicit) mandate to ensure there is at least one viable open source option that meets this spec. There are a number of ways these twin duties might impact (or perhaps should impact) how we approach software product planning:
-
Overloading multiple actors (e.g. XDS registry, XDS repository) into a single product is fine… but we need to remain cognizant of the **non-SHR related workflows** that also need to “touch” the XDS registry. I’m thinking particularly about PIX-related transactions, here. Even if we bundle a registry and repository actor together in OpenSHR, we need to separately and explicitly expose the registry actor.
-
I was surprised to see “alerting” as a feature in the OpenSHR product plan. We are working (in this dev cycle) with IHE’s QRPH community to explore a standards-based way to express and operationalize ICPs and alerting is a key part of this work. A parallel work item in IHE’s ITI committee (led by Carl Leitner) has been looking at a specific profile for alerting. I understand the attraction of framing alerting as a “custom module to OpenMRS”. Such an approach, however, runs the risk of us being poor stewards of the OpenHIE **specification**. Re-usability is part of our mandate; our specification has to “work” with other, IHE-conformant XDS repositories, too.
-
Lastly, I believe we need to treat the SHR’s performance targets as a **must-have**. I raise this because we have danced around issues related to our use of OpenMRS as the underlying database for OpenSHR. Transaction-processing throughput has to be treated as an engineering constraint that trumps developer convenience. We have to make the SHR run 10x faster than it does right now and I would recommend against us putting effort into any additional functionality until that metric is met. This is a key decision point; if thru-put targets cannot be met then OpenMRS either needs to be forked or abandoned as the database choice.
I’m excited about this product planning process for OpenSHR – but I also feel an apprehension. Some of the things that are crucial for implementation success are not the fun things. To be blunt, as we enter OpenHIE’s implementation phase, I most favour the boring things that can take some of the “excitement” out standing up a working, national-scale HIE instance. The right SHR in a low resource environment is a stable, reliable, wicked fast, easy-to-setup and easy-to-maintain database that holds all the CDA content we might send to it and can give it back to us when asked. In my view, OpenSHR’s immediate term product plan must lead to its inclusion in the list of “right” SHRs for implementers.
As a larger challenge, I think we need to explore the very awkward question: how do we attract other IHE-conformant repository “vendors” to our OpenHIE community… and to what degree might our role as a donor-funded “competitor” impede this?
DJ
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality.
From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Ryan Crichton
Sent: Thursday, May 21, 2015 8:35 AM
To: Hannes Venter
Cc: Carl Fourie; openhie-shr@googlegroups.com
Subject: Re: OpenHIE Shared Health Record - OpenSHR
Hey Hannes,
Thanks for raising this. Those are some really important questions. I think currently when we refer to the OpenSHR we really mean the XDS repository implementation that OpenMRS plus the SHR modules provid. However, as we begin to move toward more of an OpenSHR ‘product’ I think we should make things as easy as possible for the end user and, as you said, hide some of the complexities of XDS from people getting started.
So, I’m beginning to think that we need to think about including a default registry in our OpenSHR ‘bundle’ or ‘distro’. I’m curious to see what the other in this community think. Please let us know your thoughts. This may be quite a fundamental decision that we need to make for our reference app.
Cheers,
Ryan
On Thu, May 21, 2015 at 1:10 PM, Hannes Venter hannes@jembi.org wrote:
Hi Carl,
Thanks for sending this out. I think this is exactly the approach we should be taking and I’m excited to see where this will lead!
I just wanted to add another point to this discussion:
Are there any thoughts or ideas around the XDS.b Registry?
I think it’s important to note the OpenMRS SHR isn’t by itself a complete SHR solution, as you’ll still need a Registry in your infrastructure.
(the OpenMRS SHR provides the XDS repository functionality - i.e. it’s actually only half of what you need for a complete solution, the registry is the other half).
So the point I really want to raise is what does OpenSHR means in terms of XDS?
Is OpenSHR equal to OpenMRS + OMRS SHR Modules plus Registry Software
or are we saying the OpenSHR is just the OpenMRS SHR?
I think if we’re talking about productizing the SHR; and importantly abstracting away from all these pesky XDS things! 
then this will be important to address. Some options I can think of:
- should we have a recommended registry?
(e.g. OpenXDS doesn’t support On Demand Documents so probably shouldn’t be recommended)
- should we develop a registry that gets included in the OpenSHR package?
(e.g. develop OMRS registry modules)
- or do we just leave it for an implementer to figure out?
Anyway, just wanted to mention this and hear what everybody’s thoughts were?
Kind Regards
Hannes
On 20 May 2015 at 13:42, Carl Fourie carl@jembi.org wrote:
Hi all,
After yesterday’s call around the SHR one of the exciting points that came out of the discussion was the need to look at taking the current technical work going into the OpenMRS-SHR work and look at getting behind a more focused “Product” approach to the SHR. Towards this the team has drafted a beginning brief of the concept. Please find it here and an excerpt pasted below:
https://docs.google.com/document/d/1C6jOo93xWKQbpKw2WSt2JBTz74J7oWcEVqT4qSBg4gU/edit#heading=h.7jknqcbpj3tr
We encourage careful thought and consideration towards the approach and concepts, the priority areas and scope. We are excited to be taking the work done within the existing OpenMRS tool and SHR and focus it with the refined understanding of the implementations.
Overview
The Open Shared Health Record (OpenSHR) tool is the OpenHIE’s reference application of the Shared Health Record community. The tool encompasses the requirements of the OpenHIE SHR as well as recognising the requirements to reduce the barrier to uptake of the tool. To this end the SHR community is embarking on a journey to create a stable product that enables decision makers, implementers and developers to rapidly get started with an SHR.
Core Principles of OpenSHR
· Have a reliable stable tool: a defined, tested and stable version of the tool and required components.
· Performance focus: have a tool that is performance tested and has published performance figures
· Feature ready: the tool will come with preconfigured and available features and functions of the SHR.
· Administration and maintenance: Easier to setup and configure as well as monitoring of the operations of the tool
Features
The following are the key features of the OpenSHR too.
Preloaded CDA processors
OpenSHR comes preloaded with a set of (insert list) CDA content processor modules. This allows any CDA document that contains the loaded sections to be processed to discrete data stores. In addition OpenSHR allows the addition of custom built CDA section processors (see module repository for available processors)
Preloaded CDA document generators
OpenSHR comes preloaded with the ability to generate documents on demand from the data store as well as an extensible framework allowing developers to rapidly extend the available CDA document generators required for their implementation.
Ability to request original documents
OpenSHR allows users to request all original documents submitted (in lieu of document generation) for a patient.
Trigger/Alert Generation
OpenSHR contains an basic alerting engine that allows implementers to define alert rules based on clinical and data stored in the SHR. OpenSHR will work with existing efforts within OpenHIE to support the more comprehensive and complex alerting patterns and engines.
Aggregate Data Generation
OpenSHR comes preloaded with the functionality to generate aggregate data exports. These exports and functionality will be complementary to the work and efforts of the HMIS community.
Dashboards
OpenSHR comes with an operations and oversight set of dashboards to facilitate easier monitoring of operations as well as key indicators.
Admin and Configuration panel
OpenSHR has an intuitive configuration and administration section designed to better support implementers in setting up the SHR and administering its’ functional growth (adding of new processors etc.)
We look forward to any comments and contributions as part of the SHR community.
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Hannes Venter
Senior 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 “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
then this will be important to address. Some options I can think of: