From 27a5a78156717482ced6e0e0f9bff1e81a35961d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Sun, 10 May 2026 22:54:22 +0300 Subject: [PATCH 1/8] proof-reading --- ig-src/input/pagecontent/background.md | 16 ++++++++-------- ig-src/input/pagecontent/logicalmodels.md | 4 ++-- ig-src/input/pagecontent/usecases.md | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/ig-src/input/pagecontent/background.md b/ig-src/input/pagecontent/background.md index 4db890aa8..4213fc09d 100644 --- a/ig-src/input/pagecontent/background.md +++ b/ig-src/input/pagecontent/background.md @@ -1,25 +1,25 @@ ### Crossborder initiative: from epSOS to MyHealth@EU -The history of European collaboration in the health space is long, and even precedes the epSOS project (2008-2014). The epSOS project worked on the development, piloting and evaluation of the first cross-border eHealth services. +The history of European collaboration in the health space is long and even predates the epSOS project (2008-2014). The epSOS project worked on the development, piloting and evaluation of the first cross-border eHealth services. This long journey resulted in the first operational cross-border services for Patient Summary and ePrescription based on the HL7 CDA R2.0 standard in 2019 (see [here](https://art-decor.ehdsi.eu/art-decor/decor-templates--epsos-) for the current MyHealth@EU CDA-based specifications). The service was initially activated in a few countries and progressively extended on a voluntary basis. These services are maintained by [MyHealth@EU](https://health.ec.europa.eu/ehealth-digital-health-and-care/electronic-cross-border-health-services_en), formerly known as eHDSI (CEF). -While the crossborder ePrescription and eDispensation services continue to operate using HL7 CDA for the near future, the new services in MyHealth@EU are already using HL7 FHIR, and the old services will adopt HL7 FHIR in the future. +While the crossborder ePrescription and eDispensation services continue to operate using HL7 CDA for the near future, the new services in MyHealth@EU already use HL7 FHIR, and the existing services will adopt HL7 FHIR in the future. ### eHealth Network guidelines -The first version of eHealth Network Guidelines on ePrescription and eDispensation of Authorised Medicinal Products was published in 2014. The third release of this guideline was published in June 2022, and it is the main basis for the current business requirements. +The first version of the eHealth Network Guideline on ePrescription and eDispensation of Authorised Medicinal Products was published in 2014. The third release of this guideline was published in June 2022. -The data sets in eHealth Network guidelines do not include information about cardinality or data types. The data sets have been revised and enhanced by [Xt-EHR project](https://www.xt-ehr.eu/) - the mappings to these logical models are provided in the [Logical Models page](logicalmodels.html). Deviations from eHN guidelines are explained in Xt-EHR project IG and deliverables. +The data sets in eHealth Network guidelines do not include information on cardinality or data types. The data sets have been revised and enhanced by the [Xt-EHR project](https://www.xt-ehr.eu/), and the mappings to these logical models are provided in the [Logical Models page](logicalmodels.html). Deviations from the eHN guidelines are explained in Xt-EHR project deliverables. ### European Health Data Space -The EHDS regulation lists ePrescription and eDispensation as priority categories of personal electronic health data. +The EHDS regulation lists ePrescription and eDispensation as priority categories of personal electronic health data (Article 14). -According to the regulation, technical specifications for data exchange (EEHRxF a.k.a "the format") shall be created, taking into consideration that the exchange format may have different profiles for its use at the level of EHR systems and at the level of the national contact points for crossborder data exchange. +According to the regulation, technical specifications for data exchange (EEHRxF or the Format) shall be created, taking into consideration that the exchange format may have different profiles for use at the level of EHR systems and at the level of the national contact points for crossborder data exchange (see Recital 26). -This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. Also, more restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. +This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. More restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. -While the owner of the EHDS specifications will be European Commission, the current IG is resulting from cooperation between different EU projects that are working on preparing EHDS specifications and implementation. \ No newline at end of file +While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. \ No newline at end of file diff --git a/ig-src/input/pagecontent/logicalmodels.md b/ig-src/input/pagecontent/logicalmodels.md index 51f3d4963..c2381c7fb 100644 --- a/ig-src/input/pagecontent/logicalmodels.md +++ b/ig-src/input/pagecontent/logicalmodels.md @@ -1,6 +1,6 @@ ### Logical information models -Logical data models or information models for EHDS are created by Xt-EHR project. These models are refined and enhanced versions of the [eHN Guidelines data sets](https://health.ec.europa.eu/system/files/2022-06/ehealth_health-data_electronic-exchange_eprescriptions-guidelines_en.pdf) published in 2022. +Logical data models or information models for EHDS are created by Xt-EHR project. These models are refined and enhanced versions of the [eHN Guidelines data sets](https://health.ec.europa.eu/system/files/2022-06/ehealth_health-data_electronic-exchange_eprescriptions-guidelines_en.pdf) published in 2022. Future refinements are expected in the EHDS implementing acts. This IG aims to conform to EHDS logical models, and provide the FHIR profiles based on these models. @@ -8,7 +8,7 @@ EHDS draft logical models for eP and eD use case can be seen in [**Xt-EHR Implem - [Medication Prescription Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedicationPrescription.html) - [Medication Dispense Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedicationDispense.html) - [Medication Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedication.html) -- [Dosaging Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosaging.html) +- [Dosage Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosage.html) ### eHN Guideline Data Sets diff --git a/ig-src/input/pagecontent/usecases.md b/ig-src/input/pagecontent/usecases.md index 24e1d0eee..897708758 100644 --- a/ig-src/input/pagecontent/usecases.md +++ b/ig-src/input/pagecontent/usecases.md @@ -1,4 +1,4 @@ -The implementation guide explicitly covers the following use cases: +The implementation guide covers the following use cases: - Issuing a prescription for a medicinal product to a patient, - Cancelling or updating a prescription, - Dispensing a medicinal product to a patient or their proxy according to an existing prescription, From f6213ff2374683907a198e6ea0f8a735c40927cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Sun, 10 May 2026 22:55:31 +0300 Subject: [PATCH 2/8] proof-reading --- igs/mpd-r5/input/pagecontent/background.md | 16 ++++++++-------- igs/mpd-r5/input/pagecontent/logicalmodels.md | 4 ++-- igs/mpd-r5/input/pagecontent/usecases.md | 2 +- input/pagecontent/background.md | 16 ++++++++-------- input/pagecontent/logicalmodels.md | 4 ++-- input/pagecontent/usecases.md | 2 +- 6 files changed, 22 insertions(+), 22 deletions(-) diff --git a/igs/mpd-r5/input/pagecontent/background.md b/igs/mpd-r5/input/pagecontent/background.md index 4db890aa8..4213fc09d 100644 --- a/igs/mpd-r5/input/pagecontent/background.md +++ b/igs/mpd-r5/input/pagecontent/background.md @@ -1,25 +1,25 @@ ### Crossborder initiative: from epSOS to MyHealth@EU -The history of European collaboration in the health space is long, and even precedes the epSOS project (2008-2014). The epSOS project worked on the development, piloting and evaluation of the first cross-border eHealth services. +The history of European collaboration in the health space is long and even predates the epSOS project (2008-2014). The epSOS project worked on the development, piloting and evaluation of the first cross-border eHealth services. This long journey resulted in the first operational cross-border services for Patient Summary and ePrescription based on the HL7 CDA R2.0 standard in 2019 (see [here](https://art-decor.ehdsi.eu/art-decor/decor-templates--epsos-) for the current MyHealth@EU CDA-based specifications). The service was initially activated in a few countries and progressively extended on a voluntary basis. These services are maintained by [MyHealth@EU](https://health.ec.europa.eu/ehealth-digital-health-and-care/electronic-cross-border-health-services_en), formerly known as eHDSI (CEF). -While the crossborder ePrescription and eDispensation services continue to operate using HL7 CDA for the near future, the new services in MyHealth@EU are already using HL7 FHIR, and the old services will adopt HL7 FHIR in the future. +While the crossborder ePrescription and eDispensation services continue to operate using HL7 CDA for the near future, the new services in MyHealth@EU already use HL7 FHIR, and the existing services will adopt HL7 FHIR in the future. ### eHealth Network guidelines -The first version of eHealth Network Guidelines on ePrescription and eDispensation of Authorised Medicinal Products was published in 2014. The third release of this guideline was published in June 2022, and it is the main basis for the current business requirements. +The first version of the eHealth Network Guideline on ePrescription and eDispensation of Authorised Medicinal Products was published in 2014. The third release of this guideline was published in June 2022. -The data sets in eHealth Network guidelines do not include information about cardinality or data types. The data sets have been revised and enhanced by [Xt-EHR project](https://www.xt-ehr.eu/) - the mappings to these logical models are provided in the [Logical Models page](logicalmodels.html). Deviations from eHN guidelines are explained in Xt-EHR project IG and deliverables. +The data sets in eHealth Network guidelines do not include information on cardinality or data types. The data sets have been revised and enhanced by the [Xt-EHR project](https://www.xt-ehr.eu/), and the mappings to these logical models are provided in the [Logical Models page](logicalmodels.html). Deviations from the eHN guidelines are explained in Xt-EHR project deliverables. ### European Health Data Space -The EHDS regulation lists ePrescription and eDispensation as priority categories of personal electronic health data. +The EHDS regulation lists ePrescription and eDispensation as priority categories of personal electronic health data (Article 14). -According to the regulation, technical specifications for data exchange (EEHRxF a.k.a "the format") shall be created, taking into consideration that the exchange format may have different profiles for its use at the level of EHR systems and at the level of the national contact points for crossborder data exchange. +According to the regulation, technical specifications for data exchange (EEHRxF or the Format) shall be created, taking into consideration that the exchange format may have different profiles for use at the level of EHR systems and at the level of the national contact points for crossborder data exchange (see Recital 26). -This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. Also, more restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. +This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. More restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. -While the owner of the EHDS specifications will be European Commission, the current IG is resulting from cooperation between different EU projects that are working on preparing EHDS specifications and implementation. \ No newline at end of file +While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. \ No newline at end of file diff --git a/igs/mpd-r5/input/pagecontent/logicalmodels.md b/igs/mpd-r5/input/pagecontent/logicalmodels.md index 51f3d4963..c2381c7fb 100644 --- a/igs/mpd-r5/input/pagecontent/logicalmodels.md +++ b/igs/mpd-r5/input/pagecontent/logicalmodels.md @@ -1,6 +1,6 @@ ### Logical information models -Logical data models or information models for EHDS are created by Xt-EHR project. These models are refined and enhanced versions of the [eHN Guidelines data sets](https://health.ec.europa.eu/system/files/2022-06/ehealth_health-data_electronic-exchange_eprescriptions-guidelines_en.pdf) published in 2022. +Logical data models or information models for EHDS are created by Xt-EHR project. These models are refined and enhanced versions of the [eHN Guidelines data sets](https://health.ec.europa.eu/system/files/2022-06/ehealth_health-data_electronic-exchange_eprescriptions-guidelines_en.pdf) published in 2022. Future refinements are expected in the EHDS implementing acts. This IG aims to conform to EHDS logical models, and provide the FHIR profiles based on these models. @@ -8,7 +8,7 @@ EHDS draft logical models for eP and eD use case can be seen in [**Xt-EHR Implem - [Medication Prescription Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedicationPrescription.html) - [Medication Dispense Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedicationDispense.html) - [Medication Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedication.html) -- [Dosaging Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosaging.html) +- [Dosage Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosage.html) ### eHN Guideline Data Sets diff --git a/igs/mpd-r5/input/pagecontent/usecases.md b/igs/mpd-r5/input/pagecontent/usecases.md index 24e1d0eee..897708758 100644 --- a/igs/mpd-r5/input/pagecontent/usecases.md +++ b/igs/mpd-r5/input/pagecontent/usecases.md @@ -1,4 +1,4 @@ -The implementation guide explicitly covers the following use cases: +The implementation guide covers the following use cases: - Issuing a prescription for a medicinal product to a patient, - Cancelling or updating a prescription, - Dispensing a medicinal product to a patient or their proxy according to an existing prescription, diff --git a/input/pagecontent/background.md b/input/pagecontent/background.md index 4db890aa8..4213fc09d 100644 --- a/input/pagecontent/background.md +++ b/input/pagecontent/background.md @@ -1,25 +1,25 @@ ### Crossborder initiative: from epSOS to MyHealth@EU -The history of European collaboration in the health space is long, and even precedes the epSOS project (2008-2014). The epSOS project worked on the development, piloting and evaluation of the first cross-border eHealth services. +The history of European collaboration in the health space is long and even predates the epSOS project (2008-2014). The epSOS project worked on the development, piloting and evaluation of the first cross-border eHealth services. This long journey resulted in the first operational cross-border services for Patient Summary and ePrescription based on the HL7 CDA R2.0 standard in 2019 (see [here](https://art-decor.ehdsi.eu/art-decor/decor-templates--epsos-) for the current MyHealth@EU CDA-based specifications). The service was initially activated in a few countries and progressively extended on a voluntary basis. These services are maintained by [MyHealth@EU](https://health.ec.europa.eu/ehealth-digital-health-and-care/electronic-cross-border-health-services_en), formerly known as eHDSI (CEF). -While the crossborder ePrescription and eDispensation services continue to operate using HL7 CDA for the near future, the new services in MyHealth@EU are already using HL7 FHIR, and the old services will adopt HL7 FHIR in the future. +While the crossborder ePrescription and eDispensation services continue to operate using HL7 CDA for the near future, the new services in MyHealth@EU already use HL7 FHIR, and the existing services will adopt HL7 FHIR in the future. ### eHealth Network guidelines -The first version of eHealth Network Guidelines on ePrescription and eDispensation of Authorised Medicinal Products was published in 2014. The third release of this guideline was published in June 2022, and it is the main basis for the current business requirements. +The first version of the eHealth Network Guideline on ePrescription and eDispensation of Authorised Medicinal Products was published in 2014. The third release of this guideline was published in June 2022. -The data sets in eHealth Network guidelines do not include information about cardinality or data types. The data sets have been revised and enhanced by [Xt-EHR project](https://www.xt-ehr.eu/) - the mappings to these logical models are provided in the [Logical Models page](logicalmodels.html). Deviations from eHN guidelines are explained in Xt-EHR project IG and deliverables. +The data sets in eHealth Network guidelines do not include information on cardinality or data types. The data sets have been revised and enhanced by the [Xt-EHR project](https://www.xt-ehr.eu/), and the mappings to these logical models are provided in the [Logical Models page](logicalmodels.html). Deviations from the eHN guidelines are explained in Xt-EHR project deliverables. ### European Health Data Space -The EHDS regulation lists ePrescription and eDispensation as priority categories of personal electronic health data. +The EHDS regulation lists ePrescription and eDispensation as priority categories of personal electronic health data (Article 14). -According to the regulation, technical specifications for data exchange (EEHRxF a.k.a "the format") shall be created, taking into consideration that the exchange format may have different profiles for its use at the level of EHR systems and at the level of the national contact points for crossborder data exchange. +According to the regulation, technical specifications for data exchange (EEHRxF or the Format) shall be created, taking into consideration that the exchange format may have different profiles for use at the level of EHR systems and at the level of the national contact points for crossborder data exchange (see Recital 26). -This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. Also, more restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. +This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. More restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. -While the owner of the EHDS specifications will be European Commission, the current IG is resulting from cooperation between different EU projects that are working on preparing EHDS specifications and implementation. \ No newline at end of file +While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. \ No newline at end of file diff --git a/input/pagecontent/logicalmodels.md b/input/pagecontent/logicalmodels.md index 51f3d4963..c2381c7fb 100644 --- a/input/pagecontent/logicalmodels.md +++ b/input/pagecontent/logicalmodels.md @@ -1,6 +1,6 @@ ### Logical information models -Logical data models or information models for EHDS are created by Xt-EHR project. These models are refined and enhanced versions of the [eHN Guidelines data sets](https://health.ec.europa.eu/system/files/2022-06/ehealth_health-data_electronic-exchange_eprescriptions-guidelines_en.pdf) published in 2022. +Logical data models or information models for EHDS are created by Xt-EHR project. These models are refined and enhanced versions of the [eHN Guidelines data sets](https://health.ec.europa.eu/system/files/2022-06/ehealth_health-data_electronic-exchange_eprescriptions-guidelines_en.pdf) published in 2022. Future refinements are expected in the EHDS implementing acts. This IG aims to conform to EHDS logical models, and provide the FHIR profiles based on these models. @@ -8,7 +8,7 @@ EHDS draft logical models for eP and eD use case can be seen in [**Xt-EHR Implem - [Medication Prescription Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedicationPrescription.html) - [Medication Dispense Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedicationDispense.html) - [Medication Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedication.html) -- [Dosaging Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosaging.html) +- [Dosage Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosage.html) ### eHN Guideline Data Sets diff --git a/input/pagecontent/usecases.md b/input/pagecontent/usecases.md index 24e1d0eee..897708758 100644 --- a/input/pagecontent/usecases.md +++ b/input/pagecontent/usecases.md @@ -1,4 +1,4 @@ -The implementation guide explicitly covers the following use cases: +The implementation guide covers the following use cases: - Issuing a prescription for a medicinal product to a patient, - Cancelling or updating a prescription, - Dispensing a medicinal product to a patient or their proxy according to an existing prescription, From c48a12cce4bb500eca6cd6a3e0e1a1fb90478eb1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Sun, 10 May 2026 23:00:06 +0300 Subject: [PATCH 3/8] related to FHIR-52076 (remove eHN models) --- ig-src/input/pagecontent/logicalmodels.md | 2 -- igs/mpd-r5/input/pagecontent/logicalmodels.md | 2 -- input/pagecontent/logicalmodels.md | 2 -- 3 files changed, 6 deletions(-) diff --git a/ig-src/input/pagecontent/logicalmodels.md b/ig-src/input/pagecontent/logicalmodels.md index c2381c7fb..c9c305945 100644 --- a/ig-src/input/pagecontent/logicalmodels.md +++ b/ig-src/input/pagecontent/logicalmodels.md @@ -10,6 +10,4 @@ EHDS draft logical models for eP and eD use case can be seen in [**Xt-EHR Implem - [Medication Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedication.html) - [Dosage Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosage.html) -### eHN Guideline Data Sets -[The Artifacts page](artifacts.html) also provides eHN data sets as logical models. However, those data sets have not been originally published as machine-readable models and the derived logical models often lack of precision and concreteness. EHDS logical information models (see above) use eHN data sets as a conceptual base, and provide non-ambiguous machine-readable models. diff --git a/igs/mpd-r5/input/pagecontent/logicalmodels.md b/igs/mpd-r5/input/pagecontent/logicalmodels.md index c2381c7fb..c9c305945 100644 --- a/igs/mpd-r5/input/pagecontent/logicalmodels.md +++ b/igs/mpd-r5/input/pagecontent/logicalmodels.md @@ -10,6 +10,4 @@ EHDS draft logical models for eP and eD use case can be seen in [**Xt-EHR Implem - [Medication Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedication.html) - [Dosage Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosage.html) -### eHN Guideline Data Sets -[The Artifacts page](artifacts.html) also provides eHN data sets as logical models. However, those data sets have not been originally published as machine-readable models and the derived logical models often lack of precision and concreteness. EHDS logical information models (see above) use eHN data sets as a conceptual base, and provide non-ambiguous machine-readable models. diff --git a/input/pagecontent/logicalmodels.md b/input/pagecontent/logicalmodels.md index c2381c7fb..c9c305945 100644 --- a/input/pagecontent/logicalmodels.md +++ b/input/pagecontent/logicalmodels.md @@ -10,6 +10,4 @@ EHDS draft logical models for eP and eD use case can be seen in [**Xt-EHR Implem - [Medication Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSMedication.html) - [Dosage Model](https://www.xt-ehr.eu/fhir/models/StructureDefinition-EHDSDosage.html) -### eHN Guideline Data Sets -[The Artifacts page](artifacts.html) also provides eHN data sets as logical models. However, those data sets have not been originally published as machine-readable models and the derived logical models often lack of precision and concreteness. EHDS logical information models (see above) use eHN data sets as a conceptual base, and provide non-ambiguous machine-readable models. From 33d8dbf916c908ecbaf5d274026c9bf45e17f4fd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Sun, 10 May 2026 23:19:29 +0300 Subject: [PATCH 4/8] Related to FHIR-56070 --- .../pagecontent/dosagepatterns.liquid.md | 105 +++++++++--------- .../input/pagecontent/medicationconcepts.md | 11 +- ig-src/input/pagecontent/terminology.md | 16 +-- .../input/pagecontent/dosagepatterns.md | 52 ++++----- .../input/pagecontent/medicationconcepts.md | 11 +- igs/mpd-r5/input/pagecontent/terminology.md | 16 +-- input/pagecontent/dosagepatterns.md | 53 +++++---- input/pagecontent/medicationconcepts.md | 11 +- input/pagecontent/terminology.md | 16 +-- 9 files changed, 128 insertions(+), 163 deletions(-) diff --git a/ig-src/input/pagecontent/dosagepatterns.liquid.md b/ig-src/input/pagecontent/dosagepatterns.liquid.md index 9dd240e38..1a018343c 100644 --- a/ig-src/input/pagecontent/dosagepatterns.liquid.md +++ b/ig-src/input/pagecontent/dosagepatterns.liquid.md @@ -37,33 +37,32 @@ In most cases, the full rendered dosage instructions should be made available in {% if isR4 %} |Path R4|1 tablet 3 times a day for 7 days|15-20ml at 8AM and 8PM from 8.12.2025 to 15.12.2025|2 tablets every third day standing on your left foot|50mg per hour intravenously for 20 minutes every Monday|half a tablet as needed before breakfast| |---|-|-|-|-|-| -|Dosage|||||| -|Dosage.sequence|||||| -|Dosage.patientInstruction|||"standing on left foot"||| -|Dosage.timing|||||| -|Dosage.timing.repeat|||||| -|Dosage.timing.repeat.bounds[x]|||||| -|Dosage.timing.repeat.boundsDuration|7 d||||| -|Dosage.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| -|Dosage.timing.repeat.duration||||20|| -|Dosage.timing.repeat.durationUnit||||min|| -|Dosage.timing.repeat.frequency|3||1||| -|Dosage.timing.repeat.period|1||3||| -|Dosage.timing.repeat.periodUnit|d||d||| -|Dosage.timing.repeat.dayOfWeek||||Monday|| -|Dosage.timing.repeat.timeOfDay||8:00, 20:00|||| -|Dosage.timing.repeat.when|||||before breakfast| -|Dosage.asNeededBoolean|||||TRUE| -|Dosage.site|||||| -|Dosage.route||||intravenous|| -|Dosage.doseAndRate|||||| -|Dosage.doseAndRate.dose[x]|||||| -|Dosage.doseAndRate.doseRange||15 ml - 20 ml|||| -|Dosage.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| -|Dosage.doseAndRate.rate[x]|||||| -|Dosage.doseAndRate.rateRatio|||||| -|Dosage.doseAndRate.rateRange|||||| -|Dosage.doseAndRate.rateQuantity||||50 mg/h|| +|.sequence|||||| +|.patientInstruction|||"standing on left foot"||| +|.timing|||||| +|.timing.repeat|||||| +|.timing.repeat.bounds[x]|||||| +|.timing.repeat.boundsDuration|7 d||||| +|.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| +|.timing.repeat.duration||||20|| +|.timing.repeat.durationUnit||||min|| +|.timing.repeat.frequency|3||1||| +|.timing.repeat.period|1||3||| +|.timing.repeat.periodUnit|d||d||| +|.timing.repeat.dayOfWeek||||Monday|| +|.timing.repeat.timeOfDay||8:00, 20:00|||| +|.timing.repeat.when|||||before breakfast| +|.asNeededBoolean|||||TRUE| +|.site|||||| +|.route||||intravenous|| +|.doseAndRate|||||| +|.doseAndRate.dose[x]|||||| +|.doseAndRate.doseRange||15 ml - 20 ml|||| +|.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| +|.doseAndRate.rate[x]|||||| +|.doseAndRate.rateRatio|||||| +|.doseAndRate.rateRange|||||| +|.doseAndRate.rateQuantity||||50 mg/h|| {:.table-bordered .table-striped .thead-light} @@ -72,32 +71,32 @@ In most cases, the full rendered dosage instructions should be made available in |Path R5|1 tablet 3 times a day for 7 days|15-20ml at 8AM and 8PM from 8.12.2025 to 15.12.2025|2 tablets every third day standing on your left foot|50mg per hour intravenously for 20 minutes every Monday|half a tablet as needed before breakfast| |---|-|-|-|-|-| |Dosage|||||| -|Dosage.sequence|||||| -|Dosage.patientInstruction|||"standing on left foot"||| -|Dosage.timing|||||| -|Dosage.timing.repeat|||||| -|Dosage.timing.repeat.bounds[x]|||||| -|Dosage.timing.repeat.boundsDuration|7 d||||| -|Dosage.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| -|Dosage.timing.repeat.duration||||20|| -|Dosage.timing.repeat.durationUnit||||min|| -|Dosage.timing.repeat.frequency|3||1||| -|Dosage.timing.repeat.period|1||3||| -|Dosage.timing.repeat.periodUnit|d||d||| -|Dosage.timing.repeat.dayOfWeek||||Monday|| -|Dosage.timing.repeat.timeOfDay||8:00, 20:00|||| -|Dosage.timing.repeat.when|||||before breakfast| -|Dosage.asNeeded|||||TRUE| -|Dosage.site|||||| -|Dosage.route||||intravenous|| -|Dosage.doseAndRate|||||| -|Dosage.doseAndRate.dose[x]|||||| -|Dosage.doseAndRate.doseRange||15 ml - 20 ml|||| -|Dosage.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| -|Dosage.doseAndRate.rate[x]|||||| -|Dosage.doseAndRate.rateRatio|||||| -|Dosage.doseAndRate.rateRange|||||| -|Dosage.doseAndRate.rateQuantity||||50 mg/h|| +|.sequence|||||| +|.patientInstruction|||"standing on left foot"||| +|.timing|||||| +|.timing.repeat|||||| +|.timing.repeat.bounds[x]|||||| +|.timing.repeat.boundsDuration|7 d||||| +|.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| +|.timing.repeat.duration||||20|| +|.timing.repeat.durationUnit||||min|| +|.timing.repeat.frequency|3||1||| +|.timing.repeat.period|1||3||| +|.timing.repeat.periodUnit|d||d||| +|.timing.repeat.dayOfWeek||||Monday|| +|.timing.repeat.timeOfDay||8:00, 20:00|||| +|.timing.repeat.when|||||before breakfast| +|.asNeeded|||||TRUE| +|.site|||||| +|.route||||intravenous|| +|.doseAndRate|||||| +|.doseAndRate.dose[x]|||||| +|.doseAndRate.doseRange||15 ml - 20 ml|||| +|.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| +|.doseAndRate.rate[x]|||||| +|.doseAndRate.rateRatio|||||| +|.doseAndRate.rateRange|||||| +|.doseAndRate.rateQuantity||||50 mg/h|| {:.table-bordered .table-striped .thead-light} {% endif %} \ No newline at end of file diff --git a/ig-src/input/pagecontent/medicationconcepts.md b/ig-src/input/pagecontent/medicationconcepts.md index 35e0dff67..291755cc2 100644 --- a/ig-src/input/pagecontent/medicationconcepts.md +++ b/ig-src/input/pagecontent/medicationconcepts.md @@ -1,6 +1,6 @@ ### Medication concepts -Medication on a prescription may be represented either as a coded concept (`CodeableConcept`) or as a fully described FHIR resource (e.g. `Medication` or `MedicinalProductDefinition`). The level of detail may range from a simple substance to a fully specified branded product with a defined package size. On dispense, additional identifiers such as a physical package identifier may also be recorded. +Medication on a prescription may be represented either as a coded concept (`CodeableConcept`) or as a fully described FHIR resource (`Medication`). The level of detail may range from a simple substance to a fully specified branded product with a defined package size. On dispense, additional identifiers such as a physical package identifier may also be recorded. When prescribing, the medication may represent either a **virtual product** (e.g. a generic concept) or a **real product** (a specific authorised medicinal product). The implications of this choice vary by jurisdiction. In some countries, prescribing a real product implies that substitution is not allowed. In others, substitution is allowed or expected unless explicitly prohibited, and the prescribed product represents one of several acceptable alternatives. @@ -33,7 +33,7 @@ SNOMED CT includes concepts for substances, dose forms, and units, as well as pr National extensions of SNOMED CT may include real medicinal products, including branded products and packages. Although identifiers differ between countries, these extensions are based on a shared concept model, enabling linkage across jurisdictions via common clinical drug concepts. -FHIR representations of these concepts can be implemented using resources such as `MedicationDefinition` and related artifacts defined in the FHIR Medication Definition module. +FHIR representations of these concepts can be implemented using resources such as `MedicinalProductDefinition` and related artifacts defined in the FHIR Medication Definition module. ### Granularity and implementation considerations @@ -55,10 +55,3 @@ The following table illustrates how selected concept types compare: “+” indicates that the attribute is included in the concept, “-” that it is not included, and “*” that it may be inferred through relationships to other concepts. -### Medicinal product dictionaries - -Most countries maintain national medicinal product dictionaries or registers, often published by regulatory authorities and sometimes remodelled into code systems by other organisations. These systems enable prescriptions and dispenses to reference products using identifiers, with systems resolving full details via lookup. - -However, cross-border scenarios cannot rely on access to national systems. Therefore, cross-border exchange must include both: -- a product identifier, and -- a minimum set of descriptive attributes required for safe interpretation. \ No newline at end of file diff --git a/ig-src/input/pagecontent/terminology.md b/ig-src/input/pagecontent/terminology.md index a6afc5347..f9676ab8d 100644 --- a/ig-src/input/pagecontent/terminology.md +++ b/ig-src/input/pagecontent/terminology.md @@ -45,15 +45,15 @@ Table 2: Comparison of code systems used in MyHealth@EU and EMA services | Unit of presentation | EDQM: 15054000 | 200000002152 | Tablet | | Unit of measurement | UCUM: ug | 100000110656 | microgram(s) | | ATC | WHO ATC: G03AA12 | 100000095785 | drospirenone and ethinylestradiol | -| Country codes | ISO: SE | 100000000535 | Kingdom of Sweden | -| Language codes | BCP-47: sv-SE | 100000072288 | Swedish | +| Country | ISO: SE | 100000000535 | Kingdom of Sweden | +| Language | BCP-47: sv-SE | 100000072288 | Swedish | {:.table-bordered .table-striped .thead-light} The tables above are examples of different terminology needs. The code systems used in MyHealth@EU services are recommended by the eHealth Network for ePrescription and Patient Summary. At national level, additional terminology systems and implementation choices may be required. ### Substances -EMA SPOR Substance Management Services (SMS) provides a list of coded substances, including active ingredients (salts as well as moieties) and excipients. It is used in EMA SPOR services, recommended in eHealth Network guidelines, and implemented in MyHealth@EU cross-border services. However, EMA SMS does not inherently support grouping of substances, which may be relevant for substitution decision-making. +EMA SPOR Substance Management Services (SMS) provides a list of coded substances, including active ingredients (salts as well as moieties) and excipients. It is used in EMA SPOR services, recommended in eHealth Network guidelines, and implemented in MyHealth@EU cross-border services. At national level, local code systems or SNOMED CT are also often used. There is no official mapping between SNOMED CT and EMA SMS. However, as both use official International Nonproprietary Names (INN) assigned by WHO, name-based mapping may be useful. @@ -90,17 +90,13 @@ Dose form attributes can support decision logic in electronic prescription syste The preferred code system for dose form, unit of presentation, package type, and route of administration in this guide is currently EDQM Standard Terms, as used in MyHealth@EU services. Other code systems are not discouraged, provided that mapping to cross-border value sets is supported where cross-border exchange is required. -### EMA SPOR RMS and EDQM Standard Terms +### EMA SPOR RMS -EMA SPOR Referentials Management Services (RMS) is the terminology service supporting central data management for the European regulatory domain. It includes terminology originating from external sources such as EDQM Standard Terms and WHO ATC, as well as EMA-managed terminology. RMS uses EMA identifiers for terminology and product lifecycle management purposes. This means that concepts from source code systems may be recoded with RMS codes, and additional concepts may be added where needed. +EMA SPOR Referentials Management Services (RMS) is the terminology service supporting central data management for the European regulatory domain. It includes terminology originating from external sources such as EDQM Standard Terms and WHO ATC, as well as EMA-managed terminology. RMS uses EMA identifiers for terminology and product lifecycle management purposes. This means that concepts from source code systems are re-coded with RMS codes, and additional concepts may be added where needed. Mappings to source code systems are provided where they exist. For EDQM-derived RMS lists, this means that EDQM codes may be available as mappings from RMS concepts. -EDQM Standard Terms are used in European marketing authorisation applications, labelling, reporting, and related regulatory processes. They have also been adopted by the eHealth community in Europe. The eHealth Network guidelines for ePrescription and Patient Summary recommend EDQM terms for medicinal product data elements such as dose form, route of administration, unit of presentation, and package type. - -Some RMS lists originate from EDQM Standard Terms. When represented with EDQM codes, these terms may be treated as part of the EDQM code system. When represented with RMS codes, they are represented as EMA RMS terminology. This distinction may be relevant for validation and mapping. - -EMA may add concepts to RMS lists when concepts are pre-accepted by the source system but not yet active. As with ATC, using concepts before they are active in the source system may lead to mapping or validation issues in downstream systems. Where EDQM codes are required in national infrastructure or cross-border services, implementations may include additional codings to ensure that mappings are available and validated. +Some RMS lists originate from EDQM Standard Terms. When represented with EDQM codes, these terms may be treated as part of the EDQM code system. When represented with RMS codes, they are represented as EMA RMS terminology. This distinction may be relevant for validation and mapping. Note, that EDQM Standard Terms is one code system containing multiple lists, while every list in RMS is technically a separate code system. ### SNOMED CT diff --git a/igs/mpd-r5/input/pagecontent/dosagepatterns.md b/igs/mpd-r5/input/pagecontent/dosagepatterns.md index e4fc94be1..298ea04bf 100644 --- a/igs/mpd-r5/input/pagecontent/dosagepatterns.md +++ b/igs/mpd-r5/input/pagecontent/dosagepatterns.md @@ -39,31 +39,31 @@ In most cases, the full rendered dosage instructions should be made available in |Path R5|1 tablet 3 times a day for 7 days|15-20ml at 8AM and 8PM from 8.12.2025 to 15.12.2025|2 tablets every third day standing on your left foot|50mg per hour intravenously for 20 minutes every Monday|half a tablet as needed before breakfast| |---|-|-|-|-|-| |Dosage|||||| -|Dosage.sequence|||||| -|Dosage.patientInstruction|||"standing on left foot"||| -|Dosage.timing|||||| -|Dosage.timing.repeat|||||| -|Dosage.timing.repeat.bounds[x]|||||| -|Dosage.timing.repeat.boundsDuration|7 d||||| -|Dosage.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| -|Dosage.timing.repeat.duration||||20|| -|Dosage.timing.repeat.durationUnit||||min|| -|Dosage.timing.repeat.frequency|3||1||| -|Dosage.timing.repeat.period|1||3||| -|Dosage.timing.repeat.periodUnit|d||d||| -|Dosage.timing.repeat.dayOfWeek||||Monday|| -|Dosage.timing.repeat.timeOfDay||8:00, 20:00|||| -|Dosage.timing.repeat.when|||||before breakfast| -|Dosage.asNeeded|||||TRUE| -|Dosage.site|||||| -|Dosage.route||||intravenous|| -|Dosage.doseAndRate|||||| -|Dosage.doseAndRate.dose[x]|||||| -|Dosage.doseAndRate.doseRange||15 ml - 20 ml|||| -|Dosage.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| -|Dosage.doseAndRate.rate[x]|||||| -|Dosage.doseAndRate.rateRatio|||||| -|Dosage.doseAndRate.rateRange|||||| -|Dosage.doseAndRate.rateQuantity||||50 mg/h|| +|.sequence|||||| +|.patientInstruction|||"standing on left foot"||| +|.timing|||||| +|.timing.repeat|||||| +|.timing.repeat.bounds[x]|||||| +|.timing.repeat.boundsDuration|7 d||||| +|.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| +|.timing.repeat.duration||||20|| +|.timing.repeat.durationUnit||||min|| +|.timing.repeat.frequency|3||1||| +|.timing.repeat.period|1||3||| +|.timing.repeat.periodUnit|d||d||| +|.timing.repeat.dayOfWeek||||Monday|| +|.timing.repeat.timeOfDay||8:00, 20:00|||| +|.timing.repeat.when|||||before breakfast| +|.asNeeded|||||TRUE| +|.site|||||| +|.route||||intravenous|| +|.doseAndRate|||||| +|.doseAndRate.dose[x]|||||| +|.doseAndRate.doseRange||15 ml - 20 ml|||| +|.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| +|.doseAndRate.rate[x]|||||| +|.doseAndRate.rateRatio|||||| +|.doseAndRate.rateRange|||||| +|.doseAndRate.rateQuantity||||50 mg/h|| {:.table-bordered .table-striped .thead-light} diff --git a/igs/mpd-r5/input/pagecontent/medicationconcepts.md b/igs/mpd-r5/input/pagecontent/medicationconcepts.md index 35e0dff67..291755cc2 100644 --- a/igs/mpd-r5/input/pagecontent/medicationconcepts.md +++ b/igs/mpd-r5/input/pagecontent/medicationconcepts.md @@ -1,6 +1,6 @@ ### Medication concepts -Medication on a prescription may be represented either as a coded concept (`CodeableConcept`) or as a fully described FHIR resource (e.g. `Medication` or `MedicinalProductDefinition`). The level of detail may range from a simple substance to a fully specified branded product with a defined package size. On dispense, additional identifiers such as a physical package identifier may also be recorded. +Medication on a prescription may be represented either as a coded concept (`CodeableConcept`) or as a fully described FHIR resource (`Medication`). The level of detail may range from a simple substance to a fully specified branded product with a defined package size. On dispense, additional identifiers such as a physical package identifier may also be recorded. When prescribing, the medication may represent either a **virtual product** (e.g. a generic concept) or a **real product** (a specific authorised medicinal product). The implications of this choice vary by jurisdiction. In some countries, prescribing a real product implies that substitution is not allowed. In others, substitution is allowed or expected unless explicitly prohibited, and the prescribed product represents one of several acceptable alternatives. @@ -33,7 +33,7 @@ SNOMED CT includes concepts for substances, dose forms, and units, as well as pr National extensions of SNOMED CT may include real medicinal products, including branded products and packages. Although identifiers differ between countries, these extensions are based on a shared concept model, enabling linkage across jurisdictions via common clinical drug concepts. -FHIR representations of these concepts can be implemented using resources such as `MedicationDefinition` and related artifacts defined in the FHIR Medication Definition module. +FHIR representations of these concepts can be implemented using resources such as `MedicinalProductDefinition` and related artifacts defined in the FHIR Medication Definition module. ### Granularity and implementation considerations @@ -55,10 +55,3 @@ The following table illustrates how selected concept types compare: “+” indicates that the attribute is included in the concept, “-” that it is not included, and “*” that it may be inferred through relationships to other concepts. -### Medicinal product dictionaries - -Most countries maintain national medicinal product dictionaries or registers, often published by regulatory authorities and sometimes remodelled into code systems by other organisations. These systems enable prescriptions and dispenses to reference products using identifiers, with systems resolving full details via lookup. - -However, cross-border scenarios cannot rely on access to national systems. Therefore, cross-border exchange must include both: -- a product identifier, and -- a minimum set of descriptive attributes required for safe interpretation. \ No newline at end of file diff --git a/igs/mpd-r5/input/pagecontent/terminology.md b/igs/mpd-r5/input/pagecontent/terminology.md index a6afc5347..f9676ab8d 100644 --- a/igs/mpd-r5/input/pagecontent/terminology.md +++ b/igs/mpd-r5/input/pagecontent/terminology.md @@ -45,15 +45,15 @@ Table 2: Comparison of code systems used in MyHealth@EU and EMA services | Unit of presentation | EDQM: 15054000 | 200000002152 | Tablet | | Unit of measurement | UCUM: ug | 100000110656 | microgram(s) | | ATC | WHO ATC: G03AA12 | 100000095785 | drospirenone and ethinylestradiol | -| Country codes | ISO: SE | 100000000535 | Kingdom of Sweden | -| Language codes | BCP-47: sv-SE | 100000072288 | Swedish | +| Country | ISO: SE | 100000000535 | Kingdom of Sweden | +| Language | BCP-47: sv-SE | 100000072288 | Swedish | {:.table-bordered .table-striped .thead-light} The tables above are examples of different terminology needs. The code systems used in MyHealth@EU services are recommended by the eHealth Network for ePrescription and Patient Summary. At national level, additional terminology systems and implementation choices may be required. ### Substances -EMA SPOR Substance Management Services (SMS) provides a list of coded substances, including active ingredients (salts as well as moieties) and excipients. It is used in EMA SPOR services, recommended in eHealth Network guidelines, and implemented in MyHealth@EU cross-border services. However, EMA SMS does not inherently support grouping of substances, which may be relevant for substitution decision-making. +EMA SPOR Substance Management Services (SMS) provides a list of coded substances, including active ingredients (salts as well as moieties) and excipients. It is used in EMA SPOR services, recommended in eHealth Network guidelines, and implemented in MyHealth@EU cross-border services. At national level, local code systems or SNOMED CT are also often used. There is no official mapping between SNOMED CT and EMA SMS. However, as both use official International Nonproprietary Names (INN) assigned by WHO, name-based mapping may be useful. @@ -90,17 +90,13 @@ Dose form attributes can support decision logic in electronic prescription syste The preferred code system for dose form, unit of presentation, package type, and route of administration in this guide is currently EDQM Standard Terms, as used in MyHealth@EU services. Other code systems are not discouraged, provided that mapping to cross-border value sets is supported where cross-border exchange is required. -### EMA SPOR RMS and EDQM Standard Terms +### EMA SPOR RMS -EMA SPOR Referentials Management Services (RMS) is the terminology service supporting central data management for the European regulatory domain. It includes terminology originating from external sources such as EDQM Standard Terms and WHO ATC, as well as EMA-managed terminology. RMS uses EMA identifiers for terminology and product lifecycle management purposes. This means that concepts from source code systems may be recoded with RMS codes, and additional concepts may be added where needed. +EMA SPOR Referentials Management Services (RMS) is the terminology service supporting central data management for the European regulatory domain. It includes terminology originating from external sources such as EDQM Standard Terms and WHO ATC, as well as EMA-managed terminology. RMS uses EMA identifiers for terminology and product lifecycle management purposes. This means that concepts from source code systems are re-coded with RMS codes, and additional concepts may be added where needed. Mappings to source code systems are provided where they exist. For EDQM-derived RMS lists, this means that EDQM codes may be available as mappings from RMS concepts. -EDQM Standard Terms are used in European marketing authorisation applications, labelling, reporting, and related regulatory processes. They have also been adopted by the eHealth community in Europe. The eHealth Network guidelines for ePrescription and Patient Summary recommend EDQM terms for medicinal product data elements such as dose form, route of administration, unit of presentation, and package type. - -Some RMS lists originate from EDQM Standard Terms. When represented with EDQM codes, these terms may be treated as part of the EDQM code system. When represented with RMS codes, they are represented as EMA RMS terminology. This distinction may be relevant for validation and mapping. - -EMA may add concepts to RMS lists when concepts are pre-accepted by the source system but not yet active. As with ATC, using concepts before they are active in the source system may lead to mapping or validation issues in downstream systems. Where EDQM codes are required in national infrastructure or cross-border services, implementations may include additional codings to ensure that mappings are available and validated. +Some RMS lists originate from EDQM Standard Terms. When represented with EDQM codes, these terms may be treated as part of the EDQM code system. When represented with RMS codes, they are represented as EMA RMS terminology. This distinction may be relevant for validation and mapping. Note, that EDQM Standard Terms is one code system containing multiple lists, while every list in RMS is technically a separate code system. ### SNOMED CT diff --git a/input/pagecontent/dosagepatterns.md b/input/pagecontent/dosagepatterns.md index c975c19b4..817119dc7 100644 --- a/input/pagecontent/dosagepatterns.md +++ b/input/pagecontent/dosagepatterns.md @@ -37,33 +37,32 @@ In most cases, the full rendered dosage instructions should be made available in |Path R4|1 tablet 3 times a day for 7 days|15-20ml at 8AM and 8PM from 8.12.2025 to 15.12.2025|2 tablets every third day standing on your left foot|50mg per hour intravenously for 20 minutes every Monday|half a tablet as needed before breakfast| |---|-|-|-|-|-| -|Dosage|||||| -|Dosage.sequence|||||| -|Dosage.patientInstruction|||"standing on left foot"||| -|Dosage.timing|||||| -|Dosage.timing.repeat|||||| -|Dosage.timing.repeat.bounds[x]|||||| -|Dosage.timing.repeat.boundsDuration|7 d||||| -|Dosage.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| -|Dosage.timing.repeat.duration||||20|| -|Dosage.timing.repeat.durationUnit||||min|| -|Dosage.timing.repeat.frequency|3||1||| -|Dosage.timing.repeat.period|1||3||| -|Dosage.timing.repeat.periodUnit|d||d||| -|Dosage.timing.repeat.dayOfWeek||||Monday|| -|Dosage.timing.repeat.timeOfDay||8:00, 20:00|||| -|Dosage.timing.repeat.when|||||before breakfast| -|Dosage.asNeededBoolean|||||TRUE| -|Dosage.site|||||| -|Dosage.route||||intravenous|| -|Dosage.doseAndRate|||||| -|Dosage.doseAndRate.dose[x]|||||| -|Dosage.doseAndRate.doseRange||15 ml - 20 ml|||| -|Dosage.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| -|Dosage.doseAndRate.rate[x]|||||| -|Dosage.doseAndRate.rateRatio|||||| -|Dosage.doseAndRate.rateRange|||||| -|Dosage.doseAndRate.rateQuantity||||50 mg/h|| +|.sequence|||||| +|.patientInstruction|||"standing on left foot"||| +|.timing|||||| +|.timing.repeat|||||| +|.timing.repeat.bounds[x]|||||| +|.timing.repeat.boundsDuration|7 d||||| +|.timing.repeat.boundsPeriod||8.12.2025 - 15.12.2025|||| +|.timing.repeat.duration||||20|| +|.timing.repeat.durationUnit||||min|| +|.timing.repeat.frequency|3||1||| +|.timing.repeat.period|1||3||| +|.timing.repeat.periodUnit|d||d||| +|.timing.repeat.dayOfWeek||||Monday|| +|.timing.repeat.timeOfDay||8:00, 20:00|||| +|.timing.repeat.when|||||before breakfast| +|.asNeededBoolean|||||TRUE| +|.site|||||| +|.route||||intravenous|| +|.doseAndRate|||||| +|.doseAndRate.dose[x]|||||| +|.doseAndRate.doseRange||15 ml - 20 ml|||| +|.doseAndRate.doseQuantity|1 tablet(s)||2 tablet(s)||0.5 tablet(s)| +|.doseAndRate.rate[x]|||||| +|.doseAndRate.rateRatio|||||| +|.doseAndRate.rateRange|||||| +|.doseAndRate.rateQuantity||||50 mg/h|| {:.table-bordered .table-striped .thead-light} diff --git a/input/pagecontent/medicationconcepts.md b/input/pagecontent/medicationconcepts.md index 35e0dff67..291755cc2 100644 --- a/input/pagecontent/medicationconcepts.md +++ b/input/pagecontent/medicationconcepts.md @@ -1,6 +1,6 @@ ### Medication concepts -Medication on a prescription may be represented either as a coded concept (`CodeableConcept`) or as a fully described FHIR resource (e.g. `Medication` or `MedicinalProductDefinition`). The level of detail may range from a simple substance to a fully specified branded product with a defined package size. On dispense, additional identifiers such as a physical package identifier may also be recorded. +Medication on a prescription may be represented either as a coded concept (`CodeableConcept`) or as a fully described FHIR resource (`Medication`). The level of detail may range from a simple substance to a fully specified branded product with a defined package size. On dispense, additional identifiers such as a physical package identifier may also be recorded. When prescribing, the medication may represent either a **virtual product** (e.g. a generic concept) or a **real product** (a specific authorised medicinal product). The implications of this choice vary by jurisdiction. In some countries, prescribing a real product implies that substitution is not allowed. In others, substitution is allowed or expected unless explicitly prohibited, and the prescribed product represents one of several acceptable alternatives. @@ -33,7 +33,7 @@ SNOMED CT includes concepts for substances, dose forms, and units, as well as pr National extensions of SNOMED CT may include real medicinal products, including branded products and packages. Although identifiers differ between countries, these extensions are based on a shared concept model, enabling linkage across jurisdictions via common clinical drug concepts. -FHIR representations of these concepts can be implemented using resources such as `MedicationDefinition` and related artifacts defined in the FHIR Medication Definition module. +FHIR representations of these concepts can be implemented using resources such as `MedicinalProductDefinition` and related artifacts defined in the FHIR Medication Definition module. ### Granularity and implementation considerations @@ -55,10 +55,3 @@ The following table illustrates how selected concept types compare: “+” indicates that the attribute is included in the concept, “-” that it is not included, and “*” that it may be inferred through relationships to other concepts. -### Medicinal product dictionaries - -Most countries maintain national medicinal product dictionaries or registers, often published by regulatory authorities and sometimes remodelled into code systems by other organisations. These systems enable prescriptions and dispenses to reference products using identifiers, with systems resolving full details via lookup. - -However, cross-border scenarios cannot rely on access to national systems. Therefore, cross-border exchange must include both: -- a product identifier, and -- a minimum set of descriptive attributes required for safe interpretation. \ No newline at end of file diff --git a/input/pagecontent/terminology.md b/input/pagecontent/terminology.md index a6afc5347..f9676ab8d 100644 --- a/input/pagecontent/terminology.md +++ b/input/pagecontent/terminology.md @@ -45,15 +45,15 @@ Table 2: Comparison of code systems used in MyHealth@EU and EMA services | Unit of presentation | EDQM: 15054000 | 200000002152 | Tablet | | Unit of measurement | UCUM: ug | 100000110656 | microgram(s) | | ATC | WHO ATC: G03AA12 | 100000095785 | drospirenone and ethinylestradiol | -| Country codes | ISO: SE | 100000000535 | Kingdom of Sweden | -| Language codes | BCP-47: sv-SE | 100000072288 | Swedish | +| Country | ISO: SE | 100000000535 | Kingdom of Sweden | +| Language | BCP-47: sv-SE | 100000072288 | Swedish | {:.table-bordered .table-striped .thead-light} The tables above are examples of different terminology needs. The code systems used in MyHealth@EU services are recommended by the eHealth Network for ePrescription and Patient Summary. At national level, additional terminology systems and implementation choices may be required. ### Substances -EMA SPOR Substance Management Services (SMS) provides a list of coded substances, including active ingredients (salts as well as moieties) and excipients. It is used in EMA SPOR services, recommended in eHealth Network guidelines, and implemented in MyHealth@EU cross-border services. However, EMA SMS does not inherently support grouping of substances, which may be relevant for substitution decision-making. +EMA SPOR Substance Management Services (SMS) provides a list of coded substances, including active ingredients (salts as well as moieties) and excipients. It is used in EMA SPOR services, recommended in eHealth Network guidelines, and implemented in MyHealth@EU cross-border services. At national level, local code systems or SNOMED CT are also often used. There is no official mapping between SNOMED CT and EMA SMS. However, as both use official International Nonproprietary Names (INN) assigned by WHO, name-based mapping may be useful. @@ -90,17 +90,13 @@ Dose form attributes can support decision logic in electronic prescription syste The preferred code system for dose form, unit of presentation, package type, and route of administration in this guide is currently EDQM Standard Terms, as used in MyHealth@EU services. Other code systems are not discouraged, provided that mapping to cross-border value sets is supported where cross-border exchange is required. -### EMA SPOR RMS and EDQM Standard Terms +### EMA SPOR RMS -EMA SPOR Referentials Management Services (RMS) is the terminology service supporting central data management for the European regulatory domain. It includes terminology originating from external sources such as EDQM Standard Terms and WHO ATC, as well as EMA-managed terminology. RMS uses EMA identifiers for terminology and product lifecycle management purposes. This means that concepts from source code systems may be recoded with RMS codes, and additional concepts may be added where needed. +EMA SPOR Referentials Management Services (RMS) is the terminology service supporting central data management for the European regulatory domain. It includes terminology originating from external sources such as EDQM Standard Terms and WHO ATC, as well as EMA-managed terminology. RMS uses EMA identifiers for terminology and product lifecycle management purposes. This means that concepts from source code systems are re-coded with RMS codes, and additional concepts may be added where needed. Mappings to source code systems are provided where they exist. For EDQM-derived RMS lists, this means that EDQM codes may be available as mappings from RMS concepts. -EDQM Standard Terms are used in European marketing authorisation applications, labelling, reporting, and related regulatory processes. They have also been adopted by the eHealth community in Europe. The eHealth Network guidelines for ePrescription and Patient Summary recommend EDQM terms for medicinal product data elements such as dose form, route of administration, unit of presentation, and package type. - -Some RMS lists originate from EDQM Standard Terms. When represented with EDQM codes, these terms may be treated as part of the EDQM code system. When represented with RMS codes, they are represented as EMA RMS terminology. This distinction may be relevant for validation and mapping. - -EMA may add concepts to RMS lists when concepts are pre-accepted by the source system but not yet active. As with ATC, using concepts before they are active in the source system may lead to mapping or validation issues in downstream systems. Where EDQM codes are required in national infrastructure or cross-border services, implementations may include additional codings to ensure that mappings are available and validated. +Some RMS lists originate from EDQM Standard Terms. When represented with EDQM codes, these terms may be treated as part of the EDQM code system. When represented with RMS codes, they are represented as EMA RMS terminology. This distinction may be relevant for validation and mapping. Note, that EDQM Standard Terms is one code system containing multiple lists, while every list in RMS is technically a separate code system. ### SNOMED CT From 342b77d6c1a52fafe301125bb816ef456efa5e10 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Sun, 10 May 2026 23:33:03 +0300 Subject: [PATCH 5/8] proof-reading --- FHIR-eu-mpd.xml | 2 +- igs/mpd-r5/FHIR-eu-mpd-r5.xml | 83 +++++++++++++++++++++++++++++++++++ 2 files changed, 84 insertions(+), 1 deletion(-) create mode 100644 igs/mpd-r5/FHIR-eu-mpd-r5.xml diff --git a/FHIR-eu-mpd.xml b/FHIR-eu-mpd.xml index d2de91a6c..06bca4c6b 100644 --- a/FHIR-eu-mpd.xml +++ b/FHIR-eu-mpd.xml @@ -2,7 +2,7 @@ - + diff --git a/igs/mpd-r5/FHIR-eu-mpd-r5.xml b/igs/mpd-r5/FHIR-eu-mpd-r5.xml new file mode 100644 index 000000000..8cd73f940 --- /dev/null +++ b/igs/mpd-r5/FHIR-eu-mpd-r5.xml @@ -0,0 +1,83 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file From 8232ba4f6c218c8254a8a0d77fc0e539affe372d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Mon, 11 May 2026 00:33:44 +0300 Subject: [PATCH 6/8] proof-reading --- .../multiitem-prescription-r4.plantuml | 100 ++++++++++++++++ ...uml => multiitem-prescription-r5.plantuml} | 0 .../{examples.md => examples.liquid.md} | 6 +- ...notes.md => implementationnotes.liquid.md} | 29 +++-- ig-src/input/pagecontent/knownissues.md | 4 +- ig-src/input/pagecontent/modelmap.xml | 13 +- igs/mpd-r5/FHIR-eu-mpd-r5.xml | 83 ------------- .../multiitem-prescription-r4.plantuml | 100 ++++++++++++++++ ...uml => multiitem-prescription-r5.plantuml} | 0 igs/mpd-r5/input/pagecontent/examples.md | 6 +- .../input/pagecontent/implementationnotes.md | 112 ------------------ igs/mpd-r5/input/pagecontent/knownissues.md | 4 +- igs/mpd-r5/input/pagecontent/modelmap.xml | 13 +- .../multiitem-prescription-r4.plantuml | 100 ++++++++++++++++ ...uml => multiitem-prescription-r5.plantuml} | 0 input/pagecontent/examples.md | 6 +- input/pagecontent/implementationnotes.md | 112 ------------------ input/pagecontent/knownissues.md | 4 +- input/pagecontent/modelmap.xml | 13 +- temp_render.txt | 1 + 20 files changed, 347 insertions(+), 359 deletions(-) create mode 100644 ig-src/input/images-source/multiitem-prescription-r4.plantuml rename ig-src/input/images-source/{multiitem-prescription.plantuml => multiitem-prescription-r5.plantuml} (100%) rename ig-src/input/pagecontent/{examples.md => examples.liquid.md} (86%) rename ig-src/input/pagecontent/{implementationnotes.md => implementationnotes.liquid.md} (79%) delete mode 100644 igs/mpd-r5/FHIR-eu-mpd-r5.xml create mode 100644 igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml rename igs/mpd-r5/input/images-source/{multiitem-prescription.plantuml => multiitem-prescription-r5.plantuml} (100%) create mode 100644 input/images-source/multiitem-prescription-r4.plantuml rename input/images-source/{multiitem-prescription.plantuml => multiitem-prescription-r5.plantuml} (100%) create mode 100644 temp_render.txt diff --git a/ig-src/input/images-source/multiitem-prescription-r4.plantuml b/ig-src/input/images-source/multiitem-prescription-r4.plantuml new file mode 100644 index 000000000..b5f5af3c1 --- /dev/null +++ b/ig-src/input/images-source/multiitem-prescription-r4.plantuml @@ -0,0 +1,100 @@ +@startuml + +'skinparam linetype ortho +skinparam linetype polyline +hide circle +hide stereotype + +'!pragma layout smetana + +skinparam class<> { + BorderColor DarkSlateGray + BackgroundColor TECHNOLOGY + HeaderBackgroundColor #7b8 +} + +skinparam class<> { + BorderColor #909050 + BackgroundColor BUSINESS + HeaderBackgroundColor #dd4 +} + +skinparam class<> { + BorderColor #505090 + BackgroundColor APPLICATION + HeaderBackgroundColor #8bd +} + + + +class "**Prescription**" as P<> { + -- + |_ identifier = Pr1 + |_ issued = 12.12.2024 + |_ patient = Patient1 + |_ prescriber = Prescriber1 + |_ item + |_ itemIdentifier = MR1 + |_ medication = Med1 + |_ dosage = Dose1 + |_ item + |_ itemIdentifier = MR2 + |_ medication = Med2 + |_ dosage = Dose2 + -- +} + + +class "**MedicationRequest 1**" as MR1<> { + -- + |_ identifier = MR1 + |_ groupIdentifier = Pr1 + |_ intent = option + |_ subject = Patient1 + |_ requester = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ medication = Med1 + |_ dosageInstruction = Dose1 + -- +} + +class "**MedicationRequest 2**" as MR2<> { + -- + |_ identifier = MR2 + |_ groupIdentifier = Pr1 + |_ intent = option + |_ subject = Patient1 + |_ requester = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ medication = Med2 + |_ dosageInstruction = Dose2 + -- +} + +class "**RequestGroup**" as RO<> { + -- + |_ identifier + |_ groupIdentifier + |_ intent = order + |_ subject = Patient1 + |_ author = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ action + |_ resource MR1 + |_ relatedAction MR2 + |_ action + |_ resource MR2 + |_ relatedAction MR1 + -- +} + + +P -d- RO: " " +P -d- MR1: " " +P -d- MR2: " " +RO -l-> MR1: "reference" +RO -r-> MR2: "reference" + + + +@enduml diff --git a/ig-src/input/images-source/multiitem-prescription.plantuml b/ig-src/input/images-source/multiitem-prescription-r5.plantuml similarity index 100% rename from ig-src/input/images-source/multiitem-prescription.plantuml rename to ig-src/input/images-source/multiitem-prescription-r5.plantuml diff --git a/ig-src/input/pagecontent/examples.md b/ig-src/input/pagecontent/examples.liquid.md similarity index 86% rename from ig-src/input/pagecontent/examples.md rename to ig-src/input/pagecontent/examples.liquid.md index 6dc0718e4..3ccbb4f1d 100644 --- a/ig-src/input/pagecontent/examples.md +++ b/ig-src/input/pagecontent/examples.liquid.md @@ -23,7 +23,7 @@ These two approaches are not mutually exclusive - it is perfectly acceptable to ### Prescription examples -This implementation guide does not consider a prescription or dispense a HL7 FHIR document, but a transactional set of resources. There is no resource called "Prescription" in HL7 FHIR: a prescription may be implemented as a MedicationRequest, multiple MedicationRequests, or a combination of MedicationRequests and RequestOrchestration/RequestGroup. These resources may be exchanged in a Bundle. It is also allowed to use Composition for following the document-oriented approach, but it is not normative. +This implementation guide does not consider a prescription or dispense a HL7 FHIR document, but a transactional set of resources. There is no resource called "Prescription" in HL7 FHIR: a prescription may be implemented as a MedicationRequest, multiple MedicationRequests, or a combination of MedicationRequests and {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %}. These resources may be exchanged in a Bundle. It is also allowed to use Composition for following the document-oriented approach, but it is not normative. Be aware, that MedicationRequest may sometimes be used as a request NOT to give/prescribe a certain medication to a patient, and MedicationDispense can be used for declining a dispense. Do-not-perform-requests are out of scope for this implementation guide, declining a dispense is only presented in the examples. @@ -36,8 +36,8 @@ Implementations do not have to support multi-item prescriptions or dispense decl Following examples are all formulated using a Bundle of type 'collection'. This is just for the sake of representing the example in this IG - using Bundle is not normative in this guide. -- [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup/RequestOrchestration representing a 42-day-cycle where three treatments must start at the same time -- [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup/RequestOrchestration for two products that may be dispensed as one combination product or two separate products +- [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) - prescription with {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} representing a 42-day-cycle where three treatments must start at the same time +- [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) - prescription with {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} for two products that may be dispensed as one combination product or two separate products - [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) - prescription where prescription items are only connected by the .groupIdentifier value Please find more information about multi-item prescription in the [implementation notes](implementationnotes.html) page. diff --git a/ig-src/input/pagecontent/implementationnotes.md b/ig-src/input/pagecontent/implementationnotes.liquid.md similarity index 79% rename from ig-src/input/pagecontent/implementationnotes.md rename to ig-src/input/pagecontent/implementationnotes.liquid.md index 13d80b5f9..7a557b4b3 100644 --- a/ig-src/input/pagecontent/implementationnotes.md +++ b/ig-src/input/pagecontent/implementationnotes.liquid.md @@ -50,9 +50,9 @@ This option differs from the previous one by one important aspect: the data elem - No way to show interdependencies between individual items/requests - The status of the prescription has to be the same or calculable from individual prescription items -#### Option 3: Using RequestOrchestration/RequestGroup +#### Option 3: Using {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} -This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. RequestOrchestration (R5) or RequestGroup (R4) shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that RequestOrchestration/RequestGroup is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration resource and exchanging individual MedicationRequests. +This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration resource and exchanging individual MedicationRequests. **Pros:** - Possible to define interdependencies between prescription items. @@ -60,25 +60,34 @@ This option is technically more complex to handle on the FHIR side, but it allow **Cons:** - Multiitem prescription and single-item prescription are handled differently. In a prescription system where multi-item prescriptions use RequestOrchestration, it is important to consider whether single-item prescriptions should be using the same mechanism, even though it does not add anything to the semantics. -- Receiving systems outside the ecosystem are likely to drop the RequestOrchestration/RequstGroup resource when it's not explicitly supported in their implementation. +- Receiving systems outside the ecosystem are likely to drop the {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} resource when it's not explicitly supported in their implementation. -When grouping MedicationRequests with a RequestOrchestration/RequestGroup: +When grouping MedicationRequests with a {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %}: - MedicationRequest.intent value must be ‘option’. This is a signal to the receiver, that the request must be handled as part of a bigger request group. -- The element that binds MedicationRequest and RequestOrchestration/RequestGroup together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. +- The element that binds MedicationRequest and {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. - The prescription identifier should be the value of .groupIdentifier. - MedicationRequests, if they originate from the same prescription, should have the same patient and authoring metadata. -The following diagram explains the process of splitting a custom multi-item prescription (yellow) into HL7FHIR resources (green). +The following diagram explains the process of splitting a custom multi-item prescription (yellow) into HL7 FHIR resources (green). +{% if isR5 %}
- {% include multiitem-prescription.svg %} + {% include multiitem-prescription-r5.svg %}
+{% endif %} + +{% if isR4 %} +
+ {% include multiitem-prescription-r4.svg %} + +
+{% endif %}
-Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using RequestOrchestration, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. +Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %}, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. -Read more about using RequestOrchestration/RequestGroup in FHIR workflow pages. +Read more about using {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} in FHIR workflow pages. ### Prescription statuses and workflow @@ -88,7 +97,7 @@ MedicationRequest has a very limited set of statuses available for use. This is Prescription and dispensation systems often use additional or different statuses, and those statuses are not directly mappable to MedicationRequest.status. Some of these prescription statuses may actually be related to the dispense rather than the request, so the semantically correct place for some statuses would actually be MedicationDispense.status. Some simple workflows may choose to make use of the .meta.tag 'actionable' to indicate whether the request is dispensable or simply for information. -For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional RequestOrchestration (R4 RequestGroup) resource should be used. +For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} resource should be used. Workflows are typically implementation-specific and the aim of this implementation guide is not to provide one solution for everyone. Practice of using prescription and dispensation statuses varies a lot across countries and use cases (e.g. hospital use vs community pharmacy). While it is important for each implementation to map their business statuses to FHIR MedicationRequest.status values, the usage of Task and building a workflow will not be restricted by this implementation guide. diff --git a/ig-src/input/pagecontent/knownissues.md b/ig-src/input/pagecontent/knownissues.md index d71b51ff9..e706ecd98 100644 --- a/ig-src/input/pagecontent/knownissues.md +++ b/ig-src/input/pagecontent/knownissues.md @@ -12,7 +12,7 @@ The current version of the implementation guide does not impose IHE MPD profiles ### Ambiguous mappings for some elements #### Medicinal product name -Medication resource does not have an explicit element for medicinal product's name. In countries where medication information is distributed as a code system, *de facto* element for holding the medication name has been Medication.code.text or Medication.code.coding.display. This is also the recommendations by HL7 Pharmacy. +Medication resource does not have an explicit element for medicinal product's name. In countries where medication information is distributed as a code system, *de facto* element for holding the medication name has been Medication.code.text or Medication.code.coding.display. This is also the recommendation from HL7 Pharmacy. However, analysis of extensions in national implementation guides showed that many countries prefer to extend Medication resource in order to include an explicit element for the name. It is also evident, that countries often add multiple codings to the .code element, which makes it difficult to understand which of the codings display the official name of the product. Therefore, this IG includes a simple extension for the authorised medicinal product name. National implementations are not required to use the extension when their functional requirements are covered by .code element. @@ -22,7 +22,7 @@ In national implementations, two different approaches are used for capturing the - MedicationDispense.location - pharmacy is indicated using Location resource. - MedicationDispense.performer.actor - PractitionerRole as performer is expected to indicate the pharmacy as an Organization. -This implementation guide does not yet take a stance on which approach should be preferred. Additional input from countries is welcome during the ballots. +This implementation guide does not yet take a stance on which approach should be preferred. Additional input from countries is welcome. #### Medication identifier vs code diff --git a/ig-src/input/pagecontent/modelmap.xml b/ig-src/input/pagecontent/modelmap.xml index 88ae367f5..e31a07301 100644 --- a/ig-src/input/pagecontent/modelmap.xml +++ b/ig-src/input/pagecontent/modelmap.xml @@ -22,17 +22,13 @@ administrative concepts. This Implementation Guide provides HL7 FHIR profiles that realise those models.

-

- The sections below group the EHDS logical models into categories. -

-

Each table shows:

+

The table shows:

  • the logical model
  • the FHIR datatype or profile(s) used in this IG
  • a link to the detailed element-by-element mapping
-

- 💊 Medication Models

+

Medication Models

@@ -107,11 +103,10 @@
-

- 🧩 Other Models used by this guide

+

Other Models used by this guide

The implementation guide references profiles and models that are not specific for prescription and dispense. - Mapping details for such models are published in theHL7 Europe Base and Core FHIR IG. + Mapping details for such models are published in the HL7 Europe Base and Core FHIR IG.

diff --git a/igs/mpd-r5/FHIR-eu-mpd-r5.xml b/igs/mpd-r5/FHIR-eu-mpd-r5.xml deleted file mode 100644 index 8cd73f940..000000000 --- a/igs/mpd-r5/FHIR-eu-mpd-r5.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml b/igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml new file mode 100644 index 000000000..b5f5af3c1 --- /dev/null +++ b/igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml @@ -0,0 +1,100 @@ +@startuml + +'skinparam linetype ortho +skinparam linetype polyline +hide circle +hide stereotype + +'!pragma layout smetana + +skinparam class<> { + BorderColor DarkSlateGray + BackgroundColor TECHNOLOGY + HeaderBackgroundColor #7b8 +} + +skinparam class<> { + BorderColor #909050 + BackgroundColor BUSINESS + HeaderBackgroundColor #dd4 +} + +skinparam class<> { + BorderColor #505090 + BackgroundColor APPLICATION + HeaderBackgroundColor #8bd +} + + + +class "**Prescription**" as P<> { + -- + |_ identifier = Pr1 + |_ issued = 12.12.2024 + |_ patient = Patient1 + |_ prescriber = Prescriber1 + |_ item + |_ itemIdentifier = MR1 + |_ medication = Med1 + |_ dosage = Dose1 + |_ item + |_ itemIdentifier = MR2 + |_ medication = Med2 + |_ dosage = Dose2 + -- +} + + +class "**MedicationRequest 1**" as MR1<> { + -- + |_ identifier = MR1 + |_ groupIdentifier = Pr1 + |_ intent = option + |_ subject = Patient1 + |_ requester = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ medication = Med1 + |_ dosageInstruction = Dose1 + -- +} + +class "**MedicationRequest 2**" as MR2<> { + -- + |_ identifier = MR2 + |_ groupIdentifier = Pr1 + |_ intent = option + |_ subject = Patient1 + |_ requester = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ medication = Med2 + |_ dosageInstruction = Dose2 + -- +} + +class "**RequestGroup**" as RO<> { + -- + |_ identifier + |_ groupIdentifier + |_ intent = order + |_ subject = Patient1 + |_ author = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ action + |_ resource MR1 + |_ relatedAction MR2 + |_ action + |_ resource MR2 + |_ relatedAction MR1 + -- +} + + +P -d- RO: " " +P -d- MR1: " " +P -d- MR2: " " +RO -l-> MR1: "reference" +RO -r-> MR2: "reference" + + + +@enduml diff --git a/igs/mpd-r5/input/images-source/multiitem-prescription.plantuml b/igs/mpd-r5/input/images-source/multiitem-prescription-r5.plantuml similarity index 100% rename from igs/mpd-r5/input/images-source/multiitem-prescription.plantuml rename to igs/mpd-r5/input/images-source/multiitem-prescription-r5.plantuml diff --git a/igs/mpd-r5/input/pagecontent/examples.md b/igs/mpd-r5/input/pagecontent/examples.md index 6dc0718e4..a83432e37 100644 --- a/igs/mpd-r5/input/pagecontent/examples.md +++ b/igs/mpd-r5/input/pagecontent/examples.md @@ -23,7 +23,7 @@ These two approaches are not mutually exclusive - it is perfectly acceptable to ### Prescription examples -This implementation guide does not consider a prescription or dispense a HL7 FHIR document, but a transactional set of resources. There is no resource called "Prescription" in HL7 FHIR: a prescription may be implemented as a MedicationRequest, multiple MedicationRequests, or a combination of MedicationRequests and RequestOrchestration/RequestGroup. These resources may be exchanged in a Bundle. It is also allowed to use Composition for following the document-oriented approach, but it is not normative. +This implementation guide does not consider a prescription or dispense a HL7 FHIR document, but a transactional set of resources. There is no resource called "Prescription" in HL7 FHIR: a prescription may be implemented as a MedicationRequest, multiple MedicationRequests, or a combination of MedicationRequests and RequestOrchestration. These resources may be exchanged in a Bundle. It is also allowed to use Composition for following the document-oriented approach, but it is not normative. Be aware, that MedicationRequest may sometimes be used as a request NOT to give/prescribe a certain medication to a patient, and MedicationDispense can be used for declining a dispense. Do-not-perform-requests are out of scope for this implementation guide, declining a dispense is only presented in the examples. @@ -36,8 +36,8 @@ Implementations do not have to support multi-item prescriptions or dispense decl Following examples are all formulated using a Bundle of type 'collection'. This is just for the sake of representing the example in this IG - using Bundle is not normative in this guide. -- [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup/RequestOrchestration representing a 42-day-cycle where three treatments must start at the same time -- [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup/RequestOrchestration for two products that may be dispensed as one combination product or two separate products +- [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) - prescription with RequestOrchestration representing a 42-day-cycle where three treatments must start at the same time +- [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) - prescription with RequestOrchestration for two products that may be dispensed as one combination product or two separate products - [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) - prescription where prescription items are only connected by the .groupIdentifier value Please find more information about multi-item prescription in the [implementation notes](implementationnotes.html) page. diff --git a/igs/mpd-r5/input/pagecontent/implementationnotes.md b/igs/mpd-r5/input/pagecontent/implementationnotes.md index 13d80b5f9..e69de29bb 100644 --- a/igs/mpd-r5/input/pagecontent/implementationnotes.md +++ b/igs/mpd-r5/input/pagecontent/implementationnotes.md @@ -1,112 +0,0 @@ -### Prescription - document or request approach - -Prescription has historically been a document that authorises one or multiple requests. In FHIR, there is no explicit resource for Prescription, and it is possible to focus on the document aspect or the request aspect. Some countries have preferred to keep the document view using Bundle with Composition. This IG does not encourage nor ban this approach, but there is no profile for document Bundle in the IG. - -Examples in this IG use collection Bundle simply for making it easier to read for the humans. Many implementers use transaction Bundle for creating new prescriptions as it allows assigning server-side IDs more easily. - -The choice of wrapping the request and its related resources in a Bundle or not, is entirely up to the implementers. - - -### Multi-item prescriptions - -Systems are not required to support multi-item prescriptions in order to be compliant with this implementation guide. - -The recommended way of designing prescriptions in HL7 FHIR is to have one item per prescription. This is reflected in the MedicationRequest resource where the Medication cardinality is 1..1. Currently, the European crossborder prescription CDA implementation also allows only one medication per prescription, expecting the country of origin to split a multi-item prescription into several crossborder prescriptions and track the dispensations accordingly. However, real life national prescription systems are often designed differently from this logic; in many countries a prescription may contain more than one medication item. - -There is no single mechanism in HL7 FHIR for handling multi-item prescriptions. To choose the optimal solution, one must consider the business requirements and reasons behind a multi-item prescription: -- Is it used merely as a grouping mechanism without deeper semantics? -- Are there technical reasons why multiple items must be transported as one group? -- Are the items on prescription related to each other through the dosing scheme? -- Must the items be dispensed as one transaction? -- Are there pricing or reimbursement rules that are dependent on grouping? -- How does the status of a prescription relate to the statuses of individual requests? -- What are the consequences of adding or removing prescription items: can a single-item prescription become a multi-item prescription and vice versa? - -Considering the requirements above, the best match from the following approaches can be chosen. - -#### Option 1: No grouping - -This option can only be used when the items on a prescription can be easily split and dispensed separately. The information about which prescription the items belong to is handled outside FHIR services. - -**Pros:** -- Technically the easiest option to implement in FHIR. -- Allows the same handling of data for single- and multi-item prescriptions. - -**Cons:** -- The prescription identifier is not present -- The complexity of matching the items and prescriptions does not disappear, but is pushed to the prescription/dispensing systems. -- Only applicable when individual items have no interdependencies. - -#### Option 2: Using .groupIdentifier - -This option differs from the previous one by one important aspect: the data element .groupIdentifier is filled with the prescription identifier. This allows linking different prescription items within FHIR services, but it does not provide any extra information about the prescription or interdependencies between different items on the same prescription. Systems that do not support multi-item prescriptions may ignore the groupIdentifier element and leave it unprocessed. - -**Pros:** -- Easy to implement -- Allows very similar handling of data for single- and multi-item prescriptions -- .groupIdentifier preserves the prescription identifier. - -**Cons:** -- No way to show interdependencies between individual items/requests -- The status of the prescription has to be the same or calculable from individual prescription items - -#### Option 3: Using RequestOrchestration/RequestGroup - -This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. RequestOrchestration (R5) or RequestGroup (R4) shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that RequestOrchestration/RequestGroup is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration resource and exchanging individual MedicationRequests. - -**Pros:** -- Possible to define interdependencies between prescription items. -- Multi-item prescription is clearly defined and distinguishable from single-item prescriptions. - -**Cons:** -- Multiitem prescription and single-item prescription are handled differently. In a prescription system where multi-item prescriptions use RequestOrchestration, it is important to consider whether single-item prescriptions should be using the same mechanism, even though it does not add anything to the semantics. -- Receiving systems outside the ecosystem are likely to drop the RequestOrchestration/RequstGroup resource when it's not explicitly supported in their implementation. - -When grouping MedicationRequests with a RequestOrchestration/RequestGroup: -- MedicationRequest.intent value must be ‘option’. This is a signal to the receiver, that the request must be handled as part of a bigger request group. -- The element that binds MedicationRequest and RequestOrchestration/RequestGroup together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. -- The prescription identifier should be the value of .groupIdentifier. -- MedicationRequests, if they originate from the same prescription, should have the same patient and authoring metadata. - -The following diagram explains the process of splitting a custom multi-item prescription (yellow) into HL7FHIR resources (green). - -
- {% include multiitem-prescription.svg %} - -
-
- -Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using RequestOrchestration, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. - -Read more about using RequestOrchestration/RequestGroup in FHIR workflow pages. - - -### Prescription statuses and workflow - -MedicationRequest has a very limited set of statuses available for use. This is a deliberate design choice to improve interoperability across different settings. - -Prescription and dispensation systems often use additional or different statuses, and those statuses are not directly mappable to MedicationRequest.status. Some of these prescription statuses may actually be related to the dispense rather than the request, so the semantically correct place for some statuses would actually be MedicationDispense.status. - -Some simple workflows may choose to make use of the .meta.tag 'actionable' to indicate whether the request is dispensable or simply for information. -For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional RequestOrchestration (R4 RequestGroup) resource should be used. - -Workflows are typically implementation-specific and the aim of this implementation guide is not to provide one solution for everyone. Practice of using prescription and dispensation statuses varies a lot across countries and use cases (e.g. hospital use vs community pharmacy). While it is important for each implementation to map their business statuses to FHIR MedicationRequest.status values, the usage of Task and building a workflow will not be restricted by this implementation guide. - -HL7 guidance materials for designing request workflows: -- [Workflow](https://hl7.org/fhir/workflow.html) -- [Workflow module](https://hl7.org/fhir/workflow-module.html) -- [Additional explanations - WIP](https://confluence.hl7.org/pages/viewpage.action?pageId=248715046) - - -### Medication: identifier, code, classification - -In the case of medications, the distinction between .identifier and .code is not always clear, and practices for using these elements vary across countries. This implementation guide allows the use of the .identifier element for non-instance identifiers, such as IDMP identifiers or product codes from a national product registry or the EMA PMS. - -A product code is typically used when the source of the data is distributed as a code system. This may include SNOMED CT, a national drug extension, or any local code system supporting prescribing and dispensing use cases. It is common to prescribe products at the virtual product level and dispense them at the branded product package level. The source system for virtual products may differ from the source system for branded products. - -The implementation guide introduces an extension for classification and recommends using it for ATC as well as for any local classifications relevant to the use case. In several countries, ATC is also known to be added to the .code element as an additional coding. This practice is not prohibited by the implementation guide. However, implementations must be able to distinguish the actual prescribed concept from classification codes to remove potential ambiguities in cross-border settings. - -### Data absent reason - -This implementation guide does not use data absent reason extensions in profiles. -Handling missing data is explained in [HL7 Europe Base and Core FHIR Implementation Guide](https://hl7.eu/fhir/base/missing-data.html). \ No newline at end of file diff --git a/igs/mpd-r5/input/pagecontent/knownissues.md b/igs/mpd-r5/input/pagecontent/knownissues.md index d71b51ff9..e706ecd98 100644 --- a/igs/mpd-r5/input/pagecontent/knownissues.md +++ b/igs/mpd-r5/input/pagecontent/knownissues.md @@ -12,7 +12,7 @@ The current version of the implementation guide does not impose IHE MPD profiles ### Ambiguous mappings for some elements #### Medicinal product name -Medication resource does not have an explicit element for medicinal product's name. In countries where medication information is distributed as a code system, *de facto* element for holding the medication name has been Medication.code.text or Medication.code.coding.display. This is also the recommendations by HL7 Pharmacy. +Medication resource does not have an explicit element for medicinal product's name. In countries where medication information is distributed as a code system, *de facto* element for holding the medication name has been Medication.code.text or Medication.code.coding.display. This is also the recommendation from HL7 Pharmacy. However, analysis of extensions in national implementation guides showed that many countries prefer to extend Medication resource in order to include an explicit element for the name. It is also evident, that countries often add multiple codings to the .code element, which makes it difficult to understand which of the codings display the official name of the product. Therefore, this IG includes a simple extension for the authorised medicinal product name. National implementations are not required to use the extension when their functional requirements are covered by .code element. @@ -22,7 +22,7 @@ In national implementations, two different approaches are used for capturing the - MedicationDispense.location - pharmacy is indicated using Location resource. - MedicationDispense.performer.actor - PractitionerRole as performer is expected to indicate the pharmacy as an Organization. -This implementation guide does not yet take a stance on which approach should be preferred. Additional input from countries is welcome during the ballots. +This implementation guide does not yet take a stance on which approach should be preferred. Additional input from countries is welcome. #### Medication identifier vs code diff --git a/igs/mpd-r5/input/pagecontent/modelmap.xml b/igs/mpd-r5/input/pagecontent/modelmap.xml index 88ae367f5..e31a07301 100644 --- a/igs/mpd-r5/input/pagecontent/modelmap.xml +++ b/igs/mpd-r5/input/pagecontent/modelmap.xml @@ -22,17 +22,13 @@ administrative concepts. This Implementation Guide provides HL7 FHIR profiles that realise those models.

-

- The sections below group the EHDS logical models into categories. -

-

Each table shows:

+

The table shows:

  • the logical model
  • the FHIR datatype or profile(s) used in this IG
  • a link to the detailed element-by-element mapping
-

- 💊 Medication Models

+

Medication Models

@@ -107,11 +103,10 @@
-

- 🧩 Other Models used by this guide

+

Other Models used by this guide

The implementation guide references profiles and models that are not specific for prescription and dispense. - Mapping details for such models are published in theHL7 Europe Base and Core FHIR IG. + Mapping details for such models are published in the HL7 Europe Base and Core FHIR IG.

diff --git a/input/images-source/multiitem-prescription-r4.plantuml b/input/images-source/multiitem-prescription-r4.plantuml new file mode 100644 index 000000000..b5f5af3c1 --- /dev/null +++ b/input/images-source/multiitem-prescription-r4.plantuml @@ -0,0 +1,100 @@ +@startuml + +'skinparam linetype ortho +skinparam linetype polyline +hide circle +hide stereotype + +'!pragma layout smetana + +skinparam class<> { + BorderColor DarkSlateGray + BackgroundColor TECHNOLOGY + HeaderBackgroundColor #7b8 +} + +skinparam class<> { + BorderColor #909050 + BackgroundColor BUSINESS + HeaderBackgroundColor #dd4 +} + +skinparam class<> { + BorderColor #505090 + BackgroundColor APPLICATION + HeaderBackgroundColor #8bd +} + + + +class "**Prescription**" as P<> { + -- + |_ identifier = Pr1 + |_ issued = 12.12.2024 + |_ patient = Patient1 + |_ prescriber = Prescriber1 + |_ item + |_ itemIdentifier = MR1 + |_ medication = Med1 + |_ dosage = Dose1 + |_ item + |_ itemIdentifier = MR2 + |_ medication = Med2 + |_ dosage = Dose2 + -- +} + + +class "**MedicationRequest 1**" as MR1<> { + -- + |_ identifier = MR1 + |_ groupIdentifier = Pr1 + |_ intent = option + |_ subject = Patient1 + |_ requester = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ medication = Med1 + |_ dosageInstruction = Dose1 + -- +} + +class "**MedicationRequest 2**" as MR2<> { + -- + |_ identifier = MR2 + |_ groupIdentifier = Pr1 + |_ intent = option + |_ subject = Patient1 + |_ requester = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ medication = Med2 + |_ dosageInstruction = Dose2 + -- +} + +class "**RequestGroup**" as RO<> { + -- + |_ identifier + |_ groupIdentifier + |_ intent = order + |_ subject = Patient1 + |_ author = Prescriber1 + |_ authoredOn = 12.12.2024 + |_ action + |_ resource MR1 + |_ relatedAction MR2 + |_ action + |_ resource MR2 + |_ relatedAction MR1 + -- +} + + +P -d- RO: " " +P -d- MR1: " " +P -d- MR2: " " +RO -l-> MR1: "reference" +RO -r-> MR2: "reference" + + + +@enduml diff --git a/input/images-source/multiitem-prescription.plantuml b/input/images-source/multiitem-prescription-r5.plantuml similarity index 100% rename from input/images-source/multiitem-prescription.plantuml rename to input/images-source/multiitem-prescription-r5.plantuml diff --git a/input/pagecontent/examples.md b/input/pagecontent/examples.md index 6dc0718e4..423301bcc 100644 --- a/input/pagecontent/examples.md +++ b/input/pagecontent/examples.md @@ -23,7 +23,7 @@ These two approaches are not mutually exclusive - it is perfectly acceptable to ### Prescription examples -This implementation guide does not consider a prescription or dispense a HL7 FHIR document, but a transactional set of resources. There is no resource called "Prescription" in HL7 FHIR: a prescription may be implemented as a MedicationRequest, multiple MedicationRequests, or a combination of MedicationRequests and RequestOrchestration/RequestGroup. These resources may be exchanged in a Bundle. It is also allowed to use Composition for following the document-oriented approach, but it is not normative. +This implementation guide does not consider a prescription or dispense a HL7 FHIR document, but a transactional set of resources. There is no resource called "Prescription" in HL7 FHIR: a prescription may be implemented as a MedicationRequest, multiple MedicationRequests, or a combination of MedicationRequests and RequestGroup. These resources may be exchanged in a Bundle. It is also allowed to use Composition for following the document-oriented approach, but it is not normative. Be aware, that MedicationRequest may sometimes be used as a request NOT to give/prescribe a certain medication to a patient, and MedicationDispense can be used for declining a dispense. Do-not-perform-requests are out of scope for this implementation guide, declining a dispense is only presented in the examples. @@ -36,8 +36,8 @@ Implementations do not have to support multi-item prescriptions or dispense decl Following examples are all formulated using a Bundle of type 'collection'. This is just for the sake of representing the example in this IG - using Bundle is not normative in this guide. -- [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup/RequestOrchestration representing a 42-day-cycle where three treatments must start at the same time -- [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup/RequestOrchestration for two products that may be dispensed as one combination product or two separate products +- [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup representing a 42-day-cycle where three treatments must start at the same time +- [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) - prescription with RequestGroup for two products that may be dispensed as one combination product or two separate products - [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) - prescription where prescription items are only connected by the .groupIdentifier value Please find more information about multi-item prescription in the [implementation notes](implementationnotes.html) page. diff --git a/input/pagecontent/implementationnotes.md b/input/pagecontent/implementationnotes.md index 13d80b5f9..e69de29bb 100644 --- a/input/pagecontent/implementationnotes.md +++ b/input/pagecontent/implementationnotes.md @@ -1,112 +0,0 @@ -### Prescription - document or request approach - -Prescription has historically been a document that authorises one or multiple requests. In FHIR, there is no explicit resource for Prescription, and it is possible to focus on the document aspect or the request aspect. Some countries have preferred to keep the document view using Bundle with Composition. This IG does not encourage nor ban this approach, but there is no profile for document Bundle in the IG. - -Examples in this IG use collection Bundle simply for making it easier to read for the humans. Many implementers use transaction Bundle for creating new prescriptions as it allows assigning server-side IDs more easily. - -The choice of wrapping the request and its related resources in a Bundle or not, is entirely up to the implementers. - - -### Multi-item prescriptions - -Systems are not required to support multi-item prescriptions in order to be compliant with this implementation guide. - -The recommended way of designing prescriptions in HL7 FHIR is to have one item per prescription. This is reflected in the MedicationRequest resource where the Medication cardinality is 1..1. Currently, the European crossborder prescription CDA implementation also allows only one medication per prescription, expecting the country of origin to split a multi-item prescription into several crossborder prescriptions and track the dispensations accordingly. However, real life national prescription systems are often designed differently from this logic; in many countries a prescription may contain more than one medication item. - -There is no single mechanism in HL7 FHIR for handling multi-item prescriptions. To choose the optimal solution, one must consider the business requirements and reasons behind a multi-item prescription: -- Is it used merely as a grouping mechanism without deeper semantics? -- Are there technical reasons why multiple items must be transported as one group? -- Are the items on prescription related to each other through the dosing scheme? -- Must the items be dispensed as one transaction? -- Are there pricing or reimbursement rules that are dependent on grouping? -- How does the status of a prescription relate to the statuses of individual requests? -- What are the consequences of adding or removing prescription items: can a single-item prescription become a multi-item prescription and vice versa? - -Considering the requirements above, the best match from the following approaches can be chosen. - -#### Option 1: No grouping - -This option can only be used when the items on a prescription can be easily split and dispensed separately. The information about which prescription the items belong to is handled outside FHIR services. - -**Pros:** -- Technically the easiest option to implement in FHIR. -- Allows the same handling of data for single- and multi-item prescriptions. - -**Cons:** -- The prescription identifier is not present -- The complexity of matching the items and prescriptions does not disappear, but is pushed to the prescription/dispensing systems. -- Only applicable when individual items have no interdependencies. - -#### Option 2: Using .groupIdentifier - -This option differs from the previous one by one important aspect: the data element .groupIdentifier is filled with the prescription identifier. This allows linking different prescription items within FHIR services, but it does not provide any extra information about the prescription or interdependencies between different items on the same prescription. Systems that do not support multi-item prescriptions may ignore the groupIdentifier element and leave it unprocessed. - -**Pros:** -- Easy to implement -- Allows very similar handling of data for single- and multi-item prescriptions -- .groupIdentifier preserves the prescription identifier. - -**Cons:** -- No way to show interdependencies between individual items/requests -- The status of the prescription has to be the same or calculable from individual prescription items - -#### Option 3: Using RequestOrchestration/RequestGroup - -This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. RequestOrchestration (R5) or RequestGroup (R4) shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that RequestOrchestration/RequestGroup is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration resource and exchanging individual MedicationRequests. - -**Pros:** -- Possible to define interdependencies between prescription items. -- Multi-item prescription is clearly defined and distinguishable from single-item prescriptions. - -**Cons:** -- Multiitem prescription and single-item prescription are handled differently. In a prescription system where multi-item prescriptions use RequestOrchestration, it is important to consider whether single-item prescriptions should be using the same mechanism, even though it does not add anything to the semantics. -- Receiving systems outside the ecosystem are likely to drop the RequestOrchestration/RequstGroup resource when it's not explicitly supported in their implementation. - -When grouping MedicationRequests with a RequestOrchestration/RequestGroup: -- MedicationRequest.intent value must be ‘option’. This is a signal to the receiver, that the request must be handled as part of a bigger request group. -- The element that binds MedicationRequest and RequestOrchestration/RequestGroup together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. -- The prescription identifier should be the value of .groupIdentifier. -- MedicationRequests, if they originate from the same prescription, should have the same patient and authoring metadata. - -The following diagram explains the process of splitting a custom multi-item prescription (yellow) into HL7FHIR resources (green). - -
- {% include multiitem-prescription.svg %} - -
-
- -Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using RequestOrchestration, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. - -Read more about using RequestOrchestration/RequestGroup in FHIR workflow pages. - - -### Prescription statuses and workflow - -MedicationRequest has a very limited set of statuses available for use. This is a deliberate design choice to improve interoperability across different settings. - -Prescription and dispensation systems often use additional or different statuses, and those statuses are not directly mappable to MedicationRequest.status. Some of these prescription statuses may actually be related to the dispense rather than the request, so the semantically correct place for some statuses would actually be MedicationDispense.status. - -Some simple workflows may choose to make use of the .meta.tag 'actionable' to indicate whether the request is dispensable or simply for information. -For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional RequestOrchestration (R4 RequestGroup) resource should be used. - -Workflows are typically implementation-specific and the aim of this implementation guide is not to provide one solution for everyone. Practice of using prescription and dispensation statuses varies a lot across countries and use cases (e.g. hospital use vs community pharmacy). While it is important for each implementation to map their business statuses to FHIR MedicationRequest.status values, the usage of Task and building a workflow will not be restricted by this implementation guide. - -HL7 guidance materials for designing request workflows: -- [Workflow](https://hl7.org/fhir/workflow.html) -- [Workflow module](https://hl7.org/fhir/workflow-module.html) -- [Additional explanations - WIP](https://confluence.hl7.org/pages/viewpage.action?pageId=248715046) - - -### Medication: identifier, code, classification - -In the case of medications, the distinction between .identifier and .code is not always clear, and practices for using these elements vary across countries. This implementation guide allows the use of the .identifier element for non-instance identifiers, such as IDMP identifiers or product codes from a national product registry or the EMA PMS. - -A product code is typically used when the source of the data is distributed as a code system. This may include SNOMED CT, a national drug extension, or any local code system supporting prescribing and dispensing use cases. It is common to prescribe products at the virtual product level and dispense them at the branded product package level. The source system for virtual products may differ from the source system for branded products. - -The implementation guide introduces an extension for classification and recommends using it for ATC as well as for any local classifications relevant to the use case. In several countries, ATC is also known to be added to the .code element as an additional coding. This practice is not prohibited by the implementation guide. However, implementations must be able to distinguish the actual prescribed concept from classification codes to remove potential ambiguities in cross-border settings. - -### Data absent reason - -This implementation guide does not use data absent reason extensions in profiles. -Handling missing data is explained in [HL7 Europe Base and Core FHIR Implementation Guide](https://hl7.eu/fhir/base/missing-data.html). \ No newline at end of file diff --git a/input/pagecontent/knownissues.md b/input/pagecontent/knownissues.md index d71b51ff9..e706ecd98 100644 --- a/input/pagecontent/knownissues.md +++ b/input/pagecontent/knownissues.md @@ -12,7 +12,7 @@ The current version of the implementation guide does not impose IHE MPD profiles ### Ambiguous mappings for some elements #### Medicinal product name -Medication resource does not have an explicit element for medicinal product's name. In countries where medication information is distributed as a code system, *de facto* element for holding the medication name has been Medication.code.text or Medication.code.coding.display. This is also the recommendations by HL7 Pharmacy. +Medication resource does not have an explicit element for medicinal product's name. In countries where medication information is distributed as a code system, *de facto* element for holding the medication name has been Medication.code.text or Medication.code.coding.display. This is also the recommendation from HL7 Pharmacy. However, analysis of extensions in national implementation guides showed that many countries prefer to extend Medication resource in order to include an explicit element for the name. It is also evident, that countries often add multiple codings to the .code element, which makes it difficult to understand which of the codings display the official name of the product. Therefore, this IG includes a simple extension for the authorised medicinal product name. National implementations are not required to use the extension when their functional requirements are covered by .code element. @@ -22,7 +22,7 @@ In national implementations, two different approaches are used for capturing the - MedicationDispense.location - pharmacy is indicated using Location resource. - MedicationDispense.performer.actor - PractitionerRole as performer is expected to indicate the pharmacy as an Organization. -This implementation guide does not yet take a stance on which approach should be preferred. Additional input from countries is welcome during the ballots. +This implementation guide does not yet take a stance on which approach should be preferred. Additional input from countries is welcome. #### Medication identifier vs code diff --git a/input/pagecontent/modelmap.xml b/input/pagecontent/modelmap.xml index 88ae367f5..e31a07301 100644 --- a/input/pagecontent/modelmap.xml +++ b/input/pagecontent/modelmap.xml @@ -22,17 +22,13 @@ administrative concepts. This Implementation Guide provides HL7 FHIR profiles that realise those models.

-

- The sections below group the EHDS logical models into categories. -

-

Each table shows:

+

The table shows:

  • the logical model
  • the FHIR datatype or profile(s) used in this IG
  • a link to the detailed element-by-element mapping
-

- 💊 Medication Models

+

Medication Models

@@ -107,11 +103,10 @@
-

- 🧩 Other Models used by this guide

+

Other Models used by this guide

The implementation guide references profiles and models that are not specific for prescription and dispense. - Mapping details for such models are published in theHL7 Europe Base and Core FHIR IG. + Mapping details for such models are published in the HL7 Europe Base and Core FHIR IG.

diff --git a/temp_render.txt b/temp_render.txt new file mode 100644 index 000000000..0f84085f6 --- /dev/null +++ b/temp_render.txt @@ -0,0 +1 @@ +ENOENT: no such file or directory, stat 'C:\Users\rutt_\Documents\HL7-EU\mpd\"' From 24a70faf10eb6a408eca5d6a97d3ea81a7bba903 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Mon, 11 May 2026 01:26:59 +0300 Subject: [PATCH 7/8] proof-reading, scripts --- _build.bat | 120 +++++------ _build.sh | 204 +++++++++++------- .../multiitem-prescription-r4.plantuml | 100 --------- .../multiitem-prescription.plantuml | 2 +- ig-src/input/pagecontent/background.md | 2 +- ...notes.liquid.md => implementationnotes.md} | 28 +-- igs/mpd-r5/FHIR-eu-mpd-r5.xml | 83 +++++++ .../multiitem-prescription-r4.plantuml | 100 --------- .../multiitem-prescription.plantuml | 2 +- igs/mpd-r5/input/pagecontent/background.md | 2 +- .../input/pagecontent/implementationnotes.md | 113 ++++++++++ .../multiitem-prescription-r4.plantuml | 100 --------- .../multiitem-prescription.plantuml | 2 +- input/pagecontent/background.md | 2 +- input/pagecontent/implementationnotes.md | 113 ++++++++++ 15 files changed, 509 insertions(+), 464 deletions(-) delete mode 100644 ig-src/input/images-source/multiitem-prescription-r4.plantuml rename input/images-source/multiitem-prescription-r5.plantuml => ig-src/input/images-source/multiitem-prescription.plantuml (99%) rename ig-src/input/pagecontent/{implementationnotes.liquid.md => implementationnotes.md} (78%) create mode 100644 igs/mpd-r5/FHIR-eu-mpd-r5.xml delete mode 100644 igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml rename ig-src/input/images-source/multiitem-prescription-r5.plantuml => igs/mpd-r5/input/images-source/multiitem-prescription.plantuml (99%) delete mode 100644 input/images-source/multiitem-prescription-r4.plantuml rename igs/mpd-r5/input/images-source/multiitem-prescription-r5.plantuml => input/images-source/multiitem-prescription.plantuml (99%) diff --git a/_build.bat b/_build.bat index 99d0e1f97..a78d0130c 100644 --- a/_build.bat +++ b/_build.bat @@ -25,38 +25,54 @@ IF EXIST "%input_cache_path%%publisher_jar%" ( ) ELSE ( SET "jar_location=not_found" SET "default_choice=1" + SET "default_reason=publisher not found" ECHO publisher.jar not found in input-cache or parent folder ) ) :: Handle command-line argument to bypass the menu -IF NOT "%~1"=="" ( - IF /I "%~1"=="update" SET "userChoice=1" - IF /I "%~1"=="build" SET "userChoice=2" - IF /I "%~1"=="nosushi" SET "userChoice=3" - IF /I "%~1"=="notx" SET "userChoice=4" - IF /I "%~1"=="jekyll" SET "userChoice=5" - IF /I "%~1"=="clean" SET "userChoice=6" - IF /I "%~1"=="exit" SET "userChoice=0" - GOTO executeChoice -) +:: Known first arguments select a menu option; anything else is passed through to the publisher +SET "extraArgs=" +IF "%~1"=="" GOTO showMenu +IF /I "%~1"=="update" SET "userChoice=1" & GOTO parseExtra +IF /I "%~1"=="build" SET "userChoice=2" & GOTO parseExtra +IF /I "%~1"=="nosushi" SET "userChoice=3" & GOTO parseExtra +IF /I "%~1"=="notx" SET "userChoice=4" & GOTO parseExtra +IF /I "%~1"=="jekyll" SET "userChoice=5" & GOTO parseExtra +IF /I "%~1"=="clean" SET "userChoice=6" & GOTO parseExtra +IF /I "%~1"=="exit" SET "userChoice=0" & GOTO parseExtra +:: Unknown first arg - default to build, pass all args through +SET "userChoice=2" +GOTO collectArgs +:parseExtra +SHIFT +:collectArgs +IF "%~1"=="" GOTO executeChoice +SET "extraArgs=!extraArgs! %1" +SHIFT +GOTO collectArgs +:showMenu echo --------------------------------------------------------------- ECHO Checking internet connection... PING tx.fhir.org -4 -n 1 -w 4000 >nul 2>&1 && SET "online_status=true" || SET "online_status=false" IF "%online_status%"=="true" ( - ECHO We're online and tx.fhir.org is available. + ECHO We are online and tx.fhir.org is available. FOR /F "tokens=2 delims=:" %%a IN ('curl -s https://api.github.com/repos/HL7/fhir-ig-publisher/releases/latest ^| findstr "tag_name"') DO SET "latest_version=%%a" SET "latest_version=!latest_version:"=!" SET "latest_version=!latest_version: =!" SET "latest_version=!latest_version:~0,-1!" ) ELSE ( - ECHO We're offline or tx.fhir.org is not available, can only run the publisher without TX... + ECHO. + ECHO *** WARNING: Working offline - this is not the normal mode. + ECHO Some features including terminology rendering will not work. + ECHO. SET "txoption=-tx n/a" SET "latest_version=unknown" SET "default_choice=4" + SET "default_reason=working offline" ) echo --------------------------------------------------------------- @@ -74,14 +90,16 @@ IF NOT "%jar_location%"=="not_found" ( ECHO Publisher version: !publisher_version!; Latest is !latest_version! IF NOT "%online_status%"=="true" ( - ECHO We're offline. + ECHO We are offline. ) ELSE ( IF NOT "!publisher_version!"=="!latest_version!" ( ECHO An update is recommended. SET "default_choice=1" + SET "default_reason=newer version available" ) ELSE ( ECHO Publisher is up to date. SET "default_choice=2" + SET "default_reason=publisher is up to date" ) ) @@ -96,12 +114,9 @@ echo 4. Build IG - force no TX server echo 5. Jekyll build echo 6. Clean up temp directories echo 0. Exit -:: echo [Press Enter for default (%default_choice%) or type an option number:] echo. -:: Using CHOICE to handle input with timeout -:: ECHO [Enter=Continue, 1-7=Option, 0=Exit] -choice /C 12345670 /N /CS /D %default_choice% /T 5 /M "Choose an option number or wait 5 seconds for default (%default_choice%):" +choice /C 12345670 /N /CS /D %default_choice% /T 5 /M "Choose an option number or wait 5 seconds for default (%default_choice% - %default_reason%):" SET "userChoice=%ERRORLEVEL%" @@ -115,15 +130,12 @@ IF "%userChoice%"=="4" GOTO publish_notx IF "%userChoice%"=="5" GOTO debugjekyll IF "%userChoice%"=="6" GOTO clean IF "%userChoice%"=="0" EXIT /B - -:end - - +GOTO endscript :debugjekyll echo Running Jekyll build... jekyll build -s temp/pages -d output -GOTO end +GOTO endscript :clean @@ -152,10 +164,7 @@ GOTO end echo Removed: .\template ) -GOTO end - - - +GOTO endscript :downloadpublisher @@ -198,7 +207,7 @@ IF DEFINED FORCE ( GOTO download ) -IF "%skipPrompts%"=="y" ( +IF "%skipPrompts%"=="true" ( SET create=Y ) ELSE ( SET /p create="Download? (Y/N) " @@ -211,7 +220,7 @@ IF /I "%create%"=="Y" ( GOTO done :upgrade -IF "%skipPrompts%"=="y" ( +IF "%skipPrompts%"=="true" ( SET overwrite=Y ) ELSE ( SET /p overwrite="Overwrite %jarlocation%? (Y/N) " @@ -265,7 +274,7 @@ GOTO done ECHO. ECHO Updating scripts -IF "%skipPrompts%"=="y" ( +IF "%skipPrompts%"=="true" ( SET updateScripts=Y ) ELSE ( SET /p updateScripts="Update scripts? (Y/N) " @@ -273,7 +282,7 @@ IF "%skipPrompts%"=="y" ( IF /I "%updateScripts%"=="Y" ( GOTO scripts ) -GOTO end +GOTO endscript :scripts @@ -299,12 +308,12 @@ ECHO Updating _build.bat call POWERSHELL -command if ('System.Net.WebClient' -as [type]) {(new-object System.Net.WebClient).DownloadFile(\"%build_bat_url%\",\"_build.new.bat\") } else { Invoke-WebRequest -Uri "%build_bat_url%" -Outfile "_build.new.bat" } if %ERRORLEVEL% == 0 goto upd_script_2 echo "Errors encountered during download: %errorlevel%" -goto end +goto endscript :upd_script_2 start copy /y "_build.new.bat" "_build.bat" ^&^& del "_build.new.bat" ^&^& exit -GOTO end +GOTO endscript :publish_once @@ -312,14 +321,15 @@ GOTO end SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 :: Debugging statements before running publisher -ECHO 1jar_location is: %jar_location% +ECHO jar_location is: %jar_location% IF NOT "%jar_location%"=="not_found" ( - java %JAVA_OPTS% -jar "%jar_location%" -ig . %txoption% %* + ECHO IG Publisher FOUND, Publishing... + java %JAVA_OPTS% -jar "%jar_location%" -ig . %txoption% %extraArgs% ) ELSE ( - ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run _updatePublisher. Aborting... + ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run the script and update the publisher. Aborting... ) -GOTO end +GOTO endscript @@ -328,14 +338,14 @@ GOTO end SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 :: Debugging statements before running publisher -ECHO 3jar_location is: %jar_location% +ECHO jar_location is: %jar_location% IF NOT "%jar_location%"=="not_found" ( - java %JAVA_OPTS% -jar "%jar_location%" -ig . %txoption% -no-sushi %* + java %JAVA_OPTS% -jar "%jar_location%" -ig . %txoption% -no-sushi %extraArgs% ) ELSE ( - ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run _updatePublisher. Aborting... + ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run the script and update the publisher. Aborting... ) -GOTO end +GOTO endscript :publish_notx @@ -344,43 +354,33 @@ SET txoption=-tx n/a SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 :: Debugging statements before running publisher -ECHO 2jar_location is: %jar_location% +ECHO jar_location is: %jar_location% IF NOT "%jar_location%"=="not_found" ( - java %JAVA_OPTS% -jar "%jar_location%" -ig . %txoption% %* + java %JAVA_OPTS% -jar "%jar_location%" -ig . %txoption% %extraArgs% ) ELSE ( - ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run _updatePublisher. Aborting... + ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run the script and update the publisher. Aborting... ) -GOTO end - - +GOTO endscript :publish_continuous SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 -:: Debugging statements before running publisher -ECHO Checking %input_cache_path% for publisher.jar -IF EXIST "%input_cache_path%\%publisher_jar%" ( - java %JAVA_OPTS% -jar "%input_cache_path%\%publisher_jar%" -ig . %txoption% -watch %* +ECHO jar_location is: %jar_location% +IF NOT "%jar_location%"=="not_found" ( + java %JAVA_OPTS% -jar "%jar_location%" -ig . %txoption% -watch %extraArgs% ) ELSE ( - ECHO Checking %upper_path% for publisher.jar - IF EXIST "..\%publisher_jar%" ( - java %JAVA_OPTS% -jar "..\%publisher_jar%" -ig . %txoption% -watch %* - ) ELSE ( - ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run _updatePublisher. Aborting... - ) + ECHO IG Publisher NOT FOUND in input-cache or parent folder. Please run the script and update the publisher. Aborting... ) -GOTO end +GOTO endscript -:end +:endscript :: Pausing at the end - - IF NOT "%skipPrompts%"=="true" ( PAUSE ) diff --git a/_build.sh b/_build.sh index f11edff67..69ac585cf 100644 --- a/_build.sh +++ b/_build.sh @@ -26,20 +26,44 @@ function check_jar_location() { } function check_internet_connection() { - if ping -c 1 tx.fhir.org &>/dev/null; then + local target="tx.fhir.org" + local reachable=false + + if command -v ping > /dev/null 2>&1; then + if ping -c 1 -W 5 "$target" > /dev/null 2>&1 \ + || ping -c 1 -w 5 "$target" > /dev/null 2>&1; then + reachable=true + fi + elif command -v curl > /dev/null 2>&1; then + if curl --silent --max-time 5 --output /dev/null "https://$target"; then + reachable=true + fi + else + echo "WARNING: Neither ping nor curl available — assuming offline." + fi + + if [ "$reachable" = "true" ]; then online=true - echo "We're online and tx.fhir.org is available." + echo "We're online and $target is available." latest_version=$(curl -s https://api.github.com/repos/HL7/fhir-ig-publisher/releases/latest | grep tag_name | cut -d'"' -f4) else online=false - echo "We're offline or tx.fhir.org is unavailable." + echo "" + echo "⚠️ WARNING: Working offline — this is not the normal mode." + echo " Some features (e.g. terminology rendering) will not work." + echo "" fi } + function update_publisher() { echo "Publisher jar location: ${input_cache_path}${publisher_jar}" - read -p "Download or update publisher.jar? (Y/N): " confirm + if [ "$skipPrompts" = "true" ]; then + confirm="Y" + else + read -p "Download or update publisher.jar? (Y/N): " confirm + fi if [[ "$confirm" =~ ^[Yy]$ ]]; then echo "Downloading latest publisher.jar (~200 MB)..." mkdir -p "$input_cache_path" @@ -53,7 +77,11 @@ function update_publisher() { function update_scripts_prompt() { - read -p "Update scripts (_build.bat and _build.sh)? (Y/N): " update_confirm + if [ "$skipPrompts" = "true" ]; then + update_confirm="Y" + else + read -p "Update scripts (_build.bat and _build.sh)? (Y/N): " update_confirm + fi if [[ "$update_confirm" =~ ^[Yy]$ ]]; then echo "Updating scripts..." curl -L "$build_bat_url" -o "_build.new.bat" && mv "_build.new.bat" "_build.bat" @@ -66,33 +94,35 @@ function update_scripts_prompt() { } -function build_ig() { +function run_publisher() { + local extra_flags=("$@") if [ "$jar_location" != "not_found" ]; then - args=() - if [ "$online" = "false" ]; then - args+=("-tx" "n/a") - fi - java -Dfile.encoding=UTF-8 -jar "$jar_location" -ig . "${args[@]}" "$@" + echo "jar_location is: $jar_location" + export JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8" + java $JAVA_OPTS -jar "$jar_location" -ig . "${extra_flags[@]}" else - echo "publisher.jar not found. Please run update." + echo "IG Publisher NOT FOUND in input-cache or parent folder. Please run update. Aborting..." fi } +function build_ig() { + local args=() + if [ "$online" = "false" ]; then + args+=("-tx" "n/a") + fi + run_publisher "${args[@]}" "$@" +} function build_nosushi() { - if [ "$jar_location" != "not_found" ]; then - java -Dfile.encoding=UTF-8 -jar "$jar_location" -ig . -no-sushi "$@" - else - echo "publisher.jar not found. Please run update." - fi + run_publisher -no-sushi "$@" } function build_notx() { - if [ "$jar_location" != "not_found" ]; then - java -Dfile.encoding=UTF-8 -jar "$jar_location" -ig . -tx n/a "$@" - else - echo "publisher.jar not found. Please run update." - fi + run_publisher -tx n/a "$@" +} + +function build_continuous() { + run_publisher -watch "$@" } function jekyll_build() { @@ -113,64 +143,78 @@ function cleanup() { } check_jar_location -check_internet_connection -# Handle command-line argument or menu -case "$1" in - update) update_publisher ;; - build) build_ig ;; - nosushi) build_nosushi ;; - notx) build_notx ;; - jekyll) jekyll_build ;; - clean) cleanup ;; - exit) exit 0 ;; - *) - # Compute default choice - default_choice=2 # Build by default - - if [ "$jar_location" = "not_found" ]; then - default_choice=1 # Download if jar is missing - elif [ "$online" = "false" ]; then - default_choice=4 # Offline build - elif [ -n "$latest_version" ]; then - current_version=$(java -jar "$jar_location" -v 2>/dev/null | tr -d '\r') - if [ "$current_version" != "$latest_version" ]; then - default_choice=1 # Offer update if newer version exists - fi - fi - - echo "---------------------------------------------" - echo "Publisher: ${current_version:-unknown}; Latest: ${latest_version:-unknown}" - echo "Publisher location: $jar_location" - echo "Online: $online" - echo "---------------------------------------------" - echo - echo "Please select an option:" - echo "1) Download or update publisher" - echo "2) Build IG" - echo "3) Build IG without Sushi" - echo "4) Build IG without TX server" - echo "5) Jekyll build" - echo "6) Cleanup temp directories" - echo "0) Exit" - echo - - # Read with timeout, but default if nothing entered - echo -n "Choose an option [default: $default_choice]: " - read -t 5 choice || choice="$default_choice" - choice="${choice:-$default_choice}" - echo "You selected: $choice" - - case "$choice" in - 1) update_publisher ;; - 2) build_ig ;; - 3) build_nosushi ;; - 4) build_notx ;; - 5) jekyll_build ;; - 6) cleanup ;; - 0) exit 0 ;; - *) echo "Invalid option." ;; - esac - ;; +# Handle command-line arguments +# Known first arguments select a menu option; anything else is passed through to the publisher +extraArgs=() +if [ $# -gt 0 ]; then + case "$1" in + update) shift; extraArgs=("$@"); update_publisher; exit 0 ;; + build) shift; extraArgs=("$@"); check_internet_connection; build_ig "${extraArgs[@]}"; exit 0 ;; + nosushi) shift; extraArgs=("$@"); check_internet_connection; build_nosushi "${extraArgs[@]}"; exit 0 ;; + notx) shift; extraArgs=("$@"); build_notx "${extraArgs[@]}"; exit 0 ;; + jekyll) jekyll_build; exit 0 ;; + clean) cleanup; exit 0 ;; + exit) exit 0 ;; + *) + # Unknown first arg - default to build, pass all args through + extraArgs=("$@") + run_publisher "${extraArgs[@]}" + exit 0 + ;; + esac +fi + +# Interactive menu +check_internet_connection +# Compute default choice and reason +default_choice=2 +default_reason="publisher is up to date" + +if [ "$jar_location" = "not_found" ]; then + default_choice=1 + default_reason="publisher not found" +elif [ "$online" = "false" ]; then + default_choice=4 + default_reason="working offline" +elif [ -n "$latest_version" ]; then + current_version=$(java -jar "$jar_location" -v 2>/dev/null | tr -d '\r') + if [ "$current_version" != "$latest_version" ]; then + default_choice=1 + default_reason="newer version available" + fi +fi + +echo "---------------------------------------------" +echo "Publisher: ${current_version:-unknown}; Latest: ${latest_version:-unknown}" +echo "Publisher location: $jar_location" +echo "Online: $online" +echo "---------------------------------------------" +echo +echo "Please select an option:" +echo "1) Download or update publisher" +echo "2) Build IG" +echo "3) Build IG without Sushi" +echo "4) Build IG without TX server" +echo "5) Jekyll build" +echo "6) Cleanup temp directories" +echo "0) Exit" +echo + +# Read with timeout, but default if nothing entered +echo -n "Choose an option [default: $default_choice - $default_reason]: " +read -t 5 choice || choice="$default_choice" +choice="${choice:-$default_choice}" +echo "You selected: $choice" + +case "$choice" in + 1) update_publisher ;; + 2) build_ig ;; + 3) build_nosushi ;; + 4) build_notx ;; + 5) jekyll_build ;; + 6) cleanup ;; + 0) exit 0 ;; + *) echo "Invalid option." ;; esac diff --git a/ig-src/input/images-source/multiitem-prescription-r4.plantuml b/ig-src/input/images-source/multiitem-prescription-r4.plantuml deleted file mode 100644 index b5f5af3c1..000000000 --- a/ig-src/input/images-source/multiitem-prescription-r4.plantuml +++ /dev/null @@ -1,100 +0,0 @@ -@startuml - -'skinparam linetype ortho -skinparam linetype polyline -hide circle -hide stereotype - -'!pragma layout smetana - -skinparam class<> { - BorderColor DarkSlateGray - BackgroundColor TECHNOLOGY - HeaderBackgroundColor #7b8 -} - -skinparam class<> { - BorderColor #909050 - BackgroundColor BUSINESS - HeaderBackgroundColor #dd4 -} - -skinparam class<> { - BorderColor #505090 - BackgroundColor APPLICATION - HeaderBackgroundColor #8bd -} - - - -class "**Prescription**" as P<> { - -- - |_ identifier = Pr1 - |_ issued = 12.12.2024 - |_ patient = Patient1 - |_ prescriber = Prescriber1 - |_ item - |_ itemIdentifier = MR1 - |_ medication = Med1 - |_ dosage = Dose1 - |_ item - |_ itemIdentifier = MR2 - |_ medication = Med2 - |_ dosage = Dose2 - -- -} - - -class "**MedicationRequest 1**" as MR1<> { - -- - |_ identifier = MR1 - |_ groupIdentifier = Pr1 - |_ intent = option - |_ subject = Patient1 - |_ requester = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ medication = Med1 - |_ dosageInstruction = Dose1 - -- -} - -class "**MedicationRequest 2**" as MR2<> { - -- - |_ identifier = MR2 - |_ groupIdentifier = Pr1 - |_ intent = option - |_ subject = Patient1 - |_ requester = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ medication = Med2 - |_ dosageInstruction = Dose2 - -- -} - -class "**RequestGroup**" as RO<> { - -- - |_ identifier - |_ groupIdentifier - |_ intent = order - |_ subject = Patient1 - |_ author = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ action - |_ resource MR1 - |_ relatedAction MR2 - |_ action - |_ resource MR2 - |_ relatedAction MR1 - -- -} - - -P -d- RO: " " -P -d- MR1: " " -P -d- MR2: " " -RO -l-> MR1: "reference" -RO -r-> MR2: "reference" - - - -@enduml diff --git a/input/images-source/multiitem-prescription-r5.plantuml b/ig-src/input/images-source/multiitem-prescription.plantuml similarity index 99% rename from input/images-source/multiitem-prescription-r5.plantuml rename to ig-src/input/images-source/multiitem-prescription.plantuml index 1362a90cc..ea8fe070d 100644 --- a/input/images-source/multiitem-prescription-r5.plantuml +++ b/ig-src/input/images-source/multiitem-prescription.plantuml @@ -97,4 +97,4 @@ RO -r-> MR2: "reference" -@enduml +@enduml \ No newline at end of file diff --git a/ig-src/input/pagecontent/background.md b/ig-src/input/pagecontent/background.md index 4213fc09d..2509a8485 100644 --- a/ig-src/input/pagecontent/background.md +++ b/ig-src/input/pagecontent/background.md @@ -22,4 +22,4 @@ According to the regulation, technical specifications for data exchange (EEHRxF This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. More restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. -While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. \ No newline at end of file +While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. diff --git a/ig-src/input/pagecontent/implementationnotes.liquid.md b/ig-src/input/pagecontent/implementationnotes.md similarity index 78% rename from ig-src/input/pagecontent/implementationnotes.liquid.md rename to ig-src/input/pagecontent/implementationnotes.md index 7a557b4b3..88331294f 100644 --- a/ig-src/input/pagecontent/implementationnotes.liquid.md +++ b/ig-src/input/pagecontent/implementationnotes.md @@ -50,44 +50,36 @@ This option differs from the previous one by one important aspect: the data elem - No way to show interdependencies between individual items/requests - The status of the prescription has to be the same or calculable from individual prescription items -#### Option 3: Using {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} +#### Option 3: Using RequestOrchestration/RequestGroup -This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration resource and exchanging individual MedicationRequests. +This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. RequestOrchestration (R5) or RequestGroup (R4) resource shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that RequestOrchestration/RequestGroup is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration/RequestGroup resource and exchanging individual MedicationRequests. **Pros:** - Possible to define interdependencies between prescription items. - Multi-item prescription is clearly defined and distinguishable from single-item prescriptions. **Cons:** -- Multiitem prescription and single-item prescription are handled differently. In a prescription system where multi-item prescriptions use RequestOrchestration, it is important to consider whether single-item prescriptions should be using the same mechanism, even though it does not add anything to the semantics. -- Receiving systems outside the ecosystem are likely to drop the {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} resource when it's not explicitly supported in their implementation. +- Multiitem prescription and single-item prescription are handled differently. In a prescription system where multi-item prescriptions use RequestOrchestration/RequestGroup, it is important to consider whether single-item prescriptions should be using the same mechanism, even though it does not add anything to the semantics. +- Receiving systems outside the ecosystem are likely to drop the RequestOrchestration/RequestGroup resource when it's not explicitly supported in their implementation. -When grouping MedicationRequests with a {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %}: +When grouping MedicationRequests with a RequestOrchestration/RequestGroup: - MedicationRequest.intent value must be ‘option’. This is a signal to the receiver, that the request must be handled as part of a bigger request group. -- The element that binds MedicationRequest and {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. +- The element that binds MedicationRequest and RequestOrchestration/RequestGroup together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. - The prescription identifier should be the value of .groupIdentifier. - MedicationRequests, if they originate from the same prescription, should have the same patient and authoring metadata. The following diagram explains the process of splitting a custom multi-item prescription (yellow) into HL7 FHIR resources (green). -{% if isR5 %}
- {% include multiitem-prescription-r5.svg %} + {% include multiitem-prescription.svg %}
-{% endif %} -{% if isR4 %} -
- {% include multiitem-prescription-r4.svg %} - -
-{% endif %}
-Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %}, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. +Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using RequestOrchestration/RequestGroup, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. -Read more about using {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} in FHIR workflow pages. +Read more about using RequestOrchestration/RequestGroup in FHIR workflow pages. ### Prescription statuses and workflow @@ -97,7 +89,7 @@ MedicationRequest has a very limited set of statuses available for use. This is Prescription and dispensation systems often use additional or different statuses, and those statuses are not directly mappable to MedicationRequest.status. Some of these prescription statuses may actually be related to the dispense rather than the request, so the semantically correct place for some statuses would actually be MedicationDispense.status. Some simple workflows may choose to make use of the .meta.tag 'actionable' to indicate whether the request is dispensable or simply for information. -For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional {% if isR5 %}RequestOrchestration{% endif %}{% if isR4 %}RequestGroup{% endif %} resource should be used. +For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional RequestOrchestration/RequestGroup resource should be used. Workflows are typically implementation-specific and the aim of this implementation guide is not to provide one solution for everyone. Practice of using prescription and dispensation statuses varies a lot across countries and use cases (e.g. hospital use vs community pharmacy). While it is important for each implementation to map their business statuses to FHIR MedicationRequest.status values, the usage of Task and building a workflow will not be restricted by this implementation guide. diff --git a/igs/mpd-r5/FHIR-eu-mpd-r5.xml b/igs/mpd-r5/FHIR-eu-mpd-r5.xml new file mode 100644 index 000000000..8cd73f940 --- /dev/null +++ b/igs/mpd-r5/FHIR-eu-mpd-r5.xml @@ -0,0 +1,83 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml b/igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml deleted file mode 100644 index b5f5af3c1..000000000 --- a/igs/mpd-r5/input/images-source/multiitem-prescription-r4.plantuml +++ /dev/null @@ -1,100 +0,0 @@ -@startuml - -'skinparam linetype ortho -skinparam linetype polyline -hide circle -hide stereotype - -'!pragma layout smetana - -skinparam class<> { - BorderColor DarkSlateGray - BackgroundColor TECHNOLOGY - HeaderBackgroundColor #7b8 -} - -skinparam class<> { - BorderColor #909050 - BackgroundColor BUSINESS - HeaderBackgroundColor #dd4 -} - -skinparam class<> { - BorderColor #505090 - BackgroundColor APPLICATION - HeaderBackgroundColor #8bd -} - - - -class "**Prescription**" as P<> { - -- - |_ identifier = Pr1 - |_ issued = 12.12.2024 - |_ patient = Patient1 - |_ prescriber = Prescriber1 - |_ item - |_ itemIdentifier = MR1 - |_ medication = Med1 - |_ dosage = Dose1 - |_ item - |_ itemIdentifier = MR2 - |_ medication = Med2 - |_ dosage = Dose2 - -- -} - - -class "**MedicationRequest 1**" as MR1<> { - -- - |_ identifier = MR1 - |_ groupIdentifier = Pr1 - |_ intent = option - |_ subject = Patient1 - |_ requester = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ medication = Med1 - |_ dosageInstruction = Dose1 - -- -} - -class "**MedicationRequest 2**" as MR2<> { - -- - |_ identifier = MR2 - |_ groupIdentifier = Pr1 - |_ intent = option - |_ subject = Patient1 - |_ requester = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ medication = Med2 - |_ dosageInstruction = Dose2 - -- -} - -class "**RequestGroup**" as RO<> { - -- - |_ identifier - |_ groupIdentifier - |_ intent = order - |_ subject = Patient1 - |_ author = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ action - |_ resource MR1 - |_ relatedAction MR2 - |_ action - |_ resource MR2 - |_ relatedAction MR1 - -- -} - - -P -d- RO: " " -P -d- MR1: " " -P -d- MR2: " " -RO -l-> MR1: "reference" -RO -r-> MR2: "reference" - - - -@enduml diff --git a/ig-src/input/images-source/multiitem-prescription-r5.plantuml b/igs/mpd-r5/input/images-source/multiitem-prescription.plantuml similarity index 99% rename from ig-src/input/images-source/multiitem-prescription-r5.plantuml rename to igs/mpd-r5/input/images-source/multiitem-prescription.plantuml index 1362a90cc..ea8fe070d 100644 --- a/ig-src/input/images-source/multiitem-prescription-r5.plantuml +++ b/igs/mpd-r5/input/images-source/multiitem-prescription.plantuml @@ -97,4 +97,4 @@ RO -r-> MR2: "reference" -@enduml +@enduml \ No newline at end of file diff --git a/igs/mpd-r5/input/pagecontent/background.md b/igs/mpd-r5/input/pagecontent/background.md index 4213fc09d..2509a8485 100644 --- a/igs/mpd-r5/input/pagecontent/background.md +++ b/igs/mpd-r5/input/pagecontent/background.md @@ -22,4 +22,4 @@ According to the regulation, technical specifications for data exchange (EEHRxF This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. More restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. -While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. \ No newline at end of file +While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. diff --git a/igs/mpd-r5/input/pagecontent/implementationnotes.md b/igs/mpd-r5/input/pagecontent/implementationnotes.md index e69de29bb..88331294f 100644 --- a/igs/mpd-r5/input/pagecontent/implementationnotes.md +++ b/igs/mpd-r5/input/pagecontent/implementationnotes.md @@ -0,0 +1,113 @@ +### Prescription - document or request approach + +Prescription has historically been a document that authorises one or multiple requests. In FHIR, there is no explicit resource for Prescription, and it is possible to focus on the document aspect or the request aspect. Some countries have preferred to keep the document view using Bundle with Composition. This IG does not encourage nor ban this approach, but there is no profile for document Bundle in the IG. + +Examples in this IG use collection Bundle simply for making it easier to read for the humans. Many implementers use transaction Bundle for creating new prescriptions as it allows assigning server-side IDs more easily. + +The choice of wrapping the request and its related resources in a Bundle or not, is entirely up to the implementers. + + +### Multi-item prescriptions + +Systems are not required to support multi-item prescriptions in order to be compliant with this implementation guide. + +The recommended way of designing prescriptions in HL7 FHIR is to have one item per prescription. This is reflected in the MedicationRequest resource where the Medication cardinality is 1..1. Currently, the European crossborder prescription CDA implementation also allows only one medication per prescription, expecting the country of origin to split a multi-item prescription into several crossborder prescriptions and track the dispensations accordingly. However, real life national prescription systems are often designed differently from this logic; in many countries a prescription may contain more than one medication item. + +There is no single mechanism in HL7 FHIR for handling multi-item prescriptions. To choose the optimal solution, one must consider the business requirements and reasons behind a multi-item prescription: +- Is it used merely as a grouping mechanism without deeper semantics? +- Are there technical reasons why multiple items must be transported as one group? +- Are the items on prescription related to each other through the dosing scheme? +- Must the items be dispensed as one transaction? +- Are there pricing or reimbursement rules that are dependent on grouping? +- How does the status of a prescription relate to the statuses of individual requests? +- What are the consequences of adding or removing prescription items: can a single-item prescription become a multi-item prescription and vice versa? + +Considering the requirements above, the best match from the following approaches can be chosen. + +#### Option 1: No grouping + +This option can only be used when the items on a prescription can be easily split and dispensed separately. The information about which prescription the items belong to is handled outside FHIR services. + +**Pros:** +- Technically the easiest option to implement in FHIR. +- Allows the same handling of data for single- and multi-item prescriptions. + +**Cons:** +- The prescription identifier is not present +- The complexity of matching the items and prescriptions does not disappear, but is pushed to the prescription/dispensing systems. +- Only applicable when individual items have no interdependencies. + +#### Option 2: Using .groupIdentifier + +This option differs from the previous one by one important aspect: the data element .groupIdentifier is filled with the prescription identifier. This allows linking different prescription items within FHIR services, but it does not provide any extra information about the prescription or interdependencies between different items on the same prescription. Systems that do not support multi-item prescriptions may ignore the groupIdentifier element and leave it unprocessed. + +**Pros:** +- Easy to implement +- Allows very similar handling of data for single- and multi-item prescriptions +- .groupIdentifier preserves the prescription identifier. + +**Cons:** +- No way to show interdependencies between individual items/requests +- The status of the prescription has to be the same or calculable from individual prescription items + +#### Option 3: Using RequestOrchestration/RequestGroup + +This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. RequestOrchestration (R5) or RequestGroup (R4) resource shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that RequestOrchestration/RequestGroup is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration/RequestGroup resource and exchanging individual MedicationRequests. + +**Pros:** +- Possible to define interdependencies between prescription items. +- Multi-item prescription is clearly defined and distinguishable from single-item prescriptions. + +**Cons:** +- Multiitem prescription and single-item prescription are handled differently. In a prescription system where multi-item prescriptions use RequestOrchestration/RequestGroup, it is important to consider whether single-item prescriptions should be using the same mechanism, even though it does not add anything to the semantics. +- Receiving systems outside the ecosystem are likely to drop the RequestOrchestration/RequestGroup resource when it's not explicitly supported in their implementation. + +When grouping MedicationRequests with a RequestOrchestration/RequestGroup: +- MedicationRequest.intent value must be ‘option’. This is a signal to the receiver, that the request must be handled as part of a bigger request group. +- The element that binds MedicationRequest and RequestOrchestration/RequestGroup together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. +- The prescription identifier should be the value of .groupIdentifier. +- MedicationRequests, if they originate from the same prescription, should have the same patient and authoring metadata. + +The following diagram explains the process of splitting a custom multi-item prescription (yellow) into HL7 FHIR resources (green). + +
+ {% include multiitem-prescription.svg %} + +
+ +
+ +Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using RequestOrchestration/RequestGroup, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. + +Read more about using RequestOrchestration/RequestGroup in FHIR workflow pages. + + +### Prescription statuses and workflow + +MedicationRequest has a very limited set of statuses available for use. This is a deliberate design choice to improve interoperability across different settings. + +Prescription and dispensation systems often use additional or different statuses, and those statuses are not directly mappable to MedicationRequest.status. Some of these prescription statuses may actually be related to the dispense rather than the request, so the semantically correct place for some statuses would actually be MedicationDispense.status. + +Some simple workflows may choose to make use of the .meta.tag 'actionable' to indicate whether the request is dispensable or simply for information. +For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional RequestOrchestration/RequestGroup resource should be used. + +Workflows are typically implementation-specific and the aim of this implementation guide is not to provide one solution for everyone. Practice of using prescription and dispensation statuses varies a lot across countries and use cases (e.g. hospital use vs community pharmacy). While it is important for each implementation to map their business statuses to FHIR MedicationRequest.status values, the usage of Task and building a workflow will not be restricted by this implementation guide. + +HL7 guidance materials for designing request workflows: +- [Workflow](https://hl7.org/fhir/workflow.html) +- [Workflow module](https://hl7.org/fhir/workflow-module.html) +- [Additional explanations - WIP](https://confluence.hl7.org/pages/viewpage.action?pageId=248715046) + + +### Medication: identifier, code, classification + +In the case of medications, the distinction between .identifier and .code is not always clear, and practices for using these elements vary across countries. This implementation guide allows the use of the .identifier element for non-instance identifiers, such as IDMP identifiers or product codes from a national product registry or the EMA PMS. + +A product code is typically used when the source of the data is distributed as a code system. This may include SNOMED CT, a national drug extension, or any local code system supporting prescribing and dispensing use cases. It is common to prescribe products at the virtual product level and dispense them at the branded product package level. The source system for virtual products may differ from the source system for branded products. + +The implementation guide introduces an extension for classification and recommends using it for ATC as well as for any local classifications relevant to the use case. In several countries, ATC is also known to be added to the .code element as an additional coding. This practice is not prohibited by the implementation guide. However, implementations must be able to distinguish the actual prescribed concept from classification codes to remove potential ambiguities in cross-border settings. + +### Data absent reason + +This implementation guide does not use data absent reason extensions in profiles. +Handling missing data is explained in [HL7 Europe Base and Core FHIR Implementation Guide](https://hl7.eu/fhir/base/missing-data.html). \ No newline at end of file diff --git a/input/images-source/multiitem-prescription-r4.plantuml b/input/images-source/multiitem-prescription-r4.plantuml deleted file mode 100644 index b5f5af3c1..000000000 --- a/input/images-source/multiitem-prescription-r4.plantuml +++ /dev/null @@ -1,100 +0,0 @@ -@startuml - -'skinparam linetype ortho -skinparam linetype polyline -hide circle -hide stereotype - -'!pragma layout smetana - -skinparam class<> { - BorderColor DarkSlateGray - BackgroundColor TECHNOLOGY - HeaderBackgroundColor #7b8 -} - -skinparam class<> { - BorderColor #909050 - BackgroundColor BUSINESS - HeaderBackgroundColor #dd4 -} - -skinparam class<> { - BorderColor #505090 - BackgroundColor APPLICATION - HeaderBackgroundColor #8bd -} - - - -class "**Prescription**" as P<> { - -- - |_ identifier = Pr1 - |_ issued = 12.12.2024 - |_ patient = Patient1 - |_ prescriber = Prescriber1 - |_ item - |_ itemIdentifier = MR1 - |_ medication = Med1 - |_ dosage = Dose1 - |_ item - |_ itemIdentifier = MR2 - |_ medication = Med2 - |_ dosage = Dose2 - -- -} - - -class "**MedicationRequest 1**" as MR1<> { - -- - |_ identifier = MR1 - |_ groupIdentifier = Pr1 - |_ intent = option - |_ subject = Patient1 - |_ requester = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ medication = Med1 - |_ dosageInstruction = Dose1 - -- -} - -class "**MedicationRequest 2**" as MR2<> { - -- - |_ identifier = MR2 - |_ groupIdentifier = Pr1 - |_ intent = option - |_ subject = Patient1 - |_ requester = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ medication = Med2 - |_ dosageInstruction = Dose2 - -- -} - -class "**RequestGroup**" as RO<> { - -- - |_ identifier - |_ groupIdentifier - |_ intent = order - |_ subject = Patient1 - |_ author = Prescriber1 - |_ authoredOn = 12.12.2024 - |_ action - |_ resource MR1 - |_ relatedAction MR2 - |_ action - |_ resource MR2 - |_ relatedAction MR1 - -- -} - - -P -d- RO: " " -P -d- MR1: " " -P -d- MR2: " " -RO -l-> MR1: "reference" -RO -r-> MR2: "reference" - - - -@enduml diff --git a/igs/mpd-r5/input/images-source/multiitem-prescription-r5.plantuml b/input/images-source/multiitem-prescription.plantuml similarity index 99% rename from igs/mpd-r5/input/images-source/multiitem-prescription-r5.plantuml rename to input/images-source/multiitem-prescription.plantuml index 1362a90cc..ea8fe070d 100644 --- a/igs/mpd-r5/input/images-source/multiitem-prescription-r5.plantuml +++ b/input/images-source/multiitem-prescription.plantuml @@ -97,4 +97,4 @@ RO -r-> MR2: "reference" -@enduml +@enduml \ No newline at end of file diff --git a/input/pagecontent/background.md b/input/pagecontent/background.md index 4213fc09d..2509a8485 100644 --- a/input/pagecontent/background.md +++ b/input/pagecontent/background.md @@ -22,4 +22,4 @@ According to the regulation, technical specifications for data exchange (EEHRxF This implementation guide serves as the less restricted specification, suitable for adapting for national use cases. More restricted specification for crossborder data exchange may be derived from this implementation guide. National contact points are responsible for transformation when needed. -While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. \ No newline at end of file +While the owner of the EHDS specifications will be the European Commission, the current IG is the result of cooperation among different EU projects working on the preparation and implementation of EHDS specifications. The requirements are likely to change slightly in the final implementing act of Article 15, which will trigger a revision of this implementation guide. diff --git a/input/pagecontent/implementationnotes.md b/input/pagecontent/implementationnotes.md index e69de29bb..88331294f 100644 --- a/input/pagecontent/implementationnotes.md +++ b/input/pagecontent/implementationnotes.md @@ -0,0 +1,113 @@ +### Prescription - document or request approach + +Prescription has historically been a document that authorises one or multiple requests. In FHIR, there is no explicit resource for Prescription, and it is possible to focus on the document aspect or the request aspect. Some countries have preferred to keep the document view using Bundle with Composition. This IG does not encourage nor ban this approach, but there is no profile for document Bundle in the IG. + +Examples in this IG use collection Bundle simply for making it easier to read for the humans. Many implementers use transaction Bundle for creating new prescriptions as it allows assigning server-side IDs more easily. + +The choice of wrapping the request and its related resources in a Bundle or not, is entirely up to the implementers. + + +### Multi-item prescriptions + +Systems are not required to support multi-item prescriptions in order to be compliant with this implementation guide. + +The recommended way of designing prescriptions in HL7 FHIR is to have one item per prescription. This is reflected in the MedicationRequest resource where the Medication cardinality is 1..1. Currently, the European crossborder prescription CDA implementation also allows only one medication per prescription, expecting the country of origin to split a multi-item prescription into several crossborder prescriptions and track the dispensations accordingly. However, real life national prescription systems are often designed differently from this logic; in many countries a prescription may contain more than one medication item. + +There is no single mechanism in HL7 FHIR for handling multi-item prescriptions. To choose the optimal solution, one must consider the business requirements and reasons behind a multi-item prescription: +- Is it used merely as a grouping mechanism without deeper semantics? +- Are there technical reasons why multiple items must be transported as one group? +- Are the items on prescription related to each other through the dosing scheme? +- Must the items be dispensed as one transaction? +- Are there pricing or reimbursement rules that are dependent on grouping? +- How does the status of a prescription relate to the statuses of individual requests? +- What are the consequences of adding or removing prescription items: can a single-item prescription become a multi-item prescription and vice versa? + +Considering the requirements above, the best match from the following approaches can be chosen. + +#### Option 1: No grouping + +This option can only be used when the items on a prescription can be easily split and dispensed separately. The information about which prescription the items belong to is handled outside FHIR services. + +**Pros:** +- Technically the easiest option to implement in FHIR. +- Allows the same handling of data for single- and multi-item prescriptions. + +**Cons:** +- The prescription identifier is not present +- The complexity of matching the items and prescriptions does not disappear, but is pushed to the prescription/dispensing systems. +- Only applicable when individual items have no interdependencies. + +#### Option 2: Using .groupIdentifier + +This option differs from the previous one by one important aspect: the data element .groupIdentifier is filled with the prescription identifier. This allows linking different prescription items within FHIR services, but it does not provide any extra information about the prescription or interdependencies between different items on the same prescription. Systems that do not support multi-item prescriptions may ignore the groupIdentifier element and leave it unprocessed. + +**Pros:** +- Easy to implement +- Allows very similar handling of data for single- and multi-item prescriptions +- .groupIdentifier preserves the prescription identifier. + +**Cons:** +- No way to show interdependencies between individual items/requests +- The status of the prescription has to be the same or calculable from individual prescription items + +#### Option 3: Using RequestOrchestration/RequestGroup + +This option is technically more complex to handle on the FHIR side, but it allows communication of the interdependencies of different items on a prescription. Every prescription item uses the MedicationRequest resource just like in the first two options. However, an additional resource is populated to provide extra information about the semantics of grouping the items on the same prescription. RequestOrchestration (R5) or RequestGroup (R4) resource shares the same .groupIdentifier as the MedicationRequests that are linked to it. However, note that RequestOrchestration/RequestGroup is not semantically the prescription, but only a part of it. Even with this approach, there is no single resource for the prescription object as such. When exchanging this kind of prescription with another system, simplification may be needed: removing the RequestOrchestration/RequestGroup resource and exchanging individual MedicationRequests. + +**Pros:** +- Possible to define interdependencies between prescription items. +- Multi-item prescription is clearly defined and distinguishable from single-item prescriptions. + +**Cons:** +- Multiitem prescription and single-item prescription are handled differently. In a prescription system where multi-item prescriptions use RequestOrchestration/RequestGroup, it is important to consider whether single-item prescriptions should be using the same mechanism, even though it does not add anything to the semantics. +- Receiving systems outside the ecosystem are likely to drop the RequestOrchestration/RequestGroup resource when it's not explicitly supported in their implementation. + +When grouping MedicationRequests with a RequestOrchestration/RequestGroup: +- MedicationRequest.intent value must be ‘option’. This is a signal to the receiver, that the request must be handled as part of a bigger request group. +- The element that binds MedicationRequest and RequestOrchestration/RequestGroup together is .groupIdentifier. By sharing the same .groupIdentifier value, they indicate that they are a part of the same prescription document. +- The prescription identifier should be the value of .groupIdentifier. +- MedicationRequests, if they originate from the same prescription, should have the same patient and authoring metadata. + +The following diagram explains the process of splitting a custom multi-item prescription (yellow) into HL7 FHIR resources (green). + +
+ {% include multiitem-prescription.svg %} + +
+ +
+ +Please see examples [**100A**](Bundle-100A-multiitem-prescription-with-orchestration.html) and [**300A**](Bundle-300A-multiitem-prescription-with-orchestration.html) in the [Artifacts page](artifacts.html) for more information about how to create a multi-item prescription using RequestOrchestration/RequestGroup, and example [**200A**](Bundle-200A-multiitem-prescription-without-orchestration.html) for information about how to create a multi-item prescription without an additional grouping/organising resource. All examples in this IG use Bundle as a wrapper for multi-item prescription, however this is just for the convenience, and not a normative part of this IG. Implementers can choose whether to use Bundle or which type of Bundle to use. + +Read more about using RequestOrchestration/RequestGroup in FHIR workflow pages. + + +### Prescription statuses and workflow + +MedicationRequest has a very limited set of statuses available for use. This is a deliberate design choice to improve interoperability across different settings. + +Prescription and dispensation systems often use additional or different statuses, and those statuses are not directly mappable to MedicationRequest.status. Some of these prescription statuses may actually be related to the dispense rather than the request, so the semantically correct place for some statuses would actually be MedicationDispense.status. + +Some simple workflows may choose to make use of the .meta.tag 'actionable' to indicate whether the request is dispensable or simply for information. +For more sophisticated workflows, especially when FHIR messaging is the basis of the workflow, Task resource should be used in addition to MedicationRequest and MedicationDispense. For group request, an additional RequestOrchestration/RequestGroup resource should be used. + +Workflows are typically implementation-specific and the aim of this implementation guide is not to provide one solution for everyone. Practice of using prescription and dispensation statuses varies a lot across countries and use cases (e.g. hospital use vs community pharmacy). While it is important for each implementation to map their business statuses to FHIR MedicationRequest.status values, the usage of Task and building a workflow will not be restricted by this implementation guide. + +HL7 guidance materials for designing request workflows: +- [Workflow](https://hl7.org/fhir/workflow.html) +- [Workflow module](https://hl7.org/fhir/workflow-module.html) +- [Additional explanations - WIP](https://confluence.hl7.org/pages/viewpage.action?pageId=248715046) + + +### Medication: identifier, code, classification + +In the case of medications, the distinction between .identifier and .code is not always clear, and practices for using these elements vary across countries. This implementation guide allows the use of the .identifier element for non-instance identifiers, such as IDMP identifiers or product codes from a national product registry or the EMA PMS. + +A product code is typically used when the source of the data is distributed as a code system. This may include SNOMED CT, a national drug extension, or any local code system supporting prescribing and dispensing use cases. It is common to prescribe products at the virtual product level and dispense them at the branded product package level. The source system for virtual products may differ from the source system for branded products. + +The implementation guide introduces an extension for classification and recommends using it for ATC as well as for any local classifications relevant to the use case. In several countries, ATC is also known to be added to the .code element as an additional coding. This practice is not prohibited by the implementation guide. However, implementations must be able to distinguish the actual prescribed concept from classification codes to remove potential ambiguities in cross-border settings. + +### Data absent reason + +This implementation guide does not use data absent reason extensions in profiles. +Handling missing data is explained in [HL7 Europe Base and Core FHIR Implementation Guide](https://hl7.eu/fhir/base/missing-data.html). \ No newline at end of file From 81776385462a2c49a463c4757b014d0e92e1ee8c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rutt=20Lindstr=C3=B6m?= Date: Mon, 11 May 2026 11:57:35 +0300 Subject: [PATCH 8/8] artifacts grouping --- ig-src/input/pagecontent/index.md | 2 +- ig-src/sushi-config.liquid.yaml | 14 ++++++++++++++ igs/mpd-r5/input/pagecontent/index.md | 2 +- igs/mpd-r5/sushi-config.yaml | 14 ++++++++++++++ input/pagecontent/index.md | 2 +- sushi-config.yaml | 14 ++++++++++++++ 6 files changed, 45 insertions(+), 3 deletions(-) diff --git a/ig-src/input/pagecontent/index.md b/ig-src/input/pagecontent/index.md index fdfc235ee..3c020f4c7 100644 --- a/ig-src/input/pagecontent/index.md +++ b/ig-src/input/pagecontent/index.md @@ -28,7 +28,7 @@ ### Scope -The scope of this implementation guide is **Medication Prescription and Dispense** in the **European** Context. +The scope of this implementation guide is **Medication Prescription and Dispense** in the **European** context. It is coherent with the [European eHN Guidelines](https://health.ec.europa.eu/ehealth-digital-health-and-care/key-documents_en) and preparatory EHDS work. This implementation guide is designed to be a flexible basis for national specifications as well as crossborder services. diff --git a/ig-src/sushi-config.liquid.yaml b/ig-src/sushi-config.liquid.yaml index d4b40a77c..6c0452254 100644 --- a/ig-src/sushi-config.liquid.yaml +++ b/ig-src/sushi-config.liquid.yaml @@ -256,6 +256,20 @@ groups: - MedicationRequestEuMpd - MedicationDispenseEuMpd - MedicationEuMpd + + DataTypes: + name: Data Type Profiles + description: Profiles for the data types used in the Implementation Guide. + resources: + - DosageEuMpd + + ActorDefinitions: + name: Actor Definitions + description: Instances defining the actors to whom the data level obligations apply. + resources: + - ActorDefinition/actor-producer + + # ModelMaps: # name: Mappings from eHN Data Sets # description: These concept maps represent a high-level mapping from eHN guidelines data sets and FHIR profiles in this IG. Please note that mappings from EHDS logical models are provided on [Logical models page](logicalmodels.html). diff --git a/igs/mpd-r5/input/pagecontent/index.md b/igs/mpd-r5/input/pagecontent/index.md index fdfc235ee..3c020f4c7 100644 --- a/igs/mpd-r5/input/pagecontent/index.md +++ b/igs/mpd-r5/input/pagecontent/index.md @@ -28,7 +28,7 @@ ### Scope -The scope of this implementation guide is **Medication Prescription and Dispense** in the **European** Context. +The scope of this implementation guide is **Medication Prescription and Dispense** in the **European** context. It is coherent with the [European eHN Guidelines](https://health.ec.europa.eu/ehealth-digital-health-and-care/key-documents_en) and preparatory EHDS work. This implementation guide is designed to be a flexible basis for national specifications as well as crossborder services. diff --git a/igs/mpd-r5/sushi-config.yaml b/igs/mpd-r5/sushi-config.yaml index be20778c4..8e581aa9f 100644 --- a/igs/mpd-r5/sushi-config.yaml +++ b/igs/mpd-r5/sushi-config.yaml @@ -239,6 +239,20 @@ groups: - MedicationRequestEuMpd - MedicationDispenseEuMpd - MedicationEuMpd + + DataTypes: + name: Data Type Profiles + description: Profiles for the data types used in the Implementation Guide. + resources: + - DosageEuMpd + + ActorDefinitions: + name: Actor Definitions + description: Instances defining the actors to whom the data level obligations apply. + resources: + - ActorDefinition/actor-producer + + # ModelMaps: # name: Mappings from eHN Data Sets # description: These concept maps represent a high-level mapping from eHN guidelines data sets and FHIR profiles in this IG. Please note that mappings from EHDS logical models are provided on [Logical models page](logicalmodels.html). diff --git a/input/pagecontent/index.md b/input/pagecontent/index.md index fdfc235ee..3c020f4c7 100644 --- a/input/pagecontent/index.md +++ b/input/pagecontent/index.md @@ -28,7 +28,7 @@ ### Scope -The scope of this implementation guide is **Medication Prescription and Dispense** in the **European** Context. +The scope of this implementation guide is **Medication Prescription and Dispense** in the **European** context. It is coherent with the [European eHN Guidelines](https://health.ec.europa.eu/ehealth-digital-health-and-care/key-documents_en) and preparatory EHDS work. This implementation guide is designed to be a flexible basis for national specifications as well as crossborder services. diff --git a/sushi-config.yaml b/sushi-config.yaml index 0576cfe56..344cd425d 100644 --- a/sushi-config.yaml +++ b/sushi-config.yaml @@ -244,6 +244,20 @@ groups: - MedicationRequestEuMpd - MedicationDispenseEuMpd - MedicationEuMpd + + DataTypes: + name: Data Type Profiles + description: Profiles for the data types used in the Implementation Guide. + resources: + - DosageEuMpd + + ActorDefinitions: + name: Actor Definitions + description: Instances defining the actors to whom the data level obligations apply. + resources: + - ActorDefinition/actor-producer + + # ModelMaps: # name: Mappings from eHN Data Sets # description: These concept maps represent a high-level mapping from eHN guidelines data sets and FHIR profiles in this IG. Please note that mappings from EHDS logical models are provided on [Logical models page](logicalmodels.html).