In order to make ART-DECOR create the Schematron files

In order to make ART-DECOR create the Schematron files

If we want the schematrons as intended, people _have_ to stick to the "usual" namespace prefixes like...epsos

That is what Implementation Guides typically do, e.g. see IHE

Finding:

-

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.

Suggestion:

- Change to moodCode=INT

Further explanation:

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

Finding:

- no fixed value for inversion Ind

Suggestion:

- 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

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:

-

Closed after having verified the solution with Konstantin Hyppönen.

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

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.

Finding:

- Some previously available constructs are missing:

• Number of packages
• Patient instructions

Suggestion:

-

Further explanation:

-

Finding:  

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

Suggestion:

- Change the cardinality from 0 ... 1 to 1 ... 1

Further explanation:

-

Fixed the Telecom element, but I didn't create a separate Template yet...

Finding:

- telecom @use is required, but should be optional, according to text.

Suggestion:

- change cardinality to 0...1 (as in other occurences of telecom)

Further explanation:

-

Finding:

- to be changed from UNK to NI

Suggestion:

-

Further explanation:

-

OK. I removed the contain statement.

Note that the intention to make those fields mandatory will fail if not all enclosing elements are also mandatory. Otherwise, the sender can just use a nullFlavor on one of the enclosing levels.

Changed according to requirement R1.10.8 in the EXPAND documentation

Added the constraint

I processed the changes

To be considered for Next MVC version

Modified the binding for the /ClinicalDocument/participant/associatedEntity/code 

this value set is bound to   CDA.participant.AssociatedEntity.classCode

used in the telecom/@use attribute

Any analysis about the dataset is deferred

Changed the status code description for SubstaceAdministration

HCER and MRO are not priority for the time being (not part of the guidelines)

Data set element should be revised accoridng to the EU guidelines

Added the specification text to the comment field of the parent data element container

No value set binding needed at this point in time.

Mentioned HP Specialty is sufficient for now. Not value set binding necessary.

This is handled by the AD.EPSOS specialization of the AD datatype

No fix required for the DECOR template.

Checked

Finding:

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.

Suggestion:

Evaluate if is really needed that all of them would be required.

Further explanation:

This applies to several other templates

removed the not used elements

Finding:

the conceptual model consider only three types of social observation:

• Smoke

• Alcohol

• Diet

Suggestion:

Evaluate if we need to specialize the IHE PCC template considering three different specialized template for each of them

Further explanation:

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

versions of the IHE TFs have been updated

I support this. id is mandatory in IHE template, but this does not make sense here (changed it to 0..1 R).

Removed the binding 

the approachSiteCode seems to be no more in the template...assumed closed

doseQuantity is now only one element with data type RTO_PQ_PQ

Element removed

removed the "duplicated" relationship with product

manufacturerOrganization element eliminated

Solved by loading the latest MVC version 2.2.2

Template ID updated

IHE 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.5 actually reauires section.id

the actual optionality of this template id is not well specified neither in the IHE PCC nor in the epSOS specs.

The schematron published by IHE requires this element for the IHE PCC template. Change the cardinality from 0..1 to 1..1

Section revised

Reviewed Templates and pending issues, added a few new issues.
Revision is closed.

duplicated item

This was definitely entered/defined in error. doseQuantity is now a IVL_PQ as defined in the generic CDA.

Finding:

This is a known issue. No Value set have been identified for describing autonomy/invalidity

Suggestion:

-

Further explanation:

-

changed to required

added new value set and binding

Fixed

Added negationInd isOptional=true

datatypes updated

Agree, done

Agree, done

statusCode shall be present in all cases and values "completed" due to the underlying (derived from) specifications; Changes in the templates.

data type changed to CD.EPSOS

Done

The Template's business name and display name has been set accordingly

In case to be reconsidered for future discussion

entry changed to 1..* R

This an optional section used to say i know she is pregnant. Up to now all the oter cases has been managed skipping the section.

The way to manage negations, not known information need to be faced more widely. 

The code is thus declared to be mandatory 1..1 M, ie no null flavors are allowed. That is correct in spec and ART-DECOR.

The phrase "the code should come from this list" equals to a binding to the value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.9 epSOSPregnancyInformation (Dynamic) with CWE coding strength (coded with exceptions), saying that if a concept fits one of the codes in the value set this code must be used, otherwise other codes may be used (from other code systems).

Changed codings strength to CWE

Then the spec needs to be corrected.
M means no null flavors are allowed (mandatory). This is in principal equal to SHALL.
R means null flavors are allowed (required).
Null Flavors should be allowed here for sure.

Changed to 1..1 R

Finding:

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

Suggestion:

- Check for alternative, possibly request new code from LOINC

Further explanation:

-

To be reconsidered in the future

Added this text to Procedure entry

Was entered in ART-DECOR in error, is now the correct LOINC code for Section.code

Done

Element id added as 0..* R

Observation.code now bound to epSOSBloodPressure value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.21

Finding:

Only a few concepts in associated value set Obs.code

Suggestion:

In the future a value set should contain much more concepts, see e.g. ELGA_Vitalparameterarten 1.2.40.0.34.10.34

Further explanation:

-

Done

Done

Those elements had value sets associated. They were included in the template, but not accepted by functional experts as part of the Patient Summary data set.

Left as optional element without voc bunding only for future consideration. Added a note in the template description.

Done as planned

defined a new VS and added a binding

updated

Done

Removed the binding

template upodated

template updated

Updated the template

removed the voc binding

added datatype and one example with the time stamp

Added cardinality 0..*

Improvement planned for the next template version (assigned to the label Template ID even if it is not related to this)

Made Optional

updated

As epsom is multilingual, the constraint on having displayName valued as "Vital Signs" has been removed 

Added explanation and two examples

Done

added id and effectiveTime

No broken links in the template specifications; references to external templates used by /uses is not relevant for the time being . to be reconsidered for future consideration

Not clear what was the issue the 1.3.6.1.4.1.19376.1.5.3.1.3.11 is defined in the IHE PCC and it is the parent of this template

Note added in the description

Added proposal templates for unstructured documents

Finding:

According to CP#8 the optionality R/R/RFNA shall be read as RNFA / RNFA / RNFA

Suggestion:

Update the work document consequently

Finding:

Update Specialty cardinality to 0..1 (table in § 10.1)

Suggestion:

-

Further explanation:

-

Binding removed

TO BE FIXED creating a template fragment for agents

fixed to 1..1

changed cardinality of the "other" templates to 0..1

no more able to see where the problem was...maybe it has been fixed

description updated

Updated the doseQuantity description

This issue is related to issue 161 and the cardinality of the prefix/suffix is changed to 0 ... * (which is compliant with the HL7 CDA specifications)

Added fixed code S

changed to 1...*

Changed the cardinailty for authior and legal auth.

Solved by the loading of the new MVC 2.2.2

Finding:

-realmCode is Mandatory

Suggestion:

-change to 0..1 R

Further explanation:

-

Finding:

-is Mandatory

Suggestion:

--change to 0..1 R

Further explanation:

-

Finding:

-is mandatory

Suggestion:

--change to 0..1 R

Further explanation:

-

Finding:

-is mandatory

Suggestion:

--change to 0..1 R

Further explanation:

-

Finding:

-is Mandatory

Suggestion:

--change to 0..1 R

Further explanation:

-

proposal to close.

I implemented the change. Expecting little effect, because it just removes (unnecessary) constraints.

Finding:

-

Suggestion:

-

Further explanation:

epSOS said for most address occurrences: "If there is no information, the nullFlavor attribute shall have a value of 'NI' and no address parts shall be present, otherwise there shall be no nullFlavor attribute, and at least one of the address parts listed below shall be present.". Only for Healthcare Facilities there are stricter rules (R1.10.9.3). From the information on optionality it can be inferred that the intention was to make only country mandatory here. Changed accordingly.

-

Finding:

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

Suggestion:

- add more specific information on occurrence, like effectiveTime[1], effectiveTime[2] etc.

Further explanation:

-

Change rejected. This is a specialization of Template CDA documentationOf (prototype, directly derived from POCD_RM000040 MIF).

Looks okay, is the same as the other person instances. Closed.

Finding:

- EffectiveTime of ServiceEvent required Low and high

Suggestion:

- Modify template to allow for high only (without low) and also allow for TS, alternatively ("silent demotion")

Further explanation:

-

Finding:

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.

Suggestion:

Use the IHE Comment Entry as-is (ref) or clone it with a new template ID.

Further explanation:

-

Finding:

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.

Suggestion:

-

Further explanation:

-

Finding:

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.

Suggestion:

-

Further explanation:

-

Which section Libor?

done.

Finding:

- classCode is mandatory, according to schema

Suggestion:

- change cardinality from 0..1 to 1..1

Further explanation:

-

Finding:

- observation classCode is mandatory

Suggestion:

- change cardinality to 1..1

Further explanation:

-

also see discussion on LOINC code in epsos-issue-192

AFAIK the datatypes of such codes need to be CD.EPSOS rather than the generic CD

The Coded Results Section template (1.3.6.1.4.1.12559.11.10.1.3.1.2.5) accepts only blood group observation ( 1.3.6.1.4.1.19376.1.5.3.1.4.13.6)  and no other observation entries . This requirement is listed as R18.1 and R18.2 in the PDF spec, and copied in the current template spec.

proposal to close issue. 

implemented the proposed change, tests showed that it enables the documentation of both, closed and open Allergy Concerns in the same section.

I'm not sure without re-reading our manual but I think if the binding is CWE a warning is generated instead of an error.

Since this template needs to be revised in order to be specialized depending on the fact is used in a eP or into a PS.

I Suggest to postpone this issue and when the revision will be done do no consider anymore these templates but use of the subordinated substance administration as suggested by the medication statement template defined by the Phama WG and adopted for the IPS

Solved by the loading of the new MVC 2.2.2

Solved by the loading of the new MVC 2.2.2

Solved by the loading of the new MVC 2.2.2

suggest to close issue, after discussion.

change implemented

problem does not occur anymore, I was able to edit the template. issue solved.

Changed to urn:epsos-org:ep:medication

Apologies, this was a documentation error and not a definition error. The documentation has been updated to reflect the current situation. Thanks for your patience.

Finding:

- cardinality of entry is 0..1

Suggestion:

- change to 0..*

Further explanation:

- good practice is to have one entry to contain one ProblemConcernAct, containing one Problem observation.

Finding:

-section allows only 0..1 entry

Suggestion:

- change to 0..*

Further explanation:

- It is good practice that one entry contains one Act containing one Problem. So for multiple past illnesses we need multiple entries.

I suggest to remove the requirement to have a unit attribute.
a) in the present form it precludes the use of IVL_PQ (with low and/or high elements)
b) In section 11.1.1.2.3. of the PDF spec for the case of "countable items" it is stated that "In this case, only the unit count is specified , no units are specified." (which I prefer over the curly bracket kludge)
c) the value set binding has to be discussed in the light of the option to use those curly brace expressions. Probably needs to be CWE, so we get schematron warnings, but not errors.

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:

- Value set does not follow the updates in MVC

Suggestion:

- Suggest to update the value set.
Please clarify with Solution Provider Terminology Expert how to proceed...

Further explanation:

-

Finding:

- act.id is mandatory

Suggestion:

- change to 0..1 R

Further explanation:

- no reason to have it mandatory in base templates.

Finding:

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

Suggestion:

- add text to clarify

Further explanation:

-

Finding:

- id cardinality is 1..1 R

Suggestion:

- id cardinality should be 0..1 R

Further explanation:

-

Finding:

- is 1..1 R

Suggestion:

- should be 0..1 R

Further explanation:

-

Finding:

hl7:participant

0 … *

C

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. Contains 2.16.840.1.113883.3.1937.777.11.10.134 CDA Participant (Body) (DYNAMIC)

Suggestion:

A specialized template should be defined for the <participant> structure describing the substance that causes the allergy or intolerance

Further explanation:

-

Yes, it looks like an error in the current IG version. In the original PDF spec under rule R4.3 we see that manufacturedMaterial/ingredient/[@classCode='ACTI']/ingredient/name is on the same lavel as manufacturedMaterial/ingredient/[@classCode='ACTI']/ingredient/code

Also, the levels of originalText and translation are strange. I believe they should be under manufacturedMaterial/ingredient/[@classCode='ACTI']/ingredient/code.

I changed the template, moving originalText and translation under code, and moving name to the same level as code.

Solved by changing the namespace prefix from hl7 to epsos

Finding:

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

Suggestion:

This constraint is not captured by the current specifications.
Add an explicit assertion to check this.

Further explanation:

-

Finding:

- cardinality of id is 0..*

Suggestion:

- must be maximum 1. 
Changed it to 0..1

Further explanation:

-

Changed to 1..1

Finding:

- cardinality of manufacturedProduct must be less or equal 1

Suggestion:

- Changed to 0...1

Further explanation:

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

If an artefact is locked but no longer used (e.g. if somebody opened the editor and simply clicked it away instead of closing it through the save or cancel buttons) the locks can be deleted by any project author through the Project -> Status tab.

The cardinality has been changed to 1..1

Finding:

- When <let> used, it shall not contains circular references to other <let> elements [HL7TEMP-045]  

Suggestion:

- more information needed.

Further explanation:

-

Finding:

- effectiveTime has cardinality 1..*

Suggestion:

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

Further explanation:

-

Finding:

- text cardinality is 1...*

Suggestion:

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

Further explanation:

-

Finding:

- effectiveTime is 1..*

Suggestion:

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

Further explanation:

-

Finding:

- substanceAdministration maximum multiplicity is *

Suggestion:

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

Further explanation:

-

Finding:

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

Suggestion:

- cannot use the generic Organization template here. Adapt to additional constraints, specific for custodian organization.

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

Finding:

- cardinality is 0..*

Suggestion:

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

Further explanation:

-

Finding:

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

Location :  //rules/template[31]/element[1]/element[10]/element[1]/element[3] 
CDALocation :  /hl7:substanceAdministration[hl7:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.12']/hl7:consumable/hl7:manufacturedProduct/hl7:manufacturedMaterial 
Description :  The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]  Suggestion:

-

Further explanation:

-

Finding:

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

Location :  //rules/template[36]/element[1]/element[6] 
CDALocation :  /hl7:observation[hl7:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.13.5']/hl7:effectiveTime 
Description :  The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]  Suggestion:

-

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

Finding:

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

Location :  //rules/template[42]/element[1]/element[5] 
CDALocation :  /hl7:act[hl7:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.3.1']/hl7:statusCode 
Description :  The maximum multiplicity SHALL be lower or equals to the maximum multiplicity from the CDA model [CDATEMP-005]  Suggestion:

-

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

Finding:

- The contains statement produces a duplication of the participant element (nesting).

Suggestion:

- replace "contains" by "include"?

Further explanation:

-

Finding:

-

Suggestion:

-

Further explanation:

-

sorry. The referenced value set is 2.16.840.1.113883.1.11.10901. And apparently it contains concepts that were not present in the original CDA vocabulary.

The base standards validation complains:
Test : CDATEMP019(Validation Level : FLATTEN_VOCAB , Type : FATALERROR) 
Location : //rules/template[14]/element[1]/element[18]/attribute[1] 
CDALocation : /hl7:substanceAdministration[hl7:templateId/@root='1.3.6.1.4.1.12559.11.10.1.3.1.3.2']/hl7:participant/@typeCode 
Description : When a valueset is specified, and the referenced attribute is an enumeration, the content of the valueset SHALL be a restriction of the referenced attribute [CDATEMP-019] 

I won't take any action on this:
The template I changed ( 2.16.840.1.113883.3.1937.777.11.10.111 ) is the generic epSOSCDAOrganization, used for all kinds of Organizations.
The bug was that Custodian should have a specialized template, more restrictive than the generic one that you changed.

The hl7:assignedPerson has a containment and and "overriding" inline definition. This is illegal. It should be either one.
For the hl7:representedOrganization our recommendation is to name the representedOrganization element and the include the template (rather than contain).
The same should be done for hl7:assignedPerson if appropriate.

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:

-