FHIRcast logo

FHIRcast
3.0.0-ballot - ci-build International flag

FHIRcast, published by HL7 International / Infrastructure And Messaging. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhircast-docs/ and changes regularly. See the Directory of published versions

Event Maturity Model

The intent of the FHIRcast Event Maturity Model is to attain broad community engagement and consensus before an event is labeled as mature, and to ensure that the event is necessary, implementable, and worthwhile to the systems that would reasonably be expected to use it. Implementer feedback should drive the maturity of new events. Diverse participation in open developer forums and events, such as HL7 FHIR Connectathons, is necessary to achieve significant implementer feedback. The below criteria will be evaluated with these goals in mind.

Maturity Level Maturity title Requirements
0 Draft Event is correctly named and defined per the FHIRcast event template.
1 Submitted The above, and … Event definition is written up as a pull request using the Event template and community feedback is solicited from the community (e.g. the zulip FHIRcast stream](https://chat.fhir.org/#narrow/stream/179271-FHIRcast)).
2 Tested The above, and … The event has been tested and successfully supports interoperability among at least one Hub and two independent Subscribers using semi-realistic data and scenarios (e.g. at an HL7 FHIR Connectathon). The github pull request defining the event is approved and published.
3 Considered The above, and … At least 3 distinct organizations recorded ten distinct implementer comments (including a github or jira issue, tracker item, or comment on the event definition page), including at least two Hubs and three Subscribers. The event has been tested at minimum two HL7 FHIR Connectathons.
4 Documented The above, and … The HL7 workgroup agrees that the artifact is sufficiently stable to require implementer consultation for subsequent non-backward compatible changes. The event is implemented in the standard FHIRcast reference implementation and multiple prototype projects. The Event specification SHALL: (1) Identify a broad set of example contexts in which the event may be used with a minimum of three, but as many as 10. (2) Clearly differentiate the event from similar events or other standards to help an implementer determine if the event is correct for their scenario. (3) Explicitly document example scenarios when the event should not be used.
5 Mature The above, and … The event has been implemented in production in at least two Hubs and three independent Subscribers. An HL7 working group ballots the event and the event has passed an HL7 STU ballot.
6 Normative The above, and … the responsible HL7 working group and the sponsoring working group agree the material is ready to lock down and the event has passed an HL7 normative ballot

As each event progresses through a process of being defined, tested, implemented, used in production environments, and balloted, the event's formal maturity level increases. Each event has its own maturity level, which SHALL be defined in the event's definition and correspond to this Event Maturity Model.