Meeting: | SPARC OS Technical Committee |
|---|---|
Date: | 04/26/2023 |
Time: | 3:00 pm - 3:33 pm |
MUSC | Greg, Brigette |
Iowa | |
LA CaTS | |
Children’s National | |
Case Western | Jeremy |
OHSU | Imogen, Erik |
Stony Brook Medicine |
Agenda:
...
Follow up from last meeting- Q: When will MUSC update to rails 6? A:No timeline yet
No update
4/26/23
not able to attend
...
MUSC:
4/26/23
3.4.0 SPARC Fulfillment - released 4/20/23. Github to be released 2 weeks laterWorking on cherry pick to fix a bug of participant tracker menu auto collapsing
Next release SPARCRelease 3.11.0
Encouraged to let us know of any priority stories or those no longer desired to pursue
...
Oregon Health & Science University:
...
Follow up from 3/29/23 meeting:
Q: Looking to migrate mass amounts of catalog services between programs and cores. Is there a best practice, script, etc. to do this? A:
No established best practice for mass updates.
MUSC did a large # of service updates for a program, years ago and it was a complex process (also had to consider Fulfillment data) that needed to have several check points for data integrity.
As OHSU mentioned, their script fix on this story may handle the Admin Edits orphaned services. However, still consider split/notify hierarchy to make sure the correct provider gets those service req submission emails.
Recommendation is to use what’s supported in SPARC currently:
Inactive old service and create a new service under new program/core (is manual per service)
Use the Catalog feature to move services to a diff program or core (is manual per service)
If still desiring to use script for mass changes (e.g, for bigger priority to preserve all history with a service with the change), do incrementally for migration & data checks along the way, as well as report checks that request #s and data appears correctly.
Still looking for ‘your_cost’ field, how it gets calculated
Will follow up with Imogen with code
OHSU is working on testing 3.10.1
Having users test in dev environment
4/26/23
From last meeting, discussed there’s no standard practice for migrating catalog data, beyond what’s already programmed to switch services between cores or programs. They’ve been using a script for some time to move services, but wanted to make sure they weren’t missing something in light of previous conversations about Catalog Manager and moving services. The main recommendation is ensuring Catalog structure, split/notify, etc is as desired to avoid needing to do massive restructuring later, and testing the changes to make sure it's completed as desired.
Revisiting the ‘Your Cost’ calculations. Need the code that produces the on-page calculations in preparation for working with Kitt’s team on the reporting content they’d like. Noted this was also a field on the Cost Analysis, which could also be a source to review. Greg shared screen for code where ‘applicable_rate’ line item is calculated. This can be a started point and MUSC follows up to provide full code.
In testing 3.10.1 they have some broken reports due to funding source updates, so they are working through those.
Had some IT VPN issues for their university LDAP where users couldn’t log in. From it they were able to speed up the searching of ~10,000 records from ~30s to ~1s by enabling LDAP filter setting.
Iowa
4/12/23
not in attendance
4/26/23
not in attendance
...
Case Western
4/12/23
not in attendance
4/26/23
Mike’s last day was Fri 4/21. Jeremy will assume some of his roles and will also join the OS Governance calls
...
Children’s National
4/12/23
not in attendance
4/26/23
not in attendance
...
Stony Brook:
4/12/23
not in attendance
4/26/23
not in attendance
...