Stream: implementers
Topic: fhir validator vs PHINVADs valuesets and codesystems
Saul Kravitz (Aug 05 2021 at 17:19):
I'm working with an IG that makes extensive use of PHINVADs-hosted valuesets and codesystems. (No need for editorial comment on the wisdom of this choice, I'm perfectly capable of whining about it.).
Is there a way to coerce the FHIR validator to leverage PHINVADs resources so that it can validate code references to valuesets hosted by PHINVADs, that consist of system references to PHINVADs OIDS?
Lloyd McKenzie (Aug 05 2021 at 17:30):
@Rob Hausam
Rob Hausam (Aug 05 2021 at 18:56):
@Saul Kravitz There are a few ways that come to mind that should be able to make this work for you. It mainly involves having the code system and value set contents available in some place that the IG Publisher and Validator can access and use with the build terminology server (this content won't be obtained directly from PHIN VADS, as you've observed - at least that doesn't happen currently). So, to do this we would need to replicate the relevant PHIN VADS content (assuming that licensing permits - which probably would be the case) as FHIR code system and value set resource instances in either: (1) directly in your IG, or (2) THO (terminology.hl7.org) or (3) the FHIR build terminology server (tx.fhir.org). With PHIN VADS being a standard terminology provider, I don't think that replicating it in your IG is going to be the best (or even an acceptable) long term choice - even though technically that should work. There is some precedent for including "convenience copies" of other standard terminology content in THO, so it is a possibility (you probably would would need/want to discuss with both HTA and CDC before doing that and submitting UTG proposals). If the content is added to the terminology support packages and loaded on tx.fhir.org, that's not as visible externally (so it may be less of a potential issue with HTA and CDC), but it still should be functional for building the IG. So I'm probably leaning toward #3 as the direction I would try to go. The quickest "solution", though, if you need something temporarily that works right now, would be #1 - even though you probably can't publish the IG that way. There are some gray areas and questions to be answered, but that's my take at the moment.
Saul Kravitz (Aug 05 2021 at 20:49):
Hi @Rob Hausam Thanks for the quick response.
#1 is workable if the Valueset in PHINVADs is comprised of codes from an existing non-PHINVADs codesystem. For example the PHINVADs-hosted Place of Death valueset is comprised of SNOMED and null-flavor codes that the THO supports already. I don't understand the value of hosting this in PHINVADs over hosting it in the IG itself. Many of the PHINVADs-hosted value sets are of this type.
For #2 or #3: How would the valuesets and codesystems be referenced in the IG? Currently, PHINVADs-hosted valuesets are represented by binding to something like this. https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.1038. Would the reference then simply be to the OID? Would an HL7 url be allocated? Codes in PHINVADs-hosted valuesets are associated with codesystems that are identified only by an OID. As I pointed out above, many of these codesystems are 100% redundant with existing HL7 codesystems. Problem?
#2 seems to have happened for the race/ethnicity codes whose source is in PHINVADs, e.g. http://hl7.org/fhir/us/core/STU3.1/ValueSet-detailed-race.html .
Saul Kravitz (Aug 06 2021 at 14:29):
I've summarized my analysis of the status quo for the VRDR IG here https://jira.hl7.org/browse/FHIR-33149
Sarah Gaunt (Sep 28 2021 at 21:18):
Seeing this late, sorry. So the bindings to Phin Vads should be represented like: http://phinvads.cdc.gov/fhir/ValueSet/{oid}. Then you get nicer bindings in the IG (and theoretically, the validator can validate because there is a FHIR package that includes a download of all the Phin Vads value sets. (e.g. https://build.fhir.org/ig/HL7/fhir-bfdr/StructureDefinition-Condition-abnormal-condition-of-newborn.html). You also have to add a dependency to the IG in question. See this thread: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Referencing.20PHINVads.20Value.20sets
BTW, I am NOT saying we should keep these value sets in Phin Vads... I'm also unsure whether the validation is currently working properly or not. It does sound like this is not the path we maybe should be working towards.
Also - my two cents on the value of hosting value sets externally and not in the actual IG are for the flexibility of updating the value sets. For some value sets it doesn't matter, but for value sets that are likely to change, it's an issue. To update the value set, you must also update the IG. If you reference the latest version of a value set that resides in VSAC, you can simply update the value set in VSAC without having to update the IG.
Peter Jordan (Sep 28 2021 at 23:42):
Sarah Gaunt said:
Also - my two cents on the value of hosting value sets externally and not in the actual IG are for the flexibility of updating the value sets. For some value sets it doesn't matter, but for value sets that are likely to change, it's an issue. To update the value set, you must also update the IG. If you reference the latest version of a value set that resides in VSAC, you can simply update the value set in VSAC without having to update the IG.
Great points @Sarah Gaunt . Maybe using intensional value sets in IGs is one solution although, of course, that requires a terminology server to provide expansions. It will certainly be an issue for Affiliates producing Base National IGs if the proposal to tie these into the HL7 International balloting cycle is implemented. There's an obvious trade-off between ease of presentation to implementers and IG maintenance. We had a lengthy debate about this in NZ and came out in favor of placing most NZ reference terminologies in the Base IG - but we can't do that for any Code System that's updated on a regular basis, e.g. NZ Medicines Terminology.
Sarah Gaunt (Sep 29 2021 at 04:48):
Yes, definitely agree for intensional value sets. Problem is, most of the time we're unfortunately dealing with extensional value sets - especially the ones in Phin Vads that are using the local CDC code systems.
We have managed to get a couple of the NHSN local CDC code systems loaded into VSAC which seems to be working well, but I'm not sure whether that is feasible for the other code systems in Phin Vads (or even whether VSAC is a viable option - we seem to be having similar problems with validation with VSAC as we are with PhinVads (though I think this is mostly because Grahame has a such a large back log and there is an issue with the process that downloads the VSAC value sets to the FHIR package for use with the terminology server).
Sarah Gaunt (Sep 29 2021 at 04:51):
And you've made me think a bit - I wonder if, for death reporting, the cause of death value sets might actually be intensional. I'm not sure how it's defined, but we definitely need to look into that...
Last updated: Apr 12 2022 at 19:14 UTC
