Hi Craig
Great to have you weighing in here.
I think you have a good point here about the different types of implementers - are you looking at this from a technical level of those who need to "wire up" the tools primarily or a more holistic approach as from "what governance and agreements do we need in place to implement a central HIE"? I think there is definitely scope for us to understand what both groups would be looking to get from OpenHIE and what information they would find most useful.
I've added a heading on the wiki page for the assumptions you list here. I'm wondering what you are thinking around the concept of DATA ACCESS? is this how OpenHIE allows data access or what data is accessible by who, how to configure etc?
With the concept of workflows for when things go wrong is the thought here within the software or more SOPs for real world persons?
WRT to the sandbox question I think this is something that we should definitely consider and we would want to unpack what the thinking is around here. Some of the previous discussions in the Sandbox community have been around what types of reference / demo features would be useful for implementers to see and be of value. At this stage it has come down to options around:
(i) A reference OpenHIE that exposes all the workflow endpoints that interested PoC's can knock against to see how one could contribute towards being part of, say, a Maternal Use Case and that shows how OHIE manages the data (showcasing the OHIE architecture in action)
(ii) A reference PoC that is able to consume and contribute to the OHIE workflows (showing how a PoC could leverage the OHIE functionality to advance its implementation or network of implementations)
How does this fit with what you were thinking?
A lot of questions here, Craig your email has a great mine of conversation starters, and it would be great to get input from others on these too.