Implemented

Modified the linking in ART-DECOR

Implemented as a bugfix for the approved change proposal CP-19.

Finding:

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

Suggestion:

- Change conformance from R to M

Further explanation:

- Link to JIRA issue: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-454

Implemented and ready to be included in 3.0.0 release

Reverted medical strength datatype

Finding:

- 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

Suggestion:

-

Further explanation:

-

Finding:

- Add descriptions to strength and package size to reflect CP -25
Link to JIRA issue: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-414

Suggestion:

-

Further explanation:

-

Changes applied

Changes applied

Finding:

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

Suggestion:

- Remove the linkage between epsos-dataelement-116 and hl7:code from the template

Further explanation:

- Link to issue in JIRA: https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-428

Finding:

- 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

Suggestion:

-

Further explanation:

-

As an outcome from JIRA issue EHSEMANTIC-322, approved by the architecture group, it was confirmed that we can delete the issues related to changes in the Word version of the specifications (which are discontinued)

As an outcome from JIRA issue EHSEMANTIC-322, approved by the architecture group, it was confirmed that we can delete the issues related to changes in the Word version of the specifications (which are discontinued)

Closed this issue, since I combined all the OID related issues in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242

This is a known issue and has been analyzed on the confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

Closed this issue, since I combined all the OID related issues in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242

This is a known issue and has been analyzed on the confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

Closed this issue, since I combined all the OID related issues in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242

This is a known issue and has been analyzed on the confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

This issue can be closed since it is related to the duplicate OID issue which is already listed in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242

The problem is that the Allergies And Intolerances templates should not be a specialization of our Problem template, but of the IHE PCC Problem template, that doesn't have a constraint on the observation/code binding.

More information can be found on the following confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

Closed this issue, since I combined all the OID related issues in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242

This is a known issue and has been analyzed on the confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

As an outcome from JIRA issue EHSEMANTIC-322, approved by the architecture group, it was confirmed that we can delete the issues related to changes in the Word version of the specifications (which are discontinued)

Closed this issue, since I combined all the OID related issues in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242

This is a known issue and has been analyzed on the confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

Closed this issue, since I combined all the OID related issues in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242

This is a known issue and has been analyzed on the confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

As an outcome from JIRA issue EHSEMANTIC-322, approved by the architecture group, it was confirmed that we can delete the issues related to changes in the Word version of the specifications (which are discontinued)

As an outcome from JIRA issue EHSEMANTIC-322, approved by the architecture group, it was confirmed that we can delete the issues related to changes in the Word version of the specifications (which are discontinued)

Aligned error message with assert.

This issue is a duplicate for issue #182: https://art-decor.ehdsi.eu/art-decor/decor-issues--epsos-?id=2.16.840.1.113883.3.1937.777.11.6.182
This issue can be closed since we put the constraint to the epsosLanguage value set as done in ticket https://ec.europa.eu/cefdigital/tracker/browse/EHSEMANTIC-291

As agreed in the semantic F2F meeting on 13/11, it was agreed to set the realmCode element to optional for all document level templates.

As agreed in the semantic F2F meeting on 13/11, it was agreed to set the realmCode element to optional for all document level templates.

As agreed in the semantic F2F meeting on 13/11, it was agreed to set the realmCode element to optional for all document level templates.

As agreed in the semantic F2F meeting on 13/11, it was agreed to set the realmCode element to optional for all document level templates.

As agreed in the semantic F2F meeting on 13/11, it was agreed to set the realmCode element to optional for all document level templates.

Issue can be closed since it has already been implemented in the previous CDA IG releases:

• v2.1.1
• v2.2.0

Closed the issue, as it is was already implemented in the two previous official CDA IG releases:

• v2.1.1
• v2.2.0

Closed this issue, since I combined all the OID related issues in issue #242: https://art-decor.ehdsi.eu/art-decor/decor-issues-epsos?id=2.16.840.1.113883.3.1937.777.11.6.242  

This is a known issue and has been analyzed on the confluence page: https://ec.europa.eu/cefdigital/wiki/x/haJUAw

Since we don't know what section this issue is about and it's open for more then a year, we decided to close it.
If Libor specifies which section has to contain the entry definition, we can reopen it...

Implemented by Christof Gessner

Cardinality has been set already to 1...1 and was already defined like this in the previous release, so I guess this issue can be closed

Constraint added to languageCode element for:

• document level template
• recordTarget template

Closed for administrative reasons: fix for this issue was implemented last year and is already present in the last two formal releases:

• V2.1.1
  
• V2.2.0
  

I closed this ticket since it's already implemented and available in the latest CDA IG release.

Closed for administrative reasons: fix for this issue was implemented last year and is already present in the last two formal releases:

• V2.1.1
  
• V2.2.0

Closed for administrative reasons: fix for this issue was implemented last year and is already present in the last two formal releases:

• V2.1.1
  
• V2.2.0

Closed for administrative reasons: fix for this issue was implemented last year and is already present in the last two formal releases:

• V2.1.1
  
• V2.2.0

This ticket can be closed, since it has been implemented already and it was part of the latest release.

Closed for administrative reasons: fix for this issue was implemented last year and is already present in the last two formal releases:

• V2.1.1
  
• V2.2.0

Issue can be closed since it has already been implemented and it's available in the two previous formal CDA IG releases:

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

This issue can be closed since it was already adapted and the fix was available in the last two formal releases:

• v2.1.1
• v2.2.0

This issue can be closed since the fix has already been implemented and available in the previous two formal releases:

• v2.1.1
• v2.2.0

This issue is closed since it has already been fixed in the previous two CDA IG releases:

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

Closed for administrative reasons: fix for this issue was implemented last year and is already present in the last two formal releases:

• V2.1.1
  
• V2.2.0

Closed as it has already been adapted before our two main releases:

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

Replaced the contains statement by an include statement.

Change implemented. This is a technical correction, so no need for approval. The Allergies And Intolerances template has to conform to the IHE PCC Problem template. For now this is an issue, since the IHE PCC Problem template and the Problem template use the same OID.

For the IHE PCC Problem template, the Id has cardinality 1 .. 1 and conformance M
For the Problem template, the Id has cardinality 1 .. 1 and conformance M

So it makes sence to also restrict the conformance of the Allergies And Intolerances template to 1 .. 1 M

Scenario created and available.

Scenario created and available.

Is not fixed yet...

Closed for administrative reasons: fix for this issue was implemented last year and is already present in the last formal release:

• V2.2.0

Doesn't make sense to add a templateID to this CDA template

Implemented after it has been agreed in the semantic F2F meeting (12/13 november)

Closed the issue. We proposed the solution of making the manufacturedMaterial optional in the semantic F2F meeting of 12/13 November in Brussels, but although it would technically a solution, it was stressed that the formCode has to be mandatory for the eP/eD documents, but only optional for the PS documents.

Since this requirement cannot be fulfilled using a common template, 2 separate templates have to be created as a specialization of the current one. But this changes the specifications and has to occur through a change proposal.
This issue is a duplicate of the older one: https://art-decor.ehdsi.eu/art-decor/decor-issues--epsos-?id=2.16.840.1.113883.3.1937.777.11.6.126 so it was decided to close this one and to keep the old one.

Implemented after it has been agreed in the semantic F2F meeting (12/13 november)

Constraint removed after approval by the semantic group during the semantic F2F meeting in Brussels on the 12/13th of November 2018.
Added a textual constraint.

Descriptions approved during eP cluster meeting and added to the CDA IGs

Corrected example

reply from Giorgio:

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.

This element is implemented in ART-DECOR.
It will be presented to the eP cluster and available in the next CDA IG release.

Finding:

- 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

Suggestion:

- Add the binding and modify the cardinality/conformance to 1 .. 1 /R

Further explanation:

-

Created Dispenser Credentialing Organization template.

Schematron rule adapted and corrected.

Description adapted

Finding:

- 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

Suggestion:

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

Further explanation:

-

Is duplicated by https://art-decor.ehdsi.eu/art-decor/decor-issues--epsos-?id=2.16.840.1.113883.3.1937.777.11.6.291

Finding:

- 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

Further explanation:

-

Created new template with new OID

Template removed and content migrated into epSOS CDA substanceAdministration template

Aligned with guidelines on representation of "known absence" and "no information" for the required sections .

Removed ingredient data type

Datatypes adapted

Added consumable element to Related Prescription Item template.

Example adapted

Removed the value set constraint

Review finished

I guess this issue can be closed since the moodCode is adapted in ART-DECOR.
I agree with the proposal.

Dear Giorgio, thank you for your feedback. This is highly appreciated.

I always create tickets for the things I want to change where I don't feel 100% confident, and ask for feedback from the semantic experts. 
This is one of these cases. I changed the issue status to "Feedback needed" and Label "(TBA) To be approved".

If I understand it correctly, we make the following distinction:

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

Finding:

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

Suggestion:

- Change the conformance from R to M

Further explanation:

-

Finding:

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

Suggestion:

- Restrict nullFlavor value of assignedAuthor to "NI"

Further explanation:

-

Finding:

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

Suggestion:

- Restrict nullFlavor value of assignedAuthor to "NI"

Further explanation:

-

Finding:

- At this moment, the CDA NumberOfPackages template has an epSOS OID and was created for reuse. However, this template doesn't have a templateID

Suggestion:

- At the templateID for this template

Further explanation:

-

Finding:

- 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

Further explanation:

-

Finding:

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

Suggestion:

- Make the element optional.

Further explanation:

-

Finding:

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

Suggestion:

- Remove the @determinerCode attribute with it's fixed value from the epsos:ingredient element

Further explanation:

-

modified the example and the erroneous namespace prefix was fixed by dr Kai Heitmann

I implemented all the requested changes, except for:

•  the line:
  

Christof Gessner put the following remark:
            
In Section 6 it is proposed to add a constraint to template 1.3.6.1.4.1.12559.11.10.1.3.1.3.2 requiring the prescription ID to be equal to the document ID. I don't think this is required, and I even would say it is wrong. Because the two IDs do not represent the same information object, not even the same kind of information object. A document that represents a prescription is not identical to the prescription itself. And I believe we would lose flexibility if we would consider these two objects to be identical.

Giorgio Cangioli: +1. The use of the ClincalDocument.id as prescription.id is a recurring error that again and again shows up. I don't like (and IMHO it is not correct as well ) either the section.id for this scope, but at least it provides some kind of flexibility...

• The line

Finding:

- 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

Suggestion:

- Remove the possibility to have a value from the 2 value sets.

Further explanation:

-

id and text element are added to comply with the Simple Observation Template

Finding:

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

Suggestion:

- Change the cardinality from 0 ... * to 1 ... 1 or at least 0 ... 1

Further explanation:

-

Finding:

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

Suggestion:

- Lets make this template compatible with the IHE PCC Problem template and change the cardinality and conformance

Further explanation:

-

I adapted the cardinality.

Dear Giorgio,

Thank you for the feedback. Very well appreciated. But could you provide me some clarification?
To give you a little context on why I did this change:
IHE Europe creates validators based on our ART-DECOR implementation guides. Before the validator was based on the paper specifications in EXPAND.
To identify the differences in validation results between the old validator and the new ART-DECOR based one, a gap analysis was done between the two:
For the Country, there was this difference that the old validator checked that the value in the country element was coming from the epsosCountry value set.
In ART-DECOR there was no rule for this.
hl7:addr is of datatype AD.EPSOS and country is a subelement with datatype ADXP. I wanted to indicate that the value of the country subelement has to come from the epsosCountry value set.
So that <country>IT</country> is allowed and not <country>ITALY</country>

What is the correct way to define this in ART-DECOR?

Finding:

- added the templateId element

Suggestion:

-

Further explanation:

-

Finding:

- Can't edit template. Error message says: Template locked User Oliver Egger 2017-11-27

Suggestion:

-

Further explanation:

-

In the EXPAND PDF Spec this corresponds to R4.3, saying that this element is optional. As the  datatype is ST, using nullFlavor is not an option. However, in the code element you also have the name.

Text adapted

Duplicate of issue 263

We received the confirmation in the semantic group in the meeting of 14/3 to change the moodCode attribute and it has been adapted.

Effective type with datatype TS has been added to the Vital Signs Observation template.
Issue is related to issue #266

It was agreed upon to remove the dependency to the CCD template (2.16.840.1.113883.10.20.1.54) from the allergies observation. No formal reason could be found to keep it. Since the constraint was just in textual form, it won't be tested in the validation.

It's a spurious remaining from the IHE PCC, where conformance to CCD was requested. No formal rules could be seen that could not be covered by other templates present in the Allergy Reaction Observation.

Datatype is changed from IVL_TS to TS.
This has been agreed upon in the working session with the eHDSI solution provider. I also extended the description and added an example for clarification.

Textual constraint removed from the template.
I also removed it from the example in the observation for the immunizations. Since there it was not in the description, but only in the example and this is very confusing.

Changed the datatype for the effectiveTime in the Medical Devices Template from IVL_TS to TS and adapted the description accordingly.

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:

-