Compatibility/Extensibility - Backward compatibility
- Definition: New transport format will be capable of being transformed to and from existing transport format
- Examples:
- Decompose defined data types to CHAR/NUM
- Truncate variable length fields to fixed length fields and SUPPQUAL
- Translate discrete relationships to RELREC where possible
- Note that this would not accommodate loss through UTF-8 -> US ASCII
- Compatibility with existing Health data standards
- Definition: It should be be compatible with existing standard healthcare formats
- Examples:
- Transform to and from ODM (including dataset-XML)
- Transform to and from HL7 C-CDA
- Transform to and from BIMO (?)
- Projected Lifespan of Standard Support
- Definition: The transport format should be supported by a non-commercial industry body with a mandate for a minimum length of time of full support for the transport format. This may depend on the age of the existing standard
- Example:
- Consider CDA vs FHIR, will both standards continue to exist in active development or will one supplant the other? Will the standard owner continue to maintain support and development?
- Extensibility
- Definition: It should be able to accommodate new content requirements easily, cost-effectively, and retain backwards compatibility (i.e. no or minimal need to modify data management tools or processes). This implies support for namespaces.
- Example:
- Addition of custom attributes peculiar to a system adopting the standard
- Systems naive to an extension will not be affected by use of extension
|
---|