Design Principles

Overall

1. The Direct project will create a transport level set of specifications and services that can handle multiple types of content, from unstructured (text, PDF, etc.) to semi-structured (various CDA templates, HL7 MDM, etc.) to fully structured (CCR, CCD)
2. Questions of content (e.g., CCD and CCR) will be handled through profiles on top of the resulting specifications and service descriptions
3. The specifications and service descriptions will handle all Must have User Stories
4. The specifications and service descriptions, in a trust framework, must enable the highest degrees of security and privacy consistent with federal and state laws
5. The resulting specifications and services must be simultaneously deployable by an organization that deploys the existing Nationwide Health Information Network standards and services
6. The resulting specifications and services must not overlap or duplicate existing Nationwide Health Information Network specifications or services. They may provide a "on-ramp" set of specifications and services
7. The design will, along with a policy framework, enable nationwide scalability without requiring nationwide or transregional organizations (e.g., nationwide provider groups, nationwide HIOs, statewide HIOs) to maintain individual point connections to all participants
8. The design will enable a key role to be played by enabling organizations, including state HIOs and SDEs, to route messages, enable trust, and enable value-added services
9. The design will incorporate connectivity to eligible providers and will accommodate a variety of technology types (including installed EHR, modular EHR, enterprise EHR, SaaS EHR, etc.)
10. The design will incorporate at least one connectivity model wherein an installed EHR makes only outbound transactions through a firewall (that is, where the provider need not open an TCP/IP port to the open internet)
11. The design will accommodate the typical IT environment for a small practice (e.g., installed EHR, dynamic IP address, no or limited IT support)
12. The design will accommodate an EHR connectivity model that can be natively implemented by a small development team working in a language with modern library support
13. The design will enable limited scale production deployment late 2010 and wide scale deployment 2011
14. The design will accomodate and recommend, in the content layer, the provision of sufficient content metadata to enable automated processing by the receiving system, but will not require providers who do not need the metadata to supply it
15. The design will allow HISPs or intermediaries to fulfill transport needs without access to content or content metadata.

Process Guidelines

1. Open questions of policy will be referred back to the Nationwide Health Information Network Workgroup, not solved in the Direct effort, although the Direct effort may recommend solutions
2. The golden standards rule of "rough consensus, working code" will be applied to this effort.
3. Discuss disagreements in terms of goals and outcomes, not in terms of specific technical implementations.
4. The Direct project will adhere to the following design principles agreed to by the HIT Standards Committee from the feedback provided to the Implementation Workgroup (as documented on John Halamka's blog posting as well as in Aneesh Chopra's report back to the HIT Standards Committee).

Rules

	Rule	Interpretation
1.	Keep it simple; think big, but start small; recommend standards as minimal as possible to support the business goal and then build as you go.	it is better to release a set of standards and services early that provide basic support for some of the core meaningful use measures than work longer to create a more complete set of standards and services.
2.	Don’t let “perfect” be the enemy of “good enough”; go for the 80% that everyone can agree on; get everyone to send the basics (medications, problem list, allergies, labs) before focusing on the more obscure.	When in doubt, cut it out. Better to do without something if you possibly can. See also Sean Nolan's blog post
3.	Keep the implementation cost as low as possible; eliminate any royalties or other expenses associated with the use of standards.	Design for simplicity, include nothing that relies on particular language or platform features or special purpose libraries, release commercially friendly open source reference components, no standards should have patent encumbrance.
4.	Design for the little guy so that all participants can adopt the standard and not just the best resourced.	Assume EHR module implementors are 2 developer teams sitting in their garage creating the next big thing. Make their life easy, not hard.
5.	Do not try to create a one size fits all standard, it will be too heavy for the simple use cases.	Design for simple transport, and that's it.
6.	Separate content standards from transmission standards; i.e., if CCD is the html, what is the https?	Solve the basic transport problem using the Internet as the transport substrate and support multiple types of content, from text to PDF to semi-structured and highly structured (HL7, CCD, CCR). Let later work package content profiles with the basic transport.
7.	Create publicly available controlled vocabularies & code sets that are easily accessible / downloadable	Document everything that is needed to implement, and make it freely available with commercially friendly open content and source licenses
8.	Leverage the web for transport whenever possible to decrease complexity & the implementers’ learning curve (“health internet”).	Keep transport simple. REST/ simple interoperable SOAP/SMTP over TLS. Think and design like the Internet. Don't design custom XML vocabularies to solve packaging and transport needs.
9.	Create Implementation Guides that are human readable, have working examples, and include testing tools.	Produce this level of documentation as we go.