CDCgov / CDCgov/dibbs-ecr-diff
Spike: Document the lifecycle of an RR throughout an encounter
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 12
Description
What needs to be done
- Understand the Reportability Response lifecycle, including how RRs are versioned (do they follow the same version logic as an eICR? (seems like it))
- when can an RR change?
- what can trigger an RR change?
- Are changes to an RR inherently actionable as they indicate something a new RCKMS rule being triggered?
- Document the lifecycle (or clarify an existing lifecycle diagram) to indicate when an RR can change
- Product: push for an answer on whether an RR should be considered part of the diff for MVP
Why it needs to be done
Difference in Docs needs to understand how the eICR and RR can change and how they interact over their lifecycle. This will allow the team to confidently implement diffing logic that ensures actionable updates are delivered to jurisdictions.
Acceptance Criteria
- team has a lifecycle diagram that describes what can trigger an RR change and whether an RR change is always, sometimes, or never actionable
- an assessment of whether the structure of an RR can be logically grouped into the same actionable, not actionable, and indeterminate categories envisioned for the eICR
Additional context
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by resolving the issue's questions about Reportability Response versioning, lifecycle changes, triggers, and actionability relative to the eICR. Document or clarify a lifecycle diagram, then assess whether RR structures fit the actionable, not actionable, and indeterminate categories; done means the team has the diagram and MVP diff assessment described in the acceptance criteria.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100