User Story Meeting Notes 040410

Notes from User Story Review Workgroup
Status of Notes: DRAFT
Date: April 4, 2010
Time: 11am-12pm
Attendees: David Kibbe, Didi Davis, John Moehrke, Lee Jones, Steven Waldren, Brett Peterson, Honora Burnett, Jackie Key and Arien Malec
Actions

#	Date	Action	Status	Owner	Due Date
7	4/5/10	Review “Must” and “Should” stories In this group, be sure to pay attention to the Lab Story	Open	All	4/12/10
8	4/5/10	Review User Stories with NHIN Cooperative and State	Open	All	TBD
9	4/5/10	Create Related Stories Section in template	Open	Arien	4/12/10
10	4/5/10	Create language around receiver acknowledging the receipt of the message: i.e. “Source (message sender, initiator) has knowledge of their request being delivered”	Complete	Arien	4/12/10
11	4/5/10	Keep language high level, as the user experiences it	Complete	Arien	4/12/10
12	4/5/10	Correlate use case language to abstract model language	Open	Arien	4/12/10
13	4/5/10	To create a succinct sentence which states that the PCP has already decided it is okay to share information	Complete	Arien	4/12/10

Notes

• Review of last week’s action items
• Review of User Stories
• Discussion

Discussion
Review of First User Story: Primary care provider refers patient to specialist including summary care record
Comment from Steven Waldren

• Assumptions could be known as preconditions or post conditions
• Assumption was that pre conditions and post conditions
• Notion of the story is that it makes clinical business sense and incorporates key user experiences
• Technical details will include technical pre/post conditions
• High level user feel for pre and post condition
• We need to write this from a users perspective
• Discussions would fit well within acceptance, where the more formal piece goes
• Action Item: To create a succinct sentence which states that the PCP has already decided it is okay to share information
• Have almost stated as preconditions that the privacy issues have been dealt with

Comment from Brett Peterson

• Like how the business story is being briefed, called out in the data exchange section
• Within the actors section
• One doesn’t exist in the abstract model
• Action Item: Correlate our user cases to the model directly in terms of language
• Abstract model calls end points

Comment from John Moehrke

• Action item: keep this language high level, as the user feels it
• User doesn’t know what a REF i12 message means, and if we deliver the components through
• Ideally structured case would consist of a structured description

Review of 6th User Story Message sender receives delivery receipt

• Message sender received receipt
• Is there more to write here, or is it good as simple?
• Action item: Create a “related stories section” in the template?
• Action Item: the receiver needs to acknowledge that they received the message
  • “Source (message sender, initiator) has knowledge of their request being delivered”

Review of 5th User Story: Laboratory sends lab results to ordering provider

• Two issues to comment on:
  • 1) Feedback on those two stories
  • 2) Discussion of what the right process is to get to a finalized list of must have stories that will inform the rest of the discussion that will inform this process

Comment from John Moehrke

• Lab results
  • Action Item: Language should be more general about what the data being exchange includes
• Process – where do we stop?
  • Somehow to lock this down to a reasonable set, or we will forever be adding to it
  • Matter of cutting it off when we have a complete list, but that is difficult to measure
  • We know the community this is targeting, what do they need in the next few years?

Comment from David Kibbe

• Stories
  • Fine with these
• Process – where do we stop?
  • How much latitude do we have in spheres of influence to compel people to use NHIN Direct pathway
  • We don’t have any control over laboratories
  • If the use cases cover most of the provider, and at least one individual patient use cases
  • We also don’t need to consider every single provider type out there as actors, because as they try to become part of the communication network then they’ll comply because they will have reached a critical mass
  • As a group we just need to agree this is stopping
  • We know the community this is targeting, what do they need in the next few years?

Comment from Didi Davis

• Process – where do we stop?
  • Will these use cases be vetted with HIE?
  • Might vet with others
  • Action Item: take these user stories and:
    • Review with the NHIN Cooperative
    • Review with State

Comment from Lee Jones

• Stories
  • Stories 1-4 are what he would vote on for an initial set, moves the industry forward on something that isn’t standardized in practice
  • Do we really need #5, Lab?
    • Might be hard to get this moved through the big research lab
    • To do this in real word, it might be easier to be successful with 1-4
• Action item: the group should review “must stories” and “should stories”
• Must: with abstract model and concrete implementation you can satisfy the story within the first version of the policy workgroup
• Should: nice to do this, but also mean that there are additional policy considerations we may or may not get t**
  • • Arien: there is a specific MU requirements to incorporate this to allow for use of NHIN Direct Address towards lab
    • Kibbe, interesting to include this
  • #6 is an extension of other cases
  • #7 isn’t a must – a secondary concern to EHRs certified
• Process
  • This group is the initial forum to debate the merits to come up with something though our own consensus process and then bring it up to others

Comment from Brett Peterson

• How to move forward
  • Go back to design principals “keep it simple,” “when in doubt cut it out”
  • Focus on deadlines
  • Take short set of stories and bring to implementation group
  • ACK/NACK story, added into Abstract Model
    • In Abstract Model there is nothing that says “must or shall”
    • For the set of must have stories (Lab, this would have to be in there) and to give feedback about the user story ACK/NACK to be perceived as critical and included in the Abstract Model
    • Brett: all or nothing
    • Arien: Group will make decision: we can say that ACK/NACK is not important because set of must have use cases don’t need it, or even in provider refers to specialist there is an expectation that the PCP knows the referral all the way through
• Business term: as a source, I have a business need to know that the information I sent was delivered or received by the destination
• Talk about this in more high user expectation that it was delivered
• Important to user experience for delivered/red
• Read status – the destination addressee has actually, from a business workflow perspective –
• 1) Understanding transaction has arrived and ready for human to see
• 2) Human has seen this and is ready to act on it?

Comment from David Kibbe:

• Impossible to the business case for it to be demanded to be read or acted on
• Complicates the process
• Need to say this was delivered, and to the right person