FHIR Governance

FHIR (formerly RFH) Governance/process considerations

This document proposes a set of candidate governance processes and rules for RFH constructs. The intention is to start the conversation around how governance and QA management could be done for RFH. None of these rules or governance processes has been approved in any way. Comments & edits are welcome.

Changing Resource Wire Formats

Because requirements will evolve, changes to a resource wire format are unavoidable. To minimize rework by implementers, certain principles need to be followed:

Principles

1. Wire formats should only be changed if there’s a need to convey new data elements.
2. When changes are required, x-paths to elements in the prior version must be retained. If not, the resource name must be changed with the old resource being deprecated.

Processes and Guidelines

1. QA should be undertaken for all wire formats to ensure that tag names are spelled correctly (ideally by automated process that “splits” lower-camel-case names and validates the terms against a spell checker).
2. Repeating Elements
   1. Need to decide if repeating elements should be nested under a grouper (e.g. <employers><employer/></employers>). Preference for not as it makes retention of wire format easier.
   2. If groupers are used, then they should be introduced anywhere repetition might reasonably be possible. If a non-repeating element is made repeating, the original name should be retained and a repeating group should be used for “additional” repetitions.
   3. If groupers are not used and a non-repeating element is made repeating, then the collection should ideally be defined as a list sorted in such a way that the first repetition will have the same semantics as the original
3. Names should:
   1. align with common domain terminology
   2. be short but descriptive
   3. in US English
   4. avoid abbreviations
   5. follow style guidelines in terms of “start with a noun” or “start with a verb” [need to determine these rules]
   6. follow rules for suffixes based on datatype (e.g. “Code” for codes, “Ind” for Boolean)
   7. be unique in context
   8. be consistent with names of equivalent concepts in other resources where clinical/domain familiarity will not be adversely affected
4. Nesting of structures should be minimized to reduce issues with changing hierarchies
5. Ordering of different elements should not be significant. I.e. We shouldn’t encounter a situation where someone might say “A should come before B” and have rules they could point to that would necessitate such a re-ordering.
6. Resources should not be nested. Instead references should point to sibling resources. (This minimizes the impact of changes of resources to those resources that reference them.)
7. If an existing element must be “moved” into a new more complex structure to allow conveying of new data elements in an intelligent manner, there are two possibilities:
   1. Retain the existing data structure and add the new data structure and expect both to be populated with redundant data
   2. Capture the new data elements in an “extension” tied to the previously existing data element(s)
   3. Create a new version of the resource (adding a version number to the existing resource name.
8. Features added to a resource definition that affect the semantic interpretation of elements in previous versions of the specification will be handled in one of two ways:
   1. Require the newly added element with a “must support” indicator on the wire. Applications that cannot process a “must support” element must reject or fail the processing of instances containing such an element.
      1. [Need to decide if this is further qualified, possibly with a pointer to the existing data element(s) whose meaning is modified. The idea being that if you don’t support the elements whose meaning is modified, it doesn’t much matter that you also don’t support the modifying element.]
      2. [This could theoretically happen for extension elements too]
   2. Create a new version of the resource (adding a version number to the existing resource name.
9. The decision to create a new version of the resource rather than following one of the alternative approaches will only be made where the complexity of maintaining full wire format compatibility with the prior version is felt to outweigh the complexity of migrating to a new wire format version.
10. If a previous resource wire format is deprecated and a new one is created, transforms shall be published as part of the new resource version to allow transformation between the old and new version.
    1. Compliant systems should be designed to support use of such transforms at runtime should they eventually be needed for supported resources.
    2. The definition for the deprecated resource shall be updated to contain a reference to the definition of the new resource.

Changing Resource Semantic Ontologies

Just as resource wire formats can evolve, resource ontologies will also evolve. Due to the need of the ontology to support most resource extensions and the constraints associated with aligning with one or more underlying reference models, changes will tend to be more frequent and more “severe” in terms of altering existing navigation paths. While the percentage of implementers that will rely on the ontology layer is not high (likely in the 10-25% range), those who do rely on this layer will still need a means to manage these changes and operate across different versions.

Principles

1. Elements constructed against older versions of a resource ontology must be automatically expressible using new versions of the resource ontology and vice versa. This includes spanning “versions” of the underlying resource.

Processes and Guidelines

1. Ontologies will be verified for logical consistency as part of the QA process
2. When refactoring of an ontology is required, the new structure will be created in parallel with the old structure and equivalencies asserted between new and old elements where equivalencies exist.
3. When a new version of a resource is created, equivalency assertions will be made from the “complex” representations in the old ontology to equivalent structures in the new ontology.

Ontology requirements

Each data element within the ontology will include the following definitional elements:

• Descriptive label (English, ideally unique, user intuitive, domain agnostic)
• Code
• Synonym codes (includes GUIDs from local extensions as well as superseded codes, should that ever be necessary)
• Synonym labels (Other names, potentially including non-English translations)
• Definition (English, following good practices, including examples) Need to support translations to other languages at some point.
• Additional notes (todo, comments, usage notes)
• Value Domain
• Owning concept (for nested structures)
• RIM path and constraints (identifies the path from the owning concept to this element with additional constraints as needed)
• Terminology mappings (SNOMED, LOINC, etc.)

Defining Resources

One of the key challenges with RFH is the governance process for managing resource creation and maintenance. This section proposes processes and guidelines for doing this.

Who can define resources

Technically anyone can create resources, however only HL7 International and (in limited circumstances agreed by HL7 International), HL7 affiliates and other approved SDOs can create resources that can be referenced in HL7 Specifications. At the HL7 International level, the decision around the creation of new resources is managed via project request to the TSC through the sponsor committee’s steering division with review by MnM.

Affiliates wishing to create resource definitions are encouraged to first propose the resource at the HL7 International level and only proceed with local definition where there is either no interest or insufficient bandwidth to construct the resource. The potential for eventually migrating affiliate resource definitions to the international level should be kept in mind.

In addition, some resource definitions could potentially be created by other SDOs. The management of such relationships and the assignment of official HL7 status to resource definitions maintained by other SDOs and vice versa will need to be coordinated through inter-organizational agreements. In addition, the maintenance of HL7-authored resource definitions may be assisted through contributions from other SDOs both on a formal and informal basis.

In cases where resources intended for use in official HL7 standards are created by groups other than HL7 International, coordination is required to ensure resource names are constructed in a way that avoids name collisions.

When are new resources defined?

Within HL7, acceptance of a proposed resource will be based on a number of criteria, including the following:

Does the resource represent a well understood and “important” concept in the business of healthcare?

Resources should be the key things that healthcare information communications deal with. They should be labeled with terms that will be easily recognized by domain experts and should ideally be consistent in nature across national and care boundaries. (Note that care should be taken in naming resources to ensure that the resource will be easily recognized by the business community and unlikely to be confused for other meanings of the same label. E.g. is “Application” a software system or an enrollment request?)

Is there a requirement for standardization of the content represented by the resource?

Creation of a resource entails a significant development and maintenance effort on the HL7 organization. This effort should only be taken in circumstances where there is expected to be sufficient uptake of specifications using the resource to justify that effort.

Does the proposed resource overlap with content of existing resources?

Overlap can occur in several ways:

• Concepts can exist at different levels of generalization (e.g. Outbreak/Public Health Case/Observation/Act; Person/LivingSubject/Entity)
• Concepts can represent different business perspectives/restrictions of a general area (e.g. chemistry, pathology, microbiology and genetic views of lab results)
• Concepts can be shared at different levels of detail (e.g. medication summary vs. full medication detail)
• Concepts can reference other concepts (e.g. Patient referencing the provider or organization they’re a patient of)

As a general rule, overlap is not permitted. If a given piece of information would be expected to be communicated in one resource, it should not be present in another. The only exception is with references. With references, content from one resource may be included as part of another resource when:

1. There is a use-case for the data to be stored directly as part of the base resource without separate maintenance or commonality that being a separate resource provides
2. The ontology links for the data elements actually point to the ontology of the other resource
3. Where the potential exists for some implementations to wish to link to the other resource, a choice structure is provided giving the alternative of in-line description and resource reference.

Is the proposed resource appropriately sized?

Resources are intended to be created for healthcare concepts that have a descent “heft” to them. At the same time, resources should not be gigantic constructs that include everything and the kitchen sink too. For example, a resource for “names” would be considered too fine-grained. On the other hand, a resource intended to contain the full structure of a clinical trial without references to other resources would be much too large. From a numbers perspective a range of 20 data elements to around 100 data elements is probably about right. However, this is a guideline that is flexible based on other criteria.

Is it reasonable to expect the objects represented by the resource to be maintained with distinct, reliable, unique identifiers?

To be manipulated or referenced, resources must be identified. While the identifiers used to link and manipulate resources will be internal “technical” identifiers not intended for human display or data-entry. However, almost all resources will also have corresponding “business” identifiers intended for human use and exposure. If a concept doesn’t naturally have a concept of having an identifier, it may not be a good candidate for being a distinct resource.

Is the proposed resource one that makes sense to perform CRUD operations on as a single unit?

Resource objects are expected to be manipulated independently. It should make sense to create, query, update and delete them on their own, independent of other resources. Many of them will tend to have their own independent state machines. Concepts with tight coupling to other resources might not be candidates to be resources themselves.

Is the content of the resource coherent?

Definitions of resources referencing to or containing data from numerous different domains are susceptible to change and unneccessarily require knowledge of all domains referenced. They will be hard to document and implement. Like in any good design, we must strive for high cohesion and low coupling.

Others?

???

How do we minimize the need for distinct resource definitions?

To ensure the RFH process is manageable, there’s a need to control the number of resources created. This means ensuring that resource definitions are created in a manner that is reusable, scalable and extensible. Resource construction guidelines that affect reusability, scalability and extensibility include:

1. Ensure that the base conformance profile only enforce requirements that would reasonably be expected of the simplest of systems.
2. Include additional features that would reasonably be expected of most systems. (If 25% or more of systems that support the resource are reasonably expected to support the element, it should be part of the resource definition.)
3. Do not include (in the wire format) features that would be used by a very small percentage of systems or only used in limited environments (e.g. only one country, only clients of a single government agency)
4. However, ensure that “rare” requirements have an adequate representation in the ontology so they can be easily represented as extensions.
5. Resources should be constructed, named and populated an international and domain-agnostic manner. I.e. Requirements of all participating countries should be considered and requirements that are shared by multiple countries should be represented in a generic manner.
6. Resource names and property names should include a synonym list that makes is easy to discover domain-specific and country-specific terms.

How are resources vetted and approved?

Resources will generally be assigned to a single Work Group. Discussion on the content, names, mappings, etc. will be made by that workgroup. Changes to resources will be approved as a single release subject to normative ballot and published as part of a normative edition on an annual basis.

Defining Extensions

A key premise of RFH is that it tries to do simple things simply. This means that the core structure can’t handle every potential use-case or esoteric requirement as part of a resource’s wire format. For requirements not handled by the wire format, the extension mechanism is used. Extensions should be used in the following circumstances:

• Data elements that are likely to be used in fewer than 20% of implementations of a given resource
• Data elements that are specific to a particular country or narrow domain
• Data elements for which there is a near-term urgent requirement, such that waiting for approval of a change to the resource definition is too long

Conformant extensions can be handled in one of two ways: Official extensions and Local extensions:

Official extensions Official extensions are extensions that have been vetted by HL7 International and which are officially registered in the HL7 ontology. This is the target state for all extensions. However, due to the vetting process that occurs, some implementations will need to make use of Local extensions until an official extension is available and migration can occur.

Local Extensions Local Extensions use a GUID rather than an HL7-issued code to identify the extension. The other requirements for metadata are still expected to be followed (full RIM mapping, rigorous definition, business friendly name), however due to the lack of central registration and vetting, this information will not be known by all potential recipients. Therefore, all local extensions are expected to be submitted through the registration process. Upon successful registration, the original GUID(s) will be noted as alternate codes for the Official extension.

How is a new extension defined, registered and approved?

An extension must include all of the information needed by the ontology (see above). Requests are submitted via a web interface. A fee may be charged to help cover review costs. Extensions will be reviewed for duplication, accuracy and completeness of RIM and other terminology mappings and, once the definition is agreed between HL7 and the submitter, a code will be issued allowing the concept to be expressed as an official extension.

What’s the process for migrating extensions to the wire format for a resource?

At some point, the frequency of use of a given extension may suggest that inclusion as an official part of the resource definition (with direct presence in the wire format) is appropriate. This might be initiated by the responsible committee themselves, or through the request of a proponent HL7 member. If the committee agrees, the existing concept is associated with a structure in the resource wire format and proposed as part of a revised ballot. [We need to decide whether the extension still needs to be sent too or whether the extension code should be included as part of the regular wire format or neither.]

Defining Profiles/Templates

TODO

FHIR Governance Board

Appointed by TSC in July 2012, consists of

• George (Woody) Beeler
• Grahame Grieve
• Ewout Kramer
• Ron Parker
• John Quinn