0

Currently (02-12-2013), in the practitioner resource 0..1 names can be associated to a practitioner. In contrast, 0..* names can be associated to a patient. This allows specifying a person's maiden name for example. Why is there this difference?

In the project I'm working on, we're exporting existing data about practitioners from our database using FHIR messages. In the database, all persons are stored in the same way. Since it is possible to store a person's maiden name (which is also done for practitioners in our data), we have to build the name part in a practitioner message differently from the name part in a patient's message. Also, when parsing a practitioner message, we'll need different code to extract the name of a patient and of a practitioner.

Therefore, I believe that there are two disadvantages of having different generic attributes of persons of different kinds:

  1. It prevents us from sending the complete name information of a practitioner without resorting to extensions.
  2. It complicates the code for building and parsing FHIR messages, which also makes the code less maintainable.

I understand that in most cases it's not very important to be able to send the maiden name of a practitioner, but it does add extra complexity for the implementation. Furthermore, I don't see what problems setting the cardinality to 0..* could cause. If someone only wants to send a single name, then that's still possible.

Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also discussed here) also seems like an unnecessary restriction.

Community
  • 1
  • 1
Tom
  • 1
  • 1

2 Answers2

1

Managing cardinality is a tricky issue. If the resource can have multiple names, then everyone dealing with this has to deal with the possibility of multiple names. The relevant committee believes that having multiple names is an unusual practice for practitioner records (that's certainly my experience) but a common one for patient.

Perhaps you'd like to explain your full use case so it can be considered by the committee? On the other hand, you can use an extension:

<Practitioner>
  <extension url="http://myurl.com/fhir/profiles/extensions#maiden">
    <valueHumanName>
      <!-- details for human name -->
    </valueHumanName>
  </extension>
</Practitioner>
Grahame Grieve
  • 3,538
  • 3
  • 15
  • 17
  • Hi Grahame, thanks for the reply! I've add some more explanation in my original question. – Tom Dec 18 '13 at 15:52
  • I don't think it changes my answer - the committee doesn't think this is a value proposition, weighing the costs. I have passed your comments on to them. – Grahame Grieve Dec 18 '13 at 20:42
1

Therefore, I believe that there are two disadvantages of having different generic attributes of persons of different kinds:

When designing Patient, Pracitioner and RelatedPerson, we have tried several different solutions:

  1. having Person resource, separate from Patient/Pracitioner. This proved to be burdensome since many systems (unlike yours!) don't capture patient and person separately, and when looking at REST useage patterns it turned out they were always needed togehter, resulting in unneccessary burden on client and server
  2. Having a special Demographics datatype which contained all shared attributes. This met resistance since it meant having attributes on Practitioner that did not make sense, e.g. marital status and deceasedDate. This run against our intent to keep the Resources focused to their scope and the number of attributes per resource manageable.

This is how we ended up where we are now: more or less "duplicating" the attributes (when applicable) across those three resources.

Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also >discussed here) also seems like an unnecessary restriction.

The Practitioner resource represents a person employed by an organization to provide care. We assumed that for one such engagement, there is one "official" (post) address for that person. The practitioner may however perform services at multiple locations (each of which can have an address).

Ewout Kramer
  • 984
  • 6
  • 9