forked from hl7-fhir/fhir-dstu1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathconformance-rules.html
178 lines (164 loc) · 10.5 KB
/
conformance-rules.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
<!DOCTYPE HTML>
[%settitle Conformance Rules%]
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
[%file newheader%]
</head>
<body>
[%file newnavbar%]
<div class="col-9">
<a name="conformance"> </a>
<h2>Conformance</h2>
<p>
The contents of the resource and the formats used to represent it SHALL
conform to the rules described in this specification, as defined in the
narrative of the specification, and as controlled by the conformance
properties defined below.
</p>
<p>
Note: This spec uses the conformance verbs SHALL, SHOULD, and MAY as defined in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>.
</p>
<p>
Because of its general nature and wide applicability, the rules made in this specification are generally fairly loose.
As a consequence (unlike RFC 2119), this specification allows that different applications may not be able to be interoperate
because of how they use optional features. To allow applications to manage this, FHIR provides
a conformance layer that implementers and national/regional programs can use to provide a computable statement about
how the resources and their exchange paradigms are used to solve particular use cases.
The conformance layer itself is implemented using the following resources:
</p>
<table class="grid">
<tr> <td><a href="valueset.html">Value Set</a></td> <td>Defines a set of coded values (see "<a href="terminologies.html">Using Codes</a>" for more details)</td> </tr>
<tr> <td><a href="profile.html">Profile</a></td> <td>Makes rules about how a resource and it's data elements are used in a particular context. A profile references value sets for the coded elements in a resource</td> </tr>
<tr> <td><a href="conformance.html">Conformance</a></td> <td>A statement of the kinds of resources and operations provided and/or consumed by an application. The conformance resource references profiles to describe specific use of resources by the application</td> </tr>
</table>
<p>
The specification also provides a number of tools that can assist with enforcing technical conformance
to this base specification:
</p>
<ul>
<li><a href="fhir-all-xsd.zip">Schema & Schematron</a></li>
<li><a href="validation.zip">Validator Package - use to check resources against profiles</a></li>
<li><a href="downloads.html#refimpl">Reference Platforms (conformant code in various languages)</a></li>
</ul>
<p>
Note that none of these tools are able to check complete conformance to this specification.
</p>
<p>
Data elements defined in resources and data types have 3 properties that are
directly related to conformance: Cardinality, Is-Modifier, and Must-Support.
These interact to place conformance requirements on implementations.
</p>
<a name="cardinality"> </a>
<h3>Cardinality</h3>
<p>
All elements defined in FHIR have a cardinality as part of their definition - a minimum number
of required appearances, and a maximum number. This number specifies the number of times
the element 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 resource.
</p>
<p>
Note that when present, elements cannot be empty - they SHALL have either 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 XPath constraints are required
to ensure that the required data will be present.
</p>
<p>
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 sometimes very 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 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.
This specification may publish additional profiles that define which elements are required in
which situation, or alternatively, such profiles might be published by jurisdictions, vendors, or projects.
</p>
<p>
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, 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. 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 elements that repeats. Profiles and Implementation guides may often make
rules about this selection process.
</p>
<a name="mustUnderstand"> </a>
<a name="ismodifier"> </a>
<a name="isModifier"> </a>
<h3>Is-modifier</h3>
<p>
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 profiles declare extensions.
An element is labeled "Is-Modifier = true" if the value it contains may change the
interpretation of the element that contains it (including if the element is the resource as a whole). Typical examples of
elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty".
Whether an element is a modifier cannot be changed when element usage is described in a
<a href="profile.html">Resource Profile</a>.
When an element is labeled as Is-Modifier, the documentation must be clear about why
it is a modifier.
</p>
<p>
A typical example of a modifier element is one that negates the element that contains it. For
instance, in the following element definition:
</p>
<pre class="spec"><<a ok="true" title="Specific reactions to a substance." class="dict" ><b>AdverseReaction</b></a> xmlns="http://hl7.org/fhir">
<!-- Other information -->
<<a ok="true" title="When the exposure occurred." class="dict" ><b>exposureDate</b></a> value="[<span style="color: darkgreen"><a ok="true" >dateTime</a></span>]"/><span style="color: Gray"><!--</span> <span style="color: brown"><b>0..1</b></span> <span style="color: navy">When the exposure occurred</span><span style="color: Gray"> --></span>
<<a ok="true" title="Substance(s) that is presumed to have caused the adverse reaction." class="dict" ><b>substance</b></a>><span style="color: Gray"><!--</span> <span style="color: brown"><b>0..1</b></span> <span style="color: darkgreen"><a ok="true" >Resource</a>(<a ok="true" >Substance</a>)</span> <span style="color: navy">Presumed to have caused the reaction</span><span style="color: Gray"> --></span></substance>
<<a ok="true" title="To say that a reaction to substance did not occur (this element modifies the meaning of other elements)" class="dict" ><span style="text-decoration: underline"><b>didNotOccurFlag</b></span></a> value="[<span style="color: darkgreen"><a ok="true" >boolean</a></span>]"/><span style="color: Gray"><!--</span> <span style="color: brown"><b>1..1</b></span> <span style="color: navy">To say that a reaction to substance did not occur</span><span style="color: Gray"> --></span>
<!-- Other information -->
</AdverseReaction>
</pre>
<p>
The element "didNotOccurFlag" affects the entire meaning of the resource - if it is set to true, the whole resource must be understood differently, and so it is not safe for implementations to ignore it.
</p>
<p>
Generally, elements labeled "Is-Modifier = true" also have a minimum cardinality of 1, to introduce
certainty in their handling. If the value of such an element is not explicit in the instance, or known
by the context, the resource cannot be safely understood. Irrespective of the minimum cardinality,
implementations producing resources SHALL ensure that appropriate values for isModifier
elements are provided. Is-Modifier elements SHALL be represented in the narrative summary
of the resource.
</p>
<p>
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 != "ok"). Alternatively,
implementations may be able to be sure, due to their implementation environment, that such values
will never occur. However applications SHOULD always check the value irrespective of this.
</p>
<p>
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.
</p>
<a name="mustSupport"> </a>
<h3>Must-Support</h3>
<p>
Labelling an element Must-Support means that implementations that produce or consume resources SHALL
provide "support" for the element in some meaningful way. Exactly what this means is impossible
to describe or clarify as part of the FHIR specification.
</p>
<p>
For this reason, the specification itself never labels any elements as must-support.
This is done in <a href="profile.html">Resource Profiles</a>, 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 can mean many things.
</p>
<p>
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.
</p>
</div>
[%file newfooter%]
</body>
</html>