-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathCP-PCD-071-01.txt
More file actions
206 lines (151 loc) · 9.89 KB
/
CP-PCD-071-01.txt
File metadata and controls
206 lines (151 loc) · 9.89 KB
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
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
IHE Change Proposal
Tracking information:
|IHE Domain |Patient Care Devices |
|Change Proposal ID: |CP-PCD-070-0 |
|Change Proposal Status: |Submitted |
|Date of last update: |8-12-2011 |
|Person assigned: |John Rhoads |
Change Proposal Summary information:
|Example Text Change |
|Submitter’s Name(s) and e-mail |Stephen Swanson (sswanson@sjm.com) |
|address(es): |Gene Hageman |
| |(gene.hageman@medtronic.com) |
| |Alexander Kraus |
| |(alexander.kraus@biotronik.com) |
| |Ken Hoyme (ken.hoyme@bsci.com) |
|Submission Date: |June 13, 2012 |
|Integration Profile(s) affected: |Implantable Device – Cardiac – |
| |Observation |
|Actor(s) affected: |None |
|IHE Technical Framework or |IHE Patient Care Device (PCD) |
|Supplement modified: |Technical Framework; Volume 2; |
| |Revision 1.0; August 12, 2011 |
|Volume(s) and Section(s) affected: |Volume 2 (PCD TF-2); Section |
| |3.9.4.1.2.5 |
|Rationale for Change: |
|There was confusion on what values should be contained in the OBX-5 fields|
|when the Value Type (OBX-2) is Coded With Exceptions (CWE). The Change |
|Proposal clarifies the intended use of this field. |
Proposed Changes:
Replace the text defining the use of OBX-5with 3 with the following:
OBX-3.1 Observation Identifier, Identifier shall be <Code> [numeric] as
defined in Annex C.3 ‘Expanded Terms’ of IEEE 11073-10103 (see 3.9.3
Referenced Standards).
OBX-3.2 Observation Identifier, shall be <Reference ID> as defined in
Annex C.3 ‘Expanded Terms’ in IEEE 11073-10103 (see 3.9.3 Referenced
Standards)
OBX-3.3 Observation Identifier, Name of Coding System shall be MDC to
reference the group of medical device communication standards (IEEE 11073-
xxxxx)
Replace the text defining the use of OBX-5 with the following:
OBX-5 Observation Value – This is the actual value of the observation.
If OBX-2 is of type CWE then
OBX-5.1 shall be <Code> [numeric] as defined in Annex D.3 ‘enumerations’
or Annex E.3 ‘vendor enumerations’ of IEEE 11073-10103 (see 3.9.3
Referenced Standards) .
OBX-5.2 shall be <Enumerator Identifier>_<EnumerationCode [mnemonic]> as
defined in Annex D.3 ‘enumerations’ or Annex E.3 ‘vendor enumerations’ in
IEEE 11073-10103 (see 3.9.3 Referenced Standards)
OBX-5.3 shall be MDC to reference the group of medical device
communication standards (IEEE 11073-xxxxx)
OBX-5.9 can contain the according Display Name as defined in Annex D.3
‘enumerations’ or Annex E.3 ‘vendor enumerations’ of IEEE 11073-10103
(see 3.9.3 Referenced Standard) or an equivalent (maybe more compact)
localized display name. If the vendor has implemented vendor-specific
extensions (per IEEE 11073-10103 Sections 8 and A.4) than OBX-5.9 is
required. This display name should only be used by the receiving system
as a reference or if the Identifier in OBX-5.1 is unknown to the receiver
(e.g. for proprietary vendor content). Generation and localization of
display names in the receiving system shall always be preferred.
OBX-5 Observation Value – This is the actual value of the observation.
If OBX-2 is of type CWE then
OBX-5.1 shall be an enumeration code [mnemonic] as defined in Annex D.3
‘enumerations’ or Annex E.3 ‘vendor enumerations’ of IEEE 11073-10103
version 1.05.02 (10/04/2011) and
OBX-5.2 can contain the according display name as defined in Annex D.3
‘enumerations’ or Annex E.3 ‘vendor enumerations’ of IEEE 11073-10103
version 1.05.02 (10/04/2011) or an equivalent display name in another
language.
IHE Change Proposal
Tracking information:
|IHE Domain |Patient Care Devices |
|Change Proposal ID: |CP-DOM-xxx (assigned by Domain |
| |Technical Committee) |
|Change Proposal Status: |Submitted |
|Date of last update: |8-12-2011 |
|Person assigned: |(assigned by Domain Technical |
| |Committee) |
Change Proposal Summary information:
|Editorial Update – Implantable, Manufacturer |
|Submitter’s Name(s) and e-mail |Stephen Swanson (sswanson@sjm.com) |
|address(es): |Gene Hageman |
| |(gene.hageman@medtronic.com) |
| |Alexander Kraus |
| |(alexander.kraus@biotronik.com) |
| |Ken Hoyme (ken.hoyme@bsci.com) |
|Submission Date: |May 30, 2012 |
|Integration Profile(s) affected: |Implantable Device – Cardiac – |
| |Observation |
|Actor(s) affected: |None |
|IHE Technical Framework or |IHE Patient Care Device (PCD) |
|Supplement modified: |Technical Framework; Volume 2; |
| |Revision 1.0; August 12, 2011 |
|Volume(s) and Section(s) affected: |Volume 2 (PCD TF-2); Section |
| |3.9.4.1.2.7 |
|Rationale for Change: |
|We need a means of associating a specific PDF in the message with an |
|episode group, if that PDF contains only the captured waveform for that |
|episode. |
Proposed Changes:
Add the Observation Sub-ID row to Table 3.9.4.1.2.7-1: OBX Segment as
follows:
Name |Seq |DT |Len |Opt |Rep |Min |Max |Tbl |Fixed Value |Ex Val | | Set
ID - OBX | 1 | SI | 4 | R | False | 0 | 1 | | | | | Value Type
| 2 | ID | 2 | R | False | 0 | 1 | 0125 | Y | ED | | Observation
Identifier | 3 | CWE | 478 | R | False | 1 | 1 | | | | |
identifier |1 | ST | 20 | R | | 1 | 1 | | Y | 18750-0 | | Text
|2 | ST | 199 | R | | 0 | 1 | | Y |Cardiac Electrophysiology Report
| | name of coding system |3 | ID | 20 | R | | 0 | 1 | 0396 | Y
| LN | | Observation Sub-ID | 4 | ST | 20 | RE | False | 0 | 1 |
| | 1 | | Observation Value | 5 | ED | 99999 | R | True | 0 | * |
| | Encapsulated PDF | | source application |1 | ST | 10 | RE | | 1
| 1 | |Y | Application | | type of data |2 | ST | 10 | RE | | 1 |
1 | |Y | PDF | | Encoding |4 | ST | 10 | RE | | 1 | 1 | |Y | Base64
| | Data |5 | ED | * | RE | | 1 | 1 | |Y | Encapsulated and Base64
binary encoded PDF File | | Observation Result Status | 11 | ID | 1 |
R | False | 1 | 1 | 0085 | | | | Date/Time of the Observation | 14
| TS | 26 | RE | False | 0 | 1 | | | | | Time |1 | DTM |
24 | R | | 1 | 1 | | | 20040328134623.1234+0300 | |
Replace the text describing OBX field usage following Table 3.9.4.1.2.7-1
as follows:
OBX-2 If sending an encapsulated PDF the value will be ED. If referencing
an external report the value will be RP.
OBX-3 Value is a report ID from the LOINC coding system, and will be set to
18750-0^Cardiac Electrophysiology Report^LN.
OBX-4 If a value is provided here the embedded PDF will contain data
related to a specific episode or EGM being referenced via grouping to other
episode related data elements having the same Sub-ID in OBX-4 inside this
message.
OBX-5 If referencing an external document the Observation Value will
contain a reference pointer to the external document.
OBX-5.1 If sending an encapsulated PDF the Type of Data component will have
the value “Application”
OBX-5.2 If sending an encapsulated PDF the Data Subtype component will have
the value “PDF”.
OBX-5.3 Not used for an encapsulated PDF.
OBX-5.3 will be empty.
OBX-5.4 If sending an encapsulated PDF the Encoding component will have the
value “Base64”.
OBX-5.5 If sending an encapsulated PDF the Data component contains the
encapsulated Base64-encoded PDF/A document in accordance with ISO 19005-1.
Notes: 1. An actor participating in this transaction must support
encapsulated data with a length beyond the nominal 65536 byte
limit of the OBX-5.
2. The base64 encoded stream must not include CR/LF characters, which
are forbidden within HL7 field text streams. Breaking a base64
encoded stream into lines of 76 characters or less is used for
email in accordance with RFC 822, but is not applicable to
encapsulated data in HL7.
The attached PDF or externally referenced report will contain in
its content the device ID, patient ID and name if known, and the
dates of the procedure and document.