This page is part of the Protocols for Clinical Registry Extraction and Data Submission (CREDS) IG (v1.0.0-ballot: STU1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

Create/Update Registry Definitions

This section describes the CURD of this guide. This transaction is used by the Registry Submission Definition Creator and Registry Submission Definition Repository actors.

Scope

Actors Roles

Referenced Standards

Interactions

Create or Update Registry Submission Definition

Trigger Event - Create or Update Registry Submission Definition

A SubmissionDefinitionCreator requests creation of a new Submission Definition

A logical model or submission transformation created by the Registry Submission Definition Creator is communicated to the Registry Submission Definition Source.

Message Semantics

A StructureDefinition is created or updated by the Registry Submission Definition Creator on the Registry Submission Definition Repository .

The Registry Submission Definition Creator creates the …

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

create

The Registry Submission Definition Repository shall support the FHIR create operation on the StructureDefinition and StructureMap resources.

update

The Registry Submission Definition Repository shall support the FHIR update operation on the StructureDefinition and StructureMap resources.

Expected Actions

Create StructureDefinition Resource

The Registry Submission Definition Creator creates resources and sends them to a Registry Submission Definition Repository

The Measure Source performs the FHIR create operation on the MeasureReport resource at a Measure Consumer.

Accept Resource

The Measure Consumer reports success using 200 OK, 201 Created, or 204 No Content to indicate a successful create or update.

Trigger Event -

Message Semantics

Expected Actions

Conformance

See the following CapabilityStatement resources for conformance requirements:

• CapabilityStatement-RSDC-CURD Defines the requirements for the Registry Submission Definition Creator implementing the Create / Update Registry Definition transaction.
• CapabilityStatement-RSDR-CURD Defines the requirements for the Registry Submission Definition Repository implementing the Create / Update Registry Definition transaction.