TEP Schema with Extension

I realize that some of these comments are more directed towards the RIM, but they also directly impact TEP.

I think there are three use cases that we are trying to shoehorn the extension concept into.

1. Community augmentation – community adds new information that is associated to the EDXL standard. Example – adding HL7 translation information to the TEP

2. ValueList/ValueKey augmentation – community adds new values (enumerations) to the default set of values in the standard. Example – adding FlightRisk value to the TEP contingencyMedicalSpecialityCode list

3. ValueList/ValueKey replacement – community replaces the default set of values in the standard in its entirety. Example – defining TriageStatus with number codes instead of colors

4. ValueList/ValueKey redefinition – community redefines the meaning of the default set of values in the standard in its entirety. Example – redefining the Black TriageCode to mean actively dying but not yet deceased

Community augmentation is pretty straight-forward because it augments the EDXL standard with new information that the community understands. It does not affect consumers outside of the extension community.

ValueList/ValueKey extension is a lot more complicated. As some background, TEP tried to define a default set of values that could be selected from for certain value lists/value keys. Additionally, it was decided that standard adopters should be able to specify their own set of values to choose from. TEP solved this by providing a choice between the default set of values and a custom set of values with different element names. The TEP default set of values, however, had a namespace issue and had to be associated to the common types namespace. This was deemed unacceptable, so extensions (previously known as layers) were investigated as a possible solution. The choice between the TEP default set of values and a custom set of values was removed. Only the simplified set of default values would be used. Extensions would use the name/value parameter pair to represent the custom set of values and their choices. The name element would be expected to be the Uri of the custom set of values. The value element(s) would be the choice(s) from that list. While this is a decent compromise, it does lead to an interesting situation. There are now two sets of values for the same standard field: the default set as defined in the standard schema and a new set as defined in the extension. This is not what was intended with the choice between the default set of values and custom set. The choice enforced only one set of values would be used/present in an instantiation of the TEP standard.

However, having two sets of values shouldn’t be an issue as long as a default value can be used in addition to a custom value. If, on the other hand, there is no default value that can be selected, either because the field is a ValueKey (1 value), because the choices from a ValueList don’t use any of the defaults, or because the community redefines the meaning of the default values, having two sets of values is an issue. In this case, there needs to be some indicator in the default set of values that there is no appropriate value to select from and that the extension is specifying the value. I would remind everyone this is no different than if a community chose to use their own list as TEP originally intended. Consequently, I strongly feel that each default set of values should include a new value: “extension” (or something to that effect.) It would be the expectation/requirement that any community would use this value when there was no applicable default value OR if they were REDEFINING the meaning of a default value. It would potentially be disastrous if a community redefined the meaning of a default value and shared that message with non-community adopters. There would now be two different understandings of what that message and value meant.

Two things have been discussed and raised as concerns with the extension mechanism and valuelist/valuekey extension. The first is redefining the meaning of a default value. The second is interoperability with non-communities adopters. I would contend that both these issues exist whether the extension mechanism or choice mechanism is used. If a community decided to use the choice mechanism to define a custom set of values, there would be potential issues with non-community adopters interpreting what those values mean. The choice mechanism also does not preclude a community for redefining what a default value means. It would be bad form, but they might have good reason for it. Because the choice mechanism forced the adopter to choose one list or another, it didn’t suffer from a two value/two meaning situation. There was only one value/one meaning. It might be that the non-community adopters don’t understand that meaning, but at least there was little chance that community adopters and non-community adopters would interpret the same message differently. Either the non-community adopters understood the custom values or they didn’t. Without the notion of an “extension” value, we have the real possibility that the different communities could interpret the same message differently, because there would be a default value and new custom value, which may or may not align. The “extension” value allows communities to extend the default sets of values without being forced to choose/specify a value from that default set.

Overall, I think extension is a good mechanism to allow communities to adapt a standard to meet their needs without changing the underlying standard. This should facilitate adoption.

I will try to provide some more extension examples for the next TEP meeting (this coming Thursday).

Brian M Wilkins

Senior Software Systems Engineer

The MITRE Corporation

bwilkins@mitre.org

office: 781-271-2332

cell: 781-710-2617

emergency-tep message