Re: [mdht-dev] xsi:type problem in observationMedia/value

[Sean Muir <sean.w.muir@xxxxxxxxx>]

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