FHIR Collaborative Review Implementation Guide

Introduction

This Implementation Guide describes a how a FHIR Server can provide a set of services that allows for a team to review a resource instance, comment on it's contents, and then provide a response by a collator, following which, the original resource will be updated.

This Implementation Guide is intended to be suitable for supporting the collaborative review process on conformance resources (profiles, extensions, value sets, translations, conformance statements etc).

Note: The process that this IG supports may also be useful and applicable to other kinds of FHIR resources (e.g. clinical review of a medications list), or some variant of the process may be needed, but this is out of scope of the first round of this implementation guide.

Overview

Fundamentally, the review process follows this general pattern:

1. a user (the 'editor') initiates a review cycle on a 'target resource'
2. other users ('reviewers') are invited to participate in the review
3. reviewers are presented with a form that allows them to comment on the contents of the resource
4. the editor is notified of reviewer's progress in the review
5. the reviewers and the editor is able to see a summary of user comments on the review, and respond with a comment of their own
6. reviewers are notified of the editor's comments, and all users are able to see the final outcome
7. the editor updates the target resource

I think we also need to support a more informal process, whereby -for some longer period- anyone (users, developers, ...) can submit comments about the resource.

FHIR Resources

The following FHIR resources are used in the review process:

• Practitioner- all the registered users (see below) involved in the process are exposed as Practitioner resources that represent their possible roles to the system
• Group - the Group resource allows users to identify their review interests
• Encounter - each review cycle is represented by an encounter
• Questionnaire - generated to collect comments from the reviewer or editor
• QuestionnaireResponse - records the input made be reviewer or editor
• StructureDefinition & ValueSet - used by the server when generating questionnaires for steps 3 and 5
• Communication/CommunicationResponse - used to track invitations and notifications through the process
• AuditEvent - used to record all the steps in the process

The heart of a good Collaborative Review Process is the ability to generate good questionnaires from the underlying resource definitions and the target resource.

Actors

The following services are described that act in concert to provide a Collaborative review. Note that any single server may provide more than one of these. It is assumed, for the purposes of this service, that all the services share the same set of authorised users (and user SMART on FHIR to authorize them).

• Orchestration Server - this provides the workflow support, tracking the overall process. Resources: Communication/CommunicationResponse/AuditEvent/Practitioner/Group
• Target Server - this hosts the resource that is being reviewed
• Presentation Server - this takes a reference to the target resource, and generates a nicely formatted questionnaire asking the user about it's content
• analysis server - this takes user submissions as QuestionnaireResponses, and stores them, and is capable of collating the output to a single.... something
• Conformance Server - this provides a FHIR Tooling Eco-system conformance service that supports the Presentation and Analysis servers

Steps

1. a user (the 'editor') initiates a review cycle on a 'target resource'

Editor logs into the Target server to select one or more conformance resources that will be reviewed. This creates a new Encounter resource on the Orchestration server. (How to make an Encounter point to the resources under review - I think it's a bit far fetched to use Encounter for this - ek). The editor may associate a specific Questionnaire with this round of comments and thus this Encounter, so the Questionnaire can be tailored to fit the review process for these conformance resources (actually, you may want a different Questionnaire per type of conformance resource - ek)

2. other users ('reviewers') are invited to participate in the review

The Editor invites the users by selecting one or more from the list of Practitioners (representing the users involved in the review process) from the Orchestration server. These are added to the Encounter as participants. The users are notified by the creation of a Communication resource. Subsystems watching the creation of such Communication resources are involved to signal the reviewers, e.g. by e-mail.

3. reviewers are presented with a form that allows them to comment on the contents of the resource

Reviewers either have a direct url to get to the presentation server (e.g. from the email), or find a list of reviews they are currently participating in on the Orchestration server, from which they may select one of the resources to review. The presentation server fetches the Questionnaire that is relevant for this review and conformance resource, and sees whether there is already a QuestionnaireAnswers present (e.g. when the reviewer has already partly answered the Questionnaire, or wants to change his/her answers) and renders the Questionnaire + pre-fills any answers already given. When the review is ready, the reviewer saves his/her answers using the Presentation server to the Orchestration server.

4. the editor is notified of reviewer's progress in the review

When QuestionnaireAnswers get created or changed, the Orchestration server looks up the review session (=Encounter) to which this submitted review belongs and finds the editor. The Orchestration server creates a new notification as a Communication resource, which -using a subsystem that is subscribed to new communication resources - will forward this to the editor.