Opened JIRA ticket #77 to advance this resolution. It was found during audit of all CS issues.
Customer Service issue originally reported from Kent Stevenson (DoD) on 2/22/18
https://gazellecontent.sequoiaproject.org/EVSClient/detailedResult.seam?type=CDA&oid=1.3.6.1.4.1.12559.11.28.1772 Finding:
-constraint that appears more restrictive than the specifications require.
Suggestion:
-The requirement CONF:7474 indicates that if a
Medication Supply Order is included the entryRelationship/@typeCode SHALL be “REFR”. However, there is no prohibition of entryRelationships to something other than a Medication Supply Order.
Lisa and I are unclear how to edit Art Decor to relax this constraint. We also would like you to allow a way
to programatically determine where there are other patterns like this with a MAY and a SUCH THAT IT....?
See email exchange with Kai when we reached out for guidance from him previously - you were copied - but I copied below:
From: Kai U. Heitmann [mailto:
info@kheitmann.de ]
Sent: Monday, February 26, 2018 4:47 AM
To: Lisa R. Nelson <
Lisarnelson@cox.net >; Abderrazek Boufahja <
abderrazek.boufahja@gmail.com >
Cc: 'Didi Davis' <
ddavis@sequoiaproject.org >
Subject: Re: Possible Validator issue using C-CDA R2.1 validation - Item #4
Resent due to know SPAM error in your email footers…
Hi Lisa
Maybe we need to discuss that on the phone more but I can tell that the ugly „such that is“ construct is about predication, and most of that is done automatically in ART-DECOR.
In the example below the entryRelationship that is defined is with type code REFR into a supply. In the parent template itself, I assume, nothing else is allowed.
[LRN]
Kai, the statement I marked in yellow show the problem. There should be no assumption that nothing else is allowed. The validator is behaving as if nothing else were allowed and that is not the same as how this would be interpreted elsewhere. The MAY
have an entryRelationship such that the typeCode is REFR DOES NOT MEAN YOU CAN’T HAVE entryRelationships where typeCode is not REFR. This is the validation behavior we need to change. You can’t assume nothing else is allowed.
Our customer is pointing out
that the AD validator is too restrictive. It should not complain about an entryRelationship with typeCode of COMP being present.
The definition in AD automatically creates a predicate that the may be an entryRelationship to a supply with the corresponding template ID.
The predicate that is used is generated based on the containment:
0..1 entryRelationship contains …10.20.22.4.18
Medication Supply Order
that generates an entryRelationship where supply.templateId.root is …10.20.22.4.1
which exactly means 0..1 entryRelationship with a Medication Supply Order
as said: automatically detected in most cases by AD
In an open environment you may then have other entryRelationships.
In a closed
validation nothing else is allowed. That is by definition.
The AD schematron engine generates the appropriate validation code.
Obviously the IHE Gazelle validation is looking for an entryRelatonship REFR type code only which is equal to a closed validation.
Thus, the entyrRelationship COMP is not allowed in the example instance below.
If you want to allow other entyrRelationships declare them or do open validation (or in the AD schematrons you may choose for “closed warnings on open” which gives you warnings only instead of errors.
I copied Abderrazek in
this conversation because he knows best what is going on in Gazelle.
Hope this help for now.
Best regards
--Kai
PriorityMajor