User Story Meeting 2010-04-12

Notes from User Story Review Workgroup Meeting
Status of Notes: DRAFT
Date: April 12, 2010
Time: 11am-12pm
Attendees: Honora Burnett, Jackie Key and Arien Malec, Dan Russler, David Kibbe, Didi Davis, Gail Graham, Hank Fanberg, John Moehrke, Lee Jones, Paul Tuten, Peter DeVault, Robert Lynes, Steven Waldren, Susan Torzewski, Steve Krsacok, Joannie McHugh & Keith Boone
Actions

#	Date	Action	Status	Owner	Due Date
14	4/12/10	MOVE conversation about rewording the Must definition to “this provider with certified EHR module can use this type of exchange” to a discussion on the Wiki	Open	Arien/Peter	4/19/10
15	4/12/10	Have later conversation about how NHIN Direct will incorporate needs of small business partners	Open	All	4/19/10
16	4/12/10	Reflect in “Must” definition that all User Stories don’t have to be implemented in their entirety, just the ones that fit	Open	Complete	4/19/10
17	4/12/10	Consider writing a User Story for Long Term Care Facility	Open	Arien	4/19/10
18	4/12/10	Generalize the title of “Message sender receives delivery receipt”	Complete	Arien	4/19/10
19	4/12/10	Create Table correlating all User Stories to their Meaningful Use requirements	Open	Arien	4/19/10
20	4/12/10	Specifying the governance process from how stories will get added within the Wiki	Open	Arien	4/19/10
21	4/12/10	Language for Must stories tied to meaningful use will be made consistent with NPRM terminology	Open	Arien	4/19/10

Decision

#	Date	Decision
3	4/12/10	Must definition is within a limited scope and tied to MU requirements

Notes
Agenda and Framing

1. Review of last week’s action items
2. Discussion

Review of last week’s action items

• Review “Must” and “Should” stories
  • In this group, be sure to pay attention to the Lab Story
• Review User Stories
• Create Related Stories Section in template
• Create language around receiver acknowledging the receipt of the message
• Keep language high level, as the user experiences it
• Correlate use case language to abstract model language
• To create a succinct sentence which states that the PCP has already decided it is okay to share info

Discussion

• Arien in Glue Fashion:
  • Individual involvement workgroup would like this group to elevate four stories that are related to hospital sends to patient to must
  • Justification:
    • Required for MU
    • Strong desire not to leave the individual out
  • In general look at must vs. should

Comment from Peter DeVault

• Required for MU
• Provider/Hospitals send patient health information to the patient
• Discharge instructions and procedure should be included
• Language for Must stories tied to meaningful use will be made consistent with NPRM terminology (Arien)

Comment from Dan Russler

• Setting up two tables instead of one so that everyone is clear which are the stories that came from consensus building
• Create a table correlating stories to MU requirements (Arien)
• No indication of how stories get added – what is the governance process
  • Specifying the governance process from how storied get added within the Wiki (Arien)

Comment from Didi Davis

• • Likes MU table

Comment from Gail Graham

• • User story for long term care facility (Arien)

Comment from John Moehrke

• • Message sender receives delivery receipt
  • Thought we were going to bring this to a higher abstraction
  • Generalize the title of the story for delivery receipt (Arien)

Comment from Robert Lynes

• Separate eligible hospitals vs. eligible professionals
• Mapping between stories and MU criteria will highlight that

Comment from Susan Torzewski

• What will be should?
  • Full IG will weigh in and reflect on too many musts
  • If you squint, all stories look the same
  • Is there real word variation?

Comment from Steve Krsacok

• Does elevating these to “must” change the implication of implementation
• Is the scope expanding?

Comment from Joannie McHugh

• Adding patient stories because they
• Many of the MU criteria can be met on paper or handing user drive with CCR or CCD
• Good for transactions to flow to patient where they are
• What are we committing to for scope

Comment from Steven Waldren

• Authentication/Authorization

Comment from Keith Boone

• Scope of what people are being asked to deliver

Around the room on overall of must/should

• Must – NHIN Workgroup, maps to MU requirements or required to deliver another story – bad thing if we designed Implementation or specifications that didn’t allow for this
• Should – Maps to MU
• Could – doesn’t map to MU requirements

• Must first test: design of the specification and then in the actual implementation
• How about working functionality?
  • Arien: when we get to implementation time, is it okay if someone wants to implement just the hospital ambulatory stories or does real world have to implement all of them?
  • Ideally, all use cases should be implemented, but not all of them will in reality do that
  • Some vendors that serve certain market segments can’t do them
  • Weave this into must/could/should – that must stories don’t have to be implemented in their entirety (Arien)
• Must for this group should mean it is required by MU

Comment from Dan Russler

• LATER CONVERSATION: NHIN Direct is to incorporate all the needs of small business partners
• EX: small retail pharmacy
  • Include group homes, retail pharmacies – small organizations that need to participate

Comment from David Kibbe

• Keep this targeted to MU
• Suggesting to keep this simple, and small group of MU related use cases

Comment from Didi Davis

• Specify policy from NHIN Workgroup
• Must definition needs to have policy language clarified

Comment from John Moehrke

• Assure success through scoping

Comment from Lee Jones

• Don’t put the timing on the must/should

Comment from Paul Tuten

• MU has been guiding principal
• Struggle: mid-tier of should stories
• Could have must stories, could stories – but middle ground of should doesn’t provide a lot of clarity

Comment from Steven Waldren

• Limit musts
• Should – what we decide/put together doesn’t limit one
• Watch out that we don’t have scope creep

Comment from Steve Krsacok

• Which musts need to be delivered soon and which ones need to be delivered later?

Comment from Keith Boone

• Keep simple, but implementable

Decision: Must is within a limited scope and tied to MU requirements

User stories: receive data without full certified EHR

• Fall short in measuring stick of scope and MU
• Propose that it moves into a should
• 1) Original work that Wes and David McCallie did – Meet physicians where they are
• 2) Possibly refine definition to: “provider with certified EHR module can use this type of exchange” (Peter DeVault)

Comment from Peter DeVault

• Can’t leave this open to certified EHR
• Modular certification might not be good to include
• If we include EHR module, that would be good and can

Comment from Dan Russler

• Can’t make declaration that either source or destination has to be certified EHR but the other one has to be a member of the health care community

Comment from Gail Graham

• Clarify intent of this

Comment from Hank Fanberg

• What is the objective – force towards MU or improve healthcare?
• Disservice to make this mandatory for a certified EHR

Proposal: draw the line of what we are trying to accomplish

• Data exchange with any level of tech
• Scoping: try to make sure that anyone with EHR module can exchange data

Comment from John Moehrke

• Concerned about the way that the certified EHR is being addressed at this point
• We are using these scoping mechanisms to say that this kind of environment is our scope, and no one else can use a specification for what
• Primary output of NHIN Direct – specification for how to satisfy these uses and not certification guidelines

Comment from Lee Jones

• Premature and influence what certification means – defining what is relevant

Comment from Steven Waldren and Keith Boone

• On page we put a precondition or assumption that we are talking about technologies trying to get supported
• Important to realize that no one has a certified EHR
• Focusing too much attention on certification will

Summary of discussion

• Propose another wording that captures the intent:
• Intent of the story: provider with a simple client (referrals inbox) intent is to clarify within scope that it is possible to have a simple inbox like client that does referral coordination of care – sending/receiving of information that can be minimally met
• MOVE conversation about rewording the Must definition to “this provider with certified EHR module can use this type of exchange” to a discussion on the Wiki (Arien/Peter)