PCD Profile RTM Proposal Detailed

1. Proposed Profile: Rosetta Terminology Mapping [RTM]

• Proposal Editors: Paul Schluter & Todd Cooper
• Editors: Paul Schluter & Todd Cooper
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Patient Care Devices

• Contributors: John Rhoads, Jan Wittenber, Robert Flanders, Al Engelbert, Richard Roa, Susan Blyde, Ken Fuchs, Sam Carello and other IHE PCD participants

Summary

<Many people find it easier to write this section last. Use simple declarative sentences. Avoid going into background. If it's more than a dozen lines, it's not a summary.>

<Summarize in one or two lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">

<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">

<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">

<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">

<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">

2. The Problem

The majority of PCD devices use vendor-specific or proprietary nomenclatures and terminologies. As a result, even though information may be exchanged using standards-based transactions such as Device Enterprise Communication, semantic interoperability is not achieved until the content is mapped to a standard nomenclature. This mapping is often inconsistent and subject to loss of information (e.g. mapping from a specific term to a more generic term). Also given the lack of tooling, utilizing standardized medical device terminology in production systems is difficult and often cost prohibitive.

This profile will focus on identifying a core set of semantics that are shared between multiple devices within the same modality (e.g., physiological monitors, ventilators, infusion pumps, etc.) and then mapping them to a standard terminology. The RTM mapping effort will initially include numeric parameters and their associated units of measurement and enumerated values.

The RTM information should be represented in a uniform manner, such as by one or more XML files. This will facilitate use by production systems, but more importantly, facilitate comparison between vendors that have (or plan to) implement the nomenclature standard in their systems, with the following goals:

• identify terms that are missing from the standard nomenclature
• ensure correct and consistent use if multiple representations are possible
• ensure correct and consistent use of units-of-measure
• ensure correct and consistent use of enumerated values

During the development of the RTM, gaps in the standardized medical device terminology will be identified. In these cases, proposals will be made for adding the semantics to the appropriate terminologies. Although the immediate focus of the RTM profile will be to standardize the content in transaction profiles such as DEC, which are typically between a device data gateway and enterprise level applications, the standardized terms should also support direct device communication, enabling semantic interoperability literally from the sensor to the EHR.

The availability of the RTM information will also facilitate development of tools that can more rigorously validate messages, such as enforcing the use of the correct units-of-measure and correct enumerated values associated with specific numeric values. For example, ST segment deviation will be expressed in "uV" or "mV", rather than the traditional "mm". This will promote greater interoperability, clarity and correctness which will in turn benefit patient safety.

The consistent and correct use of a standard nomenclatures such as ISO/IEEE 11073-10101 and UCUM for medical device and system data exchange will facilitate further development of real-time clinical decision support, smart alarms, safety interlocks, clinical algorithms, data mining and other clinical research. This work can be also be expanded at a future date to support events and alarms, waveforms, device settings and other critical monitoring information.

<Describe the integration problem. What doesn’t work, or what needs to work.>

3. Key Use Case

A patient is monitored at home. A potentially life-threatening cardiac event is detected and reported to a remote monitoring service that confirms and forwards the event to his caregiver. The patient is subsequently admitted to the ER complaining about chest pain. A diagnostic 12-lead is taken followed by continuous vital signs monitoring or telemetry for further observation. Following a series of premonitory episodes of ST segment deviation, the patient exhibits short runs of ventricular ectopy that rapidly devolve into ventricular tachycardia and then fibrillation. The patient is cardioverted in the ER and scheduled for CABG surgery. During surgery, the patient is connected to well over a dozen medical devices (e.g. multiparameter patient monitor, anesthesia machine, multiple infusion pumps, bypass machine, etc.) and the data from these devices and systems is displayed in a unified and comprehensible manner and automatically charted. After successful surgery, the patient is monitored in the ICU. The patient is discharged a week later to continue his recovery at home, where, among other things, he uses a spirometer with a low-cost wireless interface to facilitate recovery. He also exercises while walking around in and outside the house attached to a wireless sensor that records and transmits his ECG via his cell phone to a remote monitoring service. The patient also has follow-up visits to cardiac rehab, where his ECG and glucose measurements are taken before and after exercise, with all the data also electronically recorded. This information is ultimately stored in the patient's personal health record and made available for a follow-up study regarding the cardiac medications he was taking.

The key point of this overly broad but realistic use case is that the patient's data is "touched" by well over three dozen medical devices and systems designed and manufactured by nearly an equal number of different vendors. An essential first step towards achieving interoperability across all these devices and systems is that they use a shared semantic foundation.

<Describe a short use case scenario from the user perspective. The use case should demonstrate the integration/workflow problem.>

<Feel free to add a second use case scenario demonstrating how it “should” work. Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.>

<To focus on the end user requirements, and not just the solution mechanism, and to give people trying to understand the applications concrete examples of the problems existing and the nature of the solution required. State the problem domain and outline the workflows in terms of the people, tasks, systems and information involved. Feel free to describe both the current “problematic” workflow as well as a desirable future workflow where appropriate. Remember that other committee members reviewing the proposal may or may not have a detailed familiarity with this problem. Where appropriate, define terms.>

4. Standards & Systems

ISO/IEEE 11073-10101 Health informatics — Point-of-care medical device communication — Part 10101: Nomenclature, First edition, 2004-12-15. Published by ISO and IEEE, 2004.

The ‘Unified Code for Units of Measure’ (UCUM), [1].

5. Technical Approach

The principal technical steps of the RTM profile proposal are described in Sections 5.1 to 5.4.

5.1 Create the Rosetta Terminology Mapping Table

Vendors, typically participating as a IHE PCD Device Observation Reporters, will contribute a table listing the numeric parameters they plan to support. Each row of the table includes the vendors displayed name and units of measure and the equivalent ISO/IEEE-11073 identifier and ISO/IEEE-11073 and UCUM units of measure, as shown below:

Status	Column Name	Description
R	Group	Parameter group label (informative)
M	REF_ID	e.g. MDC_ECG_HEART_RATE
M	PART	Code partition (decimal)
M	CODE10	Context-sensitive code (decimal)
M	CF_CODE10	Context-free code (decimal, calculated by Excel)
M	Vendor_ID	Vendor identifier
M	Vendor_Description	Vendor description of parameter
O	Vendor_DName	Vendor Displayed Name
O	Vendor_UOM	Vendor UOM
M	UOM_IEEE	IEEE UOM (single, short list or _pointer)
M	UPART	IEEE Unit Code partition (decimal)
M	UCODE10	IEEE Units context-sensitive code (decimal)
M	CF_UCODE10	IEEE Units context-free code (decimal, calculated by Excel)
M	UOM_UCUM	UCUM UOM (single, short list or _pointer)
C	Vendor_Status	S Supported F Future
C	Vendor_Sort	Numeric index for sorting
O	Enum_Values	Enumerated values (short list or _pointer)
O	OBX-20	Site identifier enumerations for certain measurements
O	Vendor_Comment	Vendor comment
O	Vendor_VMD	Vendor IEEE 11073 ‘Virtual Medical Device’ identifier Reference ID
O	REF_ID_COMMENTS	Vendor-specific Reference ID comments
R	DataType	wav | evt | etc. )
C,O	Containment	e.g. VMD, ‘channel’ (TBD)

Notes:

The Status letter indicates whether an entry in the column is 'M' Mandatory, 'R' Recommended or 'O' Optional.

The REF_ID column lists the MDC Reference Identifier that is equivalent to the vendor's numeric parameter. If there is any uncertainty, a "_?" shall be appended to the MDC Reference Identifier (e.g. MDC_ECG_HEART_RATE_?). If the term is missing from the ISO/IEEE 11073 nomenclature, the vendor may propose an MDC Reference Identifier and append an "_X".

5.2 Identify implementation differences and resolve them

The tables submitted by the individual vendors will be merged into a single Excel spreadsheet to facilitate discussion and discussion.

The information initially submitted as an Excel spreadsheet will also be converted into an XML document. This will facilitate the use of tools such as XSLT to find differences. For example, XSLT can be used to create a list of the MDC reference identifiers and the vendors that selected it, and MDC identifiers that were selected by only a single vendor would be examined and compared with similar terms.

5.3 Identify missing terms and propose new terms to standards groups

It is likely that new terms will need to be added to represent new concepts and terms since the publication of the ISO/IEEE 11073-10101 nomenclature standard. Any missing or new MDC reference identifiers will be submitted to the appropriate standards group (typically IEEE 11073) to create and add the new terms to the relevant standard.

5.4 Generate final set of terms, units-of-measure and enumerations for testing

Any corrections or additions will be reflected back the vendor's table and a new version of the merge table (and XML files) will be created. This review-edit-merge cycle will be performed several times.

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

Existing actors

Device Observation Reporter - The Device Observation Reporter (DOR) actor receives data from patient care devices (PCDs), including those based on proprietary formats, and maps the data to messages that provide consistent syntax and semantics before sending them to the Device Observation Consumer (DOC) or Device Observation Filter (DOF).

Device Observation Consumer - The Device Observation Consumer (DOC) actor is responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both.

Device Observation Filter - The Device Observation Filter (DOF) actor is responsible for providing PCD data filtering services based on the publish/subscribe predicates negotiated with the client DOC application.

The number of numeric parameters supported by the DOR, DOC and DOF transactions will be increased, but transaction syntax and sequencing will not be affected by this profile proposal.

New actors

None.

Existing transactions

Communicate PCD Data (PCD-01) Transmit PCD data to enterprise clients from a Device Observation Reporter (or Observation Filter for PCD-02) and Receive PCD data by a Device Observation Consumer.

Subscribe to PCD Data (PCD-02/SPD) Defines predicate(s) for communication of PCD data from a DOF to a Device Observation Consumer.

Although the number of numeric parameters supported by the DOR, DOC and DOF transactions will be increased, the transaction syntax and messaging will not be affected by this profile proposal.

New transactions (standards used)

None.

Impact on existing integration profiles

None.

New integration profiles needed

None.

Breakdown of tasks that need to be accomplished

The tasks described in steps 5.1 to 5.4 are summarized below:

• Create a uniform tabular (or XML or database) representation that will facilitate comparison and discussion.
• Identify minor implementation differences and resolve them.
• Identify missing terms and propose terms that should be added to existing standard terminologies.
• Generate final set of terms, units-of-measure and enumerations for verification and validation.

6. Support & Resources

• Vendors will need to contribute table rows as noted above.
• Within the IHE PCD and IEEE 11073 membership, discuss and resolve differences in implementation.
• Work with other standards and clinician groups to resolve difficult topics (e.g. ventilator mode terminology).
• Within the IEEE 11073 committee, formally define and approve new terms as required by this proposal.

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

• Certain terminology concepts, such as common enumerations ventilator modes, have been historically difficult to achieve due to competitive and marketing reasons. In these cases, achieve a common set of terms for communications interoperability is essential, and vendor specific terms could be supported by using non-normative "display strings".
• This effort will likely trigger a major update to the ISO/IEEE 11073-10101 nomenclature, and it is unclear that we have the manpower and resources to do this.
• At the present time, the ISO/IEEE 11073-10101 does not have a well established operating mechanism for periodically updating the nomenclature and distributing it to implementors.

<List technical or political risks that could impede successfully fielding the profile.>

8. Open Issues

Moderate: The repository for the Rosetta Terminology Mapping could be a spreadsheet or an XML file (or both). Although a final decision regarding this has not been made, using a Schema constrained XML document is currently the preferred approach due to its simplicity and ease of distribution.

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>

9. Tech Cmte Evaluation

TBD

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA