2.1.0 標準符合性

FHIR規(guī)范提供了一套資源 和幾個不同的框架，用于在不同系統(tǒng)之間交換資源。 為了適用更廣泛場景，本規(guī)范中制定的規(guī)則相當(dāng)寬松顶岸。 因此腔彰，不同的應(yīng)用程序由于采用此規(guī)范中不同的可選項將導(dǎo)致程序間無法互操作叫编，這是FHIR規(guī)范所允許的。 符合本規(guī)范的應(yīng)用程序需要聲明所采用的特定交換框架霹抛，并詳細說明使用的框架和資源內(nèi)容搓逾。

應(yīng)用程序需聲明符合以下交換框架中的一個（或多個）：

• "FHIR 微服務(wù)": RESTful API 基于REST風(fēng)格的API
• "FHIR 消息": Message based exchange消息交換
• "FHIR 文檔": Document based exchange文檔交換

為了提供相關(guān)框架和資源內(nèi)容具體用法的詳細信息， FHIR提供了一個符合性配置層杯拐， 它提供了計算機可理解的符合性聲明，用于說明資源及其交換框架如何解決在業(yè)務(wù)場景下的具體問題纸肉。 符合性配置層是使用以下關(guān)鍵資源來實現(xiàn)的：

該規(guī)范還提供了許多工具 魔种，以通過技術(shù)手段幫助實施者強制符合本規(guī)范的基本要求。

FHIR是一個封閉的規(guī)范粉洼。規(guī)范定義了對貫標者的要求,包括需提供的API服務(wù)或交換框架节预、標準資源等。 貫標系統(tǒng)可提供高于FHIR標準的功能（例如漆改，用自定義名稱添加更多的端點或服務(wù)）心铃，但對那些FHIR規(guī)范沒有明確允許的新增功能，不能在符合性聲明中當(dāng)成或描述為“FHIR符合性要求”挫剑。

符合本規(guī)范并不能保證患者或數(shù)據(jù)安全去扣。但如果不符合此規(guī)范會有以下兩種額外風(fēng)險：

• FHIR已在一定程度上進行了評審查，不會采納任何不滿足符合性要求的變更樊破，而變更可能有未知風(fēng)險愉棱。
• 類似FHIR的解決方案（基于FHIR，但不符合）由于不滿足符合性規(guī)范哲戚，可能會向客戶承諾兌現(xiàn)一些空頭期望奔滑，沒能達到這些期望也可能導(dǎo)致風(fēng)險。

系統(tǒng)只能在能力聲明資源 CapabilityStatement中描述FHIR的功能符合性顺少。

2.1.0.1 統(tǒng)一動詞涵義

本規(guī)范使用RFC 2119中定義的動詞 SHALL朋其、SHOULD、和MAY 來統(tǒng)一描述的涵義脆炎。但與RFC 2119不同梅猿，此規(guī)范允許不同的應(yīng)用程序因使用不同的可選功能而無法交互。特別是：

1. SHALL（必須）：對所有實施者的絕對要求
2. SHALL NOT（不能）: 要求對所有實施者絕對禁止
3. SHOULD/SHOULD NOT(應(yīng)該/不應(yīng)該)：實施者在其特定實施的背景下考慮的最佳做法或建議秒裕「を荆可能由于某種原理忽略某個建議，但在換方式之前必須理解其全部含義并仔細權(quán)衡几蜻。
4. MAY（可以）: 真正的可選項; 可以使用或忽略喇潘，因為實施者的決定不會造成任何后果体斩。

2.1.0.2 標準符合性基本規(guī)范

資源的內(nèi)容和格式必須符合本標準中描述的規(guī)范，包括文字描述的規(guī)范和下述的符合性屬性規(guī)范颖低。 資源類型和數(shù)據(jù)類型中定義的數(shù)據(jù)元素有3個符合性屬性：Cardinality(基數(shù))絮吵、Is-Modifier、MustSupport(必須支持)忱屑。 它們相互作用以滿足符合性的要求源武。

2.1.0.3 Cardinality

All attributes defined in FHIR have cardinality as part of their definition - a minimum number of required appearances and a maximum number. These numbers specify the number of times the attribute may appear in any instance of the resource type. This specification only defines the following cardinalities: 0..1, 0.., 1..1, and 1... Profiles that describe specific use cases may use other values for cardinality within the limits of the cardinality defined by the base resource.

Note that when present, elements cannot be empty - they SHALL have a value attribute, child elements, or extensions. This means that setting an element to a minimum cardinality of 1 does not ensure that valid data will be present; specific FHIRPath constraints are required to ensure that the required data will be present.

In this specification, very few elements have a minimum cardinality of 1. Resources are used in many contexts, often quite removed from their primary use case, and sometimes even basic information is quite incomplete. For this reason, the only elements that have a minimum cardinality of 1 are those where they are necessary to any understanding of the resource or element that contains them. The minimum cardinalities should not be taken as a guide to what elements are expected to be present in any particular use of the resource, including their normal/primary usage purpose. In some cases, this specification publishes additional profiles that define which elements are required in particular situations. Similar profiles are published by jurisdictions, vendors, profiling organizations, or projects.

For elements that have cardinality > 1, the order in which they appear may have meaning. Unless the element definition (either in this specification or the extension) defines a meaning to the order explicitly (using ElementDefinition.orderMeaning), the meaning of the order is not defined, and implementations are allowed to reorder the elements. Note that it is not possible to define a meaning for the order of the elements in a profile using a StructureDefinition. When there is no definition of the meaning of the order, implementations that need to choose a single element from a list of elements for some use SHALL do so based on the semantics of the content of the element that repeats. Profiles and Implementation guides may often make rules about this selection process.

Clients should not depend on servers maintaining ordering of elements, unless the retrieved resource conforms to a profile which mandates maintenance of ordering. If a server cannot maintain ordering, it must strip off known profile tags which require maintenance of ordering, and strip off unknown profiles (since they might require maintenance of ordering).

2.1.0.4 Is-modifier

Is-Modifier is a boolean property that is assigned when an element is defined, either as part of the base resource contents in this specification, or when extensions are defined.

An element is a modifier if and only if it cannot be safely ignored because its value, or its meaning if missing, may cause the interpretation of the containing element or one of its descendants to no longer conform to the stated definition for the element. Typical examples of elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty" that invert or negate the meaning of the resource (or element) that contains them.

Modifier is not an indication of the degree of importance for a particular piece of information or whether the element ought to be ignored when the resource is used for common use-cases. It is expected that if you ignore an element you may miss an important piece of computable meaning.

For example, consider Observation:

• Observation.status allows the entered-in-error code, which indicates that no actual Observation occurred at all. The definition of Observation indicates that it is a measurement that has been made - and doesn't allow for the possibility of a measurement that wasn't made. As a result, if the status element were ignored and an Observation were interpreted at face value based on its definition, a system or user would infer that an Observation had occurred, which would be false
• If an application ignores the Observation.subject element, it wouldn't know who or what was observed, which would make the remaining information largely useless for most usage. However, any system that ignores the subject would not have a false understanding of the Observation as it's defined. The system would understand what type of observation was made, when and what was found, just not who it was about
• Even something as critical as Observation.code is not a modifier element. While the Observation would have little utility without the code, the understanding when ignoring the element that “some” Observation had been made on the specified subject at the specified date and time would still be true when the element was reintroduced. The only exception would be if a value expressed in the Observation.code element could somehow convey that the Observation had not occurred or otherwise cause the instance to diverge from the defined meaning of Observation when ignoring the element

The definition of is-modifier has a corollary: any element that meets the requirement that it could cause the interpretation of the containing element or its descendants to diverge from their definition SHALL explicitly declare how such divergence could occur and must be marked as a modifier element. Any element not marked is-modifier and without that explanation SHALL NOT be used by an implementer in such a manner as to make the element behave as a modifier. For example, using a special "name" on a patient to indicate that the subject isn’t a real patient, but is instead an artificial structure used for non-patient tests would be non-conformant with FHIR because Patient.name is not a modifier element

Whether an element is a modifier cannot be changed when element usage is described in a constraining Structure Definition. When an element is labeled as Is-Modifier, the documentation must be clear about why it is a modifier.

A typical example of a modifier element is one that negates the element that contains it. For instance, in the following fragment of a resource definition:

image.png

The definition of an AllergyIntolerance is that it contains information about "Risk of harmful or undesirable, physiological response which is unique to an individual and associated with exposure to a substance". If the value of the 'verificationStatus' element is set to entered-in-error, the entire resource does not actually contain valid information about any risk of exposure, and it is not safe for applications to ignore this element. As a consequence, it is labeled as 'is modifier = true'. In this tabular representation of the resource, this shows as the flag '?!'. The JSON and XML representations of a resource definition have their own representation of 'is modifier = true' status, and it is defined directly in a ElementDefinition.

If a narrative summary is present, and the status is generated, Is-Modifier elements SHALL be represented in the narrative summary of the resource. If Narrative is present with some other status Is-modifier elements SHOULD be represented.

If the value of a modifier element is not explicit in the instance, or known by the context, the resource might not be able to be safely understood. Wherever possible, elements labeled "Is-Modifier = true" also have a minimum cardinality of 1, in order to introduce certainty in their handling. However, sometimes this is not possible - much legacy data is not well described. Implementations producing resources SHOULD ensure that appropriate values for isModifier elements are provided at all times.

Implementations processing the data in resources SHALL understand the impact of the element when using the data. Implementations are not required to "support" the element in any meaningful way - they may achieve this understanding by rejecting instances that contain values outside those they support (for instance, an application may refuse to accept observations with a reliability other than "ok"). Alternatively, implementations may be able to be sure that, due to their implementation environment, such values will never occur. However applications SHOULD always check the value irrespective of this.

Note that processing the data of a resource typically means copying or filtering data out of a resource for use in another context (display to a human, decision support, exchange in another format where not all information is included or storing it for this kind of use). Servers and background processes that simply move whole resources around unchanged are not "processing the data of the resource", and therefore these applications are not required to check Is-Modifier elements.

Every element in the base resource has a value of "true" or "false" for the Is-Modifier flag. The value of the flag cannot be changed by profiles on the resource, in either direction. When a StructureDefinition defines an extension, it labels the extension with the Is-Modifier flag, and this cannot be changed in other profiles. Note that extensions that have is-Modifier = true are represented differently in resource instances ("modifierExtension" instead of "extension"), and there are additional rules about how they are handled.

Most status elements are marked as modifiers because of the presence of the entered-in-error status. Other modifiers are defined:

• Address.use
• ContactPoint.use
• HumanName.use
• Identifier.use
• Quantity.comparator
• BackboneElement.modifierExtension
• BackboneType.modifierExtension
• DomainResource.modifierExtension
• Resource.implicitRules
• ActivityDefinition.doNotPerform
• AdverseEvent.actuality
• AllergyIntolerance.clinicalStatus
• AllergyIntolerance.verificationStatus
• AppointmentResponse.participantStatus
• Basic.code
• BodyStructure.active
• CarePlan.intent
• CarePlan.activity.detail.doNotPerform
• CatalogEntry.orderable
• CommunicationRequest.doNotPerform
• ConceptMap.group.element.target.relationship
• Condition.clinicalStatus
• Condition.verificationStatus
• Consent.scope
• Contract.term.action.doNotPerform
• DeviceRequest.intent
• Goal.lifecycleStatus
• HealthcareService.active
• Immunization.isSubpotent
• ImmunizationRecommendation.recommendation.forecastStatus
• Ingredient.specifiedSubstance.strength.presentationHighLimit
• Ingredient.specifiedSubstance.strength.concentrationHighLimit
• List.mode
• List.entry.deleted
• MeasureReport.improvementNotation
• MedicationRequest.intent
• MedicationRequest.doNotPerform
• NutritionOrder.intent
• ObservationDefinition.experimental
• Organization.active
• Patient.active
• Patient.deceased[x]
• Patient.link
• Person.active
• Questionnaire.item.enableWhen
• RelatedPerson.active
• RequestGroup.intent
• Schedule.active
• ServiceRequest.intent
• ServiceRequest.doNotPerform
• SpecimenDefinition.experimental
• SubscriptionStatus.notificationType
• SubscriptionTopic.experimental

2.1.0.5 MustSupport

Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.

For this reason, the specification itself never labels any elements as MustSupport. This is done in StructureDefinitions, where the profile labels an element as mustSupport=true. When a profile does this, it SHALL also make clear exactly what kind of "support" is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc.

Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.

2.1.0.6 Constraints

All elements may have constraints attached to them (also known as 'invariants'). Constraints defined on an element have the following properties:

Many constraints are defined in the base specification. In addition, additional constraints may be defined in profiles that apply to resources. Systems are not required to evaluate the constraints, just as they are not required to check for conformance, or schema validity. However, systems SHOULD always ensure that all resources are valid against all applicable constraints.

Constraints have a severity level:

Elements can also be explicitly associated with constraints defined elsewhere. This is a notification to implementers that the element is affected by the constraint. It has no meaning when the constraints are evaluated.

Profiles may define additional constraints that apply to an element, but they cannot alter or remove constraints that are already applied.

2.1.0.7 Other Metadata

In addition to the conformance metadata, each element has other metadata properties defined in the ElementDefinition:

• isSummary - How the element behaves in Summary Searches
• meaningWhenMissing - What it means when an element is missing
• maxLength - How long the representation of the primitive value is allowed to be (not including XML or JSON escaping)

2.1.0.8 Examples and Reference Implementations

This specification includes many examples. While every effort has been made to ensure that the examples are fully conformant to the specification, if the examples disagree with the specification, the specification is considered correct and normative, not the examples. This same rule applies to the reference implementations.

The examples reflected in this specification do not represent actual people. Any resemblance to real people - alive or dead - is entirely coincidental. In some cases, examples may be drawn from real clinical data. However, if this has occurred, the content has been scrubbed to remove any identifying information.