View source for Answers from CAF Simplification project

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


<b>Q: </b>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? 

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


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

<b>A:</b> We cannot yet quantify the savings in implementation effort. There is a big saving in learning time for those who are not familiar with V3 or CDA, because simplified messages can be implemented 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'.


<b>Q: </b> 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?

<b>A:</b> 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 whichever one they prefer.


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

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


<b>Q: </b> 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?

<b>A:</b> 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 could be made open-ended by including any open-ended pieces in the V3 namespace, and not trying to simplify them. This would round-trip satisfactorily.


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

<b>A:</b> These semantic relations are mappings, so it is sensible to use the [[Neutral Mapping]] notation, as supported by the simplification 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 useful to publish a standalone definition of the simplified message semantics, for RIM non-experts. 


<b>Q: </b> 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?

<b>A:</b> The process is described in the [[Simplification in the UK|project wiki page]]. It involves marking up the full message tree to say which leaf nodes you need to retain, and giving business names for nodes. Then the tools do the rest automatically. This means that the schemas, mappings and transforms are reliable. It also means you can iterate the definition of a simplified message fairly rapidly - you don't have to go back and adjust the transforms by hand, as the tools will do it.


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

<b>A:</b> The simplification tools have facilities for testing the transforms and round-trips, with a fairly high level of automation. But is it up to any simplification project to find enough good test cases and test messages. Test coverage is hard in any project.


<b>Q: </b> 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?

<b>A:</b> We are into unknown territory here. But to make maintenance and evolution feasible, a high degree of automation in the tools is almost certainly necessary. When  maintaining software, we take the automation of compilers for granted. Re-creating transforms by hand for each new release would be infeasible and unreliable.


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

<b>A:</b> The simplified domain models have several other uses - such as validation by domain experts, who can understand them better than RIM-based models. You can also map systems and databases onto the simplified models, for reporting and data comparisons acroos several systems.


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

<b>A:</b> It should include at least schemas, example messages, transforms, and mappings. We will learn over time what else it needs.


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

<b>A:</b> The simplification tools are applicable to V3 messages. There is no reason why they should not be more widely applicable; but no doubt there will need to be tool extensions for particular use cases.