Difference between revisions of "Adding ID data type and associated impact analysis"
Hugh Glover (talk | contribs) |
Hugh Glover (talk | contribs) |
||
| Line 4: | Line 4: | ||
====Download Slide Deck==== | ====Download Slide Deck==== | ||
| − | Please download the slide deck describing this issue and add your comments below. | + | Please download the slide deck describing this issue in detail and add your comments below. |
[[Media:Adding_ID_data_type_and_associated_impact_analysis_v3.pptx]] | [[Media:Adding_ID_data_type_and_associated_impact_analysis_v3.pptx]] | ||
| + | ====Comments==== | ||
| − | ==== | + | ====Impact Analysis==== |
| − | ==== | + | Before beginning a detailed analysis of the possible impact of such a change on BRIDG we need to understand exactly what is being proposed. The following description is taken from the vendor making the proposal and reflects their practical experience. These definitions can be further refined. |
| + | |||
| + | ==ID Data Type - draft definition== | ||
| + | |||
| + | The ID data type contains the standard II data type provided by ISO21090, but in BRIDG on many occasions where an identifier is required there is also a requirement for a type code to make it clear what sort of identifier we are looking at. For example is this a system identifier or a user entered identifier? | ||
| + | |||
| + | In cases where both a system identifier and a user entered identifier are required the only way to manage this at present is to put the identifier and the type code into a separate class and provide an association with a cardinality upper limit of >1. Using this class as if it were a data type allows us to have an identifier attribute rather than a complete class. | ||
| + | |||
| + | A further issue arises when the provenance of an identifier is required: "what sort of system provided the system identifier?" and even: "exactly which system provided the system identifier?". To meet these needs a sourceCode and sourceIdentifier attribute are provided. The relationship of these to the BRIDG concept of SystemOfRecord needs further thought. | ||
| − | + | Finally when BRIDG puts an identifier into a separate class it often has a primaryIndicator and an effectiveDate associated with them. | |
| − | |||
| − | <table> | + | <table class="wikitable"> |
<tr> | <tr> | ||
<th>Field </th> | <th>Field </th> | ||
| Line 33: | Line 41: | ||
<td>A value specifying the kind of identifier that this is. This is used to distinguish a system generated identifier from (say) a user entered identifier. </td> | <td>A value specifying the kind of identifier that this is. This is used to distinguish a system generated identifier from (say) a user entered identifier. </td> | ||
</tr> | </tr> | ||
| − | |||
<tr> | <tr> | ||
| Line 50: | Line 57: | ||
<td>effectiveDateRange | <td>effectiveDateRange | ||
<td>IVL_TS_DATETIME | <td>IVL_TS_DATETIME | ||
| − | <td>The date interval when the ID is valid. Before the start date and after the end | + | <td>The date interval when the ID is valid. Before the start date and after the end date the ID is not valid and should not be used. |
| − | |||
| − | |||
</tr> | </tr> | ||
| Line 58: | Line 63: | ||
<td>primaryIndicator </td> | <td>primaryIndicator </td> | ||
<td>BL </td> | <td>BL </td> | ||
| − | <td>Set to true if this is the main identifier in cases where multiple identifiers are given. While this is close in concept to a Primary Key | + | <td>Set to true if this is the main identifier in cases where multiple identifiers are given. While this is close in concept to a Primary Key is actually a somewhat looser concept. </td> |
</tr> | </tr> | ||
| − | |||
</table> | </table> | ||
Revision as of 10:43, 28 July 2016
Return to BRIDG
Download Slide Deck
Please download the slide deck describing this issue in detail and add your comments below.
Media:Adding_ID_data_type_and_associated_impact_analysis_v3.pptx
Comments
Impact Analysis
Before beginning a detailed analysis of the possible impact of such a change on BRIDG we need to understand exactly what is being proposed. The following description is taken from the vendor making the proposal and reflects their practical experience. These definitions can be further refined.
ID Data Type - draft definition
The ID data type contains the standard II data type provided by ISO21090, but in BRIDG on many occasions where an identifier is required there is also a requirement for a type code to make it clear what sort of identifier we are looking at. For example is this a system identifier or a user entered identifier?
In cases where both a system identifier and a user entered identifier are required the only way to manage this at present is to put the identifier and the type code into a separate class and provide an association with a cardinality upper limit of >1. Using this class as if it were a data type allows us to have an identifier attribute rather than a complete class.
A further issue arises when the provenance of an identifier is required: "what sort of system provided the system identifier?" and even: "exactly which system provided the system identifier?". To meet these needs a sourceCode and sourceIdentifier attribute are provided. The relationship of these to the BRIDG concept of SystemOfRecord needs further thought.
Finally when BRIDG puts an identifier into a separate class it often has a primaryIndicator and an effectiveDate associated with them.
| Field | Data Type | Comments |
|---|---|---|
| dentifier | II | The actual identifier - composed of an optional root value to guarantee uniqueness and an extension value which is what would commonly be thought of as the "identifier" |
| typeCode | CD | A value specifying the kind of identifier that this is. This is used to distinguish a system generated identifier from (say) a user entered identifier. |
| sourceCode | CD | A code representing the kind of system that provided the identifier. Note that this is what provided the identifier to the application and is not by definition the initial creator/issuer of the identifier. |
| sourceIdentifier | II | An identifier representing a specific instance of of a system (as specified in sourceCode) that provided an identifier to the application. Note that this is not by definition the originator of the identifier merely the one that provided it to the application. |
| effectiveDateRange | IVL_TS_DATETIME | The date interval when the ID is valid. Before the start date and after the end date the ID is not valid and should not be used. |
| primaryIndicator | BL | Set to true if this is the main identifier in cases where multiple identifiers are given. While this is close in concept to a Primary Key is actually a somewhat looser concept. |
