Unattributed Code Systems

Copyright Fragment

This fragment is available on index.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

Type Reference Content
web registry.example.org actor : http://registry.example.org/fhir/HealthcareService/HealthcareServiceOrthopedicsFulfiller
web registry.example.org managingOrganization : http://registry.example.org/fhir/Organization/Fulfiller
web fulfiller.example.org address : https://fulfiller.example.org/fhir
web registry.example.org managingOrganization : http://registry.example.org/fhir/Organization/Placer
web placer.example.org address : https://placer.example.org/fhir
web registry.example.org providedBy : http://registry.example.org/fhir/Organization/Fulfiller
web registry.example.org endpoint : http://registry.example.org/fhir/Endpoint/EndpointFulfiller
web registry.example.org endpoint : http://registry.example.org/fhir/Endpoint/EndpointPlacer
web tel:+41333333333 +41 33 333 33 33
web registry.example.org organization : http://registry.example.org/fhir/Organization/Placer
web snomed.info SNOMED CT: 8517006 (Ex-smoker)
web placer.example.org basedOn : http://placer.example.org/fhir/ServiceRequest/ReferralOrthopedicSurgery
web placer.example.org focus : http://placer.example.org/fhir/ServiceRequest/ReferralOrthopedicSurgery
web placer.example.org for : http://placer.example.org/fhir/Patient/PetraMeier
web registry.example.org requester : http://registry.example.org/fhir/Organization/Placer
web registry.example.org owner : http://registry.example.org/fhir/Organization/Fulfiller
web registry.example.org owner : http://registry.example.org/fhir/Organization/Placer
web snomed.info 108252007
web snomed.info 308461008
web snomed.info 183545006
web snomed.info 720006006
web umzh.uzh.ch
img umzh.uzh.ch
web github.com CH UMZH Connect IG (R4), published by UMZH. This guide is not an authorized publication; it is the continuous build for version 1.0.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/umzhconnect/umzhconnect-ig/ and changes regularly. See the Directory of published versions
web umzh.uzh.ch IG © 2024+ UMZH . Package ch.fhir.ig.ch-umzh-connect#1.0.0-cibuild based on FHIR 4.0.1 . Generated 2026-06-05
Links: Table of Contents | QA Report
web snomed.info    108252007
web snomed.info    308461008
web snomed.info    183545006
web snomed.info    720006006
web github.com #69 : Relax the ServiceRequest supportingInfo[medicationstatement] slice from CH EMED to CH Core MedicationStatement (CH EMED mandates a contained Medication; CH Core also allows a non-contained one). Also adjust the orthopedic discharge-medication example to reference a standalone (non-contained) Medication resource as a demonstration
web github.com #71 : Relax ServiceRequest.reasonReference cardinality from 1..1 to 0..1
web github.com #52 : Add a completed Task example for the orthopedic referral with results in Task.output — an intermediary pre-surgery consultation Appointment plus a discharge report (DocumentReference) and discharge medication
web github.com #42 : Align Task.status and Task.businessStatus with COW — drop local ChUmzhConnectTaskBusinessStatus value set, bind Task.businessStatus to the COW business-status value set, switch the initial Task.status from ready to requested , add a Workflow States page, and require that Placer PATCHes are only valid when Task.owner is the Placer
web github.com #45 : JWT structure — carry caller-organization identity as extensions.umzhconnect.organization_reference (IHE IUA extensions container) and document the client-assertion JWT claims
web github.com #45 : JWT structure — carry caller-organization identity as extensions.umzhconnect.organization_reference (IHE IUA extensions container), document the client-assertion JWT claims, and focus the Security page on private_key_jwt (staged client-authentication levels moved to Implementation Notes)
web github.com #50 : Show changelog note on the IG home page
web github.com #46 : Task.code — remove clinical service category binding; align examples with COW Task.code using fulfill from the standard TaskCode CodeSystem
web github.com #37 : Task updates via JSON Patch (PATCH method added to CapabilityStatement)
web github.com #40 : mCSD-based registry — profile Task to require requestor/owner as absolute URL, add Registry section to core concepts
web github.com #35 : Link to organization as an absolute url to the registry (e.g. mCSD directory)
web github.com #31 : Rename hospitalp to placer and hospitalf to fulfiller, add host descriptions to example resources
web github.com #10 : Add ValueSet for ServiceRequest.category
web profiles.ihe.net All participating organizations — both Placers and Fulfillers — are registered in a shared UMZH-Connect Registry , inspired by IHE mCSD (Mobile Care Services Discovery) . The registry serves as a directory for discovering participating organizations, the services they offer, and their FHIR API endpoints.
web github.com The UMZH Connect Sandbox is a runnable reference implementation of this IG, and the architecture it follows is intended as a starting point for building a conforming system. It simulates two independent healthcare organizations — a Placer and a Fulfiller — exchanging referral data through FHIR R4 APIs secured with OAuth 2.0 / SMART on FHIR.
web github.com The sandbox runs via Docker Compose with no external dependencies; see the README for setup. Configuration is tuned for local development and demonstration purposes; it is not intended for production deployment as-is, but may serve as a starting point for custom implementations.
web fhir.ch Initial Use Cases focus on the following resource types which are based on the profiles from CH Core and CH eTOC :
web fhir.ch Initial Use Cases focus on the following resource types which are based on the profiles from CH Core and CH eTOC :
web creativecommons.org This document is licensed under Creative Commons "No Rights Reserved" ( CC0 ).
web www.iso.org ISO maintains the copyright on the country codes, and controls its use carefully. For further details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
Show Usage
web www.ihe.net Some content from IHE® Copyright © 2015 IHE International, Inc. This content is from the IHE Technical Frameworks and Supplements, available for free download and use at http://www.ihe.net/Technical_Frameworks/
Show Usage
web ucum.org The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
Show Usage
img icons.duckduckgo.com
img icons.duckduckgo.com
img icons.duckduckgo.com
img icons.duckduckgo.com
img icons.duckduckgo.com
web developers.google.com In general it should be mentioned that fine-grained authorization may be a very complex task to perform on the standard FHIR API due to a variety of factors, such as a broad range of search parameters covered by standard FHIR APIs. This is quite well covered in the Google FHIR Info Gateway project. Our general approach is to whitelist only the necessary endpoints and parameters required to enable our use case. The complexity of the authorization enforcement is therefore essentially reduced.
web openid.net mTLS and other additional security enhancements are included in the definition of OpenID FAPI 2.0 in order to mitigate these risks by adding standardized measures defined by RFCs (RFC 5280, RFC 8705, RFC 6749, RFC 7519). In essence it defines how to
web www.rfc-editor.org This section positions the UMZH-Connect security concept against three reference profiles that target overlapping problem spaces. The single architectural choice that distinguishes UMZH-Connect from all three is context-bound tokens : every access token is issued for one specific workflow object (a ServiceRequest or Task ) carried in the JWT as a fhirContext claim, derived from an RFC 9396 authorization_details request. None of the reference profiles standardize this per-request binding.
web www.fhir.ch CH EPR FHIR — Get Access Token [ITI-71] , the Swiss national profile of the IHE IUA Get Access Token transaction.
web profiles.ihe.net CH EPR FHIR — Get Access Token [ITI-71] , the Swiss national profile of the IHE IUA Get Access Token transaction.
web www.fhir.ch CH EPR ITI-71 (IUA)
web www.rfc-editor.org RFC 9396 + fhirContext JWT claim
web profiles.ihe.net extensions.umzhconnect.organization_reference (registry URL) — follows IHE IUA extensions container pattern
web openid.net FAPI 2.0 (high-assurance option)
web www.rfc-editor.org The client communicates the workflow context to the Authorization Server using the authorization_details parameter defined in RFC 9396 (Rich Authorization Requests) . This is the standard OAuth extension point for structured, instance-specific authorization requests — purpose-built for cases where resource-type scopes alone are insufficient.
web openid.net Note: authorization_details is the same extension point used by OpenID for Verifiable Credential Issuance (OID4VCI) to carry credential requests ( type: "openid_credential" ). UMZH-Connect follows the identical pattern with a custom type ( "umzh-connect-context" ), making the approach consistent with emerging identity standards and leveraging the same AS infrastructure — for example Keycloak's RAR support — that OID4VCI relies on.
web profiles.ihe.net The issued token also carries an organization identity claim inside the extensions object, following the IHE IUA -defined container for custom JWT claims — the same approach CH EPR ITI-71 uses in its issued access token. UMZH-Connect uses umzhconnect as its extension key:
web www.fhir.ch The issued token also carries an organization identity claim inside the extensions object, following the IHE IUA -defined container for custom JWT claims — the same approach CH EPR ITI-71 uses in its issued access token. UMZH-Connect uses umzhconnect as its extension key:

Internal Images

tree-filter.png
tree-filter.png