Stream: implementers
Topic: fhir_comments
Richard Ettema (Jan 06 2017 at 01:56):
Can someone confirm whether or not the JSON representation in STU3 (v1.8.0+) supports "fhir_comments"? It looks like it is no longer part of the spec.
Peter Jordan (Jan 06 2017 at 02:44):
It's still exposed by the C# library for FHIR version 1.8.0 ( @Brian Postlethwaite ). Along with others, I was using it in CapabilityStatement.rest.operation to denote individual operations that are supported in batch mode. Maybe there is, or should be, a better way to inform clients of this particular capability?
Brian Postlethwaite (Jan 06 2017 at 03:21):
What is still exposed Peter?
Peter Jordan (Jan 06 2017 at 03:26):
The CapabilityStatement.OperationComponent.FhirComments property.
Grahame Grieve (Jan 06 2017 at 03:32):
it's been removed rrom JSON and is no longer valid. Comments can still appear in XML
Peter Jordan (Jan 06 2017 at 03:36):
Why are Fhir_comments valid in the XML format, but not in JSON?
Grahame Grieve (Jan 06 2017 at 06:54):
xml comments. we're not going to make comments in xml invalid
Grahame Grieve (Jan 06 2017 at 06:54):
but we stopped making special arrangements to allow comments in json
Peter Jordan (Jan 06 2017 at 08:03):
That's going to cause some challenges for those implementing both formats. My initial thought is not to use Fhir_Comments until/unless my reference library of choice handles this distinction at serialisation time.
Brian Postlethwaite (Jan 06 2017 at 08:04):
The comments are clinically meaningless, and only useful for annotating the examples.
Peter Jordan (Jan 06 2017 at 08:07):
I was using them in my Capability Statement to denote when individual terminology operations are supported in batch mode (Ontoserver also does this). However, there must be a better way of doing this than via comments? It's useful information for a terminology client.
Brian Postlethwaite (Jan 06 2017 at 08:10):
Maybe an extension would be more useful there.
Pascal Pfiffner (Jan 06 2017 at 16:16):
Peter, that wouldn't work with all clients, fhir_comments was only intended for those looking at the bare JSON resources. Our Python and Swift clients ignore fhir_comments so they don't say “invalid JSON”, but would not parse the contents of that property. I'd also suggest you use an extension.
Michael Lipton (Jun 09 2021 at 13:05):
If I receive a 4.0.1 FHIR resource in XML with comments, should that be stored and served up in the JSON representation of the FHIR resource under Resource.identifier.fhir_comments? Or should the comments in the XML be ignore? I saw that the fhir_comments was present in DSTU2 but not present in STU3
Lloyd McKenzie (Jun 09 2021 at 14:09):
Per the JSON page in the spec "comments SHALL not be in JSON instances irrespective of whether particular applications ignore them"
Last updated: Apr 12 2022 at 19:14 UTC
