Thanks, Chris – this is a useful “framing” regarding target markets. My sense is that there are many other possible users/user cases, but adding to the list won’t necessarily add to the “palette” of the discussion. The is a really good start.
I think we are helped by now looking for the implications of Chris’ scenarios… and here would be my starting foray into doing that:
Our “product” should scale. Even at the “small country” end – we are talking about managing 10^6 person-centric records. That isn’t huge for most databases, but we need to be cognizant of the fact that it is huge enough that any query working against non-indexed data will be way too slow. Likewise, any large joins and any “loops of loops” will be complete non-starters from a performance standpoint (our performance target should be “sub-second” for any one query). So… this will tend to favour some de-normalizing, or similar techniques which may be categorized under the heading of crimes of convenience which we will be willing to commit in the interests of high performance.
We need to support multiple languages in our product. I think, right off the bat, we should also design for supporting double-byte languages. This is something that hasn’t been mentioned yet… but it is usually (in my experience) incredibly difficult to “bolt on” after a product is built. This means all error messaging, etc., needs to come from language-specific lookup tables.
Chris’ NGO scenario seems to favour puzzle pieces that “stand alone” as well as “work together”. This means standards-based interfaces that can talk to the outside world… and talking to the outside world means supporting all the authentication, security, privacy, etc. issues that go along with making sure you keep protected health information protected. Personally… this is one of the first functionality elements I would walk away from. Requiring every openHIE puzzle piece to work with/without a HIM will add a huge amount of redundancy to every one of them. I think a “lighter HIM” would be a better approach; one that could readily/easily be included with a standalone SHR, for example, to do the “don’t talk to strangers” bits.
The “whole system” has to hang together and work… right out of the box. I think this aspect is both fundamentally important and grossly underestimated. It is fundamentally important because it may be the strongest value proposition we could possibly have, for any country, of any size. The value proposition is: “your starting point is a national health information system that WORKS”. That is a hugely important value proposition.
I think we are underestimating what “works” means, though. “Works” means, out of the box, openHIE would be able to execute 8-10 core workflows in a guideline-adherent way. These core workflows, in my view, can be and should be expressed in “business” terms (as profiles, for example):
- enroll a client
- resolve to a unique client ID (e.g. establish a person-centric care context)
- record person-centric health information (observations, history…)
- order lab tests
- record lab results
- order drugs
- dispense drugs
- refer a client
- log a discharge summary for a client
- support person-centric queries for information
The list might not even be 10 items long. A case could be made for omitting #4, for example (as an eHealth transaction) and #9 is really a specialization of #3. My point is, in the face of a small number of “verbs”, quite sophisticated guideline-based workflows may be articulated. In fact, even with this small set of verbs our guidelines for maternal, HIV, TB and chronic disease management can be pretty much fully described. Likewise, if content is coded (and therefore computable), pretty much every indicator that we need can be generated from the eHealth transaction logs. At present… our “product” does not do these 10 things and it cannot be “programmed” using workflow languages (such as BPMN) and it does not generate reportable indicators. We are still quite a long way from being a solution that could be adopted wholesale, without modification. Personally, I think getting “there” should be our primary goal, above all others.
Regarding the medium-sized country that will naturally want to highly customize openHIE… I’m of two minds. To be sure, for any open source software stack, anyone can open it up and do whatever they want. And if they do… and they break it… then they broke it. That really doesn’t create for us any kind of new demand from a product standpoint. I think, if we have an appetite for it, we can support a set of “productized” levers that allow modifications to the openHIE stack that don’t “break” it. In my view, the most useful set of levers we could provide would be a BPMN-based interface that would support custom workflow definitions. As long as these definitions employed our “verbs” and as long as the codes/terminologies could be mapped using our Terminology Server, the new workflows would just… work.
So… how is all this relevant to a discussion of our interoperability layer? Architecturally, the HIM is what turns a set of disparate point solutions into a system. It is at the HIM that coding/terminology specifications are enforced and, if necessary, code mappings happen. It is at the HIM that orchestration happens… and, if we decide to support it, guideline-based WORKFLOW is executed. If we think of our list of 10 building blocks, it is the HIM that makes them be something useful; something that actually supports coordination of care and yields improved health outcomes. Regardless of the customer segment… the HIM’s ability to coordinate point solutions strikes me as openHIE’s core “product functionality”. Honestly, I don’t think any point solution should be rolled out without also deploying a HIM. Such a deployment pattern would ensure that, whenever each new puzzle piece is put in place, there is an immediate integrative benefit and an improved “system” effect.
Other than that… I have no opinion on the matter… 
Derek.
···
On Friday, May 10, 2013 9:08:08 AM UTC-4, Chris Ford wrote:
Hi all,
As I mentioned on the last call, I think it would be a good exercise if we thought through who the customers of a HIM and SHR would be.
If I were developing a commercial application, I would try and articulate personas that capture the different segments of the public that might be interested in my software. Here is my attempt to do the same thing for OpenHIE:
A medium-sized country with:
- a population of ~40 million
-
5 official languages
- potential international donor support for eHealth programs
- a health system where NGOs and private institutions complement government facilities
- internal software development and hosting capability
A large NGO with:
- a presence in multiple countries in a region
- many long-term projects aimed at producing positive health outcomes
- various software applications, developed in-house
A small country with:
- a population of ~10 million
- 2 official languages
- a centralised health system
- little in-house software development or hosting capability
I think that these three “customers” might want to interact with OpenHIE in different ways:
- The medium-sized country might want to significantly customise OpenHIE, discarding the default orchestration for their own software that might implement workflows very specific to that government and incorporate data from other systems
- The NGO wish to use a subset of OpenHIE to track health outcomes over time e.g. the provider registry and the SHR but not the HIM or facility registry.
- The small country might want to adopt OpenHIE wholesale, without customisation
Do these use cases resonate with others on the list? Are there any others that I’ve failed to think of?
Cheers,
Chris
This is a fundamental discussion that we need to work through.