Reminder: Do not include any PHI or PII in Confluence. If you require 508 accessibility assistance or any other support for this system, then please send an email to onc-jira-questions@healthit.gov
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)
- Begins with stating “problems to be solved” (e.g. based on identified barriers & other documents)
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