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.)
the supply.code is not used in epSOS. So, there is no any @codeSystem constrain (= 2.16.840.1.113883.5.4)
remove that element
-
the datatype for the effectiveTime seems not defined (TS or IVL_TS)
the participantRole.id is optional chanhe R to O and/or add card to 0..
Add an example of how to handle the case of "no devices" (and no information about devices ?)
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
- At this moment, the dataType of the effectiveTime on the Medical Devices template is IVL_TS. This is not according to the PS Functional Requirements where they only mention the implant date
- We will limit the effectiveTime to only allow the TS and not the low/high values from the IVL_TS.
- Maybe in the future we might consider to allow again the IVL_TS datatype, this won't have any impact on the member states (since the constraint is less strict and allows also intervals instead of just timestamp values) but this change has to be done through a change request and as a result of a change in the functional requirements for the PS