Realm Transferable Standards Specifications
Project Scope Statement Link
2019-02-20 Characteristics of Realm Transferable Standards Specifications
Project Scope Statement HL7 PSS-1329

Note from the editor:

This is a work-in-progress. I have begun the first draft of this document by framing the introduction and purpose. My challenge is that, while I appreciate the need for this work within HL7 and by implementers of its standards, others are more well-equipped to provide the specific content. For this, I rely on the generous contribution of persons who care that this document be reasonably thorough and practically useful. Simple enough to be effective, but no simpler.

The initial draft of this document is going out to a targeted list of people to validate the approach and Table of Contents. Once that is done, it will be made more broadly available to the working groups generally for their contribution.  I encourage potential contributors to provide whatever perspective their experience provides. You can provide very specific content, or simply indicate what you think the structure of the document should be or what it should contain.  I rely upon reviewers, wherever possible, to provide examples of both what NOT to do, and then what is recommended to do.

Please comment inline to allow a shared response to the content.

1.0 Introduction and Purpose of the Document

The purpose of this document, "Characteristics of Realm Transferable Standards Specifications" (working title) is to provide guidance, recommendations, and a set of principles to the HL7 standards development community on what the distinguishing characteristics are for a standards specification to be transferable, and readily implementable, across countries.

Section 2: Rationale provides insight into the need for this document. This guidance is intended to be applicable generally to all current and future international standards work done in HL7. The intent is not to create a difficult process, or barriers to standards development, but rather to make it easier for work to be more inherently applicable and transferable internationally, by providing guidance for standards developers to consider that will increase the transferability of their work to other health care contexts.

Document Approach
This document focuses on the identifying and formalizing the characteristics of standards specifications that make them adoptable (without variation) or adaptable (readily localizable) internationally. 
It includes considerations and recommendations that span the life cycle of standards creation within HL7 including:

• project initiation
• requirements definition and modeling
• creation of standards specification artifacts
• specification of semantic content: internal and external terminologies
• profiling specifications
• creation of implementation guides
• standards balloting and publication

This will include other complementary mechanisms to help achieve these goals, such as recommendations for HL7 internal business processes associated with approval of project scope statements, review or validation of project artifacts, and the adjustment of modelling and methodology processes and artifacts.

Goal of This Document

The goal of this document is to promote:

• Awareness of structural, terminological, and implementation characteristics of standards specifications that are intended as candidate international standards;
• Recognition when a specification may indeed be realm-specific, rather than internationally applicable;
• Health solution vendors' and international implementors' confidence that HL7 International standards products are readily implementable and relevant globally, allowing them to reach a broader market in a manageable and scalable manner.

Assertions of Characteristics

1. Points where a realm-specific terminologies are bound is expressly stated in the specification (with examples of value sets appropriate for the data element).
2. There should be a clear distinction between business concepts represented in the standard and how those concept are represented in the implementing realm.

We are asking authors of specifications be conscious of choices they make in the spec where context may be different, and where attention has to be explicitly to ensure the user of the RTSS is aware they need to make their own choice.

Starting phrase would be: 

“A (HL7?) Standard is transferable between contexts (defined in the document) when it has the following characteristics:”

A corollary to this phrase could be:

“A (HL7?) Standards is truly “universal” when is has the following characteristics:”

Do you think this is a good start?

Also, have we debated yet if the RTSS definitions apply to Implementation Guides? There are different ways of looking at this.  It could be said that an IG is a realm or organizational approach to constraining an RTSS to be realm-specific.  Conversely it could be said that IGs can also be designated as Realm Transferable if they provide sufficient guidance for those in other realms to adapt the IG to their needs? 

Enumerate the kinds of things the spec author needs to watch for in terms of relative context e.g. data that must be sent in one context but is not permitted in another context.

data presence / absence

form of data (e.g. address structures and name structures)

terminology binding

workflow assumptions (e.g. use of data elements structurally to enable or constrain workflow based on "local" set of assumption or approach that may not be true in other contexts) 

Some things that affect those things are; 

• regulatory constrained
• attributes about people and processes that are affected by local culture
• realm may apply to standards of practice

We need to establish what types of context means:  e.g. context may be: realm (national), organizational, professional practice, workflows, content or processes constrained by regulation, or by health service payors (e.g. private insurer versus public payor).  

Question for ArB:  is context too specific?

PK: if they are different disciplines, they may be using terminologies that are specific to the country, state, that the discipline is working in.

PK: cardinalities, conformance,

Conversation re conformity:  There are things which don't cause the spec to "break" but cause it to not meaningfully meet another context's use case.  Ex.  write a spec for moving information between providers A&B... they know they are jurisdictional and regional and are aware that other providers will need to do the same thing.  While they think they have the same need, however what is needed to meet the requirements are not compatible with the specification (and is not accommodated for).  e.g. consults or referrals are defined differently depending on the domain. 

With FHIR the specification developer may / could call out the artifacts that have been constrained for.  

The type of things that may be constrained or required in a given context may include: 

Discussion:  IGs and other specifications are all implemented within a particular context.  That context may be 

2.0 Rationale

As an International Standards Development Organization (SDO) it can be presumed that all standards it produces should be readily adoptable for use by the international community.

However, practically speaking, it is also clear that the nature of any resulting specifications or resulting standards is driven by the compelling need of participant communities to achieve specific objectives in terms of their operational context. In the course of doing their work, individuals, working groups may be entirely unaware that some aspects of their approach are specific to their specific health system context and may limit or create significant effort for those who need to employ the standards in a different context.

1. In particular, given that the preponderance of HL7 member representation is from the United States, combined with the incentives, directives and accompanying (welcome) funding arising from the Office of the National Chair for Health IT (ONC) and Health and Human Services (HHS) this often means the business problems to be solved have a distinctly US national, rather than international, perspective to them. While International Affiliate members play very key and supportive roles in this work and, while International Affiliates can vote on resulting standards specifications, these factors alone are not enough to ensure that specifications are readily "transferable" to other national realms.

The business context, approaches, and priorities of Healthcare service delivery internationally are remarkably varied, yet they share a core clinical commonality, or we would not be worried about transferability. In addition, the market reach or target market for many health software systems may be international in scope. These vendors need interoperability standards that are engineered to minimize customization and increase configureability to address variation in their markets. In order to maximize the adoption and utilization of HL7 standards, this document is intended to promote a "mindfulness" about what the characteristics of a truly international standards specification should be (including both what is and is not desirable).

3.0 Challenges in Differentiating Realm-Specific and Truly Internationally Applicable Standards

The manner in which standards development and associated methodologies have evolved in HL7 includes certain concepts regarding the universal or realm-specific nature of health interoperability standards.

Realm
The term "realm" can be defined as:

1. A sovereign state, country, land, domain, dominion, nation, province, canton, etc.  Or...
   
   
2. A field or domain of activity or interest, with synonyms such as domain, sphere, area, field, department, arena.
   1. Note: Within HL7 and the context of health care these are generally called domains.

The term "Realm" has taken on a specific meaning within HL7, that being the context of a specific country's health care system. This context potentially includes:

• policy and legal constraints in terms of health service delivery
• distribution of health services across public and private service providers
• privacy and security laws and regimes for protection of personal health information
• payment or health insurance systems
• requirements for adherence to standards endorsed by particular standards-setting bodies
• ...

However, there is not a common understanding that HL7 International Affiliates are themselves realms.  have Realm and affiliates are not necessarily synonyms.obligations and entitlements for the use of HL7 standards within their associated realm.

Universal Version

Also known as "UV", this phrase is used to describe a version of a standard that is considered universally applicable. A foundational assumption for standards in other sectors is that, where the standard is used, it should be implemented without variation and that each implementation can be testable for conformity with the standard.

While this has been demonstrated to be possible in some sectors of business and industry, health service delivery currently lacks the consistency in practice, concept definition, and governance necessary to achieve such a level of universality.

Constraining versus Extending

The concept of UV exists in HL7 with the presumption that where variability exists in a particular realm that the universal version will be "constrained" or "realm localized" to adapt the standard to meet the particular requirements of the realm it is implemented in. There is an implicit assumption that the universal version has all the elements necessary to achieve a business purpose where "constraining" is used to limit optionality and how those elements are expressed or used to meet realm requirements. An alternate approach is the concept of localization by "extension", where the assumption is the standard has the basic foundation of what is commonly needed and any required variability can be achieved by extending the standards using a consistent framework that does not break the base standard itself. This permits some consistent conformity testing with responsibility for the conformity to the extensions being the responsibility of the realm implementer.

International Standard

In HL7 and International Standard is interpreted to mean that the standard has been developed to meet the needs of "most" or "many" realms through the participation of international contributors and the inclusion of the HL7 International Affiliates in the balloting process for those standards. However there is no definition or guidance on what makes a standard truly international. This is further complicated by the fact most international participants, while usually subject matter experts, are not officially delegated by their respective realms to authoritatively represent that countries business requirements (if those requirements are even known or understood) and have no ability to officially commit their realms to adherence to the standard.

Single Realm (narrative with TSC approved language)

This relates to the development of a standard that is either designed to meet the requirements of a specific realm, or in the process of its development, it is recognized that, given the business requirements being addressed at the time of its development, may not be applicable (as it is initially developed and balloted) for other realms.

Realm-Transferable Standards

In this document, rather than attempt to address the underlying challenges of rationalizing the previously mentioned terms, this document proposes to use the term realm-transferable standards as a proxy for "international". The idea is that realm-transferable standards are those developed in a manner that more readily allows realm-localization without altering the core functional aspects of the standard, permitting conformity assessment across different realms.

Differentiating Standards Development from Systems Development

For persons not familiar with standards development, it is very important to differentiate how standards are created and how they incorporated into software systems (and subsequently change-managed). This difference hinges on the use of the word "development".

When Standard Development Organizations (SDOs) use the word development, they mean the consensus-based definition and elaboration of standards artifacts that will subsequently be used (implemented) in the development of and implementation of other's products. It is a reality that all software development projects must standardize on information representation and internal exchange in order to produce a stable, maintainable product.

However, if that standardization only reflects the requirements of a single customer or does so in a way that is inconsistent with the rest of the market, the resulting product will only be useful in that one implementation. In the case of interoperability, the use of proprietary or project-only standards means the product will only be able to interact with any external systems through direct integration. The whole value proposition of interoperability standards is to allow an industry sector to achieve stability, scale, and access to a fair, competitive marketplace for their products.  Instead of creating their own proprietary system interfaces, sector participants focus on solving requirements in a consistent manner for elements that are, or need to be, common across that sector.  This includes the representation of information and the manner in which it is exchanged between business partners and their customer base.

Developing standards-based software applications allows them to innovate on their value proposition to the market, rather than attempting to define the market in their own singular way. 

4.0 Developing Realm-Transferable Standards

This section addresses how realm-transferability can be more explicitly incorporated in the HL7 standards development process and resulting specifications and guides.

4.1 Project initiation

Current HL7 governance process requires that, at the initiation of a standards project, a declaration be made as to whether the specifications being produced are specific to a particular realm (most commonly US Realm) or intended to be international in scope. While it may be appropriate to express the aspiration for the project at the beginning, and while most would start with being in the international realm, the transferability of the resulting standard specifications to more than one realm is a function both of the requirements expressed over the course of the project, and the manner in which the specification supports variability in international realm contexts and constraints.

<examples needed here>

{Recommendation A.1 Soliciting International Review

If it is known that a specification has been developed to meet realm-specific requirement, it should be declared from the outset. However it should also be possible that the project team can request that:

1. 1. The international community contribute / review / ballot the resulting standards products from the project.
   2. Request that, prior to balloting, an assessment be made of any potential issues that might allow the standards to be balloted as international. In many cases this may be entirely possible with only a few revisions.
      • The assessment process for reviewing for realm transferability would use this document as a primary source of guidance, but the GOM would need to be modified to provide appropriate timelines for such an assessment in advance of a ballot cycle.}

{Recommendation A.2 Role of International Affiliates

International Affiliate (chairs) be polled for potentially applicability of new work item proposals in their respective realms. This could become a regular reporting item by the International Council at working meetings, with the results (and potential in country contacts) distributed back to sponsoring Working Groups.}

4.2 Requirements definition and modeling

In developing realm-transferable standards, wherever possible, begin with international requirements in mind. However, where there is urgency or a compelling business need to be addressed, begin with that is known and provide outreach to the international community for validation or extension of the requirements. The domain analysis model is the first opportunity to test assumptions about the universality of or necessary variability of interoperability requirements.

<examples needed here>

{Recommendation B.1 International Validation Process

ArB recommends a process for the escalation of requests for international validation to the International Council (IC) at the requirements validation phase of the project. This process should include a consistent form of work product(s) to allow the IC members to focus quickly and specifically on what is needed of them.  

While all IC members should be encouraged to respond, not all are required to respond. If there is no explicit international participation in the requirements validation process then at the very least a pre-ballot assessment should be made to determine if the standard specification can be considered international or be designated as realm-specific.}

{Recommendation B.2 Role of International Vendors
It is recommended that a "feature" of HL7 vendor membership list is that new work item proposals are forwarded to designated vendor representatives to assess their interest, and solicit their participation, in the development of the work item.}

4.3 Creation of standards specification artifacts

Most standards work in HL7 begins with the identification of an interoperability problem or need as understood by a community of interest, for a particular organization, based on requirements that may be in the context of the health care service delivery systems for a particular realm.

<examples needed here>

{Recommendation C.1 Conventions for Tagging Elements to Be Generalized 

Documentation conventions should exist for identifying elements of standards specifications that are known to be realm-specific. While we endeavor to identify whole specifications as universal or realm specific, there is not an agreed upon set of guidelines or family-specific methodologies to "decorate" specifications with annotations that identify those portions of realm-specific specifications, either the structural aspects or terminologies, that can then be readily adapted (another way to say this is that they are un-realm'd and then re-realm'd).  This approach is very helpful if there are only one or two aspects of a specification that the standards developers know were based on a specific requirement, but have no other realm perspectives or requirements to allow them to generalize. 

This may need to be addressed within each product family modeling and methodology teams using an HL7 common approach.}

4.4 Aspects of standards specifications that SHALL NOT vary

Aspects of the specification that make the standard "work" technically as required.  These must remain constant regardless of the business, domain, or realm context.  

• Structural - formatting and other constructs that are necessary for the completeness or coherence of the specification - if they are changed the specification is "broken" 
• Infrastructure coded values - fixed or variable-possible-values that are necessary for completeness or coherence 
• Other?

4.5 Aspects of standards specifications to support realm localization

4.5.1 Profiling specifications

The FHIR documentation provides a good baseline for definitions and role of both profiles and implementation guides. Start with that as a base, but then generalize to be not-FHIR specific and express (as much as possible) in layman's terms. >> define profiling and the relationship between Resource Definitions and their use in different interoperability scenarios. Differentiate between profiling use of a specification for a particular use case, versus the use of IG's for how to actually implement the profiles in a particular realm.<<

4.5.2 Creation of implementation guides

Compositional Workflow

Even for a common use case, health service delivery workflow can vary depending on the context of use within a Health Delivery Organization (HDO), and within and across national realms. Ideally standards specifications will avoid embedding the sequencing of multi-step workflows and provide for discreet, reusable work actions that can be implemented in different sequencing. This may require additional data be provided for in the specification to allow the inter-operating systems to establish context for the interaction.

4.5.3 Specification of semantic content

Internal and external terminologies

One of the greatest concerns for making realm-transferable specifications is to recognize that international country realms may have policy or legislative obligations that require them to use certain terminologies.

• for substituting terminology bindings
• Use of international terminology standards maintained outside of HL7

Wherever terminological content is included in a standard it must make provision for the implementer to bind whatever terminology is appropriate or allowable to meet that need.

<example needed here>

{Recommendation D.1 Use of Exemplar Value Set for Terminology Binding

For terminology binding, use of an exemplar value set that is actually realm-specific is 'OK' in a universal standard or IG. This exemplar value set may be using content from a code system that some realms cannot use, either because the content is inappropriate or because it is under license. But for actual implementation in a realm, there must be a realm specific IG where the value set is completely defined and relevant/available for use in that realm. }

4.6 Product Family Modeling and Methodology Support

4.6.1 Contextual guides for solving specific problems

4.6.2 Structured Docs: CDA

4.6.3 Modelling and Methodology : v3

4.6.4 FHIR

4.6.5 v2: INM + Conformance + Vocab

4.6.6 HTA (policy for external standards) clinical / Vocab

5.0 Governance and Process Considerations

>>There may be governance implications for implementing the recommendations provided in this document.   In addition to those recommendations, there may be existing areas of the HL7 Governance and Operations Manual (GOM) that will need to be adjusted. << 

5.1 Governance

5.1.1 SDO Governance

5.1.2 Realm / Affiliate Governance

5.2 Standards balloting and publication

The GOM needs review for the balloting and publication process. Specific attention should be given for any content related to the distinct identification of things as either "realm-specific", "universal", "constrained" or "extended. This may result in additional recommendations for adjustment in the GOM as well as in the BAM.

5.3 Discovery of relevant existing realm transferable standards

5.4 Dealing Licensing and IP Considerations

5.4.2 Referencing content from more than one SDO in an Implementation Guide (best practices?)

5.4.3 Referencing foundational standards from other layers in the OSI interoperability model (e.g. W3C, IEEE and other standards in different levels of the stack (out of scope?)

5.5 Realm Governmental Regulation and Standards Development Priorities

How does this manifest itself in specs?

5.6 Architecting for Realm Transferability

Do we wish to go here?