Loading...
Help
Login
Busy
Search
epSOS - Issues
 
Select object
Results (1 / 1)
Id Issue Status Priority Type Date Assigned To Label
239Modify effectiveTime element for Medical Device templateFeedback neededNormalChange Request2017-11-23 20:51:26Mathias Ghys
 
 TBA 
 
Change RequestModify effectiveTime element for Medical Device template
Idepsos-issue-239
StatusFeedback needed
PriorityNormal
Last Tracking2017-11-23 20:51:26  by  Dr. Kai U. Heitmann
Current AssigneeMathias Ghys
Current Labels
    
 (TBA) To be approved 
    
Concerns
Template
Medical Devices (1.3.6.1.4.1.12559.11.10.1.3.1.3.5)
/
/
Template1.3.6.1.4.1.12559.11.10.1.3.1.3.5 (2013-12-20) Medical Devices
StatusDraft

/
-
/
-

Events
TrackingFeedback needed2017-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
TrackingFeedback needed2017-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. 
TrackingFeedback needed2017-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!

 

Assignment2017-11-23 17:11:11: Assigned To Mathias Ghys by Mathias Ghys
    
 TBA 
Assignment2017-11-23 16:11:18: Assigned To Dr. Kai U. Heitmann by Mathias Ghys
    
 TBA 
TrackingFeedback needed2017-11-23 16:11:05: Tracking by Mathias Ghys
    
 TBA 
Edited byMathias 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. 

Assignment2017-11-23 11:46:56: Assigned To Mathias Ghys by Mathias Ghys
Edited byChristof 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).
TrackingOpen2017-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
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