DMS Profiles, names with different cardinality requirements

[james-answer]

In the DMS profiles for all the different Fhir Resources which contain a HumanName element, weather than be the pratient, patients contact, practitioner, etc, the cardinality of the name fields such as given name and family name change. There is no consistency or reason why they are one way for one resource and another way for a different resource.

For The Practitioner Resource (https://data.developer.nhs.uk/fhir/candidaterelease-250816-appts/Profile.GetScheduleQueryResponse/gpconnect-practitioner-1.html)

The name is a standard HumanName FHIR data type apart from the family name, which has been restricted down to a single entry, the practitioner can have as many given names as they want.

For the Patient Resource (https://data.developer.nhs.uk/fhir/candidaterelease-250816-appts/Profile.GetScheduleQueryResponse/gpconnect-patient-1.html)

The patients name is restricted to only have a single given name and a single family name. The patients contact name within the same resource is just the standard HumanName data type so can have as many given and family names as they want.

This seems wrong, the name format we expect in any resource should in reality be consistent. The best thing to do would be to stick with the standard Fhir HumanName which can have as many given or family names as is required to accuratly represent the persons names.

By restricting name fields this could lead to confusion and errors, for example if you pass in three names in the persons given name field as they have a forename and two middle names, if the recieving system has a character limit, part of the second name or third name may be lost, how would consumers be expected to filter so they can just get the first name. It would be better to allow the additional name fields so that data can be represented accuratly.

[michaelmeasures]

@james-answer a potential problem with allowing the full flexibility inherent in the FHIR Human Name model is that we'd need to provide extra guidance around the population of 'use' and how to interpret / display multiple surnames etc.

[james-answer]

Still, shouldn't the profiles should still be consistent so a consumer can always expect the same from a name field in different resources?

[michaelmeasures]

Yep, I'm all for consistency but think we should consider simplifying down (either in the profile or guidance) the practitioner and patient contact details to come inline with the approach taken with the patient resource.

[michaelmeasures]

I'd suggest a single family name with consumers/providers populating one or more given names. I guess the question then becomes how are multiple given names expected to be handled in the consumer i.e. can you safely just take the first one, or do you need to concatenate and show all?

[adamjlees]

CUI design guidance defines GIVEN NAME and FAMILY NAME (for display purposes) as including 1 or more "components", i.e. multiple name or name parts concatenated, with a max field length applied (so potentially truncated) too. http://webarchive.nationalarchives.gov.uk/20160921135207/http://systems.digital.nhs.uk/data/cui/uig/patnamedisp.pdf

For these reasons I'd suggest 1 family name and if multiple given names are provided, to concatenate at least up to the 2nd.

The PDS documentation I've found is contradictory: e.g. SMSP says 0..1 Family Name and 0..2 Given Names, not mentioning the size. PDS (Spine Connect) says 1 Family Name (35 chars), 1 First Given Name (35 chars) and one Other Given Name(s) (100 chars).

The CUI guidance itself says PDS name field length is 40 chars but the NHS data dictionary says 35 chars!

[adamjlees]

Part of a wider consultation about the gp connect fhir profiles/DMS

[jackiebarnes]

Am gathering this together with other 'business' requirements-related changes for DMS change proposals

[james-answer]

This issue with inconsistent cardinality of name elements within fhir profiles no longer exists since the change to use the CareConnect profiles as a base resource. The name element has a consistent 1 family name and 0..* given names. Therefore closing the issue as it is no longer relevant.