IHE PCD F2F 2015-04-30 San Diego, America’s Finest City OBX-4 Sub-Id IHE PCD F2F 2015-04-30 San Diego, America’s Finest City

OBX-4 in general HL7 usage “Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR…”. Use of a dotted notation is mentioned, but the IHE PCD usage is IHE PCD’s own creation.

OBX-4 in IHE PCD Technical Framework Must uniquely identify each OBX Associates each observation (OBX) with its instrumental source in accordance with the IEEE 11073-10201 Domain Information Model. Accommodates deeper identification of observations: if you have multiple sources for the same measurements and you don’t have OBX-4, you can’t identify more than one. Makes traceability of observations feasible.

Containment Hierarchy 1.2.1.1 MDS VMD Channel Metric

TF V2 excerpts on OBX-4 From Annex A OBX-4 is used to express the containment level of a particular item expressed in OBX-3. This is done by defining the nodes of the <MDS> <VMD> <CHAN> <METRIC> hierarchy of the containment tree as a set of ordinal numbers expressed in a dotted notation such that each OBX-3 is expressed unambiguously in terms of its containment as defined by OBX-4. This may be supplemented by a further level or levels to distinguish attributes or other subordinate structures as may be specified in particular PCD profiles.

TF Excerpts, contd. More from Annex A NOTE: The ordinal numbers in an OBX-4 are not normative for a given parameter (identified in OBX-3) and may vary between implementations. Each OBX-4 Sub-Id must be unique within a given containment and message but the numbers and mappings may change between messages.

The flat option It is possible to model your device as an MDS with no substructure – that is, the metrics aren’t grouped into channels, or VMDs. You can represent a “not applicable” level by putting in a zero. Continua uses this to skip VMD and channel.

Device component segments Don’t report a conventional clinical observation, but rather say something about an MDS, VMD, Channel, or Metric Possible descendants – attributes like Production Spec, battery state, version ids of software/firmware How do you recognize one? Its refid ends with _MDS, _VMD, etc. Also, its OBX-4 has trailing zeros for levels that it isn’t “about”, for example an OBX-4 of 1.0.0.0 is about an MDS.

MSH|^~\&|PAT_DEVICE_PHILIPS_C|Philips|||20150122183359||ORU^R01^ORU_R01| HP0122183359177QQ000CND119C0WS75|P|2.6|||AL|NE||8859/1|EN^English^ISO639|| IHE_PCD_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.1.1^ISO PID|||HO2009001^^^^MR||Hon^Albert^""^^^^L||19610101|M PV1||I|HO Surgery^OR^1 OBR|1||201512218335601|69965^MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS^MDC||| 20150122183356 OBX|1||69965^MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS^MDC|1.0.0.0|||||||X|||||||e86c094f- f751-4acf-92b2-38f11c1f6f57-Device OBX|2||70686^MDC_DEV_PRESS_BLD_NONINV_VMD^MDC|1.1.0.0|||||||X|||||||0600dc750001 OBX|3||70675^MDC_DEV_PULS_CHAN^MDC|1.1.1.0|||||||X OBX|4|NM|147842^MDC_ECG_CARD_BEAT_RATE^MDC|1.2.1.1|80| 264864^MDC_DIM_BEAT_PER_MIN^MDC|50-120||||X OBX|5|NM|147232^MDC_ECG_TIME_PD_QT_GL^MDC|1.2.1.14|352| 264338^MDC_DIM_MILLI_SEC^MDC|||||X OBX|6|NM|147236^MDC_ECG_TIME_PD_QTc^MDC|1.2.1.15|406| 264338^MDC_DIM_MILLI_SEC^MDC|<500||||X OBX|7|NM|151562^MDC_RESP_RATE^MDC|1.2.1.19|30| 264928^MDC_DIM_RESP_PER_MIN^MDC|8-45||||X OBX|8|ST|184327^MDC_ECG_STAT_RHY^MDC|1.2.1.21|MDC_ECG_SINUS_RHY||||||X OBX|9||69642^MDC_DEV_ANALY_SAT_O2_VMD^MDC|1.3.0.0|||||||X|||||||0600dc750001 OBX|10||70771^MDC_DEV_ANALY_PERF_REL_CHAN^MDC|1.3.1.0|||||||X OBX|11|NM|150456^MDC_PULS_OXIM_SAT_O2^MDC|1.3.1.1|99| 262688^MDC_DIM_PERCENT^MDC|90-100||||X OBX|12|NM|150448^MDC_PULS_OXIM_PERF_REL^MDC|1.3.1.3|3.9| 262656^MDC_DIM_DIMLESS^MDC|||||X

Segment order “Dictionary order”: One MDS, followed by each contained VMD, followed by its contained metrics, followed by next MDS and so forth. TF specifies “dictionary order” as a SHOULD, not a SHALL. [Question: is that OK?]

OBX-4 puzzles What can be encompassed in one message: can a PCD-01 message (delimited by control characters in HL7 minimal lower-level protocol) contain observations from more than one Medical Device System? [Request from Epic: No][Request from one Philips product team: Yes] One MDS can be contained by another MDS. Do we want to find a way to represent this? Message-size optimization: should we consider some kind of expectation that a receiving system can support persisting rarely-changing (device component) information information [cf. “Key Frame” idea]. Omitting a previously sent OBX-4 value means you can rely on the persisted value.

OBX-4 puzzles, contd. Would it be permissible to have normative semantics for particular values of OBX-4 components (forbidden by current rules).

Questions / comments

Basic rules Each device sub-entity has a unique integer identifier so that each OBX-4 of an ordinary observation points uniquely to its source. This means an OBX points to all its ancestors. Integers can be any non-negative value representable in sixteen bit unsigned integer. That is, for example, if you have four VMDs, they don’t need to be numbered 1, 2, 3, 4.