ONC_SI_Simplification_Meeting

advertisement
S&I Framework
S&I Simplification - Cross Initiative
Meeting Notes
Date: 3/29/12
Name: S&I Simplification WG
Agenda/Objectives:
Topic
1. Introductions
2. Review Analysis of Assumptions, Pre/Post
Conditions (Gary)
3. Core Stakeholders, Actors, Roles
4. DES/CEDD Update (John)
5. USHIK Update (Mike/Robin)
6. New Business
7. Adjourn
Time Allotted
10:00 – 10:05 EDT
10:05 – 10:20 EDT
10:20 – 10:35 EDT
10:35 – 10:45 EDT
10:45 – 10:55 EDT
10:55-11:00 EDT
11:00 EDT
Gary Dickinson, Kosta Makrodimitri, Meredith Lewis, Freida Hall, Jennifer Barrett, Robin Barnes, Mike
Fitzmaurice, John Donnelly
Wiki has new documents posted with draft assumptions, pre/post conditions for TOC, LRI, PD, esMD:
Column C is each initiatives assumptions, pre and post conditions
Column D is the requirement type
Column E is the fulfillment aspect
Column F shows traceability
Column G is the requirements related to core requirements in the core matrix
Column H involves core actions required to fulfill the pre/post condition or requirement
Column I specifies applicability to a specific person
Column J specifics when this is relevant
Column K posts the level of requiredness per se
Column L is a restatement of column C
Might collapse the core requirements into the master list; core requirements have two aspects – data at
rest and also data in motion (interchange of information)
Column E is generally repeated in column J
There is some collapsibility or consolidation that could occur in the matrix
Reverse engineering is going on from the LRI Use Case to LOI
Six axes within LOINC, which is why you can have variation in a LOINC result
Just want to make sure the way LOI is being operated will fit with the goals of the core matrix
Bob is going to review Gary’s work related to PD (Which would then be complete aside from column F)
esMD has been added; trying to substantially reuse assumptions and pre/post conditions as they move
from Use Case 1 to 2 and 3
Perhaps ask someone from esMD to review the entries for that section - Bob Dieterle would be able to
Stakeholder/actor/role –
Hope that column I is a role entry, but need to be in sync with the Use Case
I could be an actor or a role, or just a role
Hierarchy from stakeholder to actor to role
Some roles explicitly describe actors and roles; earlier use cases really just describe the actor
S&I Use Case Simplification Workgroup 3/29/2012
1
Meeting Notes
S&I Framework
S&I Simplification - Cross Initiative
If we could specify components of one Use Case that could be registered for reuse by drilling down to
data and actions, that would be ideal
Challenge is that there is a master list that people choose from in addition to those that they add
If not computable, it is simply a list; need to manage and maintain that list appropriately
Role-based authorization and access control could lead to allowing roles to be computable
Do we want to include these things in the core matrix if it isn’t computable?
Core matrix as it stands just enumerates the actors and then defines them
Amy made a list of stakeholders
Maybe agreement across SDOs/developers – given stakeholder is category 1, 2 etc
Finite numbers to make it computable and avoid people having to redefine each stakeholder/actor
Computable means it would show up in a transaction somewhere – in code somewhere (role)
Stakeholder and actor would be more of a reusable enumeration – how much concern do we want to
have about usability for this?
Have them out there for Use Cases, but drilling down to actual activity and functionality would be more
applicable to defining role
When you discuss moving patients along the continuum of care, there is a phenomenon that has to do
with the size of the organization that is managing the patient
Dependent on the part of the organization management as to who does what – “role”
In one you can have a physician being the care manager; in another setting you can have an
unlicensed professional acting as the care coordinator, then a payer, then a case manager, then
additional organizations
So many different ways that roles can be expressed – delegation of function into role is really important
Encourage resources from other work groups to contribute definitions of the roles for their Use Cases
Perhaps create a smaller sub work group to do this
CEDD/DES – Working to expose CEDD to the other groups at the Face to Face and still trying to
resolve the DES/CEDD crosswalk
USHIK – Releasing a new version of the site today with enhanced search capability; will get returned
data elements from all of the different portals in USHIK
Waiting for feedback on the template from S&I Leadership
USHIK will be in the Face to Face in the second half of the day – third afternoon session entirely
S&I Use Case Simplification Workgroup 3/29/2012
2
Download