Problems of all kinds came to notice in my last batch of FHIR development.
The
Problem resource was implemented! Importantly it should be noted that this has the tag "
Status: Not an approved resource" so basically fills the space until the discussion is done. After seeing some of the diagnosis vs concern vs problem discussion of the past this may take some commitment to accept 'good enough' for draft standard. Committee discussions are due Thursday 18 April at 5:00pm to 6:30pm US Eastern -
TC Details.
Try out some examples
http://demo.oridashi.com.au:8190/problem/@30
http://demo.oridashi.com.au:8190/problem/@32
Some other problems also came up whilst getting this done:
#1 Type Choice I never read the specification properly with respect to 'choice' attributes - which just goes to prove you can kind of implement FHIR without reading the documentation too well. The
key words from the spec are:
When a logical element can have more than one type, it's name takes the form nnn[x]. The "nnn" part of the name is constant, and the [x] is replaced with the name of the type that is actually used. The types that are allowed are listed with a "|" used to separate them
For example from the
Problem resource a couple of the attributes have a type choice:
<onset[x]><!-- 0..1 date|Age Estimated or actual date, or age --></onset[x]>
<abatement[x]><!-- 0..1 date|Age|boolean If/when in resolution/remission --></abatement[x]>
So this really equates to elements named:
onsetDate,
onsetAge and
abatementDate,
abatementAge,
abatementBoolean. In my case
onsetDate and
abatementBoolean suit my source data best so they are what you see in the examples.
In my hasty initial implementation my code generation skipped over all the type choices and instead just chose the first type listed and the element name without the type. Only when I looked for my
abatementBoolean to mark problem as 'inactive' did I discover my implementation hole.
So to get by I went for my classic xsd.exe style choice for XML serialization:
[XmlElement(ElementName = "onsetDate", Type = typeof(FhirDate))]
[XmlElement(ElementName = "onsetAge", Type = typeof(FhirAge))]
public object Onset { get; set; }
All fine right? Now try and get it done with JSON serialization... Hmmmm.... how do I do a 'choice' in JSON? If you have suggestions let me know - this is what I came up with...
Using Newtonsoft.Json add
[JsonIgnore] to the above.
Then add specific properties for each type - note this is only good for my read/only needs e.g.
[JsonProperty(PropertyName = "onsetDate", Order = 9)]
public FhirDate OnsetDate { get { return Onset as FhirDate; } }
[JsonProperty(PropertyName = "onsetAge", Order = 10)]
public FhirAge OnsetAge { get { return Onset as FhirAge; } }
It will do for today! It means when value is set then correctly named JSON data is produced.
#2 Text Encoding did it to me again... so many times I have got this wrong... I shouldn't mess it up but I often do. I don't think I am alone ;).
FHIR specification has:
The character set for a resource is always Unicode, encoded in UTF-8. Specifying the character encoding in the XML is optional but recommended.
Yes it was wrong - now I think it is right! Take note and take care!
I think I need to take a serious look at the
Connectathon 3 scenarios... maybe next blog.
Reference - Oridashi Hiasobi FHIR Server:
http://www.oridashi.com.au/fhir
