FHIR Registry Requirements

From HL7Wiki
Revision as of 04:52, 17 October 2013 by Lmckenzi (talk | contribs) (Created page with "{{FHIR Discussion Page}} Category:Active FHIR Discussion For FHIR implementation to be completely successful, a number of registries will need to be available to implementer...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

For FHIR implementation to be completely successful, a number of registries will need to be available to implementers. In several cases, at least one instance of a given type of registry will need to be hosted by HL7 International. This page describes the types of registries that are needed, describes why they are required and identifies characteristics that may be relevant in planning how to maintain and potentially fund the ongoing curation of them.

Identifier System registry

Purpose

This registry allows implementers to look up the "system" URI to use when identifying common coding and identification systems. E.g. SNOMED CT, LOINC, Wisconsin Drivers License, Alberta College of Physicians and Surgeons License Number, etc. There is no need for this registry to contain the systems used for local identifiers (e.g. a particular hospital's patient identifier or a particular lab's test code system) because the data that makes use of those systems should always originate from the organization that is responsible for determining the URI. However, many identifiers and codes are captured by organizations *other* than the organization that assigns that identifier. For example, a Wisconsin drivers license number could easily be captured as part of a patient's identifying information when admitted to a hospital in DC. For identifiers and code systems to be computationally useful in exchange, it's important that all systems use the same "system" URI to identify the namespace of the identifier or code being conveyed. Otherwise matching won't be possible. The purpose of this registry is to provide a single source of truth for the various types of public identifiers

Considerations

  • There are a *lot* of potential identifiers. As in 10k+ (every type of professional license number in every jurisdiction in every country + every type of public patient id in every country + every type of public facility id, device id, etc . . .)
  • In FHIR, it's possible to label an identifier without specifying the system, though this limits utility in computational matching
  • To be useful, there needs to be a single authoritative system for use as much as possible
  • In some cases, local regulation, registration errors or other factors may mean that a given code system or identification system has multiple entries. The registry must support this, and allow identifying the preferred system
  • As much as possible, we want to avoid two independent registrations for the same concept (possibly using slightly different names)
  • Knowledge of what concepts are distinct namespaces vs. the same namespace often requires realm-specific knowledge. (E.g. Only a Canadian or possibly an Albertan would know that the Alberta Unique Lifetime Identifier (ULI) is just another name for the Alberta Provincial Health Number (PHN) and thus the 'system' used should be the same for both)
  • Those who need to have particular systems registered (professional license numbers, passport numbers, etc.) will generally *not* be the same as the organizations that actually maintain the code systems or issue the identifiers, so getting authoritative information may be difficult
  • At the same time, creation and updating of information should be limited to those who are knowledgable about the type of identifier or code system being registered
  • Ideally, URIs should resolve to real pages that provide information about the identification system or, if possible, the ability to look up specific codes or identifiers
  • The URIs of those real pages sometimes change
  • Much of the needed functionality already exists in the HL7 OID registry, however the OID registry also supports registration of concepts other than code systems and identifiers and does not limit registrations to "public" identifiers and codes. As well, the curation is voluntary and thus limited in terms of capacity
  • While URIs can be based on OIDs, this is not preferred as they are hard for implementers to understand and use. Where they exist, OID-based URIs would be identified as secondary "non-preferred" values for 'system'.
  • If a new registry is introduced for FHIR, it should supersede the function of the OID registry. I.e. We should not have two registries with similar function.
  • There isn't a resource for capturing System entries yet, but we could create one easily if desired.

Requirements

  1. Must be able to record the following information:
    1. Code system or identifier
    2. If identifier, a categorization of the kind of identifier (terminology to be developed)
    3. The country/realm where the code or identifier applies (could be international)
    4. The state/province/territory where the code or identifier applies (optional)
    5. The name of the organization that is responsible for maintaining the code system/issuing the identifier
    6. The label for the identifier
    7. A description of the code system or identifier
    8. Usage notes for the code system or identifier (case sensitivity, use of separators, etc.)
    9. The 'system' URI to use
    10. The OID to use (for v3 systems)
    11. links to any superseding registry entry
  2. Should be able to limit who can record information (perhaps limit to members only? Perhaps limit users to creating data for their own realm?)
  3. Need to be able to search by realm, stat/province/territory, identifier type, keyword, system and OID
  4. Need to be able to resolve a system or OID to the "preferred" system or OID and also to a list of candidate systems/OIDs (to be used for matching purposes)

Profile/Extension registry

Purpose

Considerations

Requirements

Value Set registry

Purpose

Considerations

Requirements

Conformance registry

Purpose

Considerations

Requirements

General

All of these registries share the following requirements

  1. It should be possible for systems to electronically search and retrieve entries from the registry that are useful in computational systems
  2. It should be possible for systems to subscribe to information maintained in another system - either the full registry contents or a subset of it
    1. E.g. Affiliate might maintain information that gets auto-imported into the international registry. Hospital systems might subscribe to US identifier systems for ease of look-up in their ADT systems