Share this page:

file FHIR: URI for Health Canada Drug Identification Number

  • Posts: 7
8 years 1 week ago #1270 by Greg Peres
"All that matters here is software developers." - Lloyd

I agree 100% with this statement from Lloyd. The biggest barrier to adoption is software developers/engineers and we will need to address this directly in our next generation of systems. I have been hearing this loud and clear for quite some time from the software engineering community.

"So why not bite the bullet and translate everything?" - Lloyd

As you correctly pointed out the down stream benefit is significant. I am pushing very hard to have this done for the new services that will be coming. (At least for the FHIR messages that get implemented into production systems.)

"If we don't do it during this time of transition, then it'll never happen and we'll be stuck with the costs and lose out on the developments forever more." - Lloyd

I agree as we transition systems to FHIR we are going to have to do this. No remorse, no regrets to quote Metallica.

Cheers,
Greg

Please Log in or Create an account to join the conversation.

  • Posts: 132
8 years 1 week ago #1268 by Lloyd Mckenzie
Pharmacists, nurses and doctors are irrelevant to this discussion. All that matters here is software developers. And we've got penetration to between 30% and 50% of the developer organizations we'll need to support interoperability (and the set of developers who will need to mount the learning curve will be continuous). We have no choice but to build a translation infrastructure. We can't be conformant unless we translate OIDs for code systems like LOINC, SNOMED, etc. And OIDs suck. So why not bite the bullet and translate everything? That way we can save 50-70% of organizations from ever having to learn about OIDs and eliminate the learning curve for new developers going forward. Yes, there's a short-term soft. But there's long-term benefits and savings. If we don't do it during this time of transition, then it'll never happen and we'll be stuck with the costs and lose out on the developments forever more.


Lloyd

Please Log in or Create an account to join the conversation.

  • Posts: 20
8 years 1 week ago #1267 by Iryna Roy
Thank you, Igor! You clearly described my concerns. I have tested the idea on few developers and despite their special love to OIDs, the opinion is why to create one more thing to name something that is already named. Especially FHIR supports the uri oid. I don't see a problem here. Who will browse or check codes using the url once the system is implemented? Pharmacist? Nurse? Doctor?

IMHO we invent fifth wheel and then will teach everyone how to ride using either three or five of them.

I like Igor's idea - let's keep what we have and assign URIs going forward to what is not named yet.

Thank you!

Kind regards,
Iryna

Please Log in or Create an account to join the conversation.

  • Posts: 181
8 years 1 week ago #1266 by Igor Sirkovich
Greg, we need to assign OIDs to the hate, despise & loath terms :)

Please Log in or Create an account to join the conversation.

  • Posts: 7
8 years 1 week ago #1265 by Greg Peres
"I would even say developers hate OIDs."

It is probably more accurate to say we despise/loath them. :cheer:

Cheers,
Greg Peres

Please Log in or Create an account to join the conversation.

  • Posts: 181
8 years 1 week ago #1264 by Igor Sirkovich
I understand Iryna's concerns, but I agree with Lloyd's arguments. When I speak with developers, who worked on HL7 v3 projects, they always complain about OIDs. I would even say developers hate OIDs. On the other hand, they usually do understand and like URLs.

OIDs serve their purpose well for those who figured them out, but very few people did. Every project faces the same problem of properly understanding and managing OIDs. A lot of repeating education is required and still many projects get OIDs wrong and it's not rare to some the same OID being used as a namespace for orders and results and something else.

For FHIR this would be even harder because, rather than serving big monolithic projects, FHIR usually serves API-oriented projects where you don't really know people working on the consuming applications and don't have an opportunity to educate them. They need to get all the concepts from just reading the implementation guide and from looking at the samples, same as they do with API documentation of Twitter or Github.

URLs won't solve all the problems of proper namespacing on heir own and they might have some risks of misinterpretation similar to risks of meaningful codes, especially if abbreviations are used, e.g. hl7.org/fhir/NamingSystem/ca-msh-mrn might be interpreted by a developer as MRN of Mount Sinai Hospital or MRN of Markham Stouffville Hospital, but having a resolvable NamingSystem with all the metadata would help in these cases. Also, it would be helpful if HL7 Canada Community establishes a governance on Canadian URLs to ensure uniqueness, proper names and metadata.

I believe we need to adopt URLs for all FHIR implementations and to start mapping existing Canadian OIDs to URLs to avoid duplicate URLs for the same shared concepts being assigned by different projects.

Regards,
Igor

Please Log in or Create an account to join the conversation.

InfoCentral logo

Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.