Stream: cql
Topic: URL reference to CQL
Larry Decelles (Mar 11 2021 at 20:16):
@Bryn Rhodes or others, does this snippet of example code (below) assume there is no auth mechanism to get access to the CQL file?
,
"content": [
{
"contentType": "text/cql",
"url": "http://cqlrepository.org/CMS9v4_CQM.cql"
}
]
}
Larry Decelles (Mar 11 2021 at 20:24):
This is where the example is from: https://www.hl7.org/fhir/library-exclusive-breastfeeding-cqm-logic.json.html
Bryn Rhodes (Mar 12 2021 at 00:12):
That example is silent on that aspect. Best practice is to include the content base-64 encoded, but those examples were put together before that best practice was really supported by the tooling. Now, the publisher will actually pull the CQL in, translate it to ELM, and base-64 encode it into the Library resource.
Larry Decelles (Mar 12 2021 at 17:59):
Thanks @Bryn Rhodes, my question is actually more of a process/standard question. In a Library resource you can refer to CQL with a relative path, URL, or base-64 encoded. At our Burden Reduction meeting on Wednesday. Someone suggested that relative paths should not be allow. Implying only base-64 or a full url be allowed. So, my question was if we require a full URL how does the auth work if any? I understand base-64 is still a best practice.
Bryn Rhodes (Mar 12 2021 at 18:23):
I think the answer there would be the same as it would be for any fullUrl (i.e. in Attachments that appear anywhere in a FHIR resource, or a Media, or a Binary). I agree there should be some guidance there, but I'm not sure it's specific to Library attachments. The only thing I can find in the base spec is here: http://hl7.org/fhir/security.html#attachments
Larry Decelles (Mar 12 2021 at 22:06):
Thanks @Bryn Rhodes !
Last updated: Apr 12 2022 at 19:14 UTC
