Page tree
Skip to end of metadata
Go to start of metadata

The following checklist can be used as a template for performing an Implementation Guide review – it guides the overall process for the review.

This slide deck gives details for reviewing FHIR IGs: 2019-09 FHIR IG Review.pptx

To use this checklist, copy the content to a Word Document for each IG Review.

Step #1: Orientation / Conceptual

  • Check stated Realm
  • Check kind of IG – what expectations arise?
  • Summarise what this IG does (is it clear from stated scope?)
  • Check stated dependencies – if stated
  • Check for missing appropriate dependencies 

Step #2: Orientation / Technical

  • Read note to balloters (if present)
  • Check history notes
  • Check qa.html

Step #3: Orientation / Approach

  • Check kinds of exchanges
  • APIs
  • Document
  • Messaging (o Check messaging protocol)
  • Make list of kinds of information exchanged
  • Check consistent with realm core expectations
  • Make list of actors described in system
  • Characterise as Producer | Consumer | Repository

Step #4: Capability Statement

  • Check resources exposed. For each resource
  • Check Interactions
  • Check Search Parameters
  • Modifiers 
  • Chaining
  • Combinations
  • Conformance expectations clear
  • Check System Profile
  • Check Use case Profiles
  • Check Global Profiles

Step #5: Profiles

Check resources/profiles exposed. For each resource

  • Check Text Summary – human to human
  • Check Differential as summary (consistent with text summary?)
  • Check what other related profiles exist in other IGs
  • For each element in the differential:
    • Check definitions – changed? Needs to be changed?
    • Check any mappings added
    • Check cardinality
    • Check must support (and check it’s meaning is defined)
    • Check Terminology Binding
  • Any orphan profiles?

Step #6: Extensions

Any extensions? For each extension:

  • Check context of use
  • check related extensions
  • For each element in the differential:
  • (as above)

Step #7: Value Sets / Code Systems

  • Check Copyright (externally sourced content)
  • Check Versioning
  • For code systems: something that needed to be defined?

Step #8: Specific Requirements

  • For each:
    • Defined / described?
    • Requirements described?
    • Do you agree?
  • Security
  • Error Handling
    • Specifying correct behaviour for operational failures
    • Mechanisms for handling erroneous data
  • Audit / Provenance
  • Consent / Privacy
  • Test Cases / Conformance testing support
  • Safety Issues (check)

  • No labels


  1. This guide and checklist is great.  IMO As I was reviewing the fhir implementation guides out there, I saw variation in how information was presented.  They did not have the same look and feel.  I also felt that the executive summary/high level use cases which the guide is about were not always covered well and in an obvious frontpage-like place.  I think guides need to be readable and have consistent look and feel.  I was trying to find a guide to use as a gold standard but couldn't find one.  Interested in recommendations.  Anyway, I think its important that guide clearly explain in a consistent upfront place  the main objective of this guide (with an end user focus - whose who would benefit from its implementation) and what business use cases it is trying to solve. Consistency is important - for example - there isn't a clear place to find an overview of the guide.  Also its important that everyone does diff and snapshot and examples the same way and fill all those out.

  2. I agree with VIrginia - having the same lay-out for the FHIR IGs is important to help folks in reading them - there are a lot of guides out there and getting the infromation about what the IG is for up front lets the reader decide if they need to read all of it, or if it isn't of importance to them at the moment = giving a clear WHAT and WHY in the intro page / executive summary is most helpful here, but also having the same organization makes reading them easier.