Releases: smart-on-fhir/cumulus-fhir-support
1.3.0
This release adds support for extensions on primitive types. I.e. it adds support for "sunder" fields like _status (sibling of status).
See http://hl7.org/fhir/R4/json.html#primitive for more details.
Example:
{
"birthDate": "1970-03-30",
"_birthDate": {
"id": "314159",
"extension": [{
"url": "http://example.org/fhir/StructureDefinition/text",
"valueString": "Easter 1970"
}]
}
}
These fields will be in the resulting schema if they are present in the input rows, else they will be left off.
1.2.1
1.2.0
This release adds three new methods for reading NDJSON:
list_multiline_json_in_dir
: scans for files & their resource typesread_multiline_json
: returns line by line results from a fileread_multiline_json_from_dir
: returns line by line results from a folder
Headline features:
- Lets you filter by FHIR resource type (by actually inspecting the contents of a file, rather than playing guessing games with filenames)
- But these functions are not restricted to FHIR-based JSON, you can read arbitrary multi-line JSON too
- Transparently handles I/O and decode errors by logging a warning and continuing - these are designed for bulk processing
- You can read from remote filesystem locations using the optional
fsspec
support - Supports both NDJSON and JSON Lines formats
1.1.0
Contained resources (sub-resources found in the "contained": [...]
field) now contribute to the schema. (Previously, contained
would just hold a bare bones schema for the root Resource type.)
Every contained resource found in the provided rows gets its fields added, as long as that field exists in any of the resources mentioned by contained resourceType
schemas.
Example:
"contained": [
{"resourceType": "Medication", "code": {...}},
{"resourceType": "Encounter", "status": "planned"}
]
For the above JSON, the final schema would include both contained.code
and contained.status
.
See https://github.com/smart-on-fhir/cumulus-etl/issues/250 for a discussion of whether this kind of contained handling is the best approach. But it's arguably better than ignoring the contained resources altogether.