Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdht-dev] xsi:type problem in observationMedia/value 
Sean, Joerg, Tony,

thanks a lot. Hopefully they will fix the rule soon. :)

Best,

Axel

2016-03-23 14:37 GMT+01:00 Tony Schaller <tony.schaller@xxxxxxxxxxxx>:
> OK, we'll inform the German guys about that.
> Regards, Tony
>
> -----Ursprüngliche Nachricht-----
> Von: mdht-dev-bounces@xxxxxxxxxxx [mailto:mdht-dev-bounces@xxxxxxxxxxx] Im Auftrag von Joerg Kiegeland
> Gesendet: Mittwoch, 23. März 2016 14:34
> An: mdht developer discussions <mdht-dev@xxxxxxxxxxx>
> Betreff: Re: [mdht-dev] xsi:type problem in observationMedia/value
>
> Hi Tony,
>
> the schematron rule is not really good as when xsi:type is omitted, it
> *is* an ED, so it should be like
>
> <iso:pattern name="OMVL observationMedia Class">
>         <iso:rule context="cda:observationMedia">
>                 <iso:assert test="not(cda:value/@xsi:type)) or cda:value/@xsi:type='ED'">
>                         vhitg-ruleset.ent: <emph>observationMedia</emph> must contain a value of type ED.
>                 </iso:assert>
>         </iso:rule>
> </iso:pattern>
>
> Cheers
>
>> Hi Sean
>>
>> In fact you are right, the xsi:type is not missing.
>> But unfortunately the German "Arztbrief" Schematron rules are requiring it:
>>
>> <iso:pattern name="OMVL observationMedia Class">
>>       <iso:rule context="cda:observationMedia">
>>               <iso:assert test="cda:value/@xsi:type='ED'">
>>                       vhitg-ruleset.ent: <emph>observationMedia</emph> must contain a value of type ED.
>>               </iso:assert>
>>       </iso:rule>
>> </iso:pattern>
>>
>> Regards,
>> Tony
>>
>> -----Ursprüngliche Nachricht-----
>> Von: mdht-dev-bounces@xxxxxxxxxxx
>> [mailto:mdht-dev-bounces@xxxxxxxxxxx] Im Auftrag von Sean Muir
>> Gesendet: Mittwoch, 23. März 2016 14:14
>> An: mdht developer discussions <mdht-dev@xxxxxxxxxxx>
>> Betreff: Re: [mdht-dev] xsi:type problem in observationMedia/value
>>
>> Hello
>>       The underlying schema has the value defined as an ED (as compared to
>> other observations where it is a ANY) and as such the xsi:type for the
>> value is not required; So the "xsi:type="ED" is not in fact missing
>>
>>       If you can be a bit more specific as to why you need to have the
>> xsi:type might be helpful
>>
>>       In the meantime - there are some options and none particular simple
>> or straightforward as far as i can tell First is to look into the EMF
>> serialization - there might be some way to force the xsi:type;  Second
>> is to modify the cda ecore model and regenerate the code You would
>> change the observation media value to an ANY then when you set the ED
>> it will also set the xsi:type
>>
>>       Again - I want to reiterate that in this case the xsi:type is
>> completely superfluous
>>
>> Hope this helps
>>
>> Thanks for your interest in MDHT
>>
>> Sean
>>
>>
>>
>>
>>
>> On Mar 23, 2016, at 8:07 AM, Axel Helmer <axel.helmer.job@xxxxxxxxx> wrote:
>>
>>> Dear MDHT team,
>>>
>>> I face a minor problem with the value element in the observationMedia
>>> class. For specific reasons I have the requirement that the
>>> xsi:type="ED" element is present in the XML representation of the
>>> element. My code looks like this:
>>>
>>> ObservationMedia om = CDAFactory.eINSTANCE.createObservationMedia();
>>>
>>> ED value = DatatypesFactory.eINSTANCE.createED();
>>> value.setMediaType(mimeType.getCodeValue());
>>> value.setRepresentation(BinaryDataEncoding.B64);
>>> value.addText("B64Foo");
>>> om.setValue(value);
>>>
>>> I am trying to accomplish:
>>>
>>> <observationMedia classCode="OBS" moodCode="EVN">
>>>     <value xsi:type="ED" representation="B64"
>>> mediaType="image/jpeg">B64Foo </value> </observationMedia>
>>>
>>>
>>> What I get is (missing xsi:type="ED"):
>>>
>>> <observationMedia classCode="OBS" moodCode="EVN">
>>>     <value representation="B64" mediaType="image/jpeg">B64Foo
>>> </value> </observationMedia>
>>>
>>>
>>> It seems that the CDA schema permits omitting the xsi:type, but in my
>>> case it´s required. Is there a way to bring it back?
>>>
>>> Thanks!
>>>
>>> --
>>>
>>> Dr.-Ing. Axel Helmer
>>> eHealth Services
>>> Training, Consulting, Software Development
>>>
>>> Baurat-Gerber-Str. 18
>>> D-37073 Göttingen, Germany
>>> Phone: +49 179 478 3239
>>> E-Mail: axel.helmer.job@xxxxxxxxx
>>> _______________________________________________
>>> mdht-dev mailing list
>>> mdht-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/mdht-dev
>> _______________________________________________
>> mdht-dev mailing list
>> mdht-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/mdht-dev
>> _______________________________________________
>> mdht-dev mailing list
>> mdht-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/mdht-dev
>
> _______________________________________________
> mdht-dev mailing list
> mdht-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdht-dev
> _______________________________________________
> mdht-dev mailing list
> mdht-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mdht-dev



-- 

Dr.-Ing. Axel Helmer
eHealth Services
Training, Consulting, Software Development

Baurat-Gerber-Str. 18
D-37073 Göttingen, Germany
Phone: +49 179 478 3239
E-Mail: axel.helmer.job@xxxxxxxxx

Back to the top