Skip to end of metadata
Go to start of metadata

Meeting Information

Date:

October 28, 2014

Time:

12 EDT/11 CDT/10 MDT/9 PDT

Attending: David Blake and Ross McKinney, Co-Chairs; Teresa Anderson, Susan Chimonas, Luke Diorio, Susan Ehringhaus, Julie Gottlieb, Betty Harvey, Raymond Hutchinson, Norman Kahn, Kirke Lawton, Monika Markowitz, Raj Mehrotra, Heather Pierce, Kelly Reddick, Tim Robinson, Cory Schmidt, Steve Singer, Valerie Smothers, Rebecca Spence, John Sweeney, and Gary Wimsett.

Agenda Items

1 Review minutes

Minutes were approved as submitted.

2 Discuss use cases

Are the elements for each use case correctly described?

David began with Case FI10:  An individual User enters or edits data in a web or mobile app to store Financial Interest and other relationship or activity information in a central repository.  David asked if an individual could delegate someone to enter data on their behalf.  Norm agreed that would be helpful and added that there is precedence with the open payments system.  Susan suggested adding a use case on delegation.  Monica commented that her institution does not allow delegation.  David thought it best to identify use cases and then work on next steps.  Raj commented that the use case should indicate that the success end condition is that the data is up-to-date as of the time of submission and recommended having a date marker.  FI10 use case was approved as described. 

FI20: An Individual User transfers Financial Interest and other relationship or activity information from an existing system into a Central Repository.  Kirke mentioned that the individual rather than the organization may be the trigger. Monika asked if title were to be modified does it make it too expansive.  David asked who controls information in the central repository. It suggests it is always the individual user who is the controlling agent. Heather confirmed that is consistent with the IOM recommendation.  Bill said if an individual updates their own local system and it isn’t automatically uploaded when it is updated, you could have multiple sources with different data.  Heather didn’t think that would make a difference, and Valerie concurred.  Heather will put that into the processes.  Valerie suggested including it as a best practice to accompany the specification.  Heather clarified not all use cases will be implemented for the central repository, but they need to be identified, and the data fields may already be there.  FI20 was approved as revised. 

FI 30: A Requesting Organization creates or edits an organization profile in a Central Repository, including the criteria for the Financial Interest and other relationship or activity information it would like Individual Users to include in required disclosures.  Bill said the trigger event seems like a precondition.  Valerie agreed to make the trigger events assumptions and change the trigger event to be that the requesting organization wants to create an organizational profile.  Heather suggested clarifying that it is an organizational profile being created. Ray asked if there could be multiple organization profiles.  David commented organizations can’t query system.  Valerie asked the group if we should change this to better reflect multiple profiles.  Additions to FI30 were approved as revised. 

FI40: An Individual User sends a disclosure of Financial Interest and other relationship or activity information from the Central Repository to a requesting organization.  Norm recommended allowing a Designee to perform this task.  The group also recommended changing the trigger event to be that an individual has a need to send a disclosure.  David added that there the receiving organization must have established a profile in the central repository.  Heather added an individual would be able to create a PDF.  Valerie will modify use case so it reflects that it may be a system to system communication or it may be user sending PDF; XML can be embedded in PDF document.  Kirke suggested changing the title to indicate that the requesting organization has a profile in the central repository. The group agreed that disclosures may be sent in batch by the central repository. FI 40 was approved with changes. 

FI50: An Individual User reviews his or her Financial Interest and other relationship or activity information in the central repository and submits to a Requesting Organization an attestation to its accuracy.  David clarified this use case is about attestation, not disclosure.  Norm commented he would not permit delegation for this use case; eventually a person has to attest to the accuracy of the data.  Monika added it seems as though it’s not just attestation but also a transfer of financial disclosure.  David noted the data elements will be taken care of in other use cases.  Ray asked if it was conceivable for a request from an outside organization after they reviewed what was in the system.  David thought it could work either way.  FI50 was approved with changes. 

FI60: A Requesting Organization requests a disclosure of an individual’s (or group of individuals?) Financial Interest and other relationship or activity information contained in a central repository.  David asked if disclosure for a group of individual is a separate use case.  Valerie commented that that would impact the standards we create.  Bill said a typical university would want to update regularly in a batch mode.  Valerie will revise this use case and use case FI-40 to account for group possibility.  FI60 was approved with revisions.  The additional use cases will be discussed at the next meeting.  Valerie will draft new use cases and send email to the group for feedback. 

Are there other possible use cases not included?

3 Approval of use cases

 

4 Next steps.

Decisions

6 Use cases (FI-10, FI-20, FI-30, FI-40, FI-50, and FI-60) were approved. 

3 Use cases (FI-12, FI-16, and FI-45) are pending approval.

Action Items

 

Valerie made the following changes to the use cases during  the call:

  • Added
    • An Individual User assigns a Designee who may enter or edit Financial Interest and other relationship or activity information in a central repository on his or her behalf
    • A Designee enters or edits data in a web or mobile app to store Financial Interest and other relationship or activity information in a central repository.
    • An Individual User downloads a disclosure of Financial Interest and other relationship or activity information from the Central Repository.
  • Defined Designee
  • Edited FI-10 to clarify that submissions are up-to-date as of the date of submission.
  • Edited FI-20 to indicate that the individual may request that an organization send data to the central repository form an existing system.
  • Edited FI-30 to indicate that the organization creates an organization profile, made the trigger event that the organization has a need to create or update an organization profile, added assumptions regarding legal agreements and multiple profiles.
  • Edited FI-40 to indicate that only organizations with a profile in the central repository can receive disclosures from the central repository, changed the trigger event to ne the individual’s need to send a disclosure,  added an assumption that the system may send disclosures in batch or real time.
  • Edited FI-60, added an assumption that the system may send disclosures in batch or real time.  

 Action items

Valerie will work with the Use case sub-committee to draft use cases for assigning a designee to enter or edit data on another’s behalf.

  • No labels