Stream: terminology
Topic: New FHIR ValueSets for medication records and messages
Andrew Gledhill (Jul 23 2018 at 17:29):
I have been having a think about new medication related FHIR ValueSets which DON'T refer to SNOMED CT codes. Looking at other FHIR ValueSets it appears that connecting display data with a < - > might be one way of defining a universal non-SNOMED code. I have done some copying and pasting into an excel spreadsheet and have come up with the following structures/codes for the atomic breakdown medication messages.
Possible-new-FHIR-VALUESETS-for-MEDICATION-messages-and-MEDICATION-clinical-records-20180723.xlsx
I apologise if I have completely misinterpreted the use of FHIR ValueSets but I am 'almost' a complete HL7 beginner ;-)
Grahame Grieve (Jul 23 2018 at 22:08):
can you explain this a little more... I'm not sure what you're trying to do here
Rob Hausam (Jul 23 2018 at 22:12):
I don't think I get it, either. If we can get some clarification and have some discussion we probably can offer some advice in regard to the FHIR value sets.
Andrew Gledhill (Jul 24 2018 at 16:19):
I was just 'experimenting' with the idea of creating new FHIR ValueSets and a new FHIR code system with FHIR specific 'open source' and freely available codes which don't rely on proprietary data e.g. SNOMED CT, RxNorm etc.
These open source 'FHIR ValueSets' with codes could then be used to create the building blocks of an individual patient and international 'open source' EMR (Electronic Medical Record).
The codes for medication information might be something like:
text: oral ...... code: 'admin-route-01'
text: tablet ...... code: 'dose-form-01'
text: amoxicillin ...... code: 'active-ingredient-01'
See amended spreadsheet
This might work for ValueSets with small/medium data options but would be a problem for very large datasets such as medication-product
Grahame Grieve (Jul 24 2018 at 20:08):
so we have a policy - documented somewhere, I'm sure - that we don't define code systems where any other organization does. That's a very sound policy, but it becomes problematic when some other org does but under a non-open license, or under management terms and conditions that are not workable for implementers - primarily jurisdiction limited.
Grahame Grieve (Jul 24 2018 at 20:08):
but there are very sound reasons why HL7 does not maintain code systems where it can avoid doing so
Lloyd McKenzie (Jul 24 2018 at 22:58):
And for something as massive as drug codes where there are typically jurisdictional codes that must be reported for regulatory reasons, a need to link to UPC codes, existing knowledge base sources, etc., that's not something HL7 could even consider to take on. It's not managable on a volunteer basis - and almost all development HL7 does is volunteer based.
Michael Lawley (Jul 25 2018 at 00:17):
Yep, in the medication space any practical use will need to connect in to local branding and packaging, as well as barcodes / GTINs etc, and then the bleed over into devices (medicated bandages, for example).
Andrew Gledhill (Jul 25 2018 at 11:45):
Yes I agree Grahame and Lloyd that 'Brand/Proprietary' medication information/data soon becomes extremely complex and very time consuming to manage. On the other hand when medication descriptions are taken back to a basic 'generic' description (omitting pack size etc) then the data becomes much more manageable and 'testable'. For some time I have been working on an 'open source' medication prescribing dataset (Medication.Request) which might be of use for testing new e-Prescribing systems and might also be of use for testing FHIR servers. I attach the dataset with for use by anyone who might find it useful.
Open-Source-Medication-Request-dataset-for-testing-HL7-FHIR-servers-20180725.xlsx
Paul Lynch (Jul 25 2018 at 20:32):
There is also the RxTerms data set (https://wwwcf.nlm.nih.gov/umlslicense/rxtermApp/rxTerm.cfm) which is derived from RxNorm but only from the non-proprietary data, so it is free to use.
Grahame Grieve (Jul 25 2018 at 20:43):
some developing world countries use that
Last updated: Apr 12 2022 at 19:14 UTC
