FHIR QA Approach

This page discusses how QA will be handled leading up to the first DSTU.

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 (intuitive) and consistent (following same patterns)?
• Do the choice of types allow for null flavors if appropriate/relevant?
• Is nesting appropriate (no unnecessary levels, grouping of repeating/optional elements)

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 minimum cardinality 1 elements truly necessary? I.e. is it not possible to have a sensible instance in any circumstance with the element missing?
• Is mustUnderstand set properly - element influences interpretation of other elements
• 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?
• Are code descriptions clear - will implementers understand what the codes mean

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?

Examples

Can review either XML or JSON (they're transforms of each other)

• Do examples cover the breadth and depth of the complete scope of use of the resource
• Do examples adequately exercise the elements (use all elements, show use of repetition, optionality, use of different types

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