5 IHE IT Infrastructure Technical Framework ... - HL7 · IHE Infrastructure Technical Framework Supplement – Order & Referral by Form (ORF) _ _ Rev. x.x – 20xx-MM-DD 10

Copyright © 20xx: IHE International, Inc.

Integrating the Healthcare Enterprise

5

IHE IT Infrastructure Technical Framework Supplement

Order & Referral by Form (ORF) 10

Draft in preparation for Public Comment 15

Date: November 02, 2016> Author: TODO: Will be completed before submission

Email: <[email protected]> 20

IHE Infrastructure Technical Framework Supplement – Order & Referral by Form (ORF) ______________________________________________________________________________

__________________________________________________________________________ Rev. x.x – 20xx-MM-DD 2 Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Foreword

This is a supplement to the IHE IT Infrastructure Technical Framework V15.0. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks. 25 <For Public Comment:> This supplement is published on <Month XX, 201x> for Public Comment. Comments are invited and may be submitted at http://www.ihe.net/<domain>/<domain>comments.cfm. In order to be considered in development of the Trial Implementation version of the supplement, comments must be received by <Month XX, 201X>. 30

<For Trial Implementation:> This supplement is published on <Month XX, 201X> for Trial Implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing it will be incorporated into the <Domain Name> Technical Framework. Comments are invited and may be submitted at http://www.ihe.net/<domain>/<domain>comments.cfm. 35 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 40 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: www.ihe.net. 45 Information about the IHE <Domain Name> domain can be found at: http://www.ihe.net/Domains/index.cfm. Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at: http://www.ihe.net/About/process.cfm and http://www.ihe.net/profiles/index.cfm. 50

The current version of the IHE <Domain name>Technical Framework can be found at: http://www.ihe.net/Technical_Framework/index.cfm.

<Comments may be submitted on IHE Technical Framework templates any time at http://ihe.net/ihetemplates.cfm. Please enter comments/issues as soon as they are found. Do not wait until a future review cycle is announced. 55



Template Rev. 10.3

CONTENTS

Open Issues and Questions ......................................................................................................... 660 Closed Issues .............................................................................................................................. 6

Appendix A - Actor Summary Definitions ..................................................................................... 7Appendix B - Transaction Summary Definitions ........................................................................... 7Glossary .......................................................................................................................................... 7Volume 1 – Profiles ........................................................................................................................ 965

<Copyright Licenses> ................................................................................................................ 9<Domain-specific additions> .................................................................................................... 9X.1 (ORF) Actors, Transactions, and Content Modules .......................................................... 11

X.1.1 Actor Descriptions and Actor Profile Requirements ................................................. 14X.2 ORF Actor Options ........................................................................................................... 1470 X.3 ORF Required Actor Groupings ....................................................................................... 15X.4 ORF Overview .................................................................................................................. 16

X.4.2 Use Cases .................................................................................................................. 16X.4.2.1 Use Case #1: Questionnaire Creation ................................................................ 16

X.4.2.1.1 Questionnaire Creation Use Case Description ........................................... 1675 X.4.2.1.2 Questionnaire Creation Process Flow ........................................................ 17X.4.2.1.2 18Questionnaire Deployment Process Flow .................................................................. 18X.4.2.1.2 Questionnaire Usage Process Flow ............................................................ 18

X.5 ORF Security Considerations ............................................................................................ 1980 X.6 ORF Cross Profile Considerations .................................................................................... 20

Appendices .................................................................................................................................... 21Volume 2 – Transactions .............................................................................................................. 22

3.Y1 Query Questionnaire [ITI-Y1] ........................................................................................ 223.Y1.1 Scope ....................................................................................................................... 2285 3.Y1.2 Actor Roles .............................................................................................................. 223.Y1.3 Referenced Standards .............................................................................................. 233.Y1.4 Interaction Diagram ................................................................................................. 24

3.Y1.4.1 Query Questionnaire Resource Request .......................................................... 243.Y1.4.1.1 Trigger Events .......................................................................................... 2490 3.Y1.4.1.2 Message Semantics .................................................................................. 24

3.Y1.4.1.2.1 Query Search Parameters ................................................................. 253.Y1.4.1.2.2 Populating Expected Response Format ............................................ 26

3.Y1.4.1.3 Expected Actions ..................................................................................... 263.Y1.4.2 Query Questionnaire Resource Response ........................................................ 2795

3.Y1.4.2.1 Trigger Events .......................................................................................... 273.Y1.4.2.2 Message Semantics .................................................................................. 27

3.Y1.4.2.2.1 Questionnaire Resource Definition in the Context of Query Questionnaire Resource Response ..................................................... 27

3.Y1.4.2.2.2 Resource Bundling ........................................................................... 28100



Template Rev. 10.3

3.Y1.4.2.3 Conformance Resource ............................................................................ 283.Y1.4.3 Retrieve Questionnaire Resource Request ...................................................... 28

3.Y1.4.3.1 Trigger Events .......................................................................................... 283.Y1.4.3.2 Message Semantics .................................................................................. 283.Y1.4.3.3 Expected Actions ..................................................................................... 28105

3.Y1.4.4 Retrieve Questionnaire Resource Response .................................................... 293.Y1.4.4.1 Trigger Events .......................................................................................... 293.Y1.4.4.2 Message Semantics .................................................................................. 29

3.Y1.4.4.2.1 Questionnaire Resource Definition in the Context of Retrieve Questionnaire Resource Response ..................................................... 29110

3.Y2 Store Questionnaire [ITI-Y2] .......................................................................................... 303.Y2.1 Scope ....................................................................................................................... 303.Y2.2 Actor Roles .............................................................................................................. 303.Y2.3 Referenced Standards .............................................................................................. 313.Y2.4 Interaction Diagram ................................................................................................. 32115

3.Y2.4.1 Store Questionnaire Resource Request ............................................................ 323.Y2.4.1.1 Trigger Events .......................................................................................... 323.Y2.4.1.2 Message Semantics .................................................................................. 323.Y2.4.1.3 Expected Actions ..................................................................................... 32

3.Y2.4.2 Store Questionnaire Resource response .......................................................... 33120 3.Y2.4.2.1 Trigger Events .......................................................................................... 333.Y2.4.2.2 Message Semantics .................................................................................. 333.Y2.4.2.3 Expected Actions ..................................................................................... 33

3.Y2.4.3 Conformance Resource .................................................................................... 333.Y3 Retrieve Bundle [ITI-Y3] ................................................................................................ 33125

3.Y3.1 Scope ....................................................................................................................... 333.Y3.2 Actor Roles .............................................................................................................. 343.Y3.3 Referenced Standards .............................................................................................. 343.Y3.4 Interaction Diagram ................................................................................................. 35

3.Y3.4.1 Retrieve Bundle Operation .............................................................................. 35130 3.Y3.4.1.1 Trigger Events .......................................................................................... 353.Y2.4.1.2 Message Semantics .................................................................................. 353.Y3.4.1.3 Expected Actions ..................................................................................... 35

3.Y3.4.2 Retrieve Bundle Response ............................................................................... 363.Y3.4.2.1 Trigger Events .......................................................................................... 36135 3.Y3.4.2.2 Message Semantics .................................................................................. 363.Y3.4.2.3 Expected Actions ..................................................................................... 36

3.Y2.4.3 Conformance Resource .................................................................................... 363.Y4 Submit Bundle [ITI-Y4] .................................................................................................. 37

3.Y4.1 Scope ....................................................................................................................... 37140 3.Y4.2 Actor Roles .............................................................................................................. 373.Y4.3 Referenced Standard ................................................................................................ 383.Y4.4 Interaction Diagram ................................................................................................. 38

3.Y4.4.1 Submit Bundle ................................................................................................. 38



Template Rev. 10.3

3.Y4.4.1.1 Trigger Events .......................................................................................... 38145 3.Y4.4.1.2 Message Semantics .................................................................................. 39

3.Y4.4.1.2.1 Bundle Resources ............................................................................. 393.Y4.4.1.3 Expected Actions ..................................................................................... 39

3.Y4.4.2 Status Message ................................................................................................ 393.Y4.4.2.1 Trigger Events .......................................................................................... 39150 3.Y4.4.2.2 Message Semantics .................................................................................. 393.Y4.4.2.3 Expected Actions ..................................................................................... 40

3.Y4.4.3 Conformance Resource .................................................................................... 40Appendices .................................................................................................................................... 41Appendix A – <Appendix A Title> .............................................................................................. 41155

<Add Title> ....................................................................................................................... 41A.1Appendix B – <Appendix B Title> ............................................................................................... 41

<Add Title> ....................................................................................................................... 41B.1Volume 2 Namespace Additions .................................................................................................. 41Volume 3 – Content Modules ....................................................................................................... 42160

5. Namespaces and Vocabularies ........................................................................................ 426. Questionnaire Content ..................................................................................................... 42

6.1 Mandatory given elements of a questionnaire ................................................................... 426.2 Optional given elements of a questionnaire (One of them shall be provided) .................. 446.3 FHIR Representation ........................................................................................................ 44165

6.7 FHIR Resources Constraints ...................................................................................... 456.7.1 Composition resource ......................................................................................... 456.7.2 Questionnaire resource ....................................................................................... 466.7.3 QuestionnaireResponse resource ........................................................................ 47

Appendices .................................................................................................................................... 48170 Appendix A – Concepts and Codes for mapping of elements ...................................................... 48



Template Rev. 10.3

Introduction to this Supplement This supplement uses FHIR DSTU2 defined resources – Composition Resource, Questionnaire 175 Resource, QuestionnaireResponse Resource, Patient Resource, Practitioner Resource, ReferralRequest Resource, DiagnosticOrder Resource, ImagingStudy Resource, OperationOutcome Resource and Bundle. For details on HL7 FHIR see http://hl7.org/fhir/.

The Order & Referral by Form (ORF) Profile describes how forms for eReferrals, requests for information (such as diagnostic imaging results, lab results, discharge reports etc.) can be 180 defined, deployed and used in order to achieve a syntactical and semantically consistent cross enterprise information exchange. The profile supports creation and domain wide deployment of forms for structured and coded information exchange as well as exchange of such forms for referral, orders etc. The profile relies on FHIR e.g. the questionnaire resource. Because the profile relies heavily on the FHIR 185 Resources Questionnaire and QuestionnaireResponse, forms are addressed here as Questionnaires.

Open Issues and Questions

Closed Issues

1. WereviewedRFD,XForms and the apporach of the MRRT profile which expresses the format of 190 the templates in HTML5and uses XMLfor coded content. All of these apporaches were juged less apropriate. The FHIR based apporachwasselectedbecause it fits all requirements beeing at the same time easy to implement.



Template Rev. 10.3

General Introduction 195

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

None.

Appendix A - Actor Summary Definitions 200

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

Actor Definition

Questionnaire Creator A system that generates Questionnaires. Questionnaire Filler A system that renders Questionnaires and allows for filling in. The Questionnaire

Filler is also responsible for filling in the corresponding resources in the Bundle. Questionnaire Manager A system that assembles a Bundle containing the resources according to the

Questionnaire. The Questionnaire Manager may also populate elements of the questionnaire and the corresponding resources where appropriate.

Questionnaire Receiver A system that receives a Bundle (according to the Questionnaire) from a Questionnaire filler and renders it.

Questionnaire Processor The Questionnaire Processor is an integrated Questionnaire Manager, Questionnaire Receiver and Questionnaire Filler, supporting all of the transactions and options of those actors.

Appendix B - Transaction Summary Definitions Add the following transactions to the IHE Technical Frameworks General Introduction list of Transactions: 205

Transaction Definition

Query Questionnaire [ITI-Y1] A Questionnaire Filler queries for a list of Questionnaires from a Questionnaire Manager.

Retrieve Questionnaire [ITI-Y1] A Questionnaire Filler retrieves a Questionnaire from a Form Manager. Store Questionnaire [ITI-Y2] A Questionnaire Creator stores a Questionnaire to a Questionnaire Manager. Retrieve Bundle [ITI-Y3] A Questionnaire Filler receives a Bundle (according to the Questionnaire). Submit Bundle [ITI-Y4] A Questionnaire Filler submits a Bundle (according to the Questionnaire) and the

resources according to the Questionnaire to a Questionnaire Receiver.

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



Template Rev. 10.3

TODO: Will be completed before submission Glossary Term Definition



Template Rev. 10.3

Volume 1 – Profiles <Copyright Licenses> Add the following to the IHE Technical Frameworks General Introduction Copyright section:

None 215

<Domain-specific additions>

Add to Section …

None



Template Rev. 10.3

<Reserve a subsequent section number in the current domain Technical Framework Volume 1 220 (DOM TF-1). Replace the letter “X” with that section heading number. This number should not change when this supplement is added to the Final Text Technical Framework. In this manner, references should be able to be maintained going forward.>

X Order & Referral by Form (ORF) Profile This profile concerns directional information exchange between institutions such as requests for 225 referral, requests for previous imaging results, requests for second opinions etc. as well as corresponding responses. Such request are often done – or could be done – by means of structured forms. The same may apply for responses or documents coming along in case the response consists of a particular payload (e.g. exam results). However, forms for these purposes are in general proprietary constructs and seldom suitable for further machine processing. 230 Furthermore, such forms are more or less hard coded and concerned systems may not easily be updated for new use cases.

The ORF Profile addresses two issues: 1. It supports a scenario where an authority (e. g. health authority, expert panel etc.) defines

a set of forms (here called Questionnaires) for well-defined use cases which then are 235 deployed in a specific enterprise, domain etc. or even nationwide.

2. New use cases or changes in use cases can easily be handled either by modification of existing Questionnaires or new ones. The profile itself is agnostic to the nature of a particular Questionnaire and the ORF Profile puts only little limits on its definition.

Venders implementing the ORF Profile benefit of a high re-use potential. Applications which 240 support the ORF Profile may be used for various settings of directional information exchange. The specific needs of a particular use case will be covered by a adequate design of the Questionnaire and the value sets being used..

When writing the ORF Profile, the authors had the following use case in mind: A human fills in a Questionnaire for a particular request and sends this Questionnaire to a receiver. There, a 245 human reads the Questionnaire with its content. A corresponding response will work in the same way. There is possibly some payload coming with the Questionnaire: A request may be accompanied by results of preceding exams (e.g. images, reports); the response may be a diagnostic result.

The primary aim of the ORF Profile is to assure a consistent representation of Questionnaires at 250 both – filler- and receiver – site. But there is the need for further machine processing: at filler site in terms of prepopulating attributes with content from other applications (e.g. demographic data of a patient) whereas the receiver may want to have the content of the form ready for further processing in his applications. Obviously the two aims – semantic interoperability and flexibility in the definition of Questionnaires – are contradictory. The ORF Profile addresses this problem 255 by a mandatory set of mandatory given elements and codes with defined meaning which are part of every Questionnaire in the ORF Profile. It is up to the Questionnaire Creator to create Questionnaires with additional use case specific elements.



Template Rev. 10.3

Applications claiming for conformance with the ORF Profile shall:

• Render (and in case of the Questionnaire filler allow for data entry) all elements of a 260 questionnaire in the user interface (e.g. on screen, in print). Grouping of elements and the order of groups and elements within shall be adequately reproduced according to the Questionnaire.

• Be able to process all codes related to the mandatory given elements in a Questionnaire.

265 Venders of applications with Questionnaire Filler /Questionnaire Receiver Actors are strongly recommended to implement interfaces to other applications (such as HIS and PACS) for all data in the mandatory given elements of Questionnaires.

Applications designed like this will provide out-of-the-box interconnectivity for mandatory given elements as well as out-of-the-box interoperability for all questionnaires as far it concerns user 270 interfaces at filler and receiver site. Nothing speaks against interfaces for data in the use case specific part of a particular Questionnaire. One has however to keep in mind, that such interfaces are tied to a specific questionnaire. Ownership or other means, which prevent changes of the questionnaire by third parties, are therefore advisable. 275 The ORF profile deals with Transport, Workflow and Content. It is based on FHIR resources and in particular the FHIR Questionnaire resource. FHIR specifies RESTful Web services as a mean for transport. An implementation based on RESTful Web services is strongly recommended however not mandatory to comply with the ORF Profile. Workflow is addressed by the scope of ORF Profile which addresses directional information exchange with request and response. 280 Content is defined by a set of mandatory mandatory given elements and codes and the possibility to extend both as required by the use cases addressed.

X.1 (ORF) 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 285 http://www.ihe.net/Technical_Framework/index.cfm. Figure X.1-1 shows the actors directly involved in the ORF Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a mandatory grouping are shown in conjoined boxes. 290



Template Rev. 10.3

Figure X.1-1: Questionnaire Handling Actor Diagram

295

Table X.1-1 lists the transactions for each actor directly involved in the Order & Referral by Form Profile (ORF) 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: Order & Referral by Form Profile (ORF) Profile 300

Actors Transactions Optionality Reference Questionnaire Creator

Query Questionnaire [ITI-Y1]

R ITI TF-2: 3.Y1

Retrieve Questionnaire [ITI-Y1]

R ITI TF-2: 3.Y1

Store Questionnaire [ITI-Y2]

R ITI TF-2: 3.Y2

Questionnaire Manager


R ITI TF-2: 3.Y1


Questionnaire Creator

Questionnaire Filler



<- Query/Retrieve Questionnaire [ITI-Y1]

<- Store Questionnaire [ITI-Y2]

->

Query/Retrieve Questionnaire [ITI-Y1]

Questionnaire Processor

<- Submit Bundle [ITI-Y4] (Response)

Questionnaire Receiver


Submit Bundle [ITI-Y4] (Request) ->


Retrieve Bundle [ITI-Y3]

->

->



Template Rev. 10.3

Actors Transactions Optionality Reference Store Questionnaire

[ITI-Y2] (required for Stand alone Questionnaire Manager only, for Questionnaire Mangers grouped in a Questionnaire Processor optional)

Retrieve Bundle [ITI-Y3] R ITI TF-2: 3.Y3


Retrieve Questionnaire [ITI-Y1]

R ITI TF-2: 3.Y1

Submit Bundle [ITI-Y4]

R ITI TF-2: 3.Y4


Submit Bundle [ITI-Y4]

R ITI TF-2: 3.Y4

Figure X.1-1 shows the actors directly involved in the ORF Profile and the direction that the content is exchanged. The Submit Bundle transaction is marked as optional to allow solutions which choose a different communication transaction method like IHE XDS, XDR, XMD to be conform with this profile. 305



Template Rev. 10.3

A product implementation using this profile must group actors from this profile with actors from a workflow or transport profile to be functional. The grouping of the content module described in this profile to specific actors is described in more detail in the “Required Actor Groupings” section below. 310 Table X.1-2 lists the content module defined in the Order & Referral by Form Profile (ORF) Profile. To claim support with this profile, an actor shall support all required content modules (labeled “R”) and may support optional content modules (labeled “O”).

Table X.1-2: Order & Referral by Form Profile (ORF) Profile - Actors and Content 315

Modules Actors Content Modules Optionality Reference

<this should be a reference to a

location in Volume 3) Questionnaire Filler ORF Content Module See Note 1 R ITI TF-3: 6


ORF Content Module See Note 1 R See Note 1 ITI TF-3: 6

Note 1: The content of the form depends on the form which itself is defined by the FHIR Questionnaire The FHIR Questionnaire defines elements and structure of the form. Codes for coded attributes are provided with a corresponding value set (details see ORF Content Module)

320

X.1.1 Actor Descriptions and Actor Profile Requirements Most requirements are documented in Transactions (Volume 2) and Content Modules (Volume 3). This section documents any additional requirements on profile’s actors.

Questionnaire Filler and Questionnaire Receiver Actors may be implemented on a mobile device, although this is not the primary setting in mind. All other Actors will 325 rather be implemented in a stationary setting because the use case addressed involve mostly stationary applications.

X.2 ORF Actor Options <Modify the following Table listing the actors in this profile, the options available for each, and references to sections that state requirements for compliance to each Option. For actors with no 330 options, state “No options defined” in the Options column.> <Note: Options are directly carried over to the Integration Statements which are published by vendors for review by buyers. Too many options can be confusing for readers.> < Try to minimize options for Actors and only use if necessary.>

<Several options for Content Consumers are defined in PCC TF-2 section 3.1.1-3.1.4. It is 335 recommended that these options are reused for content module definitions, but read the option



Template Rev. 10.3

definitions thoroughly to be certain that they apply. If they do apply in their entirety, you will need to define a corresponding option in this profile. The recommended naming convention for a similar, but different, option is, for example, “View Option - <profile acronym>, etc., “View Option – CIRC”.> 340 Options that may be selected for each actor in this profile, if any, are listed in the table X.2-1. Dependencies between options when applicable are specified in notes.

Table X.2-1: <Profile Name> - Actors and Options Actor Option Name Reference

<either reference TF-3 or the applicable X.2.x subsection below

table> Questionnaire Creator No options defined --

Questionnaire Manager No options defined --


No options defined --

Questionnaire Receiver No options defined --

Questionnaire Processor No options defined --

Note: <Conditional or required options must be described in this SHORT note, for longer notes use section X.2.1.>, 345

X.3 ORF Required Actor Groupings An Actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the transactions required for the grouped actor (Column 2). 350

If this is a content profile, and actors from this profile are grouped with actors from a workflow or transport profile, the Content Bindings reference column references any specifications for mapping data from the content module into data elements from the workflow or transport transactions.

In some cases, required groupings are defined as at least one of an enumerated set of possible 355 actors; this is designated by merging column one into a single cell spanning multiple potential grouped actors. Notes are used to highlight this situation. Section X.5 describes some optional groupings that may be of interest for security considerations and section X.6 describes some optional groupings in other related profiles. <All Actors from this profile should be listed in Column 1. If no mandatory required grouping 360 exists, “none” should be listed in Column 2. If the content module actor is bound to a transport or workflow actor it will be listed with at least one binding reference. Do not use “XD*” as an actor name.>



Template Rev. 10.3

<In some cases, required groupings are defined as at least one of an enumerated set of possible actors; to designate this create a row for each potential actor grouping and merge column one to 365 form a single cell containing the profile actor which should be grouped with at least one of the actors in the spanned rows. In addition, a note should be included to explain the enumerated set. See example below showing Document Consumer needing to be grouped with at least one of XDS.b Document Consumer, XDR Document Recipient or XDM Portable Media Importer> <The author should pay special consideration to IT and security profiles in this grouping 370 section. Consideration should be given to Consistent Time (CT) Client, ATNA, as well as other profiles. For the sake of clarity and completeness, even if this table begins to become long, a line should be added for each actor for each of the required grouping for IT and security. Also see the ITI document titled ‘Cookbook: Preparing the IHE Profile Security Section’ at http://www.ihe.net/Technical_Framework/index.cfm for a list of suggested IT and security 375 groupings.>

<The Bindings column is used when a Content Module profile actor is grouped with a workflow or transport actor. Otherwise, mark it as “--”.>

Table X.3-1: ORF - Required Actor Groupings 380

ORF Actor Actor to be grouped with

Reference Content Bindings Reference

Questionnaire Filler Questionnaire Receiver

ITI TF-1: X.1.1 ITI TF-3: 6

Questionnaire Receiver Questionnaire Filler ITI TF-1: X.1.1 ITI TF-3: 6

Questionnaire Processor Questionnaire Manager Questionnaire Receiver Questionnaire Filler

ITI TF-1: X.1.1 ITI TF-3: 6

Questionnaire Filler CT Time Client ITI TF-1: 7.1 na

Questionnaire Receiver CT Time Client ITI TF-1: 7.1 na

Questionnaire Processor CT Time Client ITI TF-1: 7.1 na

X.4 ORF Overview

X.4.2 Use Cases

X.4.2.1 Use Case #1: Questionnaire Creation

X.4.2.1.1 Questionnaire Creation Use Case Description The national radiological society has launched the UOR Program, a nationwide initiative to make 385 ordering and referrals easier by means of Unified Ordering an Referral (UOR). The author of a new referral form defines a new Questionnaire Resource for a specific radiological examination



Template Rev. 10.3

(e.g. MRI). He does this with an application which acts as a Questionnaire Creator Actor. The author decides to query first already existing questionnaires, and retrieves one close to that what the new Questionnaire should represent. The author edits this Questionnaire and stores the result 390 back to the Questionnaire Manager.

X.4.2.1.2 Questionnaire Creation Process Flow

395

Figure X.4.2.2-1Questionnaire Creation Process Flow in ORF Profile

The Questionnaire Manager Actor supports two tasks in the Questionnaire Creation Process:

1. It acts as a repository for Questionnaire Resources and allows query and retrieve transactions with regard existing resources. The Store Questionnaire Transaction allows 400 for storing new questionnaires.

2. It allows for further processing in terms of assembling bundles and creating new resources as determined by the Questionnaire Resource.

Design Questionnaire (based on existing template if appropriate)

Questionnaire Manager/

Questionnaire Creator/

Query/Rettrieve Questionnaire [ITI-Y1] ->

Store Questionnaire [ITI-Y2] ->



Template Rev. 10.3

X.4.2.1.2 405

Questionnaire Deployment Process Flow

Figure X.4.2.2-1Questionnaire Deployment Process Flow in ORF Profile

The radiology service S-U-P-E-R-XR joins the UOR program. The service owns an application 410 acting as a Questionnaire Processor Actor which fulfills the following tasks.

1. It queries periodically the Questionnaire Manager of the national radiology society in order to provide always the newest versions of questionnaires to the referring doctors.

2. It populates elements such as the recipient name, telco and address with the data of S-U-P-E-R-XR. 415

3. Upon request by a referring doctor, it provides the questionnaire for the required order or referral (see section X.4.2.1.2 Questionnaire Usage Process Flow)

X.4.2.1.2 Questionnaire Usage Process Flow Dr. Miller has a new Patient John Doe who has had an MRI at the radiology service “S-U-P-E-R-420 XR”. Dr. Miller retrieves a special order questionnaire from the Questionnaire Manager at S-U-P-E-R-XR which allows ordering of images and reports of previous exams. Dr. Miller fills in this questionnaire and sends it back. At S-U-P-E-R-XR, a staff member will fill in another Questionnaire with a reply, attaches images and reports an sends all to Dr. Miller.

Populate appropriate Elements in Quertionnaire and Resources in Bundle



Query Questionnaire [ITI-Y1] ->

Retrieve Bundle [ITI-Y4] ->

Questionnaire Processor/

Questionnaire Receiver/

Questionnaire Filler/

Assemble Bundle (according to Questionnaire)



Template Rev. 10.3

425

Figure X.4.2.2 Questionnaire Usage Process Flow in ORF Profile

X.5 ORF Security Considerations 430

<Describe Profile-specific security considerations. This should include the outcomes of a risk assessment. This likely will include profile groupings, and residual risks that need to be assigned to the product design, system administration, or policy. See the ITI document titled ‘Cookbook: Preparing the IHE Profile Security Section’ at http://www.ihe.net/Technical_Framework/index.cfm for suggestions on risk assessment, risk 435 mitigation, and IT and security profiles.> <If this is not a content module, delete the sentence below. If this is a content module profile, you may want to expound upon the security considerations provided by grouped actors.> A resource server should not return any patient information unless proper authentication and communications security have been proven. 440 There are many reasonable methods of securing interoperability transactions. These security models can be layered in without modifying the characteristics of the ORF Profile transactions. The use of TLS is mandatory.

Fill in QuestionnaireResponse Resource and construct Bundle



Fill in QuestionnaireResponse Resource and construct Bundle

Submit Bundle (Request)

[ITI-Y4] ->

Questionnaire Processor/



<- Submit Bundle ( Response) [ITI-Y4]

Query/Retrieve Questionnaire [ITI-Y1] ->

Retrieve Bundle [ITI-Y3] ->




Template Rev. 10.3

User authentication on mobile devices is encouraged using Internet User Authorization (IUA) Profile. The network communication security and user authentication are layered in at the HTTP 445 transport layer and do not modify the interoperability characteristics defined in the ORF Profile.

The Security Audit logging (e.g., ATNA) is recommended. Support for ATNA-based audit logging on the mobile health device may be beyond the ability of this constrained environment.

In case vendors decide to include the Patient ID (patient.identifier) as a query parameter on the Resource URL (what would be out of the scope of ORF Profile), this URL pattern would present a 450 risk when using typical web server audit logging of URL requests, and browser history. In both of these cases the URL with the patient identity would be clearly visible. These risks should be mitigated in system or operational design.

X.6 ORF Cross Profile Considerations None 455



Template Rev. 10.3

Appendices None



Template Rev. 10.3

Volume 2 – Transactions Add section 3.Y

3.Y1 Query Questionnaire [ITI-Y1] 460

This section corresponds to Transaction ITI-Y1 of the IHE IT Infrastructure Technical Framework. Transaction ITI-Y1 is used by the Questionnaire Creator, Questionnaire Manager and Questionnaire Filler.

3.Y1.1 Scope This transaction is used by the the Questionnaire Creator, Questionnaire Manager and 465 Questionnaire Filler to solicit information about questionnaires whose data match data provided in the query parameters on the request. The request is received by the Questionnaire Manager. The Questionnaire Manager processes the request and returns a response with the matching questionnaires.

3.Y1.2 Actor Roles 470

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

Questionnaire Manager Questionnaire

Creator

Query/Retrieve Questionnaire

[ITI-***]

Questionnaire Manager Questionnaire Filler



Template Rev. 10.3

475 Table 3.Y1.2-1: Actor Roles

Actor: Questionnaire Creator

Role: A system that create new Questionnaires, based on existing ones if appropriate. In order to allow the latter, the Questionnaire Creator must query the Questionnaire Manager and retrieve suitable questionnaires.

Actor: Questionnaire Manager

Role: A system that provides Questionnaires. In addition the Questionnaire Manager can process questionnaires in terms of population of elements, creating of resources and bundles as needed. A Questionnaire Manager may also query other Questionnaire Managers (e .g. one of an authority responsible for the management of Questionnaires in a certain domain) and retrieve suitable questionnaires.

Actor: Questionnaire Filler

Role: A system that allows querying a Questionnaire Manager for a Questionnaire in order to fill in the elements for submission.

3.Y1.3 Referenced Standards HL7 FHIR Fast Healthcare Interoperability Resources DSTU2 (v1.0.2) http://hl7.org/fhir/DSTU2/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

480



Template Rev. 10.3

3.Y1.4 Interaction Diagram

3.Y1.4.1 Query Questionnaire Resource Request 485

Query Questionnaire Resource Request represents an HTTP GET parameterized query from the Questionnaire Creator/Filler/Manager to the Questionnaire Manager.

3.Y1.4.1.1 Trigger Events When a Questionnaire Creator/Filler/Manager needs to select a questionnaire based on information about questionnaires whose information matches a minimal set of known data, it 490 issues a Query Questionnaire Resource request.

3.Y1.4.1.2 Message Semantics The Query Questionnaire Resource request is conducted by the Questionnaire Creator/Filler/Manager by executing an HTTP GET against the Questionnaire Manager Questionnaire Resource URL. 495

The search target follows the FHIR http specification, addressing the Questionnaire Resource type http://hl7.org/fhir/DSTU2/http.html: GET [base]/[type]{?[parameters]{&_format=[mime-type]}}

This URL is configurable by the Questionnaire Manager and is subject to the following constraints. 500

Query Questionnaire Resource Request

Query Questionnaire Resource Response

Retrieve Questionnaire Resource Request

Retrieve Questionnaire Resource Response

Questionnaire Creator/Filler/Manager

Questionnaire

Manager



Template Rev. 10.3

The [parameters] represents a series of encoded name-value pairs representing the filter for the query specified in Section 3.Y.4.1.2.1, as well as control parameters to modify the behavior of the Questionnaire Manager such as response format, or pagination.

3.Y1.4.1.2.1 Query Search Parameters The Questionnaire Creator/Filler/Manager may supply and the Questionnaire Manager shall be 505 capable of processing all query parameters listed below. See http://hl7.org/implement/standards/fhir/http.html#mime-type for details on encoding. Questionnaire Managers may choose to support additional query parameters beyond the subset listed below. Such parameters are considered out of scope for this transaction. _id Search Parameter 510

This parameter of type string, when supplied, represents the resource identifier for the Questionnaire Resource being queried. See ITI TF-2x: Appendix Z.2.3 for use of the string data type. Note: A search using _id is always an exact match search.

code Search Parameter This parameter of type token, when supplied, specifies a code that corresponds to the 515 questionnaire or one of its groups whose information is being queried. See ITI TF-2x: Appendix Z.2.2 for use of the token data type.

identifier Search Parameters This repeating parameter of type token, when supplied, specifies an identifier associated with the questionnaire whose information is being queried (e.g., a local identifier, account 520 identifier, etc.). See ITI TF-2x: Appendix Z.2.2 for use of the token data type.

publisher Search Parameter

This parameter of type string, when supplied, specifies the author of the questionnaire whose information is being queried. For details on matching rules see ITI TF-2x: Appendix Z.2.3 . 525

status Search Parameter

This parameter of type token, when supplied, specifies a code that corresponds to the status of the questionnaire. See ITI TF-2x: Appendix Z.2.2 for use of the token data type.

title Search Parameter 530

This parameter of type string, when supplied, specifies all or part of the name of the questionnaire (title for the root group of the questionnaire) whose information is being queried. For details on matching rules see ITI TF-2x: Appendix Z.2.3 .

version Search Parameter



Template Rev. 10.3

This parameter of type string, when supplied, specifies the business version of the 535 questionnaire whose information is being queried. For details on matching rules see ITI TF-2x: Appendix Z.2.3 .

3.Y1.4.1.2.2 Populating Expected Response Format The FHIR standard provides encodings for responses as either XML or JSON. Questionnaire 540 Manager Actors shall support both message encodings, whilst Questionnaire Creator/Filler/Manager Actors shall support one and may support both.

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

3.Y1.4.1.3 Expected Actions The Questionnaire Manager shall return questionnaire resources that reflect the match to all of 545 the search criteria provided by the Questionnaire Creator/Filler/Manager. The Questionnaire Manager shall respond with a Query Questionnaire Resource Response synchronously (i.e., on the same connection as was used to initiate the request). If the Questionnaire Creator/Filler/Manager supplied a query parameter, or used a query parameter modifier which the Questionnaire Manager is not capable of utilizing, then the 550 Questionnaire Manager shall respond with an HTTP 400 (Bad request) status code and an OperationOutcome resource indicating the parameters in error.

The Questionnaire Manager shall respond to the query request as described by the following cases with a Query Questionnaire Resource Response described in Section 3.Y.4.2, and shall behave according to the cases listed below: 555 Case 1: The Questionnaire Manager finds at least one questionnaire resource matching the criteria sent as HTTP query parameters. HTTP 200 (OK) is returned as the HTTP status code.

A Resource Bundle is returned representing the result set. The Questionnaire Manager populates the total property of the bundle with the total number of matching results. One entry is 560 returned from the Questionnaire Manager for each Questionnaire Resource found. Case 2: The Questionnaire Manager fails to find in its information source, any questionnaire resource matching the criteria sent as HTTP query parameters. HTTP 200 (OK) is returned as the HTTP status code.

A Resource Bundle is returned representing the zero result set. The Questionnaire Manager 565 populates the total with a value of 0 indicating no results were found. No entry attributes are provided in the result.

Case 3: The Questionnaire Manager is not capable of producing a response in the requested format specified by _format parameter (specified in Section 3.Y.4.1.2.2).

HTTP 406 (Not Acceptable) is returned as the HTTP status code. 570



Template Rev. 10.3

An OperationOutcome Resource is returned indicating that the requested response format is not supported in an issue having:

Attribute Value

severity error

code {http://hl7.org/fhir/issue-type.html, ,not-supported}

The Questionnaire Manager may be capable of servicing requests for response formats not listed 575 in Section 3.Y1.4.1.2.5, but shall, at minimum, be capable of producing XML and JSON encodings.

The Questionnaire Manager may return other HTTP status codes to represent specific error conditions. When HTTP error status codes are returned by the Questionnaire Manager, they shall conform to the HTTP standard RFC 2616. Their use is not further constrained or specified by 580 this transaction.

3.Y1.4.2 Query Questionnaire Resource Response

3.Y1.4.2.1 Trigger Events The Questionnaire Manager found questionnaires matching the query parameters specified by the Questionnaire Creator/Filler/Manager as a result of a Query Questionnaire Resource Request. 585

3.Y1.4.2.2 Message Semantics The Query Questionnaire Resource Response is sent from the Questionnaire Manager to the Questionnaire Creator/Filler/Manager as a Bundle of Questionnaire Resources. The “content-type” of the response will depend upon the requested response format indicated by the Questionnaire Creator/Filler/Manager. 590 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.Y1.4.2.2.1 Questionnaire Resource Definition in the Context of Query Questionnaire Resource Response 595

The components of the Questionnaire Resource with cardinality greater than 0 (as shown below) are required, and the detailed description is provided here. All other attributes of the response are optional. The Questionnaire Resource contained within the Query Questionnaire Resource Response is described at http://hl7.org/fhir/DSTU2/questionnaire.html. The Questionnaire Resource shall 600 follow the rules according to the http://ihe.net/iti/qrf/trial/QRFQuestionnaireProfile Profile. See Content Volume 3 for profile description.



Template Rev. 10.3

3.Y1.4.2.2.2 Resource Bundling Please see ITI TF-2x: Appendix Z.1 for details on the IHE guidelines for implementing FHIR bundles. 605

3.Y1.4.2.3 Conformance Resource Questionnaire Managers implementing [ITI-Y1] should provide a Conformance Resource as described in ITI TF-2x: Appendix Z.4 indicating the query operation for the Questionnaire Resource has been implemented and shall include all query parameters implemented for the Questionnaire Resource. 610

3.Y1.4.3 Retrieve Questionnaire Resource Request The Retrieve Questionnaire Resource Request represents an HTTP GET from the Questionnaire Creator/Filler/Manager to the Questionnaire Manager and provides a mechanism for retrieving a single Questionnaire Resource with a known resource identifier.

3.Y1.4.3.1 Trigger Events 615

When the Questionnaire Creator/Filler/Manager possesses a Questionnaire Resource’s identifier (either through query, database lookup, or other mechanism) for which it requires additional or new information, it issues a Retrieve Questionnaire Resource operation.

3.Y1.4.3.2 Message Semantics The Retrieve Questionnaire Resource is conducted by executing an HTTP GET against the 620 Questionnaire Manager’s Questionnaire Resource URL, providing the resource id of the Questionnaire being retrieved. The target is formatted as:

GET [base]/Questionnaire/[resourceId]

The Questionnaire Manager shall respond to this query by sending a single Questionnaire Resource instance. The specification for [base] is identified in ITI TF-2c:3.Y1.4.1.2. 625

3.Y1.4.3.3 Expected Actions The Questionnaire Manager shall retrieve the Questionnaire by the Resource identifier on the HTTP GET supplied by the Questionnaire Creator/Filler/Manager. The Questionnaire Manager shall respond to the retrieve request as described by the following cases:

Case 1: The Questionnaire Manager finds in its information source the Questionnaire matching 630 the resourceId sent in the HTTP request.

HTTP 200 (OK) is returned as the HTTP status code.

A Questionnaire Resource is returned representing the result. Case 2: The Questionnaire Manager fails to find in its information source the Questionnaire matching the resourceId sent in the HTTP request. 635



Template Rev. 10.3

HTTP 404 (Not Found) is returned as the HTTP status code

An OperationOutcome Resource is returned indicating that the Patient Resource could not be found:

Attribute Value

severity error

type {http://hl7.org/fhir/vs/issue-type}not-found

640

The Questionnaire Manager may return other HTTP status codes to represent specific error conditions. When HTTP error status codes are returned by the Questionnaire Manager, they shall conform to the HTTP standard RFC 2616. Their use is not further constrained or specified by this transaction.

3.Y1.4.4 Retrieve Questionnaire Resource Response 645

The Questionnaire Manager’s response to a successful Questionnaire Retrieve shall be an HTTP 200 (OK) Status code with a FHIR Questionnaire Resource, or an appropriate error code as defined in Section 3.Y.4.2.2.1.

3.Y1.4.4.1 Trigger Events The Questionnaire Manager found a questionnaire matching the Resource identifier specified by 650 the Questionnaire Creator/Filler/Manager.

3.Y1.4.4.2 Message Semantics The Retrieve Questionnaire Resource response is sent from the Questionnaire Manager to the Questionnaire Creator/Filler/Manager as a single Questionnaire Resource. See http://hl7.org/fhir/DSTU2/questionnaire.html for details on this resource. 655 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. If the Questionnaire Manager is unable to produce a response in the requested format, it shall respond with an HTTP 400 error indicating that it was unable to fulfill the request. The Questionnaire Manager may be capable of servicing requests for response formats not listed, but 660 shall, at minimum, be capable of producing XML and JSON encodings.

3.Y1.4.4.2.1 Questionnaire Resource Definition in the Context of Retrieve Questionnaire Resource Response The Questionnaire Resource definition in the context of a retrieve operation is identical to the constraints placed on the Questionnaire Resource for a search (see Section 3.Y1.4.2.2.1) 665



Template Rev. 10.3

For the complete FHIR definition of this Resource, see http://hl7.org/fhir/DSTU2/questionnaire.html.

3.Y2 Store Questionnaire [ITI-Y2] This section corresponds to Transaction ITI-Y2 of the IHE IT Infrastructure Technical Framework. Transaction ITI-Y2 is used by the Questionnaire Creator and Questionnaire 670 Manager.

3.Y2.1 Scope Transaction ITI-Y2 is used by the Questionnaire Creator to store a questionnaire in the Questionnaire Manager.

3.Y2.2 Actor Roles 675


Questionnaire Manager Questionnaire

Creator

Store Questionnaire

[ITI-***]



Template Rev. 10.3

Table 3.Y2.2-1: Actor Roles

Actor: Questionnaire Creator

Role: A system that creates new Questionnaires.



680

3.Y2.3 Referenced Standards HL7 FHIR Fast Healthcare Interoperability Resources DSTU2 (v1.0.2) http://hl7.org/fhir/DSTU2/index.html








Template Rev. 10.3


685

3.Y2.4.1 Store Questionnaire Resource Request The Questionnaire Manager shall support the message semantics for create as defined at http://hl7.org/fhir/DSTU2/http.html#create as applicable to a Questionnaire Resource defined at http://hl7.org/fhir/DSTU2/questionnaire.html. The Questionnaire Resource is further constrained 690 by a profile, see in Volume 3.

3.Y2.4.1.1 Trigger Events When a Questionnaire Creator needs to store a questionnaire it issues a Store Questionnaire Resource Request.

3.Y2.4.1.2 Message Semantics 695

A Questionnaire Creator initiates a create request as defined at http://hl7.org/fhir/DSTU2/http.html#create on the Questionnaire Resource in order to store a new questionnaire. A Questionnaire Creator shall use either the XML or the JSON messaging formats as defined in FHIR. A Questionnaire Manager shall support receiving a request in both the JSON and the XML messaging formats as defined in FHIR. See ITI TF-2x: Appendix Z.6 for more 700 details.

3.Y2.4.1.3 Expected Actions The Questionnaire Manager shall issue a Store Questionnaire Response upon validation of a received Questionnaire Resource Request. See Section 3.Y2.4.2. The Questionnaire Manager shall respond with appropriate HTTP error codes as described at 705 http://hl7.org/fhir/DSTU2/http.html#create.

Store Questionnaire Resource Request

Store Questionnaire Resource Response

Questionnaire Creator Questionnaire Manager



Template Rev. 10.3

3.Y2.4.2 Store Questionnaire Resource response The Questionnaire Manager uses the response semantics as appropriate according to the FHIR operation initiated by the Questionnaire Creator. 710

3.Y2.4.2.1 Trigger Events A Questionnaire Manager sends a Store Questionnaire Resource response to the Questionnaire Creator upon validation of a received Store Questionnaire Resource request.

3.Y2.4.2.2 Message Semantics The Questionnaire Manager shall respond with the appropriate response codes as defined at 715 http://hl7.org/fhir/DSTU2/http.html#create.

3.Y2.4.2.3 Expected Actions There are no additional actions required on Questionnaire Creator upon receipt of the Store Questionnaire Response.

3.Y2.4.3 Conformance Resource 720

Questionnaire Manager implementing this transaction should provide a Conformance Resource as described in ITI TF-2x: Appendix Z.3 indicating the operation has been implemented.

3.Y3 Retrieve Bundle [ITI-Y3] This section corresponds to Transaction ITI-Y3 of the IHE Technical Framework. Transaction ITI-Y3 is used by the Questionnaire Filler and Questionnaire Manager. 725

3.Y3.1 Scope This transaction is used to retrieve a Bundle related to a specific Questionnaire.



Template Rev. 10.3

3.Y3.2 Actor Roles

730


Table 3.Y3.2-1: Actor Roles 735


Role: A system that allows querying a Questionnaire Manager for a suitable Questionnaire. It then retrieves the corresponding Bundle. After completion of the Questionnaire, the Questionnaire Filler submits it.



3.Y3.3 Referenced Standards

Retrieve Bundle [ITI-***]

Questionnaire Manager Questionnaire Filler



Template Rev. 10.3

HL7 FHIR Fast Healthcare Interoperability Resources DSTU2 (v1.0.2) http://hl7.org/fhir/DSTU2/index.html







3.Y3.4.1 Retrieve Bundle Operation 740

The Questionnaire Manager shall support a retrieve Bundle operation on the Questionnaire Resource according to https://www.hl7.org/fhir/operations.html.

3.Y3.4.1.1 Trigger Events When a Questionnaire Filler needs a Questionnaire bundle it issues a retrieve Bundle operation.

3.Y2.4.1.2 Message Semantics 745

A Questionnaire Filler initiates a retrieve Bundle upon the Questionnaire Resource with the following operation request: URL: [base]/Questionnaire/[id]/$retrieveBundle

The operation contains no parameters.

3.Y3.4.1.3 Expected Actions 750

The Questionnaire Manager shall create an empty document bundle according to the FHIR QRFDocumentProfile (see Volume 3). The Bundle is of type "document" and has a

Retrieve Bundle Request

Retrieve Bundle Response





Template Rev. 10.3

Composition resource as the first resource in the bundle, followed by a series of other resources, referenced from the Composition resource.

3.Y3.4.2 Retrieve Bundle Response 755

The Questionnaire Manager uses the response semantics as appropriate according to the FHIR operation initiated by the Questionnaire Filler.

3.Y3.4.2.1 Trigger Events A Questionnaire Manager sends a Retrieve Bundle operation response to the Questionnaire Filler upon invoking the retrieveBundle operation. 760

3.Y3.4.2.2 Message Semantics The Questionnaire Manager shall respond with the appropriate response codes as defined at https://www.hl7.org/fhir/operations.html.

3.Y3.4.2.3 Expected Actions After receiving the Bundle the Questionnaire Filler shall provide a User Interface/Visualization 765 of the Bundle to the User so that he can add the information. After completing the form/questionnaire by the user, the Questionnaire Filler shall update the bundle and included resources in the bundle with the information provided by the User.

3.Y2.4.3 Conformance Resource Questionnaire Managers implementing this operation should provide a Conformance Resource as 770 described in ITI TF-2x: Appendix Z.3 indicating the operation has been implemented.



Template Rev. 10.3

3.Y4 Submit Bundle [ITI-Y4] This section corresponds to Transaction ITI-Y4 of the IHE Technical Framework. Transaction ITI-Y4 is used by the Questionnaire Filler and Questionnaire Receiver. 775

3.Y4.1 Scope This transaction is used to submit a filled in questionnaire together with required additional resources and attachments in a Bundle from a Questionnaire Filler to a Questionnaire Receiver.

3.Y4.2 Actor Roles

780


Questionnaire Receiver Questionnaire Filler

Submit Bundle [ITI-***]



Template Rev. 10.3

Table 3.Y4.2-1: Actor Roles 785


Role: A system that allows querying a Questionnaire Manager for a Questionnaire in order to fill in the elements. Upon completion, a corresponding bundle will be submitted to the Questionnaire Receiver.

Actor: Questionnaire Receiver

Role: A system that receives bundles and processes them compliant to the ORF Profile.

3.Y4.3 Referenced Standard HL7 FHIR Fast Healthcare Interoperability Resources DSTU2 (v1.0.2) http://hl7.org/fhir/DSTU2/index.html







3.Y4.4.1 Submit Bundle 790

The transaction uses the HTTP POST method on the target Questionnaire Bundle endpoint to convey the questionnaire bundle as a FHIR transaction.

3.Y4.4.1.1 Trigger Events After the Questionnaire is completed by the Questionnaire filler user, the Questionnaire Filler submits a the corresponding bundle to the Questionnaire receiver. 795


Submit Bundle


Status



Template Rev. 10.3

3.Y4.4.1.2 Message Semantics The Questionnaire Manager shall initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of a FHIR Bundle Resource containing the Composition resource and all resources referenced in, in particular one Questionnaire Resource, one QuestionnaireResponse Resource and additional resources according to the Questionnaire 800 Profile. The media type of the HTTP body shall be either “application/json+fhir” or “application/xml+fhir”.

See http://hl7.org/fhir/DSTU2/http.html#transaction for complete requirements of a transaction. See http://hl7.org/fhir/DSTU2/bundle-transaction.html for example of a transaction bundle. 805 Submit Bundle is sent to the base URI as defined in FHIR. See http://hl7.org/fhir/DSTU2/http.html for the definition of “http” access methods and “base”.

3.Y4.4.1.2.1 Bundle Resources For complete information on constructing a FHIR Bundle Resource, see: http://hl7.org/fhir/DSTU2/bundle.html 810 The FHIR Bundle.meta.profile shall include the value “http://ihe.net/iti/qrf/trial/QRFDocumentProfile”.

3.Y4.4.1.3 Expected Actions The Questionnaire Receiver shall accept both media types application/json+fhir and application/xml+fhir. 815

On receipt of the submission, the Questionnaire Receiver shall validate the resources and respond with one of the HTTP codes defined in Section 3.Y4.4.2.2 Message Semantics.

3.Y4.4.2 Status Message The Questionnaire receiver returns a HTTP Status code appropriate to the processing, conforming to the transaction specification requirements as specified in 820 http://hl7.org/fhir/DSTU2/http.html#transaction

3.Y4.4.2.1 Trigger Events This message shall be sent once the questionnaire bundle is received and completely processed.

3.Y4.4.2.2 Message Semantics When the Questionnaire Receiver has successfully processed the POST transaction, then the 825 Questionnaire Receiver shall return an HTTP response with an overall status code.

In order to allow the Questionnaire Filler to know the outcomes of processing the transaction, and the identities assigned to the resources by the Questionnaire Receiver, the Questionnaire



Template Rev. 10.3

Receiver shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. See FHIR 830 http://hl7.org/fhir/DSTU2/bundle.html#transaction-response

Each entry element shall contain a response element which details the outcome of processing the entry - the HTTP status code. All other elements are not required.

On success, the Questionnaire Receiver shall return the HTTP status code 200 – OK. Guidance on handling Access Denied related to use of 403 and 404 can be found in ITI TF-2x: 835 Appendix Z.7. On failure, the Questionnaire Receiver shall return the HTTP status codes as follows:

• 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules like reference inconsistencies, schema violations, etc.

• 404 Not Found - resource type not supported. 840 • 422 Unprocessable Entity - one or more proposed resources violated applicable FHIR

profiles or server business rules. In addition, the Questionnaire Receiver may also send 5xx HTTP status codes to indicate non-transaction related failures. Note that the Questionnaire Filler may also encounter non-FHIR endpoints which will not return an Bundle in the response. 845

The Questionnaire Receiver may return HTTP redirect responses (responses with HTTP status codes 301, 302, 303 or 307) in response to a request.

3.Y4.4.2.3 Expected Actions If the Questionnaire Receiver returns an HTTP redirect response (HTTP status codes 301, 302, 303, or 307), the Questionnaire Filler shall follow that redirection, although it may stop 850 processing if it detects a loop. The Questionnaire Receiver processes the results according to application-defined rules.

If a Questionnaire Receiver cannot automatically recover from an error condition, at a minimum, it should display the error to the user.

3.Y4.4.3 Conformance Resource 855

Questionnaire Receiver implementing this transaction should provide a Conformance Resource as described in ITI TF-2x: Appendix Z.3 indicating the operation has been implemented.



Template Rev. 10.3

Appendices <Detailed cross transaction relationships or mapping details are described in an appendix in 860 Volume 2x. Volume 2 appendices may be informational or normative. Immediately after the title of a Volume 2 appendix, provide a very explicit statement defining whether this new appendix is informative or normative.>

Appendix A – <Appendix A Title> 865

Appendix A text goes here.

<Add Title> A.1Appendix A.1 text goes here

Appendix B – <Appendix B Title> Appendix B text goes here. 870

<Add Title> B.1Appendix B.1 text goes here.

Volume 2 Namespace Additions Add the following terms to the IHE General Introduction Appendix G: 875

<Please explicitly identify all new OIDs, UIDs, URNs, etc., defined specifically for this profile. These will be added to the IHE TF General Introduction namespace appendix when it becomes available. These items should be collected from the sections above, and listed here as additions when this document is published for Trial Implementation. This section will be deleted prior to inclusion into the Technical Framework as Final Text, but should be present for publication of 880 Public Comment and Trial Implementation.>



Template Rev. 10.3

Volume 3 – Content Modules 885

5. Namespaces and Vocabularies Add to section 5 Namespaces and Vocabularies

Current Volume 3 does not contain this section

Add section 6 890

6. Questionnaire Content This section describes the content of a form. The following definitions apply:

Request and responses consist of filled in questionnaires. Some elements of the questionnaire are mandatory given elements (such as author, data entry person, receiver etc. are always present in a 895 questionnaire compliant to the ORF Profile. In addition, a questionnaire will contain elements which are use case specific. The ORF Profile makes no assumptions about the nature of such elements: structure and content (including coding of codes elements) are in the responsibility of those creating a form for a particular use case. As this profile is based on FHIR, the following rules apply: 900

Elements, grouping of elements, order of groups and order of elements within groups of a questionnaire shall be defined in a Questionnaire Resource. The Questionnaire Resource is defined by means of the Questionnaire Creator Actor. Based on the Questionnaire, a Questionnaire Manager Actor defines a QuestionnaireResponse and appropriate additional resources aimed at transmitting the information provided by the 905 Questionnaire filler in a standardized structured form. In addition, the Questionnaire Manager shall create a QuestionnaireResponse Resource (based on the Questionnaire Resource), a Composition Resource. Upon completion of the questionnaire, the Questionnaire Manager shall create a bundle with all resources mentioned above. Questionnaires may be accompanied by additional material which can be attached or sent by 910 postal mail (e.g. xray-films or paper documents). The use case may require some references between attached objects (e. g. which pdf-reports belongs to which imaging study).

6.1 Mandatory given elements of a questionnaire A questionnaire shall have a set of mandatory given elements (e.g. author, data entry person, receiver etc. Table 6.1.-1 lists the mandatory given elements 915



Template Rev. 10.3

Table 6.1-1: Mandatory given elements in Questionnaires compliant to the ORF Profile

Name

Role taker HL 7 V3 Equivalent

FHIR Representation

Comment

Human Organi-zation

Author X X Author Practitioner The person responsible for Form Content

Date Entry Person

X X DataEnterer Practitioner

The person who has typed/filled in the Form Content.

Urgent Notification Contact for this document

X X PrimaryInformationRecipient

Practitioner

An information recipient to notify for urgent matters (e.g. in a radiology service, the Radiologist has to be called by phone right away at the time the images arrive.

Urgent Notification Contact for the Response to this document

X X PrimaryInformationRecipient

Practitioner An information recipient to notify for urgent matters about the response. (e.g. in a clinical setting, the referring doctor has to be called by phone right away at the time the images and reports arrive.

The Urgent Notification Contact for the Response can be specified already in the request. At the time the response is written, this element shall be populated to the Urgent Notification Contact element in the response

Receiver X X Practitioner Person and/or institution who receives the Bundle

Patient X Patient The principle target of a particular Form Content is one patient (for obstetrical and neonatal use cases see….).

PrecedentDocumentId

na na This element provides a link to the preceding document in a thread (e.g. from a response to the request

Date na na Date, the document was created



Template Rev. 10.3

Priority na na DiagnosticOrderPriority

The priority shall be indicated in the one of the resources in the table “Optional given elements of a questionnaire”

920

6.2 Optional given elements of a questionnaire (One of them shall be provided)

Resource Description DiagnosticOrder ReferralRequest CommunicationRequest CommunicationRequest applies for all

documents which are not a DiagnosticOrder or a ReferralRequest

There may be the need to provide a linkage between a particular files or between a particular file 925 and an imaging study (e.g. a link between a PDF-File containing a report and a DICOM study). Such links shall be expressed with a DocumentManifest as follows:

Resource Elements Description DocumentManifest type (e.g. LOINC 18748-4 for Diagnostic Imaging Study) content pAttchment Attachment contentType Mime Type data Data inline, base64ed (contains the file; e.g. a PDF-Report) related Reference

(ImagingStudy)

ImagingStudyResource provides StudyIsntanceUID etc.

6.3 FHIR Representation 930

FHIR depicts forms (questionnaires) in a Questionnaire Resource. A Questionnaire Resource can be conceived as an empty questionnaire where as the filled in questionnaire refers to the QuestionnaireResponse Resource. QuestionnaireResponse Resources are certainly structured but due to their flexibility in design not in a standardized manner. FHIR addresses this issue by means of its standardized resources. 935

The Order & Referral by Form Profile is based on two FHIR Resources profiles. For details on profiling FHIR see HL7 FHIR http://www.hl7.org/fhir/profiling.html. For details on FHIR resources and data-types see HL7 FHIR http://hl7.org/fhir/DSTU2/.

1. The Order & Referral by Form Questionnaire (ORF) Profile defines the usage of the FHIR Questionnaire Resource within the Order & Referral by Form Profile. The 940



Template Rev. 10.3

Questionnaire Resource is an organized collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. They may be simple flat lists of questions or can be hierarchically organized in groups and sub-groups, each containing questions. The Questionnaire defines the questions to be asked, how they are ordered and grouped and what the constraints are on 945 the allowed answers. The results of a Questionnaire can be communicated using the QuestionnaireResponse resource (see http://www.hl7.org/fhir/questionnaire.html).

2. The Order & Referral by Form Document (ORF) Profile defines the usage of the FHIR Bundle within the Order & Referral by Form (ORF) Profile. The QRFDocumentProfile consist of a FHIR document (bundle) that contains the results of a filled in Questionnaire 950 (QuestionnaireResponse Resource) together with the structured resources which map all information filled in the questionnaire. The Bundle is of type "document" and has a Composition resource as the first resource in the bundle, followed by a series of other resources, referenced from the Composition resource. The bundle gathers all the content of the document into a single XML document which may be signed and managed as 955 required. The resources include both human readable and computer processable sections. In addition, a bundle as defined in this profile shall include a CSS stylesheets and optionally it may include a signature. Any resource referenced directly in the Composition Resource shall be included in the bundle. Other resources that these referenced resources refer to shall also be included in 960 the bundle. Including these additional resources will make the document bigger, but will save applications from needing to retrieve the linked resources.

6.7 FHIR Resources Constraints This section lists FHIR resources where this profile provides additional information. Resources 965 not listed here follow the specifications of FHIR. For details refer to https://www.hl7.org/fhir/resourcelist.html.

6.7.1 Composition resource

FHIR Composition Resource FHIR Type IHE Constraint Notes Element Cardi

nality Optionality

text 1..1 R Narrative Text of the composition.

extension extension QRFPrecedentDocument Identifier Identifier of the

document which precedes this document in a thread.

extension QRFDataEntryPerson Practitioner 0..1 O extension QRFUrgentNotificiationConta

ctForRequest Practitioner 0..1 R



Template Rev. 10.3

extension QRFUrgentNotificiationContactForResponse

Practitioner 0..1 O

extension QRFRequestReceiver Practitioner 0..1 R extension QRFResponseReceiver Practitioner 0..1 O extension QRFVisitNumber Identifier 0..1 O identifier Identifier 1..1 R Identifier for this

composition. date dateTime 1..1 R Composition editing

time type Codeable

Concept 1..1

class Codeable Concept

1..1

title string 1..1 R Meaningful title status code 1..1 R subject Reference(Patient) 1..1 R author Reference

(Practitioner) 1..1 R

section A section must at least one of text, entries, or sub-sections. title string 1..1 R entry Reference

(Questionnaire) 1..1 R Questionnaire

Reference (QuestionnaireResponse)

1..1 R QuestionnaireResponse

Reference (ANY) 0..n R Additionally structured entries like DiagnosticOrder ReferralRequest CommonicationRequest

970

6.7.2 Questionnaire resource The intention of the ORF profile is to provide a standardized representation of forms at sender and receiver site as well. This is achieved with the Questionnaire Resource, which defines representation of all elements for the user (with the help of a CCS) and user interaction as well (e.g. with drop down lists). 975 This approach requires two things:

1. Precise definition of all questions 2. Mapping between elements of the Questionnaire Resource and the corresponding

elements of the other resources in the bundle 980

Both is achieved by assigning meaningful concepts to all elements concerned. For codes refer to Appendix A.

Table 6.7.2-1: Content of the Questionnaire resource



Template Rev. 10.3

985 FHIR Questionnaire Resource

FHIR Type IHE Constraint Notes Cardi-

nality Optio-nality

identifier Identifier 1..1 R version string 1..1 R status code 1..1 R group 1..1 R Root group: Groups may either contain

questions or groups but not both linkId string group 0..* (R) Nested questionnaire group. Groups may

either contain questions or groups but not both; there may be 1..* nested groups

question 0..* (R) . linkId string 1..1 R concept code 1..1 R Concept that represents this question on a

questionnaire: used for mapping to the corresponding elements in the other resources in the bundle.

text string type code 1..1 R required boolean 0..1 O repeats boolean 0..1 O Whether the question can have multiple

answers A question must use either option or options, not both. options Reference

(ValueSet) 0..1 (R) Valueset containing permitted answers

option Coding 0..* (R) Permitted answers

6.7.3 QuestionnaireResponse resource The QuestionnaireResponse Resource depends of the definition of the Questionnaire Resource and is therefore use case specific. For deriving QuestionnaireResponse Resources from the Questionnaire Resources refer to https://www.hl7.org/fhir/questionnaireresponse.html. 990



Template Rev. 10.3

Appendices <Add any applicable appendices below; NA if none.>

Appendix A – Concepts and Codes for mapping of elements Concepts and Codes for mapping of elements are Use Case specific.

TODO: Codes for mandatory and optional and mandatory given elements will be defined upon 995 the results of the public comments process.

5 IHE IT Infrastructure Technical Framework ... - HL7 · IHE Infrastructure Technical Framework Supplement – Order & Referral by Form (ORF) _____ _____ Rev. x.x – 20xx-MM-DD 10

Documents

5 IHE IT Infrastructure Technical Framework ... - HL7 · IHE Infrastructure Technical Framework Supplement – Order & Referral by Form (ORF) _ _ Rev. x.x – 20xx-MM-DD 10