Stream: social
Topic: Converting FHIR bundle into a human readable format
Jay Chitalia (Oct 27 2019 at 12:45):
How do I convert the huge FHIR data that is in JSON format to a more human readable format like say Excel or csv file? Is there a solution available for this? Please help me out here.
Lloyd McKenzie (Oct 27 2019 at 14:03):
Excel and CSV aren't significantly more human-readable than JSON. However, the biggest challenge is that Excel & CSV don't support complex nested structures. Instead, you have to work to flatten the data somehow - and how you go about doing that depends on the nature of the data and how you want to view it. For example, Patient addresses can repeat and have complex parts. Do you want to handle that by adding a separate row for each address part within each address in the "patient" tab or do you want to have a separate tab for patient addresses? How would you want the Patient.contact.address .line rendered? (where contact, address and line can all repeat)
Lloyd McKenzie (Oct 27 2019 at 14:05):
Because the answer depends on "what am I going to do with it after" (which is typically to do mapping, in turn driven by what you're mapping to), there isn't a one-size-fits-all algorithm and thus no standard way of doing this in the core spec. Implementation guides do have an ability to generate both Excels and CSVs, but the standard framework doesn't yet turn this one. That's for displaying the data models though, not instances.
Jay Chitalia (Oct 28 2019 at 06:23):
@Lloyd McKenzie Thank you for the reply. I understand that converting it into a Excel or CSV with flattening the data is dumb. So how would you go about converting it into a human readable format from JSON. What is the best way a human can read the FHIR bundled data?
Jose Costa Teixeira (Oct 28 2019 at 06:32):
Hi. JSON format is actually pretty human-readable. At least more than CSV IMO.
Knowing what you are trying to dowould help - what is your goal? WHo needs the data in a more human readable format? You mention a huge FHIR data - but is it to show to a physician (why?) or to have a technical person understand better (why not JSON) or is it the large amount of data that is scary...?
Who is the human that needs more friendly data?
FHIR is a transport standard, end users typically don't need to see it.
Kevin Mayfield (Oct 28 2019 at 12:41):
We had something similar to this with FHIR Documents
Kevin Mayfield (Oct 28 2019 at 12:42):
pasted image
What we did was build an app that converted the structured content into a format a non technical user would be familiar with (see the Allergy Intolerance in the image)
Kevin Mayfield (Oct 28 2019 at 12:43):
In theory that would work with any bundle (as long as we had a component to render the resource)
Lloyd McKenzie (Oct 28 2019 at 13:07):
Most, if not all, resources should include a narrative which is intended to be the "human readable" view of the human-relevant information in the resource. The simplest thing to do is to use that. If you're not receiving narratives for some reason, you can generate your own. FHIR currently has a fairly 'simple' (i.e. not too elegant or pretty) narrative generator that we use in the specification you could leverage, but it's aimed more at people debugging examples than it is at clinicians. In theory, IGs will soon start to have Liquid templates that support narrative generation that is tuned to the expectations of those templates, however don't know how far that is in practice. In any event, converting the resources to XHTML is probably the most appropriate solution - you can use that as narrative if you don't already have one, it handles nested structures better, and it gives you more control over what content looks like. In deciding what that HTML should look like, you'll need to consult your users. Different people will have different ideas about what data is 'important' enough to include, as well as what order things should appear in, what the data should look like, etc.
René Spronk (Oct 28 2019 at 13:48):
I'd have no qualms at all in generating my own XHTML even if there always was text, especially if that original text was 'generated'. The FHIR standard is relatively silent on this (AFAIK), but my requirements for text may be rather different from those of the originator of the resource. If the existing text is 'additional' then we have a problem: should I risk a potential loss of semantics, even though that means that the XHTML snippet won't have the formatting which is desirable for my own context ? Choosing XHTML rather than some intermediate format has advantages, but also clear disadvantages.
Lloyd McKenzie (Oct 28 2019 at 14:04):
The only thing to be cautious about is if the original instance includes extensions that you don't recognize. You're free to display your own HTML, but you should make the original narrative available too
Joel Schneider (Oct 28 2019 at 17:17):
If you're interested in formatting the JSON, with indentation to increase readability, etc., you could use jq.
https://stedolan.github.io/jq/
Lloyd McKenzie (Oct 28 2019 at 17:28):
JSON is human-readable for a developer, but not realistically for a clinician or other business user (no matter how prettily you print it)
Joel Schneider (Oct 28 2019 at 18:02):
jq is also able to extract specific data elements from the JSON, or act like a JSON query language, or even convert some slice of the JSON data to CSV ... if it makes sense to do those things.
Grahame Grieve (Oct 28 2019 at 22:29):
my general feeling is that if you want to present all the data to a human, YAML (which is algorithmically generatable from the json) is the least worst option. But: it's still only good for data centric people and they might as well just look at the json or xml forms.
Otherwise: the essence of the task is decide what this particular type of human needs to see, and why, and which detail to put in narrative directly and which to hide in mouse overs/more buttons.
So it's real work to inject value. And then you need some language in which to express that. There's 100s to choose from....
Last updated: Apr 12 2022 at 19:14 UTC
