Simplified V3 and CDA Communication
Through Version 3 and CDA, HL7 has built a sound semantic base of RIM-based models for healthcare interoperability, which are in use worldwide. However, the technical complexity of RIM-based models and the XML derived from them has been a significant deterrent to implementers, leading to extra costs and limited takeup of the standards.
HL7 has undertaken a number of projects and investigations whose aim is to simplify the task for implementers of Version 3 and CDA, while retaining the sound semantic base. These methods typically define simpler XML structures for developers to interface to, and transforms between the simplified and full V3 forms. HL7 recognises the need to draw these different initiatives together, to learn the lessons from them, and to develop a consistent set of methods and tools to support simplified 'fast track'[ implementation of V3 and CDA.
The core questions which need to be answered to do this have been identified as follows: 1. 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? 2. How much can be achieved with these methods, in terms of reduced XML complexity, implementation effort, l earning time, or any other metrics? 3. 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? 4. Is it necessary for a full round-trip (full=>simplified=> full) to be automatically and reliably supported by transforms? 5. 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? 6. How are the semantic relations between simplified XML and RIM-based semantic models to be defined and recorded? 7. 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? 8. What are the processes for testing a simplified V3 or CDA form, both in its definition and in deployment? 9. 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? 10. Are there other artifacts, such as simplified domain models , which can usefully be developed in tandem with the simplified XML forms? 11. What should be the full ‘kit of parts’ in an implementation guide for a simplified form? 12. Can these ‘simplification methodologies’ be applied equally well to the other HL7 content models (messages and SOA content models)?
The investigations bearing on these questions are listed here, with links: Interface: Technology applied to the creation of or consumption of instances but not an alteration of the wire-form. Wire-form: Technology applied which alters the wire-form. Model Simplification: Technology applied to create a simpler model for both interfacing and wire formatting. • Message simplification implementations by Canada Infoway - Interface • The greenCDA project -Interface • The mu ITS project – TBD • Simple ITS (RW tooling) – Model Simplification • Simplification of NHS CDA documents being done in the UK - ??? • The RIM ITS – Model Simplification • The hData project – not a content model simplification, a packaging or content super-model specification. Other projects are invited to contribute, and add links to this page. Each contributor is asked, in the information they provide, to address the core questions listed above. In this way, HL7 can move towards a concensus set of answers, together with agreed requirements for simplification processes and tools; to a set of initial processes and tools that meet the requirements; and to definitions of simplified messages for important use cases. An important milestone in this process will be the Orlando WGM in May 2011, where ITS and SD working groups will jointly discuss the questions and the provisional answers reached by the projects. We intend to converge towards an agreed set of answers, requirements for simplification processes, and plans for future work.