Answers from CAF Simplification project

Here are provisional answers to the 12 questions asked on the parent wiki page for simplification projects, as suggested by the UK CAF simplification project:

Q: What practical methods and tools exist today for fast-track implementation of V3 and CDA exchanges? What is their current status, scope, and experience with their use?

A: The tools being used in the UK give automated support for the steps needed to define a simplified V3 or CDA message. They are currentlyt being piloted on the CAF simplification project.

Q: How much can be achieved with these methods, in terms of reduced XML complexity, implementation effort, learning time, or any other metrics?

A: We cannot yet quantify the savings in implementations effort. There is a big saving in learning time for those who are not familiar with V3 or CDA, because simplified messages can be implemmented with vanilla XML tools and techniques. The simplified XML is about three times smaller and a lot easier to read; there is reason to believe that for closed domains, the simplified XML should be 'as good as it gets'.

Q: Are they to be regarded only as a fast route to implementing the full messages, or are there cases where the simplified XML forms can be exchanged over the wire? What are the benefits and drawbacks, and what would be needed to make it acceptable?

A:Primarily they are a simplified implementation technique. However, provided there are reliable transforms in both directions, there seems to be no harm in using the simplified XML over the wire. Suppliers do not have to support two different formats, as they can use the transforms to get to whicchever one they prefer.

Q: Is it necessary for a full round-trip (full=>simplified=> full) to be automatically and reliably supported by transforms?

A:It is highly desirable, so that all parties can be coinfident that full and simplified forms are completely equivalent, and can use which one they prefer.

Q: Is it useful to define simplified XML forms for closed sub-domains of CDA and V3 domains, or should the definitions have some of the semantic openness of full V3 and CDA? Can this be done consistent with full round-trips?

A:Closed sub-domains get you a long way. Having open-ended semantics opens up a lot of complexity for senders and receivers, and should be avoided where possible. But if you need it, simplified messages can be made open-ended by including any open-ended pieces in the V3 namespace, and not trying to simplify them. This will round-trip satisfactorily.

Q: How are the semantic relations between simplified XML and RIM-based semantic models to be defined and recorded?

A:These semantic relations are mappings, so it is sensible to use the heutral mapping notation, as supported by these tools. It is important to publish the mappings, because they are an unambiguous definition of the RIM-based semantics of the simplified messages. But it would also be useflu to publish a standalone deifnition of their semantics, for non-RIM experts.

Q: What is the process for developing a simplified V3 or CDA definition, the transforms between the simplified and full forms, and the semantic relations between them? What tools support the process? How automated and reliable is the process?

A:

Q: What are the processes for testing a simplified V3 or CDA form, both in its definition and in deployment?

A:

Q: What are the processes for maintaining the definitions of simplified forms through successive versions, as requirements change or as the underlying HL7 definitions evolve through versions?

A:

Q: Are there other artifacts, such as simplified domain models , which can usefully be developed in tandem with the simplified XML forms?

A:

Q: What should be the full ‘kit of parts’ in an implementation guide for a simplified form?

A:

Q: Can these ‘simplification methodologies’ be applied equally well to the other HL7 content models (messages and SOA content models)?

A: