datatypes updated

Will use CD.EPSOS Datatype flavor, as it exists

Finding:

the data type used is the baseline CD, in epSOS is required that the diaplsyName is provided for several coded element

Suggestion:

use a CD.epSOS datat type as done for the CE.epSOS

Further explanation:

-

Finding:

this templates is used also as specialized template in the allergy section in which is not expected that the code is used

Suggestion:

(1) correct the binding

(2) update the template invoked in the history of past illnesses in ordere to have the right value set used

Further explanation:

-

postponed after the expandathon

There are multiple possible solutions.
I agree that this problem observation should be only about illnesses and disorders. There should be created another Template for allergie reactions as this is used in a specific context only. There could be laid a relationship between the two.
Unknown Information need normally always to be handled.
While easily possible I don't think that an amalgamated value set of all three helps at all. We could however bring together unknown information and real information. Please note that the "unknown" information is modelled incorrectly here anyway.

Finding:

this binding refer three possible value sets.

Suggestion:

I suggets that specialized templates would  be used in the different context in which this template is actually used. (e..g reaction allergy, problem list)

in this case evaluate if it could be useful to introduce a value set as union of epSOSUnknownInformation and epSOSIllnessesandDisorders

Further explanation:

-

Agree, done

Finding:

If present the <entryRelationship> element used for the Severity shall have typeCode ‘SUBJ’ and inversionInd ‘true’.

Suggestion:

-

Further explanation:

-

Hi Marta, I didn't know to whom I should assign this issue. Could you re-assign? Thank you

Finding:

- observation classCode is mandatory

Suggestion:

- change cardinality to 1..1

Further explanation:

-

Finding:

- 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

Suggestion:

- should be updated to contain 4 -digit ICD codes

Further explanation:

-

Finding:

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

Suggestion:

- Change the EntryAllergyAndIntolerance template and make the id a 1 ... 1 (with a conformance M?)

Further explanation:

-

Finding:

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

Suggestion:

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

Further explanation:

-

Just from a ART-DECOR definitional and validator perspective:

There are two, and after an intermediate release next week four, vocab binding strengths:
Coded no exceptions = Required => violation will always throw an error. CNE is the default, i.e. if none is specified, CNE is assumed.
Coded with exceptions = extensible => violation will always throw an info
Preferred => violation will always throw an info
Example => violation will always throw an info

Hope this helps.

I checked with Abderrazek. He liked your change (as do I).
At the moment, the validator doesn't doesn't take the CWE/CNE into account.
Abderrazek can activate this logic (and I think it's the way to proceed)
But we have to take into account that all the value sets are CWE.
So if we activate this, it will impact the validation of the Value Sets.
I'll write it down at we can take it up in the next Test FWK: Attangement towards Formal Test Event meeting next week.

In order to remove the strict contstraint, I changed the coding-strength to CWE, after adding the codeSystem once again.
The ecpected behaviour is that the validator creates a warning now, but not an error.

Could someone please check if validators work as expected here?

Remove the constraint the the hl7:code from the Problem template has to come from the value set: 1.3.6.1.4.1.12559.11.10.1.3.1.42.23 epSOSCodeProb (Dynamic)
as agreed in the eHDSI: Test FWK: Arrangement towards Formal Test event (Jan 2017) of the 29th of November

Finding:

- At this moment we have this constraint on the hl7:code element of the Problem template, while this was not the case in the former EXPAND specifications. The problem arises when we use the 'Allergy And Intolerance' template, which is a specialization of the 'Problem' template. This also has a constraint on the hl7:code element but this time for another Value Set. Since these two constraints conflict, a solution is to relax the constraint on the hl7:code element of the Problem template

Suggestion:

- Relax the constraint on hl7:code from the Problem template to be from the value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.23 epSOSCodeProb (DYNAMIC)

Further explanation:

-