This one descendants of 373873005 |Pharmaceutical / biologic product (product)| containing > 1 "Has active ingredient" relationship sounds weird. Beyond the fact that I am unsure whether there is any term server that can handle that, what's the rationale?

Possible definition could be: all descendants of 410942007 |Drug or medicament (substance)|, 116273005 |Dietary substance (substance)|, 406455002 |Allergen class (substance)|, 420111002 |Contact metal agent (substance)|, plus all descendants of 373873005 |Pharmaceutical / biologic product (product)| containing > 1 "Has active ingredient" relationship

Combined in three distict value sets

For the time being the SNOMED CT substance hierarchy has been selected. To be investigated its actual use.

Finding:

Identify a suitable value set for the allergy/intollernace agents.

Call 2016-11-30

suggested to consider the SNOMED CT terapeutic and non terapeutic substances.

Call 2016-12-05

At this stage consider substances and not products (product identifiers are rarely usable cross-jurisdictions).
mentioned code systems (SNOMED CT, ATC,...)

To be better analyzed if we should require the usage of that value set or consider it a suggested value set.

Further explanation:

-

Call 2016-12-14

No specific reasons have been identified for requiring this element.
But if used it shall be used as described by the IHE PCC templates.

Finding:

The <text> element at the entry level is required for this (and other entries) for IHE PCC (and epSOS) , optional for the C-CDA.

The text is used there as reference pointing to the narrative (the <reference> element is required).

To be agreed a common approach for this element here and for the other entries.


Suggestion:

-

Further explanation:

-

Template updated => attribute required 

Call 2016-12-14

Agreed approach: requires relationship attributes when no default value are defined.

Finding:

The attrubute @inversionInd=true is required for C-CDA; it seems instead optional for the IHE PCC.

To be agreed a common approach for handling the optionality of such a kind of attributes.

Suggestion:

-

Further explanation:

-

useful, but not essential

I was thinking about integrating the textual constraint with a check of the status reported in the [problem observation status].value.

In order to avoid to have a status active and the effectiveTime.high valued...

..but with a low priority...

I think this is a textual constraint only. How to say that in schematron (known resolved = looking into the mind of the doctor)?

Suggestion:

Consider to add a schematron assert for the constraint 
"If this condition is known to be resolved, then the effectiveTime/high would be present."

Further explanation:

-

They were actually the same template.  Templates have been updated in order to use only one (the other has been cancelled)

Finding:

There are two different templates used for the problem statuses one for the allergy and one for the problems.
Check the differences and use only one if possible.

Suggestion:

-

Further explanation:

-

Great proposal, helps understanding, great action on changing the name.

Renamed as suggested

Finding:
From François
Suggestion:

-

Further explanation:

-