This wiki has undergone a migration to Confluence found Here
2015 03 27 Minutes - CDA R2.1 Project
Jump to navigation
Jump to search
Attendance
Attendance
- Austin Kreisler
- Benjamin Flessner
- Calvin Beebe
- Kathleen Connor
- Vinayak - Cerner (VK)
- Rob Hausam
- Andy Stechishin
- KC
Minutes / Notes
- Current Agenda
- Review DPROV CDA R2.1 Wish List / Participation Functions and Role codes
- not on Entity
- ok on role
- role confidentially code % Confidentially code on clinical statement - review 2.07
- Needs some modeling assessment.
- -
- Backwards compatility change in RIM
Paragraphs
What we mean by backwards and forwards compatibility
Instances of documents old and new
Receiver old and new - expected to process - another backwards compatibility question
- add attributes / Amend the RIM definition - participation functions is not fluff , it is really important. - Maybe an IG assertions
- Need to add to entry and section where ever there is a device for Identifiers.
Backwards Compatibility and Substantivity
It is important to distinguish between the distinct but related concepts of interversion compatibility and substantivity.Substantivity is significant because of its role in the balloting process. Our rules for substantivity are based on the need to ensure that changes that are made to the standard are appropriately subjected to ballot review. For this reason, both additions and deletions from the standard are treated as substantive. As a general matter, any change which changes semantics is substantive. Interversion compatibility, on the other hand, is significant because as a way to recognize the significant cost of upgrading an installed interface from one version of the standard to a subsequent version. The rules governing interversion compatibility are centered around two notions: a) Old receivers receiving new messages should be able to continue receiving messages without error, b) New receivers should be able to understand old messages. In order to reduce this cost, HL7 V3 has introduced rules to limit the introduction of changes causing interversion compatibility problems. Those rules, which do not prevent the introduction of new features to the standard, specify that, before a feature can be removed, it must be listed as deprecated within an intervening Normative Edition of Version 3. As a practical matter, all changes that violate interversion compatibility rules are substantive. However, the converse is not true. Many changes which do not violate interversion compatibility may, nevertheless, be substantive.
- Discuss the communication plan for RIM 2.07a Project
- Open Topics
- Review DPROV CDA R2.1 Wish List / Participation Functions and Role codes