Stream: IG creation
Topic: validation of orphaned resources in message Bundle
Kevin Mayfield (Nov 09 2021 at 06:04):
In our tests we have an example where a resource is not referenced in a MessageHeader.focus or by any resource referenced by these resource.
The resource fullUrl is urn:uuid:c7d942f2-3c1d-4d93-9ba8-ba57db83cdc0 at line https://github.com/NHSDigital/IOPS-Validation/blob/main/Examples/fail/Bundle-prescription-order-extraMedicationRequest.json#L508
I believe this used to throw up errors.
Kevin Mayfield (Nov 09 2021 at 06:07):
This is via HAPI FHIR Validation
Grahame Grieve (Nov 09 2021 at 06:47):
does the standalone validator say it's a problem
Kevin Mayfield (Nov 09 2021 at 06:48):
Nope, clean except for coding errors
Grahame Grieve (Nov 10 2021 at 03:45):
hmm, well, we should do something about the coding errors, and put UK SCT on tx.fhir.org
Grahame Grieve (Nov 10 2021 at 04:11):
and it's not an error because the resource in question refers to other resources in the message - patient, etc. Just like a provenance resource would, which is why this is allowed.
Grahame Grieve (Nov 10 2021 at 04:34):
but it's not a resource that you'd expect to be used that way, so the next version of the validator will give this output:
WARNING: Bundle.entry[10]: Entry 'urn:uuid:c7d942f2-3c1d-4d93-9ba8-ba57db83cdc0' isn't reachable by traversing forwards from first Bundle entry, and isn't a resource type that is typically used that way - check this is not missed somewhere
Kevin Mayfield (Nov 10 2021 at 04:38):
Great. I've reconfigured out profiles to generate errors use bundled so we should be left with that warning for the orphans
Kevin Mayfield (Nov 10 2021 at 04:47):
We do have a UK Onto server but it's using OAuth2. I'm working on an HAPI interceptor to get around that
Kevin Mayfield (Nov 10 2021 at 04:48):
Grahame Grieve (Nov 10 2021 at 04:50):
I'm not sure why tx.fhir.org doesn't support UK SCT. I think no one has ever asked?
Grahame Grieve (Nov 10 2021 at 04:51):
@Rob Hausam do you have any memory of this?
Rob Hausam (Nov 10 2021 at 05:08):
@Grahame Grieve @Kevin Mayfield Yes, I sure do. I've been trying for months to get the UK extension(s)/edition loaded. As you know, I've gotten things to work now with the other extensions and have worked through issues with them, but there is still an issue with loading the UK extension(s). When it tries to load it complains of a missing module - and I haven't yet tracked down what that module is or why it is "missing". That's not happening with the other extensions. But I do know that the UK module dependencies have some additional complexities that the others don't - and I expect this is part of that. Maybe I can go ahead and look at this again now - I've definitely been wanting to get it working.
Grahame Grieve (Nov 10 2021 at 05:15):
ok. well, let's start working on it.
Rob Hausam (Nov 10 2021 at 05:16):
Yes. I've already started - but I'll try to finish. I'll take another look at it now.
Grahame Grieve (Nov 10 2021 at 05:20):
let me know if I need to look at anything
Rob Hausam (Nov 10 2021 at 05:24):
ok
Kevin Mayfield (Nov 10 2021 at 06:41):
@Rob Hausam you can probably ignore the drug extension as that's moving from SNOMED to a new CodeSystem, the UKCore profiles have already moved to this.
Rob Hausam (Nov 10 2021 at 08:11):
@Kevin Mayfield Thanks. I didn't actually know it was moving, but I was already ignoring it for this. I've (hopefully) fixed and worked around the remaining import bugs - if so, as soon as this one finishes importing I'll get it uploaded. And then get some sleep. :)
Rob Hausam (Nov 10 2021 at 09:07):
@Kevin Mayfield @Grahame Grieve No luck with the UK edition quite yet. It's failing with importing some of the refsets. I removed the der2_cRefset_AttributeValueUKEDSnapshot_GB_20211027 refset from the import as it had trouble with one of the values (at least one). I thought that might take care of it, but then I also ran into an issue with importing the language refset (der2_cRefset_LanguageUKEDSnapshot-en_GB_20211027) - which we can't ignore - where it contains a row for 999000341000001100 |ePrescribing nebuliser liquids type 13a simple reference set (foundation metadata concept)|, but there is no corresponding row in the description file so the import fails (I assume there may also be more rows with issues, but that's the one it failed on). I need to stop on it now and will have to come back to dealing with those issues later.
Bill Lush (Nov 10 2021 at 09:53):
@Rob Hausam you can probably ignore the drug extension as that's moving from SNOMED to a new CodeSystem, the UKCore profiles have already moved to this.
Hi All. Kevin has asked me to look at this discussion. To be clear, in the UK the standard for sharing drug information is dm+d (Dictionary of Medicines and Devices) must be used. The codes used in dm+d are SNOMED codes and the SNOMED UK Drug Extension data is created from uploading dm+d data. The UK Drug Extension data is NOT moving, it will always be there. In the perfect world the dm+d and SNOMED UK Drug Extensions would be exactly the same, but sadly they are not for a number of reasons that I won't go into here. We do plan to get them to be the same, but this will take a long time. As a Terminology Specialist I would recommend that you do NOT exclude SNOMED UK Drug Extensions from uploading SNOMED UK Edition, but it is reasonable to add the data module by module and to leave drug extensions till last. If anyone needs help with this I am happy to see if I can help.
So in summary
* dm+d is the primary data source for drug data in the UK
* There are some differences between dm+d and SNOMED UK Drug Extensions to flag that SNOMED UK Drug Extensions should not be used for interoperability
* SNOMED UK Drug Extensions will always exist as part of SNOMED UK Edition and is created from dm+d data.
Vassil Peytchev (Nov 10 2021 at 19:28):
This was really hard to read, so here it is republished for @Rob Hausam to keep in mind:
Bill Lush said:
Hi All. Kevin has asked me to look at this discussion. To be clear, in the UK the standard for sharing drug information is dm+d (Dictionary of Medicines and Devices) must be used. The codes used in dm+d are SNOMED codes and the SNOMED UK Drug Extension data is created from uploading dm+d data. The UK Drug Extension data is NOT moving, it will always be there. In the perfect world the dm+d and SNOMED UK Drug Extensions would be exactly the same, but sadly they are not for a number of reasons that I won't go into here. We do plan to get them to be the same, but this will take a long time. As a Terminology Specialist I would recommend that you do NOT exclude SNOMED UK Drug Extensions from uploading SNOMED UK Edition, but it is reasonable to add the data module by module and to leave drug extensions till last. If anyone needs help with this I am happy to see if I can help.
So in summary
- dm+d is the primary data source for drug data in the UK
- There are some differences between dm+d and SNOMED UK Drug Extensions to flag that SNOMED UK Drug Extensions should not be used for interoperability
- SNOMED UK Drug Extensions will always exist as part of SNOMED UK Edition and is created from dm+d data.
Rob Hausam (Nov 10 2021 at 23:35):
Yes, that's been my understanding.
Last updated: Apr 12 2022 at 19:14 UTC
