# General notes

* Need links to *everything* that needs to be reviewed (e.g., operations, bindings, etc.)
* Need to flag items that were draft and are going normative (for review)
* Output should be markdown pages for confluence, one per WG
* Need process to add items later
* Durable ids for items?
* Make sure to handle the case when an artifact has no declared owner (list for: FMG/FHIR-I)
* Confluence page should have
* Drop-down for disposition
* Area for commenting / linking to location?
* Checkbox for 'ready to remove' for things leaving
* Note anything allocated to a WG that as been merged into another (e.g., 'mnm')

* Add notice at top of page with list of issues that *need* to be addressed
* Determine list and post on FMG today (if possible)
* Create checklist of *required* actions at top of page, assign durable ID's in db
* All other content is informational

# Page Related

* Discover pages
* Can be automated - will generate
* Page Information Needed
* Current publication status: Draft / Active / Retired / Unknown
* Flag anything but `Active` (including missing)
* Current standards status: Normative / Trial Use / Draft / Informative / Deprecated
* Highlight `Informative` for review
* Flag anything but `Normative` and `Informative` (including missing)
* Do automated text processing tasks
* Grammar checks
* Page Checks / Decisions
* Disposition of page
* Staying in Core as Informative
* Staying in Core as Normative
* Moving to IG
* Moving to Confluence
* Being removed
* Review tasks (if staying in Core)
* Verified correct status has been set
* Verify text-processing flags
* Verify grammar check
*

# Resource Related

* Discover resources
* Can be automated - will generate
* Automated
* Text review
* Highlight breaking changes from R4, R4B, and R5
* Highlight elements with min cardinality 1
* Highlight elements with cardinality other than `*` (?)
* Find TU-marked Elements - *must* be resolved
* Extract Bindings
* Look for `required` bindings to external terminologies
* Extract cardinalities
* Extract Summary and Modifier flags
* Extract publication status: Draft / Active / Retired / Unknown
* Flag anything but `Active` (including missing)
* Extract standards status: Normative / Trial Use / Draft / Informative / Deprecated
* Highlight `Informative` for review
* Flag anything but `Normative` and `Informative` (including missing)
* Extract any uses of `fixed[x]` instead of `pattern[x]` for review
* More generally - check to see if best-practice constraints are being violated?
* Manual
* Look for `deprecated` - check vs. R5 status and report with/without that
* Review examples for accuracy and coverage (cannot be automated)
* Review descriptions of elements for accuracy
* *Can* check to see if the element has changed and the description has not
* If there is an interface, review any differences from the interface
* *Can* check if there is an interface and higlight any missing/modified elements
* Review breaking changes
* [ ] Review bindings
* Q: If required binding, is there an escape code?
* If Yes, nothing to do (won't list for review)
* Hightlight the difference between UNKNOWN flavors and OTHER flavors and what they mean
* If No, check if there *should* be (does not mean there *has* to be, just that it should be reviewed)
* Note that there is an interaction with minium cardinality here (i.e., min=1) that needs to be considered
* Q: Is the `required` binding appropriate?
* C: Legacy and external data may change and be un-mappable. There needs to be a safe way to handle that.
* [ ] Review optional elements without `meaningWhenMissing`, only of types:
* boolean
* code
* Fix any FHIRPath errors/warnings on invariants

* Report
* [ ] Cardinality higlights
* Min = 1:
* Q: Is this a concept we can count on all systems having, even those with legacy data and external non-FHIR interfaces?
* Q: For all possible use-cases (summaries, secondary reporting, research, etc.)?
* Q: Will that data be expressible in the data type choices available?
* C: While use of data-absent-reason is usually possible (see below), we want to be cautious about min=1 if there's any reasonable likelihood of the data being absent. FHIR resources aren't about expressing best practice.
* Max != `*`
* Q: Are we confident there are no real-world use-cases where a system would have multiple values for the element that they would have trouble choosing between in order to determine which to send?

## Mappings

* Five Ws
* Mandatory - filled out or exceptions
* List mappings
* See what I can find for `[resource]-[pattern]-mapping-exceptions.xml`
* Anything that has unmatched reason "Unknown" - attach to elements
* look at `shortUnmatched`
* Review maps as specified

## Operations

* Discover operations
* Will generate list
* Manual Review?

## Search Parameters

* Discover search parameters
* Will generate list
* Automatic
* Check status (TU flags)
* Fix any FHIRPath errors/warnings
* Highlight `reference` types that have an empty `target` or that does not match the definition of the element it comes from
* Manual Review?

## Extensions

* Look for extensions in core - flag for review

## Profiles

* ~~Look for profiles in core - flag for review~~

## Terminology

* Manual
* Automated checks
* Look for 'limiting' codes (`both`, `either`, `neither`)
* Flag sets that do not have 'escape' codes (for review)
* Note the bindings in place: type + cardinality (e.g., `required`+`code`)
* Examine breaking changes from R4, R4B, and R5

# Textual Content

* Locations
* Page source (*.html)
* [resource]-introduction.xml, profile-[name]-introduction.xml, operationdefinition-[name]-introduction.xml
* [resource]-notes.xml, profile-[name]-notes.xml, operationdefinition-[name]-notes.xml
* CodeSystem and ValueSet content (e.g., description, display, definition)
* bundle-[resource]-search-params.xml (description)
* list-[resource]-examples.xml, list-[resource]-operations.xml, list-[resource]-packs.xml (display)
* Element-related (e.g., Title, Description, Comments)
* Use database or XML structure definitions?
* Data types / metadata types
* Use database or XML structure definitions?

* Automated Text Processing
* **List each occurence per file / resource**
* Check for correct conformance language (`SHALL`, `SHALL NOT`, `SHOULD`, `SHOULD NOT`, `MAY`, `MAY NOT`)
* Check for *possibly* incorrect conformance language (other cases of above words)
* Spelling checks - cspell - https://github.com/streetsidesoftware/cspell-dicts (EN + Medical)
* Check for explicit references to earlier versions of FHIR
* Check for references to resources and pages that are moving out of core
* Check for textual references to resources or datatypes that no longer exist
* Check for linking to images / diagrams (`<figure>`, `<img>`, etc.)
* Ensure there is `alt` text
* Flag if there is a caption
* Flag if `<img>` is used without `<figure>` tags (for review)
* Check for potential 'incomplete' markers
* To-Do (variations)
* "Will Consider" (variations)
* "..."
* "Future versions of the spec" (variations)
* Check for reader-review notes
* [%stu-note%], "stu note"
* [%impl-note%], "Implementation Note"
* [%feedback-note%], "Feedback"
* [%dragons-start%], "Dragon"
* "[Implementers/Balloters/Voters] are asked ..." (variations)
* Check for Trial Use tags
* `Trial Use` exact literal (e.g., `>Trial Use<`) - in a -notes.xml or -introduction.xml
* class="stu" (in html tag) in any content
* Check for links to Zulip (chat.fhir.org)
* Check for links to Confluence for review