Bob Dieterle

Alix Goss

Patrick Murta

Dan Chaput

Rick Geimer

Alex Kontur


Solutions Documentation Template


Purpose:

  • Template created in coordination w/chief architects, ONC, and PoCP
  • To be used across Tiger Teams to describe what a solution may look like
  • Can be modified as needed
  • Look and feel of the template is based on the use cases documentation
  • Still need to determine appropriate level of granularity for solutions


Format:

  • First couple of pages are background, including an intro section and reference documentation (e.g. use cases, technical barriers, regulatory barriers, etc.)
  • Proposed solution overview
    • Begins with stating “problems to be solved” (e.g. based on identified barriers & other documents)
      • Bob – meant to represent all of the problems the Tiger Team has identified, or a single problem?
      • Murta – generally a full list of problems, but may want to separate based on different domains. Template provides guardrails which can be adapted to a Tiger Team’s needs. Possible to include multiple solutions, or solutions that relate to each other in some way, but more solutions may make it harder to interpret the document
      • Bob – some issues stand-alone…e.g. scaling across intermediaries vs. ability of responder to respond in real-time despite large volume of transactions. Do we map the list of issues we’ve identified to the solutions we’ve identified, or do a separate solution for each issue?
      • Murta – we should create the content and then worry about formatting later
    • Proposed solutions – include everything we have considered as a solution (included options that we declined)
      • Alix – should we use our expertise to guide a single solution, or present options?
      • Murta – most Tiger Teams will have a preferred solution, but want to include other options and why we didn’t choose them
      • Bob – 3 categories of solutions: preferred/alternatives, considered/parking lot, considered/rejected. May be documented differently. Recommend including other considered solutions in the document, but not up front (e.g. an appendix). Include viable alternatives as a parking lot (i.e. we’ve looked at them, they may work, but lack strength and won’t be developed more fully); I haven’t rejected but I’m not recommending as preferred (e.g. due to regulatory barriers, cost/operational barriers, etc.)
      • Murta – body of document should include proposed solution, appendix includes other considered/rejected solutions w/lighter documentation
    • For each proposed solution, include a diagram (embedded hyperlink provides “use case” iconography which can be leveraged for the diagram). Include numbered steps with description/notes in subsequent table
      • May use a “swim lane” diagram and/or “wiring” diagram
    • Pre-conditions/post-conditions – e.g. a regulatory change
    • Solution component analysis – describe components, attributes, whether the solution is new/already exists, what needs to be built/modified, who should “own” the solution, etc.
    • Key impacts to timeline & cost – “t-shirt sizes”, i.e. a broad feeling for cost/level of effort (as a general order of magnitude, e.g. small, medium, large)


Alix – what happens with the documentation once completed by the Tiger Team?

  • Murta – once populated by Tiger Teams, will be reviewed by other Tiger Teams and from an overall architectural perspective, and then published


Bob – we’re jumping from a problem statement to a solution. Do we need to represent current state, future state, and potential pathways between? Going from a problem to a solution implies a single step, but a lot of these won’t be. The problem statement should reflect the current state but won’t necessarily describe it completely.

  • g. for versioning, the current state is that we have 3 different versions of FHIR (1 partially adopted, 1 not really adopted, 1 likely to become part of ONC requirements) with more coming out. The problem statement should explain why that is an issue. A potential solution (e.g. a normative version of FHIR) doesn’t necessarily tell us what to do w/existing data or how to align multiple production versions, so there is a need to describe the pathway from current state to future state. The solution doesn’t necessarily describe the future state or how to get there.
  • Alix – here is the issue we identified. This is a problem because the current state is “x” and the future we want to get to is “y”. We understand that there are a set of solutions, but there will likely be short/medium/long-term steps that we need to take. The template should reflect our thought process so people can comment appropriately
  • Murta – Begin with current state overview and problems to be solved, then identify future state and proposed steps to get there
  • Bob – may want to include commentary about an intermittent state (if necessary). We are painting a picture in intermediate and future states (e.g. if I want to go from DC to LA, I might want to stop and sightsee along the way). The solution needs to reflect our goals, and needs context to explain it
  • No labels