Concrete Implementation; Minimum Threshold for Recommendation
The Design Principles page says "rough consensus, working code". Up to the point of creation of this workgroup, no code has been built specifically for NHIN Direct, though there exists plenty of pre-existing code for the protocols and functions described. To graduate to a "recommended implementation", we likely do not need a complete, debugged, one-click installable suite of software that demonstrates the implementation. But what do we need? If we ask each proposed implementation to build too much before being declared the focus, we may end up without any winner. If we do too little, we may end up with a recommendation without much substance or trust. Here are some proposed criteria.
- A self-identified community of supporters willing and capable of building a reference software implementation in the overall NHIN Direct desired timeframes, and the other artifacts and deliverables along the way, including the below.
- A software "map" for each implementation. Of the participants in the Abstract Model (plus other actors - a Certificate Authority perhaps, or another sort of directory service), what software does each party need to run in order to fulfill its role in the system? Described at one layer higher than a specification, this should describe the collection of specific software required for a demonstration, biasing towards production-quality software. For functions that are mandatory to fulfill the User Stories, the map must point to software licensed under an Open Source license that allows for integration into proprietarily-licensed software, so to accelerate adoption.
- For all actors in the system, a description of the end-user experience sufficient to author a user interface OR a similarly Open Source licensed example application that provides the desired end-user interface.
These criteria are in addition to the other criteria of the Workgroup, but are in service to them; for example, each User Story must be covered in the above deliverables. An overall picture of how an HIE would work with each implementation is desired (pending input from the Robust HIE workgroup on what else they'd like to see, if anything).
- How much of a "proof of concept" would be useful to making the recommendation, without writing the end-user interfaces?