cqframework / clinical-reasoning

CQF Clinical Reasoning on FHIR for Java
https://www.cqframework.org/clinical-reasoning/
Apache License 2.0
33 stars 24 forks source link

Missing support for externalized content when using HAPI FHIR #478

Open jkiddo opened 3 weeks ago

jkiddo commented 3 weeks ago

The functionality here: https://github.com/cqframework/clinical-reasoning/blob/f4843b3b58d39ae9b4632c3fc6703893ae4f74ef/cqf-fhir-cql/src/main/java/org/opencds/cqf/fhir/cql/cql2elm/content/BaseFhirLibrarySourceProvider.java#L49 is missing HAPI FHIR support when used together with the externalized content feature as documented here: https://smilecdr.com/docs/fhir_repository/binary_data.html#externalized-binary-storage as it missing to look up the HAPI FHIR defined extension on the data field if used. Example of piece of data as follows:

{
    "resourceType": "Library",
    "id": "14",
    "meta": {
        "versionId": "1",
        "lastUpdated": "2024-06-09T20:52:41.320+02:00"
    },
    "url": "http://trifork.com/Library/LastDueDate",
    "identifier": [
        {
            "use": "official",
            "value": "LastDueDate"
        }
    ],
    "version": "1.0.0",
    "name": "LastDueDate",
    "status": "active",
    "experimental": false,
    "type": {
        "coding": [
            {
                "system": "http://terminology.hl7.org/CodeSystem/library-type",
                "code": "logic-library",
                "display": "Logic Library"
            }
        ]
    },
    "date": "2024-06-06",
    "content": [
        {
            "contentType": "text/cql",
            "_data": {
                "extension": [
                    {
                        "url": "http://hapifhir.io/fhir/StructureDefinition/externalized-binary-id",
                        "valueString": "N7UFAtfVcrpt88IJZCdQFqCDFimQf3mlHuHQbvWLupfiEcIOQNRZ515N2a1V89d1TQg2afKf3kY7WtsKxO1OsYVAz7kMlOsVyUZG"
                    }
                ]
            },
            "size": 386
        }
    ]
}
jkiddo commented 2 weeks ago

I guess one way to fix it would be to extract this https://github.com/cqframework/clinical-reasoning/blob/d45dc73186dd5b347ee863b7d4a170d5f99de3cc/cqf-fhir-cql/src/main/java/org/opencds/cqf/fhir/cql/Engines.java#L189 and let the adaptors from the factory do the lifting. Then everything else could be left untouched.

jkiddo commented 1 week ago

@barhodes I can do a PR that fixes it but it will have quite the impact on the current architecture. Due the static design on CqlEngine and the switch statements for obtaining a AdapterFactory I'd prefer a discussion before heading into a PR adventure. I did the original design on e.g. https://github.com/hapifhir/hapi-fhir-jpaserver-starter/blob/master/src/main/java/ca/uhn/fhir/jpa/starter/annotations/OnEitherVersion.java and I would suggest to head the same direction - having the version of the AdaptorFactories being bound to configs outside the CqlEngine - or at least injected into it. There isn't many Spring annotations in the existing codebase and I assume you guys would prefer it stays that way? Preferrably and overall I would suggest let the specific AdaptorFactory be constructed by Spring and let that be arried through the different places. Let me know what you think.

barhodes commented 3 hours ago

@jkiddo Apologies for the delayed response. We've been discussing this internally and have a few ideas for solutions. We would like to avoid putting this logic into the Adapters themselves and are currently leaning towards adding support for the extension into the BaseFhirLibrarySourceProvider.

Do you have some time next week we could meet to discuss so we can better understand what your use case is here and talk through some potential solutions?