Mapping Notation Requirements

These requirements are not prioritised. A notation for mappings to be adopted by HL7 should:

1. Be Linked to a Semantic Model: Because HL7’s concern is semantic interoperability, the mapping notation should link to a semantic information model, such as a RIM-based model. So the notation should be S2M or M2M, but not S2S.

2. Have Well-Defined Meaning: What the mapping notation can say about the relation between two formalisms, and how it says it, should be well-defined and documented.

3. Be Semantically Expressive: The notation must be able to express how the meaning in one model or structure is commonly represented in the other. Sub-requirements include:

a. Can map XML, formatted text, relational databases or UML models

b. Can express how associations are mapped (for all cardinalities; 1:1, 1:N, or N:M)

c. Can state where attribute value conversions are needed (e.g. different code sets)

d. Can handle mappings of lists of items

e. Can note where mapping is not possible, and why

4. Be Easy to Understand and Review: It should be possible to read the mapping notation, with or without tools, and readily understand what it says about the relation between two formalisms. Sub-requirements include:

a. Modularity: It should be possible to divide a large mapping set into smaller ‘modules’ of mappings, with clear definition of the links between modules and allowing reuse of modules

b. Cross-Mapping: when several data structures are mapped onto one semantic model, it should be easy to view the parts of each data structure mapped to the same semantic model item

5. Be Easy to Write: It should be possible to create mappings in the formalism easily – with or without tools.

6. Have Static Validation Criteria: There should be clear criteria for a valid set of mappings in the notation, suitable for checking by eye or by machine.

7. Be Declarative rather than Procedural: Because declarative languages are easier to write, understand and analyse, a declarative mapping language is preferred (especially if transformations can be generated from it automatically – see below). The notation should allow for a ‘procedural escape’ for cases where mappings are hard to express declaratively.

8. Be Executable: It should be possible to use the mappings without further coding to convert data instances from one model or structure to another, so as to:

a. translate data instances in live applications;

b. test that mappings are correct;

c. review mappings by reviewing translations made from them;

d. support iterative development of mappings.

9. Have Editing Support: A mapping editor can make it easier to develop mappings, and to view them (e.g. with automatic capture of the structures and models to be mapped)

10. Have Automated Validation: This can go a long way towards defining and checking quality measures for the mappings.

11. Be open and neutral, not proprietary: It will probably be feasible for any supplier to convert mappings from a neutral notation to their own proprietary notation – but may not be possible the other way round

Requirements 8-10 depend on tools. HL7 is choosing a notation based on the merits of that notation, rather than choosing a tool. The existence of tools can help to verify the suitability of a notation, and can influence its usage in the short term. In the longer term, adopting a notation will create a market for tools to support it.