Your browser does not appear to support JavaScript. You may want to try one of the following:
You may want to try one of the following:
If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:
shift
control
Show details
Hide details
This form has to be reloaded. This most likely happened because your session has expired, which might take to the login page. (If you think that you shouldn't see this message and that the problem persists, please contact support.)
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)])>=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!
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.
- At this moment, the definition and the description is confusing
- 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
-