Stream: implementers
Topic: Profiling for business identifiers - best practice?
Allan Bro Hansen (Apr 01 2019 at 21:59):
Our Appointment Resource is going to support a business identifier for Appointments created/defined by external systems (Diagnostic Imaging - currently four different vendor-systems have been identified). We have also identified future similar usage for other types of systems.
I am wondering whether I should choose
A) a very strict approach:
- The possible values for identifier.system must be known by our server
Hence the Appointment Structure Definition can be very explicit about the known possible identifiers; and other systems may use this.
Likewise, we can choose to have special business rules for special systems (some systems may e.g. want us to treat "their" appointments as read-only).
The major drawback is the integration of new external systems: their identifiers will not be accepted by the server without whitelisting the new identifier.system (and we currently only have a few yearly releases...)
The major advantage is the strictness - we know the possible identifier.system and can be clear about the meaning and possible restrictions on the identifier.value in the structure definition.
Or
B) a very loose approach:
- Everything goes for the identifier.system (as long as the format is valid) and likewise for the identifier.value.
(we may also need a displayable system value).
Or
C) Something in between:
- some of the possible identifier.system are known and will be part of the structure definition.
- new/unknown identifiers are supported but we will encourage a governance in which they are added to the structure definitions as part of the next release.
I am currently in favor of C) - any inputs/suggestions?
Jean Duteau (Apr 01 2019 at 22:07):
Why don't you want the loose approach? It seems like a configuration headache every time you add a new partner.
Lloyd McKenzie (Apr 01 2019 at 22:09):
For identifiers you need to recognize due to business rules, you'll need to ensure that everyone uses the correct 'system'. For everything else, it shouldn't matter. You shouldn't constrain people from sending identifiers that you might not recognize/care about as others you pass the data on to might well care/recognize them.
Allan Bro Hansen (Apr 01 2019 at 22:18):
@Jean Duteau Yes - the "headache" is the drawback of approach A. Approach C mitigates this (and we not expect new partners to turn up frequently).
@Lloyd McKenzie Agree - and good point about possible just being a kind of identifier-repository (although that will not currently be our role)
Last updated: Apr 12 2022 at 19:14 UTC
