IEEE P11073-10101b Group1 Partition 1 and 2 <SRC> terms and Partition 2 NMT and rSO2 terms with final "provisional" code assignments

[Paul Schluter]

Greetings!

I am sending you the additional new numeric and object <source> identifiers and new evidentiary attributes that have been identified during the development of the list of over 630+ new IEEE 11073 event and alert identifiers.  These have been reviewed over the past several weeks and have now been assigned irrevocable “provisional” numeric codes.

The term REFIDs, definitions and assigned numeric codes are included in the attached spreadsheet <New10101b.1f.Group1.2020-03-14T20.P01-P02-NMT-rSO2.xls>.  This spreadsheet has four worksheets:

P01-SRCs lists the new MDC_DEV device object identifiers and MDC_ATTR attributes that will be added to Partition 1, as part of 10101b Group1 set of terms.  These are the new devices that are needed to support all the <src-evt> pairs that have proposed to date as well as several new attributes that can be used to further describe or refine the alert criteria and to convey additional information in an event or alert message.

P02-SRCs lists the numeric observation identifiers that will be included in Partition 2, exclusive of NMT and rSO2.  The ‘AlertType’ column indicates whether the numeric observation identifier can also serve as the basis for a high and/or low numeric limit event, whether it is physiologic, technical (or both) and whether it has settable thresholds (or not).  [Some ‘AlertType’ entries have been left empty since I currently do not have sufficient information regarding how they are deployed by vendors, but we can update this later.]

P02-NMT lists the numeric observation identifiers and settings for Neuromuscular Transmission (NMT).  The terms and proposed MDC_DEV containment hierarchy elements are documented in a flattened tabular format.  [For many implementations, the MDC_DEV_NMT_…_CHAN elements would not need to be sent in a message since they can be inferred by their METRIC observations.]  [Note that MDC_TEMP_SKIN is an existing term.]

P02-rSO2 lists the numeric observation identifiers for Regional Cerebral Oximetry (rSO2). The MDC_DEV_ANALY_SAT_O2_REGIONAL_CHAN provides a simple and consistent framework for supporting any number of channels of this technology.

*     *     *

We will discuss this material during the RTM tcon on Wednesday, March 18th.  This basically wraps up the 10101b Group1 set of “provisional” Partition 1 and Partition 2 terms.  We will start our effort on Group 2 two weeks from now.

I would like to thank Michael Faughn for ensuring that the final set of 10101b Group1 numeric code assignments do not conflict any of the existing numeric codes in the IEEE Std 10101-2019 revision as well as RTMMS v1 and v2.

If you have any questions or comments, please do not hesitate to contact me.  The Webex information for next Wednesday’s RTM tcon is provided below.

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<New10101b.1f.Group1.2020-03-14T20.P01-P02-NMT-rSO2.xls>>

Topic: PCD Rosetta Terminology Mapping WG
https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Date:   Every Wednesday
Time:   11:00 AM, Central; 12:00 Noon, Eastern; 

Meeting Number:         490 820 843        Devices1

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, March 25th, is cancelled, since it is likely that the IHE DEV (PCD and PCHA) Webex starting at 10:00 AM CDT will run over its allotted hour.  We will reconvene the following Wednesday, April 1st.

If you have any questions, comments or suggestions regarding the new terms and code assignments for the material I sent to you on March 16, just send me an email and please feel free to share it with the RTM community if you prefer.

On a related topic, we are currently reviewing the new terms that Kurt Elliason and the IHE PCD Infusion Pump and MEM DMC Working Groups have developed for supporting medical device and equipment management.  This includes device identity and current operational status, device power and battery status and management, basic wired and wireless networking information and additional information regarding infusion pumps.  We plan to discuss these during the IHE PCD MEM call at 1:00 PM CDT this Friday.

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

On Mar 16, 2020, at 9:08 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

At long last, I am sending you the final “provisional” code assignments for the 10101b Group1 MDC_EVT terms, listed in the new sub-table «$extra.10 New 10101b MDC_EVT terms» of the attached HTML file.

This includes the:

REFID

mdcDescription (final editorial review will be completed prior to first ballot; alternative vendor ‘definitions’ are currently shown to reflect vendor variation and to facilitate searching by vendors for phrases that they are familiar with)

Disc  (all MDC_EVT support the even/odd EVT discriminator and the Alarm Inactivation State (AIS) terms support the additional [AIS] discriminator set.

PartCode and CF_CODE10

The [AIS] discriminator set is shown immediately after the New 10101b MDC_EVT table.  The [AIS] dOffset values incorporate the even/odd [EVT] discriminator so that only the single [AIS] discriminator set needs to be processed.

The New 10101b MDC_EVT table also includes <pars> that lists the parameters and/or organ systems that use a specific MDC_EVT term and <AlertType> lists the type of alert (e.g. phys, tech, low, high, etc.).  Despite the usefulness of this information, it will likely not be published in the IEEE P11073-10101b standard, but will be available in the RTMMS v2 along with possibly additional information about each alert type (e.g. priority range among vendors, if we can obtain this information, etc.).

[The ’s’ column will not be included in the standard; its only purpose was to provide a grouping index since the code assignments are allocated according to their original grouping in ISO/IEEE 11073-10101:2004.]

The MDC_EVT code assignments listed in this table have been thoroughly vetted against the IEEE Std 11073-10101-1019 revision and other resources.  I believe you can confidently deploy the new 10101b Group1 MDC_EVT terms as “provisional” terms that have been irrevocably assigned and cannot be changed, other than final editorial review of the definitions before going to ballot.

Michael Faughn and I have verified that the new MDC_EVT numeric codes did not conflict any of the pre-existing numeric codes in the IEEE Std 10101-2019 revision and RTMMS v1 and v2.

I will be sending you the new <src> object identifiers, attributes and numeric parameters that are required to support the <evt> terms in a separate email that will be sent to you shortly.  We will discuss this material during the RTM tcon on Wednesday, March 18th.  This basically wraps up the 10101b Group1 set of “provisional” terms and begin effort on Group 2 two weeks from now.

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<ListParSrcEvt.3n.x3t.2020-03-10T19.Group1.EVT.final.html>>

[Paul Schluter]

Greetings!

Just a friendly reminder - please join our RTM tcon tomorrow on Wednesday, April 1st, at 11:00 AM CDT.

The first part of our meeting will focus on any remaining questions that you have on the new IEEE 11073-10101b Group 1 “provisional” terms, including the 630+ MDC_EVT <evt> terms, new object and numeric <src> terms, and additional numeric observation identifiers for neuromuscular transmission (NMT) and regional cerebral oximetry (rSO2).

The second part of tomorrow’s meeting will be any remaining questions or issues regarding the new MEM DMC terms intended to support infusion pump device management as well as other medical devices, including general operational status, battery and power management and IP-based wired and wireless networking (the networking terms has been recently extended to support essential IPv4 as well as IPv6 configuration information).  This information has been circulated among the IHE PCD infusion pump and MEM DMC working group principals, and if you’re interested, please send me an email and I will be happy to send you the current list of MEM DMC terms prior to tomorrow’s RTM tcon.

The third part of tomorrow’s meeting will be focused on the technical events and alerts regarding regional cerebral oximetry (rSO2).  I have been able to obtain sufficient information for the INVOS (now part of Medtronic/Covidien) and Masimo rSO2 device implementations to develop a capable set of <src-evt> identifiers for rSO2 technical events (attached), in addition to the rSO2 physiologic events and alerts defined previously.  The proposed set of rSO2 technical events will also support devices made by Nonin and Edwards Casmed but I need additional detailed technical information to confirm.

An interesting aspect of rSO2 as well as other neuromonitoring parameters such as EEG, BIS, Entropy is that they all deal with low-amplitude signals that require pre-amplification and digital signal conversion (and processing) at or near the patient.  This topology is supported by the “Digital Signal Converter” (_DSC) series of MDC_EVT identifiers that help identify whether the problem is in the host-to-DSC connection (cable, compatibility, etc.) or DSC-to-sensor (site).  The _DSC series of events deal primarily with DSC cable and communication failures, but in all other respects signal lead and signal processing events are treated exactly as if they occurred in a traditional CHAN (channel) or VMD (device).  That is, we provide the most specific information possible regarding the components that have failed or may be questionable, from the host-to-DSC cable, the DSC itself, the sensor cable as well as the individual electrodes or optodes applied to the patient.  This will help direct the clinician’s or biomedical engineer’s attention to the problem at hand as rapidly as possible.

That’s it for now, and I look forward towards our conversation tomorrow!

Best regards, and stay healthy ...

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com

Cell:  (414) 702-2026

<<ListParSrcEvt.3o.x3u.2020-03-31T14.rSO2-only.xls>>

Topic: PCD Rosetta Terminology Mapping WG
https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Date:   Every Wednesday
Time:   11:00 AM, Central; 12:00 Noon, Eastern; 

Meeting Number:         490 820 843        Devices1

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, April 8th, is cancelled.  I have not received any additional comments about the topics we discussed last week, so we will postpone our next RTM discussion until next week.

I would like to thank Charles Parisot, Monroe Pattillo, Naveen Sharma and Kurt Elliason for their participation last Wednesday as well as at the MEM DMC meeting last Friday.  We will implement Monroe’s recommendation that we define separate MDC_MOC_NCC_WIRED and MDC_MOC_NCC_WIRELESS "managed object class" identifiers for wired and wireless IP-based network communication controllers.  This will nicely support the essential parameters for IP-based “lower-layers” networking that is central to many of our devices and systems today as well as provide a modular naming framework for additional networking and communication technologies in the future.

On a related effort, I have gathered all the MDC_EVT event and alert identifiers that are currently used by the IHE PCD Infusion Pump Working Group and will send them out to the pump group later today.  For IPEC events, only three require numeric codes and a grand total of eleven new IPEC event identifiers will be published in IEEE P11073-10101b.  I have also gathered a list of 24 existing MDC_EVT identifiers that are used by the infusion pump community for ACM messages.

Best regards, and stay healthy!

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, April 15th, is cancelled.

I am making very good progress on the consolidated list of infusion pump events and alerts, building on the previous excellent work of the infusion pump working group and their positive engagement and feedback.  I plan to send out the updated HTML <src-evt> summary later this week so that everyone will have an opportunity to review it before the PCD Pump Virtual Face-to-Face next Tuesday, starting at 8 AM EDT.

Of course, comments by email are welcome at any time, and the more we get done before next week's Virtual Face-to-Face, the better.  

Best regards, and stay healthy!

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

PS.  If anyone has a nomenclature topic they would like to discuss during our normal RTM timeslot this week, please let me know by 10:55 AM CDT today.  Otherwise, I believe we will have ample time during the PCD Virtual F2F next week.

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, April 22nd, is cancelled due to the IHE PCD Virtual F2F this week.

We will reconvene next Wednesday, April 29th.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, April 29th, is cancelled … it is an “off” week for many of the IHE PCD domain tcons, especially after our very successful “Virtual F2F” meeting last week.  We will reconvene next Wednesday, May 6th.

In case you missed the Virtual F2F, there were several discussions related to the draft IEEE P11073-10101b nomenclature:

ftp://ftp.ihe.net//Patient_Care_Devices/Meetings/Face to Face Meetings/2020-April-Virtual/IHE_PCD_F2F_2020-04-23.NomenclatureStatus.1b.2020-04-23T15.pptx

This deck provides an overview of where we are with the draft IEEE P11073-10101b nomenclature and next steps, with the goal of having a ballot draft ready by the end of this summer.  This was presented during the IHE PCD TC meeting on Thursday, April 24.

ftp://ftp.ihe.net//Patient_Care_Devices/Meetings/Face to Face Meetings/2020-April-Virtual/ListParSrcEvt.3o.x3u.2020-04-21T12.xls

ftp://ftp.ihe.net//Patient_Care_Devices/Meetings/Face to Face Meetings/2020-April-Virtual/Pump-discussion-notes.1d.2020-04-21T10.docx

The spreadsheet and discussion notes were presented during the IHE PCD Infusion Pump meeting on Tuesday, April 22.  The spreadsheet documents the current MDC_EVT event and alert vocabulary currently used by members of the IHE PCD Infusion Pump WG.  We are using this list to ensure that the vendor “displayText” strings are reasonably associated with the standardized IEEE 11073 terms as well as identifying and defining new MDC_EVT terms where.  [We plan continue this discussion next week, and I am hoping for contributions from at least one more vendor by this Friday.]

Best regards, and stay healthy and safe!

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow this Wednesday, May 6th, at 11:00 AM CDT.

We will discuss two topics related to infusion pumps that may be of general interest to the broader IHE PCD community, and given our relatively busy schedules next week, we will start with two topics that we have had preliminary conversations about.  Both topics were raised by Jeff Rinda in his email sent to the infusion pump community on April 27th.

Email #1:  Hard and Soft Limit Overrides

This proposal defines several MDC_EVT events that an infusion pump can send when a clinician overrides the “hard” and “soft” limits defined by the pump’s drug library.

Email #2:  MDC_EVT_NOS, MDC_EVT, MDC_EVT_UNDEF, MDC_EVT_UNK and MDC_EVT_UNKNOWN ... and generic technical status condition(s)

Several people, including myself, are dissatisfied with using MDC_EVT_UNKNOWN for reporting events and alerts that do not have a precise MDC_EVT REFID.  Using MDC_EVT_NOS (3::61439) to indicate a ‘non-specific’ event would be more appropriate for events that are either highly vendor specific (e.g. self-test failures) or too detailed to warrant the definition of a new MDC_EVT term.  In these cases, using the “provisional” MDC_ATTR_ALERT_TEXT (1::3010) attribute to convey the vendor displayText is a sensible and practical solution.

That’s it for now, and I look forward towards our conversation tomorrow!

Best regards, and stay healthy ...

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

Topic: PCD Rosetta Terminology Mapping WG
https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Date:   Every Wednesday
Time:   11:00 AM, Central; 12:00 Noon, Eastern; 
Meeting Number:         490 820 843        Devices1

On May 5, 2020, at 10:57 AM, Paul Schluter <pssch...@gmail.com> wrote:

Email #1:  Hard and Soft Limit Override Events

Jeff and colleagues,

Jeff, your proposal makes a lot of sense, and I would be happy to add the proposed limit override events to our list of pump events.  

I recommend that ‘_UPPER’ and ‘_LOWER’ be incorporated into terms in a pre-coordinated manner, yielding a total of four events.  This would allow a single numeric value (i.e. dose, rate, bolus amount, concentration) to be specified as the numeric <source> identifier.  [This is consistent with numeric limit events, where MDC_EVT_HI and MDC_EVT_LO (and now MDC_EVT_HI_CRITICAL and MDC_EVT_LO_CRITICAL as of 10101b) indicate the numeric limit that is exceeded.]

Listing the new events in order, from highest limit down to lowest limit, we would have:

   MDC_EVT_PUMP_HARD_LIMIT_OVERRIDE_UPPER

   MDC_EVT_PUMP_SOFT_LIMIT_OVERRIDE_UPPER

   MDC_EVT_PUMP_SOFT_LIMIT_OVERRIDE_LOWER

   MDC_EVT_PUMP_HARD_LIMIT_OVERRIDE_LOWER

Pre-coordinating ‘UPPER’ and ‘LOWER’ into the REFIDs is clinically appropriate since the ‘UPPER’ limit is typically more clinically significant (e.g. overdose or over-concentration) than the ‘LOWER’ limit.  So it’s quite likely that the content models for each alert could be different, and having distinct REFIDs helps make it easier to define and validate the additional data associated with these events.

The ‘HARD’ and ‘SOFT’ variants can have significantly different content models, since clinician authorization and confirmation are more likely to be required for a ‘HARD’ override than for a ’SOFT’ override.  For example, we could adapt the key concepts from one vendor’s description of all four variants in the Description/Definitions for these terms:

You can define upper and lower soft and hard limits as part of the rule set for each medication entry that you create in the library. As you configure the limits, the software enforces the following rule: 

Lower Hard Limit (LHL) < Lower Soft Limit (LSL) <= Upper Soft Limit (USL) < Upper Hard Limit (UHL) 

Soft Limits 

Soft Limits are dose rate limits that can be overridden when programming the infuser. When a value entered on the infuser is lower than the lower soft limit or higher than the upper soft limit,  the infuser displays a soft limit override confirmation message. The infuser records soft limit alerts and the user’s response to the alert in its history logs. 

For example, if the upper soft limit is set to 15 mL/hr and the clinician enters 16 mL/hr, the infuser will display a soft limit override alert. This alert notifies the clinician that the entry is outside the range of the soft limits set for that medication entry. The clinician can choose to continue programming using the override, or cancel the override and edit the value. Both the override and edit events are recorded separately in the infuser’s history log.

Hard Limits 

Hard limits are dose rate limits that cannot be overridden; the infuser cannot be programmed with a rate that is lower than the lower hard limit or higher than the upper hard limit.

With regards to the principal <source> and other evidentiary data identifiers, we could or would have:

Principal <source> identifiers:  MDC_RATE_DOSE, MDC_VOL_FLUID_TBI, MDC_DOSE_DRUG_BOLUS, MDC_CONC_DRUG, etc.)

It would be very helpful to have a list of these, and I will need to list them under the <src> identifier column associated with the four <evt> terms above in the HTML summary table for events and alerts.  I will start with the four numeric <src> identifiers listed above.

Additional evidentiary identifiers:  Drug identity, etc. … sufficiently complete to unambiguously reference the drug library entry

Atlhough this would be helpful as well, this information is not immediately necessary for drafting 10101b.

Although we could consider defining additional “named" events for bolus amount and drug concentration limit overrides (similar to the ECG “named" event” MDC_ECG_BRADY for low heart rate), I would not recommend doing this.  Instead, we should draw from the existing and proposed numeric observation/setting nomenclature, and I assume that this would be consistent with your plans for accessing this information using a standard nomenclature.

In order to verify that the four new event terms will work for everyone, I recommend that you first consider the likely <source> identifiers (e.g. MDC_RATE_DOSE, MDC_VOL_FLUID_TBI, etc.) that would be used with the four proposed limit override events.  At some point in time, it would useful to list additional mandatory data items (e.g. drug identity, etc.) and optional data items associated with each set of <src-evt> identifier pairs.

The effort to capture and document this information would be extremely useful and is well-aligned with similar event and alert “evidentiary content models” that will eventually be defined for other events, such as including the peak and average heart rate, PVC run length, annotated waveform, etc. for a serious ventricular arrhythmia such as MDC_ECG_V_TACHY.

Thank you, Jeff, for bring this topic to our attention.  We could exchange preliminary thoughts during this week’s RTM tcon, ACM tcon, or (most likely) make it one of several topics for the Infusion Pump tcon next Monday.  Please let me know your preference by this evening, and we can always exchange emails in the meantime.

Thanks and regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

On Apr 27, 2020, at 1:12 PM, Jeffrey E. Rinda <jeffre...@icumed.com> wrote:

A few more possible events related to programming a pump.  These could occur based on the clinician response to a “soft limit” or “hard limit” warning on the pump.  The limit values are typically defined in the pump’s drug library.  Soft limits can always be overridden, and certain devices allow override of a hard limit under defined circumstances, e.g. after the clinician enters a password.

 

Soft limit overridden by clinician, MDC_EVT_PUMP_SOFT_LIMIT_OVERRIDE

Hard limit overridden by clinician, MDC_EVT_PUMP_HARD_LIMIT_OVERRIDE

 

Also, it would be useful to have a generic event defined to provide information that may be useful in cases where there is no specific event defined, MDC_EVT_PUMP_OTHER (or NOS)   [This will be discussed in a separate email.]

On May 5, 2020, at 12:37 PM, Paul Schluter <pssch...@gmail.com> wrote:

Email #2:  MDC_EVT_NOS, MDC_EVT, MDC_EVT_UNDEF, MDC_EVT_UNK and MDC_EVT_UNKNOWN ... and generic technical status condition(s)

Jeff and colleagues,

This is a reply to the second part of Jeff Rinda’s April 27th email, where he asks:

Also, it would be useful to have a generic event defined to provide information that may be useful in cases where there is no specific event defined, MDC_EVT_PUMP_OTHER (or NOS)

Here are the candidate IEEE 11073 terms, listed in most-preferred to least-preferred order:

MDC_EVT_NOS   (3::61439)   Event, NOS.❖Generic event, not otherwise specified. (p)  BEST CHOICE

  Originally defined in 10101:2004 Annex B, in 10101R we have further clarified:
  SysName:  Event | non-specific
  Description:  Event, non-specific [NOS] (This code is unusual as it applies only to an object.)
  Note:  the code is the last public code available, and applies only to an object  (3::0xEFFF)


MDC_EVT  (3::0)  An event has occurred (NOS)   (no disclosed use by any vendor)

  Originally defined in 10101:2004 Annex B, in 10101R we have further clarified:
  SysName:  ErrorEvent | | FunctionalDisturbance | Device
  CommonTerm:  Event
  Description:  An event has occurred (NOS)


MDC_EVT_UNDEF   (3::112)   Undefined.  (p)

MDC_EVT_UNK  (3::118)  VMD or signal is unknown.   (p)

MDC_EVT_UNKNOWN (3::740) An unknown event has occurred.   (p1, p2, p3, but not by g, p, d)

Please note that these are very generic event terms, and the only way of formally providing any additional specificity is by using the <source> identifier, which in most cases would be MDC_DEV_PUMP_MDS/_VMD/_CHAN or other pump related object identifier.  It would be far more useful to use MDC_EVT_MALF (typically for unrecoverable errors) and the proposed (new) MDC_EVT_SELFTEST_FAILURE to provide a greater degree of specificity.

*     *     *

Several people, including myself, are dissatisfied with ‘Unknown’.  Using MDC_EVT_NOS (3::61439) to indicate ‘non-specific’ would be far more appropriate for events that are either highly vendor specific (e.g. self-test failures) or too detailed to warrant the definition of a new MDC_EVT term.  In these cases, using the “provisional” MDC_ATTR_ALERT_TEXT (1::3010) to convey the vendor displayText is a sensible and practical solution.

At the present time MDC_EVT_UNKNOWN (3::740) has been used by several pump vendors but neither the REFID MDC_EVT_UNKNOWN nor its definition ”An unknown event has occurred” are actually valid since the actual event or alert condition is probably clearly expressed by MDC_ATTR_ALERT_TEXT.

My choice would be to use MDC_EVT_NOS (preferred) or MDC_EVT (less preferred).  [The only minor issue with MDC_EVT_NOS is that its numeric code 3::61439 = 3::0xEFFF is way off in the stratosphere (John Rhoads or Todd, why was it placed there?).  This probably won’t be an issue for most implementations, but some may prefer MDC_EVT (3::0) which has the definition “An event has occurred (NOS)”.]

*     *     *     *     *

There is another aspect regarding the use of generic event identifiers that rely on non-standardized vendor displayText.  Even though a specific MDC_EVT technical event identifier may not have been defined for the event or alert condition, additional information regarding the cause of the technical event could be conveyed in a standardized manner using an additional (optional) evidentiary attribute described below.

For now, let’s label the proposed attribute MDC_ATTR_ALERT_CAUSE which contains a set of Booleans (cause, status or remedy is asserted if true()) to convey additional information regarding the probable generic cause of the event:

Operational Alerts:

C1:       Likely induced by operator   (cause)
C2:       Self-test failure during operation   (cause)
S1:       Further device operation inhibited until resolved   (status)
R1a:     Likely correctable by operator  (remedy)
R1b:     Likely correctable by operator + manual ACK to clear  (remedy + ACK)
R2a:     Servicing by qualified personnel required   (remedy)
R2b:     Servicing by qualified personnel required  + manual ACK to clear  (remedy + ACK)
R3:       Device must be removed from care area and repaired elsewhere   (remedy)
 

Power-on Self-test failures:

C1:       Power-on Self-test failure
S1:       Further device operation inhibited until resolved
R1:       Powering cycling the device off then back on may resolve issue *
R2:       Possibly correctable by operator
R3:       Device must be removed from care area and repaired by qualified personnel
 
  *          If failure does not recur, check log file(s) for evidence of other failures.  If none found, device can be returned to use.
 

The alarm priority (MDC_ATTR_ALARM_PRIORITY) attribute (or OBX-8 in an ACM HL7 V2 message) would be used to convey urgency of this technical event, similar to physiologic events.

There are other information items we could consider in the future, such as:

            Device is being used in a mission-critical clinical application (also, don’t know)  

              (although this is often non-trivial to determine, it would help set alert priority correctly)


Please feel free to review the list of cause (C), status (S) and remedies (R) and propose additional ones (as well as additional categories).

Thank you, Jeff, for providing the initial inspiration regarding these topics.  We could exchange preliminary thoughts during this week’s RTM tcon, ACM tcon, or (most likely) make it one of several topics for the Infusion Pump tcon next Monday.  Please let me know your preference by this evening, and we can always exchange emails in the meantime.

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

On Apr 27, 2020, at 1:12 PM, Jeffrey E. Rinda <jeffre...@icumed.com> wrote:

A few more possible events related to programming a pump.  These could occur based on the clinician response to a “soft limit” or “hard limit” warning on the pump.  The limit values are typically defined in the pump’s drug library.  Soft limits can always be overridden, and certain devices allow override of a hard limit under defined circumstances, e.g. after the clinician enters a password.

 

Soft limit overridden by clinician, MDC_EVT_PUMP_SOFT_LIMIT_OVERRIDE

Hard limit overridden by clinician, MDC_EVT_PUMP_HARD_LIMIT_OVERRIDE

 

Also, it would be useful to have a generic event defined to provide information that may be useful in cases where there is no specific event defined, MDC_EVT_PUMP_OTHER (or NOS)

[Paul Schluter]

Greetings!

Please join our RTM tcon today on Wednesday, May 13th, at 11:00 AM CDT.  I plan to review the recent changes to the list of infusion pump events and alerts, including recommendations from the infusion pump working group meeting last Monday.  The attached list now includes terms based on products made by five pump vendors as well as recent discussions:

• Added 'pump limit override' and 'pump limit exceeded’ events and associated numeric <src> terms
• Added drop sensor(s) that can be implemented as an separate MDC_DEV_DROP_SENSOR_MDS or logically integrated into the pump as a VMD
• Added Alarm Inactivation State (AIS) events for ‘standby' and 'upstream IV line’ alerts (as separate from general ‘device’ AIS)
• Added MDC_EVT_NOS as the preferred term relative to MDC_EVT_UNKNOWN (but have retained the latter term for compatibility for now)

I’ve also added the ‘D’ column at the far right-hand side to indicate terms that required additional discussion (primarily for my benefit).  Although I believe we have largely resolved and agreed on what is noted in the attached document, I have left the !, !! and !!! notations in place if there is any need for further discussion.

I believe the list of existing and proposed new IEEE P11073-10101b infusion pump events and alerts is now relatively complete while avoiding the numerous detailed “self-test” and other events where the displayText should be used instead.  [That said, we can always add and delete terms based on subsequent feedback, but doing this sooner is always better than later!]

It should be noted that there is some overlap between the functionality of the IPEC events and the more specific “additional infusion delivery completion events”.  In this regard, the IHE PCD DEC, IPEC and ACM profiles, containment models and conformance test procedures should precisely specify the mandatory and optional IEEE 11073 terms and how they should be used, including the determination of whether certain information should be sent as IPEC events or ACM events and alerts.

If you have any questions or comments, please feel free to share them with the Infusion Pump or RTM working groups.  I believe we are getting close to having a very useful and complete list of standardized infusion pump events and alerts, with the proposed new terms (with REFIDs not shown in bold font) to be included in IEEE P11073-10101b.

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026 

<<ListParSrcEvt.3o.x3u.2020-05-11T14.1c.2020-05-12T14.highlighted.xls>>

PS.  The content of this list is identical to the list I sent to the pump group last Monday, May 11 at 4:31 PM CDT.  I also took the liberty of color highlighting rows, comparing the displayText with the IEEE 11073 event and alert REFID.  In many cases the displayText was a more specific case of the broader IEEE 11073 terms, and I’ve highlighted these with light green.  In other cases, I’ve highlighted the displayText with light yellow, indicating that there may be a better fit with a different IEEE 11073 event and alert REFID.  I plan to re-associate a relatively small number of the displayText strings with the more appropriate <evt> REFID to see how this all works out and determine whether we should define any additional infusion pump event and alert identifiers.

Topic: PCD Rosetta Terminology Mapping WG
https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Date:   Every Wednesday
Time:   11:00 AM, Central; 12:00 Noon, Eastern; 
Meeting Number:         490 820 843        Devices1

[Paul Schluter]

Greetings!

The RTM tcon is cancelled for today, Wednesday, May 20th, but will be held on Thursday, May 21st at 3:00 PM CDT during the normal ACM time slot for this week only.

The reason for the change this week is to encourage pump vendors who normally participate on the ACM calls to participate on this call that will focus on finalizing the list of IEEE 11073 events and alerts for infusion pumps.

I will be sending out an updated summary summary table later today that includes comments by Dr. Stefan Schlichting (OR.Net) who has provided many thoughtful comments regarding the pump events and alerts.  Many of his comments were based on his desire to be able to re-use some of the terms for other devices used in the OR and in other cases he had recommendations that would improve the clarity of the terms.

That said, many of you in the pump community have implemented the terms in development and prototype systems, and may be concerned that we could change things unnecessarily.  That’s the last thing we want or need to do, so to facilitate our decision making, I have fully restored the use of blue bold font to indicate “provisional” IEEE 11073-10101b MDC_EVT REFIDs pump events and alerts that are already captured on the NIST RTMMS as well as the block bold for font for “published” IEEE 11073 terms, and this convention will be included on the spreadsheet that I will send to you later today.

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

Topic: PCD ACM WG

Date: Every Thursday, from Thursday, March 14, 2013 to no end date

Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 493 258 799 Meeting Password: Devices1

-------------------------------------------------------

1. Go to https://himss.webex.com/himss/j.php?ED=9780078&UID=-1&PW=NMWY1YzcyZmZl&RT=MiM3 

[Paul Schluter]

Greetings!

Please join our infusion pump event and alert discussion tomorrow, Thursday, May 21, at 3:00 PM CDT during the normal ACM time slot.  Our goal will be to finalize the list of IEEE 11073 events and alerts to support for infusion pumps.  I have provided the Webex and tcon information below, courtesy of Monroe Pattillo

I have also attached an updated summary table that includes comments by Dr. Stefan Schlichting (OR.Net) who has provided many thoughtful comments regarding the pump events and alerts (under the StefanComment column and related bright yellow highlighting in related columns).   Many of his comments were based on his desire to be able to re-use some of the terms for other devices used in the OR and in other cases he had recommendations that would improve the clarity of the terms.

I have included my comments and recommendations under the PaulComment column.  In this column, comments with light green highlighting indicates term-rows that we should probably leave ‘as is’ (although additional discussion may be recommended where appropriate).  Comments with light yellow highlighting indicate term-rows where a change may be sensible but where additional discussion and buy-in by the infusion pump WG will be required.

I am well aware that many of you in the pump community have implemented the terms in development and prototype systems, and may be concerned that we could change things unnecessarily.  That’s the last thing we want or need to do, so to facilitate our decision making, I have fully restored the use of blue bold font to indicate “provisional” IEEE 11073-10101b MDC_EVT REFIDs pump events and alerts that are already captured on the NIST RTMMS as well as the black bold for font for any “published” IEEE 11073 terms.

So please review the comments and recommendations so that we can discuss them tomorrow.  Again, our immediate goal is to finalize the list of IEEE 11073 events and alerts for infusion pumps and pending general consensus on our work tomorrow, I plan to update the list with the new IEEE 11073 MDC_EVT REFIDs and definitions, and, time and energy permitting, I will manually re-associate the vendor displayText strings with the most appropriate MDC_EVT REFIDs (of course, this is something that individual vendors will ultimately need to do!).

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<ListParSrcEvt.3o.x3u.2020-05-11T14.1cc.2020-05-20T15.highlighted_SSch.PSS.xls>>

Topic: PCD ACM WG
Date: Every Thursday, from Thursday, March 14, 2013 to no end date
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 493 258 799 Meeting Password: Devices1

-------------------------------------------------------

1. Go to https://himss.webex.com/himss/j.php?ED=9780078&UID=-1&PW=NMWY1YzcyZmZl&RT=MiM3 

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, May 27th, at 11:00 AM CDT.

We will continue our discussion of infusion pump events and alerts from last week, resuming at row 80.

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

Topic: PCD Rosetta Terminology Mapping WG
https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Date:   Every Wednesday
Time:   11:00 AM, Central; 12:00 Noon, Eastern; 
Meeting Number:         490 820 843        Devices1

On May 20, 2020, at 9:50 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcon is cancelled for today, Wednesday, May 20th, but will be held on Thursday, May 21st at 3:00 PM CDT during the normal ACM time slot for this week only.

The reason for the change this week is to encourage pump vendors who normally participate on the ACM calls to participate on this call that will focus on finalizing the list of IEEE 11073 events and alerts for infusion pumps.

I will be sending out an updated summary summary table later today that includes comments by Dr. Stefan Schlichting (OR.Net) who has provided many thoughtful comments regarding the pump events and alerts.  Many of his comments were based on his desire to be able to re-use some of the terms for other devices used in the OR and in other cases he had recommendations that would improve the clarity of the terms.

That said, many of you in the pump community have implemented the terms in development and prototype systems, and may be concerned that we could change things unnecessarily.  That’s the last thing we want or need to do, so to facilitate our decision making, I have fully restored the use of blue bold font to indicate “provisional” IEEE 11073-10101b MDC_EVT REFIDs pump events and alerts that are already captured on the NIST RTMMS as well as the block bold for font for “published” IEEE 11073 terms, and this convention will be included on the spreadsheet that I will send to you later today.

Best regards,

Paul Schluter

Center4MI:  psch...@center4mi.org
Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, June 3rd, at 11:00 AM CDT.

Two topics for today:

I)  Infusion Pump Events and Alerts

I have incorporated your comments and recommendations over the past several weeks into the updated list of infusion pump events and alerts (attached).  Please review the list before the next Infusion Pump WG meeting, to be held on Monday, June 8, at 10:00 AM CDT.  I hope and expect that we can finalize any remaining issues at the end of that meeting.

Listed below are the major changes:

1)  REFIDs and/or mdcDescriptions for several new events and alerts have been updated to improve clarity and precision

2)  Several vendor displayText strings have been “re-associated” with a more appropriate IEEE 11073 term

Vendor displayText strings have been re-associated with a different IEEE 11073 REFID are indicated by a ‘+’ at the end (and have been removed from the previous REFID).  Since we have defined several new event and alert identifiers, other vendor displayText strings that could be moved as well, so please take a look, especially if they are related to your own products!

3)  The first section is now IPEC, and the miscellaneous “Other technical events and alerts” section has been moved to the end.  Way to go, IPEC!

4)  Six new ‘generic events’ have been defined that can be used by other devices (based on existing pump-specific terms) based on Stefan’s requests.

What remains to be done:

A)  Christophe Fournier has proposed several new events regarding PCA and one regarding the drop sensor.  We will send out his proposal(s) by tomorrow so that you will all have an opportunity to review them before the Infusion Pump WG meeting next Monday.

II)  Non-numeric clinical data

Ali Nakoulima indicated that he would like to discuss the need for “non-numeric” nomenclature that is often necessary to fully complement the device data that the IHE PCD domain normally focusses on.  

Examples include, but are not limited to, the following:

Pain Intensity/Pain Scores

Early Warning Scores

Measurement sites not covered by IEEE 11073

Enumerated body site position  (discussed below)

The IEEE 11073 already has a number of terms like this, such as MDC_SCORE_GLAS_COMA (Glasgow Coma Score), and others, so a good starting point would be to review the IEEE Std 11073-10101-1019 as a starting point.  Existing terms from LOINC and SNOMED should also be considered.

An example of one new term that we should define is MDCX_ATTR_BODY_POSN.  This can be used by all sorts of clinical use cases as well as by beds, chairs, etc. to report the patient’s body position based on widely accepted clinical parlance (in addition to any technical bed mattress positions reported in angles (degrees) and other representations).  [I found it surprising that IEEE 11073 really didn’t have an explicit term concept clearly intended for this purpose, thus the proposal for the MDCX_ATTR_BODY_POSN attribute.]

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<ListParSrcEvt.1ce.x3u.2020-06-03T08.with-generic.xls>>

Topic: PCD Rosetta Terminology Mapping WG
https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Date:   Every Wednesday
Time:   11:00 AM, Central; 12:00 Noon, Eastern; 
Meeting Number:         490 820 843        Devices1

Postscript re BODY POSITION

Regarding patient body position, for the chronic hemodialysis project, we have defined MDCX_ATTR_BODY_POSN which has the following enumerated body positions:  SITTING, STANDING and SUPINE

We can propose a more comprehensive list based on the body positions listed in the IHE PCD DEC POI Supplement:

From IHE PCD POI, Rev 1.1, 2012-08-16  (SpO2) supplement:

sitting    Specifies the body position during the measurement.

standing   Specifies the body position during the measurement.

prone  Specifies the body position during the measurement.  lying face downward

supine   Specifies the body position during the measurement.   lying face upward

reverseTrendelenburg   The reverse Trendelenburg position is surgical position in which the lower extremities are leveled lower than the head and neck. It is the opposite of the Trendelenburg position, in which the head and the neck are below the lower extremities.

TrendelenburgPosition   In the Trendelenburg position the body is laid flat on the back (supine position) with the feet higher than the head by 15-30 degrees. This is a standard position used in abdominal and gynecological surgery. It allows better access to the pelvic organs as gravity pulls the intestines away from the pelvis. It was named after the German surgeon Friedrich Trendelenburg.

semiFowlersPosition  The Semi-Fowler's position is when a patient is lying in bed in a supine position with the head of the bed at approximately 30 degrees.  Patients who are on tube feedings are typically placed in the Semi-Fowler's position. Were the patient to lay flat the tube feeding fluid can possibly run into the lungs. Elevating the head of the bed to 30 degrees decreases the risk of the patient aspirating the tube feeding fluid.

We can support three encodings of an enumeration, simultaneously, in the hRTM:

ASN.1 token and bit position, e.g. on(0), off(1), etc.  This is what “classic” IEEE 11073 uses..

token or TOKEN  

IEEE 11073 REFID and numeric code

These can conceptually lie on the same table-row as permitted Enum_Values and the corresponding Enum_Description that applies to all one, two, or three expressions..

For tomorrow’s discussion, we should get an idea of the variables you are seeking.  The IEEE 11073 nomenclature already has several, e.g. Glasgow Coma Score, and we could draw on LOINC or possibly SNOMED for those observation identifiers, but if there are only a few that are missing in the IEEE 11073 nomenclature, we could consider defining them as well, especially if they could be the pseudo-numeric <source> identifier for the <src-evt> event or alert identifier for an ACM PCD-04 message..

That’s it for now.  I will draft up a short note for tomorrow’s RTM invitation and send it out tomorrow morning.

Paul

[Paul Schluter]

Greetings,

As promised, here is the additional drop sensor event and three PCA events that Christophe Fournier would like to add to the list sent out to you yesterday (<ListParSrcEvt.1ce.x3u.2020-06-03T08.with-generic.xls>, still attached).

Please review both lists before the Infusion Pump WG meeting next Monday.

Thanks and regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

PS.  Regarding drop sensor events, there is one highly related event, MDC_EVT_FLUID_LINE_DRIP_MALF, that I left in the "Fluid line occlusion …” section (we can move it to “Drop Sensor …” later).  One question I have regarding drip/drop sensors made by any (or most) vendors is are they all capable of recognizing when the drip/drop rate is too high and cannot be counted, and if the drip/drop turns into a continuous stream, can they recognize that as a excessive rate or fault condition?  The essential question is whether all drip/drop sensors can return a “data is invalid” state if the actual drop rate cannot be accurately determined under all conditions.

REFID	on Paul's list ? ListParSrcEvt.3o.x3u.2020-05-11T14.1cc.2020-05-20T15.highlighted_SSch.PSS	short phrase	description of event	<src>
MDC_EVT_DROP_SENSOR_DISCONNECTION_REQD	no	No drop sensor	Drop Sensor shall not be connected, risk of flowrate badly controlled	MDC_DEV_PUMP_INFUS_VMD, MDC_DEV_DROP_SENSOR_MDS,
MDC_EVT_PCA_INSUF_DOSE	no, but reasonable	Insufficient dose	In TCI mode, the remaining volume/dose in the syringe is insufficient to reach the target.	MDC_DEV_PUMP_INFUS_VMD	TCI
MDC_EVT_PCA_MAX_BOLUSES	no, but reasonable	Maximum Nb PCA boluses!!	In PCA therapy, the maximum number of PCA boluses specified has been infused.	MDC_DEV_PUMP_INFUS_VMD	PCA
MDC_EVT_PCA_NEAR_MAX_LIMIT (reasonable)	no, but reasonable	Maximum cumulated dose nearly reached !!	In PCA therapy, the maximum dose specified in the cumulated limits is nearly reached.	MDC_DEV_PUMP_INFUS_VMD	PCA

 

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 10th, is cancelled.

We have made excellent progress in reviewing and refining our list of infusion pump events and I plan to send the largely final list out by the end of this week.  If further additions or revisions are required, they will be discussed during the appropriate Infusion Pump or ACM working group meeting.

And now, for a topic many of us have been eagerly waiting for … a much improved IEEE 11073 representation of ventilation mode, based on the excellent work done by ISO/TC 121/SC 4 regarding ISO 19223 Lung ventilators and related equipment — Vocabulary and semantics,   The ISO 19223 standard defines a well-structured and human readable text string representation of ventilation mode that can be easily conveyed by many messaging protocols, but we will also need the ability to convey it as strictly coded information, with numeric codes, to satisfy the general requirements for enterprise, system and device communication using the IEEE 11073-10101 nomenclature.  I am very happy to say that we have found a solution, and that will be the focus of the RTM tcon next Wednesday, July 17th, at 11:00 CDT.

The ISO 19223 to IEEE 11073 REFID string transformation is reasonably robust and straightforward, substituting numeric characters for the punctuation characters used in the ISO 19223 (see the ISO-IEEE Map at the bottom of the attached example).  Future additions to the ISO 19223 ventilator mode representation can be easily supported without “breaking” the transform.

Adding new ventilator modes would start by first defining the ISO 19223 ventilation mode string.  Once there is general agreement regarding the ISO 19223 string and its validity, the corresponding IEEE 11073 MDC_VENT_MODE_ISO_mode-string would be generated automatically, and then a consecutive numeric code in Partition 7 would be automatically assigned using the NIST RTMMS v2, just like any other new “provisional” IEEE 11073 term REFID and numeric code.

The end result is a valid ISO 19223 string and a valid IEEE 11073 REFID that are strictly equivalent in a 1-to-1 reversible manner.  [It would also be possible to append numeric suffixes, e.g. ‘_2’, to the REFID in cases where two different proprietary mode identifiers exist for essentially equivalent ISO 19223 mode.]

This approach looks very promising and will help ensure that the ISO 19223 and IEEE 11073 standards will remain in perfect alignment with each other.  Furthermore, this method will allow us to exploit the ISO 19223 ventilator mode string structure to support additional ventilator mode detail as well as more sophisticated searches and filtering operations.

An excellent set of resources and presentation regarding the ISO 19223 standard is available at https://ventilatorvocabulary.online/powerpoint-google/, and I recommend that you take a look at this material before next Wednesday.  Many thanks are due to Drs. Steven Dain, Norman Jones, John Walsh and other members of the ISO 19223 Committee for providing an excellent foundational standard to base our IEEE 11073 work on!

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<Iss 3 Table.E.1.x1f.2020-06-09T21.with-CPAP.html>>  derived from Table E.1 of ISO 19223

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, June 17, at 11:00 AM CDT.  We will be discussing ventilator mode during tomorrow’s tcon, and I can hope that you can attend.  I will start with an overview of the strategy of using the ISO 19223 ventilator mode strings as the foundation for this effort and defining a normative 1:1 reversible transformation to create pre-coordinated IEEE 11073 MDC_VENT_MODE_ISO_xxx REFIDs that will later be assigned irrevocable “provisional” IEEE 11073 REFIDs and numeric codes.

I plan to include a brief introduction to ISO 19223 ventilator mode nomenclature (unless Norman Jones or Steve Dain would like to do so).  I expect that our discussion tomorrow will be quite informative and interesting.

An excellent set of resources and presentation regarding the ISO 19223 standard is available at https://ventilatorvocabulary.online/powerpoint-google/, and I recommend that you take a look at this material before tomorrow.  Also, you can view the ISO 19223 standard on the ISO Open Browsing Platform (entire document with figures and tables) at https://www.iso.org/obp/ui#iso:std:iso:19223:ed-1:v1:en.  Again, many thanks are due to Drs. Steven Dain, Norman Jones, John Walsh and other members of the ISO 19223 Committee for providing an excellent foundational standard for us to base our IEEE 11073 efforts on!

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<Table I.2.1a.x1h.2020-06-13T12.with-Adjuncts-no-Notes.html>>  Additional examples from ISO 19223 Table I.2 with <Adjuncts>

Topic: PCD Rosetta Terminology Mapping WG
https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Date:   Every Wednesday
Time:   11:00 AM, Central; 12:00 Noon, Eastern; 
Meeting Number:         490 820 843        Devices1

[Paul Schluter]

Greetings!

I am sending you the notes regarding the use of the ISO 19223 ventilator mode nomenclature, using a 1:1 reversible transformation to create pre-coordinated IEEE 11073 MDC_VENT_MODE_ISO_xxx REFIDs that will later be assigned irrevocable “provisional” IEEE 11073 REFIDs and numeric codes.  The presentation was well received, judging from the comments and discussions that we had.

I would like to thank Andrew Norton, Anil Kochhar, John Rhoads, John Walsh, Michi Tietz, Monroe Pattillo, Per Johansson and especially Norman Jones for attending and their contributions over the past years as well as today.

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com

Cell:  (414) 702-2026

<<VentModeISO.3c.2020-06-17T12.DISCUSSED.docx>>

<<VentModeISO.3c.2020-06-17T12.DISCUSSED.pdf>>

On Jun 16, 2020, at 2:38 PM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

[Paul Schluter]

Greetings!

I am sending you an updated list of infusion pump events and alerts, based on our conversations and discussions since the previous list issued on June 3rd.  It incorporates all the comments and recommendations from Christophe Fournier, Kurt Elliason, Jeff Rinda, Brian Witkowski, Al Engelbert, Steven Dain, Stefan Schlichting and others.

I have highlighted the major term-row additions with light-green shading and minor text changes with red font and have attempted to assign vendor dots as appropriate.  A new section has been added, ’Target Control Infusion (TCI)’ since we now have one event in that category (and there will probably be more in the future).  Please review the standardized IEEE 11073 event and alert terms to ensure that we are providing complete coverage of what you will need.

If you have the time and interest, please also review the vendor displayText strings and determine whether they should be re-associated with another IEEE 11073 standardized event or alert.  Any future re-association will be indicated by a ‘+’ after the displayText string to indicate that it had been moved.  Although this information is not essential for preparing IEEE P11073-10101b, the correctly associating the vendor displayText text strings with the IEEE 11073 terms will be very useful for implementers and users alike.

I plan to join the Pump WG meeting next Monday, June 22, to see if any further additions and/or corrections are required.  I believe we are getting very close to completing the infusion pump events and alerts, and together with the new MEM-DMC terms, we have a very complete set of ‘Group 2’ terms that we can elevate to “provisional” status by assigning irrevocable numeric codes.  This would allow us to largely finish these two aspects of infusion pump communication, leaving only the numeric and status observations and containment trees for future completion.

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<ListParSrcEvt.1ce.x3u.2020-06-03T08.with-generic.updated.2020-06-19T14.xls>>

On Jun 3, 2020, at 9:43 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 24th, is cancelled.  We will continue our discussion regarding ventilator mode next Wednesday, July 1st.  I have received positive feedback from several vendors and other experts and believe we are on the right track, especially with our decision to use ISO 19223 as the foundation for our work.

As homework for next week, please think about any additional states for Operational Modes and Superordinate Modes.  The current plan is to define REFIDs (and numeric codes) for the two new Mode state variables as well as for their enumerated values.  This will provide a hierarchical framework to define additional settings (and observations) associated with ’SmartCare’, ‘Automode’, ‘ASV’, and other Superordinate Modes in the future.

Thank you in advance for your thoughtful consideration, and I look forward to discussing this with you next week!

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com

Cell:  (414) 702-2026

From <VentModeISO.3c.2020-06-17T12.DISCUSSED.docx> sent to you last week:


Operational Modes

Standby

Calibration

Ventilator Breathing System (VBS) Check

Start-up procedure

In-operation

NIV

Manual

ApneaVentilation

BackupVentilation

FailSafeVentilation

          ↓

Superordinate Modes

SmartCare

Automode

ASV

MMV1

MMV2  

 ... and certain RunTimeSelectableAdjuncts that can be activated or deactivated during a case

          ↓

Ventilation Mode

Pre-coordinated { VentilationPattern - InflationTypes* PreDeterminedAdjuncts* SelectableAdjuncts* } strictly based on ISO 19223

          ↓

Breath-by-breath and inflation-by-inflation annotations

These have already defined and assigned numeric codes in the IEEE P11073-10101b 'Group 1' terms.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 1st, is cancelled.  Many are taking the week off for the US July 4th Holiday.

In the meantime, I have been working with other vendors and individuals regarding ventilator terminology and ventilator mode, so we are continuing to make progress.  We will resume our discussion next Wednesday, July 8th.

As homework for next week, please think about any additional states for Operational Modes and Superordinate Modes.  The current plan is to define REFIDs (and numeric codes) for the two new Mode state variables as well as for their enumerated values.  This will provide a hierarchical framework to define additional settings (and observations) associated with ’SmartCare’, ‘Automode’, ‘ASV’, and other Superordinate Modes in the future.

Best regards, and for those of you in the United States, have a safe and effective and enjoyable Fourth of July weekend!

Paul Schluter

Gmail:  pssch...@gmail.com

Cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, July 8, at 11:00 AM CDT.  We will resume our discussion of ventilator mode using the ISO 19223 ventilator mode string represention as the foundation for our work in IEEE 11073.  The RTM tcon information is included below.

We have made additional progress over the past several weeks by adding several foundational Ventilation Modes and Patterns (e.g. HIFLOW, HFV, …), Alternative Ventilation Mode Names (e.g. ‘bi-level AV’)  and selectable Adjuncts (e.g. (SIGH)) to the PEGjs validator and to the ISO 19223 ↔ IEEE 11073 mapping and verification.

The updated PEGjs is shown below:

Parsing Expression Grammar, using PEGjs on-line parser and validator available at http://pegjs.org/online Version (4a) with exploratory additions of HIFLOW and NIV and HFV, FR, PR VentilationMode = ( ( VentilationPattern '-' InflationType ( ( '\\' / '/' ) InflationType )? ( ( '\\' / '/' ) InflationType )? )   / 'CPAP' / 'HIFLOW' / 'Manual' / 'Standby' ) AltVentModeName Adjuncts NoteRefs VentilationPattern = ( 'CMV' / 'A/C' / 'IMV' / 'SIMV' / 'S/T' / 'CSV' / 'HFV' ) PrefixCode = ( 'vt' / 'df' / 'cdf' / 'var') TrailingCode = ( 't' / 'p' / 'q+v' / 'q' / 'v' / 'S' / 'EMG' / 'pLim' / 'x2' ) InflationType = ( PrefixCode )?                 ( 'VC↔PS' / 'VC→PC' / 'PC↔VC' / 'PC→VC' / 'VC' / 'PC' / 'PS' / 'ES' / 'DC' / 'FR' / 'PR' / '-' )                 ( ( '(' TrailingCode ')' ) / ( '{' TrailingCode '}' ) / ( '[' TrailingCode ']' ) )? AltVentModeName = ( ' ' ( 'bi-level AV/APRV' / 'bi-level AV' / 'APRV' / 'MMV-VC\\PS' / 'MMV-vtPC\\PS' ) )? Adjuncts = ( ' <' ( 'ACAPL' / 'ACAPH' / 'ACAP' ) '>' )? ' (TC)'? ' (NIV)'? ' (SIGH)'? NoteRefs = ( ' ' [0-9]+ )*

I have also attached an updated rendering of Table I.2 from ISO 19223 (2019) that now includes the Alternative Ventilation Mode Names (red font) in the ISO 19223 string (in the IsoMode column) and how it is preserved in the IEEE 11073 REFID.

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<Table I.2.1b.x1j2020-07-07T22.alt-adjuncts-notes.xls>>

[Paul Schluter]

Greetings!

I am sending you the updated notes that accompany the PEGjs and spreadsheet that we discussed earlier today (also attached).  They are reasonably in-sync and reflect our latest discussions.

I would like to thank Per Johansson, Anders Häggström, Michi Tietz, Björn Andersen, Martin Kasparick, Marufur Rahman, Naveen Sharma, Anil Kochhar, Steven Dain and Norman Jones for attending and contributing to our discussion today. 

Best regards,

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

<<VentModeISO.4a.2020-07-08T20.docx>>

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 15th, is cancelled.  Several key people are out on summer vacation so we will need to wait until late August to wrap up our work on ventilators and other topics.

For vendors who would like to have their specific ISO 19223 ventilator mode strings include in IEEE P11073-10101b, please send them to me by no later than Friday, August 28th.  Please indicate whether any ISO 19223 Adjuncts apply, and if so, whether they are fixed “pre-determined” Adjuncts (ACAP*) or “selectable" Adjuncts (NIV) and (TC).  Please also indicate whether any one of the optional AltVentModeName listed in the PEGjs below should be included.  If one or more optional Note(s) are required, please provide the text for those as well.

I also plan to assign the “provisional” numeric codes for the new observation identifiers and events and alerts for MEM-DMC and infusion pumps by the end of July, since that work has been completed and stable for quite some time.  This will facilitate the incorporation of IHE Change Proposals (CPs) with final REFIDs and numeric codes.

If there are any RTM-related topics that you would like to discuss, please let me know; otherwise, we will schedule tcons on an “as needed” basis over the next month or so.

Thanks and regards, and have a safe and enjoyable summer!

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 22nd, is cancelled.

Best regards, and enjoy your summer!

Paul Schluter

Gmail:  pssch...@gmail.com
Cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 29th, is cancelled.

[Kochhar, Anil K.]

 

Hi All,

 

I wanted to confirm if our IHE RTM WG is still scheduled for today, 29 July?

I logged on to the link below,  but Naveen and I were the only ones logged in. 

 

https://himss.webex.com/himss/j.php?MTID=mdde0759722dd578f30d23844ca7aa7aa 

Topic: PCD Rosetta Terminology Mapping WG

 

Date:   Every Wednesday

Time:   11:00 AM, Central; 12:00 Noon, Eastern;

Meeting Number:         490 820 843        Devices1

 

Best,

Anil Kochhar

 

From: Paul Schluter <pssch...@gmail.com>
Sent: Wednesday, July 8, 2020 10:26 PM
To: ihe-p...@googlegroups.com; ihe-p...@googlegroups.com; PCD Technical Committee GG <ihepc...@googlegroups.com>; ihe-pcd-...@googlegroups.com; IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>; device...@lists.hl7.org
Cc: Monroe Pattillo <monroe_...@bellsouth.net> (monroe_...@bellsouth.net) <monroe_...@bellsouth.net>; Mathieu Roullet <mrou...@enovacom.fr>; Stefan Schlichting <stefan.sc...@ornet.org>; Dalibor Pokrajac <Dalibor....@guardrfid.com>; STEVEN DAIN <sd...@rogers.com>; Jan Wittenber <jan.wi...@gmail.com>; Walsh John L.M.D. <john....@mgh.harvard.edu>; Abhyankar, Swapna <sabh...@regenstrief.org>; Alexander Kraus <alexand...@biotronik.com>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J. <john.g...@nist.gov>; Crouzier, Nicolas <nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <john....@philips.com>; Chris Courville <ccou...@epic.com>; michael.faughn <michael...@prometheuscomputing.com>; Tom.Ko...@bbraun.com; Norman Jones <nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>; Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs <kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell, Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi Zhong <daidi...@ieee.org>; Michael J. Kirwan <mki...@dsheet.com>; Lisa Perry <l.p...@ieee.org>; Björn Andersen <ande...@imi.uni-luebeck.de>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; di...@moberg.com; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike Krajnak <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Sharma, Naveen Kumar (GE Healthcare) <NaveenKum...@ge.com>; Aradhya, Lokesh (GE Healthcare) <Lokesh....@ge.com>; Woloschek, Steven J (GE Healthcare) <Steven.W...@ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; McGuire, Jay <jmcg...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Iglesias, Brian <bigl...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org; Richard Tayrien <rtay...@center4mi.org>; Spencer Crosswy <scro...@center4mi.org>; Andrew Norton <andrew...@tiscali.co.uk>; Tietz, Michael <Michae...@draeger.com>; Beier, Manfred <Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>; Anders Häggström <anders.h...@getinge.com>; Kochhar, Anil K. <Anil.K...@jhuapl.edu>; Paul Schluter <pssch...@gmail.com>
Subject: [EXT] Re: Please join our RTM tcon today, Wednesday, July 8, at 11:00 AM CDT - continuation of ventilator mode discussion and updated notes

 

APL external email warning: Verify sender pssch...@gmail.com before clicking links or attachments

 

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, August 5th, and the following Wednesday, August 12th, are cancelled.  My family and I will be vacationing in Door County next week. 

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, August 19th, is cancelled.  We will reconvene next Wednesday, on August 26th.

I am currently assigning the  “provisional” numeric codes for the new observation identifiers and events and alerts for MEM-DMC and infusion pumps.  This will facilitate the incorporation of IHE Change Proposals (CPs) with final REFIDs and numeric codes.  We will also follow up on other topics accumulated over the past month next Wednesday.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, August 26th, is cancelled.  We will reconvene next Wednesday, on September 2nd, where I will summarize the work that has been done over the past two months.

The  “provisional” numeric codes for infusion pump events and alerts have been assigned and are ready for incorporation into RTMMSv2 after Micheal Faughn has an opportunity to verify that there are no conflicts with existing terms and code assignments.  MEM-DMC numeric code assignments are next, pending verification of any pre-existing numeric code assignments.

Brian Witkowski and others in the infusion pump working group are currently working on the authoritative list of observation identifiers and containment model, and hopefully we will be able to finalize this effort over the next few weeks to facilitate timely completion of IHE Change Proposals (CPs) with final REFIDs and numeric codes.

We will review the following topics next Wednesday, including the present 10101b ‘Group2’ terms and additional groups later on ...

• Ventilator parameters and events for a major vendor
• Ventilator mode (based on ISO 19223 with bidirectional mapping to IEEE 11073)
• Dialysis Machine Data Standard for hemodialysis (using IHE PCD DEC HL7 V2 messaging)
• Infusion Pump observation identifiers and events and alerts
• Identifiers to support IHE PCD MEM-DMC device management and reporting
• Attributes, observations and events to support other IHE PCD profiles and applications

Best regards, and enjoy the last one or two weeks of summer!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, September 2, at 11:00 AM CDT.  I will summarize the current status of work over the past two months, as noted below.

Also, the Webex meeting information has changed, since we are now using IHE rather than HIMSS to provide the Webex service.  Please delete your previous calendar entries and apply or copy the new Webex invitation attached below.

Summary of RTM and IEEE P11073-10101b status:

1.  The  “provisional” numeric codes for infusion pump events and alerts have been assigned and are ready for incorporation into RTMMSv2 after Micheal Faughn has an opportunity to verify that there are no conflicts with existing terms and code assignments.  MEM-DMC numeric code assignments are next, pending verification of any pre-existing numeric code assignments.

2.  Brian Witkowski and others in the infusion pump working group are currently working on the authoritative list of observation identifiers and containment model, and hopefully we will be able to finalize this effort over the next few weeks to facilitate timely completion of IHE Change Proposals (CPs) with final REFIDs and numeric codes.

We will review the following topics this Wednesday, including the current 10101b ‘Group2’ terms and additional groups later on …

New Ventilator Parameters (Getinge/Maquet)

Ventilator mode (based on ISO 19223 with bidirectional mapping to IEEE 11073)

Dialysis Machine Data Standard for hemodialysis (using IHE PCD DEC HL7 V2 messaging)

Infusion Pump observation identifiers and events and alerts

Identifiers to support IHE PCD MEM-DMC device management and reporting

Attributes, observations and events to support other IHE PCD profiles and applications

Best regards, and I look forward to your participation today!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

New RTM Webex meeting information

Meeting number (access code): 145 134 2502 Meeting password: Devices1 Occurs every Wednesday effective Wednesday, September 2, 2020 from 11:00 AM to 12:00 PM, (UTC-05:00) Central Time (US & Canada) 11:00 am  |  (UTC-05:00) Central Time (US & Canada)  |  1 hr Join meeting Tap to join from a mobile device (attendees only) 1-866-469-3239,,1451342502## Call-in toll-free number (US/Canada) +1-650-429-3300,,1451342502## Call-in number (US/Canada)   Join by phone 1-866-469-3239 Call-in toll-free number (US/Canada) 1-650-429-3300 Call-in number (US/Canada) Toll-free calling restrictions Join from a video system or application Dial 14513...@ihe.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial 1451342...@lync.webex.com Need help? Go to http://help.webex.com

[Paul Schluter]

Greetings!

First, I would like to thank everyone who joined in our RTM meeting today:  Anders Haggstrom, Christophe Fournier, Michael Tietz, Monroe Pattillo, Norman Jones, John Garguilo, Marfur Rahman, Kurt Elliason and Steven Dain.

We covered the topics listed below, with additional information noted below:

Summary of RTM and IEEE P11073-10101b status (as of 2020-09-02 afternoon):

1.  The  “provisional” numeric codes for infusion pump events and alerts have been assigned and are ready for incorporation into RTMMSv2 after Micheal Faughn has an opportunity to verify that there are no conflicts with existing terms and code assignments.  MEM-DMC numeric code assignments are next, pending verification of any pre-existing numeric code assignments.  [not changed]

2.  Brian Witkowski has made excellent progress on the infusion pump containment tree, based on our teleconference this afternoon.  The containment tree nicely captures the containment model in a very complete and usable manner, and includes co-constraints such as unit-of-measure and enumerated values as well as cardinality and other useful information.  It also has reasonably complete Descriptions/Definitions that we can use for the IEEE P11073-10101b definitions for new pump terms.  Brian plans to updated it further before releasing it to the wider pump community.

Addition topics discussed during the RTM tcon today, including the current 10101b ‘Group2’ terms and additional groups later on …

New Ventilator Parameters (Getinge/Maquet)

20+ new numeric parameters, many related to EDI (Electronic Diaphragm Monitoring) and esophageal and transpulmonary pressures, plus EDI waveform

Proposed REFIDs and mdcDescriptions completed, discuss next 9/9 or following 9/16 RTM call

Ventilator mode (based on ISO 19223 with bidirectional mapping to IEEE 11073)

Waiting for at least one vendor to provide ISO 19223 strings (several are very close).

There were several questions that were raised.  First, one participant asked whether multiple NoteRefs can be supported, and the answer is “yes”.  Second, another participant asked whether there would be editorial and other review to avoid similar notes, and the answer to that was a strong “yes” as well - that is, if two vendors had the same or very similar notes, they would be expressed as a single numbered Note that could be shared by multiple vendors.  [We won’t really know how easy or hard it will be to “harmonize” the Notes until we have submissions from two or more vendors.  We could use the Notes in the ISO 19223 standard as a starting point, or just base it on what vendors submit.]

I have attached the latest version of <VentModeISO.4c.2020-09-02T14.docx> that has several clarifications based on our discussion today as well as a slightly updated pegjs validating parser plus some practical tips regarding it’s use, including validating a list of ISO 19223 mode strings.

Dialysis Machine Data Standard for hemodialysis (using IHE PCD DEC HL7 V2 messaging)

128 new numeric parameters, 12 new device object identifiers and 23 new events have been defined.  We’re now very close to releasing the “2nd edition” for broader review within the vendor, user and EMR communities.

Infusion Pump observation identifiers and events and alerts

As noted above, Brian Witkowksi has made excellent progress on finalizing the containment tree that captures the infusion pump observation identifiers, descriptions, co-constraints and overall organization of this type of device.  This information will be essential for completing and verifying the IEEE P11073-10101a nomenclature and facilitate future device modeling and message conformance testing.

72 new pump events have been submitted for “provisional” status to RTMMSv2.

Identifiers to support IHE PCD MEM-DMC device management and reporting

Numeric code assignments are largely complete.

Attributes, observations and events to support other IHE PCD profiles and applications

This is an ongoing process and these terms will be submitted as the last IEEE P11073-10101b ‘Group’ of terms.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

I am sending you the final “provisional” code assignments for the 10101b Group2 MDC_EVT terms for infusion pumps.  Michael Faughn has graciously verified that there are no conflicts with the REFIDs and numeric code assignment for the new terms and existing terms (see postscript below).

The first table New 10101b Group2 MDC_EVT terms of the attached file <ComparePumpEvtCodes.1x.x2a.2020-08-24T19.html> is the essential table with the numeric code assignments and is formatted and labelled just like the earlier Group1 MDC_EVT table.  The only addition is the <gp> Group# column that indicates the 10101b Group#, which is either ‘2’ (for Group2) or ‘R2’ (for Group2 terms that were originally allocated on RTMMSv1).  All entries in the first table have <gp> = ‘2’ or <gp> = ‘R2’ so they are all new terms as far as 10101b is concerned.

I have also added a <Comment> column to indicate when the <evt> REFIDs were modified from their original RTMMSv1 values.  These changes were made at the request and consent of the  IHE PCD Pump WG and all are essentially REFID-synonyms where the underlying meaning of the term definitions remain the same but the REFID is more complete or easier to understand and/or remember.

The second table is a side-by-side comparison of RTMMSv2 (2020-06-04) and new 10101b Group 2 and R2 MDC_EVT events and events used by infusion pumps (include ‘P’ Published, 10101b Group ‘1’ as well as ‘2’ and ‘R2’).  The terms are listed in ECODE10 row-order, and if the RTMMSv2 rREFID and 10101b bREFID1 entries match, the latter are highlighted in green.  [The bREFID2 column would list other 10101b REFIDs that had the same ECODE10 value (an error) but fortunately none were found.]  The side-by-side visual comparison was useful for seeing the provenance of the 10101b terms (for example, three were “defined” by the Pump WG but never entered into RTMMSv1).  [Based on the side-by-side comparison, the new 10101b Group2 MDC_EVT term code assignments look fine.]

The new Group2 and Published MDC_EVTs for infusion pumps are intended to be used with the appropriate source <src> identifiers that were listed in <ListParSrcEvt.1ce.x3u.2020-06-03T08.with-generic.updated.2020-07-27T09.symbolic-skv.consolidated.mdcx-removed.html>, also attached.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<ComparePumpEvtCodes.1x.x2a.2020-08-24T19.html>>  

    Provisional 10101b Group2 MDC_EVT code assignments for infusion pumps

<<ListParSrcEvt.1ce.x3u.2020-06-03T08.with-generic.updated.2020-07-27T09.symbolic-skv.consolidated.mdcx-removed.html>>  

    Final pump <src-evt> listing with mdcDescriptions, vendor displayText and vendor ‘dots’ showing adoption.

PS.  There was a question about the provenance of MDC_EVT_DELAY_IMPOSSIBLE (3::742) term.  According to the vendor adoption ‘dots’ on the pump events and alerts table, nobody appears to claim to use MDC_EVT_DELAY_IMPOSSIBLE (3::742) but we have to treat it as a “provisional term” for now and leave the {REFID and PartCode and definition} in place.  Also, it does not appear in IHE PCD DEC TF Vol 2 (2019) that includes IPEC and PIV and most of the pump terminology.  We can discuss this during the next Pump WG meeting to see if is actually used, but if it is not, we can declare it “withdrawn”.

PPS.  Both files below can be opened with Excel and have been formatted to prevent Excel from inserting spurious rows.  The earlier <ListParSrcEvt…html> file uses the ❖ character to separate the ’standard’ definition as well as vendor descriptive phrases to subjective evaluate ’semantic variance’ across the various descriptions.

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, September 9, at 11:00 AM CDT.  Anders Häggström and Per Johansson from Getinge plan to discuss an additional twenty+ new ventilator numeric parameters that will be included in IEEE P11073-10101b.  This includes waveforms and parameters associated with the electrical activity of the diaphragm (EDI), a processed EMG signal that indicates the level of patient neural effort during inspiration and exhalation. 

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

PS.  The Webex meeting information changed last week, since we are now using IHE rather than HIMSS to provide the Webex service.  Please delete your previous calendar entries and apply or copy the new Webex invitation attached below (the same as last Wednesday's).

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, September 16, and the following week, Wednesday, September 23, are cancelled.

Several of us are developing a common set of definitions for static and dynamic elastance term(s) and that discussion is still ongoing by email.  Also, we are looking into several issues regarding the use of the “long” and “short” forms of the ISO 19223 ventilator mode nomenclature and syntax and whether supporting both forms would make searching and cross-vendor comparison of modes unnecessarily difficult.  As a consequence, we are not quite ready to discuss this topic today.

The RTM tcon for the following week (Wednesday 9/23) is also cancelled since we will be holding the IEEE and HL7 Plenary DEV (virtual) meeting next week.  Depending on who is attending, we may be able to initially discuss some of these topics with the larger IEEE 11073 GC and HL7 DEV and GAS groups, as well as other nomenclature topics that have been identified over the past several months (e.g. site labels for rSO2 measurements).

Our next RTM tcon will be held on Wednesday, September 30, and hopefully we will be able to make final recommendations at that time.

I am also very happy to say that Brian Witkowski finished his epic effort on the infusion pump containment model and presented it to the PCD Pump WG last Monday.  After the review is completed (in about two weeks) we will then be able to finalize any remaining new infusion pump terms and assign “provisional” numeric codes.  The pump containment model will also serve as an authoritative guide for future work, including more sophisticated device modeling and message conformance testing.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, September 30, at 11:00 AM CDT.  We will focus on two ventilator topics 

(1) finalizing our definitions for static and dynamic elastance, with a proposal to replace “dynamic” with “dynostatic” in the REFID

(2) mapping Getinge ventilator modes to ISO 19223 and level of detail to maintain

The two topics are described in greater detail below, based on email discussions over the past several weeks.  [I apologize for the somewhat cluttered organization of this email, but I promise to walk everyone through it tomorrow!]

The RTM tcon for next Wednesday, October 6th, will be cancelled due to the week-long IHE DEV Virtual F2F next week, that all of you are welcome to join.  The Webex for tomorrow’s RTM tcon is provided below.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

TOPIC 1:  Static and Dynamic Elastance with a proposal to replace “_DYNAMIC” with “_DYNOSTATIC” in the REFID

We have updated the definition for elastance to “inversely” match the definition for compliance (see the last two rows of the updated spreadsheet <Elastance.1d.2020-09-29T17.xlsx>).  These two “basic” lung property terms are now (inversely) consistent with each other and ISO/IEEE P11073-10101-2004, and we will include the equation for calculating each.

Please refer to the Google Image Search for “dynostatic compliance” section at the end of this email (where the P-V figure was forcibly placed by Apple Mail).

The first section proposes additional nomenclature for static compliance (and elastance) measurements relative to three regions {low, mid, high} defined along the static compliance (or elastance) curve, basically asking the question “what else would we want to report”?

The second section examines compliance (and elastance) measurements that can be obtained using “dynostatic” extraction of a static compliance (and/or elastance) curve where broadening of the P-V loop due to resistance, hysteresis and other side-effects related to air flow have been removed.  This technique has been used by several vendors to provide an accurate determination of the ideal static compliance (and possibly elastance) curves without the need for an inspiratory pause or user-initiated maneuver(s).  In fact, it is quite possible to report the calculated static compliance (and/or elastance) curve as part of an overall “dynostatic” measurement data set every three or four (or more) inflations.

Knowing that we could support the options described in the first and second sections below, I believe we can retain the simple classic compliance (or elastance) measurements and definitions based on the transition from the plateau pressure Pplat to PEEP (BAP).  This would allow us to remain consistent with the original definition of compliance in ISO/IEEE P11073-10101-2004 and then we could add extensions as we need them to support more contemporary devices and clinical applications.

*     *     *    and in a later email     *     *     *

One change I would like to make to the REFIDs for the “dynostatic” terms is to use _DYNOSTATIC rather than _DYNAMIC in the REFID.  I’ve run across several papers and presentations that use “dynamic” to refer to a “compliance” measurement that includes pressure changes due to non-zero airflow through a resistance and/or in and out of a vessel that exhibits hysteresis.  This would apply to any new _DYNOSTATIC terms defined in 10101b, including a new preferred REFID-synonym MDC_COMPL_LUNG_DYNOSTATIC that would be used instead of the existing MDC_COMPL_LUNG_DYNAMIC (2::21528) (since this is a REFID-synonym with exactly the same meaning, we would retain the existing 2::21528 code).  This will largely eliminate any confusion for the legacy use of “dynamic compliance”, which had been a concern of mine when we published IEEE 11073-1010a-2015.

We could also consider defining the REFID-synonym MDC_RES_AWAY_DYNOSTATIC that would be used instead of the existing MDC_RES_AWAY_DYNAMIC (2::21524).

I believe “dynostatic” is a great vendor-neutral term that says exactly what it means and that avoids confusion with the use of “dynamic” compliance.  We would welcome your comments about this.

TOPIC 2:  Mapping Getinge ventilator modes to ISO 19223 … and what level of detail should we maintain?

… in an email earlier sent earlier today (Tuesday 9/29) to Norman and Steve; Anders, Per and Peter at Getinge:

Anders Häggström sent me the attached spreadsheet listing the Getinge modes and their proposed mappings to the ISOshort form as well as an internally-used ISOlong form to formulate the final ISOshort form of the mode string.

I had several questions regarding the mapping and the ISO 19223 standard and I was hoping that Norman and/or Steven could join us during tomorrow’s (9/30) RTM tcon at 11:00 AM CDT, most likely after our discussion of elastance.

One question I had regarding ISO 19223 is how much information can or should be included in the ISO 19223 mode string?  If you look at Anders' short form strings, there are several ISOshort strings that are the same for different Getinge modes.  In contrast, the ISOlong strings are all unique, but in some cases require more than one TrailingCode.  [Although Anders does not plan to use the ISOlong form for actual data exchange, it would be helpful to agree that there is at most one TrailingCode per InflationType, which appears to be the case based on the examples in the published ISO 19223 standard and in Norman’s ‘Constituent Elements’ spreadsheet.]

But before we get any farther on this, I had a few issues and questions that I would like to discuss with all of you.  I reviewed Anders' ISOlong strings and noted several adjustments that would support the additional mode concepts proposed by Getinge.  I have included these in the ISOlong2 column and have tentatively updated the PEG.js grammar to verify that they can be tested.

The following changes were made to the original Getinge ISOlong strings, as captured in the ISOlong2 column:

vLim     Added as a TrailingCode option as a single token ‘pLim’ since it represents a single concept applied to an InflationType.

p+q+t   Added as a TrailingCode option since it represents a single concept applied to an InflationType.

[CC]     Added ventilator breathing Compliance Compensation as a TrailingCode (in addition to a selectable Adjunct) since it can apply to only one of a pair of InflationTypes.  [My preference would be to implement CC as a selectable Adjunct only and eliminate CC as a TrailingCode option.]  [Another question is this strictly compliance or is it a mixture of ‘dynamic’ resistance+compliance; what about resistance?]

[LC]     Added Leakage Compensation as a TrailingCode, although for all Getinge modes it appears deployable as a selectable Adjunct.  [My preference would be to implement LC as a selectable Adjunct only and eliminate LC as a TrailingCode option.]

df        Decreasing flow pattern was added as a TrailingCode, but is this correct and/or necessary, given that we have a ‘df’ PrefixCode?

(CC)   Ventilator breathing Compliance Compensation was added as a selectable Adjunct.

(LC)   Leakage Compensation was added as a selectable Adjunct.

One significant issue is that the ISO 19223 standard and Norman’s "Constituent Elements" spreadsheet (as well as my earlier work with the ISO 19223 —> IEEE 11073 REFID —> ISO 19223 round-trip conversion) assumed at most a single (0..1) TrailingCode enclosed in (…), […] or {…}.  Supporting more than a single TrailingCode in the REFID may be difficult, so I really need to know that at most a single (0..1) TrailingCode is the upper limit in the ISO 19223 standard.

All of them are easy to address with the possible exception of the cardinality for the Trailing Codes - it was ‘?' (0..1) but now it may need to be ‘*’ (0..*) if the ISOlong forms similar to those provided by Getinge would need to be supported and there was an additional requirement that a 1:1 reversible mapping exists between the vendor and ISO strings (at least within the scope of a single vendor).

The tentatively modified PEG.js is shown below and can be used with the PEGjs on-line parser and validator available at http://pegjs.org/online 

VentilationModeList = ( VentilationMode '\n' )* VentilationMode

VentilationMode = ( ( VentilationPattern '-' InflationType ( ( '\\' / '/' ) InflationType )? ( ( '\\' / '/' ) InflationType )? )

  / 'CPAP' / 'HIFLOW' / 'Manual' / 'Standby' ) AltVentModeName Adjuncts NoteRefs

VentilationPattern = ( 'CMV' / 'A/C' / 'IMV' / 'SIMV' / 'S/T' / 'CSV' / 'HFV' )

PrefixCode = ( 'vt' / 'df' / 'cdf' / 'var')

TrailingCode = ( 'pLim' / 'vLim' / 'p+q+t' / 't' / 'p' / 'q+v' / 'q' / 'v' / 'S' / 'EMG' / 'x2' / 'CC' / 'df' / 'LC'  )

InflationType = ( PrefixCode )?

                ( 'VC↔PS' / 'VC→PC' / 'PC↔VC' / 'PC→VC' / 'VC' / 'PC' / 'PS' / 'ES' / 'DC' / 'FR' / 'PR' / '-' )

                ( ( '(' TrailingCode ')' ) / ( '{' TrailingCode '}' ) / ( '[' TrailingCode ']' ) )*

AltVentModeName = ( ' ' ( 'bi-level AV/APRV' / 'bi-level AV' / 'APRV' / 'MMV-VC\\PS' / 'MMV-vtPC\\PS' ) )?

Adjuncts = ( ' <' ( 'ACAPL' / 'ACAPH' / 'ACAP' ) '>' )? ( ' (' ( 'TC' / 'CC' / 'LC' / 'NIV' / 'SIGH' ) ')' )*

NoteRefs = ( ' ' [0-9]+ )*

The revised ISOlong2 strings are: 

A/C-VC[df][p](t) (CC)

A/C-PC[vLim](t) <ACAPH> (LC)

A/C-vtPC[pLim](t) <ACAPH> (CC) (LC)

IMV-PC\PS\PS(t){p+q+t} <ACAP>

CSV-vtPS[pLim](q) (CC)

CSV-PS[vLim](q) (LC)

CSV-vtPS[pLim](q) (CC) (LC)

SIMV-VC[df][p](t)\PS(q) (CC)

SIMV-PC[vLim](t)\PS[vLim](q) <ACAPH> (LC)

SIMV-vtPC[CC][pLim](t)\PS[vLim](q) <ACAPH> (LC)

CSV-PS[vLim](q) (LC)

CSV-vtPS[pLim](q) (CC) (LC)

CSV-PS(EMG){q} (LC)

CSV-ES[pLim](EMG) (LC)

CSV-PS(q) (NIV)

A/C-PC(q) <ACAPH> (NIV) (LC)

CPAP <ACAP> (NIV)

CSV-ES[pLim](EMG) (NIV)

CSV-PS(EMG){q} (NIV)

HIFLOW (NIV)

HFV-PC[pLim](t)

HFV-vtPC(t) (CC) (LC)

Although these validated with the modified PEG.js above, defining and implementing IEEE 11073 REFIDs may be challenging if more than one TrailingCode is permitted per Inflation Type.  Again, I do not believe that Anders is planning to send the ISOlong form, but this does suggest that certain rules should be followed (e.g. "TrailingCode cardinality is (0..1)”) and that Norman’s "Constituent Elements” spreadsheet serve as an authoritative reference regarding what may, or may not, be sent.

Thanks and regards, and I look forwards to our discussion tomorrow, and hope you can all attend!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<ISO 19223 Mode chart Getinge DRAFT version2020-09-13.pss.1c.2020-09-28T18.xlsx>>

Google Image Search for “dynostatic compliance”:

There are two reasons for showing you this simplified figure (at the end of this email, due to Apple Mail limitations regarding figure placement):

1)  A sequence of static compliance (or elastance) measurements would be very useful, but also very impractical to obtain if static measurements are used.  But the central dotted static compliance graph shows three regions of interest (blue at the lower range, green at the mid range and red at the upper range of the P-V measurements) that could be obtained from static compliance (or elastance) measures in a less time-intensive manner, and should we define a vocabulary for those, e.g.

MDC_COMPLIANCE_LUNG_STATIC_HIGH  (e.g. 85-95% ‘along the dynostatic curve’)

MDC_COMPLIANCE_LUNG_STATIC_MID  (e.g. 45-55% ‘along the dynostatic curve’)

MDC_COMPLIANCE_LUNG_STATIC_LOW  (e.g. 5-15% ‘along the dynostatic curve’)

as additional refinements relative to MDC_COMPLIANCE_LUNG_STATIC (2::20624) that we already have.  The next question is whether a similar set should be defined for MDC_ELASTANCE_LUNG_STATIC?

      Would this address vendor and clinical needs?

2)  There are several vendors that support “dynostatic” extraction of a static compliance (and/or elastance) curve without the need for an inspiratory pause or a user-initiated maneuver(s).  This allows the static compliance (or elastance) curve to be obtained far more quickly and convenient than taking a series of static measurements.  We should consider this in our vocabulary in a similar manner:

MDC_COMPLIANCE_LUNG_DYNAMIC_HIGH  (e.g. 85-95% ‘along the dynostatic curve’)

MDC_COMPLIANCE_LUNG_DYNAMIC_MID  (e.g. 45-55% ‘along the dynostatic curve’)

MDC_COMPLIANCE_LUNG_DYNAMIC_LOW  (e.g. 5-15% ‘along the dynostatic curve’)

as additional refinements relative to MDC_COMPLIANCE_LUNG_DYNAMIC (2::21528) that we already have.  The next question is whether a similar set should be defined for MDC_ELASTANCE_LUNG_DYNAMIC?

We could also report the dotted static P-V line/loop as a small array as part of an overall “dynostatic” measurement data set (along with other “named procedures” in the future).

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, October 7, is cancelled due to the week-long IHE DEV Virtual F2F this week.

The agenda and Webex information for the IHE DEV Virtual F2F is available at https://wiki.ihe.net/index.php/DEV_Domain_F2F_Oct_2020_Webex and you are welcome to attend.

We will reconvene next Wednesday, October 14.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, October 14, is cancelled.

I am sending you the PDF of last week’s presentation regarding the status of IEEE P11073-10101b nomenclature amendment, IEEE P11073-10103R Implanted Devices Cardiac nomenclature revision and other projects such as the IHE PCD Infusion Pump and industry-led Dialysis Machine Data Standard project.  Excellent progress is also being made on other efforts such as extending the nomenclature to support Getinge/Maquet ventilators.

We will reconvene next Wednesday, October 21.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<IHE_DEV_F2F_NomenclatureStatus.2020-10-06.Virtual.1c.2020-10-08T14.pdf>>

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, October 21, is cancelled.  I currently do not have any topics of broader interest to discuss today, and lately I have been working individually with the IHE DEV/PCD pump, ACM and MEM groups as well as individual vendors as we try to drive everything towards completion.

I am very happy to say that the (approximately 50) new MEM-DMC terms have now achieved “provisional" status with irrevocably assigned REFIDs and numeric codes with definitions and co-constraints such as units-of-measure and enumerated values.  These were extensively discussed last March and further refined in August and now that we have a good idea where the new infusion pump terms will be allocated, we were in a good position to completely assign all of numeric identifiers for the MEM-DMC terms.  I will send out the MEM-DMC terms later today as a separate ‘10101b Group2 MEM-DMC’ email.

I would like to thank Michael Faughn for confirming that none of the new MEM-DMC provisional terms conflict with existing terms and for supporting the new terms and provisional verification on the RTMMSv2.

The ‘10101b Group2’ terms will be largely completed when the IHE DEV/PCD pump completes their containment model analysis that has all the old and new terms they plan to use in the near future.  After that, we have two remaining 10101b term Groups to consider:  additional ventilator terms (including mode) and dialysis.

We will reconvene next Wednesday, October 28.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Monroe, Kurt and the MEM-DMC working group and colleagues,

I am sending you the (approximately 50) new MEM-DMC terms have now achieved “provisional" status with irrevocably assigned REFIDs and numeric codes with definitions and co-constraints such as units-of-measure and enumerated values.

These have also been posted on the RTMMSv2 as “provisional”, and I would like to thank Michael Faughn for confirming that the new terms do not conflict with existing terms and for providing the RTMMSv2 for new term development, verification and distribution.

The Excel column names are similar to previous IEEE P11073-10101b “provisional” term releases, but there are a few differences:

(1) This file in a ‘semi-containment’ form with one, two or three dots (. MDC_, . . MDC_, . . . MDC_) prefacing the REFIDs, since this was use to (roughly) indicate preferred containment relationships in an MEM-DMC message. [The dots will not be included in the ballot draft nor should they be included in messages.]

(2) Term-rows that are ‘official’ (rather than explanatory or examples) have a <gp> value of ‘2’ or ‘R2’ or ‘P’ (Published).  Also, these rows will have a non-null <PART> and <CODE10> value (the CF_CODE10 is computed by Excel).  [There is one term-row indicated by ‘R2’ MDC_PUMP_DRUG_LIBRARY_VERSION, that was originally captured in the RTTMSv1 and included in RTMMSv2 as of 2020-09-22.]  The pump group had also ‘privately’ defined a dozen or so new terms and these are indicated by a <gp> value of ‘2’.]

(3) Term-rows that are new “provisional” terms have a <gp> value of ‘2’ or ‘R2’, as noted earlier.  New terms are assigned to both Partition 1 and Partition 2, so this table contains a mix of partitions (including several existing ‘P’ terms from Partition 8).

(4) Some of the mdcDescriptions will be edited for clarity and conformity to IEEE-SA editorial requirements prior to the first ballot draft of 10101b.

(5) Additional units-of-measure and enumerated values may be added and these will be posted on the RTMMSv2 and made available for testing with the NIST Test Tools.

If you have any questions, please feel free to contact Monroe Pattillo, Kurt Elliason and/or myself.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<2020-02-24.DMC.1h.2020-10-19T18.cf_code10.trimmed.xls>>   [MEMDMC worksheet only]

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, October 28, at 11:00 AM CDT.

Our primary topic will be to identify and discuss “observation sets” that can be used as additional OBR-4 Universal Service Identifiers to identify the clinical or technical purpose of a set of observations or test results.

Examples of SNOMED CT (HL7 Universal ID Type SCT) terms already used by OBR-4 in a PCD DEC PCD-01 message include:

      266706003^Continuous ECG monitoring^SCT

      359772000^glucose monitoring at home^SCT

      182777000^monitoring of patient ^SCT

More recently, the IEEE Std 11073-10101-2019 nomenclature was expanded to more precisely indicate the purpose of an observation set, such as a waveform snippet for continuous (MDC_OBS_WAVE_CTS) and non-continuous (MDC_OBS_WAVE_NONCTS) waveforms used by the IHE PCD Waveform Content Module (WCM).

The immediate goal of our discussion today is to identify additional observation sets, such as an IHE PCD Medical Equipment Management (MEM) message.  Another request was to identify continuous and non-continuous physiologic data observation sets of any type to facilitate routing of incoming data.  I have listed the existing and proposed new additions for IEEE P11073-10101b plus other possibilities to help drive our discussion.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

REFID	Description	PartCode
MDC_OBS_NOS	Observation set, unspecified	1::3584
MDC_OBS_WAVE_CTS	Continuous waveforms	1::3585
MDC_OBS_WAVE_NONCTS	Non-continuous waveforms such as "snapshots" and "snippets"	1::3586
MDC_OBS_MEM	Medical Equipment Management observation set	now!
MDC_OBS_CTS	Continuous and episodic observations (typical PCD DEC observation streams)	now
MDC_OBS_NONCTS	Non-continuous data set	now
	Ventilator procedures and data sets
MDC_OBS_VENT_SPIRO	Spirometry annotated PV loops, dynostatic compliance  (or MDC_OBS_WAVE_NONCTS?)
MDC_OBS_VENT_SBT	Spontaneous Breathing Trial
MDC_OBS_VENT_FRC	Functional Residual Capacity
MDC_OBS_VENT_METABOLICS	Metabolics
MDC_OBS_VENT_CALCS	Ventilator, measured data, lab data
	Waveform snippets by parameter ...
MDC_OBS_WAVE_SPIRO
MDC_OBS_WAVE_ECG
	Alternative naming ...
MDC_OBS_MEM
MDC_MEM_DMC_OBSERVATION
MDC_MEM_LS_OBSERVATION

On Oct 21, 2020, at 9:38 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcon for today, Wednesday, October 21, is cancelled.  I currently do not have any topics of broader interest to discuss today, and lately I have been working individually with the IHE DEV/PCD pump, ACM and MEM groups as well as individual vendors as we try to drive everything towards completion.

I am very happy to say that the (approximately 50) new MEM-DMC terms have now achieved “provisional" status with irrevocably assigned REFIDs and numeric codes with definitions and co-constraints such as units-of-measure and enumerated values.  These were extensively discussed last March and further refined in August and now that we have a good idea where the new infusion pump terms will be allocated, we were in a good position to completely assign all of numeric identifiers for the MEM-DMC terms.  I will send out the MEM-DMC terms later today as a separate ‘10101b Group2 MEM-DMC’ email.

I would like to thank Michael Faughn for confirming that none of the new MEM-DMC provisional terms conflict with existing terms and for supporting the new terms and provisional verification on the RTMMSv2.

The ‘10101b Group2’ terms will be largely completed when the IHE DEV/PCD pump completes their containment model analysis that has all the old and new terms they plan to use in the near future.  After that, we have two remaining 10101b term Groups to consider:  additional ventilator terms (including mode) and dialysis.

We will reconvene next Wednesday, October 28.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

RTM Webex meeting information

Meeting number (access code): 145 134 2502 Meeting password: Devices1 Occurs every Wednesday effective Wednesday, September 2, 2020 from 11:00 AM to 12:00 PM, (UTC-05:00) Central Time (US & Canada) 11:00 am  |  (UTC-05:00) Central Time (US & Canada)  |  1 hr Join meeting Tap to join from a mobile device (attendees only) 1-866-469-3239,,1451342502## Call-in toll-free number (US/Canada) +1-650-429-3300,,1451342502## Call-in number (US/Canada)   Join by phone 1-866-469-3239 Call-in toll-free number (US/Canada) 1-650-429-3300 Call-in number (US/Canada) Toll-free calling restrictions Join from a video system or application Dial 14513...@ihe.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial 1451342...@lync.webex.com

[Paul Schluter]

Greetings!

We had a very productive discussion today regarding two topics:  (1) the additional MDC_OBS_* “observation set” identifiers and (2) a notational enhancement to the ISO and IEEE 11073 representation of ventilator mode that allows the SuperordinateMode to be expressed as a semicolon-separated prefix to the VentilatorMode, allowing the pair to be expressed as a single pre-coordinated term with a single IEEE 11073 REFID and single numeric code.

1)  New MDC_OBS_* “observation set” identifiers

The new MDC_OBS_* “observation set” identifier are shown as the last three rows.  We will hold a final discussion during this Friday’s (10/30) MEM tcon, and pending general agreement, we will assign provisional numeric codes.

REFID	Description	PartCode
MDC_OBS_NOS	Observation set, unspecified	1::3584
MDC_OBS_WAVE_CTS	Continuous waveforms	1::3585
MDC_OBS_WAVE_NONCTS	Non-continuous waveforms such as "snapshots" and "snippets"	1::3586

MDC_OBS_CTS

Continuous and episodic observations (typical PCD DEC observation streams)

MDC_OBS_NONCTS	Non-continuous observations (of any type)

MDC_OBS_MEM	Medical Equipment Management observation set

2)  Combined representation of Superordinate and Ventilator Mode in an ISO 19223 and IEEE 11073 string

The ISO 19223 standard conveys the ventilator mode using two principal concepts:  the Ventilator Mode and Superordinate Mode, and for a variety of reasons it would be highly desirable to encode them together as single pre-coordinated ISO 19223 string with a corresponding single IEEE 11073 REFID and single IEEE 11073 numeric identifier..

Norman Jones proposed that the Superordinate mode ‘MMV’ could be added as a prefix followed by a colon ‘:’ if it was necessary to specify it.  This is similar to the XML namespace notation, with the exception that the semantic meaning of the Ventilator mode that follows is not modified in any way (being comprised of concepts already defined by that standard).

Draeger	Draeger-preferred ISO	Updated ISO and IEEE
VC-MMV	MMV-VC\PS <ACAPL> 4	MMV:SIMV-VC\PS <ACAPL> 4

Note that the VentilatorPattern ‘SIMV’ preserved in the final ‘Updated ISO and IEEE’ mode string.  This captures all the relevant ventilator mode information, including Superordinate mode, as a single string, which in turn allows us to capture it as a single pre-coordinated IEEE 11073 REFID and numeric identifier.

We will use the current list of Superordinate modes in ISO 19223 as our initial list with the exception that ‘ASV’ rather than ‘MMV2’ will be used for Hamilton ASV, which seeks to minimize WOB.

This proposal will be reviewed by various vendors but based on the positive response so far, we believe we have a solution that should satisfy everyone!

I would like to thank Anil Kochhar, Bjoern Anderson, John Garguilo, Marufur Rahman, Kurt Elliason, Monroe Pattillo, Norman Jones, Michael Tietz and Steve Nichols for their contributions and participation today!

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon on Wednesday, November 4, starting at 11:00 AM CST.  We have two topics to discuss:

1)  Battery identifiers  (discussed first)

There is a relatively small number of battery identifier terms that require “provisional” numeric code assignments and there has been some discussion regarding whether only a single generic MDC_OBJ_BATT term is needed or whether additional MDC_OBJ_BATT_# (# = 1 to 9, X) pre-coordinated identifiers that allow a specific battery to be directly identified as an alert <source> should also be defined.

In both cases, the MDC_ATTR_BATT_IDENTIFIER (1::2474) attribute can be used to identify an individual battery with an alphanumeric string in an ACM or MEM-DMC message, and would be mandatory if the generic MDC_OBJ_BATT was used as the alert <source>.  The pre-coordinated MDC_OBJ_BATT_# (# = 1 to 9, X) identifiers would allow the individual battery to be identified directly by the alert <source> without MDC_ATTR_BATT_IDENTIFIER.

One reason for using the pre-coordinated identifiers is that they are more consistent with IEEE Std 11073-10427-2016: Device specialization—Power Status Monitor of Personal Health Devices which uses a similar (but not identical) set of pre-coordinated battery identifiers.  Another reasons is that the use of pre-coordinated identifiers are consistent with at least one major vendor’s gateway implementation.

We will briefly discuss this topic during today’s meeting as well as the ACM and MEM-DMC tcons later this week:

Wednesday 11/4  11:00 AM CST Rosetta

Thursday 11/5       3:00 PM CST ACM

Friday 11/6            1:00 PM CST MEM-DMC

Hopefully a consensus decision will emerge by the end of this week amongst this group and others in the IHE DEV/PCD and/or IEEE 11073 communities.  If necessary, we can also consider an informal email vote.  The vote would be whether the additional pre-coordinated MDC_OBJ_BATT_# (# = 1 to 9, X) identifiers should be defined or not.  We would, at a minimum, define the generic MDC_OBJ_BATT with the required use of the MDC_ATTR_BATT_IDENTIFIER attribute.

Additional background is provided in the email sent on Monday, November 2, 2020 at 1:21 PM (below) to members of the RTM community that design therapy delivery devices such as infusion pumps and ventilators where uninterrupted operation is essential.

2)  Combine Superordinate and AlternativeVentModeName into a single ModePrefix

This discussion will continue our deliberations from last week where we considered the use of a prefix to the ISO 19223 ventilator mode string to include the SuperordinateMode (such as ‘MMV’) to the VentilatorMode string.  This allows us to pre-coordinate both concepts into a single pre-coordinated ISO 19223 string having a single pre-coordinated IEEE 11073 REFID and numeric code, a property that several vendors view as essential for preserving round-trip fidelity (from the device to gateway to EMR and possibly back to the device).

Earlier this week, Dr. Norman Jones proposed an additional enhancement that allows the ISO AltVentModeName (e.g. ‘Bi-Level AV’) and ISO-endorsed VendorDesignations (e.g. ‘MMV’, ‘ASV’, ‘BIPAP’) to be included with the ISO SuperordinateModes (e.g. ‘MMV 1’, ‘Automode’) as a single ModePrefix.  The ModePrefix values are shown below (additional ModePrefixes can be added in the future, but there probably won’t be very many). 

ModePrefix

MMV 1 (MMV):

MMV 2 (ASV):

APRV:

Bi-Level AV:

Bi-Level AV (BIPAP):

Bi-Level (Bi-Vent):

Bi-Level (DuoPAP):

Automode:

SmartCare:

 

PEGjs for ModePrefix:

ModePrefix = ( SuperordinateMode / AltVentModeName ) ( ' (' VendorDesignation ')' )? ‘:'

SuperordinateMode = ( 'MMV 1' / 'MMV 2' / 'SmartCare' / 'Automode' )

AltVentModeName = ( 'Bi-Level AV' / 'Bi-Level' / 'APRV' )

VendorDesignation = ( 'MMV' / 'ASV' / 'BIPAP' / 'ASV' / 'Bi-Vent' / 'DuoPAP' )

The ModePrefix and colon (:) would be combined with the VentilatorMode (sans AltVentModeName, which is now in the ModePrefix).  For example, two of Dräger’s modes would be represented as shown below, with the added vendor benefit of including any VendorDesignation (e.g. ‘MMV', ‘BIPAP') unambiguously before the ISO 19223 systematic mode identifier.

DrägerMode	Superordinate-only prefix  (last week)	Combined ModePrefix  (current proposal)
VC-MMV	MMV:SIMV-VC\PS <ACAPL> 4 13	MMV 1 (MMV):SIMV-VC\PS <ACAPL> 4 13
PC-BIPAP		Bi-Level AV (BIPAP):SIMV-PC\PS <ACAP> 0 9

Notes:

  0. Biphasic Positive Airway Pressure

  4. Based on a volume controlled mode

  9. Based on a pressure controlled mode

13. Mode with automatic adjustment of RRset

In a nutshell, the ModePrefix is a useful method of identifying any labelled features {SuperordinateMode, AltVentModeName and VendorDesignation} that provide additional functionality to that of the underlying systematically named VentilatorMode (that follows the ModePrefix).

*     *     *

I would like to thank you in advance for your thoughtful consideration of this material and look forward to our discussion tomorrow!

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

From: Paul Schluter [mailto:pssch...@gmail.com] 
Sent: Monday, November 02, 2020 1:21 PM
To: Monroe Pattillo <monroe_...@bellsouth.net> (monroe_...@bellsouth.net); Elliason, Kurt (MMSP)
Cc: Paul Sherman; Tom Kowalczyk; Al Engelbert; Jeff Rinda; Christophe Fournier; John Rhoads; Michael Tietz; Per Johansson; Mike Krajnak; Paul Schluter
Subject: Final disposition for MEM-DMC MDC_OBJ_BATT* and MDC_MOC_BATT

Monroe, Kurt and colleagues,

I am sending you my latest thoughts regarding battery identifiers for MEM-DMC as well as ACM, and I believe this will work well for the vast majority of PoCD devices, including life-critical therapy devices such as ventilators and infusion pumps that may have more than two batteries.  The key technical choice is to define a generic MDC_OBJ_BATT identifier plus { _1 to _9, _X } pre-coordinated identifiers that allow a specific battery to be directly identified as an alert <source>.

Unless I hear to the contrary by Wednesday morning, these terms will be defined as a contiguous block of eleven MDC_OBJ terms in Partition 1 and they will be added to the MEM-DMC term spreadsheet.  None of the other term MEM-DMC REFIDs and numeric codes are affected by these additions.

1.  Batteries  

We will define a generic MDC_OBJ_BATT identifier that relies on the new MDC_ATTR_BATT_IDENTIFIER (1::2474) to allow any number of batteries to be identified by an alphanumeric string.  The numbered MDC_OBJ_BATT_# (# = 1 to 9, X) will support the vast majority of medical devices, including infusion pumps and ventilators (the highest number of batteries I have found is six).  This provides an unambiguous alert <source> identifier and will promote consistency between implementations, especially if the battery slots are already numbered.  The MDC_OBJ_BATT_X can be used to identify an external battery or power supply available as an option on several ventilators and anesthesia machines.

REFID	CommonTerm	Description
. MDC_MOC_BATTERY		Battery Charger or Battery Management System (1::41)
. . . MDC_ATTR_BATT_CONFIG	Battery configuration	Battery configuration (1::2473)
. . MDC_OBJ_BATT	Battery (generic)	Individual battery (generic, single or multiple independently replaceable batteries, each consisting of one or more cells)
. . MDC_OBJ_BATT_1	Battery 1	Individual battery 1
. . MDC_OBJ_BATT_2	Battery 2	Individual battery 2
. . MDC_OBJ_BATT_3	Battery 3	Individual battery 3
. . MDC_OBJ_BATT_4	Battery 4	Individual battery 4
. . MDC_OBJ_BATT_5	Battery 5	Individual battery 5
. . MDC_OBJ_BATT_6	Battery 6	Individual battery 6
. . MDC_OBJ_BATT_7	Battery 7	Individual battery 7
. . MDC_OBJ_BATT_8	Battery 8	Individual battery 8
. . MDC_OBJ_BATT_9	Battery 9	Individual battery 9
. . MDC_OBJ_BATT_X	External battery	Individual battery (external)

Question:

1a)  Should we assign more MDC_OBJ_BATT_#  identifiers?

The IEEE Std 11073-10427-2016 Power Status Monitor for PHD Devices defines codes for up to sixteen MDC_BATTERY_# batteries, with a fixed allocation of eight observations about each battery (capacity, status, etc.).  The PHD battery capacity and status information is somewhat different than what has already been defined for PoCD devices and we will continue to use and extended the PoCD terms and conventions from ISO/IEEE 11073-10101:2004 and later standards.  [PHD defines batteries 1 to 8 for a “standard” configuration and 1 to 16 for an “extended” configuration, possibly anticipating the use of individual replaceable cells purchased at consumer retail stores.]  [It should also be noted that it would be possible to deploy PHD MDC_BATTERY_# terms and object models as “child” nodes of MDC_MOC_BATTERY, if supported by a IHE PCD PoCD containment model in the future.]

I have also reviewed the manuals and specifications for infusion pumps, ventilators and anesthesia machines, and all can be supported MDC_OBJ_BATT_# (# = 1 to 9, X) above.  This includes the use of modular data acquisition slots as additional battery slots.

Thus, MDC_OBJ_BATT and MDC_OBJ_BATT_# (# = 1 to 9, X) will be defined as eleven contiguous terms in Partition 1.

2.  Battery management system

A single MDC_MOC_BATTERY (1::41) was defined in ISO/IEEE 11073-10101:2004.  Although IEEE Std 11073-10201-2018 only supports a single MDC_MOC_BATTERY at the present time, it would be possible to support multiple MDC_MOC_BATTERY management subsystems within a single device or system, with each MDC_MOC_BATTERY subsystem identified by an attribute such as MDC_ATTR_CHAN_NUM_PHYS (1::2319).

Unless I hear to the contrary by Wednesday morning (11/4) at 10:30 AM CST, these terms will be defined as a contiguous block of eleven terms in Partition 1 and added to the MEM-DMC term spreadsheet.  Again, none of the other term MEM-DMC REFIDs and numeric codes are affected by these additions.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, November 11, is cancelled.  Several vendors are internally reviewing the proposed addition of the ISO ModePrefix to convey the { Superordinate, AlternativeVentModeName and VendorDesignation } as we discussed last week, and we have not heard from everyone at this time.

I have provided a recap of where we are at the present time:

1)  New 10101b Group2 MEM-DMC and other new 10101b Group2 P01, P03 and P04 terms

New 10101b Group2 MEM-DMC terms

This is essentially the same spreadsheet as before <<2020-02-24.DMC.1j.2020-10-29T17.added-uom-mdc.xls>> plus the following additions:

1.  Added eleven new terms MDC_OBJ_BATT and MDC_OBJ_BATT_# (# = 1 to 9, X) with numeric codes.

2.  Added new term MDC_TIME_PD_PUMP_INFUSING_TIME_SINCE_LAST_CAL (2::53130) requested by Al Englebert

2.  Added one more Enum_Values options and Enum_Descriptions for the Authentication method.

New 10101b Group2 P01, P02 and P04 terms

Most of these are supporting terms for MEM-DMC as well as other recent requests.

P01  Several new terms, including MDC_OBS_MEM (1::3599) required for OBR-4 in a MEM-DMC message.

P03  Several MDC_EVT_ON_BATT_LT_nn_MIN_REMAIN battery warnings to cover alerts reported by several vendors.

P04  Several UOM_MDC units-of-measure to support MEM-DMC.

Proposed “provisional” numeric codes have been assigned for all of the terms above and were submitted to Michael Faughn last week to further confirm that there are no numeric code conflicts with respect to RTMMSv2.  After I receive confirmation from Michael I will send out the final “provisional” MEM-DMC terms and codes that will be included the first ballot draft of IEEE P11073-10101b.

2)  Combine { Superordinate, AlternativeVentModeName and VendorDesignation } into a single optional ISO ModePrefix

The proposal to combine the Superordinate, AlternativeVentModeName and Vendor designation into a single and optional ISO Mode Prefix that we discussed last week is currently being internally reviewed by several vendors and is very likely to be adopted.  An updated synopsis is provided below:

The ISO Ventilator Mode string described in the previous sections may be prefaced by the ISO ModePrefix that contains the SuperordinateMode, AltVentModename and VendorDesignation.  The ModePrefix provides a useful method for identifying labelled features that provide additional familiarity and functionality to that of the underlying systematically named ventilation-mode

ModePrefix = ( SuperordinateMode / AltVentModeName ) ( ' (' VendorDesignation ')' )? ':'

SuperordinateMode = ( 'MMV 1' / 'MMV 2' / 'SmartCare' / 'Automode' )

AltVentModeName = ( 'Bi-level AV' / 'APRV' )

VendorDesignation = ( 'MMV' / 'ASV' / 'BIPAP' / 'ASV' / 'Bi-Vent' / 'DuoPAP’ ) 

       The SuperordinateMode identifies the overall ventilatory objective, such as maintaining a minimum minute volume (MMV) by automatically adjusting one or more ventilator settings and/or selecting the optimal ventilator mode.

       The AltVentModeName specifies an alternative to the systematic ventilation mode name.  It can be either a standardized generic name or a proprietary name that often has an overriding and clinically significant combinations of features that justify its use as an alternative ventilation mode name (that said, the systematic name is still required).

       The VendorDesignation supports vendor proprietary ventilator mode names, enclosed in parenthesis to denote their informative and optional role in the ModePrefix.

The recognized ISO ModePrefixes and mapping to the IEEE ModePrefix are shown below.   Although numeric modifiers such as ‘1’ and ‘2’ are encoded similarly to NoteRefs, they are pre-coordinated with the preceding token as a single semantic concept.  The ISO ModePrefix and IEEE ModePrefix use a ‘:’ and ‘_0_’ delineator to terminate the ModePrefix. 

ISO ModePrefix	IEEE ModePrefix	Comments
MMV 1 (MMV):	MMV_01_3MMV_0_	ISO : maps to IEEE _0_  (both are unique markers)
MMV 2 (ASV):	MMV_01_3MMV_0_
APRV:	APRV_0_
Bi-level AV:	Bi9level_AV_0_
Bi-level AV (BIPAP):	Bi9level_AV_3BIPAP_0_
Bi-level AV (Bi-Vent):	Bi9level_AV_3Bi9Vent_0_
Bi-level AV (DuoPAP):	Bi9level_AV_3DuoPAP_0_
Automode:	Automode_0_
SmartCare:	SmartCare_0_

Note 1:    Bi-level is spelled with a lower-case ‘l’ since a capital ‘L’ looked too much like a proprietary name.

Note 2:    The nine ModePrefixes listed above are currently the only recognized sets, even though other permutations are permitted.

Note 3:    The ModePrefix eliminates the need for AltVentModeName to be expressed in the main VentilatorMode; the ‘1’ and ‘2’ provide a formal indication of the two variants of ‘MMV’, further clarified by (MMV) and (ASV), and eliminate the need for MMV-VC\PS and MMV-vtPC\PS since the two structured suffixes are already expressed in the main VentilatorMode string after the colon.

 

3)  Infusion Pump Terms

Further progress regarding the infusion pump terms is dependent on the final review and approval of the pump containment tree and incorporation of several new terms and enumerated values proposed by infusion pump working group members.

4)  Dialysis Machine Data Standard

We will be presenting our second (and final) webinar regarding the Dialysis Machine Data Standard on Thursday, November 19, at 10:00 AM CST.  It is a very complete specification and profile, and includes an HL7 V2 Implementation Guide based on IHE PCD DEC and ACM, a complete IEEE 11073 nomenclature with co-constraints (UoM and Enum_Values and Enum_Definitions), complete containment models for both observations and events/alerts and other material.  The new terms and definitions will be included in IEEE P11073-10101b.

If you are interested in attending the webinar, please contact John Mulholland at John.Mu...@davita.com .

*     *     *

I would like to thank Al Engelbert, Björn Andersen, Anders Häggström, Marufur Rahman, Michi Tietz, Monroe Pattillo, Anil Kochhar, Norman Jones and Andrew Norton and Steven Nichols for their contributions at last week’s RTM tcon.

And to everyone in the United States, I wish you a meaningful Veterans Day today.

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The IEEE ModePrefix for the ISO ModePrefix 'MMV 2 (ASV):’ has been corrected to 'MMV_02_3ASV_0_’ in the second row of the table below.  It was copied from an early planning document rather than actual XSLT output.

Best regards,

Paul

On Nov 11, 2020, at 9:53 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

MMV 2 (ASV):

MMV_02_3ASV_0_

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, November 18, is cancelled.  I expect that many of you will be listening in on the NIST NCCoE Securing Telehealth Remote Patient Monitoring session that starts at 11:00 AM CST tomorrow.  You can obtain information about the NIST NCCoE and other sessions at https://standards.ieee.org/events/wamiii/virtual-talk-series-2020.html#sessions if you have not already received this information directly from the IEEE.

In the meantime, we are making excellent progress towards mapping vendor ventilator modes to ISO 19223.  I am very happy to say that two vendors, Dräger and Getinge, have submitted complete ISO 19223 mappings that have been reviewed and approved by their engineering, regulatory and marketing groups.  I plan to incorporate their mappings along with earlier vendor mappings from Table I.2 ISO 19223 as we begin to draft the text and tables that will be included in IEEE P11073-10101b.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, November 25, is cancelled.  Many of you are planning to take a few days off for Thanksgiving Day in the US, and most of our other meetings have already been cancelled this week.

I would like to thank Drs. Steven Dain and Norman Jones for reaching out to other ventilator vendors who worked on the ISO 19223 standard to see if they will contribute lists of their ventilator modes and proposed mappings to the ISO 19923 ventilator mode nomenclature.  This will help further promote the adoption of ISO 19223 as well as equivalent IEEE 11073 representation of this information.

We are also making excellent progress on assigning “provisional” numeric codes for the twenty or so new infusion pump terms, thanks to the excellent work by Brian Witkowski, Kurt Elliason and others on the IHE DEV/PCD pump working group.  These will be submitted to Michael Faughn within the next few days for final confirmation and adoption as “provisional” terms.  This will complement and complete the extensive set of pump events and alerts and MEM-DMC terms intended to support this important class of device.

On a final note, we held a very successful Webinar #2 for the Dialysis Machine Data Standard last Thursday.  After we complete our review of the comments within the next few weeks we will likely be in a good position to assign “provisional” numeric codes to those as well.

That’s it for now, and Happy Thanksgiving Day to everyone in the United States!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, December 2nd, starting at 11:00 AM CST.  I will provide a summary of our progress over the past several weeks.  We will also review some “findings” regarding the use of the ISO 19223 ventilator mode syntax and nomenclature that reconfirmed our earlier decision to retain the entire ISO 19223 string as a single pre-coordinated concept (string) that will be represented by a single IEEE 11073 REFID and numeric code.

Infusion pump terms:  IEEE 11073 numeric codes have been assigned to the twenty or so new infusion pump metric and status terms.  After Michael Faughn re-confirms that there are no conflicts with existing terms, the terms be elevated to “provisional” status and will be posted to the broader RTM community.  These terms, plus the earlier infusion pump events and alerts and MEM-DMC terms, will comprise the entirety of the 10101b Group2 set of pump-related terms.

Dialysis Machine Data Standard:  After a very successful Webinar #2 we are beginning to receive comments and have not found any showstoppers so far.

Ventilator Mode:  I will walk through some work using the Draeger and Getinge/Maquet ventilator mode mappings to ISO 19223 that reconfirmed our earlier decision to retain the entire ISO 19223 mode expressing as a single pre-coordinate string and single pre-coordinated IEEE 11073 REFID and single numeric code.  Although this potentially increases the number of numeric codes, the increase is relatively modest, and the precoordinated representation provides the greatest degree of semantic fidelity with the original vendor modes.

Several conclusions can be drawn from this work, which will be explained during the RTM tcon:

1.   Keep the entire ISO { ModePrefix, VentilatorMode, Adjuncts and Notes } together as a single pre‑coordinated concept.  Although splitting into two (or more) subfields would reduce the number of pre‑coordinated concepts, the potential loss of semantic fidelity is too high.  Keeping everything together is clean, simple and fully preserves the vendor semantics.

2.   If a subset had to be chosen, it would be the five { TC, CC, LC, NIV, SIGH } Selectable Adjuncts, since they are relatively independent of the other Individual subcomponents of the ISO Systematic mode.  However, the reduction of the number of permutations is simply not worth the added complexity when trying to preserve the relationship with any Notes associated with the ventilation mode.

3.   Including additional Selectable Adjuncts in the future will not dramatically increase the number of unique codes – the growth is not exponential!   The number of unique permutations is not that high and could be easily accommodated by reserving 2K to 4K of codes (in Partition 7).

At the present time we have:

Draeger  (136 modes, 35 modes with Selectable Adjuncts removed, TC, NIV and SIGH are used, 18 Notes) 

Getinge  (22 modes, 20 modes with Selectable Adjuncts removed, CC, LC and NIV are used, 9 Notes) 

We are currently soliciting additional ISO 19223 mappings from other vendors.

Best regards, and I look forward to our discussion later today!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

Parsing Expression Grammar  PEGjs  Version 5c  2020-11-10

Parsing Expression Grammar, using PEGjs on-line parser and validator available at http://pegjs.org/online Version (5c) supports { SuperordinateMode, AltVentModeName and VendorDesignation } as an optional ModePrefix VentilationModeList = ( VentilationMode '\n' '\n'? )* VentilationMode VentilationMode = ( ModePrefix ':' )? ( ( VentilationPattern '-' InflationType ( ( '\\' / '/' ) InflationType )? ( ( '\\' / '/' ) InflationType )? )   / 'CPAP' / 'CSV' / 'HIFLOW' / 'Manual' / 'Standby' ) PreDeterminedAdjuncts SelectableAdjuncts NoteRefs

ModePrefix = ( SuperordinateMode / AltVentModeName ) ( ' (' VendorDesignation ')' )? SuperordinateMode = ( 'MMV 1' / 'MMV 2' / 'SmartCare' / 'Automode' )

AltVentModeName = ( 'Bi-level AV' / 'APRV' ) ? VendorDesignation = ( 'MMV' / 'ASV' / 'BIPAP' / 'Bi-Vent' / 'DuoPAP' )

VentilationPattern = ( 'CMV' / 'A/C' / 'IMV' / 'SIMV' / 'S/T' / 'CSV' / 'HFV' ) PrefixCode = ( 'vt' / 'df' / 'cdf' / 'var')

TrailingCode = ( 'pLim' / 'vLim' / 'q+v' / 'p+q+t' / 't' / 'p' / 'q' / 'v' / 'S' / 'EMG' / 'x2' / 'CC'  / 'LC' )

InflationType = ( PrefixCode )?                 ( 'VC↔PS' / 'VC→PC' / 'PC↔VC' / 'PC→VC' / 'VC' / 'PC' / 'PS' / 'ES' / 'DC' / 'FR' / 'PR' / '-' )                 ( ( '(' TrailingCode ')' ) / ( '{' TrailingCode '}' ) / ( '[' TrailingCode ']' ) )*

PreDeterminedAdjuncts = ( ' <' ( 'ACAPL' / 'ACAPH' / 'ACAP' ) '>' )? SelectableAdjuncts = ( ' (' ( 'TC' / 'CC' / 'LC' / 'NIV' / 'SIGH' ) ')' )*

NoteRefs = ( ' ' [0-9]+ )*

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, December 9th, starting at 11:00 AM CST.

The primary objective for today’s meeting is to continue and likely conclude our discussion from last week where we considered conveying the five Selectable Adjuncts { TC, CC, LC, NIV, SIGH } as a separate companion observation and thus reduce the number of permutations if everything was sent as a single pre-coordinated mode.  This proposal was well received by Michi Tietz (Draeger) and Anders Häggström (Getinge) and I later sent them the preliminary analysis that I had shared with everyone on the call last week.

I am following up today with a more comprehensive review to confirm that there is no dependency between the Notes and Selectable Adjuncts for each group of ISO Modes that have the same base mode after the Selectable Adjuncts have been removed.  This is shown for Draeger and Getinge in the two attached HTML files, where rows having the same <RemovedSelAdj> column values are grouped together and shaded with light green or blue (or by a white background if only a single row).  The key takeaway is that for both vendors, all rows within each contiguous set have the same Notes, which in turn allows us to express { TC, CC, LC, NIV, SIGH } in a separate companion sequence of Booleans.  This, in turn, substantially reduces the number of “base” ISO 19223 modes to the distinct values listed in the <RemovedSelAdj> column.

I have encountered only one situation where a vendor may want to use a Note to distinguish two NIV modes, one intended for when a full face mask is used and the other where a nasal mask is used.  We can still support Notes specific to the use of a Selectable Adjunct if we need to if we treat the separate companion variable as conveying additional Selectable Adjuncts that would be merged with any listed in the “base” ISO 19223 string.  Thus we can continue to support the flexibility of the ISO 19223 encoding as well as IEEE 11073 numeric codes and Booleans.

That’s it for now.  We’re making excellent progress, and I am looking forward for ventilator mode mappings to ISO 19223 provided by other vendors!  I’d like to thank everyone who participated in last week’s call, including Norman Jones, Michi Tietz, Anders Häggström, Brian Witkowski, Steven Nichols, Marufur Rahman and John Garguilo. 

Another piece of good news is that we will be posting the final set of IEEE P11073-10101b Group2 “provisional” terms for infusion pumps today.  Kudos to Kurt Elliason and Brian Witkowski and others in the infusion pump working group for all their hard work on this!

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<ISO-Filter.2a.2020-12-09T08.Draeger.html>>

<<ISO-Filter.2a.2020-12-09T08.Getinge.html>>

On Dec 2, 2020, at 8:51 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

RTM Webex meeting information

[Paul Schluter]

Season's Greetings!

Please join our RTM tcon today, Wednesday, December 16th, starting at 11:00 AM CST.

This will be our last call for the year and our principal topic will be to wrap up our discussion regarding Selectable Adjuncts.  I have attached a short technical note regarding the topic (attached) that discusses the following:

1.  Two new proposed Selectable Adjuncts

(TRG)  Trigger compensation  (e.g. automatically adjust flow trigger to compensate for leaks)

Note:  The proposed (TRG) ‘Trigger Compensation’ Selectable Adjunct could be made part of a separate ‘trigger source’ variable that would also specify the { flow, pressure, EMG, neural, complex-computed, chest-wall-motion, transthoracic impedance } trigger source.

(FGF)  Fresh Gas Flow  (anesthesia)

2.  Policies regarding sending Selectable Adjuncts that are sent in the (1) pre-coordinated ISO 19223 Mode and/or (2) as zero-or-more Booleans conveyed by a separate variable.

On a final note, I am very happy to say that a third major vendor, GE Healthcare, has largely completed their mapping of the ventilation modes to the ISO 19223 syntax and nomenclature!

I look forward to our conversation today, and if you are unable to join, Best Wishes for the Holiday Season!

Sincerely,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<Adjuncts.1b.2020-12-16T09.docx>>

[Paul Schluter]

Season’s Greetings, again!

We had a productive discussion today regarding ISO 19223 Selectable Adjuncts, and I would like to thank everyone who attended:  Norman Jones, Anil Kochhar, Björn Anderson, Charles Parisot, Kim Brauer, Steve Nichols and Anders Häggström.  [Last week’s participants included Norman Jones, Björn Anderson, Michi Tietz, John Gargulio and Steve Nichols.]

Regarding the addition of the two new proposed Selectable Adjuncts (TRG) and (FGF), there was some concern that we could be adding too many Selectable Adjuncts to the systematic ISO Mode identifier, and that perhaps some of these should be reported separately as ordinary “settings”, similar to how other information such as the trigger source/method and the dozen or so numeric settings related to a mode would be sent.  On the other hand, we also want to avoid defining numerous variables to contain all this information, since this could make it more difficult to preserve round-trip fidelity of the entire set of information related to ventilator modes.

One possibility is to continue with approach of using the ISO Mode to convey Selectable Adjuncts that are essential to differentiating between vendor modes, such as the use of (NIV) to indicate non-invasive modes.  During our discussion we considered a compromise where the use of the companion set of Mode-related Booleans would allow us to define different subsets of Selectable Adjuncts based on where they are expressed:

1)  only in the ‘main’ pre-coordinated ISO Mode.  Example:  (NIV) and other Selectable Adjuncts that are required to distinguish between vendor modes.

2)  either in the ‘main’ pre-coordinated ISO Mode or in the Mode-related Booleans.  Example:  (TRG) and others

3)  only in the Mode-related Booleans.  Example:  items that are more like “settings” that are not specified as individual setting identifiers.

4)  as separately named settings.  Example:  (TRG) could be conveyed with the enumerated trigger source identifiers.

I would appreciate it if each vendor could indicate how they prefer to place their Selectable Adjuncts and other Mode-related Booleans.  The only “hard and fast” rule here is that vendor mode mappings to the ISO Mode for a given vendor shall the 1:1 reversible.  If Selectable Adjunct(s) and/or Note(s) fulfill that requirement, then they should be deployed in the pre-coordinated IEEE REFID and ISO 19223 Mode strings.  I am reasonably confident that a sensible and coherent solution will emerge and we certainly have the flexibility to address everyone’s concerns.

We also had an opportunity to discuss the proposed ISO 19223 ventilator modes for the GE Carescape R860 Ventilator and CS750 Anesthesia Carestation.  This included how to best classify the Selectable Adjuncts (according to 1, 2, 3 or 4 above and whether or not quantitive criteria existed for designating the use of ACAP as a Pre-determined Adjunct.  I would also like to take this opportunity to thank Kimberly Brauer, Steve Brauer and their colleagues at GE Healthcare on their excellent work.

In closing, I indicated that this was last RTM tcon for this year and that we will reconvene on Wednesday, January 6th.  I plan to finalize the “provisional” REFIDs and numeric codes for the Dialysis Machine Data Standards project (Group3) and follow that with assigning provisional numeric code identifiers for the new numeric observations, settings and events and alerts for Getinge/Maquet (Group4).  That will be followed by reviewing additional new terms proposed by the OpenSDC and IHE PCD domain, as well (of course) finalizing the numeric codes and containing observations for the ISO 19223 and IEEE 11073 Ventilation Mode mapping project.

Thanks again to everyone who participated today as well as last week, and to all, have a safe and enjoyable Holiday Season!

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Meier, Norbert]

Hello Paul,

 

thanks for taking me to the mailing list.

In the coming year I will deal more intensively with the matter and hope to be able to make contributions in Kai's sense.

 

I wish you happy holidays and stay healthy

Norbert

 

From: ihe-p...@googlegroups.com <ihe-p...@googlegroups.com> On Behalf Of Paul Schluter

Sent: Thursday, December 17, 2020 12:35 AM
To: ihe-p...@googlegroups.com; ihe-p...@googlegroups.com; PCD Technical Committee GG <ihepc...@googlegroups.com>; ihe-pcd-...@googlegroups.com; IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>; device...@lists.hl7.org

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Terminology Mapping Profile WG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm/93F8C696-5177-4791-A16B-DCFBB5F12237%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Terminology Mapping Profile WG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm/93F8C696-5177-4791-A16B-DCFBB5F12237%40gmail.com.

 

 

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Terminology Mapping Profile WG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm/93F8C696-5177-4791-A16B-DCFBB5F12237%40gmail.com.

 

 

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Terminology Mapping Profile WG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm/93F8C696-5177-4791-A16B-DCFBB5F12237%40gmail.com.

---

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[Paul Schluter]

Happy New Years, everyone!

Please join our RTM tcon today, Wednesday, January 6th, starting at 11:00 AM CST. 

For our first meeting this year, I plan to walk through some recent work done with the Dialysis Machine Data Standards project.  This work was a collaborative effort by the major dialysis vendors and service providers and has now reached the point where the proposed IEEE P11073-10101b nomenclature for hemodialysis observations, settings, enumerated values, events and alerts, device objects and containment model have been defined and “provisional” numeric codes have been assigned.  This effort constitutes the third major set of terms, aka “Group3”, for IEEE P11073-10101b.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, January 13th, is cancelled.  I don’t have any major new nomenclature topics to discuss today.  We will likely have an RTM next Wednesday to cover any items prior to the HL7 and IEEE 11073 virtual Working Group meetings that will be held during the week of January 25 - 28.

During last week’s meeting we discussed the IEEE P11073-10101b nomenclature developed for the Dialysis Machine Data Standards project, including hemodialysis observations, settings, enumerated values, events and alerts, device objects and containment model.  I would like to thank Monroe Pattillo, Steven Nichols, John Garguilo, Anil Kochhar and Steven Dain for their attendance and participation.

The new dialysis terms were submitted to Michael Faughn on January 9th for independent verification that the “provisional” numeric codes do not conflict with existing terms and codes.  This effort constitutes the third major set of terms for IEEE P11073-10101b, aka “Group3”.

The next set of terms, “Group4", will include the additional numeric observations, settings, waveforms and events and alerts to support Getinge/Maquette ventilators.  This work was an enjoyable collaborative effort with Per Johansson and Anders Häggström and others at Getinge.  After that, terms defined in “Group5” will be based on a mapping of the ISO 19223 ventilator mode nomenclature and syntax to IEEE 11073 REFIDs, numeric encoding and other conventions.  This work supports ventilator modes originally published in the ISO 19223 standard as well as ventilators and anesthesia machines made by Dräger, Getinge and GE Healthcare.

That’s it for now!  If you have any other questions or comments, please let me know!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

On Jan 6, 2021, at 9:52 AM, Paul Schluter <pssch...@gmail.com> wrote:

Happy New Years, everyone!

Please join our RTM tcon today, Wednesday, January 6th, starting at 11:00 AM CST. 

For our first meeting this year, I plan to walk through some recent work done with the Dialysis Machine Data Standards project.  This work was a collaborative effort by the major dialysis vendors and service providers and has now reached the point where the proposed IEEE P11073-10101b nomenclature for hemodialysis observations, settings, enumerated values, events and alerts, device objects and containment model have been defined and “provisional” numeric codes have been assigned.  This effort constitutes the third major set of terms, aka “Group3”, for IEEE P11073-10101b.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

RTM Webex Meeting Information

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, January 20th, is cancelled.  The inauguration of Joe Biden as the 46th President of the United States will take place at noon (12:00 PM EST) tomorrow, along with Kamala Harris as Vice President.  I am sure everyone will be tuned in for this significant event.

The RTM tcon for the following Wednesday, January 27th, is also cancelled, due to the virtual HL7 and IEEE 11073 General Committee meetings that will be held next week.  We plan to devote at least one hour to Rosetta and IEEE P11073-10101b nomenclature effort as well as additional related topics.  The nomenclature presentation and discussion is currently scheduled for Tuesday, January 26, starting sometime after 9:00 AM Pacific Standard Time).  I will forward a link to the meeting agenda and teleconference information after it is finalized.

Michael Faughn and I are currently making rapid progress on transferring and validating the entire set of IEEE P11073-10101b Group1, Group2 and Group3 terms as “provisional” terms, to be incorporated into RTMMSv2:

Group1:  630+ events and alerts, NMT, rSO2 and other parameters  [already verified for “provisional” status]

Group2:  Infusion pump observations and events and alerts, MEM-DMC terms  [pump events and alerts previously verified for “provisional” status]

Group3:  Hemodialysis (numeric observations, settings, events and alerts)  [to be verified for “provisional” status]

I have combined the thirteen Excel and HTML lists and/or tabular containment models that comprise this work into a single consolidated HTML file.  This will help facilitate Michael’s efforts and also serve as a framework for generating the tables and table sub-sections as they will be published in the draft IEEE P11073-10101b standard.

The following IEEE P11073-10101b term Groups are next:

Group4:  Additional numeric observations, settings, waveforms and events and alerts to support Getinge/Maquette ventilators  [ready for numeric code assignment]

Group5:  Mapping of the ISO 19223 ventilator mode nomenclature and syntax to IEEE 11073 REFIDs, numeric encoding and other conventions.  This work supports ventilator modes originally published in the ISO 19223 standard as well mappings to support ventilators and anesthesia machines made by Dräger, Getinge and GE Healthcare.  [nearly ready for numeric code assignment]

Group6:  Terms required for the BPKP (IEEE P11073-10700) ballot (provided by Bjoern Andersen) and other additional terms.

These topics (and others) will discussed during next week’s IEEE 11073 General Committee, and I look forward to seeing you there!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

I am very pleased to announce that the entire set of IEEE P11073-10101b Group1, Group2 and Group3 terms are now available as irrevocably assigned “provisional” numeric codes.  I would like to thank Michael Faughn who has confirmed that there are no REFID and numeric code conflicts with existing terms or any other terms within this set.  Michael plans to make the terms available on RTMMSv2 at a later date, but for now the set of files attached to this email should suffice.  I also plan to post the files on the IEEE-SA iMeet Central site later today at https://ieee-sa.imeetcentral.com/11073-nomenclature/ .

The three IEEE P11073-10101b term Groups are summarized below:

Group1:  630+ additional events and alerts covering devices used in the ICU, CCU, OR and ER as well as NMT, rSO2 and other parameters

Group2:  IHE PCD Infusion pump observations, settings, and events and alerts and MEM-DMC terms

Group3:  Hemodialysis (numeric observations, settings, events and alerts, containment model) that support the Dialysis Machine Data Standard project

The Excel and HTML lists and/or tabular containment models that comprise this work have been consolidated into a single unified HTML file.  In addition to the IEEE 11073-10101b terminology it includes co-constraints for units-of-measure (MDC and UCUM) and enumerated values and descriptions, similar to the NIST hRTM.  These are described at the end of this email.

The following IEEE P11073-10101b term Groups will be next:

Group4:  Additional numeric observations, settings, waveforms and events and alerts to support Getinge/Maquet ventilators  [ready for numeric code assignment]

Group5:  Mapping of the ISO 19223 ventilator mode nomenclature and syntax to IEEE 11073 REFIDs, numeric encoding and other conventions.  This work supports ventilator modes originally published in the ISO 19223 standard as well mappings to support ventilators and anesthesia machines made by Dräger, Getinge and GE Healthcare.  [nearly ready for numeric code assignment]

Group6:  Terms required for the BPKP (IEEE P11073-10700) ballot (provided by Bjoern Andersen) and other additional terms.  [nearly ready for numeric code assignment]

I would like to thank everyone who has contributed to this effort, including the IHE PCD/DEV domain, the IEEE 11703 and Dialysis Machine Data Standard communities, NIST and Prometheus Computing, as well as experts from the vendor, provider, research and other communities.  Without your help and guidance, this effort would have been far more difficult, if not impossible.

These topics (and others) will be discussed during next week’s IEEE 11073 General Committee, most likely during Tuesday Q1 or Q2 (PST).

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

The final consolidated file is a single HTML table that aggregates new terms from

Group1:  630+ events and alerts, NMT, rSO2 and other parameters

Group2:  infusion pump observations and events and alerts, MEM-DMC terms

Group3:  hemodialysis (numeric observations, settings, events and alerts)

compiled from multiple Excel and HTML lists and/or tabular containment models submitted by contributing working groups, vendors and individuals.

General properties of the consolidated list include:

1.  Duplicate terms have been removed, i.e. a new 10101b term will be included only for the Group that it first appears in, and only once.  [Each term was assigned a group identifier ‘P’ (published), ‘1’ (Group1), ‘2’ or ‘R2’ (Group2, R2 from RTMMSv1) and ‘3’ (Group3) to facilitate and manage this.]

2.  I have retained the term discriminator suffixes to show what is actually used, which has been our practice with [MMM] and _SETTINGs, and this is reflected in the PartCode and CF_CODE10 values that always correspond to the REFID.

3.  All columns that can have multiple enumerated choices (e.g. UOM_MDC and UOM_UCUM, Enum_Values and Enum_Descriptions) are formatted by listing them within a single HTML table cell with each row terminated by a <br> except for the last.  In cases where the Excel source files split these into multiple Excel rows, they were coalesced into a single HTML table cell.

4.  HTML markup is not included in the table cells but will be preserved in the ballot draft of IEEE P11073-10101b (similar to ISO/IEEE 11073-10101a-2015).

Simple error checking performed by the XSLT when creating the consolidated HTML included:

1.  Verified that Part::Code and CF_CODE10 values are consistent and non-zero.  [This was primarily a check to ensure that Excel calculated CF_CODE10 correctly, especially if the Excel was modified after the initial calculated value.  This was not an issue for CF_CODE10 calculated by XSLT.]

2.  Verified that the same number of UOM_MDC and UOM_UCUM sub-rows are listed.

3.  Verified that the same number of Enum_Values and Enum_Descriptions sub-rows are listed.

A significant number of more sophisticated tests were applied during the preparation of the source HTML and Excel files but were not repeated for the consolidated HTML listing, since I plan to use this as a framework for generating the tables and table sub-sections for the draft IEEE P11073-10101b standard.

Here are the essential columns and additional details regarding each:

REFID

Containment model dots were removed and MDCX_ was converted to MDC_

If this was an UOM_MDC (PART=4) the REFID will be valued by UOM_MDC, selected by (REFID, UOM_MDC)[1]

There were two instances of where a new preferred REFID was defined but the now less-preferred published terms were not listed, shown below. The preferred REFID is always listed first.

REFID	Description	gp	s	Disc	PartCode	CF_CODE10
MDC_EVT_STAT_VENT_PRESS_TIDAL_VOL_LIMITED MDC_EVT_STAT_VENT_PRESS_RESP_VOL_LIMITED	Tidal volume is pressure limited.	1	4	EVT	3::6206	202814
MDC_EVT_STAT_VENT_TIME_TIDAL_VOL_LIMITED MDC_EVT_STAT_VENT_TIME_RESP_VOL_LIMITED	Tidal volume is time limited.	1	4	EVT	3::6202	202810

CommonTerm

As originally captured as a CommonTerm.

Acronym

As originally captured as Acronym.

Description

Selected by (Description, Definition, mdcDescription, Unit_of_Measure)[1]   (XPath for first non-null occurrence of … ).

Definitions will be edited for clarity and removal of alternative ❖ 'short form' vendor strings prior to balloting (“semantic scatter”).

Disc

The discriminator group, with a (#) numeric suffix to indicate $dOffset if non-zero.

PartCode  

Reported as concat(PART,’::’,CODE10).

CF_CODE10

Reported as a single unsigned integer (compared with PartCode and/or PART and CODE10, UCODE10, ECODE10)

UOM_MDC

Rows gathered in single table cell (number of UOM_MDC and UOM_UCUM are compared) and existence verified

UOM_UCUM

Rows gathered in single table cell (number of UOM_MDC and UOM_UCUM are compared)

Enum_Values

Rows gathered in single table cell (number of Enum_Values and _Descriptions compared)

Enum_Descriptions

Rows gathered in single table cell (number of Enum_Values and _Descriptions compared)

External_Sites

Rows gathered in single table cell (these are not formally captured at present, but will be prior to balloting)

I included other bookkeeping columns, including:

gp   informal ‘Group number’  {1, 2, R2, 3 } for individual terms

The ‘group number’ gp is useful for term development and will be temporarily retained on RTMMSv2.

In the future, additional per-term information such as ‘AlertType’ will be included for containment tables where numeric observations that can be numeric limit alerts and ’named’ MDC_EVTs are included in the same file/worksheet.  Additional formatting information, such as section titles and codes and to group like-kind terms together, especially for events and alerts and ventilator terms, will also be captured.

Other minor issues have been addressed:

A.  Added UOM_MDC mappings for earlier work where only UOM_UCUM was provided by the working group(s).

B.  Added base units-of-measure for mS/cm, kJ/h, L/uV, {sat}.%.min and dB[SPL]  (Quiet Hospital/ICU ;-)

C.  There are several TBD’s for the NMT parameter, since it is dependent on the measurement technology that is used.  These are represented by the UCUM unit-of-measure {TBD#} where # is null or 1.  [Highlighted with light yellow; I will solicit additional information from vendors later on.]

D.  There are several instances of UOM_UCUM {date} and {alpha-numeric} placeholders where nothing is listed for UOM_MDC.  [Highlighted with light yellow; we will discuss this during the 11073 GC meeting.]  These would be more properly supported by adding one or more ‘DataType’ columns.

Files:

<<NewProvisional.10101b.Group1.Group2.Group3.x1g.2021-01-22T09.final.html>>            original using <br/> in table cells to separate lines

<<NewProvisional.10101b.Group1.Group2.Group3.x1g.2021-01-22T09.final.mso.html>>    replaced four <br/> with <br style="mso-data-placement:same-cell;”/> in table cells

<<NewProvisional.10101b.Group1.Group2.Group3.x1g.2021-01-22T09.final.xls>>               opened final.mso.html with Excel

<<RosettaTable.4j.x2d.2021-01-21T20.units.xls>>                                           Summary of UOM_MDC and UOM_UCUM with decade-expansions and numeric codes

<<ListParSrcEvt.3n.x3t.2020-03-10T19.Group1.EVT.final.AIS-only.xls>>      [AIS] Alert Inactivation State discriminators

 

[MICHAEL KIRWAN]

Stefan,

 

I could not agree more. Excellent vision and leadership by Paul and his team.

 

From: Stefan Schlichting <stefan.sc...@ornet.org>
Sent: Friday, January 22, 2021 10:35 AM
To: Paul Schluter <pssch...@gmail.com>
Cc: ihe-p...@googlegroups.com; ihe-p...@googlegroups.com; PCD Technical Committee GG <ihepc...@googlegroups.com>; ihe-pcd-...@googlegroups.com; IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>; device...@lists.hl7.org; Monroe Pattillo <monroe_...@bellsouth.net> (monroe_...@bellsouth.net) <monroe_...@bellsouth.net>; Mathieu Roullet <mrou...@enovacom.fr>; Dalibor Pokrajac <Dalibor....@guardrfid.com>; STEVEN DAIN <sd...@rogers.com>; Jan Wittenber <jan.wi...@gmail.com>; Walsh John L.M.D. <john....@mgh.harvard.edu>; Abhyankar, Swapna <sabh...@regenstrief.org>; Alexander Kraus <alexand...@biotronik.com>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J. <john.g...@nist.gov>; Crouzier, Nicolas <nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <john....@philips.com>; Chris Courville <ccou...@epic.com>; michael.faughn <michael...@prometheuscomputing.com>; Tom.Ko...@bbraun.com; Norman Jones <nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>; Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs <kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell, Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi Zhong <daidi...@ieee.org>; MICHAEL KIRWAN <mki...@dsheet.com>; Lisa Perry <l.p...@ieee.org>; Björn Andersen <ande...@imi.uni-luebeck.de>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; di...@moberg.com; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike Krajnak <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Sharma, Naveen Kumar (GE Healthcare) <NaveenKum...@ge.com>; Aradhya, Lokesh (GE Healthcare) <Lokesh....@ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; McGuire, Jay <jmcg...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Iglesias, Brian <bigl...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org; Richard Tayrien <rtay...@center4mi.org>; Spencer Crosswy <scro...@center4mi.org>; Andrew Norton <andrew...@tiscali.co.uk>; Tietz, Michael <Michae...@draeger.com>; Beier, Manfred <Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>; Anders Häggström <anders.h...@getinge.com>; Kochhar, Anil K. <Anil.K...@jhuapl.edu>; Jeff Rinda <jeffre...@gmail.com>; Nichols, Steven (GE Healthcare) <Steven....@ge.com>; Ramachandran, Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>; Brauer, Kimberly (GE Healthcare) <Kimberl...@ge.com>; snich...@gmail.com
Subject: Re: Consolidated IEEE P11073-10101b Group1, Group2 and Group3 terms with "provisional" code assignments

 

Der Paul, dear Michael,

 

These are really great news! Thank you for all the time und efford that you spend on this important topic!

 

I'm looking forward to the presentation next week during the IEEE wgm.

 

Stefan

[Melvin REYNOLDS]

Yes - well done Paul et al for reaching this momentous milestone.

Kind regards,

Melvin.


In mail of Fri, 22 Jan 2021 16:37:38, MICHAEL KIRWAN

<mki...@dsheet.com> wrote:

>Stefan,
>
>I could not agree more. Excellent vision and leadership by Paul and his team.
>
>From: Stefan Schlichting <stefan.sc...@ornet.org>
>Sent: Friday, January 22, 2021 10:35 AM
>To: Paul Schluter <pssch...@gmail.com>
>Cc: ihe-p...@googlegroups.com; ihe-p...@googlegroups.com; PCD
>Technical Committee GG <ihepc...@googlegroups.com>; ihe-pcd-rtm-
>ve...@googlegroups.com; IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>;
>device...@lists.hl7.org; Monroe Pattillo <monroe_pattillo@bellsouth
>.net> (monroe_...@bellsouth.net) <monroe_...@bellsouth.net>;

>Mathieu Roullet <mrou...@enovacom.fr>; Dalibor Pokrajac <Dalibor.pokra
>j...@guardrfid.com>; STEVEN DAIN <sd...@rogers.com>; Jan Wittenber

><jan.wi...@gmail.com>; Walsh John L.M.D.
><john....@mgh.harvard.edu>; Abhyankar, Swapna

><sabh...@regenstrief.org>; Alexander Kraus <alexander.kraus@biotronik.

>com>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J.
><john.g...@nist.gov>; Crouzier, Nicolas
><nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>;
>John Rhoads <john....@philips.com>; Chris Courville

><ccou...@epic.com>; michael.faughn <michael.faughn@prometheuscomputing

>.com>; Tom.Ko...@bbraun.com; Norman Jones
><nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>;
>Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs
><kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell,
>Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod)
><Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi
>Zhong <daidi...@ieee.org>; MICHAEL KIRWAN <mki...@dsheet.com>; Lisa
>Perry <l.p...@ieee.org>; Björn Andersen <ande...@imi.uni-luebeck.de>;
>Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>;
>di...@moberg.com; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike
>Krajnak <michael...@med.ge.com>; Neal Seidl
><Neal....@med.ge.com>; Sharma, Naveen Kumar (GE Healthcare)
><NaveenKum...@ge.com>; Aradhya, Lokesh (GE Healthcare)
><Lokesh....@ge.com>; Comunale, Carter <ccom...@bernoullihealth.co
>m>; McGuire, Jay <jmcg...@bernoullihealth.com>; Szente, Andras

><asz...@bernoullihealth.com>; Iglesias, Brian <biglesias@bernoulliheal
>th.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimpi.neel@mars

>hfieldresearch.org; Richard Tayrien <rtay...@center4mi.org>; Spencer
>Crosswy <scro...@center4mi.org>; Andrew Norton
><andrew...@tiscali.co.uk>; Tietz, Michael
><Michae...@draeger.com>; Beier, Manfred
><Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>;
>Anders Häggström <anders.h...@getinge.com>; Kochhar, Anil K.
><Anil.K...@jhuapl.edu>; Jeff Rinda <jeffre...@gmail.com>;
>Nichols, Steven (GE Healthcare) <Steven....@ge.com>; Ramachandran,
>Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>; Brauer,
>Kimberly (GE Healthcare) <Kimberl...@ge.com>;
>snich...@gmail.com
>Subject: Re: Consolidated IEEE P11073-10101b Group1, Group2 and Group3
>terms with "provisional" code assignments
>
>Der Paul, dear Michael,
>
>These are really great news! Thank you for all the time und efford that
>you spend on this important topic!
>
>I'm looking forward to the presentation next week during the IEEE wgm.
>
>Stefan
>

>Paul Schluter <pssch...@gmail.com<mailto:pssch...@gmail.com>>

>email: pssch...@gmail.com<mailto:pssch...@gmail.com>

>Definitions will be edited for clarity and removal of alternative ?

--
Melvin I REYNOLDS

Strategic Innovation for Information, Management & Technology in Society

AMS Consulting, Ashcote, Walford Road, Ross-on-Wye, HR9 5PQ, UK
email: mel...@ams-consulting.co.uk
phone: +44 (0)1989 763 120
mobile: +44 (0)7831 517 803
-----------------------------------------------------------------------
The information contained in this e-mail may be confidential and / or
copyright, and intended only for named recipient(s). If you have
received it indirectly or in error please do not copy, distribute, take
any action on, or rely on, the content; check authority for use with
the sender.

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, February 3rd, starting at 11:00 AM CST.  I will provide a recap of my presentation at the HL7 and IEEE 11073 GC virtual meeting last week regarding the current status and future plans for IEEE P11073-10101b and related nomenclature activities.  I have attached a copy of the presentation.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<IEEE_11073_NomenclatureStatus.2021-01-26.Virtual.1d.2021-01-26T11.final.pptx>>

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, February 10th, is cancelled.  I am still working with Getinge/Maquet regarding additional numeric observations, settings and events/alerts related to their anesthesia systems, and it is likely that our RTM tcon two weeks from now (February 24th) will have a strong focus on ventilator, anesthesia, ventilator mode and related topics.

The RTM tcon for next Wednesday, February 17th, is also cancelled, since I will be participating in another call that represents a significant opportunity for the IHE PCD domain and future IEEE 11073 nomenclature extensions for other equipment and systems used in acute care settings.

I would like to thank Norman Jones, Andrew Norton, Anil Kocchar, Björn Andersen, John Garguilo, Marufur Rahman, Charles Parisot, Michi Tietz, Steven Nichols and Mathieu Roullet for their participation and contributions to the meeting last week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The RTM tcon for tomorrow, Wednesday, February 24th, is cancelled.  We have not quite finished our final review of the proposed definitions for some of the Getinge/Maquet numeric observations, settings and events/alerts related to their anesthesia systems, so we will need to postpone our discussion originally scheduled for tomorrow.  This will also give us additional time to send out the proposed 10101b terms well in advance of our next RTM tcon, now scheduled two weeks from now (March 10th) that will have a strong focus on ventilator, anesthesia, ventilator mode and related topics.

The RTM tcon for the following Wednesday, March 3rd, is also cancelled.  The “virtual” IHE North American (NA) Connectathon 2021 will be held during the week of March 1 - 5 and a many vendors from the IHE DEV (aka PCD) domain will be participating in that event.  In addition to the “virtual” IHE NA Connectathon testing event, a series of interesting webinars and seminars is planned for the entire week.

Best regards, stay safe and healthy, and good luck to everyone participating in the IHE NA Connectathon next week!

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, March 10th, starting at 11:00 AM CST.   We plan to review the new numeric observations, settings, waveforms and events/alerts for the Getinge/Maquet Servo Ventilators and Flow Anesthesia workstations, with the goal of assigning irrevocable “provisional” numeric codes by the end of this week or early next.  The new terms will be included as IEEE P11073-10101b Group4 and Group5 terms.

The proposed terms are attached below as two separate HTML tables, the first for the Servo Ventilator and the second for the Flow Anesthesia workstation.  To facilitate our discussion, color highlighting has been added to identify the principal term groups to facilitate our discussion:

light-blue shading for Neurally Adjusted Ventilatory Assist (NAVA) using the electrical activity of the diaphragm (EDI)

light-yellow for High Frequency Ventilation (HFV)

light-green for High Flow Oxygen therapy

light-purple for MDC_MAQUET private terms

light-blue-grey for additional terms to be included for completeness in IEEE P11073-10101b

Please take a look at the attached material prior to our RTM tcon on March 10th.  If you have any questions or comments before then, please feel free to send me an email so we can try to resolve it prior to our discussion.  Although we have covered many of the new ventilator term concepts in previous meetings, this will provide you an opportunity to formally review them.

I would like to thank Per Johansson, Anders Häggström and Mikael Petrini with Getinge/Maquet for their massively significant contribution to this effort and to the quality and innovation of their products and designs.

Thanks and regards, and we look forward to seeing you next Wednesday!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<GetingeServoVentilator.x2d.2021-03-08T12.html>>

<<GetingeFlowAnesthesia.x2d.2021-03-08T12.html>>

PS.  The new terms account for one-third of the total number of terms used by both products.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 17, is cancelled.  Although we had a very productive RTM meeting last Wednesday and a follow-up meeting on Monday, we believe it would be better to begin our discussion of any additional MDC_DEV terms required to support the containment models for the Getinge/Maquet Servo Ventilator and Flow Anesthesia, as well as similar devices made by other vendors, next Wednesday, on March 24.

I would also like to thank everyone who participated in last week’s meeting, including Per Johansson, Anders Häggström, Mikael Petrini, Norman Jones, Javier Espina, Michael Faughn, Björn Andersen, Steven Nichols, Charles Parisot, John Garguilo and Monroe Pattillo.  I would also like to thank Norman Jones and Steven Dain for joining Per, Anders, Mikael and myself for our meeting last Monday where we focused on Norman’s in-depth comments regarding several terms.

Updates to proposed Getinge/Maquet Group4 (Servo Ventilator) and Group5 (Flow Anesthesia) terms

First, based on input from Drs. Norman Jones and Steven Dain, we have updated the REFIDs, CommonTerms and Definitions for two terms, now identified as:

MDC_VENT_TIME_PD_ASSURED_INFLATION_INSP_EXP  

MDC_VENT_TIME_PD_ASSURED_INFLATION_INSP_EXP_MAX_SETTING

These replace the original MDC_VENT_TIME_PD_INSP_EXP_SIMV and MDC_VENT_TIME_PD_INSP_EXP_SIMV_SETTING and Definitions we had earlier, since they were somewhat ambiguous and unnecessarily restricted to only SIMV mode.  The the concept of an “assured inflation” is clearly defined and illustrated in ISO 19223 (Figure C.30) and the same concept could also apply to other ventilation modes.

We also defined the new term MDC_TIME_PD_SPONT_INSP_EXP, defined as the "measured cycle time of spontaneous breath, the duration of the inspiratory and expiratory phases of spontaneous breath initiated and terminated by the patient."

We also updated the REFIDs for the six gas concentrations in fresh gas, to be more consistent with conventions used for gas concentration terms.  The REFIDs now are:

MDC_CONC_GASDLV_O2_FG_SETTING

MDC_CONC_GASDLV_DESFL_FG_SETTING

MDC_CONC_GASDLV_ENFL_FG_SETTING

MDC_CONC_GASDLV_HALOTH_FG_SETTING

MDC_CONC_GASDLV_SEVOFL_FG_SETTING

MDC_CONC_GASDLV_ISOFL_FG_SETTING

We also updated the REFID prefixes for the three “private” Getinge/Maquet terms to ‘MDCGETI_’ to be consistent with earlier implementations where ‘MDC’ is concatenated with the vendor identifier without an intervening underscore.  This will facilitate declaration of this information in REFIDs in a manner that is aligned with other vendors as well as ‘MDC_’ and ‘MDCX_’.

At this point, we believe that the Group4 and Group5 terms are ready for irrevocable numeric code assignment and elevation to “provisional” term status (to be assigned later this week). 

Next week:  Define additional MDC_DEV MDS/VMD/CHAN device modeling and containment terms for ventilators and anesthesia

During this effort we identified several additional MDC_DEV MDS/VMD/CHAN device identifiers required to model the additional capabilities provided by Getinge/Maquet ventilators and anesthesia workstations, as well as devices and systems made by other vendors.  This will be the focus of our discussion next week, on March 24th.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<GetingeServoVentilator.x2e.2021-03-17T09.html>>

<<GetingeFlowAnesthesia.x2e.2021-03-17T09.html>>

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, March 24, starting at 11:00 AM CDT.  Although our work on numeric observations, settings, waveforms and events/alerts for the Getinge/Maquet Servo Ventilator and Flow Anesthesia machines is largely complete, there was the remaining issue of whether we need to define any addition MDC_DEV device terms to support an IEEE 11073 “containment model” to provide an overall structure for modeling the complete device.  I believe we have captured most, if not all, of the MDC_DEV terms that we will need for high-frequency ventilation, high flow therapy, and other subsystems and/or capabilities.

For our meeting this Wednesday, I would like to provide an introduction and overview of containment trees and models.  This would also be an opportunity to identify any additional MDC_DEV terms that we will need for ventilators and anesthesia machines.

Listed below are the attached files that we will discuss on Wednesday:

<<ContainmentTrees.TF Vol3 2019.1b.2021-03-18T14.color.docx>>    IEEE 11073 Containment Tree diagram and skeleton example from IHE PCD DEC TF Volume 3 (2019).

<<Servo.1c.x1e.2021-03-18T12.html>>   Proposed containment model for Getinge/Maquet Servo Ventilator  (includes several new MDC_DEV terms)

<<Flow.1g.x1e.2021-03-18T12.html>>   Proposed containment model for Getinge/Maquet Flow Anesthesia   (uses only existing MDC_DEV terms)

<<Vent-Anesthesia-MVC.1b.2021-03-16T22.xlsx>>   Lists existing and new (proposed) MDC_DEV terms related to ventilators and anesthesia

My principal “ask” to everyone in the larger RTM community next Wednesday is whether we are missing any other MDC_DEV device terms related to ventilators and anesthesia.

I look forward to our discussion on Wednesday!

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, March 30, starting at 11:00 AM CDT.  Although we have captured most, if not all, of the new MDC_DEV terms that we will need for high-frequency ventilation, high flow therapy, and other subsystems and/or capabilities, there were a few items that required further consideration based on emails that I received.

The primary purpose of this meeting will be to review and finalize the additional MDC_DEV terms, in preparation for assigning final “provisional” numeric codes for IEEE P11073-10101b Group4 and Group5 terms.  The new and existing MDC_DEV terms are listed in the attached spreadsheet.  The new MDC_DEV terms are highlighted with light-blue shading and ’new’ as the Part1Code value.  The updated spreadsheet also includes existing definitions and proposed definitions for the new terms.  Relative to last week’s list, we added MDC_DEV_ENVIRON_AMBIENT_VMD.]

[I had also considered defining a new MDC_DEV for a combined airway gas flow/pressure/concentration analyzer that could be used in lieu of the existing pair MDC_DEV_ANALY_AWAY_MULTI_PARAM_VMD and MDC_DEV_ANALY_CONC_GAS_MULTI_PARAM_VMD, since both would be need for calculating “flow-weighted” amounts of anesthetic agents and other gases delivered to and consumed by the patient.  To keep things simple, we will not define a new term for this at the present time, but continue to include delivered and consumed gases using the existing MDC_DEV_ANALY_CONC_GAS_MULTI_PARAM_VMD.  Any comments?]

[Another area where we decided to stay with the status-quo was to continue to include the High Pressure System (HPS) and Intermediate Pressure System (IPS) as part of MDC_DEV_GEN_CONC_AWAY_VMD rather than defining new MDC_DEV terms.]

*     *     *

The second part of our discussion will be a quick overview of a comprehensive containment model across the combined set of IEEE Std 11073-10101-2019 and IEEE P11073-10101b respiratory, ventilator, anesthesia and nebulizer terms (this effort also included a minimal but useful set selected attributes and metrics directly under the top-level MDS).  This could be used as a starting point for future expansion and refinement by vendors and other experts. 

I apologize for the short notice, and look forward to our discussion at the top of the hour.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<Vent-Anesthesia-MVC.1e.2021-03-30T19.xlsx>>   Lists existing and new (proposed) MDC_DEV terms related to ventilators and anesthesia

<<GroupRefids.1e.x2c.2021-03-31T09.html>>  Containment model for the combined IEEE Std 11073-10101-2019 and IEEE P11073-10101b respiratory, ventilator, anesthesia and nebulizer terms

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, April 7, starting at 11:00 AM CDT.  I plan to provide an overview of how we plan to allocate numeric codes in Partition 7 for two new enumerated value sets.  The purpose of this meeting and this email notice is to inform you of this technical choice (which should be non-controversial) and answer any questions that you may have.

We can also use this time to address any remaining questions about the proposed skeletal containment model that was sent out last week that spans the entirety of the IEEE 11073-10101* nomenclature for respiratory, ventilators and anesthesia machines.  We used this model to elicit any additional VMDs that we might need for this class of device.  Based on the comments I have received, the list of MDC_DEV terms appears to be sufficient at the present time and as a consequence the entire set of Group4 (Getinge/Maquet Servo Ventilator) and Group5 (Getinge/Maquet Flow Anesthesia) terms have been assigned numeric codes and have been submitted to Michael Faughn for final verification that there are no code conflicts and for incorporation into the RTMMSv2 database as “provisional” terms.

*     *     *

The two new enumerated value sets will be located in Partition 7 that is currently used for body and measurement sites, plus a few “items” like blankets.  The existing body site terms occupy a small fraction of the lower 25% of the code range starting at 7::0 and ending at 7::16383.

The two new enumerated values sets are:

Group 6:  Ventilation mode mapping of ISO 19223 to IEEE 11073   starting at 7::16384 = 7::0x4000 with an allocation of 2048 codes

We currently have a total of 77 ISO 19223 mode mappings for Draeger, Getinge and GE Healthcare that have been proposed, reviewed and approved.

Ventilator mode selectable adjuncts will be represented as separate Booleans to reduce the number of mode mappings.

Although 77 modes for three major vendors is a small fraction of the 2048 codes allocated, the number could increase substantially if some vendors prefer not to use separate Booleans for selectable adjuncts.  Also, there are at least 25 vendors that make respiratory, ventilator and anesthesia devices, and there are countless models among all vendors, suggesting that an allocation of 2048 codes is prudent.  Should we consider allocating more codes, for example 4096?

Group 7:  BPKP Basic Participant Key Purposes (required for P10700 ballot)   starting at 7::18432 = 7::0x4800  with an allocation of 32 codes

There are eight proposed Basic Participant Key Purposes (BPKP) enumerated values that have been proposed for IEEE P11073-10700.  We will allocate an initial range spanning 32 codes for these.

It should be noted that there are currently no enumerated term codes defined from 7::10001 to the private terms starting at 7::61440, so there is significant room for future expansion.

I will be happy to entertain any questions about this proposal.

I would like to thank Per Johansson, Peter Verständig, Mikael Petrini, Javier Espina, Mathieu Roullet, Marufur Rahman, John Garguilo, Norman Jones and Steven Dain for attending and contributing to our meeting on March 24th and to thank Björn Andersen, Marufur Rahman, Eldon Metz, Mathieu Roullet and Steven Dain for attending and contributing to last week’s meeting on March 30th.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, April 14, starting at 11:00 AM CDT.  We will be discussing the new SDC BPKP Basic Participant Key Purposes and other terms that comprise the 10101b Group7 terms required to support the IEEE P11073-10700 ballot.  [Discussion of the Group6 ventilator mode terms will resume during subsequent weeks.]

The original set of proposed REFIDs and definitions is shown in the attached file <2021-04-08 PKP terms for 10101b.xlsx> provided by Björn Andersen and his colleagues, and is referenced throughout this email.  The additional terms listed in Excel rows 10 to 15 require additional review and discussion, as noted below.

BPKP Basic Participant Key Purposes  (Excel rows 2 to 9)

The set of eight BPKP terms will be assigned numeric codes in Partition 8, starting at 8::8320.  They are located 128 codes above the last group of four terms in the sub-block starting at 8::8192 that comprise the "Communication infrastructure—optional package identifiers” defined in Table A.4.7 of 10101-2019.

The placement of the eight BPKP terms is visually depicted in the attached <Partition_8.512x32x1.1c.2021-04-13T11.proposed-BPKP.docx>, showing context with respect to other term groups.

The BPKP terms are thematically more related to the issues of “should or can systems and devices talk to one another”, in contrast to Partition 7 “Body Sites”, that deals primarily with physiologic concepts.  Partition 8, for example, defines terms for Continua device certification lists, as well as other topics related to connectivity.  Partition 8 defines variables to contain this information as well as enumerated value sets, such as the fifteen enumerations for time synchronization profiles.

MDC_MODE_ON, MDC_MODE_OFF, MDC_MODE_PSD  (Excel rows 10, 11, 12)

I assume that these are event transitions, and thus each one should start with MDC_EVT_MODE_ .  If these are to be considered status events, you could consider using MDC_EVT_STAT_MODE_ instead (for example, we already have MDC_EVT_STAT_STANDBY_MODE, MDC_EVT_STAT_SVC_MODE, etc.

In practically all cases an MDC_EVT implies an underlying Boolean state variable - it is either “on” or “off”, true() or false(), etc.  For the vast majority of MDC_EVT terms, we rely on a separately encoded transition/phase to indicate <start>, <continue> and <end> for an interval event, <tpoint> for a time-point event (e.g. an R-on-T PVC), etc.  We have also defined other transition/phases to capture Alarm Inactivation State (AIS) changes, and this is mandatory information for each and every transition of an event or alert.  So the three on/off/paused events you have proposed are okay, but internally a receiving application could convert them to a single “the selected mode is active”.  That said, it is quite likely that some of the the devices you have in the OR (such as electrocautery and electrosurgical devices with various cutting modes) convey the master (footpedal) switch as an overall on/off/pause switch that can apply a variety of cutting modes.

So, my recommendation regarding the REFIDs would be MDC_EVT_MODE_ON, MDC_EVT_MODE_OFF and MDC_EVT_MODE_PAUSED (or the alternative set of REFIDs where MDC_EVT_STAT is used).

MDC_SIGNAL_QUALITY_INDEX  (Excel row 13)

We already have a few parameter-specific signal quality indices defined:

-  MDC_SPO2_SIGNAL_QUALITY_INDEX (2::29252)

-  MDC_EEG_SIGNAL_QUALITY_INDEX (2::22564)   most notably used for BIS but other EEG based parameters as well

Although many of us would not be adverse to defining a more general SQI term, it may be difficult to apply to other signals and vendor implementations since the “break points” for when a signal is considered “good” (Aspect BIS SQI > 50) would be different than what other vendors would use for other parameters.  A complete definition of a general SQI term would also have to disclose the breakpoints as name-range pairs, e.g. good=50-100, questionable=15-49, notUsable=0-14 for Aspect BIS SQI.  [In an HL7 V2 DEC message, this additional information could be conveyed as a FACET of the METRIC value MDC_EEG_SIGNAL_QUALITY_INDEX.

We would also need to standardize the names of the “breakpoints” - based on my experience, the named breakpoints { excellent, reliable, usable, questionable, notUsable and invalid } could serve as a standardized set of ‘named’ signal quality levels that proprietary signal quality labels could map to.

Another issue is whether this should be labeled MDC_ATTR_SIGNAL_QUALITY_INDEX since this is intended to be a generic term that could apply to any METRIC value, or leave it as MDC_SIGNAL_QUALITY_INDEX.

One final issue is the scope of MDC_SIGNAL_QUALITY_INDEX - in many cases it applies to a single METRIC observation and thus deploying it as a FACET of that METRIC to indicate that scope.  In other cases it can apply to the entire parameter signal, in which case it would need to be deployed as a child METRIC of the parent CHANnel.

That all said, defining a generic MDC_SIGNAL_QUALITY_INDEX would be a great first step, but there will be more work to do after that.

MDC_EVT_STAT_MSMT_COMPLETE  (Excel row 14)

Although we can add this term, please note that it is the complementary form of MDC_EVT_STAT_MSMT_START (3::6352) “start of (automatic) measurement” defined in the 10101b Group1 set of terms.  The start of a measurement would be indicated by MDC_EVT_STAT_MSMT_START <start> and completion could now be indicated by either MDC_EVT_STAT_MSMT_START <end>, or, with the addition of this term, MDC_EVT_STAT_MSMT_COMPLETE <start>.

MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR  (Excel row 15)

I assume that this is actually an MDC_EVT technical event, so replace the REFID with MDC_EVT_SIGNAL_MSMT_STAT_INDICATION.  Note that this would use the <start>, <continue> and <end> transition/phases if the indication spans a time interval or <tpoint> for a single BEEP.  The payload of the event could include additional parameters such as the tone sequence, volume and/or duration or possibly a standardized pattern or audio file name for more complex sounds, include voice.

I would like to thank Björn Andersen, Charles Parisot, Eldon Metz, John Garguilo, John Rhoads, Michael Faughn, Norman Jones, Steven Dain, Steven Nichols and Monroe Pattillo for their participation in and contributions to last week’s RTM tcon on April 7.  I am looking forward to today’s discussion, and hopefully we will achieve a level of consensus that will allow us to assign numeric codes for the 10101b Group7 terms later this week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<2021-04-08 PKP terms for 10101b.xlsx>>   Spreadsheet of proposed terms for 10101b to support IEEE P11073-10700, sent by Björn Andersen.

<<Partition_8.512x32x1.1c.2021-04-13T11.proposed-BPKP.docx>>   A visual map of the placement of the eight BPKP terms in Partition 8, showing context with respect to other term groups.

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, April 21, and next Wednesday, April 28, are cancelled.

Due to scheduling conflicts, the people we needed from Draeger to discuss several of their new term proposals are not available this week.  The RTM tcon for next Wednesday, April 28, is also cancelled due to the IHE PCD virtual F2F meeting next week on Monday, 4/26 (infusion pumps) and Wednesday through Friday, 4/28 to 4/30 (entire IHE PCD domain).

I would like to thank Björn Andersen, Eldon Metz, Jan-Alrik Philipsen, John Garguilo, Ken Fuchs, Lisa Diggett and Monroe Pattillo for attending last week’s meeting.  Everyone on the call agreed to assigning numeric codes for the eight BPKP terms in Partition 8, starting at 8::8320 for the two BPKP MDC_IDT terms and 8::8352 for the six BPKP MDC_CTX terms.  Although we began discussion of the remaining terms (Excel rows 10 to 15) we felt we needed additional input from the original authors (who were not present on the call last week) and discussion has continued by email since then.

We will reconvene two weeks from now on Wednesday, May 5th.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Michael Faughn]

It says "auditory" in the definition in the spreadsheet.  Given the definition in the spreadsheet, it seems clear enough to me that this would be a low priority alert.  That said, the priority

 of an alert does not need to be embedded in any term declaring the existence of an alert.  Ample means of declaring the priority of an alert already exists by means of other attribution within the MDIB.

Given that IEC 60601-1-8 is not freely available to all WG members, would you care to explain the requirements set forth in said standard?

-Michael

On Wed, Apr 21, 2021 at 10:40 AM Steven Dain <sd...@rogers.com> wrote:

I am having trouble understanding the intent of MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR 

The definition provided in the excel spreadsheet does not comply with IEC 60601-1-8.  Does this refer to a visual, auditory, haptic or other type of alert? 

 

This needs to be included with the metadata.  What is the priority of the alert/alarm condition?

Steven Dain

[Paul Schluter]

Michael and Steve,

Based on the information provided in Bjorn’s spreadsheet:

Proposed REFID:  MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR

Proposed CommonTerm:  Alert signal measurement status indicator

Proposed Definition:  An advisory audible signal to inform the operator that a mesaurement or procedure has started or finished.

I believe this is actually intended to be an event that indicates that some sort of audio, visual and/or haptic signal is used to indicate that a measurement is in progress.

As I noted in my earlier comments, the event identifier “MDC_EVT_SIGNAL_MSMT_STAT_INDICATION” would be far more appropriate <event> identifier to use.  It is consistent with all our previous IEEE 11073 event and alert identifier terminology, and could utilize our ability to send the event/alert <source> identifier, the <start>, <continue> and <end> transition/phases if the indication spans a time interval or <tpoint> for a single audio tone or beep, priority level, etc.  We can also support the inactivation and prospective inactivation of this “indication”, just like any other event or alert.

The event payload could also include additional parameters such as the tone sequence, volume and/or duration or possibly a standardized pattern or audio file name for more complex sounds, include voice.  This could be specified during the <start> transition/phase, and, if it changes during the event, during subsequent <update> transition/phases.

This is similar to countless other events and alerts that we have defined.  We just need to confirm with the SDC cognoscenti that this is what they have in mind.  Hopefully we will all be able to complete our discussion of this and other topics on or before the May 5th RTM meeting.

Best regards,

Paul Schluter

[Björn Andersen]

Paul,

As discussed before, defining only the event term is not sufficient for SDC where we would like to use the term in the pm:AlertSignalDescriptor/pm:Type/@Code field that semantically describes the alert signal.

If You have questions that relate to the meaning of this particular signal, please Cc Josh.

-Björn

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Terminology Mapping Profile WG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm/4D5D5812-07DB-4BCE-98F9-7CD6E5026E3C%40gmail.com.

[Paul Schluter]

Björn,

In IEEE 11073-10201-2018, an AlertCondition is identified by the pair of identifiers alert-source and alert-code

--

-- Alert-Condition attribute is the status output of the process that is detecting the alert

--

AlertCondition ::= SEQUENCE {

obj-reference                HANDLE,

controls                         AlertControls,

alert-flags                      AlertFlags,               -- supporting flags

alert-source                  OID-Type,                -- from metric or object-oriented nomenclature partition

alert-code                      OID-Type,                -- from events nomenclature partition

alert-type                      AlertType,                -- defines type and severity of condition

alert-info-id                  PrivateOid,              -- specific information can be appended; 0 if not used

alert-info                       ANY DEFINED BY  alert-info-id

}

   

NOTE—The alert-code value is a code that comes from the events nomenclature partition. Entries (i.e., codes) in this partition are even. The last bit of the code is used to determine whether the alert-source comes from the metric nomenclature partition or the object-oriented nomenclature partition. If the last bit of the alert-code value is 0, the alert-source comes from the metric nomenclature partition. If the last bit is 1 (1 is added to the base code in the events nomenclature), the alert-source comes from the object-oriented nomenclature partition. 

In an IHE PCD ACM message,

the alert-code (event identification) is conveyed by an OBX with OBX-3 = 196616^MDC_EVT_ALARM^MDC and the specific alert identifier, e.g. MDC_ECG_ASYSTOLE, is conveyed by OBX-5

the alert-source is conveyed by an OBX with OBX-3 = 196616^MDC_ATTR_ALERT_SOURCE^MDC and the specific alert source, e.g. MDC_ECG_HEART_RATE, is conveyed by OBX-5

Table B.8.5-1: Observation Sub-ID Facets in the IHE PCD DEC Technical Framework, Rev 9.0 Final Text (2019-12-12) provides a detailed description of all the other attributes that are associated with reporting an alert condition, such as event phase, alert state, inactivation state, alarm priority and alert type.

My comments above describe how the alert identification is specified by a pair of two coded identifiers.  If you are interested instead in describing the type of alert signal (audio, visual, haptic, etc.) could you kindly provide a list of the enumerated values you would plan to send?  As a general rule, enumerated values with descriptions must be provided for new terms going into IEEE P11073-10101b.  IEC 60601-1-8 would be a good starting point here.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Björn Andersen]

Paul,

it is indeed the alert signal that this term refers to and we intend to use it for pm:AlertSignalDescriptor/pm:Type (see figure below).

We are not sending any enumerated values but we populate the other elements and attributes of the descriptor as appropriate.

I would like to emphasise that SDC is service-oriented, not message-oriented, and that one of its core principles is the semantic description of containment tree elements (such as this AlertSignalDescriptor) using the pm:Type element that contains a coded value. Therefore, many of the terms we are proposing and will propose in the future relate to the semantic type of a descriptor element. These include MDS, VMD, Channel, and Metrics like in the classic 10201 DIM, but also various AlertDescriptors, ContextDescriptors, and OperationDescriptors or even BatteryDescriptors and ClockDescriptors.
To convey what they represent, all of these carry a type.

Best regards
Björn

To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm/2A853B04-4370-484E-BD9F-6C4BEE0B0405%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Terminology Mapping Profile WG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm/2A853B04-4370-484E-BD9F-6C4BEE0B0405%40gmail.com.

[Paul Schluter]

Björn and colleagues,

Based on the W3C Schema fragment you have provided, AlertSignalDescriptor appears to specify a particular instance of an alert.  That’s okay, but every profile and protocol has some mechanism for specifying an instance of an alert, whether it is IEEE 11073 “classic”, HL7 V2 ACM, FHIR, etc.

To make further progress on this topic, please send an example of how this would be used in practice.  In particular, let’s say the alert condition is “the start of atrial fibrillation” and later “the end of atrial fibrillation”, including information like the start and end times for the event, alert type and priority and other information that will be needed to successfully map to IHE PCD ACM (which has direct mappings to and from IEC 60601-1-8).  Using that as an example, what would AlertSignalDescriptor contain?

Thanks for sending this material out in advance.  If possible, do you and your colleagues have any notes you would like to share in advance regarding your thoughts on Signal Quality Index?

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On May 3, 2021, at 10:11 AM, Björn Andersen <bjoern....@ieee.org> wrote:

Paul,

[Paul Schluter]

[Michael Faughn]

I am kind of testing my understanding of BICEPS here so please let me know if any of this is wrong...

I do not think the diagramed object refers to an instance of an Alert at all, at least not in the sense of a temporal instance.  It's my understanding that elements in a BICEPS MDIB are bipartite.  Each has a Description object that specifies the capabilities of that element (what is it, what can it do) and zero or more State objects that contain / convey the...state (what is it doing right now).  Description objects "possess" their corresponding State objects.

Unless I'm mistaken, none of the information (i.e. attribute values) in AlertSignalDescriptor would change at all during the scenario that Paul outlines.  The values that would change would be in the AlertSignalState and AlertConditionState components.  You would determine the start and end of an Alert Signal by interrogating the AlertSignalState object.  You would determine what the AlertSignal was for by tracing the value of AlertSignalDescriptor.ConditionSignaled back to the AlertConditionDescriptor that it referenced.  The AlertConditionDescriptor object has attribution for Kind (Phys, Tech, Other), Priority (Lo, Med, Hi, None), and Type (a CodedValue that can be an 11073 term that describes the condition).  The AlertConditionState object has an attribute, DeterminationTime, that indicates the time when the condition last changed, from which condition start and end may be derived.  In short, it looks like everything is there, even if it isn't organized in the same way that it is in 10201.

As an aside...Is there a readable UML class diagram of the entirety of BICEPS somewhere?  The alphabetical organization of 10207 is not at all conducive to tracing through the hierarchy and really "getting to know" it, especially since there is no "back" button when following links through a PDF (at least not in the viewer I'm using).  Also, for practical purposes, it would be nice to see a diagram that actually drew lines for associations between objects that are technically referenced via handles.  There is an implicit understanding (at least I hope there is) that, for example, the value of  AlertSignalDescriptor.ConditionSignaled must be a Handle for an AlertConditionDescriptor.

-Michael

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Apr 23, 2021, at 7:18 AM, Björn Andersen <bjoern....@ieee.org> wrote:

Paul,

--

Michael Faughn
Software Developer
Prometheus Computing, LLC
m.fa...@prometheuscomputing.com
Mobile: (828) 226-1369

[Paul Schluter]

Michael, Björn and colleagues,

The text for Clause 6.1.7.1 from IEEE P11073-10701 Draft 1 (2021-02-06) provides the only context I have been able to find regarding MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR.  It is the value of the attribute pm:type/@Code, and as such, does not have any child nodes to convey additional information.  The containing context is a technical event, MDC_EVT_STAT_MSMT_START and MDC_EVT_STAT_MSMT_COMPLETE.

Based on Clause 6.1.7.1 below, this appears to mean “the { visual, audio, haptic, other } associated with indicating that a measurement (or procedure) is taking place”.  An immediate question that comes to mind is whether similar terms have been considered for other technical and physiologic events and alerts: are there enumerated values for those?  

From a medical-legal standpoint, providing more detail about alert indication type { NONE, VISUAL, AUDIO, HAPTIC } could be conveyed by defining a new attribute, MDC_ATTR_ALERT_INDICATION.  The proposed Boolean flags are consistent with the Alarm Inactivation State (AIS) discriminator suffixes already defined in the IEEE P11073-10101b Group1 terms.  At a minimum, we should also define an additional attribute or numeric (SCADA) identifier to convey the alert audio volume, e.g. MDC_ATTR_ALERT_AUDIO_VOLUME or MDC_ALERT_AUDIO_VOLUME.  [I have included Monroe Pattillo and Rob Wilder given their expertise on this topic and suitable for inclusion as optional payload elements in IHE PCD ACM PCD-04 and other transactions.]

Best regards, and I look forward to our discussion tomorrow at 11:00 AM CDT.

Paul Schluter

email:  pssch...@med.ge.com

cell:  (414) 702-2026

6.1.7.1 Notification of initiation and completion of measurements 

TR0231: If an SDC METRIC PROVIDER provides an intermittent measurement, it MAY also provide a pm:AlertConditionDescriptor with 

⎯ pm:Type/@Code = MDC_EVT_STAT_MSMT_START, 

⎯ @Kind = Oth, and 

⎯ @Priority = None, 

and a pm:AlertSignalDescriptor with 

and a pm:AlertSignalDescriptor with

⎯ pm:Type/@Code = MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR, 

⎯ @Manifestation = Aud, and 

⎯ @ConditionSignaled pointing to the alert condition 

in order to indicate the initiation of that measurement. 

TR0232: If an SDC METRIC PROVIDER provides intermittent measurements, it MAY also provide a pm:AlertConditionDescriptor with 

⎯ pm:Type/@Code = MDC_EVT_STAT_MSMT_COMPLETE, 

⎯ @Kind = Oth, and 

⎯ @Priority = None, 

and a pm:AlertSignalDescriptor with

⎯ pm:Type/@Code = MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR, 

⎯ @Manifestation = Aud, and

⎯ @ConditionSignaled pointing to the alert condition 

in order to indicate the completion of a measurement. 

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, May 5, starting at 11:00 AM CDT.  We plan to discuss and hopefully finalize our deliberations regarding several new terms requested for IEEE P11073-10701/D1.

Topic 1:  MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR

There has been a ongoing email conversation (that was circulated to the entire RTM Google Group email list plus others) about this term and exactly how it should be defined.  We plan to nail this down during our RTM call this Wednesday.  In addition, the discussion suggested that we should define two additional terms, MDC_ATTR_ALERT_INDICATION to indicate the alert indication type { NONE, VISUAL, AUDIO, HAPTIC } and an optional attribute or numeric (SCADA) term to convey the alert audio volume, e.g. MDC_ATTR_ALERT_AUDIO_VOLUME or MDC_ALERT_AUDIO_VOLUME.  These could be included as optional payload elements in an IHE PCD ACM PCD-04 and other transactions.  [If you have not seen this email thread, I will be happy to forward a copy to you.]

Topic 2:  MDC_SIGNAL_QUALITY_INDEX

Another term request was the definition of a ‘generic’ MDC_SIGNAL_QUALITY_INDEX.  Although several parameter-specific Signal Quality Indexes have been defined in the past (most notably MDC_EEG_SIGNAL_QUALITY_INDEX for Medtronic/Covidien/Aspect Medical Systems’ BIS™) there has been some hesitancy due difficulty in defining this metric in a more general manner.  The attached proposal <SQI Signal Quality Index.1b.2021-05-04T20.docx> provides a practical solution for accomplishing this, and is intended to support MDC_SIGNAL_QUALITY_INDEX (0-100%) as well as MDC_SIGNAL_QUALITY, where small positive integers and/or tokens are used.

I am expecting an interesting and productive discussion tomorrow, and hope you can join!

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<SQI Signal Quality Index.1b.2021-05-04T20.docx>>

[Björn Andersen]

Michael, thank You.

Your understanding is pretty accurate! I only have two really minor additions:

• Most descriptors may only have exactly one state, see BICEPS clause 5.4.3.
  
• "possess" actually means: States carry a handle reference to their descriptor.

As far as I know, there is no drawing or UML class diagram of the entirety of BICEPS.
Maybe something can be generated from the XSD files: https://sourceforge.net/p/opensdc/bicepsmodel/ci/master/tree/
The readability of the BICEPS annexes is indeed pretty awful.

And funny You should ask... Yes, there is definitely an implicit understanding of which HandleRef shall refer to which kind of descriptor.
A similar discussion starts here: https://sourceforge.net/p/opensdc/ieee11073-10207/211/#ddfc
I agree that it would be much nicer if that understanding was made even more explicit in BICEPS. :-)

-Björn

[Björn Andersen]

Paul,

to the best of my knowledge, similar terms have not been considered for other events. @Josh: Are You aware of any?

In SDC, the alert indication type is conveyed using pm:AlertSignalDescriptor/@Manifestation, see 10207 clause B.104.
But if other client standards need that new attribute, I do not object.

We have not considered the alert audio volume. I do not object to the new terms.

-Björn

[Michael Faughn]

Thanks, Björn.

The following is not relevant to terminology...

I had "possess" in quotes because that is the wording I found in the draft of 20701 that I have.  The UML in 5.3.2 of 10207 shows Descriptors containing States, which would normally suggest to me that, in implementation, Descriptors could access their contained state objects.  In UML, the containment association between Descriptor and State means, by definition, that Descriptor has a property of type State and that State has a property of type Descriptor.  State objects also have the DescriptorHandle property, which is a bit redundant from a modeling standpoint.  10207 has modeled State to have two different properties to reference a Descriptor.  I doubt that was really the intention.  This really just exposes one of the shortcomings of class diagrams, that it is often hard to be both extremely precise and adequately expressive at the same time.  When this really becomes a challenge is when somebody tries to programmatically build something (an API, XML Schmea, DB Schema, etc.) from computable UML.  For every different model, you have to hand-tune the code to account for the differences between what the UML actually says and what is really intended.

-Michael

[Paul Schluter]

Greetings,

The RTM tcon for tomorrow, May 12th, is cancelled.  We are having all our trees trimmed tomorrow, which will require disconnection of power for most of the day.

We will continue and hopefully conclude our discussions from last week next Wednesday, May 19th.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The RTM tcon for tomorrow, May 12th, is cancelled.  We are having all our trees trimmed tomorrow, which will require disconnection of power for most of the day.

We will continue and hopefully conclude our discussions from last week on next Wednesday, May 19th.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

On May 5, 2021, at 11:50 AM, Abell, Josh <Josh....@draeger.com> wrote:

Hi Björn, Paul,

 

That is a good question. We have also considered a visual signal specifically for to represent a connection status – I would say this falls into the category of technical events. For example, our devices might have two conditions related to a connection status of something like a sensor. The first, would be there for the technical alarm we might raise when a sensor becomes unplugged during operation. The second, is more general and simply reflects if something is connected or not. For these conditions, we would have a visual indication (like an icon) to show that it is connected (or not). This signal was something like: MDC_ALERT_SIGNAL_CONN_STATUS. While we had in mind a visual signal, this too could have a different manifestation (I’m thinking of the Windows audio tone when you plug in a USB device). 

 

Best Regards - Josh

 

From: Björn Andersen <bjoern....@ieee.org> 
Sent: Wednesday, May 5, 2021 11:34 AM
To: Paul Schluter <pssch...@gmail.com>

Cc: RTM_WG <ihe-p...@googlegroups.com>; Abell, Josh <Josh....@draeger.com>; Steven Dain <sd...@rogers.com>; Philipsen, Jan-Alrik <Jan-Alrik...@draeger.com>; Stefan Schlichting <stefan.sc...@ornet.org>; Garguilo, John J. <john.g...@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <John_...@acm.org>; John Rhoads <johnr...@johnrhoads.net>; Ken Fuchs <kenj....@gmail.com>; Tietz, Michael <Michae...@draeger.com>; Monroe Pattillo <monroe....@gmail.com>; Rob Wilder <rob.w...@spok.com>; Michael Faughn <m.fa...@prometheuscomputing.com>
Subject: Re: MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR

 

Paul,

to the best of my knowledge, similar terms have not been considered for other events. @Josh: Are You aware of any?

In SDC, the alert indication type is conveyed using pm:AlertSignalDescriptor/@Manifestation, see 10207 clause B.104.
But if other client standards need that new attribute, I do not object.

We have not considered the alert audio volume. I do not object to the new terms.

-Björn

On May 5, 2021, at 10:35 AM, Michael Faughn <m.fa...@prometheuscomputing.com> wrote:

Thanks, Björn.

The following is not relevant to terminology...

I had "possess" in quotes because that is the wording I found in the draft of 20701 that I have.  The UML in 5.3.2 of 10207 shows Descriptors containing States, which would normally suggest to me that, in implementation, Descriptors could access their contained state objects.  In UML, the containment association between Descriptor and State means, by definition, that Descriptor has a property of type State and that State has a property of type Descriptor.  State objects also have the DescriptorHandle property, which is a bit redundant from a modeling standpoint.  10207 has modeled State to have two different properties to reference a Descriptor.  I doubt that was really the intention.  This really just exposes one of the shortcomings of class diagrams, that it is often hard to be both extremely precise and adequately expressive at the same time.  When this really becomes a challenge is when somebody tries to programmatically build something (an API, XML Schmea, DB Schema, etc.) from computable UML.  For every different model, you have to hand-tune the code to account for the differences between what the UML actually says and what is really intended.

-Michael

On Wed, May 5, 2021 at 11:13 AM Björn Andersen <bjoern....@ieee.org> wrote:

Michael, thank You.

Your understanding is pretty accurate! I only have two really minor additions:

• Most descriptors may only have exactly one state, see BICEPS clause 5.4.3.
  
• "possess" actually means: States carry a handle reference to their descriptor.

As far as I know, there is no drawing or UML class diagram of the entirety of BICEPS.
Maybe something can be generated from the XSD files: https://sourceforge.net/p/opensdc/bicepsmodel/ci/master/tree/
The readability of the BICEPS annexes is indeed pretty awful.

And funny You should ask... Yes, there is definitely an implicit understanding of which HandleRef shall refer to which kind of descriptor.
A similar discussion starts here: https://sourceforge.net/p/opensdc/ieee11073-10207/211/#ddfc
I agree that it would be much nicer if that understanding was made even more explicit in BICEPS. :-)

-Björn

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, May 19, starting at 11:00 AM CDT.  We will conduct our final review of all the new Group7 SDC 10701 terms, and to that end, I am sending a consolidated spreadsheet that lists them.

There has been a significant amount of email discussion.  I have included the last four threads [1-4] since our May 5th tcon, in case we need to refer to them.  It may be easier just to review the terms you are interested in on the attached spreadsheet, since this is very close, if not identical, to what will be incorporated into IEEE P11073-10101b.  [I will also copy this email to the SDC aficionado group.]

During our discussion for the past several weeks, it has become evident that there are foundational differences between how various IEEE 11073 subgroups view certain issues.  At this point in time, topic #1 below appears to underlie several discussions that we’ve had, and so I will recapitulate several simplifying principles below:

1. All MDC_EVT events and alerts can have a visual, audio and/or haptic indication (or no indication).  We have now defined two generic attribute/observation for optionally conveying this information with any event or alert, whether it is an episode of ventricular fibrillation or a technical event such as a cable or sensor disconnection.  There is little if any need to define an event that reports “I am sending you an audio tone during a generic measurement” since we already the ability to send a visual, audio and/or haptic indication associated with more than 50+ specific events related to module, cable or sensor disconnection.  The two new terms MDC_ATTR_ALERT_INDICATION and MDC_ALERT_AUDIO_VOLUME can be used to convey this information for any transition/phase of any event or alert, including the generic MDC_EVT_MSMT_RUNNING previously defined in the 10101b Group1 events.

I’ll stop with this one and see where our discussion on Wednesday takes us.

I have also detailed greater specificity regarding MDC_SIGNAL_QUALITY_MAPPING by providing a Parsing Expression Grammer (PEG) that specifies how “signal quality” regions can be identified using standard labels { nosignal, unusable, poor, usable, good } plus optional vendor-inspired labels to support a reasonable degree of comparability between different expressions of “signal quality index” (0-100%) and “signal quality” (using a vendor-specified range of integers).  The online PEGjs parser available at http://pegjs.org/online can be used to validate the strings, similar to how we validate ISO 19223 ventilator mode strings.

I look forward to our discussion this Wednesday and the successful resolution of any remaining Group7 term issues.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<AllTogetherGroup7.3c.2021-05-17T16.PEGjs-UoM.xls>>   This is “pre-provisional” material, including any numeric codes.

PS. The two MDC_DIM units-of-measure were requested by the infusion pump working group.  A third unit, “[mgPE]” for “milligrams of Phenytoin Equivalents”, was requested from ucum.org and we hope to hear from them soon.

On May 5, 2021, at 11:50 AM, Abell, Josh <Josh....@draeger.com> wrote:  [1]

Hi Björn, Paul,

 

That is a good question. We have also considered a visual signal specifically for to represent a connection status – I would say this falls into the category of technical events. For example, our devices might have two conditions related to a connection status of something like a sensor. The first, would be there for the technical alarm we might raise when a sensor becomes unplugged during operation. The second, is more general and simply reflects if something is connected or not. For these conditions, we would have a visual indication (like an icon) to show that it is connected (or not). This signal was something like: MDC_ALERT_SIGNAL_CONN_STATUS. While we had in mind a visual signal, this too could have a different manifestation (I’m thinking of the Windows audio tone when you plug in a USB device). 

 

Best Regards - Josh

 

From: Björn Andersen <bjoern....@ieee.org> 
Sent: Wednesday, May 5, 2021 11:34 AM
To: Paul Schluter <pssch...@gmail.com>
Cc: RTM_WG <ihe-p...@googlegroups.com>; Abell, Josh <Josh....@draeger.com>; Steven Dain <sd...@rogers.com>; Philipsen, Jan-Alrik <Jan-Alrik...@draeger.com>; Stefan Schlichting <stefan.sc...@ornet.org>; Garguilo, John J. <john.g...@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <John_...@acm.org>; John Rhoads <johnr...@johnrhoads.net>; Ken Fuchs <kenj....@gmail.com>; Tietz, Michael <Michae...@draeger.com>; Monroe Pattillo <monroe....@gmail.com>; Rob Wilder <rob.w...@spok.com>; Michael Faughn <m.fa...@prometheuscomputing.com>
Subject: Re: MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR

 

Paul,

to the best of my knowledge, similar terms have not been considered for other events. @Josh: Are You aware of any?

In SDC, the alert indication type is conveyed using pm:AlertSignalDescriptor/@Manifestation, see 10207 clause B.104.
But if other client standards need that new attribute, I do not object.

We have not considered the alert audio volume. I do not object to the new terms.

-Björn

On May 5, 2021, at 10:35 AM, Michael Faughn <m.fa...@prometheuscomputing.com> wrote:  [2]

Thanks, Björn.

The following is not relevant to terminology...

I had "possess" in quotes because that is the wording I found in the draft of 20701 that I have.  The UML in 5.3.2 of 10207 shows Descriptors containing States, which would normally suggest to me that, in implementation, Descriptors could access their contained state objects.  In UML, the containment association between Descriptor and State means, by definition, that Descriptor has a property of type State and that State has a property of type Descriptor.  State objects also have the DescriptorHandle property, which is a bit redundant from a modeling standpoint.  10207 has modeled State to have two different properties to reference a Descriptor.  I doubt that was really the intention.  This really just exposes one of the shortcomings of class diagrams, that it is often hard to be both extremely precise and adequately expressive at the same time.  When this really becomes a challenge is when somebody tries to programmatically build something (an API, XML Schmea, DB Schema, etc.) from computable UML.  For every different model, you have to hand-tune the code to account for the differences between what the UML actually says and what is really intended.

-Michael

On Wed, May 5, 2021 at 11:13 AM Björn Andersen <bjoern....@ieee.org> wrote:

Michael, thank You.

Your understanding is pretty accurate! I only have two really minor additions:

• Most descriptors may only have exactly one state, see BICEPS clause 5.4.3.
  
• "possess" actually means: States carry a handle reference to their descriptor.

As far as I know, there is no drawing or UML class diagram of the entirety of BICEPS.
Maybe something can be generated from the XSD files: https://sourceforge.net/p/opensdc/bicepsmodel/ci/master/tree/
The readability of the BICEPS annexes is indeed pretty awful.

And funny You should ask... Yes, there is definitely an implicit understanding of which HandleRef shall refer to which kind of descriptor.
A similar discussion starts here: https://sourceforge.net/p/opensdc/ieee11073-10207/211/#ddfc
I agree that it would be much nicer if that understanding was made even more explicit in BICEPS. :-)

-Björn

On 03.05.2021 21:21, Michael Faughn wrote:

I am kind of testing my understanding of BICEPS here so please let me know if any of this is wrong...

I do not think the diagramed object refers to an instance of an Alert at all, at least not in the sense of a temporal instance.  It's my understanding that elements in a BICEPS MDIB are bipartite.  Each has a Description object that specifies the capabilities of that element (what is it, what can it do) and zero or more State objects that contain / convey the...state (what is it doing right now).  Description objects "possess" their corresponding State objects.

Unless I'm mistaken, none of the information (i.e. attribute values) in AlertSignalDescriptor would change at all during the scenario that Paul outlines.  The values that would change would be in the AlertSignalState and AlertConditionState components.  You would determine the start and end of an Alert Signal by interrogating the AlertSignalState object.  You would determine what the AlertSignal was for by tracing the value of AlertSignalDescriptor.ConditionSignaled back to the AlertConditionDescriptor that it referenced.  The AlertConditionDescriptor object has attribution for Kind (Phys, Tech, Other), Priority (Lo, Med, Hi, None), and Type (a CodedValue that can be an 11073 term that describes the condition).  The AlertConditionState object has an attribute, DeterminationTime, that indicates the time when the condition last changed, from which condition start and end may be derived.  In short, it looks like everything is there, even if it isn't organized in the same way that it is in 10201.

As an aside...Is there a readable UML class diagram of the entirety of BICEPS somewhere?  The alphabetical organization of 10207 is not at all conducive to tracing through the hierarchy and really "getting to know" it, especially since there is no "back" button when following links through a PDF (at least not in the viewer I'm using).  Also, for practical purposes, it would be nice to see a diagram that actually drew lines for associations between objects that are technically referenced via handles.  There is an implicit understanding (at least I hope there is) that, for example, the value of  AlertSignalDescriptor.ConditionSignaled must be a Handle for an AlertConditionDescriptor.

-Michael

On May 4, 2021, at 6:54 PM, Monroe Pattillo <monroe_...@bellsouth.net> wrote:  [3]

Specific alarm indications other than active (or not active indicated by absence) are not communicated.  Other than the ACM AM actor recording states of specific indications for logging, retrospective analysis, or clinical engineering repair actions the AM actor is not positioned to actively do anything specific to specific indications being present or absent.  Updates in alert phase, inactivation state and alarm state communicated to the AM actor in PCD-04 transitions, in both the initial phase, in updates, and end phase, are useful in escalation management.  

 

It was my understanding that the alarm standard, not the IHE ACM profile, dictated the circumstances under which audio and visual indications are required to be present.  If for some reason local alarm audio were active, but local alarm visual was not I would expect the alarming device to raise a separate technical alarm (ACM PCD-04 alert alarm technical) and possibly an equipment management event (MEM DMC DMIO PCD-15), assuming the alarming device has the smarts to recognize the nonconforming incident.

 

I’m ok with for now providing a means of communicating for logging the indications and determining how to respond to changes in them at a later date.

 

Regards,

 

Monroe Pattillo

On May 4, 2021, at 3:02 PM, Paul Schluter <pssch...@gmail.com> wrote:  [4]

Michael, Björn and colleagues,

The text for Clause 6.1.7.1 from IEEE P11073-10701 Draft 1 (2021-02-06) provides the only context I have been able to find regarding MDC_ALERT_SIGNAL_MSMT_STAT_INDICATOR.  It is the value of the attribute pm:type/@Code, and as such, does not have any child nodes to convey additional information.  The containing context is a technical event, MDC_EVT_STAT_MSMT_START and MDC_EVT_STAT_MSMT_COMPLETE.

Based on Clause 6.1.7.1 below, this appears to mean “the { visual, audio, haptic, other } associated with indicating that a measurement (or procedure) is taking place”.  An immediate question that comes to mind is whether similar terms have been considered for other technical and physiologic events and alerts: are there enumerated values for those?  

From a medical-legal standpoint, providing more detail about alert indication type { NONE, VISUAL, AUDIO, HAPTIC } could be conveyed by defining a new attribute, MDC_ATTR_ALERT_INDICATION.  The proposed Boolean flags are consistent with the Alarm Inactivation State (AIS) discriminator suffixes already defined in the IEEE P11073-10101b Group1 terms.  At a minimum, we should also define an additional attribute or numeric (SCADA) identifier to convey the alert audio volume, e.g. MDC_ATTR_ALERT_AUDIO_VOLUME or MDC_ALERT_AUDIO_VOLUME.  [I have included Monroe Pattillo and Rob Wilder given their expertise on this topic and suitable for inclusion as optional payload elements in IHE PCD ACM PCD-04 and other transactions.]

Best regards, and I look forward to our discussion tomorrow at 11:00 AM CDT.

Paul Schluter

email:  pssch...@med.ge.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, May 26, is cancelled, due to the IEEE 11073 GC and HL7 DEV meetings this week.

I would like to thank everyone who attended last week’s RTM meeting, including Björn Andersen, Charles Parisot, Eldon Metz, Jan-Alrik Philipsen, Martin Kasparik, Michael Faughn, Monroe Pattillo, Norman Jones and Javier Espina.  We made great progress in discussing and resolving all remaining issues regarding the 10101b Group7 SDC and other terms.  They have now been assigned numeric codes and have been submitted to Michael Faughn so that he can independently verify that there no code conflicts with existing terms, at which point they can be declared and memorialized as “provisional” terms on the RTMMSv2.

I am sending you a copy of the presentation I gave today to the IEEE 11073 GC and HL7 DEV groups today regarding the status of the IEEE P11073-10101b nomenclature effort.  If you have any questions or comments, please feel free to contact me.

We will reconvene next Wednesday, June 2nd, where we will resume and hopefully conclude our discussion of the 10101b Group6 terms related to the IEEE 11073 expression of ISO 19223 ventilator mode and other ventilator topics.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<IEEE_NomenclatureStatus.2021-05-25.Virtual.1g.2021-05-25T10.presented.pptx>>

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, June 2, at 11:00 AM CDT.  We will discuss the remaining 10101b Group6 terms related to ISO 19223 ventilator mode, specifically the

• optional expression of Selectable Adjuncts as an independent set of Boolean flags
• ventilator trigger type and
• ventilator operational state.

We have already done most of the heavy lifting regarding the mapping of the ISO 19223 ventilator mode syntax and nomenclature to a pre-coordinated set of IEEE 11073 REFIDs earlier this year.  I have attached the vendor ventilator modes and their mappings to ISO 19223 and IEEE 11073 REFIDs for Draeger, GE Healthcare and Getinge/Maquet that have been approved by business leadership for inclusion in 10101b.  [This information will be consolidated into a single Annex in IEEE P11073-10101b; implementers can consult ISO 19223 for additional foundational examples.]

The topics I would like to discuss tomorrow are listed below, plus any comments and suggestions that you may have:

MDC_VENT_MODE_ISO_19223

1.     PEGjs is specified in separate table due to size and complexity.  The most recent version was posted <<VentModeISO.5c.2020-11-11T10.docx>> (attached).

2.     Should we allocate additional codes to indicate the presence/optionality of MDC_VENT_MODE_SEL_ADJUNCTS_ISO_19223 as a companion piece of information in a message.

- 00 SelAdjuncts not used

- 01 SelAdjuncts may be used  (or 00?) (default)

- 10 SelAdjuncts required

MDC_VENT_MODE_SEL_ADJUNCTS_ISO_19223

1.     The Boolean flag mnemonics match those used by ISO 19223 representation for Selectable Adjuncts.

2.     Selectable Adjuncts may be encoded in MDC_VENT_MODE_ISO_19233 and/or MDC_VENT_MODE_ADJUNCTS_ISO_19223, with the effective value being the logical‑OR of both representations.

3.     Remove _ISO_19223 suffix from the REFID?



MDC_VENT_MODE_DISPLAY_TEXT

 

MDC_VENT_MODE_TRIGGER_TYPE

1.     Add ‘volume’ for Draeger Babylog?  Or, just classify this as a “flow” trigger?



MDC_VENT_OPERATIONAL_STATE

1.     These would apply to ventilators and anesthesia machines.

2.     Not every enumeration would apply to every vendor device, but these are the common ones.

3.     OperationalMode – this is normal ventilation operation, is there a better Enum_Value, such as “TherapyVentilation” to match the ones listed afterwards?  The ISO 19223 mode would be required.

ApneaVentilation – ISO 19223 expression needed?

BackupVentilation – ISO 19223 expression needed?

FailSafeVentilation – ISO 19223 expression needed?

4.     The existing IEEE 11073 attribute MDC_ATTR_VMD_STAT is too general and non-specific for complex devices and systems such as ventilators, anesthesia and dialysis machines, whereas MDC_VENT_OPERATIONAL_STATE uses phrasing that most vendors and users to describe the overall operational state of the device or system.

Thank you for your thoughtful consideration in advance, and best regards,

Paul Schluter

gmail:  pssch...@gmail.com

cell:  (414) 702-2026

<<AllTogetherGroup6.x4a.2021-06-01T12.for-review.xls>>   material for tomorrow’s RTM call

<<VentModeISO.5c.2020-11-11T10.docx>>  latest write-up regarding the overall ISO 19223 to IEEE 11073 REFID mapping

<<ISO-Filter.2a.2020-12-09T08.Draeger.html>>   

<<ISO-Filter.2a.2020-12-09T08.Getinge.html>>

<<ISO-Filter.1hy.2021-04-09T19.GE.html>>

On May 25, 2021, at 5:40 PM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcon for tomorrow, Wednesday, May 26, is cancelled, due to the IEEE 11073 GC and HL7 DEV meetings this week.

I would like to thank everyone who attended last week’s RTM meeting, including Björn Andersen, Charles Parisot, Eldon Metz, Jan-Alrik Philipsen, Martin Kasparik, Michael Faughn, Monroe Pattillo, Norman Jones and Javier Espina.  We made great progress in discussing and resolving all remaining issues regarding the 10101b Group7 SDC and other terms.  They have now been assigned numeric codes and have been submitted to Michael Faughn so that he can independently verify that there no code conflicts with existing terms, at which point they can be declared and memorialized as “provisional” terms on the RTMMSv2.

I am sending you a copy of the presentation I gave today to the IEEE 11073 GC and HL7 DEV groups today regarding the status of the IEEE P11073-10101b nomenclature effort.  If you have any questions or comments, please feel free to contact me.

We will reconvene next Wednesday, June 2nd, where we will resume and hopefully conclude our discussion of the 10101b Group6 terms related to the IEEE 11073 expression of ISO 19223 ventilator mode and other ventilator topics.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<IEEE_NomenclatureStatus.2021-05-25.Virtual.1g.2021-05-25T10.presented.pptx>>

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, June 9, is cancelled.  Based on our discussion last Wednesday, I have made a minor tweak to our list of enumerated values for MDC_VENT_OPERATIONAL_STATE.  The next step will be to consolidate the vendor ventilator modes and their mappings to ISO 19223 and IEEE 11073 REFIDs for Draeger, GE Healthcare and Getinge/Maquet into a single consolidated table suitable for publication in IEEE P11073-10101b.  We will review that material next week.

During our discussion last Wednesday, it was felt that the moniker “SuperUser” was not quite what we wanted and after further email discussion we decided to adopt “ServiceSysAdmin”, which everyone was satisfied with.  The Enum_Description was updated to match, and both highlighted in yellow below.

This would have the added benefit of more clearly relating the “ServiceSysAdmin” state to the “Service” state.  Both enumerations would remain available since both are used in devices and systems today.  The enumerations listed below may be reused by other device-specific and device-neutral indications of operational state.

During our discussion it was suggested that "RESPONSIBLE ORGANIZATION” be somehow included in the Enum_Definitions as well, but we will place these role designators in the introductory text prior to the table.  The will preserve the technical clarity and accuracy of the Enum_Descriptions we have below.

Thanks and regards,

Paul Schluter

gmail:  pssch...@gmail.com
cell:  (414) 702-2026

MDC_VENT_OPERATIONAL_STATE  (updated)

Enum_Values	Enum_Descriptions
Unspecified	Not otherwise specified (NOS)
Off	Off (reported by external device interface)
PowerOnSelfTest	Power-on self test
PreUseCheck	Pre-use system checkout (may include breathing system check)
BreathingSystemCheck	Ventilator breathing system check, extending within and outside the body of the ventilator or anesthesia system.
Calibration	Calibration
Standby	Standby
PatientSetup	Enter patient information, alarm limits, ventilation mode and other settings
StartVentilation	Start ventilation
OperationalMode	Normal operational state using the intended ventilation mode as configured by the operator's settings and selections.
ApneaVentilation	Selected apnea ventilation mode, a safety provision by which the ventilator automatically switches to a predetermined ventilation mode that generates controlled breaths whenever a hypoventilation alarm condition occurs or when a breath is not detected during a specified period of time.
BackupVentilation	Backup mode of ventilator where the normal function is for the ventilator to automatically deliver an inflation of a predetermined inflation-type when a breath is not detected during a set period.
FailSafeVentilation	Selected fail-safe mode of ventilator, a safety provision by which the ventilator automatically switches to a predetermined alternative ventilation-mode intended to maintain patient safety in the event of a component, sensor or function becoming inoperable.
Service	Service state, where the device or system is diagnosed, repaired and/or maintained by trained personnel.
ServiceSysAdmin	Service system administrator state, allowing qualified biomedical or service personnel to make unrestricted, potentially adverse, system-wide changes to a device or system in a role-based security model.
SoftwareUpdate	Software update state.
Failed	Failed state, the device or system is non-operational.
Shutdown	Standby/Shutdown, the device or system is shutting down.
MonitoringOnly	Monitoring only; active ventilation is not occurring.

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, June 16th, is cancelled.  I have a contractor coming to our house tomorrow and will need to confer with him during the morning.

We will reconvene next Wednesday, June 23rd, where we will discuss the consolidated list of Draeger, GE Healthcare and Getinge/Maquet ventilator modes and their mappings to ISO 19223 and IEEE 11073 REFIDs suitable for publication in IEEE P11073-10101b, as well as guidelines for additional vendor mappings in the future.

Thanks and regards,

Paul Schluter

gmail:  pssch...@gmail.com
cell:  (414) 702-2026