Loading...
Help
Login
Busy
Search
epSOS - Issues
 
Select object
Results (1 / 1)
Id Issue Status Priority Type Date Assigned To Label
245Relax 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)ClosedNormalChange Request2017-12-08 17:09:24Mathias Ghys
 
Change RequestRelax 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)
Idepsos-issue-245
StatusClosed
PriorityNormal
Last Tracking2017-12-08 17:09:24  by  Dr. Kai U. Heitmann
Current AssigneeMathias Ghys
    
Concerns
Template
Problem (1.3.6.1.4.1.19376.1.5.3.1.4.5)
/
/
Template1.3.6.1.4.1.19376.1.5.3.1.4.5 (2013-12-20) Problem
StatusDraft

/
-
/
-

Events
TrackingClosed2017-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.
TrackingClosed2017-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.
TrackingFeedback needed2017-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?
TrackingClosed2017-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
Assignment2017-12-05 17:02:03: Assigned To Mathias Ghys by Mathias Ghys
TrackingOpen2017-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
PreviewCodeHTML colorDisplay NameDescription
 
 TBA 
TBATBATo be approved
To be discussed and approved
 
 M1 
M1M1Milestone 1
Milestone 1 – before the EXPAND-athon 9-12 December 2015 Lisbon
 
 M2 
M2M2Milestone 2
Milestone 2 – final results to be delived at the end of EXPAND
 
 M3 
M3M3Milestone 3
Milestone 3 – end of the HL7 International Project
 
 M4 
M4M4Milestone 4
Milestone 4 – for consideration in the future / desiderata
 
 WJ 
WJWJChanges Word/JIRA
Changes in the Word Specification/Open a JIRA issue
 
 TID 
TIDTIDTemplate ID
Template-ID changes throughout the specification