CHMED Implementation Guide
3.0.0-ci-build - ci-build
CHMED Implementation Guide, published by IG eMediplan. This is not an authorized publication; it is the continuous build for version 3.0.0-ci-build). This version is based on the current content of https://github.com/ahdis/chmed/ and changes regularly. See the Directory of published versions
Official URL: http://chmed.emediplan.ch/fhir/ImplementationGuide/ch.chmed.emediplan | Version: 3.0.0-ci-build | |||
Active as of 2023-10-17 | Computable Name: CHMED | |||
Copyright/Legal: CC0-1.0 |
Medication plans are a central pillar of any eHealth solution. To enable interoperability between eHealth systems in Switzerland, the organisation IG eMediplan was founded in 2016. Its aim is to support and provide public, open-source, medication plan formats used by a broad group of stakeholders from the public and private sectors.
Fig. 1: eMediplan example (see also Use Case 1)
The eMedication Plan ChMed23A describes the specification and reference implementation of the object model for a medication plan, the so-called ChMed23A.
The reference consists of the content and layout specification for the electronic document, a JSON file containing a medication.
The content and layout specification for a paper-based layout used in Print/PDF scenarios is described in the document ‘eMediplan_Paper-based_Layout’.
A ChMed23A can be transmitted using the so called ChTransmissionFormat, which specifies the type of the content and includes the compressed and Base64 encoded content.
ChFormat: {inputType}.{compressed-base64-payload}
Example: ChMed23A.
H4sIAAAAAAAACq2OOw4CMQxE7zIt2ZUTAmzcLZsGiU+KUCEKYKlokIACRbk7jkLBAWisZz/NyAmb6/gAHxJ
WI7hsGgqhnsIOnBDBRmF4+9cebCuBtUL0Xy38g73MnIu+DxX/1nRUkCRiv1zLl9tzOF1uIloqxj9FGTKmId1oHcn
xtGM7a+28c9YtJqSZCPkD+iD8fPQAAAA=
This allows IT systems to store and transmit electronic medication plans in the form of a JSON file in UTF-8. It also enables the medication plan to be transmitted in a print-based form by using QR barcodes. Therefore, the medication plan is readable by users and systems alike. This is necessary to guarantee simple handling.
The possibility to transmit and store the compressed and Base64 encoded chunked payload (mainly to not exceed the maximum character size supported by a QR code), will be considered in the future.
Here is an example which describes how to create chunks that fit on one line in this document:
Chunk 1: ChMed23A.1/4.H4sIAAAAAAAACq2OOw4CMQxE7zIt2ZUTAmzcLZsGiU+KUCEKYKlokIACRbk7jk
Chunk 2: ChMed23A.2/4.LBAWisZz/NyAmb6/gAHxJWI7hsGgqhnsIOnBDBRmF4+9cebCuBtUL0Xy38g73MnI
Chunk 3: ChMed23A.3/4.u+DxX/1nRUkCRiv1zLl9tzOF1uIloqxj9FGTKmId1oHcnxtGM7a+28c9YtJqSZCPkD+
Chunk 4: ChMed23A.4/4.iD8fPQAAAA=
The purpose of this implementation guide (IG) is to specify the medication exchange formats given by eMediplan based on the FHIR® (R4) standard from HL7®.
Extending the eMediplan format to a FHIR-based definition (CHMED) has the following advantages:
The CHMED format can be either in JSON or XML format. However, both formats are too large in size to be exchanged in a QR code as defined by eMediplan.
HCI Solutions AG has built a converter for all software houses that have integrated the eMediplan format. It transforms the eMediplan format to the CHMED format and back. If you have any questions or require further information, please contact hotline@hcisolutions.ch.
Fig. 2: Format overview
The meaning of the flag mustSupport for this implementation guide follows the definition of CH EMED, the Swiss eMedication IG from which CHMED is derived.
You can download this implementation guide in npm format from here.
Significant changes to this specification since its initial version.
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.chmed.emediplan.r4) and R4B (ch.chmed.emediplan.r4b) are available.
IG | Package | FHIR | Comment |
---|---|---|---|
ch.chmed.emediplan#3.0.0-ci-build | R4 | ||
hl7.terminology.r4#5.3.0 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology | |
hl7.fhir.uv.extensions.r4#1.0.0 | R4 | Automatically added as a dependency - all IGs depend on the HL7 Extension Pack | |
ch.fhir.ig.ch-emed#4.0.0-ballot | R4 | ||
ch.fhir.ig.ch-core#4.0.0-ballot | R4 | ||
ch.fhir.ig.ch-epr-term#2.0.9 | R4 | ||
ihe.formatcode.fhir#1.1.0 | R4 | ||
hl7.terminology#5.1.0 | R4 |
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.1.0 Implementation Guide for IHE defined FormatCode vocabulary. (built Thu, Feb 24, 2022 16:55-0600-06:00) |
Package ch.fhir.ig.ch-epr-term#2.0.9 Implementation guide for the meta data specified in the framework of Annex 3 and 9 of the FDHA Ordinance on the electronic patient record in Switzerland (built Tue, Jun 27, 2023 18:05+0200+02:00) |
Package ch.fhir.ig.ch-core#4.0.0-ballot FHIR implementation guide CH Core (built Tue, Jun 27, 2023 23:13+0200+02:00) |
Package ch.fhir.ig.ch-emed#4.0.0-ballot Implementation Guide for the eMedication in Switzerland. (built Thu, Jun 29, 2023 14:57+0200+02:00) |
There are no Global profiles defined