Loading...
Help
Login
Busy
Search
Consolidated CDA (Sequoia) - Templates
 
Template locked

OK Not OK
Templates (External repositories)

Warning Ok
Warning
Filter
Medication Dispense
Issues (1)
Change Request Status = Closed (ccda-issue-184): CS-20180224 EntryRelationship constraint too tight.
TypeChange RequestStatusChange Request Status = Closed PriorityHigh
Current Labels
 
 (CS) Customer Support 
Events
Tracking / Status = Closed 2018-06-06 15:37:55: Tracking by Didi Davis
 
 CS 
Description
Feedback from IHE services on this issue on 2018-08-06

Cédric EOCHE-DUVAL

Today 10:34 AM

This issue has been solved by  SEQUOIA-66. See validation result :  https://gazellecontent.sequoiaproject.org/EVSClient/detailedResult.seam?type=CDA&oid=1.3.6.1.4.1.12559.11.28.13279

Moreover, There is no simple way to determine where there are other patterns like this, as it is a very specific case, strongly related between GOC, Art-Decor and specification document. The most efficient way is to wait for other feedback.

Didi verified that issue ccda111962 no longer errors. 

Assignment2018-06-04 22:04:10: Assigned To Abderrazek Boufahja by Didi Davis
 
 CS 
Tracking / Status = In Progress 2018-06-04 22:03:42: Tracking by Didi Davis
 
 CS 
Description
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
Assignment2018-04-30 22:25:26: Assigned To Didi Davis by Lisa Nelson
 
 CS 
Tracking / Status = Open 2018-03-26 23:11:55: Tracking by Lisa Nelson
 
 CS 
Description
Add label.
Tracking / Status = Open 2018-02-28 19:02:34: Tracking by Lisa Nelson
Description
Reviewed this with Didi,  She will see if there is a way to programatically determine where there are other patterns like this with a MAY and a SUCH THAT IT....
Tracking / Status = Open 2018-02-24 14:47:28: Tracking by Lisa Nelson
Description
Sent a message to Kai to ask about this issue.
Assignment2018-02-24 14:29:08: Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2018-02-24 14:29:07: Tracking by Lisa Nelson
Description
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.


Further explanation:

- This is a "such that it" interpretation problem.  I need to run this by Kai.

 
 
Busy
Structure Definitions (External repositories)