Integrating the Healthcare Enterprise

 

 

IHE PCC

Technical Framework Supplement

 

 

 

Assessment Curation and Data Collection (ACDC)

 

 

HL7 ® FHIR ® STU 4

Using Resources at FMM Levels 2-5 [KB1]

 

Rev. 1.0 – Draft for Public Comment

 

 

Date: April 27, 2019

Author: IHE PCC Technical Committee

Email: pcc@ihe.net

 

Please verify you have the most recent version of this document. See here for Trial Implementation and Final Text versions and here for Public Comment versions.

 
Foreword

This is a supplement to the IHE Patient Care Coordination Technical Framework V11.0. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.

This supplement is published on April 27, 2019 for public comment. Comments are invited and can be submitted at http://www.ihe.net/PCC_Public_Comments . In order to be considered in development of the trial implementation version of the supplement, comments must be received by June 25, 2019.

This supplement describes changes to the existing technical framework documents.

“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume.

Amend Section X.X by the following:

Where the amendment adds text, make the added text bold underline . Where the amendment removes text, make the removed text bold strikethrough . When entire new sections are added, introduce with editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined.

 

General information about IHE can be found at http://ihe.net .

Information about the IHE Patient Care Coordination domain can be found at http://ihe.net/IHE_Domains .

Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at http://ihe.net/IHE_Process and http://ihe.net/Profiles .

The current version of the IHE Patient Care Coordination Technical Framework can be found at http://ihe.net/Technical_Frameworks .

 


CONTENTS

 

Introduction to this Supplement

Open Issues and Questions

Closed Issues

General Introduction

Appendix A – Actor Summary Definitions

Appendix B – Transaction Summary Definitions

Glossary

Volume 1 – Profiles

Copyright Licenses

X Assessment Curation and Data Collection (ACDC) Profile

X.1 ACDC Actors, Transactions and Content Modules

X.1.1 Actor Descriptions and Actor Profile Requirements

X.1.1.1 Clinical Knowledge Resource Repository

X.1.1.2 Artifact Consumer

X.1.1.3 Assessor

X.1.1.4 Assessment Requestor

X.2 ACDC Actor Options

X.2.1 Assessor

X.2.1.1 EHR Launch Option

X.2.1.2 Standalone Launch Option

X.3 ACDC Required Actor Groupings

X.4 ACDC Overview

X.4.1 Concepts

X.4.2 Use Cases

X.4.2.1 Use Case #1: Discovery and Retrieval of existing clinical knowledge resources

X.4.2.1.1 Use Case #1 Description

In the first use case, a care provider organization is seeking information about assessment instruments to address a specified condition or health concern.  Their goal is to identify instruments and eventually acquire instruments which could be used to capture information essential to management of the care of patients having that condition.

X.4.2.1.2 Use Case #1 Process Flow

X.4.2.2 Use Case #2: Discovery and Retrieval of existing data elements with source document links

X.4.2.2.1 Use Case #2 Description

X.4.2.2.2 Use Case #2 Process Flow

X.5 ACDC Security Considerations

X.6 ACDC Cross Profile Considerations

Volume 2 – Transactions

3.X1 Query Artifact [PCC-X1]

3.X1.1 Scope

3.X1.2 Actor Roles

3.X1.3 Referenced Standards

3.X1.4 Interaction Diagram

3.X1.4.1 Query Artifact Request message

3.X1.4.1.1 Trigger Events

3.X1.4.1.2 Message Semantics

3.X1.4.1.2.1 Query Search Parameters

3.X1.4.1.2.2 Populating Expected Response Format

3.X1.4.1.3 Expected Actions

3.X1.4.2 Query Artifact Response message

3.X1.4.2.1 Trigger Events

3.X1.4.2.2 Message Semantics

3.X1.4.2.2.2 Resource Bundling

3.X1.4.2.3 Expected Actions

3.X1.4.3 Conformance Resource

3.X1.5 Security Considerations

3.X1.5.1 Security Audit Considerations

3.X2 Retrieve Artifact [PCC-X2]

3.X2.1 Scope

3.X2.2 Actor Roles

3.X2.3 Referenced Standards

3.X2.4 Interaction Diagram

3.X2.4.1 Retrieve Artifact Request message

3.X2.4.1.1 Trigger Events

3.X2.4.1.2 Message Semantics

3.X2.4.1.2.1 Query Search Parameters

3.X2.4.1.2.2 Populating Expected Response Format

3.X2.4.1.3 Expected Actions

3.X2.4.2 Retrieve Artifact Response message

3.X2.4.2.1 Trigger Events

3.X2.4.2.2 Message Semantics

3.X2.4.2.2.2 Resource Bundling

3.X2.4.2.3 Expected Actions

3.X2.4.3 Conformance Resource

3.X2.5 Security Considerations

3.X2.5.1 Security Audit Considerations

Volume 3 – Content Modules

 


Introduction to this Supplement

Whenever possible, IHE profiles are based on established and stable underlying standards. However, if an IHE committee determines that an emerging standard offers significant benefits for the use cases it is attempting to address and has a high likelihood of industry adoption, it may develop IHE profiles and related specifications based on such a standard.

The IHE committee will take care to update and republish the IHE profile in question as the underlying standard evolves. Updates to the profile or its underlying standards may necessitate changes to product implementations and site deployments for them to remain interoperable and conformant with the profile in question.

This Technical Framework Supplement uses the emerging HL7 ® [1] FHIR ® [2] specification. The FHIR release profiled in this supplement is R4. HL7 describes the STU (Standard for Trial Use) standardization state at https://www.hl7.org/fhir/versions.html .  

In addition, HL7 provides a rating of the maturity of FHIR content based on the FHIR Maturity Model (FMM): level 0 (draft) through 5 (normative ballot ready).The FHIR Maturity Model is described at http://hl7.org/fhir/versions.html#maturity .

Key FHIR STU 3 content, such as Resources or ValueSets, used in this profile, and their FMM levels are on April 27 th , 2019:

FHIR Resource Name

FMM Level

Questionnaire

3

QuestionnaireResponse

3

The Assessment Curation and Data Collection (ACDC) does what? [KB2]

 

 


Open Issues and Questions

  1. Is assessment an option, in that it describes a) the type of resource returned from the knowledge repository?
  2. How should we address authentication / authorization to a) access the repository, and obtain a resource for implementation?  Ideally this would allow for use of bearer tokens after authorization to enable repositories to be compatible with SMART on FHIR (SoF).  Considerations: Questionnaires are not patient specific resources, so patient/Questionnaire.read is NOT a useful scope.  It should be user/Questionnaire.read.  What scope would distinguish between search and acquire permissions?  Is that outside of the scope of this profile?  That would only be a minor challenge, I think b/c user access controls could enforce user capabilities.
  3. How do we handle provenance for QuestionnaireResponse resources?  Is that the responsibility of the assessor or the assessment requestor?  It would seem to be the responsibility of the latter, b/c we do not actually say what is done with the responses.  They could be persisted, or they could be stored as individual observation resources, et cetera, it’s up to the requestor to determine what to do with the data and how to associate it with provenance.
  4. Do we want repositories to be able to implement assessment logic for an instrument and return the QuestionnaireResponse?  In this case, how is the interaction triggered?  Yes, this case needs to be supported for some CKRR’s
  5. Should there be an option for EHR Launch/Standalone Launch?  I think yes, b/c there are some cases where assessment instruments can be executed using separate hardware (i.e., an iPad) that may need to “log in” to the EHR and be assigned to a given patient being seen, whereas there may be other cases where the EHR may simply launch a web page somewhere (in a similar scenario, the EHR application is running in a browser on the iPad and does the launch in its own UI).
  6. ATNA requirements.  Questionnaire’s are not PHI, but they are IP.  Do we need to protect transactions using Questionnaire with ATNA?  Do we require, or simply recommend ATNA?  I think we adopt RESTful ATNA related requirements re: Authentication, encryption and logging, but do not require ATNA completely b/c FHIR already has Audit Event, which is based on ATNA, and we are using SoF standalone and EHR Launch, which enforces encryption and authentication requirements, so they only thing we need to add is a logging requirement.

Closed Issues

 

 

General Introduction

Update the following Appendices to the General Introduction as indicated below. Note that these are not appendices to Volume 1.

Appendix A – Actor Summary Definitions

Add the following actors to the IHE Technical Frameworks General Introduction list of actors :

Actor

Definition

Clinical Knowledge Resource Repository

A Clinical Knowledge Resource Repository stores documents artifacts and metadata providing regarding computable clinical knowledge and enables access to that information to requesters on demand . [KB3]

 

Artifact Consumer

 

The artifact consumer is a user-oriented application component that allows an end user (e.g., clinician, informaticist, interface engineer, et cetera) to explore clinical knowledge resources available from a Clinical Knowledge Resource Repository.

Assessment Requestor

 

The assessment requestor is an application component that needs assessment data and can request the capture of assessment information from an assessor.

Assessor

 

An assessor is a user-oriented application that allows a clinician, patient or other party to answer the questions associated with an assessment instrument and obtain a completed response.

 

Appendix B – Transaction Summary Definitions

Add the following transactions to the IHE Technical Frameworks General Introduction list of Transactions :

Query Artifact [PCC-X1] – this transaction uses RESTful API to query identity assessment instruments that meet certain criteria, e.g., by topic, coded concern, procedure, clinical area, et cetera, or by provenance, retrieving the metadata essential to enable the consumer to determine if it wants to know more about the assessment instrument.

The returned result would list the metadata associated with the various Questionnaire resources available but need not contain complete data on items in the instrument.

Request Artifact [PCC-X2] this transaction uses RESTful API to requests the complete details of an Assessment Instrument in order to implement it for evaluation or production use.

Assess Patient [PCC-X3] this this transaction uses RESTful API to execute the assessment and return a QuestionnaireResponse and any data resulting from the Questionnaire (e.g., ClinicalImpression).

 

Glossary

Add the following glossary terms to the IHE Technical Frameworks General Introduction Glossary:

No new terms added [KB4] .

Volume 1 – Profiles

Copyright Licenses

Add the following to the IHE Technical Frameworks General Introduction Copyright section:

No new copyright licenses added.

 

Add new Section X

X Assessment Curation and Data Collection (ACDC) Profile

The Assessment Curation and Data Collection (ACDC) supports

TBD

X.1 ACDC Actors, Transactions and Content Modules

This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A at http://www.ihe.net/Technical_Framework/index.cfm .

Figure X.1-1 shows the actors directly involved in the ACDC Profile and the relevant transaction between them.

Figure X.1-1: ACDC Actor Diagram

Table X.1-1 lists the transactions for each actor directly involved in the ACDC Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).

 

Table X.1-1: ACDC Integration Profile - Actors and Transactions

Actors

Transactions

Optionality

Reference

Clinical Knowledge Resource Repository

Query Artifact [PCC-X1]

R

PCC TF-2: 3.X1

Retrieve Artifact [PCC-X2]

R

PCC TF-2: 3.X2

Artifact Consumer

Query Artifact [PCC-X1]

R

PCC TF-2: 3.X1

Retrieve Artifact [PCC-X2]

R

PCC TF-2: 3.X2

Assess Patient [PCC-X3]

O 2

PCC TF-2: 3.X3

Assessor

Assess Patient [PCC-X3]

R

PCC TF-2: 3.X3

Assessment Requestor

Assess Patient [PCC-X3]

R

PCC TF-2: 3.X3

X.1.1 Actor Descriptions and Actor Profile Requirements

X.1.1.1 Clinical Knowledge Resource Repository

The Clinical Knowledge Resource Repository in this profile responds to FHIR-based queries for one or more clinical knowledge artifacts.

  1. Given that a Clinical Knowledge Resource Repository provides an assessment instrument that a healthcare provider can use to assess a given condition or health concern, it must provide a mechanism by which that assessment can be performed on a given patient. This can be implemented in one of two ways:
    1. The CKRR can implement the Questionnaire Item Retrieval option, which enables the healthcare provider’s Health IT system to execute the assessment instrument with the Assessor of its choice, or
    2. The CKRR must be grouped with an Assessor that the healthcare provider’s Health IT system can use to execute the assessment instrument.

X.1.1.2 Artifact Consumer

The Artifact Consumer in this profile sends FHIR-based queries to the Clinical Knowledge Resource Repository to search for and obtain for one or more clinical knowledge artifacts.  Rendering and further processing of these artifacts is defined by the Assessor and Assessment Requestor in this profile.

  1. Given that a user with appropriate permissions is operating the provider’s health IT system, when a new assessment instrument is needed, then the user can locate an appropriate assessment instrument, and configure that health IT system to use it to capture an assessment.
  2. A healthcare provider’s health IT system must be able to support assessments from a CKRR that implements the Questionnaire Retrieval Option.
  3. A healthcare provider’s health IT system must be able to support assessments from a CKRR that implements the Grouped Assessor Option.

X.1.1.3 Assessor

The Assessor in this profile performs an assessment and posts the results as a QuestionnaireResponse to the appropriate patient and encounter.

X.1.1.4 Assessment Requestor

The Assessment Requestor in this profile requests an assessment of an assessor and processes results returned in a QuestionnaireResponse resource.

 

X.2 ACDC Actor Options

X.2.1 Assessor

X.2.1.1 EHR Launch Option
X.2.1.2 Standalone Launch Option

X.3 ACDC Required Actor Groupings

 

Table X.3-1: ACDC - Required Actor Groupings

ACDC Actor

Actor to be grouped with

Reference

Artifact Consumer

Assessment Requestor

-

Assessment Requestor

Artifact Consumer

-

Assessment Requestor

Secure Node or Secure Application

-

Assessor

Secure Node or Secure Application

-

[KB5]

X.4 ACDC Overview

Assessments are the principle means by which numerous forms of data regarding physical function, mental/cognitive status, social determinants of health, and patient reported outcomes are collected.  Many assessment instruments have been automated, but there are thousands of these instruments.  HealthMeasures [3] has nearly 750 measures, the Alcohol and Drug Abuse Institute at the University of Washington [4] lists over 1031 screening instruments, and a search of PubMed [5] results in nearly 26,000 articles on different assessment instruments, scales and questionnaires used for patient assessment.

In the US, more than a half dozen quality improvement or recognition programs require documenting or reporting specific information about patients that contain elements that can be obtained from health assessments [6] . These are shown in figure X.4-1 below.

Figure X.4-1 Quality Related Assessments

Many of these instruments can be implemented using technology, as they are simple forms or questionnaires.  Some data in these instruments might be automatically populated by the EHR system.  However, because there are so many instruments, and so many providers of the instruments, it is challenging to integrate these instruments into provider workflows.

X.4.1 Concepts

Assessment instruments are tools which enable clinicians to assess a patient’s clinical condition based on certain evaluations or observations performed with the patient.  Evaluations may include the recording of clinical data that is captured by other means (e.g., measurement tools) or by simply answering questions based on the clinician or patient’s knowledge.  The result is an assessment that will provide both the collected data and an assessment of what that means for the condition being assessed.

Assessments may be used for screening, diagnosis, treatment determination, or reporting of outcomes.  Assessment instruments are used to gather data on a wide variety of clinical conditions.  One well known example of an assessment instrument is the American College of Cardiology’s ASCVD Risk Estimator [7] .  This instrument provides an estimation of a patients’ 10-year ASCVD risk.  It appears in the figure below.

Figure X.4.1-1 An Assessment Instrument

Both the gathered data in the assessment and the resulting assessment can be used for later evaluation, either for clinical care or to support health research.

As a clinical tool used in the delivery of care, assessment instruments often go through evaluation and validation, and include training materials on how the assessment is to be performed [8] .  Changes to the questions asked, or the possible responses allowed results in a different diagnostic instrument, which may or may not perform as well as the validated instrument.  Therefore, developers of assessment instruments often accompany them with intellectual property controls that ensure they are implemented appropriately.  Many assessment instruments were originally implemented as paper forms, but with the growth of the web, these are now often implemented as electronic forms.  Because of the intellectual property controls, instrument developers may restrict online use to a validated implementation.

This results in a challenge for healthcare providers because each instrument they choose to use may have different user interfaces, different initiation protocols and delivery mechanisms, and require different ways to be integrated into their electronic health record systems.  The purpose of this profile is to provide a way for these instruments to be readily integrated into the EHR.

Because many of these instruments rely on data that is already known to the EHR, there is further value in enabling a connection between the EHR and the system delivering the assessment instrument content so that information that is already known to the EHR can be supplied to the assessment instrument delivery system.

In this profile, the assessment instrument is represented as a FHIR Questionnaire resource.  The questionnaire resource is designed to support collection of data based on answers from end users and enables detailed control over presentation of the instrument.  The responses to the assessment instrument are represented in the FHIR QuestionnaireResponse resource.  This resource provides the list of questions, answers and additional data (e.g., assessments, scores, et cetera) determined from the answers to the questions.

The figure below illustrates the abstract implementation model for working with assessments for patient reported outcomes [9] as published in the HL7 FHIR Patient Reported Outcomes Implementation Guide.  While this model was developed for patient reported outcome assessments, it can be applied to other forms of assessment as well.

pro-abstract-model-basic.png

Figure X.4.1-2 Abstract Model for Basic Questionnaires

The ACDC profile focuses on steps 2 through 5 of this model and implements these steps using four different actors.  The first use case in this profile, corresponding to step 2 in the diagram above, is to identify the assessment instrument that the healthcare provider wants to integrate into their workflow.  The PROM Instrument and Metadata repository in this diagram would support instrument retrieval by implementing the Clinical Knowledge Resource Repository Actor.  The External PRO Administration System or EHR or Care Delivery Health IT system could then retrieve instruments by implementing the Artifact Consumer actor.  This enables the assessment instrument to be selected by the healthcare provider.

The second use case in this profile corresponds to steps 3 through 5 in Figure X.4.1-1, which is the execution of the assessment instrument.  In this use case, there are several possible ways the assessment data could be collected.

  1. The provider’s Health IT system can initiate data capture on its own, using the data describing the assessment instrument.  To implement this option, the health IT system needs to correctly interpret instrument description, collect the data and do what it deems necessary with the data that was collected (e.g., create observations or other resources, store a questionnaire response, et cetera).
  2. The providers Health IT system can invoke a separate application that can interpret the assessment instrument and collect data on the patient, returning it to the EHR.
  3. A separate application can be launched which integrates the EHR to determine which assessment is to be performed, collect the data and return the EHR attached to the correct patient and encounter.

X.4.2 Use Cases

X.4.2.1 Use Case #1: Finding an Assessment

X.4.2.1.1 Use Case #1 Description
In the first use case, a care provider organization is seeking information about assessment instruments to address a specified condition or health concern.  Their goal is to identify instruments and eventually acquire instruments which could be used to capture information essential to management of the care of patients having that condition.   Their EHR will be able to perform the assessment once it has been acquired.
X.4.2.1.2 Use Case #1 Process Flow

The Query Artifact transaction is used to request lists of one or more artifacts that match the users search criteria.  The metadata for the artifacts matching the criteria is returned so that the user can further explore these artifacts to consider acquisition of them for use in their health information system.

After identifying an artifact for implementation, the user can either retrieve the full artifact so that it can be implemented in their health information system, or a link to where it has been externally implemented so that they integrated it the collected data into their system, which is described in more detail in X.4.2.2 Use Case #2 Executing the Assessment Instrument .

Figure X.4.2.1-1: Use Case #1 Process Flow in ACDC Profile

X.4.2.2 Use Case #2: Executing the Assessment Instrument

X.4.2.2.1 Use Case #2 Description

In the second use case, the care provider organization wants to execute the retrieved or identified assessment in their EHR system and be able to collect the results of this assessment for a given patient.

In this use case, there are a variety of different implementation methods:

  1. The assessment instrument may be directly executed by the user’s health IT system.  In this case, there are no real interoperability concerns this profile need address, because the health IT system is interacting with itself.
  2. The assessment instrument may need to be executed by an external piece of software (provided by the supplier of the assessment instrument) because of intellectual property requirements.  In this case, the external system
  3. The assessment instrument may be assigned for the patient to complete through the user’s patient portal for them to complete at a time that is convenient for them.
  4. The user’s EHR or portal may choose to integrate with an external piece of software to interpret the Questionnaire and collect the assessment data.
  5. An external application that integrates separately with the EHR may be used to perform this assessment.  Examples for this include giving the patient a tablet that has been configured to perform the assessment for them, and having the patient complete the assessment using the tablet.

During the execution of this use case, the software performing the assessment may wish to collect data already known about the patient that is stored in the health IT system that will receive the assessment results.

 

X.4.2.2.2 Use Case #2 Process Flow

In this use case, the first step is to associate the assessment instrument with a context available in the health IT system (shown below as the Assessment Requestor) that will receive the assessment results.  The context at a minimum establishes the subject of the assessment: the patient being assessed, and the user information that might be associated with any provenance for the assessment.  The context might also include the provider requesting the assessment, and the encounter in which the assessment is performed.

The next step performs the assessment.  During this step, the assessor might also collect data from the receiving health IT system to facilitate completion of the assessment.

Upon completion of the assessment, the assessor

 

Figure X.4.2.2-1: Use Case #2 Process Flow in ACDC Profile

 

X.5 ACDC Security Considerations

Assessment instruments are intellectual property which owners may wish to protect in various ways, e.g., licensing agreements, copyright restrictions, et cetera.  As such the content of the assessment instrument should be encrypted during exchange.  Accessors of assessment instruments may need to authenticate themselves in some way before being able to access assessment instruments.  Access to specific assessment instrument content that may be implemented by a user can have financial ramifications for that user (e.g., incur charges), and should therefore be logged by both the owner and receiver of the content.

A Health IT system that is configured to support a new assessment instrument has had a significant change in functionality that should be logged.

Assessments that are performed can contain individually identifiable information as well as protected health information, and as such, should be encrypted when exchanged, and such exchanges should also be logged.

 

X.6 ACDC Cross Profile Considerations

PCC QEDm – Query for Existing Data for Mobile

An Assessor may be grouped with a Clinical Data Consumer actor from the QED or QEDm profile to enable it to access data from the requesting system.  This grouping enables data that is already known to the requesting system to be accessed. 

Given that an Assessor is grouped with the Clinical Data Consumer actor, when the authorization process is performed, the Assessor shall negotiate for the additional scopes that it desires access to via the Clinical Data Consumer actor in order to perform the assessment.  The Assessor Actor shall not require the Assessment Requestor to implement the Clinical Data Source Actor, and must be able to perform normally if it does not support some or all of the additional requested scopes.

The Assessment Requestor may be grouped with a Clinical Data Source actor from the QEDm profile to enable it to respond to requests for data access from the requesting system.  This grouping enables data that is already known to the requesting system to be accessed during the assessment process.  Given the Assessment Requestor Actor is grouped with a Clinical Data Source from the QEDm profile, when the Assessor requests additional scopes to access clinical data, the Assessment Request shall respond with the scopes appropriate for the clinical data options that it supports.

ITI ATNA

All actors in this profile may be grouped with the Secure Node or Secure Application actors from the IHE ATNA profile.

Volume 2 – Transactions

Add Section 3.X1

3.X1 Query Artifact [PCC-X1]

This section corresponds to Transaction PCC-X1 of the IHE PCC Technical Framework. Transaction PCC-X1 is used by the Clinical Knowledge Resource Repository and Artifact Consumer Actors.

3.X1.1 Scope

The Query Artifact transaction is used to query for assessment instruments in Questionnaires that satisfy a set of parameters by using the FHIR framework. The result of the query is a FHIR Bundle containing FHIR clinical data Resources that match the query parameters.

The ACDC Profile assumes that categories and codes referenced by these FHIR Resources need to be defined at the time of deployment. The specification of these FHIR Resources make recommendations on categories and codes, that should be considered.

 

3.X1.2 Actor Roles

Figure 3.X1.2-1: Use Case Diagram

 

Table 3.X1.2-1: Actor Roles

Actor:

Artifact Consumer

Role:

Queries the Clinical Knowledge Resource Repository for assessment instrument content requested by the Artifact Consumer.

Actor:

Clinical Knowledge Resource Repository

Role:

Responds to query, supplying the FHIR Questionnaire Resources representing the assessment instrument content that match the search criteria provided by the Artifact Consumer.

3.X1.3 Referenced Standards

HL7 FHIR

HL7® FHIR® standard R4:  http://www.hl7.org/fhir/R4/index.html

IETF RFC 2616

Hypertext Transfer Protocol – HTTP/1.1

IETF RFC 7540

Hypertext Transfer Protocol – HTTP/2

IETF RFC 3986

Uniform Resource Identifier (URI): Generic Syntax

IETF RFC 4627

The application/json Media Type for JavaScript Object Notation (JSON)

IETF RFC 6585

Additional HTTP Status Codes

 

3.X1.4 Interaction Diagram

3.X1.4.1 Query Artifact Request message

This message uses the HTTP GET method parameterized query to retrieve FHIR Questionnaire Resources representing assessment instruments matching search parameters in the GET request. This transaction performs a FHIR search request on Questionnaire resources.

ACDC does not mandate any additional extended or custom method.

3.X1.4.1.1 Trigger Events

When the Artifact Consumer needs to discover Questionnaire Resources matching various search parameters it issues a Query Artifact message.

3.X1.4.1.2 Message Semantics

The Artifact Consumer executes an HTTP GET against the proper Clinical Knowledge Resource Repository’s ACDC URL.

The search target follows the FHIR http specification ( http://hl7.org/fhir/R4/http.html ), addressing the proper FHIR Resource type, according to the supported query options (see Section 3.X1.4.1.2.1). The syntax of the FHIR query is:

GET [base]/Questionnaire?summary=true&{[parameters]}

with the following constraints:

3.X1.4.1.2.1 Query Search Parameters

All query parameter values shall be appropriately encoded per RFC 3986 “percent” encoding rules. Note that percent encoding does restrict the character set to a subset of ASCII characters which is used for encoding all other characters used in the URL.

The Clinical Knowledge Resource Repository must support any combination of the following parameters:

  • code (token)
  • At least one of context (token), context-quantity (quantity), context-type (token), context-type-quantity (composite), context-type-value (composite)
  • date (date)
  • description (string)
  • name (string)
  • publisher (string)
  • status (token)

The Clinical Knowledge Resource Repository may choose to support additional query parameters beyond the subset defined by the profiling listed below, if done according to the core FHIR specification. Such additional parameters are considered out of scope for this transaction. The Clinical Knowledge Resource Repository may ignore any additional parameter not specified in this transaction. See http://hl7.org/fhir/R4/search.html#errors .

 

3.X1.4.1.2.2 Populating Expected Response Format

The FHIR standard provides encodings for responses as either XML or JSON. The Clinical Knowledge Resource Repository shall support both message encodings, whilst the Artifact Consumer shall support one and may support both.

See ITI TF-2x: Appendix Z.6 for details.

3.X1.4.1.3 Expected Actions

The Clinical Knowledge Resource Repository shall process the query to discover Questionnaire FHIR Resource entries (the assessment instruments) that match the search parameters given and shall use a FHIR Bundle resource to collect the matching entries to be returned.

The Clinical Knowledge Resource Repository shall respond with a Mobile Artifact Query Response synchronously (i.e., on the same connection as was used to initiate the request).

See ITI TF-2x: Appendix Z.6 for more details on response format handling. See ITI TF-2x: Appendix Z.7 for handling guidance for Access Denied.

3.X1.4.2 Query Artifact Response message

The Clinical Knowledge Resource Repository returns an HTTP Status code appropriate to the processing as well as a list of the matching clinical data FHIR Resources.

3.X1.4.2.1 Trigger Events

The Clinical Knowledge Resource Repository completed processing of the Query Artifact Request message.

3.X1.4.2.2 Message Semantics

Based on the query results, the Clinical Knowledge Resource Repository will either return an error or success. The guidance on handling Access Denied related to use of 200, 403 and 404 can be found in ITI TF-2x: Appendix Z.7 (reproduced here for readability).

When the Clinical Knowledge Resource Repository needs to report an error, it shall use HTTP error response codes and should include a FHIR OperationOutcome with more details on the failure. See FHIR http://hl7.org/fhir/R4/http.html and http://hl7.org/fhir/R4/operationoutcome.html .

In particular, if a Clinical Knowledge Resource Repository Actor receives an Artifact Query transaction for a resource related to a ACDC Option not supported , it shall return an operationoutcome.issue.code valued as: ‘not-supported’ and a an operationoutcome.issue.details valued as: MSG_NO_MATCH No Resource found matching the query "%s" [KB6]

If the Query Artifact request message is processed successfully, whether or not Questionnaire Resources are found, the HTTP status code shall be 200.
The Query Artifact Response message shall be a FHIR Bundle Resource containing zero or more clinical data. If the Clinical Knowledge Resource Repository is sending warnings, the Bundle Resource shall also contain an OperationOutcome Resource that contains those warnings.

The response shall adhere to the FHIR Bundle constraints specified in ITI TF-2x: Appendix Z.1.

3.X1.4.2.2.2 Resource Bundling

Resource Bundling shall comply with the guidelines in ITI TF-2x: Appendix Z.1.

The Clinical Knowledge Resource Repository shall include all resources to be returned as a contained resource. This means that the query shall return resource data contained in the FHIR Bundle as entries.

3.X1.4.2.3 Expected Actions

The Artifact Consumer Actor processes the bundle of resources, received in Transaction PCC-X1 according to the capabilities of its application.  These capabilities are not specified by IHE.

If an Artifact Consumer cannot automatically recover from an error condition, it should offer a means to make the error accessible to the query initiator (e.g. user, system).

3.X1.4.3 Capability Statement Resource

Clinical Knowledge Resource Repositories implementing this transaction should provide a Conformance Resource as described in ITI TF-2x: Appendix Z.3 indicating the query operation for the Resources have been implemented and shall include all the supported query parameters.

3.X1.5 Security Considerations

The retrieved content contains IP that shall be protected.

See the general Security Considerations in PCC TF-1: X.5.

3.X1.5.1 Security Audit Considerations

Grouping a Clinical Knowledge Resource Repository with an ATNA Secure Node or Secure Application is recommended. Grouping an Artifact Consumer with an ATNA Secure Node or Secure Application is recommended.

The Artifact Consumer may be considered overburdened to fully implement the requirements of a Secure Node or Secure Application. The Clinical Knowledge Resource Repository is likely a more robust application and should generate audit messages.

Both actors generate a ”Query” Audit Message, which is consistent with ATNA. The Query Artifact [PCC-X1] is a Query Information event as defined in Table ITI TF-2:3.20.4.1.1.1-1. The message shall comply with the following pattern:

-         EventID = EV(110112, DCM, “Query”)

-         EventTypeCode = EV(“PCC-X1”, “IHE Transactions”, “Query Artifact”)

-         EventActionCode = “E” (Execute)

  • Source of the request (1..1)

-         UserID = The Artifact Consumer actor system identity

-         RoleIDCode = EV(110153, DCM, “Source”)

  • Human Requestor (0..n) one for each know User

-         UserID = Identity of the human that initiated the transaction.

-         RoleIDCode = Access Control role(s) the user holds that allows this transaction

  • Destination of the request (1..1)

-         Clinical Knowledge Resource Repository actor system identity

-         RoleIDCode = EV(110152, DCM, “Destination”)

  • Audit Source (1..1)

-         not specified

  • Query Parameters (1..1)

-         ParticipantObjectTypeCode = “2” (system object)

-         ParticipantObjectTypeCode Role = “24” (query)

-         ParticipantObjectIDTypeCode = EV(“PCC-X1”, “IHE Transactions”, “Query Artifact”)

-         ParticipantObjectQuery = Requested URL including query parameters, base64 encoded

-         ParticipantObjectDetail = HTTP Request Headers contained in the query (e.g., Accept header)

Add Section 3.X2

3.X2 Retrieve Artifact [PCC-X2]

This section corresponds to Transaction PCC-X2 of the IHE PCC Technical Framework. Transaction PCC-X2 is used by the Clinical Knowledge Resource Repository and Artifact Consumer Actors.

3.X2.1 Scope

The Retrieve Artifact transaction is used to query for assessment instruments in Questionnaires that satisfy a set of parameters by using the FHIR framework. The result of the query is a FHIR Bundle containing FHIR Questionnaire Resources that match the query parameters.

The ACDC Profile assumes that uris referenced by these FHIR Resources need to be defined at the time of deployment. The specification of these FHIR Resources make recommendations on uris that should be considered.

 

3.X2.2 Actor Roles

Figure 3.X2.2-1: Use Case Diagram

 

Table 3.X2.2-1: Actor Roles

Actor:

Artifact Consumer

Role:

Requests the Clinical Knowledge Resource Repository for assessment instrument content identified by the Artifact Consumer.

Actor:

Clinical Knowledge Resource Repository

Role:

Responds to requesdt, supplying the identified FHIR Questionnaire Resources representing the assessment instrument content that match the search criteria provided by the Artifact Consumer.

3.X2.3 Referenced Standards

HL7 FHIR

HL7® FHIR® standard R4:  http://www.hl7.org/fhir/R4/index.html

IETF RFC 2616

Hypertext Transfer Protocol – HTTP/1.1

IETF RFC 7540

Hypertext Transfer Protocol – HTTP/2

IETF RFC 3986

Uniform Resource Identifier (URI): Generic Syntax

IETF RFC 4627

The application/json Media Type for JavaScript Object Notation (JSON)

IETF RFC 6585

Additional HTTP Status Codes

 

3.X2.4 Interaction Diagram

3.X2.4.1 Retrieve Artifact Request message

This message uses the HTTP GET method parameterized query to retrieve FHIR Questionnaire Resources representing assessment instruments matching search parameters in the GET request. This transaction performs a FHIR search request on Questionnaire resources.

ACDC does not mandate any additional extended or custom method.

3.X2.4.1.1 Trigger Events

When the Artifact Consumer needs to discover Questionnaire Resources matching various search parameters it issues a Retrieve Artifact message.

3.X2.4.1.2 Message Semantics

The Artifact Consumer executes an HTTP GET against the proper Clinical Knowledge Resource Repository’s ACDC URL.

The search target follows the FHIR http specification ( http://hl7.org/fhir/R4/http.html ), addressing the proper FHIR Resource type, according to the supported query options (see Section 3.X2.4.1.2.1). The syntax of the FHIR query is:

GET [base]/Questionnaire?{[parameters]}

with the following constraints:

  • The [base] represents the Service Base URL
  • The [parameters] represents a series of encoded name-value pairs representing the filter for the query, as specified in Section 3.X2.4.1.2.1, as well as control parameters to modify the behavior of the Clinical Knowledge Resource Repository such as response format, or pagination. See ITI TF-2x: Appendix Z.6 for more details on response format.
3.X2.4.1.2.1 Query Search Parameters

All query parameter values shall be appropriately encoded per RFC 3986 “percent” encoding rules. Note that percent encoding does restrict the character set to a subset of ASCII characters which is used for encoding all other characters used in the URL.

The Clinical Knowledge Resource Repository must the following parameters:

  • url (uri)

The Clinical Knowledge Resource Repository may choose to support additional query parameters beyond the subset defined by the profiling listed above, if done according to the core FHIR specification. Such additional parameters are considered out of scope for this transaction. The Clinical Knowledge Resource Repository may ignore any additional parameter not specified in this transaction. See http://hl7.org/fhir/R4/search.html#errors .

 

3.X2.4.1.2.2 Populating Expected Response Format

The FHIR standard provides encodings for responses as either XML or JSON. The Clinical Knowledge Resource Repository shall support both message encodings, whilst the Artifact Consumer shall support one and may support both.

See ITI TF-2x: Appendix Z.6 for details.

3.X2.4.1.3 Expected Actions

The Clinical Knowledge Resource Repository shall process the query to discover Questionnaire FHIR Questionnaire Resource entries (the assessment instruments) that match the search parameters given and shall use a FHIR Bundle resource to collect the matching entries to be returned.

The Clinical Knowledge Resource Repository shall respond with a Retrieve Artifact Response synchronously (i.e., on the same connection as was used to initiate the request).

See ITI TF-2x: Appendix Z.6 for more details on response format handling. See ITI TF-2x: Appendix Z.7 for handling guidance for Access Denied.

3.X2.4.2 Retrieve Artifact Response message

The Clinical Knowledge Resource Repository returns an HTTP Status code appropriate to the processing as well as a list of the matching clinical data FHIR Resources.

3.X2.4.2.1 Trigger Events

The Clinical Knowledge Resource Repository completed processing of the Retrieve Artifact Request message.

3.X2.4.2.2 Message Semantics

Based on the query results, the Clinical Knowledge Resource Repository will either return an error or success. The guidance on handling Access Denied related to use of 200, 403 and 404 can be found in ITI TF-2x: Appendix Z.7 (reproduced here for readability).

When the Clinical Knowledge Resource Repository needs to report an error, it shall use HTTP error response codes and should include a FHIR OperationOutcome with more details on the failure. See FHIR http://hl7.org/fhir/R4/http.html and http://hl7.org/fhir/R4/operationoutcome.html .

In particular, if a Clinical Knowledge Resource Repository Actor receives a Artifact Query transaction for a resource related to a ACDC Option not supported, it shall return an operationoutcome.issue.code valued as: ‘not-supported’ and a an operationoutcome.issue.details valued as: MSG_NO_MATCH No Resource found matching the query "%s" [KB7]

If the Retrieve Artifact request message is processed successfully, whether or not Questionnaire Resources are found, the HTTP status code shall be 200.
The Retrieve Artifact Response message shall be a FHIR Bundle Resource containing zero or more Questionnaire Resources. If the Clinical Knowledge Resource Repository is sending warnings, the Bundle Resource shall also contain an OperationOutcome Resource that contains those warnings.

The response shall adhere to the FHIR Bundle constraints specified in ITI TF-2x: Appendix Z.1.

3.X2.4.2.2.2 Resource Bundling

Resource Bundling shall comply with the guidelines in ITI TF-2x: Appendix Z.1.

The Clinical Knowledge Resource Repository shall include all resources to be returned as a contained resource. This means that the query shall return resource data contained in the FHIR Bundle as entries.

3.X2.4.2.3 Expected Actions

The Artifact Consumer Actor processes the bundle of resources, received in Transaction PCC-X2 according to the capabilities of its application.  These capabilities are not specified by IHE.

If an Artifact Consumer cannot automatically recover from an error condition, it should offer a means to make the error accessible to the query initiator (e.g. user, system).

3.X2.4.3 Conformance Resource

Clinical Knowledge Resource Repositorys implementing this transaction should provide a Conformance Resource as described in ITI TF-2x: Appendix Z.3 indicating the query operation for the Resources have been implemented and shall include all the supported query parameters.

3.X2.5 Security Considerations

The retrieved content contains IP that shall be protected.

See the general Security Considerations in PCC TF-1: X.5.

3.X2.5.1 Security Audit Considerations

Grouping a Clinical Knowledge Resource Repository with an ATNA Secure Node or Secure Application is recommended. Grouping an Artifact Consumer with an ATNA Secure Node or Secure Application is recommended.

The Artifact Consumer may be considered overburdened to fully implement the requirements of a Secure Node or Secure Application. The Clinical Knowledge Resource Repository is likely a more robust application and should generate audit messages.

Both actors generate a ”Query” Audit Message, which is consistent with ATNA. The Retrieve Artifact [PCC-X2] is a Query Information event as defined in Table ITI TF-2:3.20.4.1.1.1-1. The message shall comply with the following pattern:

  • Event

-         EventID = EV(110112, DCM, “Query”)

-         EventTypeCode = EV(“PCC-X2”, “IHE Transactions”, “Retrieve Artifact”)

-         EventActionCode = “E” (Execute)

  • Source of the request (1..1)

-         UserID = The Artifact Consumer actor system identity

-         RoleIDCode = EV(110153, DCM, “Source”)

  • Human Requestor (0..n) one for each know User

-         UserID = Identity of the human that initiated the transaction.

-         RoleIDCode = Access Control role(s) the user holds that allows this transaction

  • Destination of the request (1..1)

-         Clinical Knowledge Resource Repository actor system identity

-         RoleIDCode = EV(110152, DCM, “Destination”)

  • Audit Source (1..1)

-         not specified

  • Query Parameters (1..1)

-         ParticipantObjectTypeCode = “2” (system object)

-         ParticipantObjectTypeCode Role = “24” (query)

-         ParticipantObjectIDTypeCode = EV(“PCC-X2”, “IHE Transactions”, “Retrieve Artifact”)

-         ParticipantObjectQuery = Requested URL including query parameters, base64 encoded

-         ParticipantObjectDetail = HTTP Request Headers contained in the query (e.g., Accept header)

-          

Add Section 3.X3

3.X3 Assess Patient [PCC-X3]

This section corresponds to Transaction PCC-X3 of the IHE PCC Technical Framework. Transaction PCC-X3 is used by the Assessment Requestor, Assessor and Artifact Consumer Actors.

3.X3.1 Scope

The Retrieve Artifact transaction is used to query for assessment instruments in Questionnaires that satisfy a set of parameters by using the FHIR framework. The result of the query is a FHIR Bundle containing FHIR Questionnaire Resources that match the query parameters.

The ACDC Profile assumes that uris referenced by these FHIR Resources need to be defined at the time of deployment. The specification of these FHIR Resources make recommendations on uris that should be considered.

 

3.X3.2 Actor Roles

Figure 3.X3.2-1: Use Case Diagram

 

Table 3.X3.2-1: Actor Roles

Actor:

Assessment Requestor

Role:

Requests an assessment be performed using the specified FHIR Questionnaire Resource for the patient and encounter in the current context.

Actor:

Assessor

Role:

Responds to request, by creating a FHIR QuestionnaireResponse Resource for the patient and encounter in the current context representing the execution of the assessment instrument provided.

Actor:

Artifact Consumer

Role:

Performs the Assessment based on data it has already retrieved from an Artifact Respository

3.X3.3 Referenced Standards

HL7 FHIR

HL7® FHIR® standard R4:  http://www.hl7.org/fhir/R4/index.html

HL7 SMART on FHIR

HL7® FHIR® SMART Application Launch Framework Implementation Guide Release 1.0.0 http://hl7.org/fhir/smart-app-launch/index.html

IETF RFC 2616

Hypertext Transfer Protocol – HTTP/1.1

IETF RFC 7540

Hypertext Transfer Protocol – HTTP/2

IETF RFC 3986

Uniform Resource Identifier (URI): Generic Syntax

IETF RFC 4627

The application/json Media Type for JavaScript Object Notation (JSON)

IETF RFC 6585

Additional HTTP Status Codes

 

3.X3.4 Interaction Diagram

3.X3.4.1 Assess Patient Request message

This message uses a SMART on FHIR Standalone or EHR Launch sequence to initiate an assessment for a given patient with the specified Questionnaire resource.

3.X3.4.1.1 Trigger Events

When the Assessment Requestor needs to have a patient assessed it issues an Assess Patient message.

3.X3.4.1.2 Message Semantics

A patient context is established with a SMART on FHIR application through either the standalone launch sequence, or the EHR launch sequence depending on whether the Assessor being used implements the Standalone Launch option or the EHR Launch Option.

When the EHR Launch sequence is used, the questionnaire to use for the assessment is determined by the URL used for the launch sequence. 

When the Standalone Launch option is used, the SMART on FHIR Application is responsible for establishing the patient context and selecting the questionnaire to use for the assessment.

3.X3.4.1.2.1 Query Parameters

In addition to the SMART on FHIR parameters used in the EHR Launch, a questionnareURI parameter is provided giving the Assessor the canonical URI of the assessment instrument.  This allows the Assessor to determine the assessment instrument that it will be using to perform the assessment.

All query parameter values shall be appropriately encoded per RFC 3986 “percent” encoding rules. Note that percent encoding does restrict the character set to a subset of ASCII characters which is used for encoding all other characters used in the URL.

 

3.X3.4.1.3 Expected Actions

The Assessor shall perform the selected assessment and post a new QuestionnaireResponse to the AssessmentRequestor

See ITI TF-2x: Appendix Z.6 for more details on response format handling. See ITI TF-2x: Appendix Z.7 for handling guidance for Access Denied.

 

3.X3.4.2 Assess Patient Activity message

3.X3.4.2.1 Trigger Events

3.X3.4.2.2 Semantics

3.X3.4.2.3 Expected Actions

 

-

3.X3.4.3 Retrieve Artifact Response message

The Clinical Knowledge Resource Repository returns an HTTP Status code appropriate to the processing as well as a list of the matching clinical data FHIR Resources.

3.X3.4.3.1 Trigger Events

The Clinical Knowledge Resource Repository completed processing of the Retrieve Artifact Request message.

3.X3.4.3.2 Message Semantics

Based on the query results, the Clinical Knowledge Resource Repository will either return an error or success. The guidance on handling Access Denied related to use of 200, 403 and 404 can be found in ITI TF-2x: Appendix Z.7 (reproduced here for readability).

When the Clinical Knowledge Resource Repository needs to report an error, it shall use HTTP error response codes and should include a FHIR OperationOutcome with more details on the failure. See FHIR http://hl7.org/fhir/R4/http.html and http://hl7.org/fhir/R4/operationoutcome.html .

In particular, if a Clinical Knowledge Resource Repository Actor receives a Artifact Query transaction for a resource related to a ACDC Option not supported, it shall return an operationoutcome.issue.code valued as: ‘not-supported’ and a an operationoutcome.issue.details valued as: MSG_NO_MATCH No Resource found matching the query "%s" [KB8]

If the Retrieve Artifact request message is processed successfully, whether or not Questionnaire Resources are found, the HTTP status code shall be 200.
The Retrieve Artifact Response message shall be a FHIR Bundle Resource containing zero or more Questionnaire Resources. If the Clinical Knowledge Resource Repository is sending warnings, the Bundle Resource shall also contain an OperationOutcome Resource that contains those warnings.

The response shall adhere to the FHIR Bundle constraints specified in ITI TF-2x: Appendix Z.1.

3.X3.4.3.2.2 Resource Bundling

Resource Bundling shall comply with the guidelines in ITI TF-2x: Appendix Z.1.

The Clinical Knowledge Resource Repository shall include all resources to be returned as a contained resource. This means that the query shall return resource data contained in the FHIR Bundle as entries.

3.X3.4.3.3 Expected Actions

The Artifact Consumer Actor processes the bundle of resources, received in Transaction PCC-X3 according to the capabilities of its application.  These capabilities are not specified by IHE.

If an Artifact Consumer cannot automatically recover from an error condition, it should offer a means to make the error accessible to the query initiator (e.g. user, system).

3.X3.4.4 Conformance Resource

Clinical Knowledge Resource Repositorys implementing this transaction should provide a Conformance Resource as described in ITI TF-2x: Appendix Z.3 indicating the query operation for the Resources have been implemented and shall include all the supported query parameters.

3.X3.5 Security Considerations

The retrieved content contains IP that shall be protected.

See the general Security Considerations in PCC TF-1: X.5.

3.X3.5.1 Security Audit Considerations

Grouping a Clinical Knowledge Resource Repository with an ATNA Secure Node or Secure Application is recommended. Grouping an Artifact Consumer with an ATNA Secure Node or Secure Application is recommended.

The Artifact Consumer may be considered overburdened to fully implement the requirements of a Secure Node or Secure Application. The Clinical Knowledge Resource Repository is likely a more robust application and should generate audit messages.

Both actors generate a ”Query” Audit Message, which is consistent with ATNA. The Retrieve Artifact [PCC-X3] is a Query Information event as defined in Table ITI TF-2:3.20.4.1.1.1-1. The message shall comply with the following pattern:

  • Event

-         EventID = EV(110112, DCM, “Query”)

-         EventTypeCode = EV(“PCC-X3”, “IHE Transactions”, “Retrieve Artifact”)

-         EventActionCode = “E” (Execute)

  • Source of the request (1..1)

-         UserID = The Artifact Consumer actor system identity

-         RoleIDCode = EV(110153, DCM, “Source”)

  • Human Requestor (0..n) one for each know User

-         UserID = Identity of the human that initiated the transaction.

-         RoleIDCode = Access Control role(s) the user holds that allows this transaction

  • Destination of the request (1..1)

-         Clinical Knowledge Resource Repository actor system identity

-         RoleIDCode = EV(110152, DCM, “Destination”)

  • Audit Source (1..1)

-         not specified

  • Patient (1..1)

-         ParticipantObjectTypeCode = “1” (Person)

-         ParticipantObjectTypeCodeRole = “1” (Patient)

-         ParticipantObjectID = The ‘patient’ parameter value

  • Query Parameters (1..1)

-         ParticipantObjectTypeCode = “2” (system object)

-         ParticipantObjectTypeCode Role = “24” (query)

-         ParticipantObjectIDTypeCode = EV(“PCC-X3”, “IHE Transactions”, “Retrieve Artifact”)

-         ParticipantObjectQuery = Requested URL including query parameters, base64 encoded

-         ParticipantObjectDetail = HTTP Request Headers contained in the query (e.g., Accept header)

-          

Volume 3 – Content Modules

 

Not applicable.

 


[1] HL7 is the registered trademark of Health Level Seven International.

[2] FHIR is the registered trademark of Health Level Seven International.

[6] Health Assessments in Primary Care, September 2003, AHRQ

[9] FHIR Patient Reported Outcomes Implementation Guide available from http://hl7.org/fhir/us/patient-reported-outcomes/2019May/pro-overview.html


[KB1] Check this

[KB2] TBD

[KB3] Modified from RCK

[KB4] Need to think about this

[KB5] Needs work

[KB6] I think we can delete this.

[KB7] I think we can delete this.

[KB8] I think we can delete this.