Meeting minutes
Security alert: Does it affect our code?
advisories/
tim: Here is the Python used in that repo: https://
tim: It only affects python
tim: I have a suggested related to @Gaurav Vaidya (RENCI) ’s work w3c/
Adding prefixes for the CodeSystems that are part of the “core” spec
ericp: It is only for a DOS attack that would not affect us. Easiest to do nothing.
dbooth: oky
IRI stems
tim: I have a suggested related to @Gaurav Vaidya (RENCI) ’s work w3c/
Adding prefixes for the CodeSystems that are part of the “core” spec
tim: Example usage of a code from a “core” CodeSystem:
The fhir:status of this example: https://
I think it should at least have a fhir:l value, even if not using a prefix there
tim: Some CodeSystems are part of core FHIR, with a couple of different bases
… Many are used in required bindings in the core spec.
… Should we do prefixes for these core CodeSystems?
… One reason we're doing it is for type assertions, and we're not currently doing that for examples that use the core CodeSystems
gaurav: We can put IRI stems on any CodeSystem we want, if we respect balloting rules.
… Makes sense to do that even if we're only formalizing it. Grahame likes to just use a hash separator. We could propose to formalize that, but not sure if it will resolve to an RDF document.
… FHIR core systems are maintained by HL7. I think Grahame would be ok with the hash approach.
… For terminology.hl7.org we're recommending that people dong' tpu IRI stems on CodeSystems at all, because it only has NamingSystems now.
… But it has CodeSystems for HL7 CodeSystems.
… We now have the mechanism to do this. Just need to identify which ones we want IRI stems for, then talk w HL7 to come with IRI stems that we want.
tim: At least w SNOMED and LOINC, each concept has an obvious IRI for each concept/term, but it's not clearly the case for these internal core systems.
tim: Each code within the CodeSystem would not have its own URL.
gaurav: Interestingly https://
tim: One use of this is to add a type assertion. We're only doing it for LOINC, SNOMED and MeSH. We should do it for any codes.
Official docs here https://
gaurav: I think the internal ones all start with hl7.org and end with code-system.
gaurav: Be warned that there are a lot of internal code systems: https://
tim: Diagnostic report status points to http://
gaurav: We should not manually add IRI stems to individual CodeSystems, because there are 400+ of them. So we should use a rule.
gaurav: E.g. IRI stem should be “http://hl7.org/fhir/version-algorithm#”
ken: The largest hl7 valueset is about 150 terms, other than examples.
gaurav: CodeSystem pages for hl7.org/fhir have anchors for the codes.
… But the anchors include the CodeSystem names.
dbooth: redundant.
tim: https://
gaurav: We should propose to put this into the rdf.html page
ACTION: Tim to post on zulip asking Grahame about formalizing adding a hash to hl7 internal CodeSystems to make IRI stems, and putting this rule on the rdf.html page
gaurav: http://
gaurav: https://
… Mark changed it to a pro forma change. It still cannot be moved forward. Jessica Bota is looking into what's wrong.
gaurav: https://
… Also working on a markdown to magically making the IRI stem table of IRI stems
R6 testing
tim: The R5+6 files are ready for testing now: w3c/
ericp: No progress yet.
FHIR ontology
ken: Eric Jahn and I are working on the use case, regarding housing insecurity
… Hope to share something in a couple weeks.
ADJOURNED