FHIR Chat · nl-basiccomponents · netherlands

Stream: netherlands

Topic: nl-basiccomponents

Alexander Henket (Mar 10 2016 at 08:10):

Dit kanaal is bedoeld voor conversaties rondom het HL7 NL project voor FHIR basiscomponenten

Alexander Henket (Apr 18 2016 at 07:33):

@Marten Smits @Michel Rutten I have elaborated on the examples we worked on during the WGM NL by adding Resources.text[use='additional'] with all relevant information like ticket numbers and such.
I've uploaded Patient and Organization to Simplifier here https://www.simplifier.net/NL-BasicComponents/Patient-example and here https://www.simplifier.net/NL-BasicComponents/Organization-example3

Marten Smits (Apr 18 2016 at 14:29):

Thanks Alexander, let's keep this channel a bit more active than before

Alexander Henket (Apr 19 2016 at 07:28):

Working on V2 guides updates right now... would not want to pollute this channel with that :-)

Alexander Henket (Nov 03 2016 at 16:01):

https://informatiestandaarden.nictiz.nl/wiki/FHIR_Profiling_Guidelines

Ewout Kramer (Nov 03 2016 at 16:03):

[Context: guidance Alexander H and Marten S have stuck to while creating the dutch profiles]

Alexander Henket (Nov 09 2016 at 18:06):

For people interested in progress (and who isn't): I've updated all resources and examples at https://www.simplifier.net/NL-BasicComponents after last weeks meeting at the HL7 WGM NL

All resources have been tagged with mapping information pointing into the ZIBs/CBBs. Names and Addresses have been updated with missing information. I have simplified the voorvoegsel/birth/maiden/partner stuff to align better with the latest insights from the discussion that is still going on with @Simone Heckmann. The profiles are all marked with Dutch canonicals but align well and could be updated for international markers if and when they become available.

I only have one RelatedPerson example to go to really finalize the package and proceed to DevDays and validation in HL7 NL. cc: @Marten Smits , @Marc de Graauw , @Arianne van de Wetering , @Michael van der Zel

Marten Smits (Nov 10 2016 at 07:44):

Great work Alexander! I'll check them out.

Ben Schrijver (Nov 10 2016 at 08:55):

Thanks Alexander! The new approach to voorvoegsels seems like a big improvement.

Michael van der Zel (Nov 10 2016 at 09:54):

Thanks Alexander, especially for the mappings to the ZIBs! :-)

Michael van der Zel (Nov 10 2016 at 09:56):

@Alexander Henket BTW are the mappings now visualized in Simplifier?

Alexander Henket (Nov 10 2016 at 09:57):

No that probably is on the backlog of Simplifier (Marten?). You can only see those when you switch to the XML/JSON views. But rest assured they are present. While on that topic, I had decision to make in adding those.

Example Zorgverlener.id has been sliced into specific explanantion for UZI and AGB-Z. The ZIB only specifies Zorgverlener.id. And so I've added the mapping to the path that the slicing occurs on. The separate UZI/AGB-Z do not have any mapping info

Marc de Graauw (Nov 10 2016 at 09:59):

Ik ben niet heel gelukkig met splitsing family-maiden-partner. In Nederland is het in de meeste contexten, ook GBA als ik het me goed herinner zo dat achternaam == geboortenaam. En dat is dus voor getrouwde vrouwen die naam van hun partner of een samenstel willen voeren de meisjesnaam. Het voelt vreemd om de belangrijkste naamcomponent soms in family te stoppen, maar soms in maiden. Dat vereist dat alle systemen logica gaan inbouwen als: "If maiden = empty then family else maiden". Ik weet dat dat het voorstel van Simone is, maar misschien moeten we dat volgende week nog een doorakkeren op de DevDays.
Wat ook kan als we het voorstel volgen dat in family de complete representatie komt (waar ik dus niet zo gelukkig mee ben), dat we in NL ipv. maiden gebruiken birthname of zoiets (geboortenaam) die dan verplicht altijd gevuld moet zijn met de geboortenaam. Dan weet je in ieder geval zeker dat dat element gevuld is, en wat daar in staat. Dat lijnt ook beter uit met ZIB demografische gegevens.

Alexander Henket (Nov 10 2016 at 10:01):

Maiden != meisjesnaam. That is a common mistake. Maiden name does not include any reference to the gender of the bearer of the name

Alexander Henket (Nov 10 2016 at 10:02):

That's why I've included aliases like "geboortenaam", "geslachtsnaam" and "eigennaam". "Geslachtsnaam" is wat the GBA/BRP refers to

Alexander Henket (Nov 10 2016 at 10:03):

Also: "geboortenaam" (birth name in English) is not entirely correct for adoption situations or remarrying situations

Alexander Henket (Nov 10 2016 at 10:05):

I've learned after many years of discussion on names, that there is no way to satisfy everybody with one word, so I added all commonly used terms

Alexander Henket (Nov 10 2016 at 10:06):

To return to your point: "de Graauw" is your maiden/birth/geslachtsname. You only use the unqualified family name when you don't know what type of last name you are dealing with

Alexander Henket (Nov 10 2016 at 10:09):

: in V2 we have a Name Assembly Order sub field. In V3 we relied on order in the datatype. In FHIR we do not have any specific guidance along those lines. I thought of adding the good old Name Assembly Order thing from V2 which was well defined as a value set. Any thoughts on that? For reference, this is what V2 says:

Code Description
NL0 unknown
NL1 maiden name
NL2 name partner
NL3 name partner followed by maiden name
NL4 maiden name followed by name partner

Alexander Henket (Nov 10 2016 at 10:32):

<exampleHumanName>
    <family value="Jongeneel-de Haas">
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-maiden">
            <valueString value="Jongeneel" />
        </extension>
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-partner-prefix">
            <valueString value="de " />
        </extension>
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-partner">
            <valueString value="Haas" />
        </extension>
        <extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-name-assembly">
            <valueCode value="NL4" />
        </extension>
    </family>
    <given value="Irma">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="CL" />
        </extension>
    </given>
    <given value="I.">
        <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
            <valueCode value="IN" />
        </extension>
    </given>
</exampleHumanName>

Alexander Henket (Nov 10 2016 at 10:33):

Something along these lines. The http://fhir.nl/fhir/StructureDefinition/nl-core-humanname-family-name-assembly thing is currently not defined. Should I?

Alexander Henket (Nov 10 2016 at 10:35):

A second decision I ran into was: what to do with the voorvoegsel whitespace? Is it "de " (V3 style) or "de" (V2 style)?

I found disturbing wording in the FHIR base spec that says: "The parts of a name SHOULD NOT contain whitespace. For family name, hyphenated names such as "Smith-Jones" are a single name, but names with spaces such as "Smith Jones" are broken into multiple parts."

We are clearly violating that statement (source: http://hl7.org/fhir/datatypes.html#HumanName), but I feel that I don't care about that and we SHOULD contest validity of that statement.

Alexander Henket (Nov 10 2016 at 11:52):

I've uploaded the missing RelatedPerson example to Simplifier and fixed the postalCode (should not have had a space) on the Patient example. This concludes this part of the work for DevDays next week as far as I'm concerned.

Marc de Graauw (Nov 10 2016 at 13:24):

Maiden != meisjesnaam. That is a common mistake.

See: https://www.google.nl/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=maiden%20name.
Seems that maiden= meisjesnaam is common, and maiden != meisjesnaam a mistake...

Marc de Graauw (Nov 10 2016 at 13:35):

If family-maiden is required for "geboortenaam", that satisfied half of my problem. Still think maiden is a misnomer which will entice everyone to use this only for meisjesnaam.

Marc de Graauw (Nov 10 2016 at 13:40):

Using "de " instead of "de" feels strange... The "Smith Jones" example shows that "Smith"+"Jones" should be concatenated to "Smith Jones" on screen/in print, so "de" and "Graauw" should likewise be concatenated to "de Graauw". And you don't use "Irma " either, it's "Irma". The no-whitespace would also be violated by "van der", since family-voorvoegsel is ..1 one cannot send "van" and "der" separately.

Alexander Henket (Nov 10 2016 at 14:17):

Right well that did it I've changed all occurences of maiden to "birth". If adopted people are going to complain next, we'll just have to see.

Marten Smits (Nov 10 2016 at 15:10):

@Ben Schrijver Heads-up for this change. Do you have any problems with this?

Ben Schrijver (Nov 10 2016 at 15:14):

@Marten Smits No problem, seems like a sensible change.

Alexander Henket (Nov 10 2016 at 15:16):

whew. For my information: what are you working on, and is it enough for you to watch this work, or do we need closer ties?

Ben Schrijver (Nov 10 2016 at 15:26):

I work for ZorgDomein and we follow the development of the BasicComponents pretty close to keep our own profiles (still in development) in line with the Dutch standards. We have pretty close ties with Marten and other Furorees regarding FHIR. Also, we will be at Dev Days and join the MedMij track, so we can talk further there :)

Alexander Henket (Nov 10 2016 at 15:27):

Gotcha. Yes we should definitely try to align our work. At the WGM I invited Zorgdomein to publish on Simplifier too so we can discuss better. I think that was a colleague of yours or was it you?

Ben Schrijver (Nov 10 2016 at 15:33):

@Alexander Henket No, I wasn't at the WGM, unfortunately. But yes, we will start publishing our profiles soon enough.

Alexander Henket (Nov 10 2016 at 19:07):

Great! My end goal is to have as few profiles as possible to get things done. I'm counting on the opposite thing to happen in the coming 1-2 years where many initiatives will start 'baking' profiles for all sorts of purposes. Overlap is inevitable in that period. I sincerely hope that initiatives surface soon enough to be able to get in touch with one another before things go live. This way we have the best chances for harmonizing efforts.
I know you are doing your part already, so thanks for that!

Alexander Henket (Nov 18 2016 at 07:43):

Hi all. One of the outstanding issues in the core profiles evolved around HumanName and most specifically the voorvoegsel. We had a perfectly valid solution in place but unecessarily so it was not the same as Germany/Chile/Argentina/.. after extensive discussions we've landed on the following proposal for harmonization GF#12351.

The proposal may be compressed into the notion that it corresponds to what we landed on when we first discussed it at the WGM NL. I will be updating the nl-core-humanname as soon as the proposal is motioned and accepted. My guesstimate for timing thereof is somewhere in december.

Grahame Grieve (Nov 18 2016 at 07:58):

I may pre-apply the change - only pushback was from a portuguese user, and I think that the concerns have been resolved

Alexander Henket (Nov 19 2016 at 16:11):

Can't complain there :-)

Grahame Grieve (Nov 22 2016 at 10:29):

applied

Grahame Grieve (Nov 22 2016 at 10:29):

and signed off by committee

Marten Smits (Nov 22 2016 at 15:20):

Thanks Grahame!

Alexander Henket (Nov 22 2016 at 15:21):

Melle Sieswerda (Dec 07 2016 at 08:09):

@Alexander Henket Can it be that the description of nl-core-humanname on Simplifier contains a slight error? family-birth-voorvoegsel and familiy-birth have the same description.

Marten Smits (Dec 07 2016 at 15:19):

Tomorrow I'm going to allign nl-core-humanname with international conventions for voorvoegsel that we discussed on the DevDays. I'l also look at this issue then.

Marten Smits (Dec 07 2016 at 15:19):

Thanks for reporting!

Marten Smits (Dec 08 2016 at 14:10):

I've updated nl-core-humanname here: https://simplifier.net/NL-BasicComponents/nl-core-humanname/rendered

Marten Smits (Dec 08 2016 at 14:12):

I also updated the examples for Patient, Practitioner, and RelatedPerson and ported the new international STU3 Extensions for humanname.family parts to DSTU2

Marten Smits (Dec 08 2016 at 14:12):

@Simone Heckmann The last part might be interesting for you as well in Germany

Simone Heckmann (Dec 08 2016 at 14:15):

Hi Marten, thanks for the tag! We have created our extension for Namenszusatz/Nobility and created a couple of examples of how to use the national/international extensions in the context of HumanName:
https://simplifier.net/BasisprofilDE

Stefan Scholte (Jan 06 2017 at 10:52):

I have a question regarding Patient.Contact. In the structured definition there is no extension defined with the name nl-core-contact-role. Yet in the example this is used. Do I miss something?

Alexander Henket (Jan 17 2017 at 15:16):

This dropped off my grid during my holiday. It would appear you have a good catch here. Let me chew on this some more and see what needs to be done to make it consistent again

Alexander Henket (Jan 17 2017 at 18:17):

Found my answers. Patient does not need the extension that RelatedPerson does. So I've updated the example from extension to just Patient.contact.relationship. Secondly I noticed that the extension existed twice. nl-core-contact-role and nl-core-relatedperson-role. I've deleted the former (nl-core-contact-role) which was not referenced anywhere. Thanks @Stefan Scholte for noticing!

Last updated: Apr 12 2022 at 19:14 UTC