0.10.0 - STU 1 Ballot

CH ORF (R4), published by HL7 Switzerland. This is not an authorized publication; it is the continuous build for version 0.10.0). This version is based on the current content of and changes regularly. See the Directory of published versions


This Implementation Guide is under STU ballot by HL7 Switzerland until September 24th, 2021 midnight. Please add your feedback via the ‘Propose a change’-link in the footer on the page where you have comments.

This Implementation Guide uses FHIR defined resources – Composition Resource, Questionnaire Resource, QuestionnaireResponse Resource, Patient Resource, PractitionerRole Resource, Practitioner Resource, Organization Resource, ServiceRequest Resource and Bundle Resource from FHIR R4. For details on HL7 FHIR R4 see

The Order & Referral by Form (ORF) Implementation Guide describes how forms for eReferrals, requests for information (such as diagnostic imaging results, lab results, discharge reports etc.) can be defined, deployed and used in order to achieve a syntactical and semantically consistent cross enterprise information exchange.

The Implementation Guide 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 Implementation Guide relies on FHIR e.g. the questionnaire resource. Because the Implementation Guide relies heavily on the FHIR Resources Questionnaire and QuestionnaireResponse, forms are addressed here as Questionnaires.

This Implementation Guide is derived from the HL7 Structured Data Capture Implementation Guide, see SDC IG (v2.7.0) and uses the Swiss Core Profiles, see CH Core (v2.0.0).

Download: You can download this Implementation Guide in NPM format from here.

Volume 1 – Order & Referral by Form (CH ORF) Implementation Guide

This Implementation Guide concerns directional information exchange between institutions such as requests for 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. Furthermore, such forms are more or less hard coded and concerned systems may not easily be updated for new use cases.

The ORF Implementation Guide 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 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 Implementation Guide itself is agnostic to the nature of a particular Questionnaire and the ORF Implementation Guide puts only little limits on its definition.

Vendors implementing the ORF Implementation Guide benefit of a high re-use potential. Applications which support the ORF Implementation Guide 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 Implementation Guide, 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 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 Implementation Guide is to assure a consistent representation of Questionnaires at 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 Implementation Guide addresses this problem by a mandatory set of generic elements and codes with defined meaning which are part of every Questionnaire in the ORF Implementation Guide. It is up to a SDC Form Designer to create Questionnaires with additional use case specific elements.

Applications claiming for conformance with the ORF Implementation Guide shall:

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

Vendors 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 generics elements of Questionnaires.

Applications designed like this will provide out-of-the-box interconnectivity for generic elements as well as out-of-the-box interoperability for all questionnaires as far it concerns user 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.

The ORF Implementation Guide 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 Implementation Guide. Workflow is addressed by the scope of ORF Implementation Guide which addresses directional information exchange with request and response. Content is defined by a set of generic given elements and codes and the possibility to extend both as required by the use cases addressed.

ORF Actors, Transactions, and Content Modules

This Implementation Guide depends on the SDC Implementation Guide:

Questionnaires and forms permeate healthcare. They are used to capture administrative data, claims data, clinical information, research information, for public health reporting - every type of data that is manipulated by healthcare systems. They provide a user-friendly mechanism for capturing data in a consistent way. In FHIR, forms are represented using the Questionnaire resource and completed forms are represented using the QuestionnaireResponse resource. The base FHIR specification defines these resources but doesn't provide much guidance around how they should be used, nor does it set minimal expectations for interoperation. The SDC Implementation Guide provides a set of guidance around the use of Questionnaire and QuestionnaireResponse.

SDC Specification relevant to CH ORF

These sections define the different use-cases supported by SDC, specify the profile(s) needed to meet the use-cases.

  1. Finding a Questionnaire describes expectations for systems serving as form repositories as well as clients who will need to search for forms.
  2. Advanced Rendering describes how to use various questions and the base capabilities of Questionnaire to render different types of form elements
  3. Form Behavior describes how to design 'active' forms that adjust what information is displayed and/or that perform calculations based on user input
  4. Adaptive Forms describes an architecture to support completing forms where the questionnaire is not pre-defined and instead is dynamically developed based on the user's answers
  5. Questionnaire Population describes how to design questionnaires to support pre-population of answers and how to use services that support pre-populating forms
  6. Data Extraction describes how to design questionnaires to support converting completed forms into a FHIR resource or Bundle of FHIR resources for subsequent analysis
SDC Actors and workflow relevant to CH ORF

To be considered SDC-conformant, a system must adhere to the requirements defined by at least one of these statements. Some systems might choose to comply with more than one.

  • SDC Form Designer - System responsible for creating and editing form designs
  • SDC Form Filler - System responsible for capturing user form input to produce partially or fully completed forms
  • SDC Form Manager - Repository for form definitions. May also perform pre-population
  • SDC Form Response Manager - Searchable repository for storage and retrieval of completed and partially completed forms.
  • SDC Form Receiver - Write-only destination to which forms are sent for processing

The relationship between these roles and a summary of how they can interact is shown in [Figure 1].

[Figure 1] SDC Role operations


This section defines the actors, transactions, and/or content modules specific to this Implementation Guide.

Actor Definition
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, corresponds to the SDC Form Filler.
Questionnaire Receiver A system that receives a Bundle (according to the Questionnaire) from a Questionnaire filler and renders it, corresponds to the SDC Form Receiver.

[Table 1] Actors in the ORF Implementation Guide

[Figure 2] Questionnaire Handling Actor Diagram

[Figure 2] shows the actors directly involved in the ORF Implementation Guide and the relevant transactions between them. Actors which have a mandatory grouping are shown in conjoined boxes.

Actors Transactions Optionality Reference
Questionnaire Filler Submit Bundle [CH ORF-1] O 3.1
Questionnaire Receiver Submit Bundle[CH ORF-1] O 3.1

[Table 2] Actors in the ORF Implementation Guide

[Table 2] lists the transactions for each actor directly involved in the Order & Referral by Form (ORF) Implementation Guide. To claim compliance with this Implementation Guide, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).

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 Implementation Guide.

A product implementation using this Implementation Guide group actors from this with actors from a workflow or transport Implementation Guide to be functional. The grouping of the content module described in this Implementation Guide to specific actors is described in more detail in the “Required Actor Groupings” section below.

[Table 3] lists the content module defined in the Order & Referral by Form (ORF)) Implementation Guide. To claim support with this Implementation Guide, an actor shall support all required content modules (labeled “R”) and may support optional content modules (labeled “O”). The content module is based on the [Swiss core] profiles.

Actors Content Modules Optionality Reference
Questionnaire Filler ORF Content Module [Note 1] R Vol 3
Questionnaire Receiver ORF Content Module [Note 1] R [Note 1] Vol 3

[Table 3] Order & Referral by Form (ORF) Implementation Guide - Actors and Content Modules

[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)

ORF Actor Descriptions and Actor Requirements

Most requirements are documented in Transactions (Volume 2) and Content Modules (Volume 3). This section documents any additional requirements on Implementation Guide'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 rather be implemented in a stationary setting because the use case addressed involve mostly stationary applications.

ORF Actor Options

Options that may be selected for each actor in this profile, if any, are listed in [Table 4]. Dependencies between options when applicable are specified in notes.

Actor Option Name Reference
Questionnaire Filler No options defined --
Questionnaire Receiver No options defined --

[Table 4]ORF - Actors and Options

ORF Required Actor Groupings

An Actor from this Implementation Guide (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).

If this is a content module, and actors from this Implementation Guide 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 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 1.5 describes some optional groupings that may be of interest for security considerations and section 1.6 describes some optional groupings in other related profiles.

ORF Actor Actor to be grouped with Reference Content Bindings Reference
Questionnaire Filler Questionnaire Receiver 1.1 Volume 3
Questionnaire Receiver Questionnaire Filler 1.1 Volume 3
Questionnaire Filler CT Time Client ITI TF-1: 7.1 na
Questionnaire Receiver CT Time Client ITI TF-1: 7.1 na

[Table 5]ORF - Required Actor Groupings

ORF Overview

Use Cases
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-XR”. Dr. Miller retrieves a special order questionnaire from the SDC Form 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.

ORF Security Considerations

A resource server should not return any patient information unless proper authentication and communications security have been proven.

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.

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 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 Implementation Guide), this URL pattern would present a 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.

Volume 2 – Transactions

Submit Bundle [CH ORF-1]

This section corresponds to Transaction CH ORF-1. Transaction CH ORF-1 is used by the Questionnaire Filler and Questionnaire Receiver. This is a combination of extracting resources outlined in the SDC Workflow 10.1 Optional EHR extracts information from Questionnaire Response and sending a Bundle including the extracted information according to Volume 3 and Questionnaire Response to the Questionnaire Receiver.


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.

Actor Roles

[Figure 3] Use Case Diagram

Actor Role
Questionnaire Filler A system that allows querying a SDC Form Manager in order to fill in the elements for a Questionnaire Response. Upon completion, a corresponding bundle will be submitted to the Questionnaire Receiver.
Questionnaire Receiver A system that receives bundles and processes them compliant to the ORF Profile.

[Table 6]Actor Roles

Referenced Standard
HL7 FHIR Fast Healthcare Interoperability Resources
HL7 SDC IG Structured Data Capture Implementation Guide
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
IHE Appendix on HL7 FHIR
Interaction Diagram

[Figure 4] Interaction Diagram

Submit Bundle

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

Trigger Events

After the Questionnaire is completed by the Questionnaire filler user, the Questionnaire Filler submits a the corresponding bundle to the Questionnaire receiver.

Message Semantics

The Questionnaire Filler 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 Profile.

The media type of the HTTP body shall be either “application/json+fhir” or “application/xml+fhir”.

See for complete requirements of a transaction. See for example of a transaction bundle.

Submit Bundle is sent to the base URI as defined in FHIR. See for the definition of “http” access methods and “base”.

Bundle Resources

For complete information on constructing a FHIR Bundle Resource, see:

The FHIR Bundle.meta.profile shall include the value

Expected Actions

The Questionnaire Receiver shall accept both media types application/json+fhir and application/xml+fhir.

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

Status Message

The Questionnaire receiver returns a HTTP Status code appropriate to the processing, conforming to the transaction specification requirements as specified in

Trigger Events

This message shall be sent once the questionnaire bundle is received and completely processed.

Message Semantics

When the Questionnaire Receiver has successfully processed the POST transaction, then the 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 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

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 IHE Appendix on HL7 FHIR 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.
  • 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.

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

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 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.

Conformance Resource

Questionnaire Receiver implementing this transaction should provide a Conformance Resource as described in IHE Appendix on HL7 FHIR Z.3 indicating the operation has been implemented.

Volume 3 – Content Modules

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 generic given elements (such as author, data entry person, receiver etc. are always present in a questionnaire compliant to the ORF Implementation Guide. In addition, a questionnaire will contain elements which are use case specific. The ORF Implementation Guide 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 Implementation Guide is based on FHIR, the following rules apply:

Items, grouping of items, 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 SDC From Designer and made available by the SDC Form Manager.

Based on the Questionnaire, a Questionnaire Filler defines a QuestionnaireResponse and appropriate additional resources aimed at transmitting the information provided by the Questionnaire filler in a standardized structured form. Upon completion of the questionnaire, the Questionnaire Filler shall create a bundle with all resources mentioned above.

Questionnaires may be accompanied by additional material which can be attached or sent by 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).

Generic elements of a questionnaire

A questionnaire shall have a set of generice elements (e.g. author, data entry person, receiver etc. [Table 7] lists the generic given elements

Name Role taker HL7 V3
Human Organization
Author X X Author PractitionerRole The person/organization responsible for the form content.
Data Entry Person X X DataEnterer PractitionerRole The person/organization who has typed/filled in the form content.
Urgent Notification Contact for this document X X PrimaryInformationRecipient PractitionerRole 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 doucment is received.)
Urgent Notification Contact for the Response to this document X X PrimaryInformationRecipient PractitionerRole

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 PractitionerRole Person/organization who receives the document.
Copy Receiver X X Patient/Organization Person/organization who receives the copy of this document.
Patient X Patient The principle target of a particular form content is one patient (for obstetrical and neonatal use cases see...).
Precedent Document Identifier na na This element provides a link to the preceding document (Bundle.identifier) in a thread (e.g. from a response to the request).
Date na na Date, the document was created.
Priority na na Order priority.

[Table 7] Generic elements in Questionnaires compliant to the ORF Implementation Guide

Healthcare domain specific elements of a questionnaire

ServiceRequest resource
NameFlagsCard.TypeDescription & Constraintsdoco
.. ServiceRequest 0..*ServiceRequestCH ORF ServiceRequest
... extension 0..*ExtensionExtension
Slice: Unordered, Open by value:url
... ch-orf-locationandtime S0..*Reference(CH ORF Appointment)CH ORF Location and Time
... ch-orf-requestedencounterdetails S0..1Reference(CH ORF Requested Encounter)CH ORF Requested Encounter Details
.... identifier:placerOrderIdentifier S1..1IdentifierPlacer Order Identifier
Required Pattern: At least the following
..... type1..1CodeableConceptDescription of identifier
Fixed Value: (complex)
...... coding1..*CodingCode defined by a terminology system
Fixed Value: (complex)
....... system1..1uriIdentity of the terminology system
Fixed Value:
....... code1..1codeSymbol in syntax defined by the system
Fixed Value: PLAC
..... system S0..1uriThe namespace for the identifier value
..... value S1..1stringThe value that is unique
.... identifier:fillerOrderIdentifier S0..1IdentifierFiller Order Identifier
Required Pattern: At least the following
..... type1..1CodeableConceptDescription of identifier
Fixed Value: (complex)
...... coding1..*CodingCode defined by a terminology system
Fixed Value: (complex)
....... system1..1uriIdentity of the terminology system
Fixed Value:
....... code1..1codeSymbol in syntax defined by the system
Fixed Value: FILL
..... system S0..1uriThe namespace for the identifier value
..... value S1..1stringThe value that is unique
... status S1..1codedraft | active | on-hold | revoked | completed | entered-in-error | unknown
... intent S1..1codeproposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option
... priority S0..1codeOrder priority
... subject S1..1Reference(CH Core Patient Profile)Patient
... requester S0..1Reference(CH Core Practitioner Role Profile)The person/organization responsible for the form content
... insurance S0..*Reference(CH ORF Coverage)Associated insurance coverage
... note S0..*AnnotationComments
.... text S1..1markdownThe annotation - text content (as markdown)
... patientInstruction 0..1stringUse Appointment.patientInstruction (referenced via ServiceRequest.extension) for patient-oriented instructions

doco Documentation for this format
DocumentReference resource

There may be the need to provide a linkage between particular files or between a particular file 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 DocumentReference as follows:

NameFlagsCard.TypeDescription & Constraintsdoco
.. DocumentReference 0..*CHCoreDocumentReferenceCH ORF DocumentReference
... status S1..1codecurrent | superseded | entered-in-error
... type S0..1CodeableConceptPrecise type of clinical document
... category S0..*CodeableConceptHigh-level kind of a clinical document at a macro level
... author S0..*Reference(CH Core Practitioner Role Profile)Who and/or what authored the document
... content S1..*BackboneElementDocument referenced
.... attachment S1..1AttachmentWhere to access the document
..... contentType S0..1codeMime type of the content, with charset etc.
..... data S0..1base64BinaryData inline, base64ed
... context S0..1BackboneElementClinical context of document
.... related S0..*Reference(Resource)Related identifiers or resources

doco Documentation for this format

FHIR Representation

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.

The Order & Referral by Form Implementation Guide is based on two FHIR Resources profiles. For details on profiling FHIR see HL7 FHIR For details on FHIR resources and data-types see HL7 FHIR

  1. The Order & Referral by Form Questionnaire (ORF) Implementation Guide defines the usage of the FHIR Questionnaire Resource within the Order & Referral by Form. The 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 the allowed answers. The results of a Questionnaire can be communicated using the QuestionnaireResponse resource (see
  2. The Order & Referral by Form Document (ORF) Profile defines the usage of the FHIR Bundle within the Order & Referral by Form (ORF) Implementation Guide. The ORFDocumentProfile consist of a FHIR document (bundle) that contains the results of a filled in Questionnaire (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 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 the bundle. Including these additional resources will make the document bigger, but will save applications from needing to retrieve the linked resources.
FHIR Resources Constraints

This section lists FHIR resources where this profile provides additional information. Resources not listed here follow the specifications of FHIR. For details refer to

Composition resource
NameFlagsCard.TypeDescription & Constraintsdoco
.. Composition 0..*CHCoreCompositionCH ORF Composition
... text S1..1NarrativeNarrative text of the composition
... extension 0..*ExtensionExtension
Slice: Unordered, Open by value:url
... ch-orf-precedentdocument S0..1IdentifierIdentifier of the document which precedes this document in a thread
... ch-orf-urgentnoficationcontactforthisdocument S0..1Reference(CH Core Practitioner Role Profile)An information recipient to notify for urgent matters
... ch-orf-urgentnoficationcontactfortheresponsetothisdocument S0..1Reference(CH Core Practitioner Role Profile)An information recipient to notify for urgent matters about the response
... ch-orf-receiver S0..1Reference(CH Core Practitioner Role Profile)Person/organization who receives the document
... ch-orf-copyreceiver S0..*Reference(CH Core Organization Profile | CH Core Patient Profile)Person/organization who receives the copy of this document
... status S1..1codepreliminary | final | amended | entered-in-error
... type S1..1CodeableConceptPrecise type of clinical document
Binding: DocumentEntry.typeCode (preferred)
... category S1..1CodeableConceptHigh-level kind of a clinical document at a macro level
Binding: DocumentEntry.classCode (preferred)
... subject S0..1Reference(CH Core Patient Profile)Patient as the principle target of a particular form content
... author S1..1Reference(CH Core Practitioner Role Profile)The person/organization responsible for the form content
... title S1..1stringMeaningful title
... section S1..*(Slice Definition)Composition is broken into sections
Slice: Unordered, Open by pattern:code
.... section:orderReferral S1..1BackboneElementContains the data that supports the order and referral by form.
..... title S1..1stringOrder-Referral
..... code S1..1CodeableConceptClassification of section (recommended)
Required Pattern: At least the following
...... coding1..*CodingCode defined by a terminology system
Fixed Value: (complex)
....... system1..1uriIdentity of the terminology system
Fixed Value:
....... code1..1codeSymbol in syntax defined by the system
Fixed Value: 93037-0
....... display1..1stringRepresentation defined by the system
Fixed Value: Portable medical order form
..... text S0..1NarrativeText summary of the section, for human interpretation
..... entry S3..*(Slice Definition)A reference to data that supports this section
Slice: Unordered, Open by profile:resolve()
...... entry:Questionnaire S1..1Reference(CH ORF Questionnaire)Questionnaire
....... reference S1..1stringLiteral reference, Relative, internal or absolute URL
...... entry:QuestionnaireResponse S1..1Reference(CH ORF QuestionnaireResponse)QuestionnaireResponse
....... reference S1..1stringLiteral reference, Relative, internal or absolute URL
...... entry:ServiceRequest S1..*Reference(CH ORF ServiceRequest)ServiceRequest
....... reference S1..1stringLiteral reference, Relative, internal or absolute URL
...... entry:DocumentReference S0..*Reference(CH ORF DocumentReference)DocumentReference
....... reference S1..1stringLiteral reference, Relative, internal or absolute URL
..... section 0..0
.... section:originalRepresentation S0..1BackboneElementContains the original representation as a PDF of the current document.
..... title S1..1stringOriginal representation
..... code S1..1CodeableConceptClassification of section (recommended)
Required Pattern: At least the following
...... coding1..*CodingCode defined by a terminology system
Fixed Value: (complex)
....... system1..1uriIdentity of the terminology system
Fixed Value:
....... code1..1codeSymbol in syntax defined by the system
Fixed Value: 55108-5
....... display1..1stringRepresentation defined by the system
Fixed Value: Clinical presentation
..... text S1..1NarrativeRepresentation of the original view
..... entry S1..1Reference(Binary)According to the EPR ordonnance the PDF has to be in PDF/A-1 or PDF/A-2 format.
..... section 0..0

doco Documentation for this format
Questionnaire resource

The intention of the ORF Implementation Guide 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 CSS) and user interaction as well (e.g. with drop down lists).

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

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

NameFlagsCard.TypeDescription & Constraintsdoco
.. Questionnaire 0..*QuestionnaireExtractCH ORF Questionnaire
... extension 3..*ExtensionExtension
... extension:targetStructureMap S1..1TargetStructureMapExtensionMap to artifacts that can be populated from this Questionnaire
... sdc-questionnaire-sourceStructureMap S1..1canonical(StructureMap)Map that can populate this questionnaire
... item S1..*BackboneElementQuestions and sections within the Questionnaire

doco Documentation for this format
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

NameFlagsCard.TypeDescription & Constraintsdoco
.. QuestionnaireResponse 0..*QuestionnaireResponseCH ORF QuestionnaireResponse
... identifier S0..1IdentifierUnique id for this set of answers
... basedOn S0..*Reference(CH ORF ServiceRequest)Request fulfilled by this QuestionnaireResponse
... partOf S0..*Reference(Observation | Procedure)Part of this action
... status S1..1codein-progress | completed | amended | entered-in-error | stopped
... subject S0..1Reference(CH Core Patient Profile)The subject of the questions
... encounter S0..1Reference(CH Core Encounter Profile)Encounter created as part of
... authored S0..1dateTimeDate the answers were gathered
... author S0..1Reference(Device | CH Core Practitioner Profile | CH Core Practitioner Role Profile | CH Core Patient Profile | RelatedPerson | CH Core Organization Profile)Person who received and recorded the answers
... source S0..1Reference(CH Core Patient Profile | CH Core Practitioner Profile | CH Core Practitioner Role Profile | RelatedPerson)The person who answered the questions
... item S0..*BackboneElementGroups and questions
.... linkId S1..1stringPointer to specific item from Questionnaire
.... definition S0..1uriElementDefinition - details for the item
.... text S0..1stringName for group or question text
.... answer S0..*BackboneElementThe response(s) to the question
..... value[x] S0..1boolean, decimal, integer, date, dateTime, time, string, uri, Attachment, Coding, Quantity, Reference(Resource)Single-valued answer to the question
..... item S0..*Nested groups and questions
.... item S0..*Nested questionnaire response items

doco Documentation for this format