Protocols for Clinical Registry Extraction and Data Submission (CREDS) IG, published by HL7 International / Clinical Interoperability Council. This is not an authorized publication; it is the continuous build for version 1.0.0. This version is based on the current content of https://github.com/HL7/fhir-registry-protocols-ig/ and changes regularly. See the Directory of published versions

Search for and Retrieve Registry Submission Definitions

Scope

Search/Retrieve Registry Definition (SRRD) This section describes the SRRD of this guide. This transaction is used by the Registry Submission Definition Creator, Registry Submission Definition Repository and Registry Submitter actors.

Actors Roles

Referenced Standards

Interactions

Search Request

Message Semantics

The client sends a query using an HTTP GET or POST transaction to the server requesting information on available resources.

The following are general requirements of the interaction.

1. Formats
   All servers **shall** support the _format parameter for any read or search and the standard values defined by FHIR for JSON and XML output. This value **shall** override the Accept: header when present in an exchange. Servers **shall** also support the Accept: header, and **shall** support any value in Accept: that can be given to _format for consistency. Servers are also free to support other output formats (e.g. turtle as defined in the base FHIR specifications, or other formats such as CSV which might be easier for clients to present or use). Servers should support other commonly used expressions representing JSON or XML outputs without complaint, including those specified in prior releases (e.g., the DSTU2 application/xml+fhir or application/json+fhir types that have since changed in R4).

   Parameter	Cardinality	Registry Submission Definition Repository Expectation	Registry Submitter Expectation
   _format=application/fhir+xml|application/fhir+json	0..1	shall	shall
   _format=xml|json|text/xml|application/json|application/xml|application/xml+fhir|application/json+fhir	0..1	should	should not
   Accept:=application/fhir+xml|application/fhir+json	0..1	shall	shall
   Accept:=xml|json|text/xml|application/json|application/xml|application/xml+fhir|application/json+fhir	0..1	should	should not

2. The server **shall** support the _count parameter for queries. Servers **should** use a default value for _count if no value is provided to avoid server overloading. This guide recommends a default value of 100 based on existing implementation experience.

   Parameter	Cardinality	Registry Submission Definition Repository Expectation	Registry Submitter Expectation
   _count	0..1	shall	shall

3. Include Support
   To reduce transaction overhead, a client system may wish to retrieve all the resources referenced by the selected resource when obtaining it. This can be accomplished by using a search with an _id parameter, combined with _include=*. This guide does not further specify specify resource includes beyond required support for *. Systems that support _include generally handle _include=*, in fact, in some ways it is easier to implement than more selective _include operations. Recursive includes can be a source of server loading issues, as an incorrectly implemented include with recursive includes could wind up retrieving far more data than the client expected. Thus, these are not recommended.

   Parameter	Cardinality	Registry Submission Definition Repository Expectation	Registry Submitter Expectation
   _include=*	0..1	shall	shall
   _include:iterate		should not	should not

read

A client shall be able to read individual resources that are returned or referenced within resources returned by a query.

The Registry Submission Definition Repository shall support the FHIR read operation on the StructureDefinition resource.

search

A client system shall be able to retrieve the definition data by publisher, condition, description or other text. The Registry Submission Definition Repository shall support the FHIR search operation on the StructureDefinition resource with the following parameters.

1. Search by _id
   A client **shall** be able to read individual resources that are returned or referenced within resources returned by a query. Client systems may save resource references for future use, retrieving them later as needed. To reduce overhead, a client system may also wish to retrieve the resources referenced by the selected resource. This can be accomplished by using a search with an _id parameter, combined with _include=*

   Parameter	Cardinality	Registry Submission Definition Repository Expectation	Registry Submitter Expectation
   _id	1..*	shall	shall

2. Search by url, name, identifier, publisher, condition or status
   A client **shall** be able to query for resources by url, name, identifier, publisher, condition or status.

   Parameter	Cardinality	Registry Submission Definition Repository Expectation	Registry Submitter Expectation
   url	0..*	shall	shall
   name	0..*	shall	shall
   identifier	0..*	shall	shall
   publisher	0..*	shall	shall
   context	0..*	shall	shall
   status	0..*	shall	shall

3. Search by Date
   A client **shall** be able to search by relevant dates, e.g., the date of _lastUpdate of a previously retrieved resource to see if it has changed (e.g., in cases where data needs to be refreshed). All date searches **shall** allow a range to be specified, but need not allow more than one range. Approximate ranges are not required to be supported because server support for these is not commonly available, nor implemented in readily reproducable fashions (the definition of an approximate date can have different meanings for different servers). Simple eq, le, lt, ge, and gt **should** be sufficient to specify date ranges.

   Parameter	Cardinality	Registry Submission Definition Repository Expectation	Registry Submitter Expectation
   _lastUpdated	0..2	shall	shall
   date	0..2	shall	shall

4. Search by Text or Code
   A client system **should** be able to search for definition resources associated with by text within the definition. This requirement can be met through support of the _text or _content search parameters.

   Parameter	Cardinality	Registry Submission Definition Repository Expectation	Registry Submitter Expectation
   _text	0..*	should	should
   _content	0..*	should	should

Conformance

See the following CapabilityStatement resources for conformance requirements:

• CapabilityStatement-RSDR-SRRD Defines the requirements for the Registry Submission Definition Repository implementing the Search / Retrieve Registry Definition transaction.
• CapabilityStatement-RS-SRRD Defines the requirements for the Registry Submitter implementing the Search / Retrieve Registry Definition transaction.