Table of Contents

Interoperability (IO) Specification Publication Model

The Interoperability Specification Publication Model describes the lifecycle of the interoperability specifications (e.g., PS-CA, CA:FeX). Specifications will be identified according to semantic versioning, using a three-part version number and release type tag (e.g., v0.1.0 DFT, v1.1.1 TI, etc.,).  The tag will identify the Specification Publication Type (i.e., maturity level) as either Draft (DFT), Trial Implementation (TI) or Final (Final).

The following table provides a summary view of the IO Specification Publication Model. There are three Specification Publication Types: Draft, Trial Implementation and Final, which represent the level of maturity for the specification. Within each Specification Publication Type, there are two attributes that further define the maturity level: Implementation Readiness and Prototyping / Validation Readiness. Definitions for each Specification Publication Type and Attribute can be found in the sections below. 

The IO Specification Publication Model may also be accessed in PDF format here.


Specification Publication Types

Publication AttributesDraftTrial ImplementationFinal
Implementation ReadinessIn DevelopmentLimited Roll-OutProduction
Prototyping / Validation ReadinessBeta Testing / Beta ProjectathonProjectathon / ConformanceConnectathon / Certification

IO Specification Publication Types

                      Draft                         

When this designation is assigned, the specification is currently in development and may be in the midst of an internal and/or public review periods (balloting cycles).  These specifications will generally benefit from lessons learned through development and pilots.

          Trial Implementation          

When this designation is assigned, the specification is considered to be a draft for trial use / trial implementation in production systems. It has been cycled through public open review and comment dispositioning has been completed. In some cases, features and capabilities or known issues may be documented in the backlog for inclusion in a future trial implementation release.

                        Final                        

When this designation is assigned, the specification is considered to have addressed all stakeholder comments received in reviews of prior releases. Projectathon testing has been successfully completed, with all known issues resolved. And, all documentation is complete, providing implementers the ability to use the specification for compliance and certification of their products.

IO Specification Attribute Definitions

       Implementation Readiness       
  • In Development: when this designation is assigned, the specification is in the development process and subject to significant change. It is not ready for limited roll-out or production level use.
  • Limited Roll-Out: when this designation is assigned, the specification is ready to be used for limited scale projects to meet a health care interoperability need.
  • Production: when this designation is assigned, the specification is ready to be used in production to meet a health care interoperability need.
Prototyping / Validation Readiness
  • Beta Testing / Beta Projectathon: when this designation is assigned the specification is subject to significant changes and has undergone feature complete testing by the Infoway IO team. The specification may be available to implementers to test their solutions at a testing event, such as a beta Projectathon, to provide input and help prepare the specification for Projectathon readiness.
  • Projectathon / Conformance: when this designation is assigned the specification is ready for testing and validation where implementers collaborate to test their solutions using methodology and tools that accelerate interoperability. A Projectathon provides an opportunity for participants to test their systems among themselves, against a reference environment and show conformance with the specification.
  • Connectathon / Certification: when this designation is assigned, the specification is ready for implementers to perform detailed validation and achieve certification of their solutions to the specification.

IO Specification Publication Versioning

The interoperability specifications will follow semantic versioning, using a three-part version number and release type tag (e.g., v0.1.0 DFT, v1.1.1 TI, v0.1.0 DFT-preBallot, etc.).

Major:

  • Increments every time a breaking change is made.
  • Indicated by increasing the Major number.

Minor:

  • Increments every time new non-breaking changes are made (i.e., changes that create new capabilities, but do not render existing implementations to be non-conformant.)
  • Indicated by increasing the Minor number.
  • Resets to 0 each time the Major version changes.

Patch:

  • Non-breaking changes (e.g., corrections).
  • Indicated by increasing the Patch number.
  • Resets to 0 each time the Minor version changes.

Release Tag:

  • Draft (DFT)
  • Trial Implementation (TI)
  • Final

Release tags may also include optional labels to indicate the intent of the release.  The following are the optional labels that may be used:

  • Ballot- indicates the release is for balloting purposes
  • preBallot - indicates an early look at what is going to be released for balloting in a future release



Balloting

Balloting is the formal process of sending a specification to a consensus body, collecting and addressing feedback and change requests prior to publication.

It is a methodology for taking a version of a specification, technical and  business content, and bringing it to a body of interested individuals (working group participants, SDOs, etc) with the purpose of gathering consensus and collecting feedback from that body and working through how that feedback will be addressed in a formulated way for the purposes of feeding what goes into a published release. 

The intent is to follow a consensus driven activity that utilizes and build on best practices used around the world.  The goal is to gauge and drive decision making best practices.

The balloting process has seven stages:

The balloting process is composed of seven stages:

  1. Preparation for Ballot
  2. Consensus Group Formation
  3. Circulation of Content
  4. Ballot Period
  5. Disposition Period
  6. Reconciliation Period
  7. Final Results

The diagram below, Balloting Process: Stages, provides a visual of the seven stages with additional details within each stage.

Learn More About Balloting 

An Introduction to Balloting Processes Community Education Session was held in November 2023 and was recorded. In this recorded session, you will learn more about the balloting process, its stages and how how various levels of balloting may impact the process.

The recorded session is available here. And the associated webinar deck is available below.

  • No labels