2nd DSTU Draft For Comment

This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

6.4 Resource Other - Content

This resource maintained by the FHIR Management Group Work Group

Other is a conformant for handling resource concepts not yet defined for FHIR or outside HL7's scope of interest.

6.4.1 Scope and Usage

Other is a special type of resource. Unlike all other resources, it doesn't correspond to a specific identifiable real-world concept. Instead, it's a placeholder for any resource-like concept that isn't already defined in the HL7 specification.

The Other resource is intended for use in two circumstances:

  1. When an implementer needs a resource concept that is likely to be defined by HL7 in the future but they have not yet done so (due to bandwidth issues, lack of sufficient requirements, lower prioritization, etc.)
  2. When the resource concept falls "outside the 99%" - i.e. less than 1% of the systems that use FHIR are likely to ever make use of the resource. To keep the specification manageable, it cannot incorporate every esoteric requirement that might be needed in some implementation somewhere. This set of resources likely won't ever be officially defined in HL7.

There's also a third circumstance: An implementer wishes to convey information that could/should be conveyed using a standard resource, however they want to represent the information in a custom format that isn't aligned with the official resource's elements. While this resource would be the preferred way of meeting that use-case because it will at least be wire-format compatible, such a use would not be conformant because making use of the Other resource would prevent the healthcare-related information from being safely processed, queried and analyzed by other conformant systems.

Implementers don't really need to be concerned with one of the two categories their desired resource fits within. If they need a resource and it doesn't yet exist, they should use Other.

6.4.2 Background and Context

Other defines only a minimal set of data elements - those necessary to identify what kind of resource it represents and those necessary to support resource compartmenting. All other data elements are represented using the extension mechanism.

6.4.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Other DomainResourceResource for non-supported content
... identifier 0..*IdentifierBusiness identifier
... code M1..1CodeableConceptKind of Resource
OtherResourceType (Example)
... subject 0..1AnyIdentifies the
... author 0..1Practitioner | Patient | RelatedPersonWho created
... created 0..1dateWhen created

XML Template

<Other xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Business identifier --></identifier>
 <code><!-- 1..1 CodeableConcept Kind of Resource --></code>
 <subject><!-- 0..1 Reference(Any) Identifies the --></subject>
 <author><!-- 0..1 Reference(Practitioner|Patient|RelatedPerson) Who created --></author>
 <created value="[date]"/><!-- 0..1 When created -->
</Other>

JSON Template

{doco
  "resourceType" : "Other",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Business identifier
  "code" : { CodeableConcept }, // R! Kind of Resource
  "subject" : { Reference(Any) }, // Identifies the
  "author" : { Reference(Practitioner|Patient|RelatedPerson) }, // Who created
  "created" : "<date>" // When created
}

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Other DomainResourceResource for non-supported content
... identifier 0..*IdentifierBusiness identifier
... code M1..1CodeableConceptKind of Resource
OtherResourceType (Example)
... subject 0..1AnyIdentifies the
... author 0..1Practitioner | Patient | RelatedPersonWho created
... created 0..1dateWhen created

XML Template

<Other xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Business identifier --></identifier>
 <code><!-- 1..1 CodeableConcept Kind of Resource --></code>
 <subject><!-- 0..1 Reference(Any) Identifies the --></subject>
 <author><!-- 0..1 Reference(Practitioner|Patient|RelatedPerson) Who created --></author>
 <created value="[date]"/><!-- 0..1 When created -->
</Other>

JSON Template

{doco
  "resourceType" : "Other",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Business identifier
  "code" : { CodeableConcept }, // R! Kind of Resource
  "subject" : { Reference(Any) }, // Identifies the
  "author" : { Reference(Practitioner|Patient|RelatedPerson) }, // Who created
  "created" : "<date>" // When created
}

 

Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire

6.4.3.1 Terminology Bindings

PathDefinitionTypeReference
Other.code Codes for identifying types of resources not yet defined by FHIRExamplehttp://hl7.org/fhir/vs/other-resource-type

6.4.4 Why not custom resources?

Technically, nothing prevents implementers from going off and defining their own resources containing whatever data elements they wish. However, doing so causes several issues:

  • Custom resources don't have a discoverability mechanism in the same way custom codes and extensions do using the ValueSet and Profile resources. As a result, any implementer that receives a custom resource would have no way of looking up what the meaning of the resource or its elements were. While they could get some sense of meaning from XML or JSON tag names, this often isn't sufficient for safe healthcare interoperability.
  • Custom resource names would not be present in the FHIR schemas as allowed elements within the FHIR ATOM schema and would also not be present in the enumeration of resources in the Reference type. This would cause issues for any receiving system making use of the schemas directly or via code-generation.
  • There is no means of ensuring that two implementers might independently come up with the same name for a resource but define it differently in terms of meaning as well as allowed elements. This would also cause interoperability issues.

All of these concerns are mitigated when there's an assumption that the custom resource will only be used within a narrow constrained environment where all participants will be aware of the semantics, will be using the same custom schemas and there's no chance of collisions. However, HL7's experience is that closed implementation environments rarely remain that way over the long term. Eventually data will need to be shared with others outside the closed environment and all of the above issues will again come into play.

Therefore, use of 'custom' resources is NOT considered to be conformant with FHIR. While the use of extensions may make the Other resource slightly more complex and less visually appealing, it is the only safe and approved mechanism for sharing resource concepts not representable using standard HL7-defined resources.

NOTE: This position is subject to change based on implementation experience. Alternative mechanisms for handling custom resource requirements in a safe manner may be explored. Ideas around alternative technical strategies for managing this issue are welcome.

6.4.5 Best practices for using 'Other'

There are several good practices to follow when making use of the Other resource:

  1. Before using Other, post a description of the desired resource type on HL7's FHIR list-server or on Stack Overflow to see whether the use-case can be met by an existing resource. (Sometimes the intended scope of an existing resource won't be clear, even if the intent is to cover your space.) Using an existing resource is usually preferable to using Other as it significantly increases the likelihood of interoperability.
  2. If an existing resource would normally be a good fit for your use-case but can't be used due to overly prescriptive constraints your implementation is unable to meet, again raise the problem on Stack Overflow so the problem with the specification can be addressed
  3. If it is necessary to make use of the Other resource, try to use one of the HL7-defined codes for resource type or submit your requirement for a new type for inclusion in the HL7 vocabulary, as this will increase the likelihood of interoperability. Alternate code systems are conformant, but are less likely to be recognized or re-used across the healthcare implementation space.
  4. Architect your interface in a way that will make it less painful to swap your use of Other with an 'official' resource in the event that a future release of FHIR formally defines a resource that encompasses your use-case.
  5. Use a Profile to define the extensions relevant to each type of other resource used. Profile can also be used to define additional search criteria appropriate for the resource.

Other should always be defined by the use of a

6.4.6 Referencing Other resources

None of the standard resources will have direct references to Other, aside from those that allow linking to "Any" resource. As a result, most references to "Other" will need to be performed using extensions.

6.4.7 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionPaths
codetokenKind of ResourceOther.code
createddateWhen createdOther.created
patientreferenceIdentifies theOther.subject
(Patient)
subjectreferenceIdentifies theOther.subject
(Any)