Get documents about "RCH.1g
Document Sample
Rosetta Containment Hierarchy
Paul Schluter 2009-09-09
1. Introduction
This whitepaper proposes a simple yet rigorous representation of the observation hierarchy that can be used for IHE
DEC PCD-01 message modeling, conformance testing and documentation. It is intended to support the PCD-01
representation of PCD clinical care devices that use the IEEE 11073-10101 nomenclature and multi-level
MDS.VMD.CHAN.METRIC „containment hierarchy‟ and PHD personal health devices that use the IEEE 11073-
20601 and -104XX device specializations that conform to a flatter hierarchy..
The Rosetta Containment Hierarchy (RCH) specifies the following information:
The allowed hierarchies of OBX-3 observation identifiers, expressed as nodes of a „containment tree‟.
PCD and PHD devices are separately modeled, reflecting their somewhat different top-level data models.
Although their definitions can be developed and maintained as separate files or databases, they can be
combined at any time, since both sets of files conform to the same overarching framework.
Individual devices are modeled, starting with the top-level MDC_DEV_*_MDS OBX for PCD clinical devices
and top-level MDC_DEV_SPEC_PROFILE_* OBX for a PHD personal health devices.
The cardinality of each node in the containment tree is specified.
The visibility of VMD or CHAN OBX „wrapper‟ nodes is also specified. For example, an infusion pump may
have multiple drug source channels and a single fluid delivery channel that defines groups of METRICs that
must be identified by explicit OBX wrapper that is present in the message whereas other METRICs need only
belong to implicit groups based their dotted number in OBX-4. Otherwise, the default anonymous case is
assumed for METRIC observation identifiers such as MDC_ECG_HEART_RATE that can be sent as stand-
alone terms without an explicit CHAN OBX wrapper (even though it may nominally be assigned to a VMD or
CHAN).
The Rosetta containment hierarchy is specified by an Excel table described in the following pages and is used with
the companion „Harmonized Rosetta‟ table (hRTM) that specifies the units-of-measure, enumerations, measurement
site and other information for each observation identifier REFID. Together, both files rigorously define the device
containment hierarchy and value constraints that can be used for modeling, conformance testing and documentation.
The information contained in the RCH and hRTM tables can be used in a variety of conformance testing
frameworks. For example, the RCH can be transformed into a W3C or RELAX-NG Schema that can be used to
validate the sequence of OBX-3 REFIDs and their OBX-4 nesting depths along with additional co-constraint testing
using the hRTM.
In addition to enabling conformance testing of individual devices as sources of physiologic information, the RCH
also enables the theoretical assessment of whether combinations of devices can fulfill specific clinical use cases by
specifying the cardinality of the receiving applications. Although this is not an immediate objective of the RCH
effort, expressing the RCH rules using a simple tabular format facilitates the addition of this capability later on.
2. Observation Hierarchy - Device-specific and General Attributes
An example of the Rosetta Containment Hierarchy table for a subset of PCD and PHD devices is shown in Table 1.
The REFID column lists the REFIDs and indicates their MDS.VMD.CHAN.METRIC hierarchical depth by the
number of dots that preface the REFID. The OBXV column specifies the „visibility‟ of the OBX (explicit, implicit
or anonymous, defined later) and the SC0 column indicates the „source cardinality‟ to which all devices must
comply. Additional cardinality columns indicating stricter specificity can be added later to describe the capabilities
of individual vendor devices and requirements to fulfill specific clinical use-cases.
RCH.1g.doc -1- 2009-09-09T17
Table 1: Observation Hierarchy for selected PCD (X73-classic) and PHD (X73_PH) Devices 1
REFID OBXV SC0 OBX-4 2 Comments
MDC_DEV_PUMP_INFUS_MDS V 0..1 1 explicit MDS OBX required for PCD
. MDC_DEV_PUMP_INFUS_VMD V 1..1 1.1 explicit VMD OBX required for PCD
. . MDC_DEV_PUMP_INFUS_CHAN_SOURCE V 0..* 1.1.1 explicit infusion source CHAN required if sent
. . . MDC_FLOW_FLUID_PUMP 1..1 1.1.1.1
. . . MDC_VOL_FLUID_TBI_REMAIN 0..1 1.1.1.2
. . . MDC_TIME_PD_REMAIN 0..1 1.1.1.3
. . . MDC_FLOW_DRUG_DELIV 1..1 1.1.1.4
. . . MDC_VOL_FLUID_DELIV 1..1 1.1.1.5
. . . MDC_DRUG_NAME_TYPE 0..1 1.1.1.6
. . MDC_DEV_PUMP_INFUS_CHAN_DELIVERY V 1..1 1.1.2 explicit infusion source CHAN required
. . . MDC_FLOW_FLUID_PUMP 1..1 1.1.2.1
. . . MDC_VOL_INFUS_ACTUAL_TOTAL 1..1 1.1.2.2
. . . MDC_PUMP_STAT 1..1 1.1.2.3
. . . MDC_PUMP_MODE 1..1 1.1.2.4
MDC_DEV_SYS_PT_VENT_MDS V 0..1 2 explicit MDS OBX required for PCD
. MDC_DEV_SYS_PT_VENT_VMD V 0..1 2.1 explicit VMD OBX required for PCD
. . MDC_DEV_SYS_PT_VENT_CHAN 0..1 2.1.1 anonymous _VENT_CHAN need not be sent
. . . MDC_VENT_MODE 0..1 2.1.1.1
. . . MDC_RESP_RATE 0..1 2.1.1.2
. . . MDC_VOL_AWAY_TIDAL_EXP 0..1 2.1.1.3
. . . MDC_VENT_FLOW_INSP 0..1 2.1.1.4
. . . MDC_PRESS_AWAY_END_EXP_POS 0..1 2.1.1.5
. . . MDC_TIME_PD_INSP 0..1 2.1.1.6
. . . MDC_VENT_TIME_PD_PAUSE_INSP 0..1 2.1.1.7
. . . MDC_VENT_FLOW_SHAPE 0..1 2.1.1.8
. . . MDC_VENT_CONC_AWAY_O2 0..1 2.1.1.9
. MDC_DEV_ANALY_AWAY_MULTI_PARAM_VMD V 0..1 2.2
. . MDC_DEV_ANALY_PRESS_AWAY_CHAN 0..1 2.2.1
. . . MDC_PRESS_AWAY_INSP_PEAK 0..1 2.2.1.1
. . . MDC_PRESS_AWAY_MEAN 0..1 2.2.1.2
. . . MDC_PRESS_AWAY_END_EXP_POS 0..1 2.2.1.3
. . MDC_DEV_ANALY_FLOW_AWAY_CHAN 0..1 2.2.2
. . MDC_DEV_ANALY_VOL_AWAY_CHAN 0..1 2.2.3
. . . MDC_VOL_AWAY_TIDAL_EXP 0..1 2.2.3.1
. . . MDC_VOL_AWAY_MINUTE_EXP 0..1 2.2.3.2
. . MDC_DEV_ANALY_BREATH_PATTERN_CHAN 0..1 2.2.4
. . . MDC_RATIO_IE 0..1 2.2.4.1
. . . MDC_RATIO_INSP 0..1 2.2.4.2
. . . MDC_RATIO_EXP 0..1 2.2.4.3
. . . MDC_RESP_RATE 0..1 2.2.4.4
. . . MDC_TIME_PD_INSP 0..1 2.2.4.5
MDC_DEV_SPEC_PROFILE_TEMP V 0..1 3 SPEC_PROFILE_TEMP required for PHD
. MDC_DEV_METER_TEMP_VMD 1..1 3.0 specify VMD to facilitate uniform SPD query
. . . MDC_TEMP_BODY 1..1 3.0.0.1
MDC_DEV_SPEC_PROFILE_SCALE V 0..1 4 SPEC_PROFILE_SCALE required for PHD
. MDC_DEV_METER_SCALE_VMD 1..1 4.0 specify VMD to facilitate uniform SPD query3
. . . MDC_MASS_BODY_ACTUAL 1..1 4.0.0.1
. . . MDC_RATIO_MASS_BODY_LEN_SQ 0..1 4.0.0.1.1 why not leave at METRIC level?
. . . MDC_LEN_BODY_ACTUAL 0..1 4.0.0.2
Note: The device-specific METRICs shown above are reported after any general attributes listed in Table 2.
1
The infusor and ventilator containment is from PCD-01 Annex D and the scale is from the PHD2PCD mapping document.
2
These are example OBX-4 values and are dynamically created based on the content of the message.
3
I could not find a MDC_DEV_BODY_VMD or equivalent term for this type of body measurement.
RCH.1g.doc -2- 2009-09-09T17
The following „general attributes‟ can reported at the METRIC level for any MDS, VMD, CHAN and METRIC
level in the MDS, VMD.CHAN.METRIC hierarchy.4 , 5 These are reported before any of the device-specific
attributes shown in Table 1.6
Table 2: PCD Observation Hierarchy -- General MDS, VMD and CHAN Attributes for PCD Devices
GENERAL DEVICE OR SYSTEM, FROM PCD-01 ANNEX D OBXV SC0 OBX-4 7
MDC_DEV_ANY_MDS S.0.0.0
. MDC_ATTR_SYS_TYPE 0..1 S.0.0.1
. MDC_ATTR_VMS_MDS_STAT 0..1 S.0.0.2
. MDC_ATTR_ID_MODEL 1..1 S.0.0.3
. MDC_ATTR_SYS_ID 1..1 S.0.0.4
. MDC_ATTR_ID_SOFT 0..1 S.0.0.5
. MDC_DEV_ANY_VMD S.V.0.0
. . MDC_ATTR_ID_PROD_SPECN 0..1 S.V.0.1
. . MDC_ATTR_ID_BED_LABEL 0..1 S.V.0.2
. . MDC_ATTR_TIME_ABS 0..1 S.V.0.3
. . MDC_ATTR_POWER_STAT 0..1 S.V.0.4
. . MDC_ATTR_VAL_BATT_CHARGE 0..1 S.V.0.5
. . MDC_ATTR_VAL_BATT_REMAIN 0..1 S.V.0.6
. . MDC_ATTR_ALTITUDE 0..1 S.V.0.7
. . MDC_ATTR_LOCALE 0..1 S.V.0.8
. . MDC_DEV_ANY_CHAN S.V.C.0
. . . MDC_ATTR_ID_TYPE 0..1 S.V.C.1
. . . MDC_ATTR_CHAN_STAT 0..1 S.V.C.2
. . . MDC_ATTR_CHAN_NUM_PHYS 0..1 S.V.C.3
. . . MDC_ATTR_CHAN_NUM_LOGICAL 0..1 S.V.C.4
. . MDC_DEV_ANY_METRIC S.V.C.M
. . . MDC_ATTR_MSMT_STAT 0..1 S.V.C.M.1
Notes:
1. The „metrics‟ shown above are reported at „dot-level-4‟, before any METRICS specific to a CHAN are listed.
2. Although not currently defined in the PCD-01 Technical Framework, we will need to define a set of general
attributes for the METRIC level indicating measurement status (MDC_ATTR_MEAS_STAT) and other
information.8
4
There has been some debate regarding whether the general attributes should be reported at the METRIC or FACET level;
currently, the general (but not unanimous) preference is to use the METRIC level.
5
These are taken from PCD-01 Annex D for PCD devices; a separate set of general attributes will probably need to be defined
for PHD devices due to differences between the PCD and PHD top-level data models.
6
The „general attributes‟ can be viewed as a base type for each MDS, VMD, CHAN and METRIC observation that is extended
by the device-specific attributes listed in Table 1.
7
These are example OBX-4 values and are dynamically created based on the content of the message.
8
We may need the ability to indicate specific base types on a row-by-row basis in Table 1, since some METRIC observations
may have additional measurement status information whereas other METRICs such as configuration settings will not.
RCH.1g.doc -3- 2009-09-09T17
Putting it all together, Table 3 shows the infusion pump model from Table 1 combined with selected general
attributes from Table 2, with example dotted number values in OBX-4. The MDS, VMD and CHAN wrapper nodes
and selected general attributes are highlighted, and in the case of the CHAN, illustrates how the general attributes
are listed first.
Table 3: Example Infusion Pump with selected General Attributes (reported at METRIC level)
REFID OBX-4 9
MDC_DEV_PUMP_INFUS_MDS 1
. . . MDC_ATTR_SYS_TYPE 1.0.0.1
. . . MDC_ATTR_VMS_MDS_STAT 1.0.0.2
. . . MDC_ATTR_ID_MODEL 1.0.0.3
. . . MDC_ATTR_SYS_ID 1.0.0.4
. . . MDC_ATTR_ID_SOFT 1.0.0.5
. MDC_DEV_PUMP_INFUS_VMD 1.1
. . MDC_ATTR_ID_PROD_SPECN 1.1.0.1
. . MDC_ATTR_ID_BED_LABEL 1.1.0.2
. . MDC_DEV_PUMP_INFUS_CHAN_SOURCE 1.1.1
. . . MDC_ATTR_ID_TYPE 1.1.1.1
. . . MDC_ATTR_CHAN_STAT 1.1.1.2
. . . MDC_FLOW_FLUID_PUMP 1.1.1.3
. . . MDC_VOL_FLUID_TBI_REMAIN 1.1.1.4
. . . MDC_TIME_PD_REMAIN 1.1.1.5
. . . MDC_FLOW_DRUG_DELIV 1.1.1.6
. . . MDC_VOL_FLUID_DELIV 1.1.1.7
. . . MDC_DRUG_NAME_TYPE 1.1.1.8
. . MDC_DEV_PUMP_INFUS_CHAN_DELIVERY 1.1.2
. . . MDC_ATTR_ID_TYPE 1.1.2.1
. . . MDC_ATTR_CHAN_STAT 1.1.2.2
. . . MDC_FLOW_FLUID_PUMP 1.1.2.3
. . . MDC_VOL_INFUS_ACTUAL_TOTAL 1.1.2.4
. . . MDC_PUMP_STAT 1.1.2.5
. . . MDC_PUMP_MODE 1.1.2.6
Comment:
1. A „0‟ dotted number indicates a dummy level so that all METRICs are reported starting at dot-level-4.
This avoids using „1‟, „2‟, etc, which are reserved for real hierarchical dotted numbers.
2. We may need to update the existing PCD frameworks to solidify the use of the „0‟ convention.
9
These are example OBX-4 values and are dynamically created based on the content of the message.
RCH.1g.doc -4- 2009-09-09T17
3. MDS.VMD.CHAN.METRIC Containment Definitions
The MDS.VMD.CHAN.METRIC hierarchy is captured in a simple list, with each row containing the following
columns of information:
REFID Reference ID with MDS, VMD, CHAN, METRIC and FACET level indicated by zero, one, two, three
or four dots, respectively.
OBX OBX Visibility
V explicit MDS, VMD or CHAN OBX must be sent in the message and have a distinct dot number.
d implicit VMD or CHAN OBX need not be sent but a distinct dot number shall be used for its children.
(default) anonymous VMD or CHAN OBX need not be sent in message and dot number is zero.
SC0 Source Cardinality, the broadest range to which all devices must comply. 10
Table 1: MDS.VMD.CHAN.METRIC Hierarchy
LEVEL OBX Visibility and Cardinality
MDS 1 Medical Device System
MDS OBXV: MDS OBX shall be sent in message if the device or system is present.
„V‟ an explicit MDS or MDC_DEV_SPEC_PROFILE_* OBX shall be sent.
Cardinality: always 0..1 for devices and systems contained within an aggregated stream or record.
VMD 2 Virtual Medical Device
VMD OBXV: VMD OBX shall be sent if the VMD cannot be inferred from message.11, 12
„V‟ an explicit VMD OBX shall be sent if any metrics for this VMD are sent,
and a distinct dot number shall be used for this MDS.VMD.
„d‟ an explicit VMD OBX is not required, but a distinct dot number shall be used
for this implicit MDS.VMD and its descendent OBXs.
otherwise default: this VMD may be sent as anonymously as MDS.0.*.*
Cardinality: as specified {0..1, 0..*, 1..1, 1..*}
CHAN 3 Channel - Group
CHAN OBXV: CHAN OBX shall be sent to disambiguate like-named METRICs under the same VMD
and to identify waveform and annotation data when embedded in same message.
„V‟ an explicit CHAN OBX is required if any metrics for this CHAN are sent,
and a distinct dot number shall be used for this MDS.VMD.CHAN.
„d‟ an explicit CHAN OBX is not required, but a distinct dot number shall be used
for this implicit MDS.VMD.CHAN and its descendent OBXs.
otherwise default: this CHAN may be sent as an anonymously as MDS.VMD.0.*
Cardinality: as specified {0..1, 0..*, 1..1, 1..*}
METRIC 4 Observation
METRIC OBXV: always present if observation is reported (left blank).
Cardinality: as specified {0..1, 0..*, 1..1, 1..*}
FACET 5 Sub-observation
FACET OBXV: always present if sub-observation is reported (left blank).
Cardinality: as specified {0..1, 0..*, 1..1, 1..*}
...
10
Additional columns supporting alternative source and multiple receiver cardinalities can be added later.
11
Design options for X73-classic VMD OBX: Option 1 - the MDC_DEV_xxx_VMD OBX may be omitted if the parent MDS is
MDC_DEV_xxx_MDS; otherwise, MDC_DEV_xxx_VMD OBX must be sent. Option 2 - always send MDC_DEV_xxx_VMD.
Note that Option 2 provides a consistent MDC_DEV_xxx_VMD target for queries and doesn‟t significantly increase message
size. Option 3 - don‟t require a VMD node to be present, since in most cases it can be inferred from the message if the METRIC
node has a unique ancestral path to the top-level MDS or MDC_DEV_SPEC_PROFILE_* node. [Most of the current PCD-01
implementations use Option 3, since the vast majority of METRICs are stand-alone identifiers.]
12
The X73_PH series of standards does not use the VMD level; all of the information required to identify individual devices and
their functions is contained at the MDS level. The RCH will still specify a „dummy‟ VMD entry even though it need not be sent
to provide a consistent query target at the VMD level for both PHD as well as PCD devices.
RCH.1g.doc -5- 2009-09-09T17
4. Definitions
explicit OBX: An OBX that must be sent in message, e.g. an infusion DELIVERY or SOURCE channel.
implicit OBX: An OBX that need not be sent in message, but must be distinct OBX-4 dotted numeric value.
anonymous OBX: Catch-all for standalone METRIC terms that need not belong to a specific CHAN or VMD.
RTM: IHE PCD Rosetta Terminology Mapping Technical Framework
hRTM: The harmonized and normative list of REFIDs, units-of-measure, enumeration values,
measurement site locations and numeric code values, based on input provided by the RTM. 13
PCD-01 Foundational IHE DEC transaction for near real-time transmission of patient vital signs data.
SPD IHE DEC „Subscribe to Patient Data‟ profile (optional).
5. Essential RCH-RTM Requirements
1. The RCH and RTM shall be sufficiently comprehensive to generate valid and complete message instances for all
devices and at all VMD, CHAN, METRIC levels, including general attributes, at each level.
2. The RCH containment file shall be able to represent the OBX observation hierarchy for „classic‟ acute care
devices and X73_PH personal health devices using the same file format(s). 14
6. General Rules and Guidelines
1. A VMD and CHAN OBX may be declared „anonymous‟ only if the path from the METRIC to a given MDS is
unique. This rule guarantees that a receiver using the RCH table can fill in the missing VMD and/or CHAN
nodes. This rule can be evaluated for all devices in the RCH to verify that it is not violated.
2. A data source may generate sibling MDS, VMD, CHAN, METRIC and FACET nodes in any order and a data
receiver must accept them in any order.
3. As mentioned previously, all top-level MDS and MDC_DEV_SPEC_PROFILE_* OBXs shall be Visible.
4. As mentioned previously, all CHAN wrapper nodes for waveform and annotation data embedded in a PCD-01
message shall be Visible to facilitate selection of embedded waveform or annotation content.
13
The „hRTM‟ acronym replaces the earlier „HRosetta‟ in version „1f‟, based on a suggestion by Todd Cooper.
14
The classic and X73_PH could be selected based on the MDS and/or VMD identifier. Otherwise, we may need to allow an
arbitrary base type to be specified.
RCH.1g.doc -6- 2009-09-09T17
7. Topics for General Discussion
1. What defines the MDS.VMD.CHAN.METRIC node order? Is it (a) the order they appear in the message or
(b) dotted numeric order? The latter is more flexible but also harder to read (by humans) without sorting.
2. Although the general attributes for the MDS, VMD, CHAN and METRIC levels are generally the same for each
node level, are there any instances where the the general attribute cardinality would be different based on a
particular MDS.VMD.CHAN.METRIC ancestral „path‟? -- i.e. could the cardinalities for lower-level metrics be
different for an ECG versus an invasive pressure module? Although the RCH could support this, modeling and
validation would be somewhat more difficult.
3. There has been some discussion that we could simply map existing 11073 „attributes‟ to the .FACET. level
(and perhaps renaming it the .ATTR. level) but it remains to be proven that this will work for the different
encoding and modeling conventions that have been adopted in the X73_PH device specializations.
4. Although the RCH lists device-specific MDS identifiers, we would also allow a „hydra‟ or other aggregator MDS
to be used instead. In this case, the VMD would provide device and organ-system level grouping if sent in the
message, or it could be inferred from the lower-level METRIC identifiers. This would just be stated as a general
rule regarding the MDS level.
5. Likewise, we would also allow aggregated data streams consisting of one-or-more top-level MDS and
MDC_DEV_SPEC_PROFILE_* to be sent together, with the aggregator identified elsewhere in the HL7
message.
The remaining Annexes contain addtional detail and historical notes
and need not be reviewed at the present time.
RCH.1g.doc -7- 2009-09-09T17
Annex A: General guidelines and observations regarding OBX-4 and dotted numeric values
These notes were in earlier versions and summarize the key issues and goals for the RCH:
1. Every OBX reporting a MDS, VMD, CHAN or METRIC value must have a dotted numeric value in OBX-4
and the set of dotted value must be unique for each OBX in the message.
2. In general, an OBX need not be sent for every MDS, VMD and CHAN wrapper, but the dotted numeric value for
OBXs that are sent must be consistent with a message where explicit MDS, VMD, CHAN and METRIC OBXs
had been sent.
3. The dotted numeric value defines an OBX „observation hierarchy‟ so that measurements and the hardware and
software used to acquire and analyze the measurements can be unambiguously associated with each other. For
example, any device identification information provided at the MDS level applies to all the descendant VMD,
CHAN and METRIC nodes, unless overridden at a lower descendent level (e.g. module identifier at a lower
level provides a stronger hardware association than the top-level system identifier that hosts the module).
4. The vast majority of METRIC observation identifiers such as „MDC_ECG_HEART_RATE‟ do not require an
explicit VMD or CHAN since practically all METRIC identifiers are ‘context-free’ stand-alone terms.
This will be the default case for the RCH representation.
5. In contrast, additional VMD and CHAN context may be required to identify groups of certain METRICs. For
example, an infusion pump may have multiple drug source channels, each with a MDC_FLOW_DRUG_DELIV
and other per-channel metrics.15, 16 In this case, these METRICs are grouped by having the same dotted-numbers
for the VMD and/or CHAN levels. An explicit OBX for the VMD and/or CHAN is typically not required since
the association between related METRICs is established by the dotted numbers in OBX-4.17
It would be useful to capture these statements in a rigorous manner. The essential first step is to formally define the
complete MDS.VMD.CHAN.METRIC hierarchy for each device, including any cardinality constraints.
The second step is to apply the following rules that would allow any unnecessary MDS, VMD and CHAN ancestors
of a METRIC to be omitted, except in cases where they are absolutely required:
1a. The OBX containing the MDS is always required for PCD and PHD devices.
The MDC_DEV_xxx_MDS is used for PCD devices and the MDC_DEV_SPEC_PROFILE_xxx is used.
1b. The OBX containing the VMD is always required for a PCD device. A VMD should also be specified for a
PHD device but is not required to be present as an explicit OBX since it is not required in the original PHD
device (agent) data.
1c. The OBX containing the CHAN is only required if more than one CHAN is required to disambiguate multiple
like-named METRICs for the same VMD (relatively rare, and nonexistent for PHD devices).
1d. For most PHD devices and some PCD devices, we can define an „anonymous‟ CHAN REFID that basically
implies “I don‟t have a actual name for the CHAN or GROUP and it really doesn‟t matter.” For example,
MDC_ECG_HEART_RATE is a context-free term that does not need an explicit hierarchical context.
15
Actually, the per-drug channelization may be at the VMD rather than CHAN level for infusion pumps; this is currently being
discussed by the IHE PCD PIV working group. Whatever we decide, it needs to be captured in the RCH.
16
We may want to consider the use of the term .GROUP. as an alternative (but not replacing) .CHAN. to recognize that this level
can be used to group or associate related METRIC OBXs.
17
However, we should consider requiring an explicit VMD or CHAN OBX in cases where it is required, such as a infusion pump
CHANnel.
RCH.1g.doc -8- 2009-09-09T17
Annex B: Comparison of methods to capture and validate RCH hierarchy
These notes summarize several methods to capture and validate the RCH hierarchy:
A. Use NIST ICSGenerator representation, if it can meet the requirements expressed above
+ Designed to support PDU validation.
– Hard to see the containment hierarchy, since so much other information is included.
– Shows containment relationship but not cardinality and OBX „visibility‟ status.
B. Capture hierarchy in a W3C Schema
+ A W3C Schema can capture a normative hierarchy, including multiple content models.
+ Cardinality and content model groups easy to support.
– Supporting non-explicit and anonymous OBXs is possible with xs:appinfo element (awkward).
–– Additional OBX „visibility‟ information would not be easily visible in xs:appinfo element.
–– Difficult to support multiple sender and receiver cardinality constraints and requirements.
C. Capture hierarchy in an XML file
++ Can be easily expanded to include tabular columns regarding individual device capabilities, to allow
„theoretical‟ interoperability evaluation -- i.e. can a set of devices fulfill a particular clinical use case?
++ Vendors can easily specify „send‟ and „receive‟ cardinality to satisfy particular clinical use cases.
++ Normative hierarchy can be captured in an XML file.
+ Cardinalities easy to indicate (e.g. use minOccurs, maxOccurs, possibly with 0..1 as default).
+ Supporting non-explicit and anonymous OBX is easy.
– Content models more difficult (reinventing W3C Schema capability).
++ Can transform XML to W3C Schema (or more capable alternative schemas such as RELAX-NG).
D. Capture hierarchy in an Excel spreadsheet, convert XML for later processing
++ All information is easily accessible, visible and commentable to developers and clinicians.
++ Can be easily expanded to include tabular columns regarding individual device capabilities, to allow
„theoretical‟ interoperability evaluation -- i.e. can a set of devices fulfill a particular clinical use case?
++ Vendors can easily specify „send‟ and „receive‟ cardinality to satisfy particular clinical use cases.
++ Normative hierarchy can be captured in an XML file.
+ Cardinalities easy to indicate (e.g. use minOccurs, maxOccurs, possibly with 0..1 as default).
+ Supporting non-explicit and anonymous OBX is easy.
– Content models more difficult (reinventing W3C Schema capability).
++ Can transform XML to W3C Schema (or more capable alternative schemas such as RELAX-NG).
Recommendation:
Start with Option D using an Excel file that specifies MDS.VMD.CHAN.METRIC.FACET hierarchy and convert it
to an XML and/or schema later on. An XML file „naturally‟ expresses the observation hierarchy and facilitates
capture of ancillary information that can be transformed to use the best validation environment.18
The default content model would be ‘rng:interleave’ to allow 0..1, 0..*, 1..1, 1..* cardinality to be expressed for an
unordered set of nodes.19 Senders would be allowed to send nodes in any order and receivers would have to accept
them in any order.
18
For example, additional W3C Schema types can be created for METRIC nodes flagged as implicit or anonymous by the XSLT,
rather than by „manually‟ specifying them in the Schema.
19
Although W3C Schema content models (e.g. xs:sequence, xs:all, ... ) are will handle most cases, RELAX-NG‟s „interleave‟
model allows 0..1, 0..*, 1..1, 1..* to be expressed.
RCH.1g.doc -9- 2009-09-09T17
Annex C. Validation frameworks using W3C and RELAX-NG Schemas
One approach to validating the PCD-01 OBX observation sequence is to convert the sequence of REFIDs to an
XML file whose element tagnames are the REFIDs and node depth is based on OBX-4. Missing VMD and CHAN
nodes can be filled in using either (#1) generic „anonVMD‟ and „anonCHAN‟ nodes or (#2) specific nodes from the
RCH, with both methods producing a well-formed XML file.20
The XML file can then be validated against a W3C or RELAX-NG Schema that was created from the RCH file.
Since sibling MDS, VMD, CHAN, METRIC and FACET nodes are allowed in any order, unbounded W3C Schema
content models of the form (a|b|c)* may be required if the xs:all content model cannot be used due to its 0..1
cardinality limitation.21
If Method #1 was used to fill in missing VMD and CHAN nodes, then the „anonVMD‟ and „anonCHAN‟ nodes will
must be added to the schema to include any RCH nodes that could be could be sent anonymously. If Method #2 was
used, then the schema can be used „as is‟ for REFID observation hierarchy validation.
20
This is a restatement of „General Rule #1‟, where a singularly node path must exist for the constraints established by the MDS,
VMD, CHAN and METRIC nodes already present in the message.
21
In contrast, RELAX-NG supports unordered node sets where member cardinality can exceed one using the rng:interleave
content model. Despite its technical superiority, RELAX-NG has not enjoyed widespread adoption, a significant issue.
RCH.1g.doc - 10 - 2009-09-09T17
Annex D. Named ‘base type’ may be specified for any node [added 2009-09-07 to ‘1f’]
Although a single common „base type‟ for the MDS and VMD levels (originally proposed in «RCH.1e.doc») it is
also likely that we will need to define different „flavors‟ of base types at the lower CHAN and METRIC levels.
This will allow us to define a „WAV‟ base type for waveforms plus additional variants to handle specialized cases
(e.g. waveform snippet vs. QRS medians vs. signal-averaged evoked potentials). The „base type‟ representation will
make the entire RCH considerably easier to understand and maintain.
The BTYPE column is shown below. 22 The hierarchical depth of the data items added by the base type data would
be relative to the node that invoked the base type (in the example below, MDC_ATTR_TIME_PD_SAMP would be one
level below . . . MDC_DEV_SYS_PT_WVM_GROUP that invoked it, namely at . . . . MDC_ATTR_TIME_PD_SAMP .
[We could also consider supporting a list of base types in the BTYPE column.]
REFID BTYPE OBXV SC0 OBX-4 23 Comments
MDC-DEV-SYS_PT_MONITOR_MDS MDS 0..1 1
. MDC_DEV_SYS_PT_MONITOR_VMD VMD V 0..1 1.1 _ECG_VMD?
. . MDC_DEV_SYS_PT_ECG_CHAN CHAN 0..1 1.1.1
. . . MDC_HEART_RATE 1.1.1.1
. . . MDC_VENTRICULAR_RATE 1.1.1.2
. . . MDC_DEV_SYS_PT_WVM_GROUP WAV 1.1.1.3 use ..CHAN level instead?
. . . . MDC_ECG 1.1.1.3.9 Lead I
. . . . MDC_ECG 1.1.1.3.10 Lead II
. . MDC_DEV_SYS_PT_VENT_CHAN 1.1.2
. . . MDC_VENT_MODE 0..1 1.1.2.1
. . . MDC_RESP_RATE 0..1 1.1.2.2
. . . MDC_VOL_AWAY_TIDAL_EXP 0..1 1.1.2.3
. . . MDC_VENT_FLOW_INSP 0..1 1.1.2.4
. . . MDC_PRESS_AWAY_END_EXP_POS 0..1 1.1.2.5
. . . MDC_TIME_PD_INSP 0..1 1.1.2.6
. . . MDC_VENT_TIME_PD_PAUSE_INSP 0..1 1.1.2.7
. . . MDC_VENT_CONC_AWAY_O2 0..1 1.1.2.8
. . . MDC_DEV_SYS_PT_WVM_GROUP WAV 1.1.2.9 use ..CHAN level instead?
. . . . MDC_VENT_FLOW 1.1.2.9.5 Waveform
. . . . MDC_VENT_PRESSURE 1.1.2.9.6 Waveform
. . . . MDC_VENT_VOLUME 1.1.2.9.7
BTYPE (in the ‘base type’ worksheet) n/a OBXV SCO OBX-4
WAV
. MDC_ATTR_TIME_PD_SAMP 1..1 .1
. MDC_ATTR_FILTER_SPEC d 0..* .2 compare with FDA-HL7 aECG
. . MDC_CTL_VBL_ATTR_FILTER_CUTOFF_FREQ 0..1 .3
. . MDC_CTL_VBL_ATTR_FILTER_ORDER 0..1 .4
. . MDC_ATTR_FILTER_LABEL_STRING 0..1 .5
. MDC_ATTR_SPD_SWEEP_DEFAULT 0..1 .6
. MDC_ATTR_GRID_VIS 0..1 .7
. MDC_ATTR_NU_MSMT_RES 0..1 .8
22
From «WCM_Discussion_Topics_2009-09-03.pss.doc» as an extension to Ken Fuchs‟ original WCM document.
Several of the MDC REFIDs were „made up‟ for this example.
23
These are example OBX-4 values and are dynamically created based on the content of the message.
RCH.1g.doc - 11 - 2009-09-09T17
Annex E. Example mapping of a X73_PH thermometer to PCD-01 [added 2009-09-09 to ‘1g’]
During the 2009-09-09 RTM tcon it was asked how the RCH table would be used to generate and/or validate a
PCD-01 HL7 V2 message. The „thermometer containment tree‟ from the Continua WAN Payload Mapping
whitepaper illustrates the basic process.24
The RCH containment tree from that document is shown below. The final normative RCH tree will include the
cardinality, visibility, base type and other columns. 25
Table E.1 Thermometer containment tree
REFID Description
MDC_DEV_SPEC_PROFILE_TEMP Thermometer MDS
... MDC_TEMP_BODY Body Temperature
From the perspective of a message conformance testing framework, the allowed message observation hierarchies are
specified by the RCH down to the FACET REFID level (OBX-3) and any co-constraints such as units-of-measure
(OBX-6) and measurement sites (OBX-20) are specified by the hRTM. The HL7 datatype (OBX-2) is specified by
the RCH (or hRTM) and the value type and enumerations (OBX-5) are specified by the hRTM. Finally, the „dotted
number‟ in OBX-4 would be based on the dotted prefix length and visibility rules specified by the RCH.
Table E.2 PCD-01 HL7 V2 Thermometer Encoding - Part 1
Description OBX-2 OBX-3 OBX-4 OBX-5
Thermometer MDS 528392^MDC_DEV_SPEC_PROFILE_TEMP^MDC 1
Body Temperature NM 150364^MDC_TEMP_BODY^MDC 1.0.0.1 98.6
Table E.3 PCD-01 HL7 V2 Thermometer Encoding - Part 2
Description OBX-6 OBX-18 OBX-20
Thermometer MDS SN12345^^\X0123456789ABCDEF\^EUI64
Body Temperature 268192^MDC_DIM_DEGC^MDC or 188452^MDC_TEMP_AXILLA^MDC or
266560^MDC_DIM_FAHR^MDC 150364^MDC_TEMP_BODY^MDC or
188428^MDC_TEMP_EAR^MDC or
188432^MDC_TEMP_FINGER^MDC or
188456^MDC_TEMP_GIT^MDC or
188424^MDC_TEMP_ORAL^MDC or
188420^MDC_TEMP_RECT^MDC or
188448^MDC_TEMP_TOE^MDC or
150392^MDC_TEMP_TYMP^MDC
Example E.1: PCD-01 HL7 V2 Message
OBX|1||528392^MDC_DEV_SPEC_PROFILE_TEMP^MDC|1||||||R|||20090224202200+0500||||SN12345^^\X0123456789ABCDEF\^EUI64
OBX|2|NM|150364^MDC_TEMP_BODY^MDC|1.1.1.1|98.6|266560^MDC_DIM_FAHR^MDC||||R|||20090715070707+0500||||||188424^MDC_TEMP_ORAL^MDC
24
Continua WAN Payload Mapping whitepaper (2009-08-30B), written by Randy Carroll and the joint IHE and Continua WAN
working group.
25
The RCH could also specify a „classic‟ VMD to facilitate uniform SPD queries across PHD and PCD devices. The VMD
would not be required in the WAN message sent on behalf of the PHD device but would be implied by the unique OBX path
from the MDC_TEMP_BODY METRIC node to the top-level MDC_DEV_SPEC_PROFILE_TEMP node (see Table 1).
RCH.1g.doc - 12 - 2009-09-09T17
Archive - Discarded Items from earlier drafts
1. MDS and VMD specification of ‘device type’
Three types of MDS/VMD representations are supported in a manner that facilities query by VMD, even though the
VMD need not be sent in two of three of the cases. OBX REFIDs shown with double-strikethrough may be omitted
by general policy and single-strikethrough may be omitted based context.
LEVEL X73-classic ECG in multi-parameter monitor X73-classic ECG stand-alone X73_PH ECG device
MDS MDC_DEV_METER_PHYSIO_MULTI_PARAM_MDS MDC_DEV_ECG_MDS MDC_DEV_SPEC_PROFILE_ECG
VMD . MDC_DEV_ECG_VMD . MDC_DEV_ECG_VMD . MDC_DEV_ECG_VMD
CHAN . . MDC_DEV_ECG_CHAN . . MDC_DEV_ECG_CHAN . . MDC_DEV_ECG_CHAN
METRIC . . . MDC_ECG_HEART_RATE . . . MDC_ECG_HEART_RATE . . . MDC_ECG_HEART_RATE
Note 1: MDC_DEV_ECG_VMD is required when it cannot be MDC_DEV_xxx_VMD is not X73_PH specifies the top-level with
inferred from the top-level MDS, such as in the case of required when the single parent MDC_DEV_SPEC_PROFILE_xxx
a multi-parameter monitor. MDC_DEV_xxx_MDS refers to and the VMD need not be sent.
the same device or organ system.
Note 2: Although MDC_DEV_ECG_VMD need not be sent in two of the three cases above, it is included in the RCH to provide a
consistent VMD target for queries by parameter or organ system, regardless of the top-level MDS representation.
Note 3: MDC_DEV_ECG_CHAN need not be sent since it is the sole ancestor of MDC_ECG_HEART_RATE, and can be determined with
the use of the RCH table. Clinical systems do not need MDC_DEV_ECG_CHAN since MDC_ECG_HEART_RATE is a ‘stand-
alone’ term that does not require any supporting context to be understood. The MDC_DEV_ECG_CHAN would still be present in
the RCH but the ‘CHAN OBX’ rule above since parent CHAN of MDC_ECG_HEART_RATE can be unambiguously determined.
Revision History
RCH.1g.doc - 13 - 2009-09-09T17
