Composer.name changed for an external_ref -> ERROR

Implementation
1

Hi all

We have an issue affecting our ReSPECT implementation which runs on an instance of EHRbase.

Essentially, for our Composer values in ReSPECT compositions, we store this:

"composer": { "_type": "PARTY_IDENTIFIED", "name": "John Smith", "external_ref": { "type": "PERSON", "namespace": "NHSScotland", "id": { "_type": "GENERIC_ID", "value": "john.smith@nhs.scot", "scheme": "NHSScotland" } } }

This was fine until last week when the format of someone’s name (from their AAD token) changed from ‘Surname, Forename (Organisation Name)’ to ‘Forename Surname’.

This then caused EHRbase to return an error, and we could not commit the record.

‘composer.name’ and ‘composer.external_ref.id.value’ are taken from Azure Active Directory token values for ‘Name’ and ‘e-mail’ respectively. Neither of these values is immutable in the AAD token.

We think what is happening is that when a composer value is sent, EHRBase checks the ID and if it finds it in a previous record (all IDs are stored in a table*), and the name does not match what it has stored for the same ‘composer.external_ref’, then it throws an error.
We are not bothered by the ‘name’ value changing as that is for display purposes and people should be able to format that as they wish. Names may also change, for e.g. marriage, other choices. The ID value unique to the person is their e-mail.

Any suggestions as to how to handle this issue?

Our devs propose one of:

  • Remove the Composer Name and External Reference Check in EHRBase
  • ReSPECT Queries EHRBase for the User’s Name Before Sending the Composition
  • ReSPECT Adds a Layer of User Management

none of which are super nor necessarily achievable, so we are still investigating an approach.

I’d appreciate any suggestions or comments that could help us resolve this.

Thanks all

Paul

*I am told this table: org.ehrbase.jooq.pg.tables.PartyIdentified

2

This does seem like incorrect behaviour. As you say the ‘name’ is not intended to be definitive - it is just for display purposes so if your diagnosis is correct, Ehrbase is being over-prescriptive here @birger.haarbrandt @vidi42 ??

3

@ian.mcnicoll @Paulmiller the team will take a look at this!

1 Like
4

@Paulmiller I got some feedback: for now and as a short-term workaround it would be advised to make this change on the database.

The new EHRbase does not have this issue and will be released soon. Though we will decouple the release from the migration path from data stored in old EHRbase to new EHRbase to avoid further delay. So if this issue needs to be resolved asap, then please use the workaround.

1 Like
5

Amazing, @birger.haarbrandt really appreciate your help and feedback. :+1: Our team is meeting this morning to decide on what to do.