Stream: netherlands
Topic: GBA table 33 and 34
Yuri Bonanno (Dec 17 2018 at 14:34):
I am mapping the Address element from a patient FHIR message to ZIBS and I encountered a speedbump. According to the WIKI the values for district/city and country found in the FHIR message should conform to GBA tables 33 and 34, respectively. Although the use of table 33 is merely advised, it is problematic nonetheless.
The ISO codes were as problematic if it were not for someone who had already made a piece of open-source java code in which the country codes were already programmed. Sadly, this is not the case for the GBA tables (as far as I know).
If someone happens to know an open-source java code that fits my needs, I would happily hear where I can get this code.
There is of course also the case in which the code has not been produced yet, if so, is it not possible to create this code together? I can't imagine I am the only person wanting this code.
With kind regards,
Yuri Bonanno
PS: I am new to this community so I am not sure whether this information should be shared here.
Michel Rutten (Dec 18 2018 at 10:32):
@Alexander Henket, @Ardon Toonstra?
Alexander Henket (Dec 18 2018 at 10:33):
Not sure what the problem is. Contents of the CodeSystem? You can download them from here http://publicaties.rvig.nl/Landelijke_tabellen/Landelijke_tabellen_32_t_m_60_excl_tabel_35
Alexander Henket (Dec 18 2018 at 10:34):
They are external CodeSystems which is why we, MedMij, do not provide them. That would present a maintenance issue
Alexander Henket (Dec 18 2018 at 10:35):
The 'application code' for these ValueSets is the same as for any ValueSet
Yuri Bonanno (Dec 18 2018 at 12:37):
Not sure what the problem is. Contents of the CodeSystem? You can download them from here http://publicaties.rvig.nl/Landelijke_tabellen/Landelijke_tabellen_32_t_m_60_excl_tabel_35
I should make myself more clear.
https://github.com/TakahikoKawasaki/nv-i18n
This package supports looking for countryCodes/names in java. For example, there is a function in which I can input "NLD" and it will return the string "Netherlands". I could make a program that does the same (but with GBA 33 and GBA 34 instead of ISO) but I wanted to check if it was not already produced. I did not expect HAPI to supply this code.
Alexander Henket (Dec 18 2018 at 21:14):
Sounds a lot like terminology services that HAPI would likely supply, if you fed it the right contents. When you do you should have access to something like POST ValueSet/[id]/$expand with param filter. See: https://www.hl7.org/fhir/valueset-operations.html#4.8.16.1
Alexander Henket (Dec 18 2018 at 21:16):
I'm not sure hardcoding each CodeSystem into a java class separately would be a productive way forward.
Alexander Henket (Dec 18 2018 at 21:17):
If you need specific Terminology Services guidance the terminology stream is useful. If you want to get more specific on HAPI, the conformance stream could be a starting point
Yuri Bonanno (Dec 19 2018 at 08:44):
Sounds a lot like terminology services that HAPI would likely supply, if you fed it the right contents. When you do you should have access to something like POST ValueSet/[id]/$expand with param filter. See: https://www.hl7.org/fhir/valueset-operations.html#4.8.16.1
Thanks! I will look into this!
Michael van der Zel (Dec 19 2018 at 16:22):
@Alexander Henket But who then converts the csv provided to a FHIR ValueSet?
Alexander Henket (Dec 19 2018 at 16:37):
Who does for any external set?
Alexander Henket (Dec 19 2018 at 16:45):
Today we looked at bcp13 which is the txt for the IETF RFC that defines mime types. The official FHIR binding for mime types is based on a link to that RFC txt file. It is not particularly possible to assume a CodeSystem there.
External sets are an issue in general. A party that builds one for offer commits to the maintenance there of. Registration aan de Bron, MedMij, Nictiz, ... cannot offer that afaik.
So as it currently stands: each vendor will choose a solution that best matches their context.
Alexander Henket (Dec 19 2018 at 16:52):
It might just be that CSV suits some implementations fine as-is. Other implementations want a Java class file with constants. Again others may have SQL tables and an import procedure for the CSV. etc. CSV used to be the lingua franca for interchange of table data. Maybe that is shifting towards FHIR, but in any case, SNOMED CT is RF2 in it's raw form, GBA is CSV with a certain column set, LOINC is CSV with a different column set, HCIM ValueSets are serialized into ART-DECOR ValueSets and exportable as FHIR ValueSets and then some.
A single terminology format that rules them all is not yet feasable
Alexander Henket (Dec 19 2018 at 16:56):
Is this a topic best discussed at Registratie aan de Bron? Maybe we can talk to the VNG/GBA/Logius/Vektis/NHG/... and other governing bodies and progressively persuade them to come together for the sake of their implementers? Sounds ambitious but possible
Michael van der Zel (Dec 20 2018 at 13:40):
Maybe we should describe in Registratie aan de Bron how to handle external valuesets. For example we need DHD Diagnosen as a FHIR ValueSet for a PGO implementation. So I converted some spreadsheet to a valueset. That means the maintanance also lies with me and I don't want that.
Alexander Henket (Dec 20 2018 at 13:40):
Nobody does... :-) The hot potatoe is pushed around the table
Last updated: Apr 12 2022 at 19:14 UTC
