FHIR Chat · Parsing FHIR File Extracts · dotnet

Stream: dotnet

Topic: Parsing FHIR File Extracts


view this post on Zulip Gregg Ripley (Jul 01 2021 at 20:03):

Greetings. I am an experienced software engineer with very much beginners knowledge of FHIR and message structures. I recently been tasked with converting a set of json FHIR file extracts so I can load them into a relational DB (i.e. SQL). I am struggling to understand how to parse these files as I am getting parsing errors. For example, I am attempting to parse the "Condition" entity and I get this error: "Exception thrown: 'Hl7.Fhir.ElementModel.StructuralTypeException' in Hl7.Fhir.Support.dll
Additional information: Type checking the data: Encountered unknown element 'resourceId' at location 'Condition.resourceId[0]' while parsing
"

My environment is .NET and leveraging the R5 Core SDK library. The data set's documentation indicated as "These resources are FHIR R5 preview 2 (version 4.4) compliant. ". The data is in .JSON representation with a single extract in each folder. Each folder represents a data entity (condition, patient, encounter, etc). A sample of a single line is demonstrated at the end of my message.

I apologize if this is the wrong group or message board for this type of posting. If that is the case, please direct me to the appropriate location. Any help on this would be greatly appreciated. If I could be directed to a good resource would be equally appreciated.

Thanks
Gregg


Release Format
FHIR and FHIR+ resources are delivered in new line delimited json files (ndjson). Schema files are delivered as a text file that contains a json object.

FHIR Resources
FHIR resources have the following top-level keys/values:
 resourceId – logical id, an extraction of resource.id
 resource – FHIR resource content
Further information regarding the structure of each resource can be found by referencing the corresponding hl7.org FHIR schema.

{
"resourceId": "{GUID}",
"resource": {
"abatementDateTime": "{DateTime}",
"clinicalStatus": {
"coding": [
{
"code": "{integer}",
"display": "{condition display}",
"system": "{systemId}"
}
],
"text": "Resolved"
},
"code": {
"coding": [
{
"code": "{integer}",
"display": "{condition display}",
"system": "{systemId}"
}
],
"text": "{Symptom Description}"
},
"id": "{GUID}",
"identifier": [
{
"system": "{SystemURL},
"type": {
"coding": [
{
"code": "{Code Name}",
"display": "{Code Name}",
"system": "{SystemURL}"
}
],
"text": "{Code Name}"
},
"use": "{use}",
"value": "{Integer}"
},
{
"system": "{System Id},
"type": {
"coding": [
{
"code": "{Code}",
"display": "{Display}",
"system": "http://hl7.org/v2/diagnosis-id"
}
],
"text": "DXID"
},
"use": "{use}",
"value": "{Integer}"
}
],
"meta": {
"lastUpdated": "{DateTime}"
},
"onsetDateTime": "{DateTime}",
"resourceType": "Condition",
"subject": {
"reference": "{Guid}",
"type": "Patient"
}
}

view this post on Zulip Michele Mottini (Jul 01 2021 at 20:13):

As I wrote in #implementers : the Condition resource is just the "resource" object, not the entire JSON, so you should extract and parse only that piece

view this post on Zulip Gregg Ripley (Jul 01 2021 at 21:01):

Thanks @Michele Mottini for the reply. I was thinking I could take the file "as-is" and parse as it was given to me. With a little bit of "parsing the resource" file, I was able to successfully parse a record (i.e. Condition in this case as a POC). I just need to rifle through each given fileset as provided to me and rip out the actual object contained in the "resource" object just as you said. Thanks a ton!

view this post on Zulip Brian Postlethwaite (Jul 01 2021 at 22:17):

That doesn't lookike a valid fhir json structure.

view this post on Zulip Brian Postlethwaite (Jul 01 2021 at 22:19):

Is doesn't have the resourceType: "Condition" property and the id property is not named right.
Might want to recheck some examples from the R5 spec to compare.

view this post on Zulip Gregg Ripley (Jul 01 2021 at 23:09):

@Brian Postlethwaite , When I posted, I copied and didn't want to relay any potential PHI so I obfuscated it heavily out of caution. Also, the "resourceType": "Condition" is present if you look 6 lines from the bottom up. I was able to successfully parse the "Condition" object as it was embedded in a "resource" object. However, I was hoping I could parse the "resource" object and then retrieve the "resource" and cast it as a Condition. When I try to parse it as a "resource", I get similar parsing errors. What I plan to do is rifle through the raw extracts and rip out the "Condition" objects (and all the other objects such as Patient, Encounter, etc) and parse those. That's the plan anyway after successfully parsing the first one.

I have a team of analysts that just received this data extract and need to quickly review it. This team are all SQL folks. I need to convert this to simple SQL tables (no relationships at this point, just raw viewable data).

view this post on Zulip Brian Postlethwaite (Jul 02 2021 at 03:45):

Sorry, missed the resoureType in there as you point out.
The fhir parser won't be able to understand your custom wrapper that is around it - has that come straight out of the DB of Spark or HAPI or something like that?
(also interesting that the ResourceID property in your custom wrapper isn't in the id property on resource itself...)
To process that, you'd need to extract the resource from the wrapper, and then the FHIR serializer should be able to handle that no problem, and you could cast that to the Condition (or just parse using the generic with Condition, and remove the need to cast too)

view this post on Zulip Gregg Ripley (Jul 02 2021 at 19:57):

@Brian Postlethwaite , to your point, I am stripping out the 'wrapper' of the actual FHIR object and it's working great. I am going to examine recreating these JSONHD files and see if I can import them into an instance of the FHIR server (SQLite) via the VonkLoader. With this, my thinking is to export to an equivalent MS SQL so we can review the data. I am still working through it, but so far, I'm making progress. I appreciate all the feedback!

view this post on Zulip Brian Postlethwaite (Jul 02 2021 at 21:56):

Good to hear.


Last updated: Apr 12 2022 at 19:14 UTC