Help
Login
Busy
Search
epSOS - Issues

 
Select object
 
falsehide
Results (1 / 1)
Id Issue Status Priority Type Date Assigned To Label
239 Modify effectiveTime element for Medical Device template Feedback needed Normal Change Request 2017-11-23 20:51:26 Mathias Ghys
 
 TBA 
 
Change Request Modify effectiveTime element for Medical Device template
Id epsos-issue-239
Status Feedback needed
Priority Normal
Last Tracking 2017-11-23 20:51:26  by  Dr. Kai U. Heitmann
Current Assignee Mathias Ghys
Current Labels
    
 (TBA) To be approved 
    
Concerns
Template
false
Medical Devices (1.3.6.1.4.1.12559.11.10.1.3.1.3.5)
/
/
Template 1.3.6.1.4.1.12559.11.10.1.3.1.3.5 (2013-12-20) Medical Devices
Status Draft
/
-
/
-
Events
Tracking Feedback needed 2017-11-23 20:51:26 : Tracking by Dr. Kai U. Heitmann
    
 TBA 
Description
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
Tracking Feedback needed 2017-11-23 18:22:49 : Tracking by Christof Gessner
    
 TBA 
Description
Answer to question "Thinking about adding low 1 ...1 R and high 0 ...1 R subelements.":

This has to be decided on a case ba case basis. Sometimes the "low" of the interval is the default and clinically relevant (and usually available) timestamp, sometimes it is the "high" of the interval.
An example is the serviceEvent/effectiveTime where the "high" is relevant (as the time of the last modification).

Joining this with the option to "demote" and just send a point-in-time, and not an interval, this would imply that this single value is sometimes interpreted as the "low" and in other contexts as the "high" of the effectiveTime interval. Still, I am in favor of such an option (to allow sending a point-in-time), mostly for the convenience of the implementers that only have one timestamp (or a null) for a given item. 
Tracking Feedback needed 2017-11-23 18:15:43 : Tracking by Christof Gessner
    
 TBA 
Description

I just reviewed the schematrons for epsos.

 

In the main file epsos-PatientSummary.sch I could find the namespace declarations for xsi and epsos, prefixes explicitely defined (and therefore a fixed assumption!):

<ns uri="urn:epsos-org:ep:medication" prefix="epsos"/>

<ns uri="http://www.w3.org/2001/XMLSchema-instance" prefix="xsi"/>

<ns uri="urn:hl7-org:v3" prefix="hl7"/>

 

In the detail Schematrons I see tests where elements are referenced using this (fixed) prefix:

test="count(epsos:quantity[not(@nullFlavor)])&gt;=1"

 

In some cases, code like this is generated:

test="(local-name-from-QName(resolve-QName(@xsi:type,.))='CD' and namespace-uri-from-QName(resolve-QName(@xsi:type,.))='urn:hl7-org:v3') or not(@xsi:type)"

where the namespace of the _datatype_ is detected in a generic way, i. e. independent of the prefix that is used for the namespace 'urn:hl7-org:v3'

 

But I can see this neither for urn:epsos-org:ep:medication nor for http://www.w3.org/2001/XMLSchema-instance.

 

To my understanding, this means that if someone uses different prefixes for those namespaces (not epsos and xsi), the schematrons will not work properly.

 

So, all I'm saying is: If we want the schematrons as intended, people _have_ to stick to the "usual" namespace prefixes like

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:epsos="urn:epsos-org:ep:medication"

 

Probably a wise way to go, because schematron files would get very clumsy and hard to read (and possibly slow...).

But it is a _caveat_ for implementers!

 

Assignment 2017-11-23 17:11:11 : Assigned To Mathias Ghys by Mathias Ghys
    
 TBA 
Assignment 2017-11-23 16:11:18 : Assigned To Dr. Kai U. Heitmann by Mathias Ghys
    
 TBA 
Tracking Feedback needed 2017-11-23 16:11:05 : Tracking by Mathias Ghys
    
 TBA 
Edited by Mathias Ghys ( 2017-11-23 17:11:00 )
Description
The outcome of this issue has to be decided via a change proposal or with discussions in the semantic group.
Issues to think about:
  • adding the xsi:type attribute, the question must be answered, if this is robust. Not sure whether Schematron will just verify the namespace prefix, or check the namespace that it represents, or both. (BTW: That same question applies to the epsos prefix for the extensions in the Medication entry!). Problems could arise when people would use a different prefix, but with the correct namespace. 

  • Should we allow the option of sending just a TS (or alternatively just a TS with a nullFlavor?) or do we require the low value and put the TS there?

  • Thinking about adding low 1 ...1 R and high 0 ...1 R subelements. 

Assignment 2017-11-23 11:46:56 : Assigned To Mathias Ghys by Mathias Ghys
Edited by Christof Gessner ( 2017-11-23 12:49:25 )
Description
I support this change.

- Should we also allow the option of sending just a TS (or alternatively just a TS with a nullFlavor?). See issue-174 for implementation in ART DECOR.

- Should we also adjust the cardinality to 1..1? I believe that the receivers could not interpret multiple effectiveTimes correctly (in the display tool).
Tracking Open 2017-11-23 11:46:55 : Tracking by Mathias Ghys
Description
Finding:

- At this moment, the definition and the description is confusing

Suggestion:

make low 1..1 R and high 0..1 R as subelements. This is no breaking change, it simply makes low required to be the implant/start date

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