forked from hl7-fhir/fhir-dstu1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathmanaging.html
133 lines (115 loc) · 7.16 KB
/
managing.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
<!DOCTYPE HTML>
<!--
However
applications may need to replace Service Root URLs. This may be needed
as application URLs may change or in uses of FHIR within internal
eco-systems, local configuration may dictate that the provider of
a resource is different to that claimed by any particular provider
or consumer.
-->
<!--
A person or animal receiving care at multiple organizations will therefore have its information present in multiple Patient Resources.
What are the explicit mechanisms that should be used to synchronize them? This dynamic behavior, is not covered at any depth (that I can see), except to suggest that a message that emulates a V2 or V3 event be employed. The entire notion of dynamic behavior of a model employing resources is not covered well. If one happens to employ RESTful services (not required AFAICS) then, yes, we have CRUD verb mappings on resources, but no real discussion of the dynamic behavior of multiple resources involved in transactions/events, except to fall back on V2 and V3. Am I missing something?
-->
[%settitle Managing Resource Identity%]
<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="identity"></a>
<h2>Managing Resource Identity</h2>
<p>
Each resource has a known identity, which is a URL. The identity is not stored
inside the resource, but must be tracked by systems handling resources. For
RESTful systems, the resource identity is the same as the URL by which it is found.
When a resource is packaged in a <a href="extras.html#bundle">bundle</a> (e.g. for
<a href="messaging.html">messages</a> or <a href="documents.html">documents</a>, or
<a href="services.html">exchanged in a service </a>, the id is included along
with the resource. When systems using FHIR resources are deployed in an implementation
context where there is more than two systems exchanging resources, the way that
resources are identified with URLs needs to be managed carefully.
</p>
<p>
Note that many resources also have an identifier element, which may repeat. This identifier
is a logical identifier for the concept that the resource describes, and is different to
the identity discussed in this section, which is the literal identity of the resource.
Note that there are often multiple resource instances that describe the same concept
across multiple systems, e.g. each application keeps it's own copy of the patient
information in a <a href="patient.html">Patient</a> resource. This can even
exist within a single system, such as in the case of <a href="patient.html#links">patient duplicates</a>).
</p>
<a name="using"> </a>
<h3>Using Resources</h3>
<p>
Resources are used in a variety of circumstances. Generally, these can be categorized into 3 different scenarios:
</p>
<ol>
<li><b>Closed Trading System</b>: the resources are only ever exchanged between fixed systems in a tightly controlled
community, such as a single EHR system with multiple modules. There is only one master server for each resource type, and resources are managed
by that server. In this context, the <a href="resources.html#metadata">logical id</a> of a resource is sufficient
to fully identify the resource</li>
<li><b>Open system</b>: there are many peer servers, each managing a set of resources of different types.
In order to identify resources, a full URL reference to the origin server is required. The grand example of
an open system is the World Wide Web</li>
<li><b>Partially closed, inter-linked systems</b>: a mixture of both closed and open systems - trading communities that are tightly managed, but have managed
interactions with other closed trading systems, or with the world-wide web, or both. In fact,
this combination appears to be the most likely scenario for current real-world healthcare business solutions</li>
</ol>
<p>
These combinations are why either relative (logical) or absolute references are allowed, and why
a logical id is always required, in order to enable seamless exchange amongst partially closed trading systems.
</p>
<a name="distributed"> </a>
<h3>Copying Resources and Re-identification</h3>
<p>
When resources are exchanged between systems, they may need to be re-identified (i.e. assigned a new resource).
When a resource is re-identified, nothing in the resource changes, but any references that point to the resource
need to be updated. Whether re-identification is required or not depends on the context, as does how resource
references are updated.
</p>
<p>
The normal case is that a client/receiving system accepts the server/sender's identification of a resource
at face value, whether it is a relative or absolute reference. When the client/receiver wants to follow
resource references, they are done using the server id (typically either by http calls or locating them
in a <a href="extras.html#bundle">bundle</a>), but other arrangements are possible. In such cases, there is no need for re-identification.
</p>
<p>
Another scenario is for a client to retrieve a resource from a server, and make its own local persistent
copy. If the local resource has a life-cycle of its own (i.e. it is not just a cached resource), then it
needs to have its own identity; i.e. the resource must be re-identified. The simplest case is that the
client only is keeping local copies of resources from a single server. In these cases, the client can
simply replace the root URL and keep the logical id of the resource the same. In fact, if the server
is using relative references, then this change doesn't involve any actual changes to the resources, it only
means a re-interpretation of the references.
</p>
<p>
In some cases, however, the client may deal with multiple servers. In this case, the logical id of the
resource is not guaranteed to be unique (unless all resources have a UUID for the logical id, which is
allowed but not required). When the client cannot be sure that the resource identities are unique, it
will have to re-identify the resources. In practice this means that the client needs to keep some kind of
identity translation table, and update references to the resources it has copied locally when other resources
are received.
</p>
<p>
The case of a gateway system that migrates resources from one ecosystem to another is very similar.
In some limited cases, it can leave the logical id of the resources unchanged as resources are copied
from one closed system to another. However in more complicated cases, it will have to modify the
resource references as resources pass across the gateway.
</p>
<a name="dstu"> </a>
<blockquote>
<p>
DSTU Note: In it's current form, FHIR allows various convenient implementer practices around
resource identification that make integration across eco-system boundaries more difficult.
In particular, either only allowing UUIDs for logical IDs or only allowing absolute references
would make the boundary management problem easier but remove useful and convenient flexibility for
other uses of FHIR. Feedback on this will be welcome during trial use.
</p>
</blockquote>
</div>
[%file newfooter%]
</body>
</html>