This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. For a full list of available versions, see the Directory of published versions

1.2 Patterns Index

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

Types Framework Cross Reference: Base Types | Datatypes | Resources | Patterns

This specification defines 157 Resources as the primary means for exchange for data. In addition, this specification defines a number of patterns to assist implementers to better understand the relationships between the resources, and also to support the use of abstractions of the resources when implementing common tasks.

There are two different types of patterns:

• Design Patterns: General patterns that resources may follow to some degree, depending on the requirements of the domain that they represent
• Interface Patterns: Specific patterns that are intended to be used as operation abstractions for the resources that follow (=implement) them

Design Patterns

These patterns provide general guidelines around the design of the resources that follow them. The resources that follow these patterns indicate how they follow the pattern by mapping elements in the resource to the pattern. In general, resources may:

• have a matching element, or not (or define an extension for the element)
• split different possible values between different elements
• use different types, or codes that have different values
• have different cardinalities, based on domain analysis

The following Design Patterns are defined:

• FiveWs (Attribution):
• Event: AdverseEvent, AuditEvent, ChargeItem, ClaimResponse, ClinicalImpression, Communication, Composition, Consent, Contract, Coverage, CoverageEligibilityResponse, DetectedIssue, DeviceDispense, DeviceUsage, DiagnosticReport, DocumentReference, Encounter, EnrollmentResponse, EpisodeOfCare, ExplanationOfBenefit, FamilyMemberHistory, GenomicStudy, GuidanceResponse, ImagingSelection, ImagingStudy, Immunization, ImmunizationEvaluation, InventoryReport, Invoice, MedicationAdministration, MedicationDispense, MedicationStatement, MessageHeader, NutritionIntake, Observation, PaymentNotice, PaymentReconciliation, Procedure, Provenance, QuestionnaireResponse, RiskAssessment, SupplyDelivery, Transport
• Request: Appointment, AppointmentResponse, CarePlan, Claim, CommunicationRequest, CoverageEligibilityRequest, DeviceRequest, EnrollmentRequest, ImmunizationRecommendation, MedicationRequest, NutritionOrder, RequestOrchestration, ServiceRequest, SupplyRequest, Task, Transport, VisionPrescription
• Definition: ActivityDefinition, ChargeItemDefinition, ClinicalUseDefinition, EventDefinition, Measure, MessageDefinition, ObservationDefinition, OperationDefinition, PlanDefinition, Questionnaire, Requirements, SubscriptionTopic, TestPlan, TestScript

Interface Patterns

These patterns are intended to provide abstractions for the resources that follow them, for use by implementers. The resources that follow these patterns indicate how they follow the pattern by mapping elements in the resource to the pattern. These patterns are followed more closely, and resources may:

• use a different name for the element
• allow for a higher cardinality that the pattern
• provide a concept map to map between values in the resource and the element values e.g. mapping a set of status codes to an active : boolean
• use a different type with a defined conversion to the pattern type

The following Interface Patterns are defined:

• Participant: CareTeam, Device, Group, HealthcareService, Location, Organization, Patient, Practitioner, PractitionerRole, RelatedPerson
  • Participant - Contactable: Location, Organization, Patient, Practitioner, RelatedPerson
    • Participant - Living: Patient, Practitioner, RelatedPerson

Pattern Candidates

Patterns are a work in progress. This analysis helps identify candidate patterns:

Participation type Patterns

Other Patterns