CH ORF (R4)
3.0.0-ballot - ballot
CH ORF (R4)
3.0.0-ballot - ballot
This page is part of the CH ORF (R4) (v3.0.0-ballot: STU 3 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
| Official URL: http://fhir.ch/ig/ch-orf/ImplementationGuide/ch.fhir.ig.ch-orf | Version: 3.0.0-ballot | |||
| Active as of 2024-05-17 | Computable Name: CH_ORF | |||
Copyright/Legal: CC0-1.0 |
||||
The CH Order & Referral by Form (CH ORF) implementation guide and its derivatives describe 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.
Whereas CH ORF is the “mother”-implementation guide defining attributes and value sets necessary in all sorts of order and referrals (such as patient name, order placer and order filler, insurance data etc.), derivatives cover specific use cases thus defining dedicated attributes and value sets needed there. Currently under development are CH eTOC for electronic transition of care, CH RAD Order for imaging services and CH LAB Order for laboratory orders.
All support creation and domain wide deployment of forms for structured and coded information exchange. Because the implementation guide relies heavily on the FHIR resources Questionnaire and QuestionnaireResponse, forms are addressed here as Questionnaires.
All IG derived from CH Orf use FHIR defined resources – Composition, Questionnaire, QuestionnaireResponse, Patient, PractitionerRole, Practitioner, Organization, ServiceRequest and Bundle from FHIR R4. For details on HL7 FHIR R4 see http://hl7.org/fhir/r4.
CH ORF and its derivatives are derived from the implementation guides HL7 Structured Data Capture - STU 3 and CH Core.
This implementation guide is under STU ballot by HL7 Switzerland until September 30th, 2024 midnight.
Please add your feedback via the ‘Propose a change’-link in the footer on the page where you have comments.
Download: You can download this implementation guide in NPM format from here.
In this implementation guide “MustSupport” (MS) denotes elements of the questionnaire that are mapped to corresponding resource items.
The CH ORF implementation guide addresses three issues:
When writing the CH 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. Workflow is therefore not a particular issue because directional information exchange is based on a request and response mechanism.
There may be good reasons to implement user interfaces by other technical means than questionnaires. Therefore CH ORF sets the cardinality for the questionnaire / questionnaireResponse to 0.. thus allowing authors of derivatives to decide if applications following their IG must implement a questionnaire / questionnaireResponse or not. In any case, the questionnaire will give guidance for sequence and grouping of items in the user interface.
A major challenge 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. CH ORF addresses this problem by defining the mandatory set of generic elements and codes with defined being part of every CH ORF derived IG. Derivatives will then only define additional case specific elements.
Vendors implementing the CH ORF implementation guide (or one of its derivatives) therefore benefit of a high re-use potential.
There has been a discussion whether population of the resources such as Patient, ServiceRequest etc. with the content of the QuestionnaireResponse should be done by the order placer application or rather by the order filler application. The argument for assigning the task to the order placer is a result of not making the implementation of a questionnaire / questionnaireResponse mandatory: For the sake of keeping all CH ORF derived exchange formats equal (as far as sensible), the authors decided to mandate the order placer application with the task.
Applications claiming for conformance with an CH ORF derived implementation guide shall:
Vendors of applications with Questionnaire Filler/Questionnaire Receiver actors are strongly recommended to implement interfaces to other applications (such as HIS and PACS) at least for all data in the generics elements of questionnaires.
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 CH ORF implementation guide or its derivatives unless the authors of a derivate insist on it. 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
This implementation guide depends on the implementation guide Structured Data Capture:
Questionnaires and forms are found everywhere in 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 does not 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.
These sections define the different use cases supported by SDC, specify the profile(s) needed to meet the use cases.
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.
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] ORF actors
[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.
| Actor | Transaction | Optionality | Reference |
|---|---|---|---|
| Questionnaire Filler | Submit Bundle [CH ORF-1] | O | Volume 2 – Transactions |
| Questionnaire Receiver | Submit Bundle [CH ORF-1] | O | Volume 2 – Transactions |
[Table 2] ORF actors and transactions
[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 the group actors from this implementation guide 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 CH Core profiles.
| Actor | Content Module | Optionality | Reference |
|---|---|---|---|
| Questionnaire Filler | ORF Content Module [Note 1] | R | Volume 3 – Content Modules |
| Questionnaire Receiver | ORF Content Module [Note 1] | R [Note 1] | Volume 3 – Content Modules |
[Table 3] ORF actors and content modules
[Note 1] The content of the form depends on the form which itself is defined by the FHIR Questionnaire. The Questionnaire defines elements and structure of the form. Codes for coded attributes are provided with corresponding value sets (for details see Content Modules (Volume 3)).
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.
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
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.
The Security Considerations section describes some optional groupings that may be of interest for security considerations.
| ORF Actor | Actor to be grouped with | Reference | Content Bindings Reference |
|---|---|---|---|
| Questionnaire Filler | Questionnaire Receiver | CH ORF Actors/Transactions | Volume 3 – Content Modules |
| Questionnaire Receiver | Questionnaire Filler | CH ORF Actors/Transactions | Volume 3 – Content Modules |
| Questionnaire Filler | CT Time Client | ITI TF-1: 7.1 CT Actors/Transactions | na |
| Questionnaire Receiver | CT Time Client | ITI TF-1: 7.1 CT Actors/Transactions | na |
[Table 5] ORF required actor groupings
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.
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.
This section corresponds to transaction [CH ORF-1]. This transaction 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 system extracts data from Questionnaire Response and sending a Bundle including the extracted information according to Volume 3 and QuestionnaireResponse to the Questionnaire Receiver.
This transaction is used to submit a filled in Questionnaire together with required additional resources and attachment in a Bundle from a Questionnaire Filler to a Questionnaire Receiver.
[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 QuestionnaireResponse. 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] ORF actors and roles
[Figure 4] Interaction diagram
The transaction uses the HTTP POST method on the target Questionnaire Receiver endpoint to convey the Bundle with the questionnaire as a FHIR transaction.
Trigger Events
After the questionnaire is completed by the Questionnaire Filler user, the Questionnaire Filler submits 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 http://hl7.org/fhir/http.html#transaction for complete requirements of a transaction. See http://hl7.org/fhir/bundle-transaction.html for example of a transaction Bundle.
Submit Bundle is sent to the base URI as defined in FHIR. See http://hl7.org/fhir/r4/http.html for the definition of “http” access methods and “base”.
For complete information on constructing a FHIR Bundle resource, see http://hl7.org/fhir/r4/bundle.html.
The FHIR Bundle.meta.profile shall include the value http://fhir.ch/ig/ch-orf/StructureDefinition/ch-orf-document.
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 Message Semantics of section Status Message.
The Questionnaire Receiver returns a HTTP Status code appropriate to the processing, conforming to the transaction specification requirements as specified in http://hl7.org/fhir/r4/http.html#transaction.
Trigger Events
This message shall be sent once the Bundle with the questionnaire 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 http://hl7.org/fhir/r4/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 IHE Appendix on HL7 FHIR Z.7.
On failure, the Questionnaire Receiver shall return the HTTP status codes as follows:
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 a 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.
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.
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.) and 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).
A Questionnaire shall have a set of generic elements (e.g. author, data entry person, receiver etc.).
| Name | Comment |
|---|---|
| Date | Date when the request transitioned to being actionable (e.g sent to the receiver). |
| Placer Order Identifier | Placer Order Identifier |
| Placer Order Identifier Domain | Placer Order Identifier Domain |
| Filler Order Identifier | Filler Order Identifier |
| Filler Order Identifier Domain | Filler Order Identifier Domain |
| Precedent Document Identifier | Precedent Document Identifier |
| Urgent Notification Contact for this document | 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 document is received.) |
| Urgent Notification Contact for the Response to this document |
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. |
| Priority | Order priority. |
| Receiver | Person/organization who receives the document. |
| Initiator | Person or organization who initiated the service request; particularly in the context of spitex or admission to a nursing/retirement home (e.g the husband asks for spitex support because he needs help for the care of his wife). |
| Patient | The principle target of a particular form content is one patient. |
| Patient Contact Person | The principle target of a particular form content is one patient. |
| Familydoctor | Healthprofessional who takes the role of a familydoctor. |
| Requested Encounter | Requested Encounter such as ambulatory/inpatient/emergency. |
| Coverage | Payor covering the costs. |
| Sender/Author | The person/organization responsible for the form content. |
| Data Entry Person | The person/organization who has typed/filled in the form content. |
| Copy Receiver | Person/organization who receives the copy of this order (shall receive also all results therefrom). |
| Antecedent Episode of Care | Documentation of the episode of care preceding this order (e.g in case of care transfer between institutions such as hospitals, rehab. clinics, retirement homes etc.)" |
| Appointment | Indication of date/time and location of the requested appointment(s) |
| Patientconsent | Indication of whether the patient has given informed consent to this order; in particular for Spitex and transfer to nursing/retirement home, etc. |
| Note | General remarks |
[Table 7] Generic elements in questionnaires compliant to the ORF implementation guide
[Table 7] shows that the FHIR representation of elements representing a person and/or an organization is defined by the PractitionerRole resource. The Practitioner and/or the Organization resource can then be referenced from the PractitionerRole resource.
The CH ORF context specific requirements for this resource are shown in the profile CH ORF ServiceRequest.
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 resource.
The CH ORF context specific requirements for this resource are shown in the profile CH ORF DocumentReference.
FHIR depicts forms 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 http://www.hl7.org/fhir/profiling.html. For details on FHIR resources and data-types see HL7 FHIR http://hl7.org/fhir/.
document and has a Composition 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 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.This section lists FHIR resources for which these CH ORF profiles provide additional information. Resources not listed here follow the specifications of FHIR. For details refer to https://www.hl7.org/fhir/resourcelist.html.
The CH ORF context specific requirements for this resource are shown in the profile CH ORF Composition.
In the Composition, general information about the document is defined, such as title, type and category. In the CH ORF exchange format, no fixed values are determined for these elements, only a preferred binding to specific value sets is made. These values are context-dependent and have to be specified in the corresponding derived exchange format. They must be defined as fixedValues or limited value set in the Composition profile.
| Element | Description | DataType | ValueSet |
|---|---|---|---|
| Composition.title | Meaningful human-readable title of the document | string |
- |
| Composition.type | Precise type of the document | CodeableConcept |
DocumentEntry.typeCode |
| Composition.category | High-level kind of the document at a macro level | CodeableConcept |
DocumentEntry.classCode |
[Table 8] General information about the document defined in Composition
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:
Both is achieved by assigning meaningful concepts to all elements concerned. For codes refer to Appendix A.
The CH ORF context specific requirements for this resource are shown in the profile CH ORF Questionnaire.
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/r4/questionnaireresponse.html.
The CH ORF context specific requirements for this resource are shown in the profile CH ORF QuestionnaireResponse.
This Implementation Guide provides three examples of QuestionnaireResponse such as QuestionnaireResponse Medical Referral, QuestionnaireResponse Radiology Order and QuestionnaireResponse External Diagnostics Order. Only QuestionnaireResponse Medical Referral shows all items filled in.
This implementation guide defines data elements, resources, formats, and methods for exchanging healthcare data between different participants in the healthcare process. As such, clinical safety is a key concern. Additional guidance regarding safety for the specification’s many and various implementations is available at: https://www.hl7.org/FHIR/safety.html.
Although the present specification does gives users the opportunity to observe data protection and data security regulations, its use does not guarantee compliance with these regulations. Effective compliance must be ensured by appropriate measures during implementation projects and in daily operations. The corresponding implementation measures are explained in the standard. In addition, the present specification can only influence compliance with the security regulations in the technical area of standardization. It cannot influence organizational and contractual matters.
This document is licensed under Creative Commons “No Rights Reserved” (CC0).
HL7®, HEALTH LEVEL SEVEN®, FHIR® and the FHIR 
® are trademarks owned by Health Level Seven International, registered with the United States Patent and Trademark Office.
This implementation guide contains and references intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant any rights with respect to Third Party IP. The licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the specification or otherwise.
This publication includes IP covered under the following statements.
This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (ch.fhir.ig.ch-orf.r4) and R4B (ch.fhir.ig.ch-orf.r4b) are available.
| IG | Package | FHIR | Comment |
|---|---|---|---|
  CH ORF (R4) | ch.fhir.ig.ch-orf#3.0.0-ballot | R4 | |
 FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.1.0 | R4 | Automatically added as a dependency - all IGs depend on the HL7 Extension Pack |
| HL7 Terminology (THO) | hl7.terminology#5.5.0 | R4 | |
  FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#1.0.0 | R4 | |
| CH Core (R4) | ch.fhir.ig.ch-core#5.0.0-ballot | R4 | |
| CH Term (R4) | ch.fhir.ig.ch-term#3.0.0 | R4 | |
 IHE FormatCode Vocabulary | ihe.formatcode.fhir#1.2.0 | R4 | |
| HL7 Terminology (THO) | hl7.terminology.r4#5.3.0 | R4 | |
| Structured Data Capture | hl7.fhir.uv.sdc#3.0.0 | R4 | |
| FHIR R4 package : Examples | hl7.fhir.r4.examples#4.0.1 | R4 |
Package hl7.fhir.uv.extensions.r4#5.1.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00) |
Package hl7.fhir.uv.extensions.r4#1.0.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00) |
Package ihe.formatcode.fhir#1.2.0 Implementation Guide for IHE defined FormatCode vocabulary. (built Tue, Mar 12, 2024 16:59-0500-05:00) |
Package ch.fhir.ig.ch-term#3.0.0 Implementation Guide for Swiss Terminology (built Thu, May 16, 2024 10:33+0000+00:00) |
Package ch.fhir.ig.ch-core#5.0.0-ballot FHIR implementation guide CH Core (built Thu, May 16, 2024 16:08+0000+00:00) |
Package hl7.fhir.r4.examples#4.0.1 Example resources in the R4 version of the FHIR standard |
Package hl7.fhir.uv.sdc#3.0.0 The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR. |
There are no Global profiles defined