Your browser does not appear to support JavaScript. You may want to try one of the following:
You may want to try one of the following:
If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:
shift
control
Show details
Hide details
This form has to be reloaded. This most likely happened because your session has expired, which might take to the login page. (If you think that you shouldn't see this message and that the problem persists, please contact support.)
The eHealth Digital Service Infrastructure (eHDSI or eHealth DSI) is the initial deployment and operation of services for cross-border health data exchange under the Connecting Europe Facility (CEF). eHDSI sets up and starts deploying the core and generic services, as defined in the CEF, for Patient Summary and ePrescription. The generic services are the necessary implementation of data exchange at country level, the core services at EU level. These together enable the provision of Cross Border eHealth Information Services (CBeHIS).
This project was initially started as the epSOS Large Scale Pilot, where a first version of the CDA implementation guides were created. The transcription to ART-DECOR of the normative master specification for epSOS was originally done by the Dutch National IT Institute for Health Care (Nictiz) end of 2013 / beginning of 2014 as part of an official agreementbetween the epSOS project and Nictiz.The specification as of now is the result of a review of the original epSOS specification. This was done within the EXPAND project WP5, before moving the specification to CEG. The activity was supported by HL7 International /HL7 International Foundation / HL7 Europe. The eHDSI project uses the CDA Implementation Guides of EXPAND asa base for further development.
The CDA IGs of the epSOS project are still available: https://art-decor.org/art-decor/decor-project--epsos-. No active development is done on this project, that served as a base for the eHDSI CDA IGs.
Within the eHDSI project, three main use cases are defined:
Release notes of the CDA Implementation guides can be found at the following location: https://webgate.ec.europa.eu/fpfis/wikis/x/9AVoNg
The value sets that are used inside the project are combined in a master value set catalogue (MVC): https://webgate.ec.europa.eu/fpfis/wikis/x/8gNoNg
The Central Terminology Server (CTS) is a set of components used for the representation, access, and maintenance of the terminology content of the electronic documents exchanged within eHealth Digital Service Infrastructure (eHDSI). The CTS aims at supporting the Member States in coordinating their terminology efforts. More information on the CTS can be found in Confluence: https://webgate.ec.europa.eu/fpfis/wikis/x/PgJoNg
- New Value Sets needed to present the rare disease scenarios are to be created in the MVC for Wave 6. These new value sets need to be bound in the dedicated template definitions and the value sets need to be loaded in ART-DECOR. Link to JIRA Issue: https://citnet.tech.ec.europa.eu/CITnet/jira/browse/EHEALTH-9607 Suggestion:
-
- During the generation of the IHE CDA validators based on the CDA IG v5.0.0 release it was discovered that the GOC had difficulties with the expressions of the where clauses (https://gazelle.ihe.net/jira/servicedesk/customer/portal/24/DGSANTE-116).
This lead to the discussion whether it makes clinically sense to keep the cardinality of the hl7:value element to unbounded.
After discussions with Semantic expert and STF Arch WG leader, it was decided that this is a typo from the past and it can be restricted to 1.
This makes it possible for IHE to generate the validators on a short term.
- Change the cardinality of the hl7:value element to from [0..*] to [0..1]
- Link to corresponding JIRA issue: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-1131
- We noticed that there is an issue in the examples provided for the effectiveTime elements. If you use the examples in your CDA documents as specified, validation will not pass.
xsi:type must be used instead of just type:
wrong:
// twice a day <effectiveTime type="PIVL_TS" institutionSpecified="true"> <period value="12" unit="h"/> </effectiveTime>
correct:
// twice a day <effectiveTime xsi:type="PIVL_TS" institutionSpecified="true"> <period value="12" unit="h"/> </effectiveTime>
- Modify the attributes
- Current description is not describing the element correctly:
- We propose: Based on the eHN Guidelines:
Date on which the woman is due to give birth. Year, month and day are required. If unknown nullFlavor has to be provided.
- Corresponding JIRA issue: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-511
- In order to facilitate the life for the implementers, additional documentation must be provided for certain elements in ART-DECOR.
This Jira issue is to address the most easy ones for which there is currently no description.
The former EXPAND specifications, the CDA standard and CEN HL7 IPS CDA IGs can serve as inspiration.
Link to ART-DECOR issue: https://ec.europa.eu/cefdigital/tracker/projects/EHSEMANTIC/issues/EHSEMANTIC-512
- Add descriptions
- During the gap analysis of the CEN IPS vs eHDSI CDA IGs, it was noticed that the hl7:name element has a conformance of R (required). This allows us to set it to a nullFlavor value. According to Giorgio CANGIOLI it is a type and it should be changed to M (mandatory) since the given and family subelements are mandatory and have to be filled in according to the specifications.
- Change conformance from R to M
- Link to JIRA issue: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-454
- Since the OID of the Problem template has been changed, also the reference to the Problem template has to be adapted with the new OID.Link to JIRA issue: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-415
- Add descriptions to strength and package size to reflect CP -25Link to JIRA issue: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-414
- After an issue I created in the IHE Jira ( https://gazelle.ihe.net/jira/servicedesk/customer/portal/24/DGSANTE-32 ) the conclusion by Kai is the following:
The element 116 Expected date of Delivery links either to the whole observation (a general approach) or to the hl7:value element, not to the hl7:code element in this case
The latter is recommended.
You may link a single data element to different template elements.
So the data-element linkage can be altered.
- Remove the linkage between epsos-dataelement-116 and hl7:code from the template
- Link to issue in JIRA: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-428
- At the moment the description is not aligned with the IHE ITI Technical Framework revision 9Link with JIRA issue: https://ec.europa.eu/cefdigital/tracker/projects/EHSEMANTIC/issues/EHSEMANTIC-430
- Since the migration of the art décor server from the art-decor infrastructure towards the commission servers, the e-mail notification doesn't work anymore.
In the semantic F2F meeting on 13/11, it was agreed upon to change the template status of the two templates to 'retired'. Like this we don't lose them and they are still there, but they are filtered out in the overview.
If we don't receive any feedback to reactivate them in the coming 2 years, we can delete them.
- We noticed there is no binding in the CDA IG to the epSOSAllergenNoDrugs value set.
Within the Allergies And Intolerances section, we have the participant that is the allergen - the substance that caused the allergy.
Within the CDA template, this info can be found in the participantRole/participantEntity code element
- Add the binding and modify the cardinality/conformance to 1 .. 1 /R
- A lot of confusion about this element in the preparation of the February test event. An issue has been created in JIRA: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-381
- Comment proposed by Konstantin HYPPÖNEN
The description of field Number of Packages is the following: The supply entry should indicate the quantity supplied (such as tablets or containers). The value attribute shall be present and indicates the quantity of medication supplied. If the medication is supplied in dosing units (tablets or capsules), then the unit attribute need not be present (and should be set to 1 if present). Otherwise, the unit element shall be present to indicate the quantity (e.g., volume or mass) of medication supplied.
feedback from Christof GESSNER absent information means "1"
- From the CDA book:
Do Not Use the schemaLocation Attribute
While the XML Schema Language allows a schema location to be associated with an XML
document by including a schemaLocation attribute associated with the http://www.
w3.org/2001/XMLSchema-instance namespace, this is explicitly PROHIBITED
by [ITS§1.4], and thus by the CDA standard.
Systems validating a CDA document are expected to provide their own schemas to use
during validation. This rule is sometimes broken by CDA implementers. Applications
receiving CDA documents should at the very least REMOVE the schemaLocation
attribute
from the document before processing it, if not rejecting documents containing
them completely. Downloading schema resources from arbitrary URLs or file locations for
validation can at the very least slow down your system, and could crash it or even worse,
cause a security breach. I have seen a number of different systems crash at testing events
upon seeing an otherwise valid CDA document containing a schemaLocation attribute
pointing to a file that does not exist. Suggestion:
- Add a schematron rule to avoid the use of the schemaLocation attribute. Has to be added to every CDA Document Level Template.JIRA issue has been created for this: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-385
- From the functional requirements, the family/first name of a patient is mandatory. But if in ART-DECOR the parent element (name) allows a nullFlavor, there is the possibility to have a valid CDA document without providing the family/first name of a patient.
- Change the conformance from R to M
- For reasons of consistency with other telecom elements, restrict the nullFlavor value of the assignedAuthor element to "NI". It is also specified like this in the Expand documentation.
- Restrict nullFlavor value of assignedAuthor to "NI"
- At this moment, the CDA NumberOfPackages template has an epSOS OID and was created for reuse. However, this template doesn't have a templateID
- At the templateID for this template
- We noticed that, although ART-DECOR states that the attributes are optional, the XSD states that it's mandatory. The schema error is correct, as the attribute is required as per W3C schema (and that makes sense for the classCode). Therefore you MUST specify this in the template as 1..1, either fixed or with a value set of valid class codes. Suggestion:
- Change the cardinality from 0 .. 1 to 1 .. 1
- From the discussion with dr. Christof Gessner: If we look into the expand documentation, we noticed that the formCode has to have cardinality 1 .. 1 and conformance R for ePrescription and eDispensation. However, for PatientSummary, the formCode has to have cardinality 0 .. 1 and be optional. Since this template is reused in all document templates (eP, eD, PS) we should make the element optional.This won't have any impact on the document validation, since eP/eD messages will still be valid (there is just the relaxation of the constraint)
- Make the element optional.
- In ART-DECOR, we have two attribute values defined for the upper epsos:ingredient element: @classCode and @determinerCode with both fixed values. But when we add these attributes as defined in ART-DECOR, we have XSD schema validation errors. The @determinerCode should be removed from ART-DECOR (this is also in line with the EXPAND documentation)
- Remove the @determinerCode attribute with it's fixed value from the epsos:ingredient element
- The prescription ID must be the same as the prescription ID defined in the document header (document ID).
- Rename the template http://art-decor.org/art-decor/decor-templates--epsos-?id=2.16.840.1.113883.3.1937.777.11.10.144 “epSOS Related Prescription Item” to “eHealth DSI Related Prescription”
- In the asContent element we see the following description: This structure describes the packaging of the medication. The element provides the code for the particular package. But if we go into the formCode, we have the freedom to choose from the epSOSDoseForm value set OR the epSOSPackage value set. In my opinion, the Pharmaceutical dose form has to come into the formCode element under the manufacturedMaterial level and the formCode element under the /asContent/containerPackageMedicine can only contain values from the epSOSPackage value set
- Remove the possibility to have a value from the 2 value sets.
- We received a question from Heiko Zimmermann: The "value" element, shouldn't it be with a cardinality 1..1 instead of 0..* ? as it is mentioned that it shall be given. Is a max "*" cardinality really useful in practice? I had a look in the IHE PCC templates: https://art-decor.ihe-europe.net/art-decor/decor-templates--IHE-PCC-?id=1.3.6.1.4.1.19376.1.5.3.1.4.6
In this template the cardinality of the value element is 1 … *:
I don't know if these this template is something official we can rely on (I guess it's based on this pdf document: http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf since the ART-DÉCOR references the paragraph in this document)?
From the pdf document:
6.3.4.15.5 <value xsi:type='CD' code=' ' codeSystem=' ' codeSystemName=' ' displayName=' '>
The <value> is a description of the allergy or adverse reaction. While the value may be a coded or an uncoded string, the type is always a coded value (xsi:type='CD'). If coded, the code and codeSystem attributes must be present. The codingSystem should reference a controlled vocabulary describing allergies and adverse reactions, see Table 5.4 12 above. If uncoded, all attributes other than xsi:type='CD' must be absent. The allergy or intolerance may not be known, 5570 in which case that fact shall be recorded appropriately. This might occur in the case where a patient experiences an allergic reaction to an unknown substance.
In the pdf we don't have any indication about the cardinality.
BUT, if the IHE PCC has a minimum cardinality of 1 and our template has a minimum cardinality of 0, it means we are not compatible with the IHE PCC templates, since omitting the value will provide a valid document according to the ehDSI specifications, but will be an invalid document according to the IHE PCC templates.
- Change the cardinality from 0 ... * to 1 ... 1 or at least 0 ... 1
- This template is a subtype of the Problem Entry, and so must also confirm to the rules of the problem entry, which has the template identifier of 1.3.6.1.4.1.19376.1.5.3.1.4.5. This is an OID from the IHE PCC that is duplicated by an eHDSI template. But from the description, I understand that the templateId is referring to the IHE PCC Problem Entry. There the hl7:id and hl7:text are 1 … 1 M. Then I don't see why the hl7:id and hl7:text are 0 … * R and 1 … 1 R .
- Lets make this template compatible with the IHE PCC Problem template and change the cardinality and conformance
- added the templateId element
- Can't edit template. Error message says: Template locked User Oliver Egger 2017-11-27
There is an inconsistency between the specification with OID 1.3.6.1.4.1.19376.1.5.3.1.4.3.1 in the older EXPAND documentation (where the implementation guides were written in paper) where the old validator was based upon and the current ART-DÉCOR definitions.
- Change to moodCode=INT
- I checked the PDF documentation, the parent template from IHE PCC 1.3.6.1.4.1.19376.1.5.3.1.4.3.1, and the C-CDA template 2.16.840.1.113883.10.20.1.43
(see https://art-decor.ihe-europe.net/art-decor/decor-templates--IHE-PCC-?id=1.3.6.1.4.1.19376.1.5.3.1.4.3.1 )
Also see IHE PCC TF2 6.3.4.8.4: <act classCode='ACT' moodCode='INT'>The related statement is the intent (moodCode='INT') on how the related entry is to be performed.
- no fixed value for inversion Ind
- fixed inversionInd value true, according to IHE PCC 1.3.6.1.4.1.19376.1.5.3.1.4.7, and epsos PDF specification
We noticed that the same OIDs are used in ART-DECOR for defining different templates. This originates from the older implementation guide definitions in the EXPAND period and is a known issue for some time.The majority of conflicts arises from re-using templates from IHE PCC in epSOS, but with additional constraints.I compared the list of templates in epsos: http://art-decor.org/art-decor/decor-template-ids--epsos-with the IHE PCC templates: https://art-decor.ihe-europe.net/art-decor/decor-template-ids--IHE-PCC- I tried to list the templates where the OID is reused in epSOS:
Change the OIDs. To what OIDs has to be discussed and maybe the change has to occur by a change request.
- Some previously available constructs are missing:
- outcome of gap analysis of Abderrazek: consumable/manufacturedProduct/manufacturedMaterial/name required. In Expand the Cardinality is for the element is: (eP/eD/PS: R/NA/NA).
- Change the cardinality from 0 ... 1 to 1 ... 1
- telecom @use is required, but should be optional, according to text.
- change cardinality to 0...1 (as in other occurences of telecom)
- to be changed from UNK to NI
The current specs requires that all the IHE PCC (simple obs ad socila Obs) and the CCD template IDs are provided .
IHE PCC template just says that "These <templateId> elements identify this as a Social History observation." without indicating any optionality.
Evaluate if is really needed that all of them would be required.
This applies to several other templates
the conceptual model consider only three types of social observation:
Alcohol
Evaluate if we need to specialize the IHE PCC template considering three different specialized template for each of them
in the case of diet a coded element is excpected in the obs.value , but the epSSO MVC doesn't define such a type of value set
This is a known issue. No Value set have been identified for describing autonomy/invalidity
- The LOINC code used here signifies a document, not a section. Furthermore, it asks for specification of {setting} and {Author Type}. Not sure if this is appropriate code here.
- Check for alternative, possibly request new code from LOINC
Only a few concepts in associated value set Obs.code
In the future a value set should contain much more concepts, see e.g. ELGA_Vitalparameterarten 1.2.40.0.34.10.34
According to CP#8 the optionality R/R/RFNA shall be read as RNFA / RNFA / RNFA
Update the work document consequently
Update Specialty cardinality to 0..1 (table in § 10.1)
-realmCode is Mandatory
-change to 0..1 R
-is Mandatory
--change to 0..1 R
-is mandatory
-validation fails for multiple effectiveTime instances. But epSOS requires two instances, at least in some cases. Note: this will probably be fixed by epsos-issue-101.
- add more specific information on occurrence, like effectiveTime[1], effectiveTime[2] etc.
- EffectiveTime of ServiceEvent required Low and high
- Modify template to allow for high only (without low) and also allow for TS, alternatively ("silent demotion")
The OID for the Comment Entry here is the same as for the IHE Comment Entry from PCC. You cannot use the same OID as it defines additional constraints here.
Use the IHE Comment Entry as-is (ref) or clone it with a new template ID.
To be evaluate if the value set indicated "The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.16040 EntityCode (DYNAMIC)" is here appropriate.
To describe the Preferred Health Professional for emergency contact is currently used participant/functionCode = PCP and particiapnt/associatedEntity@classCode="PRS" The usage of the classCode ECON seems to be more appropriate.
- classCode is mandatory, according to schema
- change cardinality from 0..1 to 1..1
- observation classCode is mandatory
- change cardinality to 1..1
- cardinality of entry is 0..1
- change to 0..*
- good practice is to have one entry to contain one ProblemConcernAct, containing one Problem observation.
-section allows only 0..1 entry
- It is good practice that one entry contains one Act containing one Problem. So for multiple past illnesses we need multiple entries.
- The current value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.5 does not reflect the most recent version of MVC
- should be updated to contain 4 -digit ICD codes
- Value set does not follow the updates in MVC
- Suggest to update the value set.Please clarify with Solution Provider Terminology Expert how to proceed...
- act.id is mandatory
- change to 0..1 R
- no reason to have it mandatory in base templates.
- Description doesn't make it clear that codeSystem IHEActCode (1.3. 5.1.4.1.19376.1.5.3.2) must be used, and not generic HL7 ActCode (2.16.840.1.113883.5.4)
- add text to clarify
- id cardinality is 1..1 R
- id cardinality should be 0..1 R
- is 1..1 R
- should be 0..1 R
The substance that causes the allergy or intolerance shall be specified in the <participant> structure.
The <code> element shall be present. It may contain a code and codeSystem attribute to indicate the code for the substance causing the allergy or intolerance. It shall contain a <reference> to the <originalText> in the narrative where the substance is named.
A specialized template should be defined for the <participant> structure describing the substance that causes the allergy or intolerance
The CDA standard claims"A conformant CDA document can have a single relatedDocument with typeCode "APND"; a single relatedDocument with typeCode "RPLC"; a single relatedDocument with typeCode "XFRM"; a combination of two relatedDocuments with typeCodes "XFRM" and "RPLC"; or a combination of two relatedDocuments with typeCodes "XFRM" and "APND". No other combinations are allowed."
This constraint is not captured by the current specifications. Add an explicit assertion to check this.
- cardinality of id is 0..*
- must be maximum 1. Changed it to 0..1
- cardinality of manufacturedProduct must be less or equal 1
- Changed to 0...1
- Test : CDATEMP005(Validation Level : FLATTEN_4 , Type : ERROR) Location : //rules/template[14]/element[1]/element[16]/element[1] CDALocation : /hl7:substanceAdministration[hl7:templateId/@root='1.3.6.1.4.1.12559.11.10.1.3.1.3.2']/hl7:consumable/hl7:manufacturedProduct Description : The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]
- When <let> used, it shall not contains circular references to other <let> elements [HL7TEMP-045]
- more information needed.
- effectiveTime has cardinality 1..*
-The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]
- text cardinality is 1...*
- The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]
- effectiveTime is 1..*
- substanceAdministration maximum multiplicity is *
- The cardinality of custodian telecom is 0..* here, while it is constrained to 0..1 in the CDA Spec for custodiaon Org. Moreover, ID is mandatory for Custodian organisation.
- cannot use the generic Organization template here. Adapt to additional constraints, specific for custodian organization.
- cardinality is 0..*
-Test : CDATEMP005(Validation Level : FLATTEN_4 , Type : ERROR)
- The contains statement produces a duplication of the participant element (nesting).
- replace "contains" by "include"?
- In the Template EntryAllergyAndIntolerance [1.3.6.1.4.1.19376.1.5.3.1.4.6] in ART-DECOR, the hl7:id element is not consistent with the inheritance from the template Problem [1.3.6.1.4.1.19376.1.5.3.1.4.5]
- The template EntryAllergyAndIntolerance inherit from the template Problem, the template EntryAllergyAndIntolerance says that hl7:id is 0..* , however the template Problem says that hl7:id is 1..1. This is not permitted to relax constraints.
- Change the EntryAllergyAndIntolerance template and make the id a 1 ... 1 (with a conformance M?)