FHIR Chat · Middle Name

Stream: nordics

Topic: Middle Name

Grahame Grieve (Jun 07 2019 at 12:02):

  <extension url="http://hl7.org/fhir/StructureDefinitioniso-20190#name-qualifier" >
      <valueCoding>
         <code value="MID" />
         <system value="http://terminology.hl7.org/CodeSystem/v3-EntityNamePartQualifier2" />
      </valueCoding>
    </extension>

Grahame Grieve (Jun 07 2019 at 12:02):

http://hl7.org/fhir/datatypes-examples.html#humanname

Jens Villadsen (Jun 07 2019 at 12:04):

http://hl7.org/fhir/valueset-name-part-qualifier.html#definition

Grahame Grieve (Jun 07 2019 at 12:04):

so you find that by searching for 'Mellannamn' but not 'middle name' ;-)

Grahame Grieve (Jun 07 2019 at 12:06):

that extension is wrong - it doesn't exist

Jens Villadsen (Jun 07 2019 at 12:08):

http://hl7.org/fhir/extension-iso21090-en-qualifier.html thats the extension

Grahame Grieve (Jun 07 2019 at 12:08):

and this is the correct representation:

Grahame Grieve (Jun 07 2019 at 12:08):

<name>
  <use value="official" />
  <family value="Erikson" />
  <given value="Jan" />
  <given value="Erik" />
  <given value="Östlund">
    <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" >
      <valueCoding>
         <code value="MID" />
         <system value="http://terminology.hl7.org/CodeSystem/v3-EntityNamePartQualifierR2" />
      </valueCoding>
    </extension>
  </given>
</name>

Grahame Grieve (Jun 07 2019 at 12:08):

or in json:

Jens Villadsen (Jun 07 2019 at 12:10):

"name": [
    {
      "given": [
        "Jan",
        "Erik",
        "Östlund"
      ],
      "family": "Erikson",
      "use": "official",
      "_given": [
        null,
        null,
        {
          "extension": [
            {
              "url": "http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier",
              "valueCoding": {
                "code": "MID",
                "system": "http://terminology.hl7.org/CodeSystem/v3-EntityNamePartQualifierR2"
              }
            }
          ]
        }
      ]
    }

Grahame Grieve (Jun 07 2019 at 12:11):

you beat me ;-)

Jens Villadsen (Jun 07 2019 at 12:11):

https://fhir-formats.github.io

Vadim Peretokin (Jun 07 2019 at 12:12):

(someone actually uses my website! yes!)

Grahame Grieve (Jun 07 2019 at 12:15):

I've fixed this in the current build

Thomas Tveit Rosenlund (Jun 07 2019 at 12:53):

Yes, now I get it. I don't like it we, might have to change this in the no-basis.

Grahame Grieve (Jun 07 2019 at 13:08):

well, if you change it, I might as well change it, since you're the only user. What would you do instead?

Jens Villadsen (Jun 09 2019 at 09:46):

(someone actually uses my website! yes!)

@Vadim Peretokin what is up with the null values in the _given structure?

Grahame Grieve (Jun 09 2019 at 09:47):

that's a special case - extensions in an array - see http://hl7.org/fhir/json.html#primitive about the use of null

Jens Villadsen (Jun 09 2019 at 09:52):

@Grahame Grieve its sunday ... aren't you supposed to enjoy the weekend or something?

Grahame Grieve (Jun 09 2019 at 10:28):

I'm awake at 2:30 am in Seattle with jetlag doing my devdays presentations

Martin Grundberg (Jun 26 2019 at 20:45):

Stumbled upon this and thought I’d add the plan for Swedish “middle name” or mellannamn. It is used historically as an “additional” family name, but the use of mellannamn has recently been removed, and those names should now be seen as part of the family name meaning we may just append a mellannamn to the family name.

So it is likely that we don’t include support for mellannamn in the Swedish core patient profile.

We do plan to use the extension mentioned above though (http://hl7.org/fhir/extension-iso21090-en-qualifier.html) for pointing out the “preferred” given name using code CL.

Oskar Thunman (Jun 27 2019 at 08:29):

During the nordic meeting here in June it was mentioned that this change in national name standards are not yet reflected in the regional infrastructure, so although middle name might not be officially in use anymore, it could be useful to provide the reasoning around this in the profile, possibly even offering guidance on how to map "old" middle names to the profile.

Martin Grundberg (Aug 01 2019 at 07:51):

Have looked into this a bit more.

From a Swedish perspective, as it stands now, these are the national rules (https://www4.skatteverket.se/rattsligvagledning/330287.html#)

Middle name is not a form of Given name, hence using the name part qualifier like this is not correct as the middle name here is a given name:

Middle name is a form of last name/family name
It is no longer possible to acquire a middle name (e.g. Andersson), but people can choose to keep an old middle name (e.g. Andersson) as an explicit middle name, or either 1) append it to the family name (e.g. Svensson), giving *one *family name consisting of two names (family name=Andersson Svensson) or 2) replace the previous family name (family name=Andersson).

Requirements from a Swedish perspective
Even though middle names can no longer be acquired, they still need to be supported for people who have old ones. Hence, we need to support explicit middle names, and they cannot be a given name. This needs to be done using an extension as family name is 0..1 (if family name was 0..* we could have used the name qualifier extension).

What have other Nordic countries done?

Norway have created their own extension for middle name, http://hl7.no/fhir/StructureDefinition/no-basis-middlename
Finland?
Denmark?
Iceland?

What I think should be done
There should be a new standard extension for Middle Name when used in the context as a family name like in the Scandinavian countries. It can then be used by all countries with this use case.

The existing extension http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier does not support middle name as used in Scandinavia, despite the following code and definition. It would work if it was possible to have multiple Family names, so you can put a MID qualifier on one of them. But I would say it's directly incorrect to use MID on a given name for the Scandinavian/Nordic use case as it is described in the code definition below.

"MID Middle Name Indicates that the name part is a middle name. In general, the English "middle name" concept is all of the given names after the first. This qualifier may be used to explicitly indicate which given names are considered to be middle names. The middle name qualifier may also be used with family names. This is a Scandinavian use case, matching the concept of "mellomnavn"/"mellannamn". There are specific rules that indicate what names may be taken as a mellannamnin different Scandinavian countries."

What do you think, should I report a Change Request for inclusion of a Middle Name extension?

Martin Grundberg (Aug 01 2019 at 08:13):

https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23036&start=0

Martin Grundberg (Aug 01 2019 at 11:03):

More information. Seems like the requirements are the same in Sweden, Denmark and Norway at least according to https://www4.skatteverket.se/rattsligvagledning/edition/2019.6/330289.html#h-Andra-utlandska-mellannamn.

Viktor Jernelöv (Aug 05 2019 at 12:28):

It does sound like we have a case for a change request, and in the meantime use an extension?

This text taken from http://hl7.org/fhir/datatypes.html#humanname could perhaps also provide us with some guidance:

"In some cultures (e.g. German, Dutch, Spanish, Portuguese), family names are complex and composed of various parts that may need to be managed separately, e.g. they have differing significance for searching. In these cases, the full family name is populated in family, and a decomposition of the name can be provided using the family extensions own-name, own-prefix, partner-name, partner-prefix, fathers-family and mothers-family."

Thomas Tveit Rosenlund (Aug 13 2019 at 06:38):

@Martin Grundberg @Viktor Jernelöv
We have the same situation in Norway. In the Norwegian naming law middle name is defined as a separate name type that makes the use of the naming qualifier unprecise. The naming law in Norway states that any family name can be a middle name. (Given names cannot). I guess this is a technical issue more than an actual obstacle, but in my mind the middle name is a separate entity in the naming law and should also be a separate entity in the information model, hence the separate norwegian extension for middlename as a part of the no-basis-HumanName, i still feel this is the most correct approach to define specific entities defined by national law. I would wery much appreciate further feedback regarding this reasoning.
link to the no-basis-HumanName: https://simplifier.net/HL7Norwayno-basis/NoBasisHumanName

Martin Grundberg (Aug 14 2019 at 12:31):

thanks @Thomas Tveit Rosenlund , I think this should settle it for us in Sweden as well. We should do the same. Question then is whether to use your extension, or create our own (probably replicating yours) while waiting for a standard extension.

Thomas Tveit Rosenlund (Aug 14 2019 at 13:04):

You might want to duplicate the extension @Martin Grundberg because I have restricted it in documentation to scope middlename in accordance to the Norwegian legislation (Navneloven). "The basis extension defines the Norwegian middlename wich is called "mellomnavn" and defined by Norwegian legislation (Lov om personnavn)." You probably want some other definition in Sweden :-) We could however change the extension to be more general and maybe work in the Nordics instead of only be made for Norway. Feel free to suggest changes to the profile to make it apropriate for use in Norway/Sweden/Denmark.

Thomas Tveit Rosenlund (Sep 10 2019 at 08:51):

The first proposal for nordic-middlename is published on GitHub:
https://github.com/HL7Norway/Nordics-on-FHIR/tree/master/StructureDefinition

Please review.

Espen Stranger Seland (Sep 10 2019 at 21:26):

Information about Sweden:
https://www4.skatteverket.se/rattsligvagledning/edition/2019.7/330287.html
Legislation:
https://www4.skatteverket.se/rattsligvagledning/362047.html?date=2019-01-01

tl;dr: Sweden is removing middlename, but people who already have one can keep it.

Vadim Peretokin (Oct 02 2019 at 08:53):

@Thomas Tveit Rosenlund how would this extension be used - does middle name go into both Human.family and the extension (so the data is present for all systems, and for those who understand the extension, it's semantically enriched)

or does the middle name go only into the extension, so systems who don't understand the extension don't get the data?

Vadim Peretokin (Oct 02 2019 at 08:53):

I think this should be clarified in the extension.

Viktor Jernelöv (Oct 02 2019 at 14:54):

Thomas Tveit Rosenlund how would this extension be used - does middle name go into both Human.family and the extension (so the data is present for all systems, and for those who understand the extension, it's semantically enriched)

or does the middle name go only into the extension, so systems who don't understand the extension don't get the data?

Our understanding is that middle name only goes into the extension and in humanName.text if that's deemed necessary by the use case. humanName.family SHOULD NOT contain the middle name since the Scandinavian countries' naming laws specifically differentiate between the family name and the middle name.

We don't want to put the oranges in the apple basket.

Thomas Tveit Rosenlund (Oct 03 2019 at 05:41):

@Vadim Peretokin @Viktor Jernelöv That it correct Viktor. Systems that don't understand the middlename extension get the data, but they can make use of it I suppose. Viktor describes it correctly. In Norway, Sweden and Denmark a middle name is not a given or a family name but a separate name entity defined in the legislation. Otherwise it would be no problem to use the standard extension for this.

We have used the middlename (currently the Norwegian version) in the no-basis-HumanName profile, so this is an example of how we would like to use the no-basis/nordic middlename in actual implementation:
https://simplifier.net/hl7norwayno-basis/nobasishumanname

Emmeli Gross (Oct 07 2019 at 14:54):

If there is vital information about the patient that is only available in an extension there is a risk that the patient can potentially be harmed. From my point of view, the patients name is vital information and it is our responsibility to do all we can to ensure that it’s always available and as complete as possible.
When doing a quick search for “wrong patient similar names” in Sweden I get a number of newspaper articles, for example:
https://www.expressen.se/kvallsposten/patient-fick-fel-blod-hade-liknande-namn/
https://www.dagensmedicin.se/artiklar/2016/07/27/sjukhus-sovde-fel-patient/
We know that there will be scenarios when systems that conform with the national Patient-profile communicate with other systems that do not conform to the national profile. Therefore, we need to take into account that there will be systems that only handle HumanName.given and HumanName.family and not the middle-name-extension. We need to ensure that those systems also have as complete information about the patient’s name as possible.
From my point of view, we must provide the Swedish middle name in HumanName.family as well as in the nordic-middle-name-extension.

Martin Grundberg (Oct 09 2019 at 14:17):

I am with @Viktor Jernelöv and @Thomas Tveit Rosenlund on this one.

First of all, I think its should be a fundamental principle to not change the meaning of information communicated between systems, hence the middle name should not also be added to to familyName for the simple reason that it is not a part of the family name (like Viktor said, no oranges in the apple basket). I dont know the details of naming in the other Nordic countries, but at least my assessment is that appending the middle name to the family name is against Swedish legal recommendations (https://www4.skatteverket.se/rattsligvagledning/330287.html).

There are potential problems when the middleName extension is not handled by a system. If that is the case, having added it to the familyName means that the family name is incorrect and there is no way to find what is a middle name or a family name, and hence I would argue it cannot be accepted, meaning there is a risk of loosing the whole patient resource instead of just the middle name. From my point of view (an EHR vendors point of view), we would not accept a risk of saving incorrect data.

When it comes to the process of identifying a patient, a few things can be said about that:
1) how to identify patients is a business decision based on the available information in the hospitals system and the interaction with the patient, it doesnt really have anything to do with how you profile the patient resource
2) patient name is probably not a good way of identifying patients anyway, and the primary method for the business should be a patient identifier. As an example, different patients may have the same or similar names. There is a reason why scanning patient wristbands and id cards is the preferred identification method.

Extensions is a core part of FHIR, and we cannot introduce workarounds for all extensions like this and while doing so complicating life for producers and consumers of the information.

Thomas Tveit Rosenlund (Oct 09 2019 at 16:24):

I am with @Martin Grundberg on the point that a person name should not be the main identifier of a Patient receving care in most situations we will use an actual Identifier.

Furthermore I think @Viktor Jernelöv has an excellent point conserning the HumanName.text element. This could be used as a method to assure clients whitch do not conform to the no/se/dk HumanName profiles to still be able to see the full name of a Patient. A Norwegian argonaut IG (for example) could choose to add must-support and even a cardinality of 1..1 to the HumanName.text element to the profile.

Grahame Grieve (Oct 10 2019 at 06:48):

I've finally had a chance to catch up on this thread.

Grahame Grieve (Oct 10 2019 at 06:51):

I think that the last point from Thomas hasn't been considered enough in this thread - you can indeed make whatever rules you like internally, but it's the flow of information into consumer devices running international specifications that you have to consider carefully, since you have less control there. Consider this:

you make the rule that middle name is always in the family name as well
any scandinavian software knows that a middle name in the extension is removed from the family name
other software just uses the family name
this assumes that the middle name isn't independently duplicated in the family name (is that valid?)

Alternatively:

you make the rule that middle name is never in the family name as well
all scandinavian software finds the middle name extension
other software just ignores the middle name

The first feels inherently safer to me, but there's a proviso - maybe it's the tail wagging the dog, and losing the middle name in consumer software wouldn't matter? But this leads me to a follow up question:

Is there any published research about what people do with their middle names when setting up apple/google accounts etc?

One final comment: I think that if the international patient access spec doesn't make using HumanName.text must-support, then nothing is achieved by making it so in a scandinavian interpretation of that.

Grahame Grieve (Oct 10 2019 at 06:55):

I'll ask the argonaut clients what they do with name...

Grahame Grieve (Oct 10 2019 at 07:03):

see https://chat.fhir.org/#narrow/stream/207835-IPS/topic/Patient.20Name

Grahame Grieve (Oct 10 2019 at 07:03):

and https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/HumanName.2Etext.20question.20for.20clients

Martin Grundberg (Oct 10 2019 at 07:34):

@Grahame Grieve , I would argue the first approach isnt really safer for the following reasons:

the middle name is not a part of the family name, hence you are representing patient names in a way that is in conflict with national naming conventions
Consumers that cant handle the extension has no way of figuring out if the family name is correct or not, which at least means it cannot be used for persisting the name in that application as you risk incorrectly changing the patients name that is in conflict with the master patient index.
Business logic is forced on all producers and consumers to append/remove the middle name from the family name. What if a producer is not aware of this intended business logic (it will not be obvious as it is in conflict with naming conventions)?

I also see a risk of having this type of discussion for all extensions. That information is always at risk of being lost for a consumer that doesnt handle it, does that mean we should append that information also to some other standard element to be safe? And couldnt you have the same discussion about any non-extension element, what if it is not supported and removed from a profile, should that also be appended elsewhere?

It is true though that most people (in Sweden at least) will use their middle name together with their family name. And many would likely be confused to hear their name without the middle name. But keeping to the intended use of the resource elements and following national rules, as well as agreeing methods of integration between consumer and producer I would probably see as the safest path forward.

Grahame Grieve (Oct 10 2019 at 07:50):

so I'm just an observer here, with no strong opinion, and no right to have a strong opinion. But... consider these 2 things you said:

the middle name is not a part of the family name

many would likely be confused to hear their name without the middle name

These sounds inconsistent to me. And it's inconsistency that I heard through out the discussion and that make me ask about the 2 options

Grahame Grieve (Oct 10 2019 at 08:35):

I do think that the best option is dependence on HumanName.text, and to engage with specifications such as International Patient Summary and International Patient Access (code name for Argonaut gone global) to get that formalised (IPS does not). Same for Address.text

Viktor Jernelöv (Oct 10 2019 at 11:18):

so I'm just an observer here, with no strong opinion, and no right to have a strong opinion. But... consider these 2 things you said:

the middle name is not a part of the family name

many would likely be confused to hear their name without the middle name

These sounds inconsistent to me. And it's inconsistency that I heard through out the discussion and that make me ask about the 2 options

I would argue there is no inconsistency if you look at it a more closely. The Swedish (not sure about Norway or Denmark) Master Data source (MPIs) strictly seperate the middle name from the given name and the family name. Our job lies in achieving interoperability between systems, and to do that we need to maintain the semantic structures as far as possible. We don't want to remove the possibility for systems to distinguish between the different name parts and also at the same time make sure they don't confuse the name parts with each other.

This is not a controversial thing.

The fact that human beings are confused while hearing their name with a part excluded or not is a different question. The standard is (hopefully?) meant to achieve system <-> system interoperability and not focus on system -> human interoperability if that makes sense? That comes in a later stage and is handled by how the systems implement their business supporting features and how the people using the systems act.

Grahame Grieve (Oct 10 2019 at 11:26):

Perhaps that's my concern - the standard is meant to support the exchanges people want. That's not the same as what you said in a subtle but important way. That doesn't mean I don't agree with your points though. And I don't really have a an opinion about the outcome, I just want to make sure you've thought about it from all angles

Viktor Jernelöv (Oct 10 2019 at 11:35):

I do think that the best option is dependence on HumanName.text, and to engage with specifications such as International Patient Summary and International Patient Access (code name for Argonaut gone global) to get that formalised (IPS does not). Same for Address.text

This raises the question about what a "national basic profile" is and how it should relate to other profiles of different sorts. The idea that I personally have, and that I know at least SOME people (to use Fox News rhetorics) share, is that the national basic profiles are predefined building blocks to represent solutions to profiling problems/needs that most consumers and producers in a specific FHIR context are going to have to solve. This could be for instance:
*how do I represent a national specific address
*how do I make sure my data is tagged with the country specific metadata needed to ensure the various laws can be upheld
*how do I represent the different official identifiers used in our country
*etc

These profiles and extensions could then be used and extended by consumers that have a use case within the same "affinity domain". In the case with the middleName we simply state that "in the Nordic countries it's important to distinguish between the different parts of a person's name, and this is how you do it". If you are involved in a use case where this is NOT deemed important or meaningful, then by all means, use another profile that supports your use case!

If we try too hard to align all markets/communities to doing the exact same thing or representing the information in the exact same way you're removing one of the most vital cornerstone of the whole standard, clearly explained in https://www.hl7.org/fhir/extensibility.html .

If that's the ambition we have, maybe we're better off trying to standardise at the point of data creation and persistation (basically solving the interoperability problem the openEHR way) and not try to do it at a later stage in the data lifecycle when it's already been created and represented in a system?

Am I completely off track here? In that case, please enlighten me.

Viktor Jernelöv (Oct 10 2019 at 11:41):

Perhaps that's my concern - the standard is meant to support the exchanges people want. That's not the same as what you said in a subtle but important way. That doesn't mean I don't agree with your points though. And I don't really have a an opinion about the outcome, I just want to make sure you've thought about it from all angles

Fair enough!
But is that purpose, to cover the need of human <-> human information exchange, properly covered by the standard in its current shape? I would argue not, but will prefer to do so under more discussion friendly circumstances :)

Also, make no mistake @Grahame Grieve , your thoughts and perspectives are invaluable to all communities trying to make sense of what FHIR is and how it should be used in their specific contexts. Never stop! :)

Grahame Grieve (Oct 10 2019 at 11:47):

This raises the question about what a "national basic profile" is and how it should relate to other profiles of different sorts

I thought your description of what a national profile is was spot on. The tricky bit is that we are also paying attention to international exchange as well

Grahame Grieve (Oct 10 2019 at 11:48):

the rules there are different and slippery because it's not well worn ground. Also, we are not, as a group, used to dealing with external constraints from outside our own jurisdication

Viktor Jernelöv (Oct 10 2019 at 12:03):

I thought your description of what a national profile is was spot on. The tricky bit is that we are also paying attention to international exchange as well

As we should, but I'm questioning whether or not we should be concerned by that in the national profiling initiatives or if we simply should treat that as a different use case which needs a new set of profiling work. The latter seems much "cleaner" to me and in a way supports a "separation of concerns" approach to the problem area.

Grahame Grieve (Oct 11 2019 at 01:41):

.. so in practice, yes, we are treating that as a different use case and a different stack of profiles. But the resources themselves are not separate; you don't want to have to do special transformation. So the discussion here is about whether the national profiles (or nordic profiles) should do something (what?) in the national profiles because of something that will happen in the international rules

Grahame Grieve (Oct 11 2019 at 01:44):

but based on both public and private feedback, I think that populating HumanName.text has legs, and so both my earlier alternatives are less good than:

you make the rule that middle name is never in the family name as well
all scandinavian software finds the middle name extension
other software just ignores the middle name, but since it uses the HumanName.text, that doesn't matter

That does have the consequence that middle names are not really editable by non-scandinavian aware software, but I think that would be a very low or non-existent disadvantange

Viktor Jernelöv (Oct 11 2019 at 07:56):

.. so in practice, yes, we are treating that as a different use case and a different stack of profiles. But the resources themselves are not separate; you don't want to have to do special transformation. So the discussion here is about whether the national profiles (or nordic profiles) should do something (what?) in the national profiles because of something that will happen in the international rules

@Grahame Grieve , is there a different thread where this discussion is being held, or at least where it's more suitably held than in the nordics.Middle Name thread? I'd love to partake in that discussion if it's ongoing.

Grahame Grieve (Oct 11 2019 at 09:05):

hmm. not in any specific zulip thread - some on IG Creation, and then dispersed across our activities. will be more discussion next week while I move International Patient Access forward

Jens Villadsen (Oct 17 2019 at 05:42):

With those (I believe somewhat closing remarks) it seems evident to me (at least) that we use the same extension across the nordics for the middle name component in order to at least give vendors and communities outside the nordics a chance to achieve interoperability. @Grahame Grieve The FHIR spec contains standardized extensions. Could this pan-national extension such as the middle name extension be a valid candidate for a standardized extension? In DK I believe we will be discussing the middle name monday in the DK affiliate

Grahame Grieve (Oct 17 2019 at 21:25):

yes it's a candidate for inclusion in the base spec

Emmeli Gross (Oct 22 2019 at 06:56):

There are still some scenarios that aren’t covered by the last suggested solution to only use the extension for communicating the middle name. One scenario is that there may be software that doesn’t use HumanName.text but uses a combination of HumanName.given and HumanName.family instead. A consequence is then that they will not get the middle name at all. As HumanName.text has cardinality 0…1 in the FHIR spec, that is something I think you must consider.
When making national profiles, I argue that it should be a strong recommendation that the name should always be as complete as possible in all scenarios. The reason for that is that the patients name is used for ensuring the identity of the patient (often together with an identifier, but sometimes on its own.)
I the Swedish group there has been discussions about whether it is our responsibility or not. From my point of view, it is absolutely the responsibly of the makers of national profiles to consider the interoperability in an international context (and in the national context as well, as there will be profiles that are not based on the national profiles) and to do all you can to ensure that vital data isn’t lost in the communication.
@Grahame Grieve Do you know how other similar scenarios have been handled in other national profiles? Do you know if there are any recommendations about how you should handle HumanName.given and HumanName.family? It is not a desired behaviour of an API that new data could “pop up” in HumanName.text that you cannot find in any of the other two fields. It is quite easy to imagine a scenario where a system that does not support the nordic profile has got the complete name in HumanName.text and is forced to prop the data into a model where only two attributes are available in the form of a field for given name and another field for family name. How should they then know what to do with the middle name?
In Sweden, the situation regarding middle name is that you weren’t allowed to have two family names. If you wanted another family name (for example if you wanted to keep our own family name and also take your spouse’s family name) you had to take that new family name as a middle name. Today the rules have changed, you can now have two family names and it is no longer allowed to take new middle names. The persons who have middle names can change them into a family name and then have two family names instead. Therefore, in Sweden, the middle name could be regarded as a kind of family name.

Grahame Grieve (Oct 22 2019 at 07:08):

I don't have any better ideas

Jens Villadsen (Nov 02 2019 at 21:17):

Danish law is a bit different. You MUST have a single family name. There aren't any limits on either the amount of given names or the amount of middle names (though middle names tend to be like a family name). For identification in the healthcare sector, you are always asked for your full name and your civil registration number in order to ensure the identity. As such, the name is not used as a single factor in identifying the individual. It is the combination of name and registration number. Omitting eg. one of the given names and eg. a middle name in the bearing information is therefore not 'dangerous'

Thomas Tveit Rosenlund (Jan 27 2020 at 08:33):

On a side note, is there a way to restrict the search result from a server to only include a specific extension value? I can't seem to fix it. I can restrict it to give me all Extensions, but not only the middlename extension:
http://hapi.fhir.org/baseR4/Person/53098?_elements=name.extension

Jens Villadsen (Jan 27 2020 at 08:41):

I don't think there's syntax support for that using _elements

Thomas Tveit Rosenlund (Jan 27 2020 at 08:48):

@Jens Villadsen Neither do I unfortunately. The only other solution I can think of is some operations implemented specificly on the server, could get messy.

Grahame Grieve (Jan 27 2020 at 11:05):

the only thing we have that is that specific is graphQL

Thomas Tveit Rosenlund (Jan 27 2020 at 14:37):

Thanks for the feedback @Grahame Grieve I Guess we just have to implement graphQL on our servers then.

Grahame Grieve (Feb 02 2020 at 06:33):

related follow up issue: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/IPS.20Name.20Question - please comment

Thomas Tveit Rosenlund (Feb 05 2020 at 06:48):

Thanks for the tip @Grahame Grieve, have been held up With other business and did not see this issue until today, and now it's just settled :-)

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Middle Name · nordics

Stream: nordics

Topic: Middle Name

Grahame Grieve (Jun 07 2019 at 12:02):

Grahame Grieve (Jun 07 2019 at 12:02):

Jens Villadsen (Jun 07 2019 at 12:04):

Grahame Grieve (Jun 07 2019 at 12:04):

Grahame Grieve (Jun 07 2019 at 12:06):

Jens Villadsen (Jun 07 2019 at 12:08):

Grahame Grieve (Jun 07 2019 at 12:08):

Grahame Grieve (Jun 07 2019 at 12:08):

Grahame Grieve (Jun 07 2019 at 12:08):

Jens Villadsen (Jun 07 2019 at 12:10):

Grahame Grieve (Jun 07 2019 at 12:11):

Jens Villadsen (Jun 07 2019 at 12:11):

Vadim Peretokin (Jun 07 2019 at 12:12):

Grahame Grieve (Jun 07 2019 at 12:15):

Thomas Tveit Rosenlund (Jun 07 2019 at 12:53):

Grahame Grieve (Jun 07 2019 at 13:08):

Jens Villadsen (Jun 09 2019 at 09:46):

Grahame Grieve (Jun 09 2019 at 09:47):

Jens Villadsen (Jun 09 2019 at 09:52):

Grahame Grieve (Jun 09 2019 at 10:28):

Martin Grundberg (Jun 26 2019 at 20:45):

Oskar Thunman (Jun 27 2019 at 08:29):

Martin Grundberg (Aug 01 2019 at 07:51):

Martin Grundberg (Aug 01 2019 at 08:13):

Martin Grundberg (Aug 01 2019 at 11:03):

Viktor Jernelöv (Aug 05 2019 at 12:28):

Thomas Tveit Rosenlund (Aug 13 2019 at 06:38):

Martin Grundberg (Aug 14 2019 at 12:31):

Thomas Tveit Rosenlund (Aug 14 2019 at 13:04):

Thomas Tveit Rosenlund (Sep 10 2019 at 08:51):

Espen Stranger Seland (Sep 10 2019 at 21:26):

Vadim Peretokin (Oct 02 2019 at 08:53):

Vadim Peretokin (Oct 02 2019 at 08:53):

Viktor Jernelöv (Oct 02 2019 at 14:54):

Thomas Tveit Rosenlund (Oct 03 2019 at 05:41):

Emmeli Gross (Oct 07 2019 at 14:54):

Martin Grundberg (Oct 09 2019 at 14:17):

Thomas Tveit Rosenlund (Oct 09 2019 at 16:24):

Grahame Grieve (Oct 10 2019 at 06:48):

Grahame Grieve (Oct 10 2019 at 06:51):

Grahame Grieve (Oct 10 2019 at 06:55):

Grahame Grieve (Oct 10 2019 at 07:03):

Grahame Grieve (Oct 10 2019 at 07:03):

Martin Grundberg (Oct 10 2019 at 07:34):

Grahame Grieve (Oct 10 2019 at 07:50):

Grahame Grieve (Oct 10 2019 at 08:35):

Viktor Jernelöv (Oct 10 2019 at 11:18):

Grahame Grieve (Oct 10 2019 at 11:26):

Viktor Jernelöv (Oct 10 2019 at 11:35):

Viktor Jernelöv (Oct 10 2019 at 11:41):

Grahame Grieve (Oct 10 2019 at 11:47):

Grahame Grieve (Oct 10 2019 at 11:48):

Viktor Jernelöv (Oct 10 2019 at 12:03):

Grahame Grieve (Oct 11 2019 at 01:41):

Grahame Grieve (Oct 11 2019 at 01:44):

Viktor Jernelöv (Oct 11 2019 at 07:56):

Grahame Grieve (Oct 11 2019 at 09:05):

Jens Villadsen (Oct 17 2019 at 05:42):

Grahame Grieve (Oct 17 2019 at 21:25):

Emmeli Gross (Oct 22 2019 at 06:56):

Grahame Grieve (Oct 22 2019 at 07:08):

Jens Villadsen (Nov 02 2019 at 21:17):

Thomas Tveit Rosenlund (Jan 27 2020 at 08:33):

Jens Villadsen (Jan 27 2020 at 08:41):

Thomas Tveit Rosenlund (Jan 27 2020 at 08:48):

Grahame Grieve (Jan 27 2020 at 11:05):

Thomas Tveit Rosenlund (Jan 27 2020 at 14:37):

Grahame Grieve (Feb 02 2020 at 06:33):

Thomas Tveit Rosenlund (Feb 05 2020 at 06:48):