Stream: canada
Topic: URI for Health Canada Drug Identification Number
Igor Sirkovich (Apr 13 2016 at 20:13):
Hello fellow Canadians. We would like to register a URI for Health Canada Drug Identification Number. Its OID: 2.16.840.1.113883.5.1105, symbolic name: hc-DIN. I'm wondering which URI you prefer: http://www.hc-sc.gc.ca/hc-din or http://hl7.org/fhir/sid/hc-din.
Lloyd McKenzie (Apr 13 2016 at 21:17):
My leaning is actually http://hl7.org/fhir/NamingSystem/ca-hc-din
Lloyd McKenzie (Apr 13 2016 at 21:17):
That way it could resolve to the naming system definition which could then point to the current health canada URL, OID and other relevant information.
Igor Sirkovich (Apr 14 2016 at 02:45):
Great suggestion! I agree that this would be the best approach.
Lloyd McKenzie (Apr 14 2016 at 03:25):
Once the registry is up and running, we can submit such things. For now, we should probably raise them on the HL7 Canada forum and, once we get agreement, I can just add them into the international list so they're visible (and official).
Igor Sirkovich (Jun 16 2016 at 20:55):
@Lloyd McKenzie , I'm wondering if you know whether there is any progress on the FHIR registry front. We have defined a number of Identifier namespaces and jurisdictional code systems internally for the project, but it would be great if there is a chance the registry becomes available anytime soon.
Lloyd McKenzie (Jun 17 2016 at 01:35):
Well, https://www.simplifier.net/ is available. Whether HL7 will use that directly or a separate instance of it hasn't been landed on yet.
Igor Sirkovich (Jun 17 2016 at 14:16):
Thank you @Lloyd McKenzie . Simplifier is great and allows to list resource definitions, extensions, etc. on various FHIR servers , but it doesn't help solve one of the issues we face.
If we follow the advise of using a resolvable NamingSystem for URLs of our identifiers and code systems, we need a stable FHIR server, which is not going to change in the future, e.g. something like fhir.ontario.ca/NamingSystem/ca-hc-din. Unfortunatey, this is not under our control and our FHIR server's base URL is pretty flexible. It's not a problem for posting and getting resources (clients just need to update their configurable base URL), but it creates a real problem with defining permanent URLs to replace OIDs.
So one option for us is to define permanent URLs for identifiers and jursidictional code systems, which are not tied to a FHIR server and are not resolvable, and to maintain a published list of these URLs, same as we did with the OIDs in the past. Apparently, we are losing the benefit of using URLs over OIDs with this approach. Another option is to find a permanent FHIR server that would allow us register our URLs in its NamingSystem, but I don't see how Simplifier can help with this.
James Agnew (Jun 17 2016 at 14:47):
I tend to think that having a resolvable permanent home for things like NamingSystem is probably not so realistic anyhow.. I mean, no matter how good your intentions, eventually something will force you to move the server. XSDs and XML namespaces had the same problem back when those were cool. :)
Defining the URL scheme you listed, and just treating it as a logical URL might be much less fuss in the end..
Igor Sirkovich (Jun 17 2016 at 15:33):
Yes James, this what we planned initially, but having a resolvable permanenet NamingSystem for local identifiers and code systems sounded so compelling. Too bad it's unrealistic.
Igor Sirkovich (Jun 17 2016 at 15:39):
However, I think it would still be beneficial to register global identifiers and code systems under http://hl7.org/fhir/NamingSystem if HL7 has a process that allows this. For example, the reason I had started this thread was a need for a URI of Health Canada Drug Identifiers, e.g. http://hl7.org/fhir/NamingSystem/ca-hc-din, which would be used many projects in Canada and some otehr countries. I'm wondering whether I can open gForge tracker for his or if there is any other process to submit a request.
James Agnew (Jun 17 2016 at 15:40):
It would be nice to have some kind of discoverable place where things like that could be found, that's for sure.
Grahame Grieve (Jun 17 2016 at 22:53):
http://registry.fhir.org. I'm working on getting that set up now
Igor Sirkovich (Jun 20 2016 at 14:03):
Thank you @Grahame Grieve . I'm wondering if you have any timelines for the first release of registry.fhir.org in mind. I'm also wondering if this would be the recommended permanent home for regional and jurisdictional code systems, identifier namespaces and extensions, e.g. if in Ontario, Canada we will be able to use http://registry.fhir.org/NamingSystem/ca-on-some-code-system, http://registry.fhir.org/NamingSystem/ca-on-some-identifier, http://registry.fhir.org/StructureDefinition/ca-on-some-extension in our FHIR implementations.
James Agnew (Jun 20 2016 at 20:14):
This is an interesting question.... will using registry addresses as logical URLs/identifiers be a recommended practice?
Grahame Grieve (Jun 20 2016 at 22:13):
it's certainly possible, and our intent is to run registry.fhir.org with appropriate policies to support that. I'm not sure that we'll making recommendations about it. and certainly not in the short term
Igor Sirkovich (Jun 21 2016 at 05:32):
@Grahame Grieve , I'm wondering when you expect the first release of registry.fhir.org to become operational.
Grahame Grieve (Jun 21 2016 at 23:19):
great question
Igor Sirkovich (Jun 22 2016 at 19:47):
Thank you @Grahame Grieve, I won't ask this question again :)
Back to my original question from 2 months ago, in addition to local URIs, we would like to register a URI for Health Canada Drug Identification Number. Its OID is 2.16.840.1.113883.5.1105, symbolic name: hc-DIN. Since this will be used by many Canadian and international projects, we would prefer to register it under HL7 (similar to the US-based code systems) as http://hl7.org/fhir/NamingSystem/ca-hc-din. I'm wondering what would be the process to request this URI.
Grahame Grieve (Jun 22 2016 at 20:10):
make a task
Grahame Grieve (Jun 22 2016 at 20:11):
(on gForge)
Igor Sirkovich (Jun 23 2016 at 13:58):
Done, #10228
Grahame Grieve (Jul 13 2016 at 03:04):
I have a question about GF#10228
Grahame Grieve (Jul 13 2016 at 03:06):
this is to register the name only? Does Canada want a page describing how it's used as a code system, like this page: http://hl7-fhir.github.io/rxnorm.html
Lloyd McKenzie (Jul 13 2016 at 03:29):
I don't think there's too much to say. It's a simple, flat code system with no funky characters to eliminate or properties to declare or relationships to worry about.
Grahame Grieve (Jul 13 2016 at 03:56):
well you could say
- where it's released from (how to get a copy)
- what part of the release format is the right code, and display
- how versioning works
- what kind of filters can be used in value sets
- whether there's any implicit value sets
- how it relates to medication resources.
Grahame Grieve (Jul 13 2016 at 03:57):
we've found all them quite important with the Australian medication code systems
Grahame Grieve (Jul 13 2016 at 04:01):
I find it hard to believe that a medication code system has no depth to the semantics
Lloyd McKenzie (Jul 13 2016 at 05:03):
This is a flat list of products allowed to be dispensed and identifies the product at the packaging level. The semantics are through references to other code systems. Certainly some of the other pieces could be written up though. Igor, would you be willing to take a stab at it?
Lloyd McKenzie (Jul 13 2016 at 05:04):
Should have said @Igor Sirkovich :)
Igor Sirkovich (Jul 13 2016 at 13:58):
@Grahame Grieve, as @Lloyd McKenzie has said, Health Canada Drug Identification Number relates to "a flat list of products allowed to be dispensed and identifies the product at the packaging level". I will create a write a description of this code system and then will post it here and add to GF#10228.
Grahame Grieve (Jul 13 2016 at 19:46):
ok great
Igor Sirkovich (Jul 15 2016 at 16:09):
@Grahame Grieve, I'm not sure if there is enough information to create a separate page about Health Canada DINs. Probably we can just add 1-2 paragraphs to its descripton on the main terminology-systems page.
The current description is "A computer-generated eight digit number assigned by Health Canada to a drug product prior to being marketed in Canada".
I would suggest to change this to:
A computer-generated eight digit number assigned by Health Canada to a drug product prior to being marketed in Canada. It uniquely identifies all drug products sold in a dosage form in Canada and is located on the label of prescription and over-the-counter drug products that have been evaluated and authorized for sale in Canada. A DIN uniquely identifies the following product characteristics: manufacturer; product name; active ingredient(s); strength(s) of active ingredient(s); pharmaceutical form; route of administration.
Canada Health Drug Product Database (http://www.hc-sc.gc.ca/dhp-mps/prodpharma/databasdon/index-eng.php) contains product specific information on drugs approved for use in Canada. The database is managed by Health Canada and includes human pharmaceutical and biological drugs, veterinary drugs, radiopharmaceutical drugs and disinfectant products. It contains approximately 47,000 products that are currently approved, marketed or cancelled.
Grahame Grieve (Jul 15 2016 at 20:31):
so, not going to provide guidance on versioning?
Grahame Grieve (Jul 15 2016 at 20:31):
how does one subset the code system?
Igor Sirkovich (Jul 15 2016 at 21:27):
There is no versioning. It's a flat set of meaningless codes with no ontology or hierarchy and no way to programmaticaly define inclusion / exclusion rules. To subset the code system, one needs to arbitrary select a list of relevant codes.
Grahame Grieve (Jul 15 2016 at 21:28):
no versioning? it's never ben updated?
Igor Sirkovich (Jul 15 2016 at 21:49):
I mean no formal versioning process. They do add new DINs and change status of exiting ones, e.g to "Cancelled", on an ongoing basis, but they don't have a formal release process.
Grahame Grieve (Jul 15 2016 at 21:50):
so the recommended version would the YYYYMMDD for the date you downloaded then?
Igor Sirkovich (Jul 15 2016 at 21:52):
Yes, this seems to be the only reasonable approach
Grahame Grieve (Jul 15 2016 at 21:53):
ok thanks
Grahame Grieve (Jul 15 2016 at 22:01):
looking at this page: http://www.hc-sc.gc.ca/dhp-mps/prodpharma/databasdon/dpd_bdpp_data_extract-eng.php - I see a whole lot of structure and semantics. It is, as I expected - as rich as RxNorm. I think there should be plenty to say about this
Igor Sirkovich (Jul 15 2016 at 23:42):
It just looks rich, but is actually very simple: a drug product table and a bunch of lookups: status, manufacturing companies, packaging, dosage form, route, therapeutic class, etc.: http://www.hc-sc.gc.ca/dhp-mps/prodpharma/databasdon/dpd_read_me-bdpp_lisez-moi-eng.php.
Grahame Grieve (Jul 16 2016 at 05:23):
all those look ups are properties on which you could build value sets
Igor Sirkovich (Jul 18 2016 at 14:58):
I'm wondering if there is a standard or guidlines on how the local and global code systems and identifier system URIs should be constructed. @Lloyd McKenzie, in the beginning of this thread for our DIN URI request you had mentioned that "My leaning is actually http://hl7.org/fhir/NamingSystem/ca-hc-din", but the URI @Grahame Grieve has assigned is "http://hl7.org/fhir/sid/ca-hc-din" and I see that many HL7 defined URIs have "/fhir/sid/" while some UK and Australoan URIs have "/fhir/id/". I'm wondering if "/NamingSystem/", "/sid/" or "/id/" should be preferred.
Lloyd McKenzie (Jul 18 2016 at 15:49):
The benefit of the NamingSystem approach is that the URL will resolve to something at the FHIR level. With sid, you have to search and have to know what registry to search - and it won't resolve by default.
Igor Sirkovich (Jul 18 2016 at 17:35):
Thank you @Lloyd McKenzie. Would you suggest to ask Grahame to change the URL for Health Canada DIN to "http://hl7.org/fhir/NamingSystem/ca-hc-din" or this benefit only applies on local URIs and not on the ones registered with HL7?
Grahame Grieve (Jul 18 2016 at 19:10):
I used sid for it because this is how the existing spec based system ids work. I don't know whether this is a request for a variation, or a change to the pattern
Igor Sirkovich (Jul 18 2016 at 20:57):
Thank you @Grahame Grieve. Do you know if "NamingSystem" would be used for global FHIR system URIs going forward as per Lloyd's suggestion or this would be just used as a registry of system URIs defined somewhere else? If it's the later, would you recommend FHIR based projects to stick to the same pattern of using "sid" for local systems too? Or it's a subject of local naming convention and FHIR doesn't have a stand on this?
Lloyd McKenzie (Jul 18 2016 at 21:04):
My leaning is to change the pattern. Do you see a problem with the pattern @Grahame Grieve
Grahame Grieve (Jul 18 2016 at 21:10):
well, there's the pattern itself, and the possible change process. will need to address both, but I'll take it up later
Grahame Grieve (Jul 18 2016 at 22:25):
The advantage of "http://hl7.org/fhir/NamingSystem/ca-hc-din" is that it more obviously refers to a NamingSystem.
Grahame Grieve (Jul 18 2016 at 22:25):
it doesn't actually make any difference to the fact that it resolves to a naming system - I do that anyway, whatever the URL we choose is
Grahame Grieve (Jul 18 2016 at 22:26):
as in, "http://hl7.org/fhir/sid/ca-hc-din" will resolve the same way
Grahame Grieve (Jul 18 2016 at 22:27):
Lloyd's concern appeared to relate to renaming
Grahame Grieve (Jul 18 2016 at 22:33):
sorry, redirections.
Grahame Grieve (Jul 18 2016 at 22:49):
otoh, the IG publisher presently enforces that it be http://hl7.org/fhir/NamingSystem/ca-hc-din, though
Igor Sirkovich (Jul 19 2016 at 18:59):
@Grahame Grieve, I'm not sure what the butoom line of this discussion is: should the sytem URI be "http://hl7.org/fhir/NamingSystem/ca-hc-din" or "http://hl7.org/fhir/sid/ca-hc-din" with a redirection to "http://hl7.org/fhir/NamingSystem/ca-hc-din"?
We are trying to come up with an approach to assigning & managing our local system URIs and I hope this discussion will help us with the right direction.
Grahame Grieve (Jul 19 2016 at 19:38):
I was waiting for @Lloyd McKenzie to comment before I figured out whether there was a bottom line or not
Lloyd McKenzie (Jul 19 2016 at 19:59):
My expectation is that if I query http://hl7.ogr/fhir/NamingSystem/ca-hc-din, something will be there and I'll probably be able to get the XML or JSON variants if I want and the server won't have to do anything sepecial to make that work. On the other hand, if I query http://hl7.org/fhir/sid/ca-hc-din, I have no expectations about whether/how the query will work. And if it does work, it'll be specific to the HL7 server and anyone who wants to follow a similar approach with a different URL base will have to do special things to their server to make it work. So it seems to me the NamingSystem approach is the most straight-forward. The NamingSystem is a useful thing to resolve to because it lets you translate to the OID, lets you identify constraints on the values and can be updated to point to the current "source of truth" for the codes, whether the code system is available as a FHIR-defined/published CodeSystem resource or not.
Grahame Grieve (Jul 19 2016 at 20:01):
I think your logic is backwards. Since we've made no rule that naming systems must be referenced, whether a url resolves to a naming system resource is something you can only find out by trying
Grahame Grieve (Jul 19 2016 at 20:01):
and both will work
Grahame Grieve (Jul 19 2016 at 20:02):
as for the more general pattern.... yes, that's true. though mostly servers won't be able to do content -type negotiation on this. (doing that on the HL7 server was the tricky part of the enterprise)
Igor Sirkovich (Jul 19 2016 at 21:11):
As a general pattern I like the NamingSystem approach as an elegant FHIR way to define system URI.
My conecern is that this pattern tightly couples the system URI to a FHIR server URL, which is dynamic and might change over time, while a system URI has to be stable and persistent unless it gets depricated.
For example, if my FHIR server URL is www.SomeJurisdiction.org/fhir and I define my system URIs under www.SomeJurisdiction.org/fhir/NamingSystem, but in a couple of years the operations department decides to change the FHIR server URL to fhir.SomeJurisdiction.org, I should either change all my system URIs, breaking interoperability with all existing projects, or these system URIs will not be resolvable on their own (only with redirections), which beats the purpose of going with the NamingSystem approach.
Grahame Grieve (Jul 19 2016 at 21:21):
yes, that's certainly true; over time, the system has to be robust against degeneration
Grahame Grieve (Jul 19 2016 at 21:22):
though we also need to be realistic about how horizon as well; FHIR will cease to be a live specification in the 10-15 year time frame
Lloyd McKenzie (Jul 19 2016 at 21:31):
@Grahame Grieve Is that when you're predicting the demise of the internet? ;)
Lloyd McKenzie (Jul 19 2016 at 21:32):
The reality is that we can use any URL and have it work as a canonical URL that you can search for in the registry(ies) of your choice. And any URL can theoretically also be resolvable.
Lloyd McKenzie (Jul 19 2016 at 21:32):
The benefit of NamingSystem is that it's more likely to be resolvable and it's more likely to be resolvable to a predictable electronic artifact - and it's the artifact that's most likely to be useful.
Lloyd McKenzie (Jul 19 2016 at 21:33):
As such, I prefer it to an arbitrary URL. But it's a preference, it's not a critical thing.
Ken Sinn (Jul 21 2016 at 12:54):
The other aspect of this is the impact of the choice on URI registries and governance the registration process. If we go with the NamingSystem approach, would that double the amount of work required, requiring registration of both the ../NamingSystem/.. and the ../sid/.. URIs?
There's also the initial confusion of learning about NamingSystems and URIs -- The fact that we can have a ../NamingSystem/.. as an URI to denote an ID's code system, and that it's also a resolvable resource that can help map between OIDs and URIs in URL form, can be very confusing for novices.
We've had such a nightmare with OIDs, that we are being very cautious with how URI URLs will be assignd and managed.
Grahame Grieve (Jul 21 2016 at 13:10):
we don't need both
Ken Sinn (Jul 26 2016 at 13:12):
@Lloyd McKenzie @Grahame Grieve Thanks for your input. I didn't want this conversation to trail off without some conclusion. We currently have two FHIR-based projects currently in development and testing, so we would love to finalise our specifications, and apply a consistent URI naming scheme. Lloyd's suggestion of using ../NamingSystem/.. is at odds with the current FHIR spec's use of ../sid/.. when listing existing code systems. What needs to happen to move this discussion/decision forward?
Thanks for any guidance you can provide!
Grahame Grieve (Jul 26 2016 at 20:23):
ah yes, we need to resolve this, and I overlooked it. I think I was waiting for comment from @Lloyd McKenzie on this
Lloyd McKenzie (Jul 26 2016 at 20:29):
@Grahame Grieve I did respond. Was there something specific you wanted me to address that I haven't?
Grahame Grieve (Jul 26 2016 at 20:31):
hmm I see that you have now.
Grahame Grieve (Jul 26 2016 at 20:31):
I'll change the spec
Igor Sirkovich (Oct 09 2018 at 16:22):
@Lloyd McKenzie, @Melva Peters, I know that this is an old discussion, but I had recently found that while we have been using http://hl7.org/fhir/NamingSystem/ca-hc-din to represent Health Canada Drug Identification Numbers (the URI that we had submitted back in 2016 and the one that was also approved by tracker 10228), the URI that appears on the FHIR code systems page is http://hl7.org/fhir/sid/ca-hc-din
Last week, I had opened a ticket 19213 asking to change the URI on the FHIR code systems page.
Lloyd McKenzie (Oct 09 2018 at 17:33):
I'm pretty sure PrescribeIT is using the sid version. It may be too late to change
Igor Sirkovich (Oct 09 2018 at 17:39):
Actually, I see that PrescribeIT is using NamingSystem too:
Code systems that are acceptable in the message are:
CCDD - https://fhir.infoway-inforoute.ca/CodeSystem/canadianclinicaldrugdataset
DIN - http://hl7.org/fhir/NamingSystem/ca-hc-din
NPN - http://hl7.org/fhir/NamingSystem/ca-hc-npn
Igor Sirkovich (Oct 09 2018 at 17:41):
NPN also appears to have "sid" instead of "NamingSystem" in the build version, i.e. we would need to request FHIR to change both ca-hc-din and ca-hc-npn URIs.
Lloyd McKenzie (Oct 09 2018 at 21:21):
If we're sure no-one in Canada is using the wrong ones, then we should be able to get them corrected.
Igor Sirkovich (Oct 09 2018 at 23:34):
I will post a question to the Canadian HL7 and FHIR forums to make sure.
Igor Sirkovich (Oct 31 2018 at 19:06):
@Lloyd McKenzie, @Melva Peters, we had been discussing this issue with the members of the Canadian FHIR community for the last 3 weeks. We've found that CIHI and one of the EMR vendors use "sid" version internally while Ontario Provincial Drug Repository and Canadian PrescribeIT use "NamingSystem". CIHI has indicated that it would be easy for them to migrate to the "NamingSystem" soon.
The Canadian FHIR Solution Architecture group plans to recommend keeping both URIs for now, but to mark the "NamingSystem" URIs as "preferred" and the "sid" URIs as "soon to be deprecated". Please let us know if you have any concerns with this direction.
Lloyd McKenzie (Oct 31 2018 at 19:09):
That seems reasonable to me. It would be good to have an official venue for such decisions that we could recognize as "authoritative" and fair/representative.
Igor Sirkovich (Oct 31 2018 at 19:36):
Totally agree, but unfortunately, we don't have an official venue at this point. The best we could do was to discuss this at the bi-weekly FHIR Solution Architecture calls and at the monthly FHIR Community call (last week), as well as to post on Infoway's HL7 & FHIR forums and on the Canadian stream of the FHIR Chat.
Lloyd McKenzie (Oct 31 2018 at 21:38):
Is this something that can be escalated within Infoway? This function went away when the SC went away and we really need it back...
Igor Sirkovich (Nov 01 2018 at 14:13):
Yes, we've been trying to talk about this with Infoway, but probably, we need to escalate this even more.
Last updated: Apr 12 2022 at 19:14 UTC
