FHIR export resource type filter #1178
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1178 +/- ##
==========================================
+ Coverage 79% 80% +1%
- Complexity 3407 4017 +610
==========================================
Files 135 137 +2
Lines 23028 26003 +2975
Branches 3125 4148 +1023
==========================================
+ Hits 18239 20862 +2623
- Misses 3809 4097 +288
- Partials 980 1044 +64
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
|
dehall
changed the title
|
Marking this as ready to review per separate conversation -- Patient and Encounter will always be required, and if people like this approach and want it for FHIR DSTU2 or STU3 I'll copy it over, pending any other suggestions. |
|
@dehall this is awesome stuff that I would love to begin using! Would it be possible to include a filter for |
|
@KevinCranmer thanks and good catch, that was an unintentional omission. I've now added a check for Provenance. I'll remind our team this is ready for review and hopefully we can get it merged soon |
There was a problem hiding this comment.
The only thing I would say is that many reasons are now lost, even if they are known.
For example, assume we are exporting only MedicationRequest resources.
If a MedicationRequest has a reason, but Condition is filtered out, then MedicationRequest.reasonReference is not populated (as expected)... however, because the reasonCode is known, you should be able to populate the MedicationRequest.reasonCode.
Do you want to make a change now or in a separate PR?
|
Sounds good, I'll make that change now unless it turns out to be a lot more complex than it seems |
| // normalize filenames by trimming | ||
| files = files.stream().map(f -> f.trim()).collect(Collectors.toList()); | ||
|
|
||
| // TODO: convert these into FHIR resource enums |
There was a problem hiding this comment.
Instead of using an enum you could use the class. E.g. Class clazz = Class.forName("org.hl7.fhir.r4.model." + className).
This function could return a List<Class> instead of List<String>
The Class.forName method can throw a ClassNotFound exception. You could use that to catch spelling errors in the list of resources to include/exclude.
| @@ -267,75 +320,108 @@ public static Bundle convertToFHIR(Person person, long stopTime) { | |||
| for (Encounter encounter : person.record.encounters) { | |||
| BundleEntryComponent encounterEntry = encounter(person, personEntry, bundle, encounter); | |||
|
|
|||
| for (HealthRecord.Entry condition : encounter.conditions) { | |||
| condition(person, personEntry, bundle, encounterEntry, condition); | |||
| if (shouldExport("Condition")) { | |||
There was a problem hiding this comment.
If you take my suggestion above about using classes instead of strings, this would become shouldExport(Condition.class) which would make it less prone to typo errors.
|
@hadleynet I like the idea but there are a couple ways the Java code winds up being a little less elegant in practice. 1) To prevent compiler warnings, we can't use just Neither is the end of the world obviously but if people think this is ugly then I can try something else. I've pushed that change to a separate branch |
|
You might be able to get away with PersonalIy, think the type-safety aspect is worth the extra effort. |
|
Ok I've gone ahead and added the type-safe changes here. Rather than change more unrelated lines I'll keep the fully qualified FHIR class names where necessary |
Addresses #1104
Adds new config settings to support filtering the resource types that are exported in the FHIR exporter, by either an include list or exclude list. (Similar to the existing feature for CSVs)
This approach checks each resource type before instantiating the relevant HAPI resource class.
A few notes on current status:
This also includes a tweak to build.gradle to fix some error messages I was seeing in Eclipse. The issue was that JSBCL includes JUnit 4.10 as a transitive dependency, but we use JUnit 4.13 as a direct dependency for tests. Eclipse was getting confused and using JUnit 4.10 at compile time and it didn't recognize some method calls. The tweak removes the transitive dependency on JUnit from JSBCL because I don't think there's any need for the main build to include JUnit.