Executive Summary


Annotating RIM-based Models (RBMs)



Yüklə 464 Kb.
səhifə5/13
tarix30.10.2018
ölçüsü464 Kb.
#76220
1   2   3   4   5   6   7   8   9   ...   13

1.8Annotating RIM-based Models (RBMs)

1.8.1Managing References

1.8.1.1Proposal


XUMs should be specific about which classes can be conveyed by reference rather than by value. This may be done by a flag shown in the RBM.

1.8.1.2Discussion


There is a strong desire to use references in the wire form for some parts of the models, in order to reduce the duplication of redundant data in the instance. We could simply allow this for any class in the instance, but long debate (to be closed in Boca Raton) has shown that this is too expensive at the implementation level.
Specific associations could be marked to indicate that they can be referenced in the instance. Note that the default on all associations would be that they cannot be referenced; only the author of the RBM may mark an association as implementable by reference.

1.8.1.3Benefits


This will allow some classes to be passed by reference, dramatically reducing message size in some circumstances without imposing the cost of introducing references everywhere in the instance.

1.8.1.4Cost / Risk


The committees will need to make a ruling on which classes may be passed by reference (this should be fairly rare, and only apply to very common participations, such as author).
This introduces a new RBM flag for tooling support.

1.8.1.5Performance


This will dramatically improve performance for some implementations.

1.8.1.6Usability


Because the reference can only be used in certain circumstances and it is clearly indicated in the XUM, the references do not impact usability.

1.8.2Infrastructure Root Attributes

1.8.2.1Proposal


For implementation purposes, allow committees to indicate that the infrastructure root attributes on a particular class are prohibited, and introduce new flags on the RBM to record this information.

1.8.2.2Discussion


Often the modelling process involves the creation of a number of RIM classes that do not have a useful real world equivalent; they are only required to meet the RIM grammar requirements.
There is no useful point for these classes to carry Infrastructure root attributes such as nullFlavor. Often there is a cascade of classes where any one of them could carry a nullFlavor, but all the possible permutations of statements carries the same meaning

in the domain models.


1.8.2.3Benefits


Allows the elimination of model attributes from an instance that serve no implementation purpose. Makes implementation easier as implementers will need to consider fewer attributes, avoiding some with uncertain meaning (as demonstrated by various list server debates).

1.8.2.4Cost / Risk


Adds workload, training, and tooling requirements to V3 modeling development. Care in terms of guidance and quality checking is needed to ensure that the flag meanings are not inappropriately applied.

1.8.2.5Performance


Performance will be enhanced, mainly when reading, as less attributes exist that need to be considered (even when not much is done with them, applications must still check for them).

1.8.2.6Usability


See Benefits.

1.8.3“Flattening” Models

1.8.3.1Proposal


Flatten associations with maximum cardinality of 1 where the infrastructure root attributes on the target class have been prohibited, by removing the association and the target class, and putting the attributes and associations of the target class on the source class.

1.8.3.2Discussion


Where the InfrastructureRoot attributes have been prohibited, there is no need to represent the RBM association and target as an association in the XUM. The attributes of the target class can be folded into the source. This works because there is no name clashes in the attribute names (though even this could be managed). The XUM must allow for an application to reverse engineer the flattening transformations.
Note that should the maximum cardinality be 0, the XUM will automatically exclude the association.
For more information about re-shaping and a prototype tool, see Appendix C.
The flattening cannot be achieved across model boundaries – it is important to maintain these model boundaries in support of code re-use.
There is ongoing discussion about whether the flattening should be dependent on the status of the infrastructure root attributes. However, if null flavour, realmId or template Id are allowed on an association target class, it is rather poor design in the XUM to have a single class with attributes and associations subject to different nullFlavors, realmId or templates depending on their original source, so this should only be allowed where the infrastructure root attributes of the target are prohibited.

1.8.3.3Benefits


Reduces message processing time for validation. Supports easier de-bugging of message instances. Provides a slightly more direct view of message ‘payload’ data.

1.8.3.4Cost / Risk


The biggest risk here is for applications that use RIM based processing of the data, without using MIF (or XUM) when the instance is read (as the javaSIG and Eclipse V3 code do). Note that such applications can only exist if the instance includes the default and fixed values – this is discussed below.
An associated risk is that the flattening is done differently for different models and also could be inconsistent because it is not done across model boundaries.
This introduces new differences between the instance and the RBM, although there should be no difference between the instance and the XUM.

1.8.3.5Performance


Reduces message processing time for validation.

1.8.3.6Usability


See Benefits.

1.8.4Annotating RBMs with business names

1.8.4.1Proposal


Most artefacts in HL7 diagrams may be given ‘business names’– the MIF supports this, but support in the current V3 tooling is haphazard and the feature is rarely used by V3 modellers. We propose explicitly representing business names in the published V3 diagrams. For instance, with attributes, the current representation is something like

name [: Type] [constraints]

This could be changed to:

business name ["name"] [:Type] [constraints]


Note that this proposal is not directly related to XUMs or the wire format, but may independently increase the usability (understandability) of RBMs from an implementation perspective. It is also recognised that this is not a new capability, but that there would be benefit to the V3 product if it was used to a greater degree than at present.

1.8.4.2Discussion


We previously proposed that it would be useful to produce a mapping between Analysis models and RBMs (RIM based Models), and then to factor this mapping into the ITS, on the basis that this would be useful tool for introducing implementation concepts into the instances. Although further research has shown that this is generally not appropriate, a particular aspect of Analysis models remains of interest with respect to message design usability.
From the perspective of implementing HL7 V3, a key aspect of HL7 Domain Analysis Models (DAMs) is their domain specific names for domain specific concepts – these are currently lost in RIM-Based Models (RBMs). We believe that these names are important, and that they should be carried into the message design process beyond domain analysis modelling.
Also, the exercise of mapping between DAMs and their associated RBMs is useful in its own right as a quality assurance step and in order to support the traceability between requirements and messages designs.
We suggest that the inclusion of business names provides a notational map between the RBM and ‘real world’ terms and/or analysis models. We are proposing that the capability to do this be made available to all models, whether they are global DIMs or local profiles.
One of our initial ideas was to use business names in the instance rather than RBM names. For now, we are not proposing to use business names for this purpose, given the competing objective of wire format stability and issues related to semantic processing. We recognise that there would be additional benefit in standardising the use patterns of business names, but we believe that we should experiment with this approach before proposing any particular standards for their use.
An alternative to this proposal is to more tightly integrate the analysis model and the RBM than simply providing some form of alias naming. This is an attractive option, but we have not investigated the logical and tooling concepts of this approach.

1.8.4.3Benefit


The presentation of business names on the diagrams would help in the ease of human understanding of HL7 message models (i.e. for business experts and applications developers). It could also help in tracing message artefacts to business requirements and in mapping V3 instance data to local data stores.

1.8.4.4Risk / Cost:


Adding business names may increase the workload of V3 modellers, and also places more emphasis on the importance of establishing committee-level business analysis / requirements models (and terms or class names) in V3 development. (This may be a benefit rather than a risk.) Note that we do not propose to mandate the use or presence of the business names, only to leverage them more if they are provided. Diagrams showing business names alternatives could be a user view option, with appropriate tooling.

1.8.4.5Performance


No impact

1.8.4.6Usability


We believe that judicious use of business names could improve the implementers experience as they could more easily see the relationship between the RBM and its analysis model.

1.8.4.7Example


In development.

1.8.5Using Business Names in the instance

1.8.5.1Proposal


We propose that the XUM uses appropriate real world names for classes, associations and attributes as they are available, and that they are sourced from the business names on the RBMs.

1.8.5.2Discussion


For implementers, this means that in the instance, the names of the associations and attributes will be names that they are familiar with, or at least names that they can trace more easily to analysis models and/or contractual requirements.

1.8.5.3Benefits


Element names are useful to help humans locate within the XML and good naming and consistency across versions helps implementers identify equivalent structures. It is helpful for the casual viewer to see ‘NHSNumber’, for instance, which maps easily to a real world concept (e.g. easier than when faced with an OID).

1.8.5.4Cost / Risk


Several significant costs are associated with this proposal. The most significant is that experienced V3 users will need to consult the model to make any sense of the instance – in fact, when it comes to instances, there will be no such thing as an experienced V3 user – everyone will need to use a model aware instance editor. It won’t be possible to implement generic message processors using this ITS unless they are MIF (or XUM) aware. There is no real guarantee that business names will prove to be any more useful on a global level than the more predictable and more abstract V3 names. (This needs to be investigated further.)

1.8.5.5Performance


No effect on performance (except for generic message processors).

1.8.5.6Usability


See under Benefits and Cost / Risk.

1.8.6Specifying which fixed and default values to send

1.8.6.1Proposal


For implementation purposes, allow committees or profiles to indicate which fixed and default values should be carried on the wire, and introduce new flags on the RBM to record this information

1.8.6.2Discussion


The advantage of this is that it gives HL7 the most control over the thorny issue of which fixed values should be carried on the wire (see Appendix D for further discussion). The disadvantage is, well, the same.
In many ways, which fixed and default values should be carried is an implementation issue, and committees will probably struggle to have a coherent frame of reference for deciding how to make this decision. An attractive alternative could be to allow implementers to define their own profiles to define which attributes are on the wire. If this is acceptable, HL7 could introduce the methodology and let committees or implementers decide whether to do it themselves.

1.8.6.3Benefits


This gives the most control over which fixed and default values should be in the instance.

1.8.6.4Cost / Risk


The tooling has to provide this new flag.

1.8.6.5Performance & Usability


Implementers get the most control over the flags they would like to see on the wire, which will serve both performance and usability (once the hard decisions have been made).

Yüklə 464 Kb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9   ...   13




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə