User Story Review 2010-04-10
Jump to navigation
Jump to search
Notes
Agenda and Framing
1. Review of last week’s action items
2. Discussion
Review of last week’s action items
· “Must” definition is within a limited scope and tied to MU requirements
· 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
· Have later conversation about how NHIN Direct will incorporate needs of small business partners
· Reflect in “Must” definition that all User Stories don’t have to be implemented in their entirety, just the ones that fit
· Consider writing a User Story for Long Term Care Facility
· Generalize the title of “Message sender receives delivery receipt”
· Create Table correlating all User Stories to their Meaningful Use requirements
· Specifying the governance process from how stories will get added within the Wiki
· Language for “Must” stories tied to meaningful use will be made consistent with NPRM terminology
Discussion
· Get ready for a call for consensus for the list of “Must” stories & the wording of the “Must” stories
Comment from John Moehrke
· Two use cases confusing:
o Provider sends and receives data with minimal HIT technology
§ Intent to acknowledge that we want capabilities for providers who have something short of full EHRs
§ How do you measure this?
§ Seems like a principal, not a Use Case – move to business case
o Transaction sender receives delivery receipt
§ Working towards high level use case description, this one is specifically talking about the receipt as a transaction as opposed
§ John will propose alternate wording
§ Intent is that the sender understands the status of the word request, not the status of the transaction
§ Both important, express the
§ ANOTHER CONVERSATION Discussing separation of read receipt (Transaction sender receives read receipt) VS delivery receipt as separable items and placement of read receipt as a “Should”
Comment from Noam Artz
· Public health is both state and local public health
Comment from Steve Krsacok
· Promoting patient centric stories from “Must” to “Should” – wasn’t expecting last two “Must”s (sending reminder, and patient immunization data) are those “Must”s?
· Separate out the send immunizations/quality measure stories because those are single test MU requirements
· HOLD FOR LATER CONVERSATION: Entire MU storied tied to reporting requirements and immunization
Comment from Dan Russler
· Include quality reporting
· Eliminate technology mention, might take out all EHR mentions
o Issue: makes the user stories dry & abstract
o HOLD FOR LATER CONVERSATION: Use same concept of using an example so it isn’t so abstract – should be apprised to all levels of technology
Comment from Linda Fishetti
· Provider sends and receives data with minimal HIT technologyshould be moved to guiding principal
Handling of Provider sends and receives data with minimal HIT technology
· Suggestion: Arien take some of these existing stories that say EHR and rewrite them to say “module” “EHR module” etc …
· Move this one to “design principals”
Comment from Steve Waldren
· Liked it as a Use Case because then it ment that all didn’t have to comply with “minimal”
Comment from David Kibbe
· EHR “Should” be EHR technology and this “Should” include in the definition as “complete EHR” and “EHR module” Arien will reword the design principal
· Arien – list of terminology as well
Comment from Hank Fanberg& John Moehrke
· Define an EHR as David Kibbe does
Comment from Dan Russler
· What is the difference between ISO definition and ARRA definition
· ISO, ARRA and IFR definitions will guide our own definition
· The proposal is
o Remove the Provider sends and receives data with minimal HIT technologyStory
o Ensure that language used in the rest of the stories referring to EHR is consistent
o Terminology section will define EHR in a way that reflects the ISO, ARRA and IFR definitions
o Change design principal #9 will be modified to be consistent with those definitions
Lab/quality/immunization reporting
· Capability to report in NPRM about MU – one time test component
Comment from Chris Voight
· Public Health reporting might stay as a “Must” …
Comment from David Kibee
· Important but complicate our use cases
Comment from Noam Artz, Dan Russler& Will Ross
· Should be in the “Must” category
· Will Ross will get MU Matrix – get that into the Wiki
· Definition of “Must”: concrete implementation
· Definition of “Should”: enable the capability, considered but if there is a motivating reason why it “Shouldn’t be included, then it is okay
· Notion of address/routing “Should” be able to accommodate most of the use cases
· Significantly different considerations for reporting
· Someone who represents “Must” – address concerns that people believe “Should” be a “Should” (complex stuff, let’s keep this simple, everyone thinks these are important, but it is complicated)
· Immunization:
o One public health example in the “Must” and it could be immunization and it is a push mechanism
o Is there a current gap?
§ There are cases where people don’t report because it is too difficult
§ Need to have as many possible methods to submit this data
· Just consider Immunization transaction?
· Easy thing to do is to make them all “Must”s”
· Would it be okay that we couldn’t get something up and running because we set this up as “Must”
Comment from Steve Waldren, Andy Heernan & Chris Voight
· Include immunization in “Must”
· Arien will rewrite the Immunization story and note that state law may not require consent
Comment from David Kibbe:
· Agree with consensus to include immunizations, discussion illustrated the point that as we start to consider other messaging content, it become very complicated to understand the formatting and content – in favor of keeping this very focused
Comment from Hank Fanberg:
· Look at Medicaid side of each state, important to keep in mind – all of them could be “Must”s, go either way
Comment from Girish Navani:
· Variability in terms of the states that require the formats , clear rules and guidelines
o Arien, only talking about the transport level
o Immunization registry can host an address and someone can push to that but the content is out of scope
Comment from John Moehrke:
· Concerned about scope creep – make a presumption that immunization is document form that it falls closer to transport requirement
Comment from Noam Artz:
· Keep public health in the mainstream of what is going on
Comment from Lee Jones:
· no strong objection … the more with “Must” the less likely we are to succeed
Comment from Arien:
· If we have major scope issues we can revisit
Comment from Steve Krsacok:
· Scope creep question
Comment from Dan Russler:
· Take away redundancies
Comment from Teri Byrne:
· Should be a “Should”
Comment from Wil Ross:
· Should be a “Must”
· Arien will get Immunization User Story updated and do full call for consensus by next meeting
Notes from User Story Review Workgroup
Status of Notes: DRAFT
Date: April 19, 2010
Time: 11am-12pm
Attendees: Arien Malec, Honora Burnett, Steven Waldren, Chris Voigt, Andy Heeren, David Kibbe, Hank Fanberg, Girish Kumar Navani, Vasu Manjrekar, John Moehrke, Noam H. Arzt, Lee Jones, Steve Krsacok, Joannie McHugh, Dan Russler, Will Ross, Teri Byrne, Linda Fischetti & Paul Tuten
Actions
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 22 |
4/19/10 |
Update Immunization User Story and do full call for consensus by next meeting |
Open |
Arien |
4/26/10 |
| 23 |
4/19/10 |
Get MU Matrix into the Wiki |
Open |
Will Ross |
4/26/10 |
| 24 |
4/19/10 |
Remove the Provider sends and receives data with minimal HIT technologyStory |
Open |
Arien |
4/26/10 |
| 25 |
4/19/10 |
Ensure that language used in the rest of the stories referring to EHR is consistent |
Open |
Arien |
4/26/10 |
| 26 |
4/19/10 |
Terminology section will define EHR in a way that reflects the ISO, ARRA and IFR definitions |
Open |
Arien |
4/26/10 |
| 27 |
4/19/10 |
Change design principal #9 will be modified to be consistent with those definitions |
Open |
Arien |
4/26/10 |
Agenda and Framing
1. Review of last week’s action items
2. Discussion
Review of last week’s action items
· “Must” definition is within a limited scope and tied to MU requirements
· 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
· Have later conversation about how NHIN Direct will incorporate needs of small business partners
· Reflect in “Must” definition that all User Stories don’t have to be implemented in their entirety, just the ones that fit
· Consider writing a User Story for Long Term Care Facility
· Generalize the title of “Message sender receives delivery receipt”
· Create Table correlating all User Stories to their Meaningful Use requirements
· Specifying the governance process from how stories will get added within the Wiki
· Language for “Must” stories tied to meaningful use will be made consistent with NPRM terminology
Discussion
· Get ready for a call for consensus for the list of “Must” stories & the wording of the “Must” stories
Comment from John Moehrke
· Two use cases confusing:
o Provider sends and receives data with minimal HIT technology
§ Intent to acknowledge that we want capabilities for providers who have something short of full EHRs
§ How do you measure this?
§ Seems like a principal, not a Use Case – move to business case
o Transaction sender receives delivery receipt
§ Working towards high level use case description, this one is specifically talking about the receipt as a transaction as opposed
§ John will propose alternate wording
§ Intent is that the sender understands the status of the word request, not the status of the transaction
§ Both important, express the
§ ANOTHER CONVERSATION Discussing separation of read receipt (Transaction sender receives read receipt) VS delivery receipt as separable items and placement of read receipt as a “Should”
Comment from Noam Artz
· Public health is both state and local public health
Comment from Steve Krsacok
· Promoting patient centric stories from “Must” to “Should” – wasn’t expecting last two “Must”s (sending reminder, and patient immunization data) are those “Must”s?
· Separate out the send immunizations/quality measure stories because those are single test MU requirements
· HOLD FOR LATER CONVERSATION: Entire MU storied tied to reporting requirements and immunization
Comment from Dan Russler
· Include quality reporting
· Eliminate technology mention, might take out all EHR mentions
o Issue: makes the user stories dry & abstract
o HOLD FOR LATER CONVERSATION: Use same concept of using an example so it isn’t so abstract – should be apprised to all levels of technology
Comment from Linda Fishetti
· Provider sends and receives data with minimal HIT technologyshould be moved to guiding principal
Handling of Provider sends and receives data with minimal HIT technology
· Suggestion: Arien take some of these existing stories that say EHR and rewrite them to say “module” “EHR module” etc …
· Move this one to “design principals”
Comment from Steve Waldren
· Liked it as a Use Case because then it ment that all didn’t have to comply with “minimal”
Comment from David Kibbe
· EHR “Should” be EHR technology and this “Should” include in the definition as “complete EHR” and “EHR module” Arien will reword the design principal
· Arien – list of terminology as well
Comment from Hank Fanberg& John Moehrke
· Define an EHR as David Kibbe does
Comment from Dan Russler
· What is the difference between ISO definition and ARRA definition
· ISO, ARRA and IFR definitions will guide our own definition
· The proposal is
o Remove the Provider sends and receives data with minimal HIT technologyStory
o Ensure that language used in the rest of the stories referring to EHR is consistent
o Terminology section will define EHR in a way that reflects the ISO, ARRA and IFR definitions
o Change design principal #9 will be modified to be consistent with those definitions
Lab/quality/immunization reporting
· Capability to report in NPRM about MU – one time test component
Comment from Chris Voight
· Public Health reporting might stay as a “Must” …
Comment from David Kibee
· Important but complicate our use cases
Comment from Noam Artz, Dan Russler& Will Ross
· Should be in the “Must” category
· Will Ross will get MU Matrix – get that into the Wiki
· Definition of “Must”: concrete implementation
· Definition of “Should”: enable the capability, considered but if there is a motivating reason why it “Shouldn’t be included, then it is okay
· Notion of address/routing “Should” be able to accommodate most of the use cases
· Significantly different considerations for reporting
· Someone who represents “Must” – address concerns that people believe “Should” be a “Should” (complex stuff, let’s keep this simple, everyone thinks these are important, but it is complicated)
· Immunization:
o One public health example in the “Must” and it could be immunization and it is a push mechanism
o Is there a current gap?
§ There are cases where people don’t report because it is too difficult
§ Need to have as many possible methods to submit this data
· Just consider Immunization transaction?
· Easy thing to do is to make them all “Must”s”
· Would it be okay that we couldn’t get something up and running because we set this up as “Must”
Comment from Steve Waldren, Andy Heernan & Chris Voight
· Include immunization in “Must”
· Arien will rewrite the Immunization story and note that state law may not require consent
Comment from David Kibbe:
· Agree with consensus to include immunizations, discussion illustrated the point that as we start to consider other messaging content, it become very complicated to understand the formatting and content – in favor of keeping this very focused
Comment from Hank Fanberg:
· Look at Medicaid side of each state, important to keep in mind – all of them could be “Must”s, go either way
Comment from Girish Navani:
· Variability in terms of the states that require the formats , clear rules and guidelines
o Arien, only talking about the transport level
o Immunization registry can host an address and someone can push to that but the content is out of scope
Comment from John Moehrke:
· Concerned about scope creep – make a presumption that immunization is document form that it falls closer to transport requirement
Comment from Noam Artz:
· Keep public health in the mainstream of what is going on
Comment from Lee Jones:
· no strong objection … the more with “Must” the less likely we are to succeed
Comment from Arien:
· If we have major scope issues we can revisit
Comment from Steve Krsacok:
· Scope creep question
Comment from Dan Russler:
· Take away redundancies
Comment from Teri Byrne:
· Should be a “Should”
Comment from Wil Ross:
· Should be a “Must”
· Arien will get Immunization User Story updated and do full call for consensus by next meeting