All,
As we think about being more diligent with what does it mean to be conform to OpenHIE, one of the first things we need to do is to be clear about what OpenHIE is. To do that we propose to put renewed emphasis on creating releases of the OpenHIE specifications. One of the first steps is to identify the content that will be in a release and the community entity that is responsible for creating and curating each bit of content.
Once we have the content identified, then we will address additional steps, such as creating a release schedule and identifying the format (possibly multiple PDFs).
Thanks for raising this, looking at it I think the one area that I would hold off on including in the âofficial releaseâ is the reference technologies. My stand in this is that the architecture and workflows should be published as a referenceable document (drawn from the WIKI) but in a way that allows us to create validation tests for software etc. I would see a release constituting something like:
OpenHIE Architecture vX.x
Architecture Diagram
Workflows (as youâve stated)
Architecture Components (descriptions of function - short)
Architectural Components minimum base functions (as required to accomplish the workflows)
Architectural Component interface and standards requirement (this is extrapolated from the workflows and is something that the SHR did a while ago as well as the IOL)
The latter allows us to answer the question â what are the interface functionality required to be seen as a functioning <<insert type : facility registry, MPI etc >> component of the HIE.
// END Release
Then from there we are able to extrapolate
OpenHIE Reference Technology lists
each technology can then be compliant to a particular version of the OHIE Architectural release
When we build testing and compliance frameworks we can reference which version of the OHIE release it is conformant to / or testing against.
When implementers create packed HIEâs they are able to reference which version of OHIE workflows it supports etc.
RE: * Architectural Component interface and standards requirement (this is extrapolated from the workflows and is something that the SHR did a while ago as well as the IOL)
I think some communities included this on their page with their component requirements (see https://wiki.ohie.org/pages/viewpage.action?pageId=29593103 âStandards and Workflowsâ) However, not all components included this. Is this what you are referencing? If so, we have it for several communities and can draft it for the rest.
Perhaps Iâm down in the weeds on this, but to me a release is about a testable workflow exactly like a CI approach. The workflow is tied to specific software releases and a compatibility matrix.
In GitHub, âreleasesâ are actually tied to the SHA of the relevant commit. So, for a given release compatibility could be tested. Preferably, this happens with every pull request in CI fashion.
Example: iHRIS mints a new release. Then, as part of a health worker registry interoperability workflow, an environment is stood up with synthetic data to ensure that the basic mCSD transactions continue to work when a new health worker is added.
Since OHIE is not really software, but a specification, I was thinking that any testing of software would state what release of the OHIE standards it complies with. Itâs a bit tricky as I think we will need to think about this from OHIEâs perspective and from the software product teamâs perspective (as you well represented). I donât think OHIE wants to be in a place where OHIE is dictating a new version of the OpenHIM or of iHRIS. Rather, OHIE will want to publish the specification and software can be deemed to comply with that version or not.
Perhaps the issue is with the word âreleaseâ? Should it be something more clear like âSpecification 1.0â?
Above I was suggesting that the mCSD workflow, not software, is the product. The mCSD workflow can include software, and I think it could as a way to provide value as noted above about e2e testing. The workflow is a product which adds value to the specification.
As an end user, I would go to the mCSD workflow repository and find the narrative of the specification and its versions and tools to use it and validate that my own products can be tested against. The mCSD workflow is a product for me to use as a reference. Itâs but one way â not the absolute â to try out the specification.
I think some communities included this on their page with their component requirements (see https://wiki.ohie.org/pages/viewpage.action?pageId=29593103 âStandards and Workflowsâ) However, not all components included this. Is this what you are referencing? If so, we have it for several communities and can draft it for the rest.
Yes that is the type of flow I was thinking about â would be good to standardize this. I know the IOL and SHR teams did a specification document too in the past.
Thanks Carl! Quick question: what is the difference between your bullet #3 and bullet #4?
Bullet #3 is that narrative pitch of a few lines that can be put on a slide or in a proposal without the âchecklistâ of functional requirements.
Bullet #4 is the list of functionality that I would expect to see in a slightly longer RFA or Appendix of what a CR/SHR/ etc would need to be able to do. Here it would also list out our list of required standards etc.
@rstanley (I pretext this with possibly being off point) I think you are a bit down the road in the mCSD example. From my reading I think the description of the:
mCSD workflow repository and find the narrative of the specification and its versions and tools to use it and validate that my own products can be tested against.
This could be a further extension of the OpenHIE Architectural Specification to accommodate the e2e (assuming end to end) testing. Etc.
I would love to chat about this on the next OpenHIE architecture call â also this is key for us to better understand how we help community members claim or measure the validity of a tool being âOpenHIE compliantâ
To @rstanleyâs point, I do think though a release should require some minimal PoC (by no means enterprise ready) implementation code with sample/fictitious data, which a CI tool could process. This may help iron out critical ambiguities in behavior which only present themselves, once one tries to encode the workflow. We all been there, we write a set of non-functional requirements, and then the implementation immediately raises significant practical requirements questions.
