-
Notifications
You must be signed in to change notification settings - Fork 10
Decision: System last updated behavior
Thing | Info |
---|---|
Relevant features | Content view, footer |
Date started | 2021-03-29 |
Date finished | 2021-04-02 |
Decision status | Done |
Summary of outcome | Record last successfully-updated date for each part. Using that information, design a display that makes sense for our users. |
This is related to Decision: Reg content sources.
Users want to be able to learn how recently the regulations in the system have been updated.
- Does this apply to both regulations and supplemental content?
- If both, which supplemental content?
- Which regulation defines the single date? Some regulations may not be updated at the same time as others, due to parser failures or lack of access to data.
- In this case, is there an updated date per part?
- In this case, do we prevent any from updating if one of them can't?
Types of content in our system:
- Updates to reg text
- Supplemental content (especially sub-regulatory guidance)
Users want:
- One date for all reg text.
- Is this the latest reg text (incorporating the stuff that is effective), as of yesterday or today?
- When was the reg text last refreshed from a source that I trust?
- It is much less important to display last updated info for subreg guidance - people want to understand how that updating process happens, but the specific updated date is less important, especially since most of the specific content will have dates associated with it - we can consider this out of scope for this decision.
Technical info:
- Currently eRegs makes an effort to parse new content from the Federal Register every day. This is not super reliable - sometimes needs fixing to make it work.
- If we switch eRegs to use eCFR instead, we should be able to reliably pull in new content every day.
Things we can do:
- Record last successfully-updated date for each part.
- Using that information, design a display that makes sense for our users.
We decided at Decision: Reg content sources to use eCFR, which simplified this decision. We'll do the thing we can do.
Please note that all pages on this GitHub wiki are draft working documents, not complete or polished.
Our software team puts non-sensitive technical documentation on this wiki to help us maintain a shared understanding of our work, including what we've done and why. As an open source project, this documentation is public in case anything in here is helpful to other teams, including anyone who may be interested in reusing our code for other projects.
For context, see the HHS Open Source Software plan (2016) and CMS Technical Reference Architecture section about Open Source Software, including Business Rule BR-OSS-13: "CMS-Released OSS Code Must Include Documentation Accessible to the Open Source Community".
For CMS staff and contractors: internal documentation on Enterprise Confluence (requires login).
- Federal policy structured data options
- Regulations
- Resources
- Statute
- Citation formats
- Export data
- Site homepage
- Content authoring
- Search
- Timeline
- Not built
- 2021
- Reg content sources
- Default content view
- System last updated behavior
- Paragraph indenting
- Content authoring workflow
- Browser support
- Focus in left nav submenu
- Multiple content views
- Content review workflow
- Wayfinding while reading content
- Display of rules and NPRMs in sidebar
- Empty states for supplemental content
- 2022
- 2023
- 2024
- Medicaid and CHIP regulations user experience
- Initial pilot research outline
- Comparative analysis
- Statute research
- Usability study SOP
- 2021
- 2022
- 2023-2024: 🔒 Dovetail (requires login)
- 🔒 Overview (requires login)
- Authentication and authorization
- Frontend caching
- Validation checklist
- Search
- Security tools
- Tests and linting
- Archive