FHIR QA Approach

May QA

• Focus is on major design issues
• Review will be by category. Each reviewer will review all resources looking at narrow set of issues
  • Allows better detection of consistency/coherence
• Each category will be reviewed independently by at least two people
• We may look at producing "views" of the content that allow faster review for each focus area
• Review should take 20-30 hours
• We will seek volunteers from the HL7 community first and fill in with FMG resources as needed
• In-scope resources:
  • These are posted for the benefit of those considering participating in the review process. The names of a few of these may shift prior to the start of the review cycle. For more information, go to the FHIR website: http://hl7.org/fhir
  • Provider, Device, Encounter, Group, Location, Organization, Patient, Substance, Supply, AdverseReaction, Allergy, CarePlan, DeviceObservations, DeviceManifest, DeviceEvent, FamilyHistory, Imaging[TBD], Immunization, Observation, Problem, Procedure, Coverage, Conformance, List, OrderRequest, OrderResponse, Profile, Provenance, SecurityEvent, ValueSet, Category, DiagnosticReport, Specimen, Medication, MedicationAdministration, MedicationDispense, MedicationStatement, MedicationPrescription, DocumentRoot, IssueReport, MessageRoot, IndexEntry

Resource descriptions

• Check that boundaries are clear - it's obvious what's in and out of scope
• Is the scope unnecessarily restrictive (e.g. type of care, animal vs. human, etc.)
• Check that related resources are identified and that the boundaries are clearly identified such that there's no overlap
• Is content appropriately targeted as "what do implementers need to know?"
• Is content organized consistently across resources

Resource elements

• Are names clear and consistent (following same patterns)?
• Are minimum cardinality 1 elements truly necessary? I.e. is it not possible to have a sensible instance in any circumstance with the element missing?
• Do the choice of types allow for null flavors if appropriate/relevant?

80%

• Do the list of elements seem intuitively appropriate as "part of the 80%" for the broad scope of the resource?
• Where an element doesn't pass the "intuitive" sniff-test, are there clearly documented requirements and mappings supporting the element's inclusion?
• Do the provided mappings demonstrate validation against a variety of existing specifications?

Constraints

• Are there constraints that ought to be enforced missing?
• Is the constraint language clear? Is the rationale obvious?
• Is the constraint too tight? Will it work in all implementation environments, situations of "partial knowledge", edge cases?

Vocabulary

• If something is universally bound, is it reasonable to expect *all* implementations to manage with only the provided set of codes and to not have issues mapping their existing content?
• Where value lists have been provided, are all concepts clearly mutually exclusive, or if not, defined in a hierarchy in which all siblings are mutually exclusive?
• Are we inventing new codes where appropriate codes already exist?

Search Criteria

• Are search criteria consistently named and defined across resources?
• Do search criteria fit the 80% - i.e. will most systems want to search by/support searching by this criteria?
• Is the expected behavior of the search criteria clear or, where multiple behaviors are possible, is the range of behavior obvious?

July QA

• Everything we did in May, plus check for grammar, spelling, consistent language, valid links, etc.

Pass DSTU

Before a resource can be approved as DSTU:

• At least one of the reference implementations must fully support the resource
• The test suite must fully support the resource