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

• Create a uniform tabular (or XML or database) representation that will facilitate comparison.
• 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.

5.1 Creation of Rosetta Terminology Mapping Table

Vendors, typically participating as a IHE PCD Device Observation Reporters, will provide 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 units of measure and UCUM units-of-measure, as shown below:

Status	Column Name	Description
R	Group	Parameter group label (informative)
M	REFERENCE_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 | ... }
C,O	Containment	e.g. VMD, ‘channel’ (TBD)

5.2 Identify implementation differences and resolve them

The tables submitted by the individual vendors are then combined into a single Excel spreadsheet to facilitate initial discussion and resolution of implementation differences.

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 likely identification differences. For example, and XSLT could be used to create a list of unique standard identifiers and the vendors that chose that identifier for their mapping. Identifiers that were supported by only a single vendor would be examined with particular care.

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

<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

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

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

7. Risks

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

8. Open Issues

<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

<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

<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>