Extending a required binding on ContactPoint

So we’ve got an interesting issue in New Zealand (from a FHIR perspective of course). We’re in the process of creating extensions to be used nationally, and one of the requirements we have is to be able to store the HealthLink EDI number – an ‘address’ used to send information electronically between healthcare providers.

Some background: in New Zealand we have a messaging service that is operated by a private company (HealthLink) which has national coverage that connects Primary care with Hospitals, Laboratories and other services such as eReferrals. It’s actually been running for a number of decades and has certainly helped with electronic sharing of information. The company provides vendors with client-side applications they they use to interact with the service.

Users of the service are assigned a unique code (the EDI number) that acts as a delivery address for the user (which can be an individual or an organization). For example, when a hospital wishes to send a Discharge Summary to the patient’s General Practitioner (their Primary / Ambulatory care provider) then they will send the summary to the service, asking for it to be delivered to that EDI account.

As we move into FHIR, the question is how do we represent that number? For the purposes of this discussion, we’ll assume that we wish to attach it to a Practitioner resource, though it will also need to be applied to others such as Organization or PractitionerRole.

An initial option we thought of is to use the EndPoint resource. But if you look at the description of that resource it states:

The technical details of an endpoint that can be used for electronic services, such as for web services providing XDS.b or a REST endpoint for another FHIR server. This may include any security context information.

And that isn’t really what we are after. We’re not concerned with how the payload is to be moved – just where the destination is. 

If we take a look at the Practitioner resource, we see that it has a .telecom element. The description of this element is:

A contact detail for the practitioner, e.g. a telephone number or an email address.

That does look like what we’re after but there’s a catch. When we look at the definition of the datatype of the element (which is a ContactPoint), we see that the system child element (which is the ‘type’ of communication) is a code that has a required binding to the ValueSet – and looking at the contents of the ValueSet, there isn’t anything that looks like an EDI number. Bother.

A required binding means that we have to choose one of the values from the valueset – we can’t just add another one. But – we are allowed to use extensions to ‘refine’ the value – or to make it more specific. 

So provided that there is an existing value which matches (at a more general level) the one we want to use then we can use that one, and add an extension for our more specific value. And – there is an ‘other’ value in the ValueSet – we’re in business!

So here’s what it could look like ‘on the wire’:

<telecom>
  <system value="other"> 
    <extension url="http://hl7.org.nz/fhir/StructureDefinition/edi-address">
       <valueCode value="healthlink-edi-number"/> 
    </extension> 
   </system>
 <value value="someedi"/>
</telecom>

A recipient parsing the resource would see that the value of ContactPoint.system is ‘other’, and that there is an extension on that value. The extension url points to the extension definition (a StructureDefinition resource) which describes what it means. If they aren’t particularly concerned about the EDI then they simply record the ‘connection type’ as ‘other’. If they are interested then they know that this value refers to the EDI.

In practise, only New Zealand clients are going to be interested in the EDI number (as it only works in New Zealand) – and they should have access to the Implementation Guide which will describe this use.

There’s an argument to say that this is all too complex – why not just put the extension on the root of the resource? 

Well, the primary reason is that the Practitioner.telecom element seems a good match for our requirements so we really shouldn’t be putting something that belongs there somewhere else. In effect we’d be saying the “if the communications method is an email or a fax, then the location is at Practitioner.telecom, If it’s an EDI account then go look at Practitioner.extension. That just doesn’t seem right.

And it’s not like it’s hard to get at the extended telecom value – all the client libraries expose extensions so it’s just a matter of specific code to get the EDI number – which you’d have to do wherever the EDI number was located.

And finally, when we look at the description of the ValueSet, we see the following description of ‘other’:

A contact that is not a phone, fax, page or email address and is not expressible as a URL. E.g. Internal mail address. This SHOULD NOT be used for contacts that are expressible as a URL (e.g. Skype, Twitter, Facebook, etc.) Extensions may be used to distinguish “other” contact types.

We’re on the right track!