Understanding the standards process

The standards process at HL7 (and in other standards development organizations) can seem complex, bureaucratic and unnecessarily time-consuming.  There are absolutely areas about the process that can and should be improved.  Areas that seem inefficient or that create unnecessary barriers to getting useful work done can and should be challenged.

However, newcomers to the standards space may come with misconceptions about what the standards process is and what it can/should accomplish.  This page is intended to help explain what it is that we do, why we have some of the processes we have, and how to maximize the benefits of using the HL7 process.

Get more information on how to participate at HL7: Participating in HL7

Why create a standard?

Some come into to the HL7 process believing that the overall objective is to get a needed “stamp of approval” after which the community can focus on the important thing – implementation.  This belief is understandable given that there have been times when HL7 thought that too.  I.e. that the priority was getting out some sort of document with the appropriate label.

It turns out that creating a specification and giving it a label isn’t terribly hard.  What really matters is what the label represents.  The label is only valuable insofar as it demonstrates that the specification reflects the qualities that the sponsors and consumers of the specification expect it to have.  A ‘standard’ is only valuable insofar as it is adopted, and that the adoption achieves the outcomes the standard was created to achieve.

To meet the objective of adoption and achieving desired outcomes, the standards process must do five things:

1. Foster consensus,
2. Ensure content is fit for purpose,
3. Ensure content is implementable,
4. Establish an appropriate implementer community, and
5. Ensure ongoing maintenance of the standard. 

Without all five aspects, the likelihood of broad uptake is significantly reduced.

HL7's capabilities and effort by sponsoring projects both have a role to play in achieving these objectives, though projects also need to be aware of innate limitations of the standards process.

Foster Consensus

The specification must meet the requirements of – and reflect the agreement of – the various parts of the community that will participate in the workflow the standard sets expectations for.  This means:

• Ensuring there is a clear boundary around what parts of the workflow are covered by the standard
• Identifying the stakeholders involved in the relevant parts of the workflow 
• Engaging those stakeholders to participate in the open standardization process (and keeping them engaged as the standard progresses)
• Ensuring the requirements of each stakeholder group are heard and recorded in a way that allows other participants to understand them consistently
• Prioritizing and harmonizing those requirements such that there is a single integrated set of requirements all stakeholders can agree with or at least accept
• Ensuring the resulting specification created to meet those requirements reflects a solution that the stakeholders also agree with or can accept

The standards development organization’s processes need to transparently support all these aspects and must do so throughout the standards development cycle.

The consensus process is key to ensuring outputs in two ways:

1. If participants do not have buy-in to the specification, they are unlikely to implement. Even if a regulatory or similar power dynamic exists, stakeholders who do not feel their needs/desires are reflected can often obstruct or delay implementation.  Alternatively, they can implement in a manner that meets the technical letter of the specification without producing the desired objectives.  On the other hand, if a specification has the support of stakeholders, implementation is more likely to happen, happen in a timely manner, and happen in a fashion that aligns with the intended objectives
2. To achieve the desired outcomes, the solution must ‘fit’ the implementation space. A solution that fails to consider the business processes, regulatory requirements, capacity or other limitations/requirements of one or more of the stakeholder groups often simply “won’t work”, regardless of how committed the parties might be to achieving implementation.  Broad perspectives and informed participants are essential to ensuring that all aspects of impacted processes and stakeholder groups are considered as part of the design process.

An added benefit of the consensus process is that additional value can often be identified as part of the design process that results in a specification achieving more benefits than had originally been envisioned and finding a wider audience than had originally been sought.

Larger communities provide more support for implementers and better ongoing support for the evolution of the standard.

While HL7’s committee processes technically function by majority vote, acceptance of a proposed direction suggests that consensus is missing.  Work groups will strive to find solution in which far more than a mere “50% + 1” is in favor of the outcome.  When formally balloting specifications, considerably higher percentages of favorable votes are required.

In HL7, when ensuring adequate representation of viewpoints, we try particularly hard to ensure adequate representation of those who will actually implement the specification – those who will write the code, or who will at least make the decision about whether code will be written.  Fundamentally, these stakeholders are the target audience for most specifications we produce.  As such, their agreement with and willingness to make the necessary software changes to realize the specification in their own products is critical to the specification’s success.Examples of how HL7 helps form consensus:

• Ensuring all relevant work groups have the opportunity to co-sponsor or be listed as interested parties in the [Project Scope Statement]
• Announcing proposed projects to the ANSI and international communities and, in some cases, to other standards development organizations to encourage interested parties to participate
• Ensuring all meetings discussing the proposed specification and connectathons testing it are openly advertised and open to all interested participants
• Actively soliciting balanced representation from different stakeholder groups when conducting ballot review
• Providing opportunities for open feedback on specifications throughout their life-cycle
• Conducting “straw polls” to test for consensus and to see whether further discussion/implementer experimentation is needed before calling for formal votes
• When voting on normative specifications, ensuring that all voters must consider unresolved negative comments and consider whether they wish to change their vote

Ensure fitness for purpose

The solution that is reflected in the specification must function as intended.  That means:

• It must be able to work with the inputs stakeholders are able to provide
• It must be able to produce outputs stakeholders are able to consume
• It must result in the objectives the standard is intended to achieve
• It must do the above in the varying circumstances that affect the day-to-day operation of the relevant healthcare systems
• It must manage failure/exceptions in a manner that is safe for affected stakeholders

Fitness for purpose can be seen as a Boolean – some solutions will meet the desired outcomes, others will not.  However, in practice, it is a range.  Solutions might meet the desired outcomes with greater or lesser frequency, in narrower or larger circumstances and for greater or lesser costs.  Perception of fitness may vary by stakeholder group.  Fitness is therefore typically a weighted measure of suitability across numerous objectives.  The standards process attempts to first identify candidate solutions and then evaluate them.

The breadth of solutions evaluated is driven by the creativity of those doing the design, the breadth and accuracy of their perspectives and the time they have available to come up with and evaluate alternatives.

Fitness can include considerations such as:

• Will the specification introduce safety risks?
• Will it create issues with admissions, billing or other critical business processes?
• Does it require capturing data elements that are sometimes unavailable?

The fitness of the solutions is evaluated by two primary mechanisms:

1. Vetting of the specification by a sufficiently diverse and competent set of stakeholders against the potential range of inputs and outputs as well as evaluating the clarity, rigor and precision of the specification.
2. Testing of the specification in both test and real-world environments to verify operation in complex situations that cannot necessarily be predicted or intuited merely by evaluation.

Be implementable

It’s possible for a solution that technically meets the community’s objectives to not actually be implementable by one or more of the stakeholder groups involved.  To be implementable, a specification must achieve the following:

• It must fall within the regulatory, technical and capacity constraints of the software developers, vendors and implementation environments that must implement some or all of the specification.
• It must define the solution with enough precision, rigor and clarity/understandability that stakeholders can independently consistently implement the specification – and thus achieve the desired outcomes.
• It must ensure that the return on investment for the resources (money, time, expertise) expended to implement the specification is large enough for each stakeholder (particularly when compared to the benefits for that stakeholder) that it makes business sense for all stakeholders to implement (and implement sooner rather than later)

Implementability includes considerations such as complying with underlying standards, working within the capabilities of existing database technologies and development languages, ensuring definitions are expressed in terms understandable to non-experts, etc.

Like “fitness for use”, implementability exists on a continuum and can involve trade-offs among stakeholder groups.  These trade-offs occur as part of the consensus process.

Ensuring implementability is managed by the same two mechanisms as “fitness for use” – providing a combination of adequate review and testing opportunity.

Establishing an implementer community

Except in the case of regulation, the notion of “build it and they will come” is seldom successful in the standards space.  Many specifications have been developed by consensus processes within HL7 and other standards organizations that were both implementable and “fit for purpose”, yet saw little or no adoption.

Adoption requires awareness and appetite in the community of target implementers.  Creating this awareness involves outreach, connection, education, advocacy and engagement with the stakeholders who will (ideally) implement and/or be impacted by the specification.  This includes recruiting a subset of the stakeholders into the standards development process (to ensure a representative consensus).  However, it also involves getting the standard “on the radar” of those who might not want to engage in development, but who should be planning and budgeting for eventual adoption.

In addition to ensuring the ground for the new standard is fertile, building a community is essential to providing support for implementer activities.  Any specification produced can’t ever hope to cover every nuance and edge-case that will be encountered in the implementation space.  Having a connected community of implementers who can communicate about and come to consensus around how to manage such issues is essential to ensure consistent implementation and adaptation of the specification to real-world environments.

These implementation communities also provide an on-ramp to those new to the specification, create tooling and other materials that ease implementation, provide consultation and education to other implementers and help the understanding of the specification scale from the initial smaller subset of stakeholders involved in the development process to the much larger set of stakeholders who need to adopt it in order to achieve the desired outcomes.

In some cases, the implementer community already exists (having been formed through other standards, advocacy or other activity).  In these cases, the objective is to integrate the standards development community into the existing implementation community so that knowledge can flow both ways and feedback can be looped into the standards development process.  In other cases, the community must be formed or grown to achieve desired implementation breadth and depth – and to achieve the objectives of the specification.

Whether forming, growing or integrating the community, the mechanisms are the same: engagement through outreach, advocacy, connection, and education.

The formation of the implementation community starts with the same processes as those used in forming the consensus group, but it adds on numerous other aspects:

• providing education and webinars, articles in newsletters
• sponsoring connectathons at working group meetings, DevDays and various other forums
• hosting list serves, Zulip streams and engaging with implementers by other means such as Stack Overflow

Ongoing maintenance

To be successful, a standard must be ‘living’.  It must be updated as issues arise, clarifications are required, requirements evolve and the technical environment changes.  This requires a few things:

• A significant representation of the community that originally developed the standard must remain in some form, even after the initial project is complete (and its associated resources are expended)
• As much as possible, the knowledge of the community must be retained as community members come and go
• The specification itself should have been designed to allow for future evolution, such as expanding use to new provider or geographic communities, providing mechanisms for enhancing or adjusting behavior in future versions, and establishing practices for implementations to manage the likely situation where multiple ‘versions’ of the specification being in use simultaneously.

All the considerations involved in the original specification – formation of consensus, verifying fitness for purpose and implementability, and fostering/retaining a community are relevant in the maintenance process.  So long as a specification is relevant, there will be a continuous iterative process of revision and adoption, though the intensity of that process will wax and wane depending on the stability of the implementation space.

HL7 ensures that all content is managed through source control and is moving to a Jira-based tracker mechanism for all specifications that have moved past a ‘draft’ state.  Confluence documentation, including meeting minutes and decision points also help to retain institutional knowledge.  Most importantly, HL7 strives to continue to produce new, relevant and interesting content.  This provides reasons for participants to remain engaged and therefore remain available to support in the maintenance of previously published specifications.

Additional considerations

There is a trade-off between the time and energy expended and the degree to which these ‘benefits’ of the standards process can be achieved.  Spend too little time and energy and the standard is unlikely to be fit for purpose or see much adoption.  Take too long or require too much investment and the community will move on before the specification is declared “fit for use”.

Within the HL7 standards process, it will typically take 1-2 years from the beginning of the process to when a specification is available as a “Standard for Trial Use” and another 3+ years after that before the content has been sufficiently exercised that it can be locked down as “normative” (i.e., a relatively stable ANSI standard which strives to maintain backward compatibility as new versions are created).   The latter timeframe is primarily driven by the speed with which the implementer community can adopt a version of a specification in production and provide feedback into the standards process and then move to the resulting revised version.

What HL7 brings to the standards process

HL7 has been developing healthcare standards for over 30 years.  It has learned (and continues to learn) many things about how to perform all the functions above.

• It has processes in place to help form communities, perform review, encourage testing and perform a balanced, objective review of specifications
• It has a large community who, together, have extremely deep expertise in pretty much every area of healthcare and the technologies relevant to data sharing
• More importantly, it has a community who are passionate and enthusiastic about using technology to improve the flow of information in healthcare, and in so doing improve the lives of people worldwide.

Specific capabilities include:

• Processes at the outset of projects to ensure that scope is well defined, awareness of intended work propagates both across our organization and to the external community, that relevant expertise within the organization is leveraged and that coordination exists to minimize the likelihood of overlapping or conflicting specifications being produced
• Processes to help ensure balanced representation and transparency to specification development, review and change
• Technical infrastructure to support community formation, communication and knowledge retention/sharing (Confluence, Github, Zulip, conference calls, working group meetings, etc.)
• Formal methodologies (and processes for maintaining those methodologies) to guide the creation of consistent, good quality specifications based on our core standards
• Regular connectathons, shared registries and testing environments to support ongoing validation of specifications as they’re developed
• Mechanisms to solicit review from a wide pool of knowledgeable experts and processes to coordinate responses to (and adaptation of specifications resulting from) provided feedback
• Infrastructure to support the development, publication, distribution and ongoing version management of specifications
• Management processes to coordinate the work of our numerous committees and facilitate community processes such as balloting and publication
• Governance processes to ensure that all stakeholders have an opportunity to be heard and that specifications are developed in a collaborative and consensus manner.
• Regional affiliates in numerous countries, partnerships with other standards-related organizations, governments and key stakeholders and marketing reach to create awareness of specifications produced

What projects are expected to bring to the process

While HL7 has deep expertise in many areas and has broad reach in terms of its community, it is composed almost exclusively of volunteers.  Some are true volunteers and support standards development in their spare time.  Others have support from their employers or clients.  In both cases, their bandwidth is finite.

Projects looking to enable healthcare change through the development of standards are expected to bring resources that can assist with the work.  This might mean bringing paid or volunteer individuals who will assist with developing content, coordinating review, managing or participating in connectathons, etc.  In other cases, it may involve providing funding to those already in the community to allow them to devote more attention to the work needed by the project.

In either case, projects must recognize that they are becoming part of a community.  The community will be expending its time and energy in helping the project progress its work.  However, the community is made up of others who are also seeking to advance their own standards initiatives.  Project proponents will need to be respectful of HL7's need to support multiple projects, share communal resources (committee time, reviewers, etc.) and will also expect to contribute to helping progress other standards work not directly related to their own project’s objectives.

Projects will need to help recruit expertise from their respective communities to come engage with HL7.  While we have deep expertise, we are unlikely to have representatives of all stakeholder groups that will be impacted by the proposed specification (and the representatives we do have won’t always have the bandwidth to provide the needed support). It is also hoped that project participants will encourage their organizations to join as HL7 members to help support the HL7 organization and infrastructure.

HL7 has processes to help ensure that specifications achieve their objectives of adoption and desired outcomes.  While the needs of projects will vary, relative consistency of processes and governance is essential to ensure smooth functioning of the community.  While exceptions can be granted to HL7's expectations in some cases, such exceptions will necessarily be rare and will be evaluated based on the overall objective of the process or rule being waived or adjusted.  In the end, HL7’s credibility and brand will be affected by the quality of what is produced, and it reserves the right to ensure that processes are followed that will help ensure that quality, even if it means compromise or a longer process than might be desired.

Projects are encouraged to contribute to communal resources through support for tooling, education, open source work, etc. that will benefit not only their own work, but the entire standards community.

As mentioned above, an essential component of the standards process is ongoing maintenance.  While projects may have time-limited funding and resources, they should make plans for how the initial specification will be maintained once the project ends.  Ideally this should include individuals who volunteer with the community long after the project ends as well as ongoing organizational support of HL7.  At minimum, it must include ensuring that work products are well documented and include all source material, records of decision-making and rationale, and that there is knowledge transfer between project participants and HL7 community members who will provide support upon project completion.

All project participants are expected to act ethically and in accordance with HL7’s rules and guidelines.  This includes revealing potential conflicts of interest, helping avoid actual or perceived preponderance of influence, following rules regarding the use of intellectual property, and generally not trying to put their own personal interests above the good of the community.

The limitations of the standards process

Much as we might wish otherwise, standards aren’t magic.

1. Both the standards community and the implementer community have finite bandwidth. HL7 will do its best to be fair to all projects, but prioritization will occur where resources are limited. Notwithstanding the importance of a given project’s objectives, pending (or active) regulation, project funding timelines or other considerations, it won’t always be possible to meet desired timelines and/or get desired levels of engagement.  And the HL7 process necessarily must include specific milestones and expectations that all projects must meet to ensure fairness and consistency.
2. While communal resources (work group time, opportunity to ballot, etc.) will seek to be fairly allocated across work products, volunteers and funded members will typically only go “above and beyond” in developing and reviewing content that reflects their own interests. This is true even if a project might have ‘acceleration’ arrangements with the HL7 organization.
3. The hard (and time-consuming) work of the standards process is not the creation of the technical artifacts, but rather the task of working with people – getting engagement, establishing shared understanding, fostering collaboration and achieving compromise. It is sometimes possible to speed up technical work by adding extra resources.  However, there are significant limitations to how much additional resources can speed up the even more essential ‘social’ processes of implementation
4. There are no guarantees. In an open, consensus-based process, HL7 can’t provide any guarantees as to:
   1. Outcomes – specifications (and even scope) may change from what was envisioned at the outset of a project
   2. Stability – the ‘final’ version of a standard may have very little in common with the initial release. Changes will occur based on the review and testing process.  Sometimes those changes may be radical.  Stability only comes once enough experience and community consensus allow the specification to be locked down (which will take several years at minimum and sometimes considerably longer).
   3. Timing – HL7 and its work groups will have multiple demands on their time. As well, the length of time needed to achieve consensus is hard to predict.  Experienced HL7 members may be able to provide estimates as to how long the process will take, but projects should provide ample safety margins to allow for unexpected inputs or issues.
   4. Adoption – The standards process can’t, by itself, create demand. It can enable progress in meeting existing demands and (sometimes) it can lower barriers to a point where previous invisible demand activates.  Even if community formation is successful, external circumstances can cause implementation to be delayed or fail to occur at all.
5. Standards are often a small piece of the puzzle. Significant change management is often needed to shift market incentives, business practices, professional cultures, individual habits and sometimes even regulations in the ways necessary to realize the benefits a specification was developed to achieve.  Consider what’s achievable in the change management space (and the strategy to make it happen) before investing too much in a specification whose success depends on significant change.
6. Some of the power of standards comes from how they work together, and a big picture view of interoperability is a fundamental premise of the HL7 standards process. Whenever possible consider how outcomes and objectives could be achieved by building on existing work or piggy backing on other projects rather than building something entirely from scratch.  Not only is there savings on content development and review, it can be possible to leverage much of the existing community.
7. Consider whether better outcomes could be achieved with small, incremental steps than with a single giant leap. (Giant leaps sometimes work, but it’s more work and takes good timing.)

The HL7 community is a special one.  It is full of very smart, very dedicated individuals who care passionately about this space.  Many have adjusted their careers solely to be able to remain part of this community.  We are pleased that you’ve decided to join us and look forward to helping you achieve your own ideas about how to make healthcare better.