fishbaugher / WAweb-Issues

A repository to track issues with WAweb usage. This includes problems, work arounds, shortcuts, and workflow suggestions
0 stars 0 forks source link

Access to WAweb data for reporting and program administration #89

Open bgoldenMN opened 7 months ago

bgoldenMN commented 7 months ago

This issue is being addressed with DOE and at other levels, but I wanted to make sure it was included on the GitHub as well.

Minnesota requests access to statewide data for the purpose of creating additional reporting modules, beyond the minimal reporting offered within WAweb. Minnesota has currently implemented a number of reports in WA desktop that have become essential for program effectiveness both at the grantee and subgrantee level.

These additional reports serve two significant purposes. First, they allow Subgrantees to monitor production, costs, and trends on a regular basis, allowing them to better meet programmatic requirements. Second, they allow effective monitoring of subgrantees by the grantee (in this case, MN Department of Commerce). Minnesota has worked hard to build a collaborative monitoring process that relies on regular-check-ins and monitoring visits with Subgrantees. These check ins require the ability to analyze recent data and trends.

Minnesota understands and shares data privacy concerns. However, this data is generated in Minnesota, by Minnesota subgrantees. Minnesota is not asking for data or records that it did not create or does not otherwise have access to by navigating to individual accounts on WAweb. What we request is the ability to export that data (or to receive regular exports from ORNL) and create reporting modules for internal analysis.

fishbaugher commented 7 months ago

Directly related to all the open New Report request Issues:

3

6

7

8

9

10

11

12

13

14

15

17

18

19

fishbaugher commented 7 months ago

Other things to consider.

1) Any reports that are currently generated by the service providers may need some careful consideration. Currently, the WA 8.12 desktop version allows service providers to generate things like Client Payment Summary, Audit Completions, and Jobs in Progress (basically any report that can be generated from the WA 8.12 UI desktop, especially at the Client level). These reports are on current data, that is, on clients that may have just been completed.

2) The other reports are generated from the monthly aggregate database using the separate MNDOC reporting module.

If we need to duplicate functionality for the service providers (1 above) then we will need to be able to query the MN database frequently and implement some kind of reporting available for the service provider. Perhaps the best option would be that ORNL open up the reporting development platform allowing states to implement and deploy those custom reports to their own servers (e.g. wa-mn.ornl.gov). The alternative is to maintain some kind of synchronous SQL database just for reports (poor work around).

IF (on the other hand) service providers can live with the reporting currenty available in WAweb, then a monthly sync of the MNDOC v10 SQL database may suffice (2 above). In short, we would have a monthly sync/download operation which would generate an aggregated SQL database just for MNDOC reporting. Of course, those reports may be forwarded to service providers as necessary, but they would only have data updates monthly.

Just some things to think about.

eckmanwe commented 7 months ago

Of note, there have been a variety of discussions regarding similar data "export" over the past year, with a major shift in the plan per request by DOE within the last (2) months.

For additional note, the issues regarding data security arise not based upon who "generated the data", but what the data is. Please carefully consider the Tooltips on the "Account" Form when guiding subgrantees as to the data to input. The easiest way to limit data security concerns is to have systems in-place that preclude input of client name. We cannot fully preclude users from inputting client names. As such, we must operate as if DOE is stewarding client information that includes the client name.

fishbaugher commented 7 months ago

I presume that all production management features of WAweb will necessarily involve PII and the backend database and import/export techniques will be compliant with handling PII data online. Thus, the export feature will certainly require the suitable level of authentication and encryption safeguards.

Is this why Accounts do not have contact information? Is the Account supposed to be free of PII?

eckmanwe commented 7 months ago

If we could fully avoid PII in the database, that would certainly simplify things. However, at this time we cannot guarantee the non-existence of PII in the database.

bgoldenMN commented 6 months ago

Confirming here that this remains a Priority Critical for Minnesota, as we have communicated to DOE through several avenues.

For clarity, the reason the origin of the PII is relevant is because Minnesota is not asking to be supplied any PII that it does not already steward the security of in other formats. All data that Oak Ridge would be providing from the database is already viewable by the State in individual WAweb accounts. Thus, this seems like a technical issue regarding a route for the secure transfer of information--not an issue of whether the information should be transferred.

As Mark has noted above, this could either look like additional report generation abilities within WA (which might best serve Subgrantees) and/or a separate secure format for timely reporting of data back to Minnesota as the grantee. In either case, we believe the ability to analyze this information is critical to program implementation, program growth and Minnesota's ability to remain in compliance with DOE requirements.

Minnesota will continue training Subgrantees on the proper stewardship of PII, including the avoidance of PII in WAweb entries.