Technical Strategy

Our Philosophy and Technical Strategy
H2A believes in the power of health care service networks and light-weight open frameworks that produce learnings or actual components that can benefit the entire Health 2.0 community. H2A is not creating another standards organization, but instead building a network where companies can collaborate through loosely coupled business services to build simple or complex solutions that meet the evolving needs of patients and the health care industry. By promoting the use of light-weight open frameworks and leveraging existing standards wherever possible, H2A participants will be able to ease deployment, interoperation, and distribution of services. Loosely Coupled Services

More about light-weight open frameworks

Numerous frameworks in the software industry offer a very large and rich collection of components. Sometimes these are so full featured that an entire application may be constructed without venturing beyond what the framework provides; these are heavy-weight frameworks, such as Rails and Spring. Light-weight frameworks are on the other end of the spectrum, taking a minimalist approach and in many cases pointing to third-party standards and implementations to fill framework spots rather than providing these directly with the framework.

What should be considered for an H2A light-weight open framework?

  • Definition of solution architecture and specification of its technical artifacts
    • Components, services, containers, interfaces, adapters, models, connectors, messages and message formats, protocols and processes
  • Designation of:
    • Selected standards utilized in the solution
    • Implementations utilized in the solution, both open source and commercial
    • Compatible alternative standards and implementations
  • Components:
    • Open Source code if it was developed
    • Pseudocode
  • Development guidelines, templates and interpretations
    • e.g., how a designated technical artifact was actually used
    • Best Practices
  • Documentation:
    • Factors driving technical choices
    • Pros and cons discovered in working with technical artifacts
    • Known problems, limitations, workarounds, etc.
    • Lessons learned
    • Results from each participant
  • Access to demonstrations of the solution
    • If possible given security and privacy concerns
    • Screen shots and walk-thru or video tour of the solution otherwise

See the DPI cast study for an example of an H2A project and light-weight open framework.