forked from hl7-fhir/fhir-dstu1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcomparison-v3.html
189 lines (176 loc) · 13.1 KB
/
comparison-v3.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
179
180
181
182
183
184
185
186
187
188
189
<!DOCTYPE HTML>
[%setwiki http://wiki.hl7.org/index.php?title=FHIR_HL7_Standard_Relationship%]
[%settitle Relationship between FHIR and v3 Messaging%]
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
[%file newheader%]
</head>
<body>
[%file newnavbar%]
<div class="col-9">
[%cmpheader v3%]
<h2>HL7 Version 3 (and ISO 21090)</h2>
<a name="V3"> </a>
<p>
HL7 Version 3 (V3) is the next generation of HL7's messaging standards. It introduced
a common Reference Information Model (RIM), data type model and set of vocabulary as well as
a formal standards development methodology. In addition, it introduced the use of
"documents" as an alternative architecture to messaging for sharing healthcare information
(see <a href="comparison-cda.html">the CDA comparison</a>). While nominally covering both, the term "V3" is
typically used to refer to "V3 messaging". The data types used as a basis for V3 have
also been adopted by ISO as ISO 21090. The HL7 RIM has also
been adopted as an ISO standard.
</p>
<p>
V3 messaging has been adopted by a number of large projects, particularly in the
electronic health record area, though it has not achieved the market penetration of
HL7 V2. The HL7 RIM and the ISO 21090 data types have also been
used by other SDOs and projects that have not leveraged the full HL7 V3 methodology.
Most of the comments and guidance provided here will apply to those solutions as well.
</p>
<h3>V3 Similarities and Differences</h3>
<p>
<b>Reference model:</b> The use of the HL7 RIM is a core aspect
of the HL7 V3 methodology and it is front and center in the specification and the wire
format. All data elements in HL7 V3 instances are derived from either the RIM or the ISO
data types. In FHIR, this is true of most resources and data type elements, but not all.
Some resources (<a href="profile.html">Profile</a>, <a href="conformance.html">Conformance</a>,
<a href="valueset.html">ValueSet</a>, etc.) deal with content that is outside the RIM's scope. And in a few circumstances, adjustments have been made in
the FHIR data types that are not yet supported in the HL7 V3 data types model. The expectation
is that these changes will be supported in the next version of the V3 data types model. The
main difference is that the wire format of FHIR is not driven by the RIM
mappings. This results in considerably more concise and intuitive instances. It is possible
to implement FHIR with absolutely no knowledge of the HL7 RIM.
</p>
<p>
<b>Codes:</b> V3 places considerable reliance on coded attributes to convey the
meaning of instances. Examples include <i>classCode</i>, <i>moodCode</i>, <i>determinerCode</i>,
etc.
The allowed codes for these attributes are strictly controlled by HL7. FHIR also has attributes
that are limited to codes defined in the FHIR specification - those using the <a href="datatypes.html#code">code</a>
data type. However, these are generally limited to attributes with business meaning - status, contact types, etc.
</p>
<p>Both FHIR and V3 make use of value sets to define the sets of codes that can be used for
attributes in particular contexts. However, in FHIR, a <a href="valueset.html">ValueSet</a>
is just another type of resource, meaning it can be sent as part of an instance just like any
other piece of data. (The same is true of <a href="profile.html">Profile</a>, <a href="conformance.html">Conformance</a>
and other meta-level resources.)</p>
<p>
<b>Granularity & referencing:</b> HL7 V3 models are broken into 3 main types - wrappers,
payloads and Common Message Element Types (CMETs). These are combined into interactions to
define the set of content that can be sent over the wire at one time. In some cases, the
granularity of each of these models will exactly align with the granularity of FHIR resources,
but not always. V3 models are divided based on the expectation of re-use. FHIR models are
divided based on whether the objects they represent are considered to be able to "stand alone".
In HL7 V3, numerous models can exist to represent the same essential underlying healthcare
information construct. For example, at the HL7 International level, there are 10 different CMETs
for the concept of "Patient". In addition, some payload models represent patient directly without
using CMETs. Further variation exists in the V3 models created by HL7 affiliates and other V3
implementers. Each of these different CMETs has their own schema and may use different element names,
different levels of nesting and different constraints. With FHIR, there is only one <a href="patient.html">Patient</a> resource.
Many profiles can be created on that resource, but all of them will use the same schema and support the same wire format.
</p>
<p>
<b>Design by constraint:</b> The design methodology in V3 is one of "design by constraint".
The idea is that all data needed for any sort of healthcare communication is represented in the HL7 RIM.
All other data models simply constrain the RIM to reflect the needs of particular domain spaces.
This starts at the international level with further refinement happening in individual countries, projects
and finally specific implementations. As models become closer to the implementer, they become less abstract.
The result is a tendency for V3 models to be extremely broad in their coverage and capability and also
somewhat abstract. They need to be in order to ensure that all possible implementations in the space
covered by that model can be proper constraints on it. As well, each model produces its own schema and,
in most cases, constrained schemas are not strictly wire-compatible with the schemas of the model being
constrained.
</p>
<p>FHIR takes a different approach. FHIR resources do not attempt to represent all data elements that
could possibly be used in a space. Instead, only those data elements that are expected to be used by
"most" implementations within the scope of the resource are considered part of the core resource definition.
(This is sometimes referred to as "The 80% rule" - if approximately 80% of systems maintaining the resource
will support the element, then it is part of core). All other data elements are expected to be handled
using extensions. <a href="profile.html">Profiles</a> are used both to constrain resources and to define
extensions appropriate to narrower implementation spaces. Wire format interoperability is retained across
all profiles on a given resource.</p>
<p>
<b>Context conduction:</b> When conveying healthcare information between humans, much data can be inferred
from context. For example, if a report has an "author" noted on a cover page, it is generally inferred that
each statement within the report is authored by that same person. This inference grows more challenging when
data needs to be analyzed by computers, whether for query, decision support or other analysis. Thus far, the
HL7 V3 methodology has provided three distinct mechanisms to allow data models to define how "context" should
propagate through models, making explicit for computers what humans would normally understand intuitively.
FHIR has chosen a different path. In FHIR, no context is conducted - everything is explicit. If a report
about a patient contains 100 observations all about that same patient, each observation will include a reference
to the patient. However, this is relatively painless because it's only a reference - an id and possibly a short
display value. One of the benefits of this approach is that each resource can be safely consumed and examined
without concern for the context in which that resource was communicated. The meaning of each resource instance
is fully self-contained.
</p>
<p>
<b>Null flavors:</b> In healthcare, it's quite common for data to be unknown, unavailable, have an exceptional
value or otherwise fall outside the bounds of a "normal" value. To deal with this, V3 introduced the
concept of "null flavor" on almost every attribute and data type property in its models. These coded null flavors
could be sent in place of or in addition to the data that would typically be sent for the attribute, association or
data type property. Examples include the ideas of "Unknown", "Not asked", "Positive infinity", "Trace amount",
"Masked", "Other", etc. Unless an element was explicitly marked as "mandatory" - meaning no null flavors were
permitted, these null flavors could appear absolutely anywhere.
</p>
<p>
FHIR approached the problem differently. Null flavors are only introduced in the core specification in those
circumstances where it is expected that most systems will need them. Where needed, the flavors are constrained
to those relevant to that element.
</p>
<h3>V3 Interoperability Considerations</h3>
<a name="V3-interoperability"> </a>
<p>
<b>Using RIM mappings:</b> Most resource elements and data type properties include mappings to the RIM. These
mappings serve two purposes. They help to define FHIR semantics in terms of HL7's reference models, helping to
ensure that the Work Groups defining the data elements have a good and consistent understanding of the meaning of
every element. They also provide guidance for implementers of version 3 specifications that may be looking to migrate
to or map between version 3 and FHIR. However, for the latter use it's important to understand some limitations on
the RIM mappings. The RIM is a language which allows the same "idea" to be conveyed in a number of different ways
with varying granularity and expressiveness. Thus it's entirely possible for a RIM element to map to a core FHIR
element even though its RIM representation is somewhat different than described in the mapping. In addition, not all
V3 models adhere to good modeling practices, so some data elements that would appear to map to a FHIR element might
not map if the information has not been well represented. Therefore RIM mappings should be taken as a guide,
not an absolute, and mappings must be done in the context of the V3 specification being mapped. (Also
see <a href="#V3-abstractModels">Abstract models</a> below.)
</p>
<p>
<b>V3 extensions:</b> While the core of the V3 methodology is "design by constraint", it still makes provision
for the use of extensions - either in a foreign namespace or denoted by a special attribute. When converting
between V3 and FHIR, the use of such extensions will need to be taken into account. As a rule, most V3 extensions
will map to FHIR extensions, as the V3 design-by-constraint principle suggests that anything that would qualify as
"core" in FHIR would already have been part of the base V3 specification.
</p>
<p>
<b>Abstract models:</b><a name="V3-abstractModels"> </a>As previously noted, many of the V3 models created at the
HL7 International level are quite abstract. As a result, the models can be used to say a wide variety of things,
often in a wide variety of different ways. This makes defining a mapping between those specifications and FHIR
(or any other specification) quite tricky. For practical V3 <-> FHIR interoperability, mappings will need to be
created at the level of message specifications, implementation guides and/or templates that are more concrete and
closer to the implementation level. For example, mapping all of CDA to FHIR would be impossible given the expressive
capability of the right-hand-side of the CDA model. However, mapping the Consolidated CDA (CCDA) templates to FHIR
is quite possible.
</p>
<p>
<b>Context conduction:</b> As discussed above, HL7 V3 models rely on context conduction - either implicitly or
explicitly controlled. When converting to FHIR, the context will need to be propagated into each resource.
</p>
<p>
<b>Update mode:</b> In HL7 V3 instances, updates are generally handled in snapshot mode, similar to the FHIR
approach - if any information changes, the entire record is sent, including the modified data elements. However,
the V3 methodology does support the introduction of an "updateMode" property to allow only the changes to be sent
for all or part of an instance. Each element repetition is flagged with an updateMode to indicate whether the
element is to be added, removed, updated, etc. Additional updateModes allow further control over updates. As
with the <a href="comparison-v2.html#V2-updateMode">V2 discussion</a> above, implementers will need to generate a full snapshot of
each resource or will need to introduce modifier extensions to allow similar behavior to V3.
</p>
<p>
<b>Additional considerations:</b> Most of the implementation considerations for interoperating between FHIR and
V2 also hold with V3. Specifically: <a href="comparison-v2.html#V2-extensions">Extensions</a>, <a href="comparison-v2.html#V2-contained">Independent vs.
Contained resources</a>, <a href="comparison-v2.html#V2-identification">Resource Identification</a>, <a href="comparison-v2.html#V2-merging">Merging
references and resources</a> and <a href="comparison-v2.html#V2-humanReadable">Generating human-readable content</a>.
</p>
</div>
[%file newfooter%]
</body>
</html>