Help
Login
Busy
Search
epSOS - Issues

 
Select object
 
false
Results (1 / 1)
Id Issue Status Priority Type Date Assigned To Label
245 Relax the constraint that the hl7:code shall be from value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.23 epSOSCodeProb (DYNAMIC) Closed Normal Change Request 2017-12-08 17:09:24 Mathias Ghys
 
Change Request Relax the constraint that the hl7:code shall be from value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.23 epSOSCodeProb (DYNAMIC)
Id epsos-issue-245
Status Closed
Priority Normal
Last Tracking 2017-12-08 17:09:24  by  Dr. Kai U. Heitmann
Current Assignee Mathias Ghys
    
Concerns
Template
false
Problem (1.3.6.1.4.1.19376.1.5.3.1.4.5)
/
/
Template 1.3.6.1.4.1.19376.1.5.3.1.4.5 (2013-12-20) Problem
Status Draft
/
-
/
-
Events
Tracking Closed 2017-12-08 17:09:24 : Tracking by Dr. Kai U. Heitmann
Description
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.
Tracking Closed 2017-12-08 14:56:00 : Tracking by Mathias Ghys
Description
I checked with Abderrazek. He liked your change (as do I).
At the moment, the validator doesn't doesn't take the CWE/CNE into account.
Abderrazek can activate this logic (and I think it's the way to proceed)
But we have to take into account that all the value sets are CWE.
So if we activate this, it will impact the validation of the Value Sets.
I'll write it down at we can take it up in the next Test FWK: Attangement towards Formal Test Event meeting next week.
Tracking Feedback needed 2017-12-08 13:46:24 : Tracking by Christof Gessner
Description
In order to remove the strict contstraint, I changed the coding-strength to CWE, after adding the codeSystem once again.
The ecpected behaviour is that the validator creates a warning now, but not an error.

Could someone please check if validators work as expected here?
Tracking Closed 2017-12-07 19:10:01 : Tracking by Mathias Ghys
Description
Remove the constraint the the hl7:code from the Problem template has to come from the value set: 1.3.6.1.4.1.12559.11.10.1.3.1.42.23 epSOSCodeProb (Dynamic)
as agreed in the eHDSI: Test FWK: Arrangement towards Formal Test event (Jan 2017) of the 29th of November
Assignment 2017-12-05 17:02:03 : Assigned To Mathias Ghys by Mathias Ghys
Tracking Open 2017-12-05 17:02:02 : Tracking by Mathias Ghys
Description
Finding:

- At this moment we have this constraint on the hl7:code element of the Problem template, while this was not the case in the former EXPAND specifications. The problem arises when we use the 'Allergy And Intolerance' template, which is a specialization of the 'Problem' template. This also has a constraint on the hl7:code element but this time for another Value Set. Since these two constraints conflict, a solution is to relax the constraint on the hl7:code element of the Problem template

Suggestion:

- Relax the constraint on hl7:code from the Problem template to be from the value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.23 epSOSCodeProb (DYNAMIC)

Further explanation:

-

    
Labels
Preview Code HTML color Display Name Description
 
 TBA 
TBA TBA To be approved
To be discussed and approved
 
 M1 
M1 M1 Milestone 1
Milestone 1 – before the EXPAND-athon 9-12 December 2015 Lisbon
 
 M2 
M2 M2 Milestone 2
Milestone 2 – final results to be delived at the end of EXPAND
 
 M3 
M3 M3 Milestone 3
Milestone 3 – end of the HL7 International Project
 
 M4 
M4 M4 Milestone 4
Milestone 4 – for consideration in the future / desiderata
 
 WJ 
WJ WJ Changes Word/JIRA
Changes in the Word Specification/Open a JIRA issue
 
 TID 
TID TID Template ID
Template-ID changes throughout the specification