bug in validation operation

[fokusfpa]

When using the operation for validation there is a bug which throws an error if the fhir server says the resource is valid.

// code for validation operation
final Parameters parameters = Parameters(
  parameter: [
    ParametersParameter(name: 'resource', resource: extendedQuestionnaire),
  ],
);

final request = FhirRequest.operation(
  type: R4ResourceType.Questionnaire,
  base: baseUrl,
  operation: 'validate',
  usePost: true,
  fhirParameter: parameters,
);

The issue is here.

The code is

OperationOutcome operationOutcome = OperationOutcome.fromJson(
    body['response'] as Map<String, dynamic>); 

but it should be

OperationOutcome operationOutcome = OperationOutcome.fromJson(
    body as Map<String, dynamic>);

because the server response looks like this and doesn't have a response key.

The result body:

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "information",
            "code": "informational",
            "diagnostics": "No issues detected during validation"
        }
    ]
}

When the not existing response key gets casted an Exception is thrown because null is not of type Map<String, dynamic>.

Should I open a pull request or what do you think about this @Dokotela ?

[Dokotela]

I've finally pushed a version of fhir_r4 and fhir_r5. The base package was growing too big. But these new versions include all of the other packages too. So they each have the base package, fhir_at_rest, fhir_auth, fhir_path, fhir_bulk, and fhir_db. They're also much smaller than the old version (partly because the main branch doesn't have any of the tests). Please try them out and let me know if you run into issues. It also takes care of that OperationOutcome issue by just returning the OperationOutcome in your example.

[luis901101]

Thanks @Dokotela It is good to know that the fhir packages continue to be maintained, and also good the separation by FHIR version, but not so good to have all the packages bundled together, not all apps need to use all packages, so unnecessary dependencies would be included. Also I didn't noticed about this new versions of the packages because they are not provided by the same verified publisher: fhirfli.dev 🤔

[Dokotela]

@luis901101 thanks for the comment! And also thanks for your Questionnaire package.

You are correct, and I forgot to move the packages over to fhirfli.dev. They are now moved though, so that issue is fixed.

As for the unnecessary dependencies, I agree, but I'm not sure the best way to manage it. The FHIR package was getting too big to work with (VSCode would lock up, pub.dev would break when trying to analyze it, etc.). And since most people only use a single version of FHIR, it seemed to make sense to put them into a single package, and that way you would have all of the functionality that you would need in one place. I had (briefly) considered breaking up each smaller package by version (but fhir_r4, fhir_r4_at_rest, fhirpath_r4, etc, but for dstu2, stu3, r4, r5, r6 seemed too much to manage).

Were there specific packages that you were running into issues with?

I'm also open to suggestions if you think there could be a better way to group the different libraries.

[luis901101]

@Dokotela yeah, separate FHIR versions on individual packages was the right call, but including all complement packages in one package is what I see overkill, I mean including all of this:

• fhir
• fhir_at_rest
• fhir_auth
• fhir_bulk
• fhir_db
• fhir_path
• fhir_yaml

into one package fhir_r4 seems like too much. For instance I have been working in a project for several months and I only use fhir types and fhir_at_rest. Also I created this package fhir_questionnaire and it only uses fhir types and fhir_path. So for me to migrate to the new fhir_r4 would be to include a lot of dependencies that I don't use and this also means possible conflicts with transitive dependencies, etc. Off course could be other devs that uses most of the packages and having it all together could be good, but it's hard for me to think that avg devs would need all those packages together. I also understand from a Package Publisher PoV is hard to maintain all the packages individually but this also have other advantages like fixing specific package issues without having to publish a whole new version of the big package... I don't know it's just my opinion, and by the way you have made a really great job with this packages 👍.