This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Realm"

From HL7Wiki
Jump to navigation Jump to search
(Realm moved to Resolved:Realm)
 
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
#REDIRECT [[Resolved:Realm]]
+
{{Approved Lore}}
 +
{{MnM Resolved Hot Topic}}
  
 +
==Definition==
 +
The term Realm (previously also referred to as [[Context of Use]]) is used in different ways:
 +
# It is often used to identify an '''affiliate''' organization or a country, e.g. in statements like "This issue is realm specific", "this is a U.S. Realm use-case". This usage identifies the Affiliate as a whole.  For the U.S., 'affiliate' includes the the equivalent U.S. organization
 +
# It may indicate a '''namespace realm:''' a "namespacing" mechanism for artifact identifiers (the CA, UK, UV, etc. that appear near the end of artifact ids). Its value is either an alphabetic string (no longer limited to 2 characters in forthcoming MIF 2.0-based tooling) registered with HL7 or an OID. Each namespace realm has a '''namespace realm owner''': the authorising entity that is responsible for what can legitimately be put in the realm. Anyone who wants to should be able to create artifacts in separate realm-namespaces.
 +
## Any party can be a "namspace realm owner". The current artefact IDs don't support this, a new way of constructing artefact identifiers has been discussed, but has yet to be made available (in the pubs tools). Right now there's no guarantee that your ID won't be re-used at some point in time. You may choose to use a dummy realm ID (e.g. XX); or use  a number that is in the 999xxx range in an attempt to prevent duplication, but there's still no guarantee under the current ID scheme that duplication will be avoided.  In the new identifier style (DD_RR_AA_nnnnnn_vv), based on MIF 2.0, the limits in character lengths will go away and RR will be either a string registered with international publishing (along the lines of UV, UK, CA, etc., though no longer limited to 2 characters) or an OID.  This will be the "realm namespace" for the artifact.  However, the use of this new expression of artifact identifiers will not exist until the new tools are in place, which will start in Q2 2008.
 +
# It may indicate a '''binding realm:''' this manages the bindings/substitutions of Valuesets and CMETs (and templates and datatype specialisations if and when substitution rules for these are agreed) to reflect local rules.  It is the realm communicated by InfrastructureRoot.realmCode and determines conformance rules for vocab, datatype, etc. Each binding-realm has a '''binding realm owner''': this organization must be an Affiliate. In some exceptional cases the binding realm owner may be a group of Affiliates (if they have an agreement to share ownership), e.g. for binding realms like "Dutch-German cross-border hospitalisation", "European-Indian dental tourism" or "US-Canadian Pharmacy".
 +
 +
While initially, the latter two purposes had considerable overlap, reality is that they should be quite distinct.
 +
 +
When a realm identifier is issued, a record will be kept as to whether that is to be used for namespaces, bindings, or both.  Effectively this means that there is a single "realm" code system from which are derived 3 distinct valuesets which are hierarchical: ''Affiliate'', ''binding realm'' and ''namespace realm'', such that all binding realms are automatically namespace realms and affiliate realms are automatically both binding and namespace realm.
 +
 +
''Addendum (from Nov. 2006 interim meeting):'' Bindings may apply to a single 'binding realm' even when messages originate from multiple countries.  For example, U.S. Medicare insurance claims are considered to be "U.S. Binding Realm", even if they originate from countries other than the U.S.  This is because the definition of the specifications are intended for U.S.-covered parties and the rules are defined and managed solely within the U.S.
 +
 +
=== Consequences ===
 +
*An Affiliate may maintain more than a single realm (i.e. more than one ''binding realm'', as well as more than one ''namespace realm'').
 +
 +
== Approval and next steps ==
 +
MnM call 2006/06/30
 +
*Motion by Craig to approve these definitions and undertake the actions below
 +
*Seconded by Woody 8:0:0
 +
 +
'''Actions:'''
 +
*MnM agrees to maintain these definitions
 +
*MnM will forward these definitions to vocabulary (Woody), EHR (Woody) and conformance (Lloyd), requesting that the use the agreed terms or provide feedback on necessary adjustments (resolutions needed from each committee to that effect)
 +
*MnM (Lloyd) to request Publishing to develop a process for managing the issuing of realm short codes for now (resolution from the committee to that effect - with instructions as to how to request one)
 +
 +
*MnM (Lloyd) to request publishing to add these terms to the glossary, and maintain them as core glossary definitions (realm is currently defined as a core glossary term)
 +
*MnM and other committees will update all documents that discuss realm or context will be updated to use the appropriate term, and to have it hyperlinked to the glossary.  This includes Vocabulary, RIM (Woody), Conformance and Localisation, the V3 Guide and the glossary.  This should be done as a technical correction to the version in the ballot package, and be validated by ballot next time the documents go through an approval cycle.

Latest revision as of 00:50, 22 December 2006

Definition

The term Realm (previously also referred to as Context of Use) is used in different ways:

  1. It is often used to identify an affiliate organization or a country, e.g. in statements like "This issue is realm specific", "this is a U.S. Realm use-case". This usage identifies the Affiliate as a whole. For the U.S., 'affiliate' includes the the equivalent U.S. organization
  2. It may indicate a namespace realm: a "namespacing" mechanism for artifact identifiers (the CA, UK, UV, etc. that appear near the end of artifact ids). Its value is either an alphabetic string (no longer limited to 2 characters in forthcoming MIF 2.0-based tooling) registered with HL7 or an OID. Each namespace realm has a namespace realm owner: the authorising entity that is responsible for what can legitimately be put in the realm. Anyone who wants to should be able to create artifacts in separate realm-namespaces.
    1. Any party can be a "namspace realm owner". The current artefact IDs don't support this, a new way of constructing artefact identifiers has been discussed, but has yet to be made available (in the pubs tools). Right now there's no guarantee that your ID won't be re-used at some point in time. You may choose to use a dummy realm ID (e.g. XX); or use a number that is in the 999xxx range in an attempt to prevent duplication, but there's still no guarantee under the current ID scheme that duplication will be avoided. In the new identifier style (DD_RR_AA_nnnnnn_vv), based on MIF 2.0, the limits in character lengths will go away and RR will be either a string registered with international publishing (along the lines of UV, UK, CA, etc., though no longer limited to 2 characters) or an OID. This will be the "realm namespace" for the artifact. However, the use of this new expression of artifact identifiers will not exist until the new tools are in place, which will start in Q2 2008.
  3. It may indicate a binding realm: this manages the bindings/substitutions of Valuesets and CMETs (and templates and datatype specialisations if and when substitution rules for these are agreed) to reflect local rules. It is the realm communicated by InfrastructureRoot.realmCode and determines conformance rules for vocab, datatype, etc. Each binding-realm has a binding realm owner: this organization must be an Affiliate. In some exceptional cases the binding realm owner may be a group of Affiliates (if they have an agreement to share ownership), e.g. for binding realms like "Dutch-German cross-border hospitalisation", "European-Indian dental tourism" or "US-Canadian Pharmacy".

While initially, the latter two purposes had considerable overlap, reality is that they should be quite distinct.

When a realm identifier is issued, a record will be kept as to whether that is to be used for namespaces, bindings, or both. Effectively this means that there is a single "realm" code system from which are derived 3 distinct valuesets which are hierarchical: Affiliate, binding realm and namespace realm, such that all binding realms are automatically namespace realms and affiliate realms are automatically both binding and namespace realm.

Addendum (from Nov. 2006 interim meeting): Bindings may apply to a single 'binding realm' even when messages originate from multiple countries. For example, U.S. Medicare insurance claims are considered to be "U.S. Binding Realm", even if they originate from countries other than the U.S. This is because the definition of the specifications are intended for U.S.-covered parties and the rules are defined and managed solely within the U.S.

Consequences

  • An Affiliate may maintain more than a single realm (i.e. more than one binding realm, as well as more than one namespace realm).

Approval and next steps

MnM call 2006/06/30

  • Motion by Craig to approve these definitions and undertake the actions below
  • Seconded by Woody 8:0:0

Actions:

  • MnM agrees to maintain these definitions
  • MnM will forward these definitions to vocabulary (Woody), EHR (Woody) and conformance (Lloyd), requesting that the use the agreed terms or provide feedback on necessary adjustments (resolutions needed from each committee to that effect)
  • MnM (Lloyd) to request Publishing to develop a process for managing the issuing of realm short codes for now (resolution from the committee to that effect - with instructions as to how to request one)
  • MnM (Lloyd) to request publishing to add these terms to the glossary, and maintain them as core glossary definitions (realm is currently defined as a core glossary term)
  • MnM and other committees will update all documents that discuss realm or context will be updated to use the appropriate term, and to have it hyperlinked to the glossary. This includes Vocabulary, RIM (Woody), Conformance and Localisation, the V3 Guide and the glossary. This should be done as a technical correction to the version in the ballot package, and be validated by ballot next time the documents go through an approval cycle.