- 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

-

• For the first effectiveTime (duration of treatment): where [@xsi:type='IVL_TS']
• For the second effectiveTime (frequency of intakes): 

• where [@value or @nullFlavor]
• where  [@xsi:type='PIVL_TS']
  
• where  [@xsi:type='EIVL_TS']
  
• where  [@xsi:type='SXPR_TS']
  

- 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

- 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 -25
Link 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 9
Link with JIRA issue: https://ec.europa.eu/cefdigital/tracker/projects/EHSEMANTIC/issues/EHSEMANTIC-430

-

-

• v2.1.1
• v2.2.0

• v2.1.1
• v2.2.0

• document level template
• recordTarget template

• V2.1.1
  
• V2.2.0
  

• V2.1.1
  
• V2.2.0

• V2.1.1
  
• V2.2.0

• V2.1.1
  
• V2.2.0

• V2.1.1
  
• V2.2.0

• v2.1.1 (formal W1 release)
• v2.2.0 (formal W2 release)

• v2.1.1
• v2.2.0

• v2.1.1
• v2.2.0

• v2.1.1 (official W1 CDA IG release)
• v2.2.0 (official W2 CDA IG release)

• V2.1.1
  
• V2.2.0

• v2.1.1 (formal Wave 1 release)
• v2.2.0 (formal Wave 2 release)

• V2.2.0

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.

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

-

• specialization: we modify an existing template (in this case the IHE PCC template) and add some self-defined elements or we add some additional restrictions to existing elements (as been decided in previous project phases)
• adaptation: we use an existing template as a base but add/modify elements so that the template is not following the rules of the original template anymore.

- 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"

-

- 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 line:
  

• The line

- 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:

• 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2 - Section Coded Vital Signs
• 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.4 - Section Pregnancy History
• 1.3.6.1.4.1.19376.1.5.3.1.1.9.50 - Section Health Maintenance Care Plan
• 1.3.6.1.4.1.19376.1.5.3.1.3.6 - Section Active Problems
• 1.3.6.1.4.1.19376.1.5.3.1.3.8 - Section History of Past Illness
• 1.3.6.1.4.1.19376.1.5.3.1.3.12 - Section Coded List of Surgeries
• 1.3.6.1.4.1.19376.1.5.3.1.3.13 - Section Allergies and Other Adverse Reactions
• 1.3.6.1.4.1.19376.1.5.3.1.3.16.1 - Section Coded Social History
• 1.3.6.1.4.1.19376.1.5.3.1.3.17 - Section Functional Status
• 1.3.6.1.4.1.19376.1.5.3.1.3.23 - Section Immunizations
• 1.3.6.1.4.1.19376.1.5.3.1.4.1 - Severity
• 1.3.6.1.4.1.19376.1.5.3.1.4.1.1 - Entry Problem Status Observation
• 1.3.6.1.4.1.19376.1.5.3.1.4.1.2 - Entry Health Status Observation
• 1.3.6.1.4.1.19376.1.5.3.1.4.2 - Comment
• 1.3.6.1.4.1.19376.1.5.3.1.4.3 - epSOS Patient Medication Instructions
• 1.3.6.1.4.1.19376.1.5.3.1.4.3.1 - Entry Medication FulFillment Instructions
• 1.3.6.1.4.1.19376.1.5.3.1.4.4 - External Reference
• 1.3.6.1.4.1.19376.1.5.3.1.4.4.1 - Internal Reference
• 1.3.6.1.4.1.19376.1.5.3.1.4.5 - Problem
• 1.3.6.1.4.1.19376.1.5.3.1.4.5.2 - Problem Concern
• 1.3.6.1.4.1.19376.1.5.3.1.4.5.3 - Allergy and Intolerance Concern
• 1.3.6.1.4.1.19376.1.5.3.1.4.6 - Allergies And Intolerances
• 1.3.6.1.4.1.19376.1.5.3.1.4.7.2 - Immunization Product
• 1.3.6.1.4.1.19376.1.5.3.1.4.12 - Immunizations
• 1.3.6.1.4.1.19376.1.5.3.1.4.13 - Simple Observation
• 1.3.6.1.4.1.19376.1.5.3.1.4.13.1 - Vital Signs Organizer
• 1.3.6.1.4.1.19376.1.5.3.1.4.13.2 - Vital Signs Observation
• 1.3.6.1.4.1.19376.1.5.3.1.4.13.4 - Social History Observation
• 1.3.6.1.4.1.19376.1.5.3.1.4.13.5 - Pregnancy Observation
• 1.3.6.1.4.1.19376.1.5.3.1.4.13.6 - Blood Group
• 1.3.6.1.4.1.19376.1.5.3.1.4.19 - Procedure

Change the OIDs. To what OIDs has to be discussed and maybe the change has to occur by a change request.

-

• Conformance of Organisation changed from 1 ... 1 M to 1 ... 1 R
  
• nullFlavor fixed value for telecom element changed from 'UNK' to 'NI'

- Some previously available constructs are missing:

• Number of packages
• Patient instructions

-

-

- 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:

• Smoke

• Alcohol

• Diet

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

--change to 0..1 R

-

-is mandatory

--change to 0..1 R

-

-is Mandatory

--change to 0..1 R

-

-

-

-

-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

- change to 0..*

- 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

-

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..*

-The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]  

-

- substanceAdministration maximum multiplicity is *

- The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]  

-

- 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..*

- The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]  

-

-Test :  CDATEMP005(Validation Level : FLATTEN_4 , Type : ERROR) 

-

-

-Test :  CDATEMP005(Validation Level : FLATTEN_4 , Type : ERROR) 

-

-

-

-

-

-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?)

-