FHIR Registry Requirements

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.

There are currently 6 primary resources that will be needed to be supported in a FHIR registry to fully support FHIR implementers. They will be fully open for submissions and viewing by the general public They are:

• Namespace - allows registration of the URIs (and potentially other identifier types) used to identify identifier systems (e.g. Alberta drivers licence, US social security number, etc.) and code systems
• Profile - allows constraints on resources (and collections of resources) to be defined
• ValueSet - allows registration of full code systems as well as subsets of codes drawn from one or more code systems
• Conformance - defines expectations for the dynamic behavior of a system
• ConceptMap - allows mappings between codes in value sets and DataElements to be established
• DataElement - describes individual pieces of data that may need to be exchanged

In addition, the registry system will make use of two additional resources that won't function as "registries" but will provide support functions for the overall registry.

• SecurityEvent - allows logging of activities performed against the other registries
• Subscription - Allows applications to request that updates to other resources matching particular parameters be forwarded to them directly.

Of the eight resources identified, the first three registry resources and the SecurityEvent support resource are "high priority". Ideally they should be in place for the second DSTU ballot (spring, 2015). The remaining four are lower priority, though they should be implemented in a timely fashion. It is possible that requirements for additional resources (e.g. Composition, Binary and/or DocumentReference to support implementation guides) might be identified over the DSTU period.

Business Case

• Registries are going to be essential to FHIR's success as an interoperability framework. Implementers need to be able to find the URIs used to identify code systems and identifier types in order to allow matching on codes and ids. Shared (discoverable) profiles and value sets will encourage implementers to coalesce around a more limited set of variations than if everyone goes off and does their own thing. It will also increase the visibility of HL7-developed profiles.
• Registries - and the ability to retrieve information over a FHIR interface is a strong component of the FHIR specification. Systems will come to rely on the ability to retrieve profiles, value sets, lists of identifier types electronically. While they may choose/be encouraged to cache information locally and synchronize for performance reasons, a central authoritative registry will be essential. (This is different from the theory of v2 profile registries and CDA template registries which were both not a core part of the methodology, nor did they have standard programmatic interfaces)
• If HL7 does not develop these registries, someone else in the implementation community will have to, likely within the next 1-2 years
• Maintaining registries opens the opportunity for curation and vetting functions that could be a value add to members and/or a source of revenue for the organization.
• Registries are likely to be one of the more frequent "interaction points" of implementers using FHIR. By hosting the registries, HL7 can help to ensure that the community around FHIR remains centered on HL7 (including relating to content from other SDOs - e.g. IHE, DICOM, etc.)
• The registries will provide an opportunity to publicize what implementers are doing - what problems they are solving, and to gather metrics about what profiles they're defining, what extensions are likely in use, what implementers are querying, etc. This will be valuable to HL7 in tuning the FHIR specification and implementation guides and will also be valuable information for other HL7 members.

Registry Landscape

The registry system defined here will include content from both HL7 and from the general public. The rationale for inclusion of HL7 artifacts is as follows:

• It is in HL7's interest to have our artifacts as discoverable as possible. Registries make the artifacts available in ways that merely posting to a website does not
• RESTful access to resources is a hallmark of how FHIR functions and it would appear odd (and be providing a disservice to implementers) for us to not make our artifacts available in that manner
• Registries provide us with better mechanisms for gathering metrics about the use of resources, profiles and other artifacts

The rationale for inclusion of non-HL7 artifacts is as follows:

• For almost all of the registries, the proportion of content that HL7 will be able to define will be a tiny fraction of what's required in the implementation environment. E.g. Namespaces will need to be defined for all of the various provider types, license types, etc. used in jurisdictions through-out the world. These won't only be used within their own jurisdictions. For example, in Canada it is common for systems to support capturing US Drivers license identifiers, etc. To be useful, the registries will need to contain this content
• HL7 benefits from increased interoperability from the use of FHIR. Interoperability is enhanced the more that implementers use consistent profiles, value sets, etc. Registries encourage and enable such consistency
• The information in the registry from externally-submitted artifacts will provide a metric on use. More profiles on one resource suggests increased implementation of that resource. Broad use of a particular extension may suggest a migration from extension to core (if the resource is not already normative or if the need is handled by implementations using a diverse set of distinct extensions)

While HL7's registry will be important, it will not be the only one. Each organization is likely to have their own local repositories of namespaces, extensions and profiles for reasons of performance and control. In the area of profiles, there will be tens of thousands - every detailed clinical model defined by any system will be a FHIR profile. Every hospital that defines constraints on what a discharge summary should look like or what a referral should look like for particular type of procedure will do so using profiles. Not all will be submitted to the HL7 registry, but the more we can encourage a culture of sharing, the better for interoperability.

Approach

• Development will be required to bring these registries into being. No existing software can meet all requirements
  • If starting from the open source FHIR servers, user interfaces and tie-ins to HL7 authentication mechanisms will be required
  • If starting from the OID registry, a FHIR interface will need to be exposed and content will need to be massaged to be "identified item"-centric rather than "identifier"-centric. Additional tie-ins to HL7 authentication mechanisms may also be needed. Enhancements in the database representation to support additional FHIR data elements and extensions would also be required
  • If starting with an existing off-the-shelf registry mechanism (HINGX, ebXML, etc.), would need to tie into HL7 authentication mechanisms, add a FHIR interface and possibly also change the internals to support FHIR's data model, query approach and extension capability
• The least-cost approach is likely to start with one of the open-source FHIR servers as that will require the least adaptation and be the easiest to migrate when the FHIR specification changes
• From a development perspective there are three options:
  • Develop the necessary application within HL7 and host it within HL7
  • Outsource the development but host and maintain it within HL7
  • Outsource both the development and hosting/maintenance (though making it available under the HL7 URL)

Given limits on HL7 development resources (and the somewhat specialized skills required for FHIR development), as well as the need to make ongoing enhancements to the tool as the specifications change, outsourcing both development and maintenance probably makes sense, at least for the near term. (An option to bring the environment in-house in the future might be desirable)

General

The following aspects are shared by all of the registries

Considerations

• If the registries are used for run-time purposes, this has significant ramifications for the required reliability expectations of the infrastructure supporting the registries as well as the registries themselves. HL7 has not historically needed to provide this sort of reliability. Charging for SLAs would be reasonable. Requiring local caching would be highly advised. We might want to place caps on how frequently services can be invoked from a given IP address to avoid systems using our content in production and incurring associated high usage costs for bandwidth or other hosting charges
• Read access to all registries needs to be made available to everyone - members and non-members alike.
  • It may be possible to have a revenue model and/or "membership benefit" differentiation for certain features (e.g. enhanced search, access to metrics, priority placement), but neither membership nor payment should be required for base features.
• Based on discussions with HQ staff prior to Mike's departure, internal development will not be practical due to both bandwidth and lack of FHIR expertise. Recent staff transitions reinforce these limitations. Thus development will need to be done by a third party. In the near term, third party hosting is likely also desirable for the same reasons as well as to allow rapid scaling based on degree of adoption. Costs would likely involve initial development as well as ongoing hosting and maintenance. Given the scope of the effort, it is unlikely that HL7 could fund the full development cost, so some sort of business model allowing for partial payment would be necessary.
  • Due to the outsourced nature of the work, HL7 should give preference to open-source or other arrangements where we have access to the code and can take on maintenance ourselves if necessary. Similarly, we would need to be able to export all data within the system (including metadata) in standard FHIR formats to allow porting to alternative registries if in the future
• A single integrated set of registries is more desirable than having multiple independent registries for a number of reasons:
  • Improved user experience
  • Reduced cost for shared functions such as authentication
  • Reduced maintenance effort
• The FHIR interface definitions are continuing to evolve during the DSTU process. The registries will need to evolve to remain in sync with the specifications as they change until they become normative (2016-2017 for most, though perhaps not all of them)
• Supporting FHIR interfaces also means the ability to persist (and expose) extensions on submitted content
• All of the registries are limited to infrastructure and support content. No clinical data would be persisted in the registries.
• Default HTML rendering code exists that can be used to display all resources in a standardized manner. This could (and probably should) be leveraged by the solution for standard human rendering of resources
• Work is underway to auto-generate questionnaires for each resource including transforms to convert them to HTML forms. This capability could (and probably should) be leveraged by the solution to allow manual creation and editing of resource instances.

Curation

One of the key functions of a registry is to help implementers discover content they should re-use. This is desirable in many places - profiles, value sets, mappings. However, it's particularly essential for namespaces. If two implementations use different uris to identify the same identifier type or code system, they won't interoperate. For the HL7 OID registry, a process of manual human curation has been adopted, however, this has proven challenging to do on a volunteer or even partially funded basis. Even on a fully funded basis, it would be difficult to have the domain-specific knowledge to understand whether two registrations with slightly different names were in fact "duplicate".

Some artifacts will receive their legitimacy from the HL7 voting process or other formal review processes. However, the bulk of content will come from external sources - affiliates, government organizations, educational institutions, etc. It may be possible to curate some of these submissions with paid or volunteer human review, possibly as a membership benefit or paid service. However, the volume of content will make alternative means necessary. The most common general solution to vetting of large volumes of publicly submitted content is the use of crowd-sourcing. A similar approach of either vote up/vote down or "we use this" may be appropriate, though some submitters may not wish to submit their content for such review.

Requirements

Permissions

1. SHALL support interfacing with HL7's security interface
2. SHALL support authorizing users by OAuth providers configured as acceptable by HL7 (e.g. Google, Facebook)
3. SHALL support associating administrative privileges with specific user ids as well as "member" privileges for users logged on via an HL7 mechanism
4. SHALL only allow operations to be performed against the registries by authorized users, whether using the FHIR RESTful or HTML interface (some operations will be permitted without authentication/authorization)
5. SHALL be able to limit update privileges to the submitter or those with administrative privileges
6. SHALL redirect users to a webpage to accept HL7's usage terms and conditions for content submission prior to receiving permission to post or download content. The web page shall offer the user the ability to log in in a read-only mode
7. SHOULD be able to identify the membership level and affiliate of users logging in via the HL7 interface
8. SHOULD support differentiating privileges based on whether someone is an HL7 member as well as their category of membership
9. SHOULD be configurable to allow all members within an HL7 organization to edit entries submitted by other members associated with the same organization
10. SHOULD allow the integration of an e-commerce solution to allow charging for certain operations based on the resource, operation, operation parameters and user type (HL7/non-HL7 and membership category)

Interface

1. SHALL support RESTful access to the "conformance" operation (all users, no authentication required)
2. SHALL support the "transaction" operation by both RESTful and HTML means. (The latter would be via an "upload" screen accessible from the registry home page)
   1. The upload page SHOULD also accept uploads of individual resource definitions not wrapped in an atom feed, treating them as a "create"
3. SHALL support the "history" operation at a whole system level for administrative users only (with no record limit)
4. SHALL expose a compliant FHIR interface to an agreed version of the supported resources (can't be first DSTU as not all resources are included in that release)
5. SHALL provide a plan for how the registry will be kept up-to-date as resources are revised during the progression to normative ballot, including migration of existing data.
6. SHALL support both the FHIR XML and JSON syntax.
7. SHALL ensure that resource instances are valid against the specification prior to accepting them
8. SHALL be configurable to validate submitted resources (regardless of operation or interface) against an HL7-defined profile for that registry to ensure appropriate population of essential metadata.
9. SHALL provide the ability to query, view and edit resource instances using an HTML interface (for users with the appropriate privileges). Query results must display the resource's submitted narrative.
10. SHALL log all performed and rejected operations using the SecurityEvent resource
11. SHALL be capable of accepting, persisting and exposing extensions on all registry resource instances.
12. SHALL require users to agree to a set of license terms before using the HTML interface and shall be capable of embedding standard (configurable) license terms as part of the feeds for the REST interface.
13. SHALL distinguish content edited or maintained directly on the registry from content acquired from external sources (direct read from source control, subscription to another server, etc.) and only permit edits where the FHIR registry is the "primary" authority for the resource
14. SHOULD be extensible to support the RDF syntax once it is finalized
15. SHOULD be configurable to limit access frequency to the RESTful interface based on userid
16. SHOULD be configurable to limit the number of rows returnable in a single query and paging
17. SHOULD also support rendering of resources using the default rendering capabilities used by the FHIR publication process
18. SHOULD make use of the planned capability allowing HTML creation and updating of resources through the Questionnaire interface. (RESTful support and persistance of Questionnaire and Questionnaire answers is not required)
19. SHOULD support a "voting" mechanism where registered users can indicate their use/support for or disagreement with/non-support for a particular registry entry
    1. SHALL allow control of whether voting is permitted and how it is labeled ("I use" vs. "I endorse" vs. some other term) and whether only positive or both positive and negative votes are permitted on a per-resource type.
    2. SHALL allow registry entries to be tagged by their authors or administrators as not allowing voting
    3. SHALL allow registered users to change their votes, but not to vote more than once
    4. SHALL display the sum of votes on the HTML and as a generated tag in RESTful query responses
    5. SHOULD allow users to see what resources they've voted on and what their votes are
20. SHOULD allow subscription to other registries such that resources maintained on those other registries (possibly limited to those matching particular filters) can be imported and displayed through the HL7 registries. Configuring such subscriptions would be an administrative function
21. MAY support configuration to point at source control repositories such as GIT, SVN and/or Subversion and auto-import and synchronize with resources found on those repositories. This option would be an alternative to uploading a resource instance.

Design

1. SHALL be hostable on a cloud service provider or directly within the HL7 environment
2. SHALL support the Namespace, ValueSet, Profile and SecurityEvent resources as described in the requirements below
3. SHALL display the HL7 and FHIR logos on all HTML pages. The logos shall link to the HL7.org and hl7.org/fhir sites, respectively
4. SHALL support providing a "help" link for each HTML page. The content of each page should be an HTML page that can be edited by HL7
5. SHALL include a "contact webmaster" link that points to a configurable email address
6. SHALL support tagging resources with a special "endorsed" tags, the creation and removal of which shall be limited to administrators or other designated users
7. SHALL support searching based on the "endorsed" tags identified as part of system configuration, including within HTML-based queries
8. SHALL limit the creation or updating of artifacts defining content with a base uri of matching a configurable list of restricted uris (including hl7.org) to users with administrative privileges or designated other users
9. SHALL limit the creation or updating of artifacts with a publisher matching a configurable list of restricted publisher names (including "HL7" and "Health Level Seven") to users with administrative privileges or designated other users
10. SHALL be extensible to accommodate additional registries in the future
11. SHOULD support render "endorsed" resources with a specific logo pointed to in a configuration file based on the type of endorsement
12. SHOULD support the six resources (in order of importance: Subscription, ConceptMap, Conformance, DataElement, Binary, Composition) as described in the requirements listed below. (If support is claimed,

all SHALL clauses for that resource must be met.)

Namespace 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 Driver's 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

• For this to work, there needs to be one authoritative "logical" registry that contains all public code systems and identifier schemes. However, the physical implementation might involve a federated approach. As well, it's possible that local systems might clone all or part of the authoritative registry for performance or other reasons.
• 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'.
• This registry partially duplicates the functionality of the OID registry
  • The OID registry also issues OIDs, which is not a function the Namespace registry would have
  • Ideally, this registry would have an interface to synchronize with the OID registry. However, this would both require making changes to the OID registry and is complicated by the fact that the OID registry now charges for registrations. As well, the OID registry has one record per identifier, while the Namespace registry has one record per identified object, complicating the process. Thus this requirement should be deferred to a future version of the registry
• The design of the Namespace resource is not yet final - harmonization with the existing registry as well as with a recent ISO standard is still required.
• The computational load on the registry is hard to predict. The primary requirement is for design-time use, which should be relatively low load. However, it is possible that systems could choose to perform run-time look-ups of systems for identifiers which would result in higher load, particularly if there is no local caching. It would be possible to separate these uses based on whether the results were returned in human readable (HTML) or computable (XML/JSON) form - and thus possibly place cost expectations or access restrictions on the higher load usages.

Namespace-specific Requirements

1. SHALL support the following operations: read, update, delete (admin only), create, search, validate
2. SHALL be able to check for (and prevent) create or update operations (including via transaction) that would result in multiple active namespaces having the same unique identifier with an appropriate OperationOutcome response
3. SHALL be configurable to automatically change the status from "proposed" to "active" if manual curation is not enabled (with a warning OperationOutcome noting the change)
4. SHOULD support the following operations: vread, history (instance or type)
5. SHOULD be able to limit create privileges to members and be able to constrain permissions of who can edit namespaces associated with particular countries. (Both as configurable options)

Profile/Extension registry

Purpose

FHIR makes use of the Profile resource to define messages, documents, extensions and search parameters. Some of these will be defined by HL7 International. Some will be defined by affiliates. Some will defined by other SDOs such as IHE and some will be defined by projects and local implementers. Profiles will also be used to create Detailed Clinical Models (of which there will be tens of thousands). Maximum interoperability benefit is achieved when implementers use the same extension/profile/search parameter definition for the same purpose. For this to occur, implementers must be able to find existing definitions they can leverage before going through the effort of inventing their own. That means they need a registry.

Considerations

• FHIR says that conformant systems can only use extensions whose definitions are electronically available in the implementation space the communication is happening within, so all extensions will need to be hosted on a registry somewhere
• There will be multiple registries. Some implementations will not want their extensions publicly exposed and thus will want to host registries behind firewalls or other access control mechanisms
• The number of registries may be driven in part by how easy HL7's registry is to use. If it's easy to find information in HL7's registry and it's possible to partition the registry to easily find profiles and extensions relevant to the IHE or a particular affiliate using HL7's registry, then there's less incentive for projects to go off and maintain their own.
• The volume of registered profiles is unknown, but could easily reach into the tens of thousands. Profiles will exist to define extensions needed in different contexts. They will be used to define the types of documents and messages that can be shared. They will also serve the purpose that document templates and Detailed Clinical Models (DCMs) serve
• It makes the most sense to use FHIR to serve up the Profile registry because FHIR reference implementations support all the necessary functions
• The registry needs to support content that has "official" status - content approved by HL7, affiliates and perhaps other SDOs - as well as ad-hoc content submitted by members or possibly the public at large
• There may need to be access controls in place around official content. E.g. HL7 Int'l content is restricted to members only during the ballot period and for 3 months after
• There will also need to be access controls in terms of who can update/supersede content. In general this can be as simple as "only the person or organization that posted content can change it", however more fine-grained control might be needed. For example, it might not be appropriate for anyone who's a member of an affiliate to make changes to affiliate-posted content. Similarly, if content is posted on behalf of an organization by an individual member and that member dies or finds other employment, there needs to be some way of the ownership of the content to be re-assigned
• For content submitted by organizations other than HL7, FHIR has the idea that some of that content might be "vetted" by HL7. This would mean checking to ensure certain quality measures are adhered to, ensuring appropriate RIM mappings and terminology use, checking for duplication against other vetted content, etc. Vetting would be a value-add process, likely with an associated cost.
• Load on this registry is also somewhat hard to predict. Primary use is at design time when selecting profiles, extensions and search parameters for use. However, the registry will sometimes also be used by human analysts at run-time to look up non-recognized extensions and/or profiles (particularly isModifier extensions). As well, the registry could in theory be used at run-time to auto-render extensions by looking up a label for an unrecognized extension and performing simple data type-based display. Filtering run-time use will be challenging as both run-time and non-run-time uses have a need to access the computable form.
• Caution will need to be used if attaching fees to the ability to upload or maintain profiles. Profiles might contain 1 extension or they might contain thousands. We don't want to make people register things in strange ways for financial reasons, nor do we want necessary updates to not be applied to avoid incurring a charge.
• One candidate approach that's been identified is to use Github as a repository and just put a front end on it to expose content as FHIR
• There are several changes proposed to the Profile resource. Implementers should confer with the core team prior to implementing this portion of the registry

Profile-specific Requirements

1. SHALL support the following operations: read, vread, update, delete (admin only), create, search, history (instance), validate
2. SHALL be able to check for (and prevent) create or update operations (including via transaction) that would result in a profile that is invalid against the associated resource(s)
3. SHOULD support the following operations: history (type)
4. SHOULD support restricting read and search operations from returning profiles to non-members if the profile is tagged as "members only" (setting and removing the tag SHALL be limited to administrators)
5. SHOULD support tagging profile instances as "private", which will prevent those profiles from being returned in searches or queries to anyone other than administrators, the submitter or those in the submitter's organization (presuming they're HL7 members).

Value Set registry

Purpose

Any coded element in FHIR is associated with at least one value set. Value sets will also be needed when defining profiles. Implementations need to be able to retrieve the value sets to know what sets of codes are allowed to be used when sending data and, occasionally, what sets of codes were considered when data was selected. Value sets may also depend on other value sets. Value set development and maintenance can be challenging, so re-use of value sets when feasible is also desired.

Considerations

• While the focus here is on computational delivery of value sets for use in FHIR, nothing about a value set is specific to FHIR. A value set registry could easily expose value sets relevant to CDA, v3 messaging, v2, CCOW and other HL7 (and non-HL7) standards.
• HL7 will need to host the value sets it develops and maintains. However, organizations are likely to be interested in registering their own value sets with HL7 for the same reason they register their profiles - greater exposure, greater re-use, leveraging existing infrastructure
• HL7 could, in theory, offer a "vetting" process for value sets, similar to what is contemplated for profiles/extensions
• In addition to exposing value set definitions, there will also be a requirement to compute value set expansions based on those definitions
• It may be advantageous to place a CTS 2 service on the back end to more easily integrate with other terminology sources and to manage complex expansion determinations
• The front end should still expose content using the FHIR resource syntax
• This service is likely to be used for both design and run time. The load could be quite significant if there isn't local caching.
• Access controls will need to be similar to those for profiles - possible restriction on non-member read access, at least for a period of time, limitation of updating to author or author's organization
• This service will need to expose value sets used by FHIR, which includes value set defined in v2 and v3 standards (and likely in CDA implementation guides as well). Ideally, it will expose all HL7-maintained value sets.
• Because value sets can be used by multiple specifications, as well as the fact that pre-existing value sets can be changed by new versions of specifications, maintaining any sort of 3-month "members only" access restriction will be difficult.
• Will also need to verify that exposing value sets referencing LOINC, SNOMED and other external codes does not constitute a violation of our licensing agreements
• Other terminology registries exist (UMLS Metathesaurus, VSAC), however most are realm-specific, code-system specific and/or require curation of submitted content (i.e. they won't just accept whatever value sets someone wants to submit). Because we need to be cross-realm, cross-code-system and able to accept content regardless of quality level, the best we'll be able to do is synchronize with these other registries.
• The git-hub repository model could work for this function as well.

ValueSet-specific Requirements

1. SHALL support the following operations: read, vread, update, delete (admin only), create, search, history (instance), validate
2. SHALL only permit the use of _query=expand operations on SNOMED-CT value sets that are limited to international and HL7 extensions and shall only provide those expansions to members
3. SHOULD support the following operations: history (type), _query=expand
4. SHOULD limit the use of _query=expand to value sets with "reasonable" expansion sizes
5. SHOULD be able to validate codes in a value set from a configurable list of code system sources (possibly including HL7 codes, LOINC, SNOMED CT, UCUM and others) are valid prior to accepting value set creations and updates. This should be configurable to return either an error or warning OperationOutcome.
6. SHOULD support restricting read and search operations from returning value sets to non-members if the profile is tagged as "members only" (setting and removing the tag SHALL be limited to administrators). This includes performing expansions on value sets that draw from "members only" value sets
7. MAY support integration with CTS 2 services to allow an alternative means of accessing, validating against and generating expansions from other code systems

QUESTION: What requirements, if any, should we set about exposing the LOINC license terms and possibly licenses from other terminologies.

Conformance registry

Purpose

Conformance resource instances can be used to identify exactly what particular system end points can do, to describe what particular software systems are capable of independent of a specific installation and to identify what features are desired by a particular organization seeking a system (e.g. as part of an RFP). Central registration of Conformance instances can be used as a means of exposing available FHIR services, as a means of advertising system capabilities and as a way of shaping the market by identifying desired capabilities.

Considerations

• Not clear what the value proposition is for a central registry of these. In the past, organizations have not exactly been jumping up and down to provide computable comparisons of their capabilities.
• One possible use-case is identifying publicly available FHIR repositories for reference data. (Use-case for patient-specific data is less clear, though may be useful in some scenarios.)
• Another possible use-case is setting an expectation that only Conformance statements submitted to the HL7 registry will be considered when evaluating decisions around the migration of extensions into core and other decisions around the support and enhancement of particular resource capabilities.

Conformance-specific Requirements

1. SHALL support the following operations: read, update, delete (admin only), create, search, history (instance), validate
2. SHOULD support the following operations: vread, history (type)
3. SHOULD support tagging conformance instances as "private", which will prevent those profiles from being returned in searches or queries to anyone other than administrators, the submitter or those in the submitter's organization (presuming they're HL7 members).

ConceptMap registry

Purpose

ConceptMap resource instances allow associating code from different code systems or value sets with each other and can be used to support automated code translation. It can also be used to create mappings between data elements and between data elements and codes. It may be extended to support mappings to other things (e.g. interface standards). Shared registration of concept maps allows these resources to be widely shared and built upon. E.g. If one implementer has created a map between two code systems, it doesn't make sense for everyone else to have to support the same effort.

Considerations

• It's possible that two independent entities could create different maps for the same sets of value sets.
• We need to make very clear that maps are not HL7's responsibility and are a "use at your own risk" thing
• The content of this registry may change to support mapping more than just code, so it likely shouldn't be implemented immediately

ConceptMap-specific Requirements

1. SHALL support the following operations: read, update, delete (admin only), create, search, history (instance), validate
2. SHOULD support the following operations: vread, history (type), _query=translate

DataElement registry

Purpose

The data element resource allows a type of data to be defined in terms of its meaning and allowed values. DataElements can be referenced in Profiles and Questionnaires as well as in non-FHIR artifacts such as CDA templates. By standardizing allowed content, data elements increase interoperability across systems. This standardization only works if implementers use the same data element definitions, making the existence of a registry essential for them to be useful.

Considerations

• This resource is new and not stable. It should not be implemented prior to passing DSTU

DataElement-specific Requirements

1. SHALL support the following operations: read, update, delete (admin only), create, search, history (instance), validate
2. SHOULD support the following operations: vread, history (type)

SecurityEvent

Purpose

This registry provides a full audit of all activity that has taken place in any of the FHIR registries. This allows the integrity of the registries to be validated. It also provides a source of information about the use of the registries that can be leveraged for various analysis purposes

Considerations

• The information in the registry should be considered confidential as it shows what specific users have done over time
• HL7 may choose to make summary and detailed reports of a subset of this information available to benefactors or to other interested parties, potentially for a price
• There is no need for general interfaces to create, modify or browse this information

SecurityEvent-specific Requirements

1. SHALL support the read operation and no others via RESTful interface
2. SHALL create a record in this registry for every single resource operation as well as transaction operations. This includes "read" operations on security event, though not "create" operations on security event.
3. Does not need to support an HTML interface for this registry

Subscription

Purpose

This registry allows systems to create subscriptions allowing updates to resources of interest to automatically be delivered to a particular system. This provides benefits for both users and for HL7. Users are notified of new content as soon as it is available and HL7 avoids having thousands of systems regularly polling multiple registries checking to see if there is a new version of content of interest to that system. For example "tell me whenever one of these profiles has been updated" or "tell me whenever there's a new identifier namespace defined with a country of Japan".

Considerations

• This is a draft resource that has not yet been exercised. Implementation should be delayed until the behavior has been successfully demonstrated in test systems and the design is considered somewhat stable. (Passing DSTU ballot wouldn't be a bad thing either.)
• This is a candidate for a member benefit or a paid service

Subscription-specific Requirements

1. SHALL support the following operations: read, update, delete (NOT restricted to admin only), create, search, validate
2. SHALL support the web-hook subscription type
3. SHALL support subscriptions that include payload as well as notification-only subscriptions
4. SHALL enforce user security privileges when evaluating whether to accept a subscription
5. SHOULD support the following operations: vread, history (instance, type)
6. SHOULD support the WebSockets, Email and Messaging subscription types
7. SHOULD provide an automated means of canceling subscriptions that no longer have authorization (e.g. user is no longer a member and subscription is limited to members or a particular membership category)