Please join our RTM tcon tomorrow, Wednesday, July 11, at 11:00 AM CDT - quick review of IEEE 11073 units-of-measure, then back to events and alerts!

[Paul Schluter]

Greetings!

Please plan to join our RTM tcon tomorrow, Wednesday, July 11, at 11:00 AM CDT.  We will start with a quick review of the IEEE 11073 units-of-measure for the mandatory 10101R revision later this year, and if there’s time, we will return to events and alerts.  The Webex and tcon information is provided at the end of this email.

The IEEE-SA also requires that standards be ‘revised’ every ten+ years.  In our case, this means that ISO/IEEE 11073-10101a-2015 is merged with 11073-10101:2004 to created a combined document and that any aspect of the revised document is subject to review and possible revision.  In this case, Malcolm Clarke, who is a co-chair for the IEEE 11073 PHD working group, is adding IEEE 11073 PHD terminology developed on behalf of the ISO/IEEE 11073-20601 Personal Health Device standard and approved ISO/IEEE 11073-104xx PHD device specializations.  I will be responsible for any terminology revisions related to the IEEE 11073 PoCD working group and the IHE PCD domain and ensuring alignment between this work and the previous -10101:2004 and -10101a-2015 terminology standards and what has already been captured on the NIST RTMMS.

The scope of IEEE P11073-10101b has and will not change - although it will likely be drafted as an amendment to -10101R it could also be drafted as a revision to -10101R if necessary, given the magnitude of our work regarding infusion pumps and events and alerts.  That said, this should not adversely affect our progress on -10101b (other than the additional time consumed) and we will have the ability to ‘lock-down’ new IEEE 11073 terms and codes using the NIST RTMMS ‘provisional’ term assignment process to avoid any further delay of the work within the IHE PCD domain and other organizations.  Given that we are trying to have -10101R balloted and approved by this October, no additional content on behalf of the PoCD and IHE PCD communities is planned for -10101R.

That said, the -10101R revision is a great opportunity to clarify, and, if necessary, revise the original IEEE 11073-10101:2004 base nomenclature standard and recent IEEE 11073-10101a-2015 amendment.  To that end I am sending you a summary of the current list of IEEE 11073 units-of-measure (MDC_DIM in partition 4) and including their REFIDs (aka UOM_MDC) and UCODE10 numeric codes.  The left-hand column includes all the base unit codes from the NIST ‘x73’ table (REFID::UCODE10) and the right-hand column includes all the base unit codes that are planned for -10101R, including new codes that have been defined since ISO/IEEE 11073-10101a-2015 was approved and published in late 2015.

The UoM term-code 11200 (row 346) was the last one defined in ISO/IEEE 11073-10101a-2015.  The term-rows highlighted in light-green were defined afterwards based on requests from the PHD community and several PoCD vendors over the past two years and should be considered ‘provisional’ due to the substantial review they have received.   The term-rows highlighted in light-blue are more recent additions that will be included in 10101R as well, including two requested by Christophe Fournier and the IHE PCD infusion working group to further support nutritional caloric infusions.  [The NIST RTMMS will be updated with these changes, including all decade-scaled UoM values that are supported by present-day gateways and devices and their mappings to UCUM, after we review and approve this list.]

There are several ‘legacy’ REFID-synonyms that should be removed.  For example, I believe that we should deprecate or remove the REFID-synonyms MDC_DIM_PARTS_PER_BILLION and MDC_DIM_PARTS_PER_TRILLION since they are ambiguous internationally (this would be aligned with UCUM as well as hRTM) and possibly MDC_DIM_PPMD as well.  These rows are indicated by ‘REMOVE’ in the comment column, and practically all of them are REFID-synonyms - that is, the primary/preferred REFIDs and numeric codes will still exist.

My request to you for tomorrow’s RTM tcon is to take a quick look at the commented items in the ‘10101R’ column of the ‘Compared’ worksheet.  We will briefly review and discuss this material during the first part of our RTM tcon tomorrow and if you have any additional comments or findings, please send them to me no later than Monday, July 16th, so that I can finalize the list.  [At the present time I am only planning to remove the legacy REFID-synonyms in rows that have ‘REMOVE’ in the comment column.]  Of course, you will have additional opportunities to comment on this information during the formal balloting of IEEE 11073-10101R later this summer.

Hopefully this won’t take too much time, since most of this information has been stable for years.  If we have time tomorrow, we will continue our review of events and alerts, starting with ECG and the recommendations we have received to date regarding additional alert concepts for this parameter.

Best regards,

Paul Schluter

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


<<NISTx73v10101R.1c.2018-07-07T11.xlsx>>

PS.  What does the _X_ in the REFID mean?

1.  The IEEE 11073-10101* vocabulary standards SHALL use _X_ in the UoM REFID to (1) denote a decade-scalable unit-of-measure and (2) serve as the REFID for a unity-scaled (1) unit of measure.

2.  A message, if it includes the UoM REFID, MAY use ‘_X_' in the REFID OR replace it with ‘_’, sent with the base UoM numeric code.  

3.  The RTMMS x73 tab, representing the original IEEE 11073 standards, uses ‘_X_’ to indicate decade-scalable unit-of-measure.

4.  The hRTM has a mix of both ‘_X_’ (infusion pump terms) and ‘_’ (for everything else), just like a message can.  The hRTM has a mix of ‘_X_’ and ‘_’ unity-scaled UoM based on how things evolved with the IHE PCD effort and later the PCHA/Continua WAN, where most everyone preferred the ‘_’ rather than the more obscure ‘_X_’ version.

The fact that the ‘_X_’ and ‘_’ may be used in the REFID of a message (e.g. HL7 V2 OBX-6.2) does not introduce any ambiguity - first, the numeric code in OBX-6.3 is still the governing quantity and second, for those who want to validate the REFID, replacing the ‘_X_’ with ‘_’ in the OBX-6.2 REFID may be used.  Another way of viewing this is that replacing the ‘_X_’ with a ‘_’ in any MDC_DIM_* REFID creates a valid REFID-synonym that may be used in messages.

————————————————————————————————————————————————————

GENERAL MEETING ACCESS INFORMATION
All meetings have the same phone number, but different access numbers:
Call the number below and enter the access code. Webex will offer Internet audio, an 800 number and a 650 area code number as options.
Call-in toll-free number (US/Canada): 1-866-469-3239 
Call-in toll number (US/Canada): 1-650-429-3300 
Global call-in numbers: https://himss.webex.com/himss/globalcallin.php?serviceType=MC&ED=9775253&tollFree=1 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 
Please log on before dialing in; Webex will tie your name to the phone line.
For assistance 
1. Go to https://himss.webex.com/himss/mc 
2. On the left navigation bar, click "Support". 
 
Rosetta Terminology Mapping – Ventilator  See emails from the WG for the type of meeting scheduled (General or Ventilator)
RTM meetings occur as vent specialization or general
Topic: PCD Rosetta Terminology Mapping WGs 
Date: Every Wednesday, from Wednesday, March 23, 2011 to no end date 
Time: 12:00 pm, Eastern Time 
Meeting Number: 490 820 843 
Meeting Password: PCDmeet1 

------------------------------------------------------- 
To join the online meeting (Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://himss.webex.com/himss/j.php?ED=9781998&UID=0&PW=NZmQwZjAzZDg5&RT=MiMxMQ%3D%3D 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: PCDmeet1 
4. Click "Join". 

To view in other time zones or languages, please click the link: 
https://himss.webex.com/himss/j.php?ED=9781998&UID=0&PW=NZmQwZjAzZDg5&ORT=MiMxMQ%3D%3D 

To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 

https://himss.webex.com/himss/j.php?ED=9781998&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=Bj9OYiW8VEQhy-oOHyR5Y27EhXfkdN3fl6kHKnnIIR4=&RT=MiMxMQ%3D%3D

[Paul Schluter]

Malcolm and colleagues,

Most of the IEEE 11073 “classicists” would insist that the _X_ be required in the REFID that appeared in a message, and it is really the upstart PCDers and PHDers (via the PHD/Continua WAN interface) who are incorrect by using _ instead.  Both variants (with ‘_X_' or ‘_’) are used by shipping devices and systems today.

So here is what I propose to make everyone happy:

In the 10101R revised standard and in the updated tables available on the NIST RTMMS, the following REFID variants will be listed in the order shown below:

1. If the UoM is decade-scalable (has an _X_) the _X_ variant of the UOM_MDC will be listed first.
2. If the UoM is decade-scalable, the ‘_’ variant (e.g. using the XSLT and XQuery replace(REFID, ’_X_’, ’_’) function) will be listed second and in italics, like all other REFID synonyms are.  This will facilitate searching, whether you are using the NIST RTMMS or the published IEEE 11073-10101R standard.
3. There are a few REFID-synoyms, and they will be listed second or third, unless we decide to deprecate a subset of hem.

These would be listed in the same table UOM_MDC cell, like we do with other REFID-synonyms, so that the common information (Dimensionality, Description, UOM_UCUM, UCODE10, etc.) associated with each unit is listed once.  I will also include the CF_CODE10 for deployment in HL7 V2 messages, and, assuming we adopt the ISO/IEEE 11073-10101a-2015 Annex C style of listing this information along with the associated discriminator set identifier, we would include the CF_UCODE10 information there as well.

Best regards,

Paul

On Jul 11, 2018, at 1:52 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

I would like to ask clarification on this aspect, so that the wording is changed to something like

2.  A message, if it includes the UoM REFID, should _X_ replace it with ‘_’ for unitary scaling but may use _X_.

[Paul Schluter]

Malcolm,

In the standard, the ‘_X_’ form of the UOM_MDC REFID SHALL be used to clearly distinguish them from non-decade scalable units-of-measure, and will be listed first if alternative REFID-synonyms exist for the same numeric code.

In supporting documentation for developers and other interested parties, either form may be used (or omitted) in an IHE PCD DEC message, e.g. OBX-6.2, since the context-free 32-bit numeric code in OBX-6.1 and  vocabulary designator in OBX-6.3 are the normative and both are required.

I would be okay with a phrase like “should use ‘_X_' but may use ‘_’ in a message that permits the REFID to be sent”.

Best regards,

Paul

On Jul 11, 2018, at 11:11 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

This is overkill, there is no need for italics or anything else. What is required is a statement as to which form (_ or _X_) is preferred for use, hence I suggest "should use _X_ but may use _"

Regards

MAlcolm

[Paul Schluter]

Malcolm and colleagues,

There are not that many REFID-synonyms (different REFID identifier strings with same numeric code) and we do have a way of handling them in the RTMMS and in the published IEEE 11073 standard where the preferred REFID is listed first within the ‘Reference ID’ table cell and the less preferred but otherwise equivalent REFID is listed afterwards.  By specifying the order we can support deterministic reverse-translation from the numeric code back to the preferred REFID.  REFID-synonyms are a fact of life and almost unavoidable, and any coalescing of REFID-synonyms into a single preferred REFID has to be balanced with the fact that the less preferred REFIDs are being deprecated and could potentially obsolete existing vendor implementations and documentation.

The tougher issue are synonyms where the REFIDs and numeric codes are both different yet the term means the essentially the same thing.  If reviewers are serious about this topic then they should submit the list of synonym REFID::Part::Code for further review.  Again, this may be controversial since one vendor may be using term and another is using a different one.  It may be easier just to compile these and post a curated list on the NIST RTMMS.

I personally do not view REFID-synonyms as a major issue.  Furthermore, the terms will be further collapsed in any case on their way into the EMR, as many clinicians prefer to see a single indication of heart rate and respiration rate on their flow sheets, and not the half-dozen or so device-specific rates that can be reported for each.  That is, further customization and coalescing of terms is typically performed at the provider’s site when the EMR is installed, and hopefully this task will be facilitated by providing a highly standardized nomenclature such as ISO/IEEE 11073-10101* and a curated list of the known REFID::Part::Code synonyms.

Best regards,

Paul

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

On Jul 12, 2018, at 7:05 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

As 10101R is to be published as version 2 of the nomenclature, we might take the opportunity to harmonise terms (RTMMS?) and remove many of the synonyms. Certainly this is a comment I am hearing.

Regards

Malcolm

On 10/07/2018 20:40, Paul Schluter wrote:

[Paul Schluter]

Greetings,

The RTM tcon is cancelled for today, Wednesday, July 18, in part since I am in Nashville at the Center for Medical Interoperability two-day test event and vendor meeting this week.

There are two remaining issues regarding units-of-measure, both for the upcoming 10101R ‘revision’ to the IEEE 11073 nomenclature and to the harmonized Rosetta (hRTM) that specifies the units-of-measure co-constraints for the 900+ observation identifiers that are currently supported.

1.  Trace quantities using ppm, ppb, ppt and ppq

We plan to add support for parts-per-million, -billion, -trillion (and possibly -quadrillion) which could be used to report trace amount of contaminants in an anesthetic gas supply or other sources.  We are trying to align this addition with the existing MDC_DIM_PARTS_… terms, but removing the any ambiguity of the existing REFIDs with respect to the meaning of ‘billion’ and ‘trillion’, which will now match SI units, the Oxford English dictionary and how the financial trading industry interprets ‘billion' (as 10^9) and ‘trillion' (as 10^12).

2.  SVRI and PVRI units-of-measure.

Although there is a preferred unit-of-measure for SVRI and PVRI, dyne s m² cm^-5, aka MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5 (4::8320; 270464), we have identified at least one vendor implementation that uses the alternative unit-of-measure, dyne s m^-2 cm^-5, aka MDC_DIM_DYNE_SEC_PER_M_SQ_PER_CM_5 (4::6016; 268160).  Although the former appears to be the preferred unit-of-measure, the latter also appears in the literature as well.  The hRTM currently only allows the former, and we would like to keep it that way if all vendors actually use dyne s m² cm^-5, aka MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5 (4::8320; 270464), but if at least one vendor actually uses the latter, then we will need to permit it in the hRTM as well.

Although this is less than ideal, the top-most goal of any interoperability standard is that it faithfully represent what the device has observed, calculated and displayed and fully inform any data consumers such as an EMR.  In the case of SVRI and PVRI, the two different units-of-measure clearly indicate that different BSA normalization has been used, and this is not too different than the handling the various BSA and other normalizations used for infusion pumps.  [I will also review the clinical literature to confirm the BSA normalization that actually fulfills its intended purpose of normalizing the data with respect to BSA; as I recall, there were several papers that confirmed that dyne s m² cm^-5 is the appropriate unit-of-measure to use.]  

Please see the more detailed note below regarding this topic and send me an email if you use the less-preferred dyne s m^-2 cm^-5  by Tuesday, July 24, in which case we will need to allow both in the hRTM.

Thanks and best regards,

Paul Schluter

 

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

 

Email message regarding units-of-measure for SVRI and PVRI - which unit(s) do you use?

Could you kindly reconfirm the units-of-measure that you are using for SVRI and PVRI?  Years ago, in an another IHE PCD discussion, we concluded that everyone used MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5 (4::8320; 270464 as a 32-bit integer).  The corresponding equivalent UCUM units are dyn.s.m2/cm5 and dyn.s.cm-5.m2.

 

This unit of measure arises when the SVRI and PVRI is calculated as follows:

 

   SVRI = [ ( MAP -  CVP) / CI ] x 80  where the Cardiac Index CI = Cardiac Output CO / BSA .

 

This can also be equivalently expressed as 

 

   SVRI = [ ( MAP -  CVP) / CO ] x 80  x  BSA   where [ ( MAP -  CVP) / CO ] x 80  is the systemic vascular resistance SVR or PVR

 

If this method of calculating SVRI and PVRI used, then the units are dyne s m² cm^-5, aka MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5 (4::8320; 270464).

 

I have seen SVRI and PVRI calculated in the literature where the BSA appears in the denominator, yielding dyne s m^-2 cm^-5, aka MDC_DIM_DYNE_SEC_PER_M_SQ_PER_CM_5 (4::6016; 268160).  This appears to be the unit-of-measure that some vendors have indicated that they are using for SVRI and PVRI.

 

If both methods of calculation are used (which is not the conclusion we arrived at several years ago in the IHE PCD domain) then we may need to allow either unit-of-measure to be used.  When we considered this option (allowing either unit) the proposal was harshly criticized, since we would be allowing two different methods for calculating and reporting the same named variable.  That’s when we dug deeper and concluded that everyone actually was calculating SVRI and PVRI in the same manner and thus dyne s m² cm^-5, aka MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5 (4::8320; 270464) was the single correct unit, and that is why it is the only one listed in the harmonized Rosetta at the present time.

 

It would be great if we all could confirm that we actually calculate PVRI and SVRI the same way, including any technology licensed from other vendors.  If not, we may need to simply allow two fundamentally different units of measure to be used and that the method of calculation would be inferred from the unit of measure.  If we formally allow this, we would need to update the definitions for PVRI and SVRI accordingly (just in time for the 10101R revision currently underway) because I’m also quite sure that nobody wants to define two different observation identifiers for the PVRI or SVRI concept.

Thanks and regards,

 

Paul Schluter

 

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

 

 

SVRI/PVRI unit defined in 10101a-2015  dyne s m² cm^-5

Pulmonary/ Systemic Vascular Resistance Index

dyne seconds square meter per centimeter to the power of 5

dyne s m2 cm-5

MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5

4::8320

270464

 

SVRI/PVRI unit defined in 10101:2004  dyne s m^-2 cm^-5

- Pulmonary/Systemic vascular resistance index

dyne seconds per square meter per centimeter to the power of 5

dyne s m–2 cm–5

MDC_DIM_DYNE_SEC_PER_M_SQ_PER_CM_5

4::6016

268160

 

 

Harmonized Rosetta (hRTM) background regarding vascular resistances SVR and PVR

MDC_RES_VASC_SYS

150312

L-4MT-1 L-4MT-1 L-4MT-1

MDC_DIM_DYNE_SEC_PER_CM_5 MDC_DIM_MMHG_SEC_PER_ML MDC_DIM_MMHG_MIN_PER_L

dyn.s/cm5 [PRU] mm[Hg].s/mL [wood'U] mm[Hg].min/L

270656 270688 270720

 

Harmonized Rosetta (hRTM) – only MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5 is permitted at the present time

MDC_RES_VASC_SYS_INDEX

149760

L-2MT-1

MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5

dyn.s.m2/cm5 dyn.s.cm-5.m2

270464

[Paul Schluter]

Greetings!

Please plan to join our RTM tcon today, Wednesday, July 25 at 11:00 AM CDT.  We will focus on units-of-measure as we identify issues during the first ballot round of IEEE 11073-10101R.  We will postpone our discussion of events and alerts for an another week.  The Webex and tcon information is provided at the end of this email.

The first worksheet of the attached spreadsheet <CheckMDCUnits.4e.x1g.2018-07-25T07.withComments.xlsx> contains a comprehensive list of all IEEE 11073 units-of-measure to date, including units from ISO/IEEE 11073-10101:2004 and 11073-10101a-2015 plus additional units from the IEEE 11073 Personal Health Devices (PHD), IHE PCD domains and NIST RTMMS, collectively identified as the ‘Rosetta’ resources.  The list of base terms (divisible by 32 with REFIDs in bold font) is practically identical to the current draft of -10101R, but there are differences that we will need to explore and resolve.

The first worksheet also includes additional information used by the IHE PCD domain, such as decade-scaled expansions (shown in regular font) and mappings to UCUM.  The IHE PCD community should use the attached spreadsheet to verify that the units you plan to use, either MDC or UCUM, are listed on the first worksheet.  Adding decade-scaled expansions and mapping to UCUM for existing IEEE 11073 base UoM terms is relatively easy but if we need any additional base IEEE 11073 UoM terms, we should identify them now.

The smaller table at the end of the first worksheet is a comparison of the current IEEE 11073-10101R-D2-r3 draft with the Rosetta resources noted above, and the same table with comments appears on the second worksheet.  I am very happy to say that only 13 base term-row differences were found and most of the these are refinements or corrections to the REFIDs.  We will walk through these items during our tcon today and I plan to incorporate our discussion into the comments that will be submitted on July 31st and be available for further discussion and reconciliation within the ballot group.

During the IEEE 11073-10101R review and reconciliation process I will be reviewing other partitions, especially the SCADA partition that contains the vast majority of observation and settings identifiers used by the IHE PCD domain.  As I mentioned earlier, a key value-add for the IEEE 11073-10101R revision is the addition of the IEEE 11073 PHD terms under the careful curation of Malcolm Clarke and others in the IEEE 11073 PHD community.  Once this project is complete we will be able to support both the PoCD acute-care and PHD personal health devices with the NIST RTMMS serving as the single authoritative repository for all IEEE 11073 related terminologies, including new terminology development by multiple groups (IEEE 11073 PoCD, IEEE 11073 PHD, IHE PCD, PCHA/Continua, OpenSDC, OpenICE, The Center for Medical Interoperability and other organizations and communities, including clinicians and vendors).

That’s it for now, and I look forward to your participation later today.

Best regards,

Paul Schluter

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

NOTICE:  The attached document is based on an unapproved draft of a proposed or revised IEEE Standard, and as such, it is subject to change.  USE AT YOUR OWN RISK!  Because this is based on an unapproved draft, this document must not be utilized for any conformance/compliance purposes.

<CheckMDCUnits.4e.x1g.2018-07-25T07.withComments.xlsx>

[Paul Schluter]

Malcolm,

I based my comparison on my Excel extraction from the MS-Word draft standard <11073-10101R-D3-r2.doc> to ensure that it is consistent with all other IEEE 11073 resources that are available.

Best regards,

Paul

On Jul 25, 2018, at 9:55 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

I am attaching the spreadsheet I developed for myself to compare the tables (annex A), the defines (annex B) and RTMMS (download from Units tab).

Column

A Table RefID

B Table term code

C Check table entry with defines entry (* = code missing, $ RefD mismatch)

D Check defines entry with table entry (* = code missing)

E Check tables entry with RTMMS entry

F Check RTMMS entry with tables entry

G Defines RefID

H Define term code

I Check defines entry with RTMMS entry

J Check RTMMS entry with defines entry

K RTMMS REfID

J RTMMS term code

L Work column to find base code

This clearly shows where codes are missing or not matching.

There is good concordance with tables and defines, and with early RTMMS. PHD units are missing from  RTMMS towards end.

Regards

Malcolm

[Paul Schluter]

Malcolm and IHE PCD colleagues,

Malcolm, yes, we can use this week's (and possibly subsequent weeks) RTM tcon to discuss the first ballot round comments and other issues related to the IEEE 11073-10101R ‘revision’.  The Webex and tcon information is provided below.

To everyone, please feel free to attend this teleconference, even if you are not formally part of the IEEE 11073-10101R balloting group - we will always welcome your expertise.  The first ballot round ends this Tuesday, July 31st, at 11:59 PM EDT, so we will not have had much time to review everyone’s comments, but during the past month we have already built up a reasonable list of topics to talk about.

Best regards,

Paul Schluter

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

On Jul 30, 2018, at 7:42 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

May we use the Tcon this week to dispose comments on 10101R?

I have dealt with many, but some require discussion.

Regards

Malcolm

[Paul Schluter]

Malcolm and colleagues,

The <comment.xls> spreadsheet that you sent appears to have truncated a significant number of my longer comments, removing essential information.

Please verify that the transfer from the IEEE-SA worked correctly; when I submitted my comments, there were no warnings regarding length, and they really weren’t that long in any case.

Best regards,

Paul

On Aug 1, 2018, at 12:36 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

To assist our meeting today I am circulating the ballot comments and the most recent revision 10101-D3-r3.

Regards

Malcolm

[Paul Schluter]

Greetings,

I am sending you a short note that summarizes two bit-flag additions to the PowerStatus attribute originally defined in ISO/IEEE 11073-10201:2004 that will increase its usefulness for reporting AC-mains, battery and standby or off (unpowered) status.  This is conveyed as a set of Boolean (bit) flags that can be independently set or cleared and can be easily encoded an IHE PCD DEC or MEM-DMC HL7 V2.6 message.

The PowerStatus information is conveyed by the MDC_ATTR_POWER_STAT attribute (1::2389, CF_CODE 67925) is extremely useful for device management purposes, and as such, we should consider making MDC_ATTR_POWER_STAT a mandatory data item in IHE PCD MEM-DMC messages.

The proposed deviceOff(4) and standby(5) bits have already been ‘penciled’ into the next draft of 10201R, but if you believe we are missing any foundational information items related to device power status reporting, please let me know by Wednesday, August 8th.

Thanks for your thoughtful review in advance.

Paul Schluter

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

<<PowerStatus.1a.2018-08-02T15.docx>>

[Paul Schluter]

Greetings,

Please join our RTM tcon this Wednesday, August 15, at 11:00 AM CDT, where we will continue our review, discussion and reconciliation of the IEEE 11073-10101R ‘revision’ comments and issues.

I have attached the latest version of the main <comments.xlsx> spreadsheet that includes the entire text of the comments and proposed changes originally provided by the reviewers as well as proposed dispositions.  We will continue from where we left off last week.

The attached <comments_extra.xlsx> has additional issues that have been identified that we can review after we make our way through most of the main <comments.xlsx> spreadsheet.

Thanks for your thoughtful review and Malcolm and I look forward to a productive discussion tomorrow.

Paul Schluter

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

<comments.xlsx>

<comments_extra.xlsx>

[Paul Schluter]

Greetings,

The RTM tcon for Wednesday, August 15, is cancelled.  Many people, including myself, are on vacation that week.

We will reconvene on Wednesday, August 22, with the top priority of reconciling any and all remaining comments from the first ballot round of 10101R so that an updated draft can be recirculated as soon as possible.

Best regards, and enjoy your summer!

Paul Schluter

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

On Aug 7, 2018, at 8:55 PM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings,

Please join our RTM tcon this Wednesday, August 8, at 11:00 AM CDT, where we will continue our review, discussion and reconciliation of the IEEE 11073-10101R ‘revision’ comments and issues.

[Paul Schluter]

Greetings,

Please join our RTM tcon this Wednesday, August 22, at 11:00 AM CDT, where we will continue our review, discussion and reconciliation of the IEEE 11073-10101R ‘revision’ comments and issues.

The most recently updated <comments.xlsx> and <comments_extra_14-08-18.xlsx> were sent to you by Malcolm on August 15, along with the current interim draft <11073-10101R-D3-r4_15-08-18.zip> of 10101R.

Thanks for your thoughtful review and Malcolm and I look forward to a productive discussion tomorrow.  The Webex and tcon information is attached below.

Paul Schluter

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

Cell:  (414) 702-2026

<comments.xlsx>

<comments_extra_14-08-18.xlsx>

<11073-10101R-D3-r4_15-08-18.zip>

On Aug 15, 2018, at 7:33 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear All

For the tcon on August 22 I have prepared the attached files.

11073-10101 is the latest version of the document, which should now contain a definition in annex A for all (base) terms in annex B, except where I cannot determine an appropriate definition. I have started annex C with a number of partitions given in alphabetical order for comment.

I have collected terms with queries in the spreadsheet. You may return comments to me by email without need to wait for the tcon.

Also collected are terms where I have determined synonyms, and I would ask that we select a single term going forward.

There are a number of other queries to resolve.

Regards

Malcolm

[Paul Schluter]

Greetings,

Please join our RTM tcon today, Wednesday, August 29, at 11:00 AM CDT where we will have a preliminary and informal discussion about what to do with IEEE 11073 terms that with missing or unclear definitions.

I expect light attendance today since many are out on summer and pre-Labor Day vacations and it is an “off” week for many of the IHE PCD teleconferences (and I’m not sure whether Malcolm can attend due to travel).  So the discussion this week may be shorter than most, and we’ll just take this topic up again next Wednesday, September 5th, along with our walk-through of the -10101R ballot comments.  The Webex and tcon information is located at the end of this email.

Best regards,

Paul Schluter

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

On Aug 24, 2018, at 4:37 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear All

It is my proposal that any term currently in annex B that does not have a clear definition in annex A is deprecated in 10101R, as it not safe to use such terms. the comments spreadsheets I have circulated containt the terms for which I cannot determine a definition as they are either not intuitive and I can find no reference elsewhere.

May I therefore ask people to check the terms and respond with definitions where possible by next week's tcon.

Failing definition then I shall move such terms to a deprecated table in the next version of 10101R that shall go to recirculation.

Regards

Malcolm

[Paul Schluter]

Greetings,

Please join our RTM tcon today, Wednesday, September 5, at 11:00 AM CDT where we will continue our review and discussion of 10101R.  An updated draft of 10101R and comment logs were sent to you yesterday by Malcolm.

The Webex and tcon information is located at the end of this email.

Best regards,

Paul Schluter

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

Cell:  (414) 702-2026

On Sep 4, 2018, at 6:41 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear All

I have closed all but 1 comment from the initial ballot (see attached comments resolution), and have asked for clarification of that comment to complete. The attached (D3-r6) is almost ready for recirculation based on the comments.

However some questions remain that should be answered before recirculation, namely dealing with synonyms.

For my opinion, I believe a standard should have a single code to represent the concept of a data item. It is intended for machine to machine communication, and therefore synonyms have no purpose, and only make extra work for coding. Manufacturers claiming to adhere to the standard should use the single code, and we should not be supporting the choices of multiple manufacturers. We tell the world the purpose of Rosetta and 10101 is to harmonise our codes to a single representative code - it is perverse then to publicise synonyms.

The second spreadsheet contains synonyms I have identified. I would like to resolve each to a single code and deprecate. 10101R will then be complete for recirculation.

Regards

Malcolm

[Paul Schluter]

Greetings,

Please join our RTM tcon tomorrow, Wednesday, September 12, at 11:00 AM CDT where we will continue our review and discussion of 10101R.  An updated draft of 10101R and comment logs were sent to you earlier today by Malcolm (although the filenames are the same as the files sent last week, the content has been substantially updated, such as including the discriminator group identifiers).

The Webex and tcon information is located at the end of this email.

Best regards,

Paul Schluter

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

Cell:  (414) 702-2026

On Sep 11, 2018, at 10:47 AM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear All

I have made final changes to 10101R in readiness to submit for recirculation. This will allow to undertake comment resolution, deal with remaining issues and have any other discussions at HL7 meeting, hopefully in readiness for final recirculation.

We haven't quite met the timetable for publication in 2018, but the extra time has allowed us to produce a good final result which consolidates all 11073 nomenclature.

We can have final discussion on Wednesday before submission for this recirculation.

Regards

Malcolm

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, September 19, is cancelled.  I am currently out of town at The Center for Medical Interoperability in Nashville and will not be able to host nor attend the call.

We will reconvene next Wednesday, September 26th.  Please use the additional hour (and 1-1/2 weeks) to continue reviewing IEEE P11073-10101R - ballot comments are due at 11:59 PM Eastern on Saturday, 2018-09-29.

Thanks in advance for your thoughtful and thorough review!

Best regards,

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

[Paul Schluter]

Greetings,

The RTM tcons for today, Wednesday, September 26th, and next Wednesday, October 3rd, are cancelled.  

Please use this time to continue reviewing IEEE P11073-10101R - your ballot comments are due at 11:59 PM Eastern on Saturday, 2018-09-29.  If you have any questions or other issues, please feel free to send them to Malcolm, myself (and anyone else) by email prior to the ballot deadline.

We will be discussing the ballot comments during the HL7 and IEEE 11073 meetings in Baltimore next week, October 1 - 4.  The IEEE 11073 terminology (10101R, 10101b, RTMMS) will be the primary focus for Wednesday Q1 - Q2 (9:00 - 12:30) and Q3 (13:45 - 15:00).  Webex and tcon information will be made available on a later version of the IEEE 11073 meeting agenda.

We will reconvene two weeks from now, on Wednesday, October 10th.  

Thanks in advance for your thoughtful and careful review, and I look forward to seeing many of you at the HL7 and IEEE 11073 meetings next week!

Best regards,

Paul Schluter

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

[Paul Schluter]

Greetings,

Please attend our RTM tcon today, Wednesday, October 10th at 11:00 AM CDT.  We will be discussing the RTM and IEEE 11073 term proposal, approval and publication process.  This is a continuation of our discussion that started at the IEEE 11073 and HL7 HCD meetings in Baltimore last week.  The essential goal for this effort is to clearly define and document the process that we use today and expect to use in the future.  This will play an essential role in how we manage the development of existing and new terms in the future using the RTMMS and IEEE 11073 standardization and publication process.

To support our discussion today, I am sending a proposed process diagram that Malcolm Clarke sent out last weekend and a revised process diagram that I have prepared that addresses the additional goals and concerns of other parties that currently use or plan to use the RTMMS and IEEE 11073 nomenclature.  This includes NIST, IEEE, HL7 and FHIR, IHE PCD, PCHA/Continua, device manufacturers, clinical users, regulatory agencies and test and certification organizations.

Best regards, and I look forward towards your participation and a productive discussion today!

Paul Schluter

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

<<fig G1.1a.2018-10-06T15.malcolm.docx>>

<<ProcessDiagram.2a.2018-10-10T09.pss.docx>>

[Malcolm Clarke]

Dear Paul

Please note that RTMMS will become the custodian of all IEEE
nomenclature, both pre- and post-publication. It is therefore important
that RTMMSshows all states for codes including deprecated and withdrawn.
For this reason I include these lines between RTMMS and these states.

Zombie is not an appropriate technical term, and rejected is better.

Also note that deprecated terms will not be withdrawn as they must
remain defined to support databases with stored data. However withdrawn
codes will be invalid, as they are withdrawn because of error.

Regards

Malcolm

[Paul Schluter]

Malcolm and colleagues,

I agree with you that the RTMMS will support a long-term history of zombie, deprecated and withdrawn terms, but I see little need in showing that in the main diagram since that can and will be clearly expressed in the body text of Annex G.

Unless anyone has an objection, I would be happy to change ‘zombie’ to ‘rejected’.

Regarding your last point, the RTMMS will keep a record of all withdrawn terms, whether they be rejected (formerly zombie), deprecated or withdrawn.  Until we run out of numeric codes in a partition, we can use the RTMMS to detect the use of rejected and withdrawn terms in any and all messages, and deprecated terms once their grace period has elapsed.

For example, the SCADA partition is one of the most crowded partitions, but well over half of the non-private code points are still available, and I don’t see us running out any time soon:

   Total number of SCADA base terms: 1500
   Total number of SCADA code points: 24396

Best regards,

Paul Schluter

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

On Oct 10, 2018, at 4:18 PM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

Please note that RTMMS will become the custodian of all IEEE nomenclature, both pre- and post-publication. It is therefore important that RTMMS shows all states for codes including deprecated and withdrawn. For this reason I include these lines between RTMMS and these states.

[Paul Schluter]

Malcolm and colleagues,

I am sending you an updated version of the RTM and IEEE 11073 process diagram that was discussed during the RTM tcon today and I have incorporated many of the changes that were proposed later during the tcon and also by email afterwards.

The changes include -

1. All state identifiers now have an ‘rtm-‘ or ‘ieee-‘ or ‘iso-ieee-‘ prefix to clearly label them.
2. Show the ‘rtm-accepted’ state.  Additional clarification regarding this state will be required in the body text of Annex G.
3. Add explanatory italicized text on transitions (this was added to the transitions to ‘rejected’).
4. Removed the two ‘?’ (that served as a reminder to discuss during the RTM tcon) and removed yellow highlighting.
5. Draw an über-box around the 'ieee-approved' and 'ieee-published' states, since the latter follows the former in a predictable manner.
6. Added the ‘iso-ieee-published’ state.
7. Renamed the ‘zombie’ state to the ‘rejected’ state (hey, it was fun while it lasted)

If there are any changes that were missed or need to be added in retrospect, please let us know.  And thanks again for a very productive discussion!

Best regards,

Paul Schluter

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

<<ProcessDiagram.2b.2018-10-10T19.pss.docx>>

Attendees:  John Rhoads, Stefan Karl, John Garguilo, Malcolm Clarke, Spencer Crosswy, Richard Tayrien, Matthias Kaeser, Paul Schluter.

On Oct 10, 2018, at 6:19 PM, Paul Schluter <pssch...@gmail.com> wrote:

Malcolm and colleagues,

I agree with you that the RTMMS will support a long-term history of zombie, deprecated and withdrawn terms, but I see little need in showing that in the main diagram since that can and will be clearly expressed in the body text of Annex G.

Unless anyone has an objection, I would be happy to change ‘zombie’ to ‘rejected’.

Regarding your last point, the RTMMS will keep a record of all withdrawn terms, whether they be rejected (formerly zombie), deprecated or withdrawn.  Until we run out of numeric codes in a partition, we can use the RTMMS to detect the use of rejected and withdrawn terms in any and all messages, and deprecated terms once their grace period has elapsed.

For example, the SCADA partition is one of the most crowded partitions, but well over half of the non-private code points are still available, and I don’t see us running out any time soon:

   Total number of SCADA base terms: 1500
   Total number of SCADA code points: 24396

Best regards,

Paul Schluter

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

On Oct 10, 2018, at 4:18 PM, Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

Please note that RTMMS will become the custodian of all IEEE nomenclature, both pre- and post-publication. It is therefore important that RTMMS shows all states for codes including deprecated and withdrawn. For this reason I include these lines between RTMMS and these states.

Zombie is not an appropriate technical term, and rejected is better.

Also note that deprecated terms will not be withdrawn as they must remain defined to support databases with stored data. However withdrawn codes will be invalid, as they are withdrawn because of error.

Regards

Malcolm

[Malcolm Clarke]

Dear Paul

Terms can be deprecated and withdrawn within RTMMS before being published. It is important that this is shown. We have some PHD examples already.

Regards

Malcolm

[Malcolm Clarke]

Dear Spencer

Data may continue to exist in databases long after we make changes to nomenclature, and for this  reason we believe we should keep valid nomenclature as deprecated and not withdrawn. Deprecated will signify that nomenclature should not be used in future releases of systems and can be flagged that it needs to be updated.

We chose to have withdrawn for nomenclature codes that were in error, perhaps there was a code conflict and one must be withdrawn from use.

Rejected was to apply to codes that did not make it to RTMMS, but were to be kept for reference.

My belief is that we should be using RTMMS to manage the status of the terms, before and after publication, and so will require RTMMS to record nomenclature that is deprecated and withdrawn. I therefore indicated these paths on my diagram.

Regards

Malcolm

On 11/10/2018 19:54, Spencer Crosswy wrote:

All,

 

The diagram shows “deprecated” as an end-state; it also shows “withdrawn” as a result of IEEE balloting. I expected that terms intended for removal would become “deprecated” after balloting and that “withdrawn” would follow after some time delay. Is that not the case?

 

Malcolm, my understanding is that “rejected” (formerly zombie) and “deprecated” exist to distinguish between terms that were removed before and after balloting.

 

Thanks,

Spencer

[Malcolm Clarke]

Dear Paul

Thank you for your suggestions and contributions. I shall consider how to integrate to the next revision for ballot. However time presses and I must proceed.

You may comment during the next recirculation.

Regards

Malcolm

On 11/10/2018 20:32, Paul Schluter wrote:

Spencer and colleagues,

 

I largely concur with Malcolm’s points in the email he sent a few moments ago (attached), but perhaps we should try to refine the text to the level of precision and clarity that would be appropriate to a contract or standard, and after that is accomplished, possibly capture (some of) it as additional detail in the process diagram, starting with something like:

 

 

rejected (formerly zombie) – withdraw provisional term and code

 

Applies to provisional terms (REFID and Part::Code) that are later rejected prior to or during the IEEE balloting process and is immediately withdrawn from future use.

 

 

deprecated – withdraw term and code at a future date or revision

 

Applies to an existing term that is considered to be poorly defined or specified or is obsolete.  The term (REFID and code) will be withdrawn at a future date or future revision or amendment of the standard.

 

 

withdrawn – withdraw existing term and code

 

Applies to approved and provisional terms that should (shall) not be deployed in current (new) devices and systems that send data.

 

The withdrawn REFID[Disc]Part::Code term (or term set based on the discriminator Disc) is retained on the NIST RTMMS to facilitate detection in messages – ‘gone but not forgotten’ – and if detected, an error is reported for (new) devices and systems that send data.

 

 

As noted in my earlier email, there is sufficient free space in the SCADA partition to avoid reusing any withdrawn REFID-Part::Code 2-tuples.  This allows the NIST Tools (and other tools) to detect the use of formerly provisional tools that did not become rtm-accepted, rtm-accepted or ieee-approved or ieee-published terms.

 

Please feel free to update the text above to address any concerns that you have.  My preference would be to capture this as text with the precision and clarity appropriate to a contract or standard, and after that is accomplished, add a little more detail to the process diagram.

 

Best regards,

 

Paul Schluter

 

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

 

 

PS.  I have received the comment «I’ll never not say zombie.» from a fellow engineer who I admire and respect from Wisconsin.

 

 

Dear Spencer

Data may continue to exist in databases long after we make changes to nomenclature, and for this  reason we believe we should keep valid nomenclature as deprecated and not withdrawn. Deprecated will signify that nomenclature should not be used in future releases of systems and can be flagged that it needs to be updated.

We chose to have withdrawn for nomenclature codes that were in error, perhaps there was a code conflict and one must be withdrawn from use.

Rejected was to apply to codes that did not make it to RTMMS, but were to be kept for reference.

My belief is that we should be using RTMMS to manage the status of the terms, before and after publication, and so will require RTMMS to record nomenclature that is deprecated and withdrawn. I therefore indicated these paths on my diagram.

Regards

Malcolm

 

From: Spencer Crosswy <scro...@center4mi.org>
Date: Thursday, October 11, 2018 at 11:54 AM
To: Malcolm Clarke <mclar...@gmail.com>, Paul Schluter <pssch...@gmail.com>
Cc: "ihe-p...@googlegroups.com" <ihe-p...@googlegroups.com>, "ihe-p...@googlegroups.com" <ihe-p...@googlegroups.com>, PCD Technical Committee GG <ihepc...@googlegroups.com>, "ihe-pcd-...@googlegroups.com" <ihe-pcd-...@googlegroups.com>, IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>, "device...@lists.hl7.org" <device...@lists.hl7.org>, "Monroe Pattillo <monroe_...@bellsouth.net> (monroe_...@bellsouth.net)" <monroe_...@bellsouth.net>, 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" <Tom.Ko...@bbraun.com>, Norman Jones <nsjo...@btinternet.com>, "Hassing, Kai" <kai.h...@philips.com>, "Kaeser, Matthias" <matthia...@philips.com>, "Schlichting, Stefan" <Stefan.Sc...@draeger.com>, "Klotz, Tobias" <Tobias...@draeger.com>, "Rinda, Jeffrey E." <Jeffre...@hospira.com>, Ken Fuchs <kenj....@gmail.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>, Simon Baumhof <simon....@student.uni-luebeck.de>, "Sabo, Perry (Carefusion, non-GE)" <perry...@carefusion.com>, Scott Eaton <s.e...@mindray.com>, "ocoe...@qualcommlife.com" <ocoe...@qualcommlife.com>, "di...@moberg.com" <di...@moberg.com>, "Marks, Kenneth E" <KEMa...@madisoncollege.edu>, "Treacy, Stephen (GE Healthcare)" <Stephen...@med.ge.com>, "Krajnak, Mike (GE Healthcare)" <michael...@med.ge.com>, Neal Seidl <Neal....@med.ge.com>, "Comunale, Carter" <ccom...@bernoullihealth.com>, "McGuire, Jay" <jmcg...@bernoullihealth.com>, "Szente, Andras" <asz...@bernoullihealth.com>, Hadi Rahemi <rah...@circulationconcepts.com>, "shimp...@marshfieldresearch.org" <shimp...@marshfieldresearch.org>, Richard Tayrien <rtay...@center4mi.org>, Paul Schluter <psch...@center4mi.org>
Subject: RE: [External]: Re: Please attend our RTM tcon today, Wednesday, October 10th - zombie, deprecated, withdrawn terms - 'gone but not forgotten'

 

All,

 

The diagram shows “deprecated” as an end-state; it also shows “withdrawn” as a result of IEEE balloting. I expected that terms intended for removal would become “deprecated” after balloting and that “withdrawn” would follow after some time delay. Is that not the case?

 

Malcolm, my understanding is that “rejected” (formerly zombie) and “deprecated” exist to distinguish between terms that were removed before and after balloting.

 

Thanks,

Spencer

 

From: Malcolm Clarke <mclar...@gmail.com>
Sent: Thursday, October 11, 2018 2:48 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>; 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>; Kaeser, Matthias <matthia...@philips.com>; Schlichting, Stefan <Stefan.Sc...@draeger.com>; Klotz, Tobias <Tobias...@draeger.com>; Rinda, Jeffrey E. <Jeffre...@hospira.com>; Ken Fuchs <kenj....@gmail.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>; Simon Baumhof <simon....@student.uni-luebeck.de>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; Scott Eaton <s.e...@mindray.com>; ocoe...@qualcommlife.com; di...@moberg.com; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Treacy, Stephen (GE Healthcare) <Stephen...@med.ge.com>; Krajnak, Mike (GE Healthcare) <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; McGuire, Jay <jmcg...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org; Richard Tayrien <rtay...@center4mi.org>; Spencer Crosswy <scro...@center4mi.org>; Paul Schluter <psch...@center4mi.org>
Subject: [External]: Re: Please attend our RTM tcon today, Wednesday, October 10th - zombie, deprecated, withdrawn terms - 'gone but not forgotten'

 

Dear Paul

[Paul Schluter]

Greetings,

The RTM tcon for tomorrow, Wednesday, October 17th, is cancelled.  Many of us are attending the IHE PCD Face-to-Face meeting at The Center for Medical Interoperability in Nashville this week.

We will reconvene next Wednesday, October 24th.

Best regards,

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, October 24th, is cancelled. Hopefully we will be able to start up our discussion and review of the second round of 10101R (D3r7) ballot comments and their proposed resolutions next week.

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, October 31st, is cancelled.  Malcolm has been bogged down with his teaching responsibilities for the past few weeks and hasn’t had sufficient time to fully address the IEEE P11073-10101R-D3r7 comments he received last month.

[Paul Schluter]

Greetings,

The RTM tcon for tomorrow, Wednesday, November 7th, is cancelled.  My wife and I are traveling through the Niagara Falls and Toronto area this week so it will be difficult to host the call.  Hopefully we will be able to resume our discussion of the IEEE P11073-10101R-D3r7 comments next Wednesday, November 14th.

The Niagara Falls is a great example of what “data fluidity” could look like, on a massively grand scale.  

[Paul Schluter]

Greetings,

The RTM tcons for today, Wednesday, November 14, and next Wednesday, November 21, are cancelled.

Malcolm continues to be bogged down with his teaching responsibilities for the past few weeks and hasn’t had sufficient time to fully address the IEEE P11073-10101R-D3r7 comments.  It is also likely that many of us will be traveling to celebrate Thanksgiving Day so next week’s call is cancelled as well.

Enjoy Thanksgiving with your family and friends!

[Paul Schluter]

Greetings,

Please plan to join our RTM tcon today, starting at 11:00 AM CST.  It has been a while since our last meeting, so I would like to take this opportunity to walk through some of the new terms that will be added to 10101R to support the work of the IHE PCD domain and other organizations.  These are all incremental additions to existing devices and existing semantic groups, since the major device additions and new event and alert terms will be incorporated in 10101b.

Some of the topics we will review today include:

1.  Twenty new ventilator terms (based on topics we’ve considered before)

2.  Eight new terms based on requests by IHE PCD domain and other organizations and individuals

3.  Five agent “uptake” terms (likely addition, pending further refinement of definition and consent)

We will return to the topic of events and alerts next week, with an in-depth review of the proposed 10101R definitions for the event and alert identifiers that were originally listed in Annex B of ISO/IEEE 11073-10101:2004.  I will be sending out material regarding this topic later this week.

Thanks and regards,

Paul Schluter

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

PS.  If any of you would like a copy of the 28 terms (term groups 1 and 2 above) that will be included in 10101R, I will be happy to send you a copy of the spreadsheets.  I will be walking through this information during today’s meeting.

[Malcolm Clarke]

Dear All

A number of terms in 10101R have synonyms. This includes code synonyms (same code different RefId) and RefId synonyms (same RefId different code).

We need to consider whether some of these could be deprecated. At minimum we need to identify a preferred term to be used.

I should be grateful if people could complete the table with preferences and return to me. I shall collate.

Regards

Malcolm

RefId	Code	Part	Current preferred	Prefer	Deprecate	Comment
MDC_ECG_TIME_PD_PQ_SEG	16148	2				These are synonyms for US and EU
MDC_ECG_TIME_PD_PR_GL	16148	2				These are synonyms for US and EU
MDC_ECG_TIME_PD_RR_GL	16168	2
MDC_ECG_RR	16168	2
MDC_ECG_CARD_BEAT	16768	2
MDC_ECG_HEART	16768	2
MDC_ECG_CARD_BEAT_RATE	16770	2
MDC_ECG_HEART_RATE	16770	2
MDC_ECG_MULTIFORM	17016	2
MDC_ECG_V_P_C_MULTIFOCAL	17016	2
MDC_PRESS_BLD_ART_PULM_OCCL	18980	2
MDC_PRESS_BLD_ART_PULM_WEDGE	18980	2
MDC_PLETH	19380	2
MDC_PULS_OXIM_PLETH	19380	2
MDC_RESP_RATE	20482	2
MDC_RESP_RATE	20490	2	*
MDC_PRESS_RESP_PLAT_STATIC	20712	2				Added in 10101a
MDC_PRESS_RESP_PLAT	20712	2	*			Only this was defined in 10101
MDC_PRESS_AWAY_END_EXP_POS	20732	2	*			Only this was defined in 10101
MDC_PRESS_AWAY_END_EXP_POS_EXTRINSIC	20732	2				Added in 10101a
MDC_VENT_TIME_PD_INSP	21344	2	*			Added in 10101a
MDC_VENT_TIME_PD_PPV	21344	2				Only this was defined in 10101
MDC_VOL_AWAY_TIDAL_EXP_BTSD_PSAZC_PER_IBW	21596	2	*			Both added in 10101a
MDC_VOL_AWAY_TIDAL_EXP_PER_IBW	21596	2
MDC_VOL_MINUTE_AWAY_EXP_BTSD_PSAZC_PER_IBW	21616	2	*			Both added in 10101a
MDC_VOL_MINUTE_AWAY_EXP_PER_IBW	21616	2
MDC_FLOW_FLUID_PUMP	26712	2	*
MDC_RATE_INFUS	26712	2
MDC_CONC_CHLOR_GEN	29032	2				Only this was defined in 10101
MDC_CONC_CHLORIDE_GEN	29032	2				This is only in RTMMS
MDC_EVT_DISTURB	24	3				This is defined in 10101 in annex A
MDC_EVT_QUALITY	24	3				This is defined in 10101 only in annex B
MDC_EVT_SIG_QUALITY	24	3				This is defined in 10101 only in annex B
MDC_EVT_OBSTRUC	80	3				This is defined in 10101 only in annex B
MDC_EVT_OCCL	80	3				This is defined in 10101 only in annex B
MDC_EVT_SYNCH_ERR_RCV_OVRUN	182	3				This is defined in 10101 in annex A
MDC_EVT_SYNCH_ERR	182	3				This is defined in 10101 in annex A
MDC_EVT_VENT_OBSTRUC	508	3				This is defined in 10101 only in annex B
MDC_EVT_VENT_ENDOTRACH_TUBE_OBSTRUC	508	3				This is defined in 10101 in annex A
MDC_DIM_PARTS_PER_10_TO_3	576	4
MDC_DIM_PARTS_PER_THOUSAND	576	4
MDC_DIM_PARTS_PER_10_TO_6	608	4
MDC_DIM_PARTS_PER_MILLION	608	4

[Malcolm Clarke]

Dear All

The following 3 terms have (potentially) the same RefId but different
term codes. Note that these are case sensitive.

The 3rd is not currently in 10101R as it was defined in 10102 but has
not been included in RTMMS.

I should be grateful for comments.

Regards

Malcolm


Duration | ECG, QTc | Heart |CVS
MDC_ECG_TIME_PD_QTc
QTc
Duration of the interval between the QRS onset and T wave offset,
related to heart rate 60 beats per minute of ECG (global), Bazett formula
2 16164

Duration | ECG, QTc, NOS | Heart | CVS
MDC_ECG_TIME_PD_QTC
Duration of the interval between the QRS onset and T wave offset,
corrected for heart rate using an
unspecified correction
2 15876

Duration | ECG {lead}, QTc | Heart | CVS
MDC_ECG_TIME_PD_QTc
QTc Time period, QT (correction specified as a separate attribute or
unknown)
2 33792

[Malcolm Clarke]

Dear All

Apologies, here is a further synonym. MDC_ECG_BEAT_COUNT was introduced in 10102.

Regards

Malcolm

Count | Rhythm, Beat | ECG, Heart | CVS			Beat count	MDC_ECG_CARD_BEAT_CNT	2::16769
Count | Rhythm, Beat | ECG, Heart | CVS			Beat count	MDC_ECG_BEAT_COUNT	2::16032

[Malcolm Clarke]

Dear All

Apologies for more synonyms. We have 3 synonyms for the following term, different in both RefId and code

Malcolm

Duration | ECG, PQSegment | Heart | CVS	P-Q segment	PQseg	Duration of the interval between P offset and QRS onset of ECG (global) (synonymous to PR interval - American)	MDC_ECG_TIME_PD_PQ_SEG	2::16148
Duration | ECG, PR | Heart | CVS	P-R duration	PR	Duration of the interval between P offset and QRS onset of ECG (global) (synonymous to PQseg interval)	MDC_ECG_TIME_PD_PR_GL	2::16148
Duration | ECG, PR | Heart | CVS	P-R interval	PRint	Duration of the interval between P onset and QRS onset of ECG R-wave (global)	MDC_ECG_TIME_PD_PR(_INT)	2::15872

[Malcolm Clarke]

Dear Michael

Partition 10, which comes from 10102, is not included in 10101R. However it seems I should at least list the #defines in order that conflicts can be picked up.

There will be further conflict between _BEAT_RATE and _HEART_RATE.

However I also note a direct code conflict within 10102, so who knows

MDC_ECG_WAVP_DEFIB   10   8192

MDC_ECG_BEAT                  10   8192

Regards

Malcolm

On 30/11/2018 16:33, Michael Faughn wrote:

There is also MDC_ECG_BEAT_COUNT 10::16393.  I know it is in a different partition but it still seems suboptimal.

Michael Faughn
Software Developer
Prometheus Computing, LLC
m.fa...@prometheuscomputing.com
W: (828) 293-5927
F:  (828) 293-5927

[Paul Schluter]

Malcolm and colleagues,

Regarding the three terms you’ve identified:

Duration | ECG, QTc | Heart |CVS

MDC_ECG_TIME_PD_QTc

QTc

Duration of the interval between the QRS onset and T wave offset, related to heart rate 60 beats per minute of ECG (global), Bazett formula

2 16164

The term above was originally defined in 10101:2004 as a ‘global’ ECG parameter and thus uses the [MMM] discriminator group.  As noted in my comment on row #59 of my extended D3r7 comments I sent to you recently, we should define MDC_ECG_TIME_PD_QTc_GL as the preferred REFID for this [MMM] term at 2::16164 so that the ‘global’ and ‘per-lead’ terms can be unambiguously distinguished solely by their REFID, without referring to their numeric codes.]

Duration | ECG, QTc, NOS | Heart | CVS

MDC_ECG_TIME_PD_QTC

Duration of the interval between the QRS onset and T wave offset, corrected for heart rate using an unspecified correction

2 15876

As noted on row #46 in my extended D3r7 comments, we should deprecate MDC_ECG_TIME_PD_QTC[MMM]2::15876 and use the preferred MDC_ECG_TIME_PD_QTC_GL[MMM]2::15876.

Duration | ECG {lead}, QTc | Heart | CVS

MDC_ECG_TIME_PD_QTc

QTc Time period, QT (correction specified as a separate attribute or unknown)
2 33792

The 'per-lead’ ECG term above was originally defined in 10102:2012 aECG and uses the [LEAD] discriminator group, as noted by my comment on row #42 of my extended D3r7 comments.

At the time the per-lead term was defined in aECG, both Jan and I continued with the concept of relying on the numeric code (range) to determine whether the [MMM] or [LEAD] version was used, consistent with existing practice used for several other terms in the IEEE 11073-10101:2004, rather than defining a new _GL REFID for the earlier [MMM] term at 2::16164.  [Today, we should define MDC_ECG_TIME_PD_QTc_GL as the preferred REFID for the [MMM] code at 2::16164 so that the ‘global’ and ‘per-lead’ terms can be unambiguously distinguished solely by their REFID, without referring to their numeric codes, as noted in my comment on row #59 of my extended D3r7 comments.]

The consistent theme is to apply the _GL suffix to all ‘global’ ECG REFIDs that have an identical ‘per-lead’ base REFID - there are about a half-dozen of these, as noted in my D3r7 comments.  Again, this would allow the ‘global’ and ‘per-lead’ ECG terms can be unambiguously distinguished solely by their REFID, a very useful and desirable property, especially with regards the containment modeling and other tooling that is being developed today.

Best regards,

Paul Schluter

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

[Malcolm Clarke]

Dear All

I forgot to add

MDC_ECG_TIME_PD_QTC_BAZETT    2::15880

which is a further synonym.

MDC_ECG_TIME_PD_QTC 2::15876 should not be deprecated, as this is to be used for uncorrected.

Malcolm

[Malcolm Clarke]

Dear Paul

In the comments to 10101R you have added. You will see in the notes I have started to add that 10102 has not only created RefId synonyms, but term code synonyms of the same RefId. It is hard to understand the intention of the confusion and errors that this is likely to produce.

It is perhaps one reason why we should accept no synonyms, and then this perplexing situation would have been avoided.

Note that the new codes of 10102 have not been entered into RTMMS and thus currently do not appear in 10101R.

I can add the new codes of 10102 to a table of deprecated codes with explanation with agreement.

I am in the process of adding all 10102 scada terms to 10101R in order to undertake rigorous check.

Regards

Malcolm

Comment	Proposed Change	Note
MDC_ECG_TIME_PD_P[MMM]2::16184 defined in -10102 aECG has been deprecated by the REFID-synonym MDC_ECG_TIME_PD_P_GL[MMM]2::16184 to avoid confusion with the corresponding 'per-lead' REFID; please note this in 10101R.	List MDC_ECG_TIME_PD_P[MMM]2::16184 as a deprecated REFID-synonym for MDC_ECG_TIME_PD_P_GL[MMM]2::16184.	MDC_ECG_TIME_PD_P_GL (16184) and MDC_ECG_TIME_PD_P (6656) are already defined in 10101:2005 and therefore defined in 10101R. It is unclear why 10102 defines a new RefId MDC_ECG_TIME_PD_P with code of 16184. MDC_ECG_TIME_PD_P (16184) is not in RTMMS.
MDC_ECG_TIME_PD_PP[MMM]2::16140 defined in -10102 aECG has been deprecated by the REFID-synonym MDC_ECG_TIME_PD_PP_GL[MMM]2::16140 to avoid confusion with the corresponding 'per-lead' REFID; please note this in 10101R.	List MDC_ECG_TIME_PD_PP[MMM]2::16140 as a deprecated REFID-synonym for MDC_ECG_TIME_PD_PP_GL[MMM]2::16140.	MDC_ECG_TIME_PD_PP_GL (16140) is already defined in 10101:2005 and therefore defined in 10101R. It is unclear why 10102 defines a new RefId MDC_ECG_TIME_PD_PP (global) with code of 16140 and defines the same RefId MDC_ECG_TIME_PD_PP as 32768 for lead.
The 'per-lead' term MDC_ECG_TIME_PD_PR[LEAD]2::7168 defined in -10101:2004 clearly specifies the Poffset to QRSonset in a particular <lead> (no issue here; let's use this as the baseline for the following discussion). Let's also accept MDC_ECG_TIME_PD_PR_GL[MMM]2::16148 as the 'global' version of this term; the REFID was reserved as a #undefined term in -10101:2004 Annex B and now it has a definition that is consistent with the 'per-lead' above, and more specifically, it conveys the Poffset to QRSonset.  So we're good here, too. But we're missing MDC_ECG_TIME_PD_PR[MMM]2::15872 that was defined in -10102 that represents the 'global' Ponset to QRSonset, i.e. the PR interval.  In order to avoid confusion with the MDC_ECG_TIME_PD_PR_GL[MMM]2::16148 we should define a new (and preferred) REFID for the -10102 term, name MDC_ECG_TIME_PD_PR_INT[MMM]2::15872.	List MDC_ECG_TIME_PD_PR_INT[MMM]2::15872 in 10101R in Annexes A, B and C as a valid and current term for base code 2::15872 (e.g. in Annex C) and list MDC_ECG_TIME_PD_PR[MMM]2::15872 as a deprecated REFID-synonym. [We could consider appending _GL to the preferred REFID proposed above, namely MDC_ECG_TIME_PD_PR_INT[MMM]2::15872 so that there is no uncertainly regarding whether it is a 'per-lead' term or not.  [I haven't checked for how many other terms would benefit from adding _GL and there is always the backwards compatibility issue to consider with the FDA-inspired HL7 V3 aECG and DICOM.]	MDC_ECG_TIME_PD_PR _GL (16148) and MDC_ECG_TIME_PD_PR (7168) are already defined in 10101:2005 and therefore defined in 10101R. It is unclear why 10102 defines a new RefId MDC_ECG_TIME_PD_PR (global) with code of 16140 and defines the same RefId MDC_ECG_TIME_PD_PP as 32768 for lead.
List MDC_ECG_TIME_PD_QRS[MMM]2::16156 as a deprecated REFID from -10102 aECG.	List MDC_ECG_TIME_PD_QRS[MMM]2::16156 as a deprecated REFID-synonym for MDC_ECG_TIME_PD_QRS_GL[MMM]2::16156.
List MDC_ECG_TIME_PD_QT[MMM]2::16160 as a deprecated REFID from -10102 aECG.	List MDC_ECG_TIME_PD_QT[MMM]2::16160 as a deprecated REFID-synonym for MDC_ECG_TIME_PD_QT_GL[MMM]2::16160.
List MDC_ECG_TIME_PD_QTC[MMM]2::15876 as a deprecated REFID from -10102 aECG.	List MDC_ECG_TIME_PD_QTC[MMM]2::15876 as a deprecated REFID-synonym for MDC_ECG_TIME_PD_QTC_GL[MMM]2::15876.
List MDC_ECG_TIME_PD_RR[MMM]2::16168 as a deprecated REFID from -10102 aECG.	List MDC_ECG_TIME_PD_RR[MMM]2::16168 as a deprecated REFID-synonym for MDC_ECG_TIME_PD_RR_GL[MMM]2::16168.
Add MDC_ECG_TIME_PD_PQ_GL[MMM]2::16144 as the preferred REFID for MDC_ECG_TIME_PD_PQ[MMM]2::16144, the latter having the same REFID as the 'per-lead' measurement.	Add MDC_ECG_TIME_PD_PQ_GL[MMM]2::16144 as the preferred REFID for MDC_ECG_TIME_PD_PQ[MMM]2::16144, the latter having the same REFID as the 'per-lead' measurement.
Add MDC_ECG_TIME_PD_QTc_GL[MMM]2::16164 as the preferred REFID for MDC_ECG_TIME_PD_QTc[MMM]2::16164; the latter having the same REFID as the 'per-lead' measurement.	Add MDC_ECG_TIME_PD_QTc_GL[MMM]2::16164 as the preferred REFID for MDC_ECG_TIME_PD_QTc[MMM]2::16164; the latter having the same REFID as the 'per-lead' measurement.
Add MDC_ECG_TIME_PD_QTU_GL[MMM]2::16004 as the preferred REFID for  MDC_ECG_TIME_PD_QTU[MMM]2::16004, the latter having the same REFID as the 'per-lead' measurement.	Add MDC_ECG_TIME_PD_QTU_GL[MMM]2::16004 as the preferred REFID for  MDC_ECG_TIME_PD_QTU[MMM]2::16004, the latter having the same REFID as the 'per-lead' measurement.
Consider adding MDC_ECG_TIME_PD_PQ_SEG_GL[MMM]2::16148 as the preferred REFID for MDC_ECG_TIME_PD_PQ_SEG[MMM]2::16148, the latter having the same REFID as the 'per-lead' measurement.  [THIS REQUIRES FURTHER INPUT FROM PHILIPS since this is related to 2::15872, email was sent to Kai and JohnR on October 23, 2018 at 1:06 PM CDT.]	DISCUSS, since 2::16148 and 2::15872 were also declared equivalent.  Requested input from Philips,	MDC_ECG_TIME_PD_PQ_SEQ (16148) is already defined in 10101:2005 and therefore defined in 10101R. It is unclear why 10102 defines the same RefId MDC_ECG_TIME_PD_PP as 33536 for lead.

[Paul Schluter]

Michael and colleagues,

Michael, I totally agree with you - you’ve identified the three principal types of “synonym terms” that can and do occur in the IEEE 11073 nomenclature, and they can and should be treated differently.  This would be an excellent and timely topic to discuss during our next RTM tcon to be held this Wednesday, December 5th, at 11:00 AM CST.

Expanding on your three classifications of IEEE 11073 “synonyms", we have:

1.  “Different REFIDs same code”  aka “REFID-synonyms”   [Michael:  multiple RefIDs map to a single context-free term code]

Example:  MDC_ECG_CARD_BEAT_RATE or MDC_ECG_HEART_RATE having same numeric code 2::16770. 

These are very easy to identify, manage, display and publish since they have the same numeric identifier.  Different REFIDs having the same numeric identifier is an unambiguous declaration of their equivalency by the IEEE P11073-10101 and other working groups, and today, shipping products and their documentation may use either REFID.  This is something that will have to be documented and supported by the IEEE 11073 nomenclature standards and supported by the NIST RTMMS and NIST and other test tools for the foreseeable future.

2.  “Same REFID multiple codes”  [Michael:  multiple terms with the same RefID]  

Example:  MDC_ECG_TIME_PD_P_GL [MMM] 2::16184 is preferred over MDC_ECG_TIME_PD_P [MMM] 2::16184 for the ‘global’ (over all leads) measurement of P-wave duration.

This is limited to a relatively small number of ‘global’ and ‘per-lead’ ECG terms that were defined in IEEE 11073-10101:2004 and 11073-10102:2012 aECG.  When most of the terms in aECG were defined back in 2005 (to support the HL7 V3 IG aECG—HL7 Version 3 Implementation Guide: aECG, Release 1, March 2005, supported by practically every major vendor of diagnostic 12-lead ECG systems to report clinical trial results to the FDA and other institutions) the decision by Jan, myself and others was continue relying on the numeric code for terms that had the same base REFID to distinguish between ‘global’ and ‘per-lead’ ECG terms.  [In retrospect, we should have required the addition of the _GL suffix on any ‘global’ term that had the same base REFID as a ‘per-lead’ term back at that time, and this is the reason why I have submitted several 10101R-D3r7 comments recommending this action for specific terms.]

There are very small number of “same REFID multiple codes” terms and they can be readily identified.  Addressing this now in 10101R will facilitate development of containment modeling and other tools that would benefit from the simplicity of REFID identifiers that are unambiguously be associated with a specific numeric code and discriminator group (i.e. MMM vs LEAD for ‘global’ vs ‘per-lead’ ECG terms).  [DICOM and HL7 V3 IG aECG Implementation Guide both use the aECG nomenclature resolve this issue by defining ‘global’ and ‘per-lead’ context groups (sets of terms) and only require REFID uniqueness within each group; in the case of DICOM, ‘Context Groups’ CID 3689 and CID 3687 are used for ‘global’ and ‘per-lead’ ECG terms, respectively.] 

3.  “Different REFIDs different codes”  [Michael:  different RefIDs and term codes which mean the same thing]

Example:  MDC_TEMP_AXILLA [MMM] 2::57380  and  MDC_TEMP_AXIL [MMM] 2::57424

From time to time the same semantic concept is proposed by two different groups and cannot be easily identified by automatic means since the REFIDs and codes are different and were missed by reviewers and editors.  [In the example above, one term was proposed by PoCD and the other by PHD.]  Other types of “different REFIDs different codes” can arise for many other reasons, and how these are evaluated as “like kind” synonyms can be a complex topic and can be dependent on the clinical use case(s) as well.

So, unless anyone objects, we will take this topic up during our RTM tcon this Wednesday.  This topic is also tightly coupled with the issue of term deprecation, since “REFID-synonyms” often arise when solving an issue that may require that an older term be “deprecated" and ultimately “withdrawn” from use.

Best regards,

Paul Schluter

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

On Dec 3, 2018, at 11:15 AM, Michael Faughn <m.fa...@prometheuscomputing.com> wrote:

I'm sure this has been discussed before but the lumping together of all of the synonym-like cases into one bucket and calling them simply 'synonyms' is perhaps not maximally helpful.  While it isn't ideal, I don't see the case of having multiple RefIDs map to a single context-free term code as being nearly as problematic as having multiple terms with the same RefID and different term codes or having two terms that have both different RefIDs and term codes which mean the same thing.  Is there some language that we could use to maintain a distinction between the different cases?

-Michael

[Malcolm Clarke]

Dear Paul

In 10101R I have provided 3 separate ways of listing codes

a) Grouped by similarity in systemmatic name

b) Term code order

c) Alphabetic RefId order.

This provides an excellent opportunity to determine where synonyms occur and I have been using this technique for the preparation of 10101R to identify the synonyms that exist. Unfortunately it is not perfect and does not identify all.

I have resolved some synonyms but others remain. I have sent out a list for people to consider how to prioritise.

I am currently dealing with the list of ECG_TIME_PD_*.

Regards

Malcolm

[Malcolm Clarke]

Dear Paul

I am concerned that you assume that all applications and users do and will always treat the term code as unique, and therefore we may freely have as many RefId synonyms as we choose (case 1). This may not be and will not remain the case. We therefore ought to treat all occurrences of synonyms in the same way and remove them.

Allowing synonyms is a very bad precedent. On what basis do we allow some RefId synonyms, but not others. If the term code is unique, why not abandon the notion of the unique RefId and make it a free text string for manufacturers to use as they choose?

Having synonyms will and has led to confusion and errors and we should make every effort to avoid in the future and remove existing.

We also need to protect our reputation. We say we make great effort to collect terms, from which we select one to represent the concept - but then immediately people find synonyms. They then ask the question which one should they use, so why not then select that as the single term? Synonyms make no sense.

Although we can accept that terminology changes, and a RefId may be substituted with a replacement term, the old term should be phased out. However it is a mystery why synonyms are being added to the nomenclature, when perfectly good terms exist.

Regards

Malcolm

On 03/12/2018 22:03, Paul Schluter wrote:

[Paul Schluter]

Greetings,

Please plan to join our RTM tcon tomorrow, Wednesday, December 5th, starting at 11:30 AM CST.  We are delaying the start of the tcon by ONE-HALF HOUR for those of you who would prefer to watch or observe the The State Funeral for George H. W. Bush at the Washington National Cathedral from 11:00 AM to 12:30 PM EST.

The first ten to fifteen minutes, starting at 11:30 AM CST, will be devoted to ventilator topics with Dr. Norman Jones to see if further alignment with ISO 19223 is possible.

If Malcolm is available, we will likely follow that with a discussion regarding REFID-synonyms (and we can go past 12:00 N CST if we need to).  If additional time is required, we can continue the REFID-synonym discussion during the DPI tcon on Thursday, starting at 1:00 PM CST, graciously hosted by Michael Faughn.

PLEASE REVIEW Malcolm’s “Synonyms in 10101R” email thread regarding REFID-synonym preferences, starting with the first email sent on November 29, 2018 at 12:59 PM CDT and mail your replies to Malcolm so that he can collate your responses.

Thanks and regards,

Paul Schluter

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

[Malcolm Clarke]

Dear Paul

The following are the current terms that include ECG time periods and points and that might be considered for global and lead forms. Some are already defined as _GL for global and have MMM (0), and the per lead without _GL has LEAD (0). We might discuss which others should have both forms to provide consistent approach.

We have a bewildering confusion of MDC_ECG_TIME_PD_QT forms.

Regards

Malcolm

MDC_ECG_TIME_END_P	LEAD (0)	2::5888
MDC_ECG_TIME_END_QRS	LEAD (0)	2::6144
MDC_ECG_TIME_END_T	LEAD (0)	2::6400
MDC_ECG_TIME_PD_P	LEAD (0)	2::6656
MDC_ECG_TIME_PD_P_GL	MMM (0)	2::16184
MDC_ECG_TIME_PD_P1	LEAD (0)	2::4608
MDC_ECG_TIME_PD_P2	LEAD (0)	2::4864
MDC_ECG_TIME_PD_P3	LEAD (0)	2::5120
MDC_ECG_TIME_PD_PP	LEAD (0)	2::32768
MDC_ECG_TIME_PD_PP_GL	MMM (0)	2::16140
MDC_ECG_TIME_PD_PQ	LEAD (0)	2::33280
MDC_ECG_TIME_PD_PQ_GL	MMM (0)	2::16144
MDC_ECG_TIME_PD_PQ_SEG	LEAD (0)	2::16148
MDC_ECG_TIME_PD_PR	LEAD (0)	2::7168
MDC_ECG_TIME_PD_PR_GL	MMM (0)	2::16148
MDC_ECG_TIME_PD_Q	LEAD (0)	2::7680
MDC_ECG_TIME_PD_QRS	LEAD (0)	2::7936
MDC_ECG_TIME_PD_QRS_GL	MMM (0)	2::16156
MDC_ECG_TIME_PD_QT	LEAD (0)	2::8192
MDC_ECG_TIME_PD_QT_CORR	LEAD (0)	2::8448
MDC_ECG_TIME_PD_QT_GL	MMM (0)	2::16160
MDC_ECG_TIME_PD_QTc	LEAD (0)	2::33792
MDC_ECG_TIME_PD_QTc_GL	MMM (0)	2::16164
MDC_ECG_TIME_PD_QTC_BAZETT	MMM (0)	2::15880
MDC_ECG_TIME_PD_QTC_FRAMINGHAM	MMM (0)	2::15884
MDC_ECG_TIME_PD_QTC_FREDERICA	MMM (0)	2::15892
MDC_ECG_TIME_PD_QTC_HODGES	MMM (0)	2::15888
MDC_ECG_TIME_PD_QTC_USER	MMM (0)	2::15896
MDC_ECG_TIME_PD_QTcB	LEAD (0)	2::34048
MDC_ECG_TIME_PD_QTcF	LEAD (0)	2::34304
MDC_ECG_TIME_PD_QTU	LEAD (0)	2::34560
MDC_ECG_TIME_PD_QTU_GL	MMM (0)	2::16004
MDC_ECG_TIME_PD_R_1	LEAD (0)	2::11264
MDC_ECG_TIME_PD_R_2	LEAD (0)	2::11520
MDC_ECG_TIME_PD_R_3	LEAD (0)	2::11776
MDC_ECG_TIME_PD_RR	LEAD (0)	2::33024
MDC_ECG_TIME_PD_RR_GL	MMM (0)	2::16168
MDC_ECG_TIME_PD_S_1	LEAD (0)	2::12032
MDC_ECG_TIME_PD_S_2	LEAD (0)	2::12288
MDC_ECG_TIME_PD_S_3	LEAD (0)	2::12544
MDC_ECG_TIME_PD_VENT_ACTIV	LEAD (0)	2::11008
MDC_ECG_TIME_ST_Jxx	MMM (0)	2::16304
MDC_ECG_TIME_START_P	LEAD (0)	2::9472
MDC_ECG_TIME_START_QRS	LEAD (0)	2::9728
MDC_ECG_TIME_START_T	LEAD (0)	2::9984

[Malcolm Clarke]

Dear Michael

My problem is simple, and therefore I am seeking resolution.

Although my software can be designed to manage synonyms (duplicates of codes), I am required to send a single code (one term code with one RefId) when I send an observation in a message. My problem is how do I chose which code to send? It is not practical to say codes are equal as my software must chose a single code from the alternatives. Do we therefore offer suggestions on which code to select? People are naturally asking this question to assist them.

However once we define a preferred term, the other terms will, in time, fall into disuse. At some stage we deprecate.

Regards

Malcolm

On 05/12/2018 03:55, Michael Faughn wrote:

Malcolm and others,

In what cases would applications or users not be treating the term code as unique?  It seems to me that they should be doing so.

Here is my understanding of the situation: 

The most important information about a term is neither the term code nor is it the RefID but instead it is the concept that the term describes.  This concept is expressed in the text found in the description/definition column of the published tables.  Ultimately, it is those concepts that should not be duplicated.  The term code exists as a key with which to reference a concept.  It is certainly understandable that implementations become simpler if there is a 1:1 correspondence between keys and concepts.  

It seems that many would also like to use RefIDs as keys to concepts.  Maintaining a system with multiple sets of keys represents increased complexity and therefore increased opportunity for error.  This is compounded  by the expectation that there is correspondence between the key sets (i.e. that a key in one set can serve as a reference to a key in another key set in addition to being a key into the set of concepts).

From an information standpoint, there shouldn't be any reason why any concept could not be referenced by multiple keys (from any number of key sets).  One reason why such a situation ought to be avoided is that, again, it becomes harder to implement a system that manages all of these relationships.  Essentially, you could have one concept, e.g., the concept with the descriptive text "Pressure of the blood at the systolic phase", that was associated to millions of term codes and millions of RefIDs.  As long as implemented systems could dereference the concepts when it was necessary to do so then there would be no problem.  Of course this is ridiculous from a practical standpoint.  The system with the least amount of complexity is the easiest to implement.     

The question then is one of how much complexity should be allowed in the 11073 terminology.  Maintaining a 1:1 correspondence between term codes and concepts minimizes complexity and seems like a good idea which everyone agrees on.  My understanding is that there are also use cases where RefIDs are being used as keys into the terminology (instead of using term codes) and the standard endeavors to support this use case as well.  It also seems that 11073 aims to support using the RefID as a proxy for the term code as well as using a term code as a proxy for RefID as well.  There appears to be contention over a few more cases:

1. A term (i.e. concept) has multiple RefIDs ("RefID synonyms") -- I don't understand why this should not be supported other than because doing so increases the complexity just a bit more.  There is no existential reason why we can't decide that while a term will be allowed to have only one term code, that it is permissible for it to have multiple RefIDs.
2. A term (i.e. concept) has multiple term codes ("term code synonyms") -- There are good reasons to desire a 1:1 correspondence between codes and terms.  Everyone seems to agree that this is how things ought to be and achieving it probably falls into the "low hanging fruit" category.
   
3. Multiple terms have the same term code and/or RefID but have different meanings -- This isn't a synonym.  If we want to stick with the idea that the keys are words, then these are homographic homonyms.  This is a broken key problem.  They should definitely be fixed.
4. The same concept is expressed by multiple entries in the collection of terms.  This isn't a really a synonym either.  This is a duplicate.  While this could theoretically be managed, it seems clear that desired situation is one where each concept is expressed by one and only one entry in the collection of terms.

Of the cases above, I think I am really only hearing disparity over the first of them.  Am I wrong about that? Is anyone proposing that the second, third, or fourth cases should be supported?

For the first case there is an argument that the benefits from allowing RefID synonyms outweigh the cost incurred by the increase in complexity.  Personally, I am swayed by this argument.  Perhaps there are flaws in the foundation of my understanding or perhaps I don't understand why RefID synonyms are likely to be especially dangerous.  I look forward to this week's teleconference sessions.

Regards,
Michael

 

Michael Faughn

Software Developer
Prometheus Computing, LLC
m.fa...@prometheuscomputing.com
W: (828) 293-5927
F:  (828) 293-5927

[Malcolm Clarke]

Dear Michael

I can only describe my experience of implementing a gateway following the Continua guidelines, which were based on IHE PCD-01.

The gateway accepts connections from PHD devices, which send their observations in the form of IEEE 11073 binary messages. These only contain the binary term codes. Our gateway was resource constrained, and therefore we only mapped the binary code to a numeric code in the equivalent PCD-01 message, as Continua only require the numeric term code to be sent, and the RefId is optional. This removes the need for a dictionary in the gateway and any need to update for new devices. An excellent feature for generic gateways in the field.

I understand that IHE PCD-01 has the same requirement that the RefId is optional. I also understand that devices on FHIR will follow the same requirements.

This would imply that current uses of IEEE nomenclature only require the numeric term code as mandatory, and the RefId is optional. However do not know if this will remain the case.

If the messaging is intended for machine to machine, then the numeric code is ideal, it is short and easily manipulated. The only purpose I can find for the RefId would be for diagnostics and inspecting messages. It is much quicker for the human to read the RefId than doing a look up in a table for the code.

However we enter a circular argument.

If the RefId is optional and carries no information (it is all in the code, which we shall assume is unique), then there are no requirements on how many RefId synonyms we might allow, we can simply ignore the RefId on reception, and put as many as we wish in a big RefId synonym pot.

But, we tell the world we create a "harmonised" Rosetta, which has a single code, which we assume means both a single term code and a single RefId. And there is the inevitable question - which one do I use? So if you specify a preferred RefId, why not make this the only RefId?

10101-2004 had almost no synonyms, and the terms were largely adequate. I can understand some terms are replaced by a more modern term, and thus the old should be deprecated. However it is not clear why we are generating equal synonyms.

Regards

Malcolm

On 05/12/2018 17:14, Michael Faughn wrote:

Malcolm, 

Are you required to send both a term code and a RefID or just a term code?  If just a term code then what does it matter how many RefIDs may also be used as keys to the reference a term?  If you are sending both a term code and a RefID, then, well, why would you do that?

-Michael

Michael Faughn
Software Developer
Prometheus Computing, LLC
m.fa...@prometheuscomputing.com
W: (828) 293-5927
F:  (828) 293-5927

[Paul Schluter]

Malcolm,

Only four new “REFID-synonyms” need to be defined with a _GL suffix to clearly distinguish existing ‘global’ ECG terms from the existing ‘per-lead’ terms that have the same base REFID.

They are listed below along with the corresponding Excel row number in my extended 10101R-D3r7 comments. 

   Add MDC_ECG_TIME_PD_PQ_GL[MMM]2::16144 (#58)

   Add MDC_ECG_TIME_PD_QTc_GL[MMM]2::16164 (#59)

   Add MDC_ECG_TIME_PD_QTU_GL[MMM]2::16004 (#60)

   Consider adding MDC_ECG_TIME_PD_PQ_SEG_GL[MMM]2::16148  (#61, further discussion with Philips required)

We should not add the _GL suffix to other ‘global’ terms that do not have a conflict with a corresponding ‘per-lead’ term.  If someone defines a new ‘per-lead’ ECG term (and the 256 code-points that it would consume) then it would be easily to define the corresponding ‘global’ REFID with a _GL suffix for the corresponding ‘global’ term.  [Since 2006, after most of the new term development work for 10102 aECG was completed, there have been no further requests for additional ‘per-lead’ terms.]

I am sending you the chart <listPerLeadandGlobalECG.x1c.2018-10-21T13.html> that served as an initial worksheet for my exploration of this topic.  This list of ‘per-lead’ ECG terms going down the leftmost column [LEAD] per-lead terms contains all the ‘per-lead’ terms defined in -10101:2004 and -10102-2012 aECG, with the following columns listed to the right:

Matching [MMM] terms :  ‘global’ terms with same base REFID as ‘per-lead’ term - every REFID listed in this column conflicts to the same-named REFID to its left, and all of these will have be deprecated as REFIDs for ‘global’ terms and using existing _GL REFIDs and defining the four new _GL REFIDs listed above as the preferred REFID-synonym.

Matching _GL [MMM] terms :  ‘global’ terms with same base REFID as ‘per-lead’ term that already have a _GL suffix.  This lists the existing ‘global’ _GL REFIDs to which we need to add the four new _GL REFIDs mentioned above.

Other [MMM] terms with same code :  other terms having the same numeric code as either one or both of the ‘global’ terms in the same row.  We can discuss these once we begin our walk-through of all the 10101R-D3r7 ballot comments that have been submitted.

Regarding the ECG QT terms, all of the ‘global’ QT and QTc terms are listed and defined on a single page (52) in ISO/IEEE 11073-10102-2012.  The first term, MDC_ECG_TIME_PD_QTc, was originally defined in 10101:2004.  The other six term-rows

   MDC_ECG_TIME_PD_QTC,

   MDC_ECG_TIME_PD_QTC_BAZETT,

   MDC_ECG_TIME_PD_QTC_FRAMINGHAM,

   MDC_ECG_TIME_PD_QTC_HODGES,

   MDC_ECG_TIME_PD_QTC_FREDERICA  and

   MDC_ECG_TIME_PD_QTC_USER

were requested by the FDA, the user and research communities and 12-lead diagnostic, stress and Holter ECG vendors to have explicit terms the most widely-used QT-correction algorithms (and over 30+ less frequently used corrections using MDC_ECG_TIME_PD_QTC_USER).

Best regards,

Paul Schluter

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

<<listPerLeadandGlobalECG.x1c.2018-10-21T13.html>>

[Malcolm Clarke]

Dear Paul

In your comments you made requests for several _GL suffix, namely:

MDC_ECG_TIME_PD_P[MMM]2::16184

MDC_ECG_TIME_PD_PP[MMM]2::16140

MDC_ECG_TIME_PD_PR_INT[MMM]2::15872

MDC_ECG_TIME_PD_QRS[MMM]2::16156

MDC_ECG_TIME_PD_QT[MMM]2::16160

MDC_ECG_TIME_PD_QTC[MMM]2::15876

MDC_ECG_TIME_PD_RR[MMM]2::16168

MDC_ECG_TIME_PD_PQ[MMM]2::16144

MDC_ECG_TIME_PD_QTc[MMM]2::16164

MDC_ECG_TIME_PD_QTU[MMM]2::16004

MDC_ECG_TIME_PD_PQ_SEG[MMM]2::16148

These have been made and therefore appear in the list I gave.

I have asked to consider whether we should have

MDC_ECG_TIME_PD_QTC[MMM]2::15876

MDC_ECG_TIME_PD_QTc[MMM]2::16164

As this means that the RefId is case sensitive, and is the only example. If this remains, there should be a statement in 10101R to the effect that RefId are case sensitive.

Also there are potential ECG term code synonyms to resolve. I would ask to consider 16144 and 15872 and whether QRS onset is the same as R-wave onset, and thus these are equal. 16148 refers P offset so is not a term code synonym.

Duration of the interval between P onset and QRS onset of ECG (global)	MDC_ECG_TIME_PD_PQ_GL	2::16144

Duration of the interval between P offset and QRS onset of ECG (global) (synonymous to PR interval - American)

MDC_ECG_TIME_PD_PQ_SEG_GL

2::16148

Duration of the interval between P offset and QRS onset of ECG (global) (synonymous to PQseg interval)

MDC_ECG_TIME_PD_PR_GL

2::16148

Duration of the interval between P onset and QRS onset of ECG R-wave (global)

MDC_ECG_TIME_PD_PR_INT_GL

2::15872

Regards

Malcolm

[Paul Schluter]

Malcolm and colleagues,

The two terms, MDC_ECG_TIME_PD_QTc[MMM]2::16164 and MDC_ECG_TIME_PD_QTC[MMM]2::15876 represent different concepts and should be retained.  The REFID match should be “case sensitive” since there are other case-sensitive terms (e.g. ECG lead designators) that also use lower-case characters.  Other standards such as UCUM offer a case-sensitive “c/s” format and that is what we use in the IHE PCD DEC messaging if UCUM is used, and it definitely improves the readability of the UCUM code-strings.  Other standards such as the International 10/20 (EEG) system for electrode site locations are case-sensitive.

I certainly would endorse a statement in 10101R indicating that the REFIDs are case sensitive and should be processed in a case-sensitive manner.

MDC_ECG_TIME_PD_QTc[MMM]2::16164

Definition:  Duration of the interval between the QRS onset and T wave offset, related to heart rate 60 beats per minute of ECG (global), Bazett formula.

This term and code was originally defined in ISO/IEEE 11073-10101:2004 and is typically used for the ‘global’ QTc.  Although most real-time patient monitoring algorithms use Bazett, not all do, so to claim that his is strictly Bazett is misleading, since this is the term practically everyone uses in the real-time patient monitoring domain.  We had an extensive discussion about this when IEEE P11073-10102R was launched back in 2002, and the FDA (with a particular focus on standardized reporting of clinical trial results that have a diagnostic ECG data component) and all the major diagnostic ECG vendors wanted a clearly labeled and defined term, and thus MDC_ECG_TIME_PD_QTC_BAZETT 2::15880 was defined (and with the reference to 60 bpm excluded).

MDC_ECG_TIME_PD_QTC[MMM]2::15876

Definition:  Duration of the interval between the QRS onset and T wave offset, corrected for heart rate using an unspecified correction

This was added to provide a ‘generic’ QTC using an unspecified correction.

All of the QTC terms are in active use by other protocols, such as the FDA-requested HL7 V3 IG for aECG, DICOM, and others, as well as IEEE 11073 and IHE PCD DEC.

We can discuss the last topic with Kai Hassing, John Rhoads and possibly others on a separate email thread or telephone call.  This is an example of where declaring a synonymous relationship in the definition of a term in the Description/Definition is an extremely poor practice, especially since it appears to include a regional geographic aspect (whereas human patients and their respective P, Q, R, S, T and U wave components and their respective onsets, offsets, segments and intervals are not).  Also, vendors do distinguish between the segment and interval timings relative to the Q-onset and R-onset relative to QRS-onset, but I will have to review my notes on this as well as cross-check against HL7 V3 IG aECG and DICOM.

Best regards,

Paul Schluter

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

[Malcolm Clarke]

Dear Paul

In the strict sense, "case sensitive" means that otherwise similar terms will differ in meaning if the case of letters in the term is different, thus "a" is different to "A".

To date, 10101 is NOT case sensitive, there are no two RefIds that are otherwise similar but have a different meaning because they have a difference in the case of letters. And whilst it may be nice to incorporate case in RefIds to match the familar form for a human reader (such as might have been used in ECG leads), case makes no difference to a receiving computer, and will more than likely capitalise for comparing, processing and storage.

This approach to managing strings is very common, as it allows for the differences that humans might use to enter a string, the computer does not care about case - for example Excel is case insensitive if the simple "=" operator is used so that "a"="A" is true. If we mandate 10101 to be case sensitive we may need to rewrite RTMMS.

MDC_ECG_TIME_PD_QTc[MMM]2::16164 and MDC_ECG_TIME_PD_QTC[MMM]2::15876 is the ONLY example of case sensitive terms out of 10000+ terms, and so I would recommend in the strongest possible terms that 10101 is NOT case sensitive. This implies we will need to deal with 1 term. The expedient is to deprecate MDC_ECG_TIME_PD_QTc[MMM]2::16164 and specify that MDC_ECG_TIME_PD_QTC_BAZETT[MMM]2::2 15880 is used to specify that BAZETT has been used. This also removes term code synonyms.

Alternatively countless applications may need to be rewritten.

Regards

Malcolm

[Paul Schluter]

Michael and Malcolm,

Before we get tied up into knots about case (in)sensitivity, we should step back a bit and simply state that the REFID text string published in the IEEE 11073 is the normative text, exactly as it appears as an octet string, which is fundamentally case sensitive.

I believe most implementations are already compatible with this approach.  For example, if you were to look up a term-row based on the Part::Code in the published standard, the REFID string would be exactly as it appears in the standard, and that is what we should expect when the REFID is transmitted ‘over-the-wire’.  If an application wishes to convert it to all upper case, it is free to do so, but only for purposes internal to that application.

To that end, I would be happy to agree to the statement that “All preferred IEEE 11073 REFIDs SHALL be unique to after conversion to a case-insensitive format, e.g. all capitals" and I am currently looking into the best REFID to replace the current MDC_ECG_TIME_PD_QTc[MMM]2::16164.  I will send this out later, but for now, Christmas preparation and gatherings beckon.

So, again, for message conformance testing, on-the-wire REFIDs SHALL be compared with the original REFID string in the published standard as well as its electronic equivalent published on the IEEE-SA download site.  This would be identical to the exact same string you would obtain by looking up the term-row by its Part::Code or CF_CODE10.  For applications and message validation that support earlier versions of the nomenclature(s), synonym pairs captured in a synonym table (similar to what I sent to several of you a few days ago) would also use exact string matches with the originally published but now deprecated REFIDs.  [The essential use-case here is a gateway and/or EMR that is aggregating observations from a mix of devices and systems use various revisions of the IEEE 11073 standard, and integrating the information in a seamless manner with little or no knowledge regarding the version of the IEEE 11073 nomenclature that is used by the sending devices, device middleware integration engines, and gateways.]

Furthermore, there are several other standards (the FDA-inspired HL7 V3 IG Annotated ECG, DICOM, ENV1064:2005,:2017 and SCP V3) that use the REFIDs originally published in ISO/IEEE 11073-10102-2012 aECG that contain a mix of upper- and lower-case characters.  The only term we need to address is MDC_ECG_TIME_PD_QTc[MMM]2::16164 to support applications that may wish to convert the REFID to a case-insensitive format for internal processing.

Best regards,

Paul Schluter

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

 

On Dec 8, 2018, at 1:27 PM, Michael Faughn <m.fa...@prometheuscomputing.com> wrote:

Introducing the necessity for parsing case sensitivity at this point would likely mean that every current implementor would have to write new code (or at least go back and ensure that they have suitable code in place).  The installed base of implementations (i.e. software) that parse RefIDs could, potentially, be broken by making RefIDs case sensitive.  It seems like something that should be avoided if at all possible.

 

Michael Faughn
Software Developer
Prometheus Computing, LLC
m.fa...@prometheuscomputing.com
W: (828) 293-5927
F:  (828) 293-5927

On Fri, Dec 7, 2018 at 7:48 AM Steven Dain <sd...@rogers.com> wrote:

Making refids case sensitive  will create coding errors which can cause patient safety problems.

QTC for QTc does not reduce comprehension.

10101 shall not be case sensitive

On Dec 7, 2018 at 05:02, <Malcolm Clarke> wrote:

Dear Paul

In the strict sense, "case sensitive" means that otherwise similar terms will differ in meaning if the case of letters in the term is different, thus "a" is different to "A".

To date, 10101 is NOT case sensitive, there are no two RefIds that are otherwise similar but have a different meaning because they have a difference in the case of letters. And whilst it may be nice to incorporate case in RefIds to match the familar form for a human reader (such as might have been used in ECG leads), case makes no difference to a receiving computer, and will more than likely capitalise for comparing, processing and storage.

This approach to managing strings is very common, as it allows for the differences that humans might use to enter a string, the computer does not care about case - for example Excel is case insensitive if the simple "=" operator is used so that "a"="A" is true. If we mandate 10101 to be case sensitive we may need to rewrite RTMMS.

MDC_ECG_TIME_PD_QTc[MMM]2::16164 and MDC_ECG_TIME_PD_QTC[MMM]2::15876 is the ONLY example of case sensitive terms out of 10000+ terms, and so I would recommend in the strongest possible terms that 10101 is NOT case sensitive. This implies we will need to deal with 1 term. The expedient is to deprecate MDC_ECG_TIME_PD_QTc[MMM]2::16164 and specify that MDC_ECG_TIME_PD_QTC_BAZETT[MMM]2::2 15880 is used to specify that BAZETT has been used. This also removes term code synonyms.

Alternatively countless applications may need to be rewritten.

Regards

Malcolm

On 06/12/2018 18:40, Paul Schluter wrote:

[Malcolm Clarke]

Dear Paul

We are trying to explain that many software applications will do a string comparison that is case-insensitive. I know that Excel works this way as I have had to go back and make changes and used "exact()" in place of "=". It is possible flavours of SQL may behave likewise. For this reason it is advisable to avoid case-sensitive terms.

Currently the only conflict is between MDC_ECG_TIME_PD_QTc[MMM]2::16164 and MDC_ECG_TIME_PD_QTC[MMM]2::15876, and so one of these terms should be amended. My suggestion is to deprecate MDC_ECG_TIME_PD_QTc[MMM]2::16164 (as it defines BAZETT is used) and specify that MDC_ECG_TIME_PD_QTC_BAZETT[MMM]2::2 15880 is used to specify that BAZETT has been used specifically. This also removes term code synonyms.

Regards

Malcolm

[Paul Schluter]

Michael and Malcolm,

As I stated in my email two days ago (included below), I agree with updating the REFID MDC_ECG_TIME_PD_QTc[MMM]2::16164 so that case-insensitive comparisons may be used for all preferred (and single) REFIDs that will be listed in -10101R.

There are two related REFIDs that would should consider updating as well, related to the original QTc definitions in ISO/IEEE 11073-10101:2004 that used inconsistent REFID naming for both ‘global’ and ‘per-lead’ QTc measurements.  [The REFID naming inconsistency was not fully addressed in -10102 due to a desire to maintain backwards compatibility with the REFIDs originally defined in 11073-10101:2004 with regards to QT and QTc.]   I will send this out later this morning after I review the changes with other standards that have adopted the ISO/IEEE 11073-10102-2012 aECG nomenclature (e.g. HL7 V3 IG Annotated ECG (aECG) used by the FDA for reporting clinical trial results, especially those related to QT measurement, and DICOM, as well as ENV1064:2005,:2017 and SCP V3).  I believe that my final proposal will work in all cases and scenarios, including the HL7 V3 IG Annotated ECG convention of only using the REFID for an observation identifier.]

It is essential that any changes like this are clearly documented in the default IEEE P11073-10101R but also on the NIST RTMMS in both human and machine-readable formats.  In the case of REFID synonyms (and other forms of IEEE 11073 synonyms), it is highly likely that all current and previous REFID-synonym relationships can be documented (e.g. preferred-REFID, deprecated REFIDs) to support automatic run-time conversion, including those required to support message conformance verification.  In the case of MDC_ECG_TIME_PD_QTc, a case-sensitive comparison will be required when performing synonym comparisons since the earlier version relied on the lower-case QTc, but as I stated earlier, a case-insensitive comparison will work for all preferred and single REFIDs in 10101R after we make the changes noted above.

Best regards,

Paul Schluter

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

On Dec 8, 2018, at 3:14 PM, Paul Schluter <pssch...@gmail.com> wrote:

Michael and Malcolm,

Before we get tied up into knots about case (in)sensitivity, we should step back a bit and simply state that the REFID text string published in the IEEE 11073 is the normative text, exactly as it appears as an octet string, which is fundamentally case sensitive.

I believe most implementations are already compatible with this approach.  For example, if you were to look up a term-row based on the Part::Code in the published standard, the REFID string would be exactly as it appears in the standard, and that is what we should expect when the REFID is transmitted ‘over-the-wire’.  If an application wishes to convert it to all upper case, it is free to do so, but only for purposes internal to that application.

To that end, I would be happy to agree to the statement that “All preferred IEEE 11073 REFIDs SHALL be unique to after conversion to a case-insensitive format, e.g. all capitals" and I am currently looking into the best REFID to replace the current MDC_ECG_TIME_PD_QTc[MMM]2::16164.  I will send this out later, but for now, Christmas preparation and gatherings beckon.

So, again, for message conformance testing, on-the-wire REFIDs SHALL be compared with the original REFID string in the published standard as well as its electronic equivalent published on the IEEE-SA download site.  This would be identical to the exact same string you would obtain by looking up the term-row by its Part::Code or CF_CODE10.  For applications and message validation that support earlier versions of the nomenclature(s), synonym pairs captured in a synonym table (similar to what I sent to several of you a few days ago) would also use exact string matches with the originally published but now deprecated REFIDs.  [The essential use-case here is a gateway and/or EMR that is aggregating observations from a mix of devices and systems use various revisions of the IEEE 11073 standard, and integrating the information in a seamless manner with little or no knowledge regarding the version of the IEEE 11073 nomenclature that is used by the sending devices, device middleware integration engines, and gateways.]

Furthermore, there are several other standards (the FDA-inspired HL7 V3 IG Annotated ECG, DICOM, ENV1064:2005,:2017 and SCP V3) that use the REFIDs originally published in ISO/IEEE 11073-10102-2012 aECG that contain a mix of upper- and lower-case characters.  The only term we need to address is MDC_ECG_TIME_PD_QTc[MMM]2::16164 to support applications that may wish to convert the REFID to a case-insensitive format for internal processing.

Best regards,

Paul Schluter

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

On Dec 10, 2018, at 7:59 AM, Michael Faughn <m.fa...@prometheuscomputing.com> wrote:

All,

I must concur with Malcolm on this because the software that I have built currently searches for RefIDs in a case-insensitive manner.  There are several layers at which case sensitivity must be understood and managed in any software implementation.  The Device Profile Editor that I have built serves as an example.  We currently use SQLite as the database behind it (but could switch to PostgreSQL or some other).  On top of that we use an ORM (Ruby Sequel).  And on top of that we have implemented out own logic for filtering collections (or terms and anything else) in the user interface.  All three of these layers implement a choice between filtering in a case-sensitive or case-insensitive manner.  In the first two (lower) layers, string filtering is case sensitive by default (add to this that, at least in SQLite, you can bake into the DB schema whether or not a given column should or should not be queried in a case-sensitive manner).  However, in the UI, it is not.  Why not?  Because we have a "one size fits all" string search in our GUI.  We didn't develop string searching specifically for RefIDs.  We developed it for the general case, which we believe is better served by a case insensitive search.  It is true that we can, on a case-by-case basis, make certain fields case-sensitive.  My expectation is that this might be the case for many software products, that they are built upon a stack of technologies and that you have to have a careful understanding of the stack and have to know when and if you must do some special configuration.  I now do know that I should be handling RefIDs in a case-sensitive manner.  The challenge will be to ensure that all implementers understand this and implement it correctly.

-Michael

Michael Faughn
Software Developer
Prometheus Computing, LLC
m.fa...@prometheuscomputing.com
W: (828) 293-5927
F:  (828) 293-5927

On Mon, Dec 10, 2018 at 3:36 AM Malcolm Clarke <mclar...@gmail.com> wrote:

Dear Paul

We are trying to explain that many software applications will do a string comparison that is case-insensitive. I know that Excel works this way as I have had to go back and make changes and used "exact()" in place of "=". It is possible flavours of SQL may behave likewise. For this reason it is advisable to avoid case-sensitive terms.

[Paul Schluter]

Michael and colleagues,

The IEEE 11073 has agreed over the past two decades that the normative identifier is the numeric code, since it can uniquely select the term-row that has the definition, common term, systematic name and REFID.  This applies to “classic” IEEE 11073 and IEEE 11073 PHD encoding using ASN.1 modeled binary, IHE PCD, DICOM and FHIR.  ENV1064:2005,:2017 and SCP V3 also support the numeric identifier codes in addition to the REFIDs.

Among other open standards and implementation guides, the HL7 V3 IG Annotated ECG (aECG) is the only open implementation guide or profile that only uses only the REFID for observation and other identifiers that I am currently aware of, and there may be vendors who have adopted the REFID-only form in their xml-based protocols as well.  Since the HL7 V3 IG Annotated ECG protocol and nomenclature is actively used, we need to continue supporting it by (1) not ‘withdrawing’ existing terms and the semantic concepts that it uses and (2) providing unambiguous human-readable and machine-readable documentation about any changes in 10101R and (3) facilitating automatic mapping of any changes, especially for inbound aggregating receivers such as EMRs that may be acquiring data from a mix of any number of devices systems and protocols that use the IEEE 11073 nomenclature over the past 15+ years.

Best regards,

Paul Schluter

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

On Dec 10, 2018, at 9:24 AM, Michael Faughn <m.fa...@prometheuscomputing.com> wrote:

All,

In 11073 RefIDs don't go over the wire, term codes do.  So, 11073 device communication isn't the domain in which there is an issue.  Or am I mistaken about this?  It is in all of the non-11073 usages of the terminology where people/systems do store and/or transmit the RefID where there is potential for error.  I think the email I sent just a few moments ago addresses the issue in application domains that are outside of 11073 device communication.

-Michael

Michael Faughn
Software Developer
Prometheus Computing, LL

m.fa...@prometheuscomputing.com
W: (828) 293-5927
F:  (828) 293-5927

--
You received this message because you are subscribed to the Google Groups "IHE PCD Profile - Device Point-of-Care Integration" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-dpi...@googlegroups.com.
To post to this group, send email to ihe-p...@googlegroups.com.
Visit this group at https://groups.google.com/group/ihe-pcd-dpi.
For more options, visit https://groups.google.com/d/optout.

[Paul Schluter]

Michael, Malcolm, John, Kai, Barry, Mary, Joel and colleagues,

As promised, I am sending you a spreadsheet that lists all the IEEE 11073-10101 and -10102 QT and QTc terms.  This is organized as two side-by-side tables showing the ‘global’ terms on the left and ‘per-lead’ terms on the right with rows aligned by their numeric code and definitions.  The table also includes an informative ‘UsedBy’ column regarding their adoption by the HL7 <V3_IG_ECGR1_R2_INFORM_2015JUN.pdf>, denoted by ‘aECG IG’, and DICOM by their ‘Context Group’ identified by ‘CID nnnn’. (there are many other DICOM CIDs that use the -10102:2012 aECG nomenclature, but these are the most relevant to this discussion).

There were several objectives regarding this effort:  

(1) specify the use of the _GL suffix in cases where it is necessary to clearly distinguish between ‘global’ and ‘per-lead’ ECG terms,

(2) enable the use of a “case-insensitive” string match by deprecating the use of the QTc suffix in MDC_ECG_TIME_PD_QTc[MMM]2::16164, and

(3) address an inconsistency between the ‘global’ and ‘per-lead’ suffixes regarding QTc measurements where an ‘unspecified' correction is used vs a ‘corrected’ QTc (presumably based on the Bazett formula, but at the time that -10102 aECG was developed, we could not achieve consensus on that it really was Bazett to the satisfaction of the FDA and representatives from the diagnostic 12-lead vendor community, which led to the definition of a new term code and REFID MDC_ECG_TIME_PD_QTC_BAZETT (also note that Bazett was not included in the Systematic Name in the original pair of terms).

The attached spreadsheets shows the proposed final resolution, where the first-listed REFID is the ‘preferred REFID’ (or only REFID) and the second is the less-preferred REFID-synonym that will be maintained to document and to facilitate message conformance testing using the NIST RTMMS and NIST (and other) test tools and to facilitate mapping.  In all cases where a numeric code is provided the relationship is unambiguous and automatic conversion to a standard internal representation is possible.  In cases where only the REFID is specified, the only problematic REFID is ‘MDC_ECG_TIME_PD_QTc’ if the ‘global’ vs ‘per-lead’ context is unknown (that said, the context is known and conveyed by both HL7 V3 IG aECG and DICOM messaging formats, so it hasn’t been an issue).

Please feel free to review the attached spreadsheet and feel free to contact me (or the larger group) if you have any questions, concerns or recommendations.

Thanks and regards,

Paul Schluter

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

<<QTc.Global.PerLead.1c.2018-12-10T11.xlsx>>   provided on an ‘as is’ basis as part IEEE P11073-10101R “revision” balloting

[Malcolm Clarke]

Dear Paul

Thank you for this information. I shall update 10101R.

Please note that the process will be to deprecate the old terms, especially MDC_ECG_TIME_PD_QTc, in favour of the new terms. Be aware that we have defined "deprecate" in 10101R to mean that the code continues to exist (supporting legacy), but is marked that it should not be used in future production. This fulfils the requirements that have been identified to manage these terms and avoid confusion. It will leave 10101R "clean" rather than having a multiplicity of RefId synonyms and term code synonyms, as well as a case sensitive term, which can serve no-one.

I am still in the process of adding the new terms you sent. I hope to complete that task shortly and so have a draft available.

Regards

Malcolm

[Paul Schluter]

Greetings!

Please plan to join our RTM tcon today, Wednesday, December 12th, starting at 11:00 AM CST, where we will consider adding one or two additional new ventilator terms and make any final adjustments to the definitions of the terms we already have to more precisely align them with ISO 19223.  The first of the two new proposed terms are “delivered tidal volume” where the volume-flow is determined by and/or measured solely inside the machine.  The second term reports breathing circuit or airway leakage over a single tidal volume cycle.

After the ventilator term discussion, and provided that there’s time and interest at today’s RTM meeting, we could touch on the topic of REFID-synonyms and other types of synonyms.  It is more likely, however, that this will be a more in-depth technical discussion that will be co-hosted and co-led by Michael Faughn and others as part of the DPI call either this Thursday or next Thursday (or both) starting at 1:00 PM CST.  Michael will sent out a notice about that later.

The Webex and tcon information is provided below.

Thanks and regards,

Paul Schluter

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

[Paul Schluter]

Season Greetings!

Please plan to join our RTM tcon tomorrow, Wednesday, December 19th, starting at 11:00 AM CST.  We will start with a brief discussion of a recent proposal by Norman Jones and Steve Dain to repurpose and redefine one of the new terms we discussed last week to apply to the “unintended leakage at the patient interface” expressed as a volume of gas per single respiratory cycle having the proposed Reference ID “MDC_VENT_VOL_TIDAL_LEAK_UNINTENDED_PI”, retaining the previously assigned numeric code 2::22484 and discarding the previously proposed Reference ID “MDC_VENT_VOL_TIDAL_LEAK”.  It is very likely that we will be able to conclude this discussion by email prior to the RTM tcon tomorrow, but if not, we will probably only need the first five to ten minutes to finalize everything.  [The updated term and definition have been sent out to the individuals involved with this topic.]

The primary focus of our RTM tcon tomorrow will be to review a proposal regarding the RTMMS and IEEE 11073 term process flow and term state definitions that will be included as Annex G in the next updated to IEEE P11073-10101R “revision”.

During the DoF, RTM and/or DPI calls last week, several people expressed concerns that we have not yet finalized the RTM and IEEE 11073 term state identifiers to the point where they could be included in the FHIR PoCD Implementation Guide that Stefan and John Rhoads are working on.  I have corralled most everyone’s thoughts on this matter and offer the following three documents for your thoughtful review prior to tomorrows RTM tcon and discussion during the tcon.  Based on comments I have received and incorporated from several people, the attached drafts provide a high degree of clarity and consistency:

<<ProcessDiagram.3c.2018-12-18T11.docx>>

This has been updated relative to previous versions to use the more recent state names and greater clarity regarding ‘rejected’, ‘deprecated’ and ‘withdrawn’ terms and other items.

<<AnnexG-D3r7.1c.2018-12-18T11.pss-comments.docx>>

This is a significantly updated version of IEEE P11073-10101R-D3r7 Annex G that use the more recent state names and provides greater clarity regarding ‘rejected’, ‘deprecated’ and ‘withdrawn’ terms and other information.

<<FHIR IG Proposed Text and Discussion.1a.2018-12-18T12.docx>>

This is the shorter form of the descriptions, intended for the FHIR IG.  Please note my three comments regarding ‘accepted’ (formerly ‘rtm-accepted’) terms since this is where the primary difference lies between a more IEEE 11073 centric process (that we have today) and a more RTMMS-centric process (that would can and should consider for the future).  I believe the proposed text should satisfy everyone, but I retained my earlier comments (in italics) to primarily serve as talking points.

All three documents are relatively final DRAFTS intended to facilitate further discussion and closure on this topic.  The updated Annex G is intended to replace the existing Annex G, and including the process diagram would be very beneficial.  The updated text for the FHIR IG provides a more concise summary of the principal term states and is entirely consistent with the updated Annex G content and diagram.

I look forward to our discussion(s) tomorrow.  The RTM tcon for next week (Wednesday, December 26) is cancelled due to the Holidays.  We will likely reconvene on Wednesday, January 2nd.

The Webex and tcon information is provided below.

Thanks and regards, and to everyone, have a wonderful Holiday Season!

[Malcolm Clarke]

Dear Paul

It is my understanding that IEEE accept that we may use RTMMS as an adjunct to the published 10101 series of standards to manage terminology interim between publication.

We therefore will take the opportunity of 10101R to produce annex G to describe the process of management of terminology on that basis.

Several of aspects of the documents therefore should be amended to ensure clarity of description of the formal relationship between RTMMS and the published standards.

Regards

Malcolm

[Malcolm Clarke]

Dear All

11073-10101R is currently IEEE ballot. This is a strict process. Drafts are submitted for review and comments on content are submitted. During the initial ballot, comments may be made on the entire document. Thereafter, during a recirculation (given a certain acceptance) further comments should only be made on the redlines of the revised draft. This ensures that a standard can make progress during ballot. Comments may obviously be made on other areas of text, and are important where technical error is identified; but such comment may be ignored as out of scope.

In developing Annex G of 10101R I sought wide discussion on its content, which included distribution of text for comment in advance submitting the draft for review in recirculation 1. In the recirculation I received no comments on Annex G, which I take as approval by the ballot group for its content.

However, in order to ensure concensus, I invited discussion on Annex G at the IEEE/HL7 meeting in September, when comments were discussed. Some useful comments were made and I shall incorporate these in the next draft.

It is therefore not appropriate for Paul to reopen discussions on Annex G with intent to make fundamental changes to content, as this directly undermines the IEEE ballot process. Moreover, in order to ensure timely conclusion of the ballot, I shall invoke IEEE guidelines and I shall not accept new material for Annex G - |I certainly will not replace the current Annex G.

A new draft of 10101R is almost complete, and this will go to recirculation within the next few days in order to have comments back for the forthcoming IEEE/HL7 meeting in January. I hope this then brings timely conclusion to the ballot.

Regards

Malcolm

On 19/12/2018 00:39, Paul Schluter wrote:

[Paul Schluter]

Malcolm; John and John, Patricia, Chris, Daidi, Todd and colleagues,

Although I sympathize with Malcolm's desire to accelerate the term standardization process and use the RTMMS and IEEE processes more effectively, we also must recognize that the RTMMS and IEEE each have their own individual roles.  The RTMMS was originally designed to capture new terms from vendors and clinicians, compare them with the existing IEEE 11073 terms, and in cases where no matching IEEE 11073 term exists, propose a new term.  The list of new terms serves as the starting point for creating a new IEEE 11073-10101 revision or amendment to capture, review and ballot and ultimately approve and publish the new terms using the well-defined, ANSI-accredited and internationally recognized and respected IEEE-SA standardization process.  A recent example of this is ISO/IEEE 11073-10101a-2015 nomenclature amendment.

In your recent term process proposal, you appear to be recommending that the RTMMS be used to define and publish new terms that are endorsed for use in commercially available products.  This, I believe, would create a conflict with existing IEEE procedures and could lead to confusion within our industry as to when a term is truly approved.  There are many reasons why we use the IEEE standardization process as the final gatekeeper for the IEEE 11073 terminology and I see no reason to abandon that now.  Furthermore, I do not believe that the IEEE-SA or ANSI can grant this exception to IEEE 11073 General Committee and it's Working Groups.

We should continue to use the IEEE standardization process as we have in the past.  However, we can and should increase our effectiveness by using the enhancements that Michael Faughn, Nicolas Crouzier and others are currently adding to the NIST RTMMS that will allow us to automate and streamline many of the bookkeeping chores we have to deal with today.  Also, defining additional terms on a ‘per-device’ basis using more modern methods of expressing device containment models to verify completeness of the nomenclature can also be used.

*     *     *

The IEEE has a well-defined, ANSI-accredited and internationally recognized and respected process for proposing, drafting, reviewing, balloting and publishing voluntary consensus-based open standards.  Participation is open to all persons who are directly and materially affected by the standardization activity and participants are free to express their position(s) and supporting rationale and have their position(s) fully considered.

I raised concerns about the content in Annex G at the HL7 and IEEE 11073 meetings in Baltimore, and as a consequence we devoted a significant amount of time during the Wednesday ‘Q2’ discussion (on October 3) regarding the IEEE 11073-10101* term 'process' and 'state' topics.  One of the concerns I raised (and that has been raised by others) is that the earlier term process and state diagram proposed that the ‘approved’ state identifier apply to terms that were still within the RTMMS process, prior to the creation of a draft IEEE 11073-10101* nomenclature revision or amendment that would ultimately 'approve and publish’ them.

There was little clarity regarding the criteria for the proposed ‘(rtm-)approved’ state, other than indicating that vendors could use ‘(rtm)-approved’ terms in commercially available products.  [I’ve added the '(rtm)-‘ prefix to ‘approved' to clearly distinguish it from the fully reviewed and balloted ‘ieee-approved’ term state in this email and attached diagram.]  This is an important issue since the ‘(rtm-)approved’ state would be tantamount to an IEEE ‘approved and published’ term that uses the well-documented, ANSI-accredited and internationally recognized IEEE process, even though little or no process nor criteria have been defined for the ‘(rtm)-approved’ state.

More importantly, the ‘(rtm)-approved’ description has text indicating that it may be made available in commercially available systems, but this would directly conflict with the standard IEEE warning listed on the first and third lines of the first page of any IEEE draft standard:

      This document is an unapproved draft of a proposed IEEE Standard.  As such, this document is subject to change. USE AT YOUR OWN RISK! ... Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes. 

This warning applies to all previously unpublished terms in a draft IEEE P11073-10101* revision or amendment until the standard is approved and published.

Furthermore, the ‘(rtm)-approved’ term state appears to imply that ‘(rtm)-approved’ terms must pass into and through the IEEE standard process without modification or deletion.  This is also clearly at odds with the “due process” requirement required by ANSI and IEEE, where any new content is subject to review and discussion.

In a similar vein, the earlier term process diagrams and D3r7 Annex G text appear to prohibit the introduction of new terms during preparation of the first ballot draft as well as subsequent ballot recirculations.  But new terms can and do arise, especially as we refine the originally proposed terms and bring in additional outside expertise (e.g. consult with the leadership and other experts from ISO 19223 regarding ventilator terminology, review topics with representatives from LOINC, etc.).  It is our ability to work with nationally and internationally recognized experts and vendors that helps ensure that the IEEE 11073-10101* nomenclature standards are comprehensive, complete and correct and are written with sufficient rigor and clarity to largely ensure semantic interoperability.

*     *     *

The ’term process’ topic has been an ongoing issue since the HL7 and IEEE 11073 meeting in Baltimore in early October, when I articulated concerns about ‘term process’ overlap between the RTMMS and IEEE (this was brought up during Wednesday ‘Q2' and at other times during our meeting).  We discussed other aspects regarding ’term process’, such as Spencer Crosswy’s presentation and proposals based on his experience with the FACE (Future Airborne Capability Environment) interoperability standard.

I volunteered to update the process diagram and presented it during our RTM tcon held on Wednesday, October 10 (with Malcolm, Spencer, Richard Tayrien, Stefan Karl, John Rhoads attending) immediately following the HL7 meeting.  Based on what was said (or not) during the tcon, the updated diagram appeared to be acceptable to everyone.  [The RTM invitation with attachments <ProcessDiagram.2a.2018-10-10T09.pss.docx> and Malcolm’s D3r7 diagram <fig G1.1a.2018-10-06T15.malcolm.docx> was sent out on October 10, 2018].  During this meeting we also discussed the use of the state identifier ‘rtm-accepted’ rather than ‘approved’ to avoid confusion with the use of ‘approved’ used during the more formal IEEE standardization process.

Two months elapsed after the October 10 tcon without further discussion or updated documentation provided by you, but questions regarding ‘What are the term state names?’ continue to persist since they are necessary to support future RTMMS term development, to enable completion of the FHIR PoCD Implementation Guide and to indicate term status when the NIST RTMSS as a FHIR terminology server.

Based on these requests, we held an RTM tcon last Wednesday, December 19 (with John Rhoads, John Garguilo, Nicolas Crouzier, Michael Faughn, Norman Jones, Steven Dain, Richard Tayrien, Spencer Crosswy, Stefan Karl and Swapna Abhyankar attending) with a shorter follow-up discussion during the DPI tcon on Thursday, December 20 (with John Garguilo, Michael Faughn and Matthias Kaiser attending).  I walked through the proposed updates to the IEEE P11073-10101R Annex G process diagram and text as well as updated text for the FHIR implementation guide so that all three documents were consistent.

During our meetings we further confirmed that the IEEE process should continue to be used as our ’top-level’ consensus review and approval process.  The three major IEEE term states ('ieee-draft', 'ieee-approved' and 'ieee-published’) now use the ‘ieee-‘ prefix to clearly distinguish them from all other RTMMS term processes and states.  The attached <ProcessDiagram.3d.2018-12-21T09.docx> and .pdf include the ‘ieee-‘ prefixes that makes the relationships between the RTMMS and IEEE term processes and states very clear.  [Prefixes were not added to the RTMMS and other general term states, partly as a preference expressed by several software and database developers and partly to leave the option open if additional groups (FHIR, PCHA/Continua, MDPnP, OR.NET, CMI and other organizations) wanted to contribute to the RTMMS and IEEE 11073 nomenclature but also preferred to connect to and interact with the RTMMS in a slightly different manner regarding the term state names.]

It would be very helpful to hear what others think about this issue, since many of you have been involved in IEEE 11073 standards activities for the past one or two decades and more recently with the NIST RTMMS since its inception over ten years ago. 

Thanks for your patience in this manner, and have a very enjoyable Holiday Season!

Paul Schluter

Center4MI:  psch...@center4mi.org

Gmail:  pssch...@gmail.com

Cell:  (414) 702-2026

<<ProcessDiagram.3d.2018-12-21T09.docx>>

<<ProcessDiagram.3d.2018-12-21T09.pdf>>   viewable on any platform!

[Malcolm Clarke]

Dear Paul

On 24/12/2018 01:22, Paul Schluter wrote:

Malcolm; John and John, Patricia, Chris, Daidi, Todd and colleagues,

Although I sympathize with Malcolm's desire to accelerate the term standardization process and use the RTMMS and IEEE processes more effectively, we also must recognize that the RTMMS and IEEE each have their own individual roles. 

Discussions on RTMMS were started in July 2018 and included in draft D3 which was balloted in September. As there were no comments on Annex G, I assume ballots accepted the content. However I invited discussions at IEEE/HL7. I received some useful comments that I have included in the next draft. This is hardly acceleration.

The RTMMS was originally designed to capture new terms from vendors and clinicians, compare them with the existing IEEE 11073 terms, and in cases where no matching IEEE 11073 term exists, propose a new term.  The list of new terms serves as the starting point for creating a new IEEE 11073-10101 revision or amendment to capture, review and ballot and ultimately approve and publish the new terms using the well-defined, ANSI-accredited and internationally recognized and respected IEEE-SA standardization process.  A recent example of this is ISO/IEEE 11073-10101a-2015 nomenclature amendment.

RTMMS was first available in 2007. In almost 12 years we should have a fully approved process for RTMMS and IEEE publication. These should complement. Your example that the last published standard was 2015 shows exactly how slow we can be to publish an amendment and is not sufficient for the needs of industry.

In your recent term process proposal, you appear to be recommending that the RTMMS be used to define and publish new terms that are endorsed for use in commercially available products. 

From my experience 10101R I would recommend that all terms are within RTMMS and are taken from RTMMS to populate any revision or amendment. RTMMS can then be used to ensure terms are fully populated with information and will ensure no conflicts. It has been arduous to cope with the multiplicity of spreadsheets, databases, standards and other bits of information. This can no longer continue.

We must move to a faster method to support nomenclature. LOINC release new version frquently (6 months?). We should be achiving a similar timescale.

This, I believe, would create a conflict with existing IEEE procedures and could lead to confusion within our industry as to when a term is truly approved.

Many organisations function using only a database (LOINC) and IEEE 11073 should be no different. An approved term means exactly that it is an approved term and thus can be used with confidence. This supports the interface with the increasing number of organisations and applications that demand an electronic interface (e.g. FHIR, DIM Editor). We must move to an electronic form that is understood to be complete and authorative.

An electronic form of nomenclature is essential to support the rapidly changing demands industry for new nomenclature terms that they expect to use in products between publication of revisions or amendments. Annex G defines status of terms to avoid confusion.

 There are many reasons why we use the IEEE standardization process as the final gatekeeper for the IEEE 11073 terminology and I see no reason to abandon that now.  Furthermore, I do not believe that the IEEE-SA or ANSI can grant this exception to IEEE 11073 General Committee and it's Working Groups.

The IEEE publication complements an electroninc form. This might include description text to augment a set of nomenclature. There is no suggestion to abandon the published form. It is unclear why you should raise this as an issue.

We should continue to use the IEEE standardization process as we have in the past. 

No. We must move to an electronic form that is complete and authorative. This can complement and support production of revisions and amendments, but provide approved nomenclature interim publication to support industry.

However, we can and should increase our effectiveness by using the enhancements that Michael Faughn, Nicolas Crouzier and others are currently adding to the NIST RTMMS that will allow us to automate and streamline many of the bookkeeping chores we have to deal with today.  Also, defining additional terms on a ‘per-device’ basis using more modern methods of expressing device containment models to verify completeness of the nomenclature can also be used.

*     *     *

The IEEE has a well-defined, ANSI-accredited and internationally recognized and respected process for proposing, drafting, reviewing, balloting and publishing voluntary consensus-based open standards.  Participation is open to all persons who are directly and materially affected by the standardization activity and participants are free to express their position(s) and supporting rationale and have their position(s) fully considered.

What is your point?

I raised concerns about the content in Annex G at the HL7 and IEEE 11073 meetings in Baltimore, and as a consequence we devoted a significant amount of time during the Wednesday ‘Q2’ discussion (on October 3) regarding the IEEE 11073-10101* term 'process' and 'state' topics.  One of the concerns I raised (and that has been raised by others) is that the earlier term process and state diagram proposed that the ‘approved’ state identifier apply to terms that were still within the RTMMS process, prior to the creation of a draft IEEE 11073-10101* nomenclature revision or amendment that would ultimately 'approve and publish’ them.

FYI. RTMMS refers to terms as "approved" and so I took this into consideration when I created Annex G. The status terms are defined in Annex G so there can be no confusion between "approved" and "published". The terms are clear within the context of the process. I do not understand why you try to confuse where there does not need to be confusion.

There was little clarity regarding the criteria for the proposed ‘(rtm-)approved’ state, other than indicating that vendors could use ‘(rtm)-approved’ terms in commercially available products.  [I’ve added the '(rtm)-‘ prefix to ‘approved' to clearly distinguish it from the fully reviewed and balloted ‘ieee-approved’ term state in this email and attached diagram.]  This is an important issue since the ‘(rtm-)approved’ state would be tantamount to an IEEE ‘approved and published’ term that uses the well-documented, ANSI-accredited and internationally recognized IEEE process, even though little or no process nor criteria have been defined for the ‘(rtm)-approved’ state.

To be honest, I do not understand the current "approval" process. It has been described but I am unsure if it is enacted.

More importantly, the ‘(rtm)-approved’ description has text indicating that it may be made available in commercially available systems

Yes, we need fast track approval of new terms for manufacturers. They cannot wait years for a new publication,

, but this would directly conflict with the standard IEEE warning listed on the first and third lines of the first page of any IEEE draft standard:

      This document is an unapproved draft of a proposed IEEE Standard.  As such, this document is subject to change. USE AT YOUR OWN RISK! ... Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes.

But published terms are subject to similar changes in a revision. I see no reason to differentiate.

This warning applies to all previously unpublished terms in a draft IEEE P11073-10101* revision or amendment until the standard is approved and published.

But published terms are subject to similar changes in a revision. I see no reason to differentiate. 10101R highlights the mess that currently exists.

Furthermore, the ‘(rtm)-approved’ term state appears to imply that ‘(rtm)-approved’ terms must pass into and through the IEEE standard process without modification or deletion.  This is also clearly at odds with the “due process” requirement required by ANSI and IEEE, where any new content is subject to review and discussion.

Quite the contrary, all terms go through the ballot process and so could be changed. However, given a correct process in RTMMS then there ought not to be reason for changes to be made (QA already done and no conflicts).

In a similar vein, the earlier term process diagrams and D3r7 Annex G text appear to prohibit the introduction of new terms during preparation of the first ballot draft as well as subsequent ballot recirculations.  But new terms can and do arise, especially as we refine the originally proposed terms and bring in additional outside expertise (e.g. consult with the leadership and other experts from ISO 19223 regarding ventilator terminology, review topics with representatives from LOINC, etc.).  It is our ability to work with nationally and internationally recognized experts and vendors that helps ensure that the IEEE 11073-10101* nomenclature standards are comprehensive, complete and correct and are written with sufficient rigor and clarity to largely ensure semantic interoperability.

It would be my hope that all terms are entered into RTMMS first and then taken from RTMMS to create any revision or amendment. This would support improved QA of terms prior to inclusion in any draft and would remove the need to compare RTMMS with document.

The ’term process’ topic has been an ongoing issue since the HL7 and IEEE 11073 meeting in Baltimore in early October, when I articulated concerns about ‘term process’ overlap between the RTMMS and IEEE (this was brought up during Wednesday ‘Q2' and at other times during our meeting).  We discussed other aspects regarding ’term process’, such as Spencer Crosswy’s presentation and proposals based on his experience with the FACE (Future Airborne Capability Environment) interoperability standard.

I volunteered to update the process diagram and presented it during our RTM tcon held on Wednesday, October 10 (with Malcolm, Spencer, Richard Tayrien, Stefan Karl, John Rhoads attending) immediately following the HL7 meeting.  Based on what was said (or not) during the tcon, the updated diagram appeared to be acceptable to everyone.  [The RTM invitation with attachments <ProcessDiagram.2a.2018-10-10T09.pss.docx> and Malcolm’s D3r7 diagram <fig G1.1a.2018-10-06T15.malcolm.docx> was sent out on October 10, 2018].  During this meeting we also discussed the use of the state identifier ‘rtm-accepted’ rather than ‘approved’ to avoid confusion with the use of ‘approved’ used during the more formal IEEE standardization process.

Two months elapsed after the October 10 tcon without further discussion or updated documentation provided by you, but questions regarding ‘What are the term state names?’ continue to persist since they are necessary to support future RTMMS term development, to enable completion of the FHIR PoCD Implementation Guide and to indicate term status when the NIST RTMSS as a FHIR terminology server.

Based on these requests, we held an RTM tcon last Wednesday, December 19 (with John Rhoads, John Garguilo, Nicolas Crouzier, Michael Faughn, Norman Jones, Steven Dain, Richard Tayrien, Spencer Crosswy, Stefan Karl and Swapna Abhyankar attending) with a shorter follow-up discussion during the DPI tcon on Thursday, December 20 (with John Garguilo, Michael Faughn and Matthias Kaiser attending).  I walked through the proposed updates to the IEEE P11073-10101R Annex G process diagram and text as well as updated text for the FHIR implementation guide so that all three documents were consistent.

During our meetings we further confirmed that the IEEE process should continue to be used as our ’top-level’ consensus review and approval process.  The three major IEEE term states ('ieee-draft', 'ieee-approved' and 'ieee-published’) now use the ‘ieee-‘ prefix to clearly distinguish them from all other RTMMS term processes and states.  The attached <ProcessDiagram.3d.2018-12-21T09.docx> and .pdf include the ‘ieee-‘ prefixes that makes the relationships between the RTMMS and IEEE term processes and states very clear.  [Prefixes were not added to the RTMMS and other general term states, partly as a preference expressed by several software and database developers and partly to leave the option open if additional groups (FHIR, PCHA/Continua, MDPnP, OR.NET, CMI and other organizations) wanted to contribute to the RTMMS and IEEE 11073 nomenclature but also preferred to connect to and interact with the RTMMS in a slightly different manner regarding the term state names.]

I am concerned that you are making and creating discussion of issues that do not exist and, as I received no comments during ballot, are not shared by others.

These discussions are a storm in a teacup. The major issue that we should address is to attend the content of RTMMS so that it is complete and accurate, and to ensure that RTMMS can serve people in an intuitive manner, and support the process of term management.

It would be very helpful to hear what others think about this issue, since many of you have been involved in IEEE 11073 standards activities for the past one or two decades and more recently with the NIST RTMMS since its inception over ten years ago.

I will look at the documents I have received and consider appropriate amendments.

<<ProcessDiagram.3d.2018-12-21T09.docx>>

<<ProcessDiagram.3d.2018-12-21T09.pdf>>

[Paul Schluter]

Greetings, and Happy New Year!

Please plan to join our RTM tcon today, Wednesday, January 2nd, starting at 11:00 AM CST.  We will resume our discussion regarding the RTMMS and IEEE 11073 term process flow and term state definitions that we held on December 19th, but also including additional discussion brought up in the following emails sent to you since then:

   Paul Schluter, “11073-10101R Annex G”, December 23, 2018 at 4:22 PM CST

   Malcolm Clarke, “Re: 11073-10101R Annex G”, December 28, 2018 at 8:05 AM CST

   Michael Faughn, “Re: 11073-10101R Annex G”, December 28, 2018 at 10:18 AM CST and 11:33 AM CST

This will be a general discussion, starting with the general topic of whether it is appropriate to define a separate term approval process within the RTMMS community.  What would its standing be among other standards organizations, such as IEEE 11073 and ISO and others?

Although ‘IHE Connectathon’ and ‘PlugFest’ interoperability test events are likely to also use ‘provisional’ and/or ‘accepted’ terms to enable testing of more recent or advanced features, e.g. MEM-LS uses ‘provisional’ attributes and location events, it is also very likely that 'Certification’ level testing will almost always require ‘published’ IEEE 11073 terms.

The Webex and tcon information is provided below.

Best regards,

Paul Schluter

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

[Malcolm Clarke]

Dear Paul

The draft revision of 10101R has been submitted to IEEE for recirculation. It is intended this will close in time to consider comments during a session at IEEE/HL7.

As I have indicated, changes to Annex G will not be made at this stage. I would therefore recommend you do not have discussion on this topic today.

Regards

Malcolm

[Paul Schluter]

Malcolm and colleagues,

I am soliciting input from the broader community of standards users as those involved with developing them so that we are fully informed of all the relevant issues by the upcoming HL7 and IEEE 11073 meeting in San Antonio.  Any and all are welcome to join in the RTM tcon discussion today and hopefully we will be able to finalize this two weeks from now.

Best regards,

Paul Schluter

[Malcolm Clarke]

Dear All

A revised draft has been submitted to IEEE for recirculation. It is
hoped that comments will be available for discussion at IEEE/HL7.

The clean and redline drafts and comment resolution from recirculation 1
are available as a package for members of this group to review at

https://app.box.com/s/mr3fu607cag9twli1czhpq7yhyf4wk1g

A comment file is included for people to submit comments. Please submit
your comments to me for inclusion in the ballot.

Regards

Malcolm

[Paul Schluter]

Greetings!

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

Michael Faughn had several topics regarding the RTMMS that he would like to discuss prior to the HL7 and IEEE 11073 meetings in San Antonio next week.  This includes several updated modeling concepts for the RTMMS and possibly follow-up topics regarding IEEE P11073-10101R Annexes G and H.

The Webex and tcon information is provided below.

Best regards,

Paul Schluter

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

[Malcolm Clarke]

Dear All

The IEEE have asked that I recall the package for the recirculation of
11073-10101R. I have therefore removed from the link. Furthermore, IEEE
have asked that I do not forward the package by email.

Ballot comments may only be submitted by members of the ballot group,
other than through the IEEE-SA public review system
(https://publicreview.standards.ieee.org/public-review-web/public-app).

IEEE also remind that drafts may not be shared other than to members of
an IEEE working group.

As this group has a primary focus to discuss and develop IEEE
nomenclature, I would recommend that it properly constitutes as an IEEE
working group.

Regards

Malcolm

On 03/01/2019 10:04, Malcolm Clarke wrote:
> Dear All
>
> A revised draft has been submitted to IEEE for recirculation. It is
> hoped that comments will be available for discussion at IEEE/HL7.
>
>

> Regards
>
> Malcolm
>
>

[Paul Schluter]

Greetings,

The RTM tcon for today is cancelled since many of us are attending the IEEE 11073 and HL7 meetings in San Antonio this week.  

The call for the following week is also cancelled due to the IHE NA Connectathon.

I wish all of you the best of success at the Connectathon next week!

Paul Schluter

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

[Paul Schluter]

Greetings,

Just a friendly reminder, but the RTM tcon for this Wednesday, January 23rd, is cancelled, since many are attending the IHE NA Connectathon this week in Cleveland.

And to everyone attending the Connectathon, I wish you the best of success!

Paul Schluter

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

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, January 30th, is cancelled.  It’s an “off week” for the IHE PCD tcons, and it is very likely that everyone is busy catching up after a successful Connectathon last week.

We will reconvene next Wednesday, February 6th.

Paul Schluter

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

PS.  It’s a balmy -20°F,  -47°F WC outside my house in Wisconsin right now!

[Paul Schluter]

Greetings!

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

We are making reasonable progress on IEEE P11073-10101R and have general agreement regarding Annex H that describes the overall term process flow and term states.  I will provide a brief summary of where we are today with -10101R and have included a pdf of Annex H that we can walk through during our meeting today.

The Webex and tcon information is provided below.

Best regards,

Paul Schluter

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

<<11073-10101R-D5-r2-2019-02-05 - Annex H.pdf>>

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, February 13, is cancelled, since many of you are attending HIMSS19 in Orlando this week.

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, February 20, starting at 11:00 AM CST.  We can use this hour as an open forum to cover any topics regarding IEEE P11073-10101R “revision” that have only been discussed by email or any other IEEE 11073 nomenclature topics.  If nobody joins the call before 11:05 AM, I’ll just drop the call.

One topic I plan to go over is the topic of synonym terms of all types (not just REFID-synonyms that have the same numeric code) and how they can be represented in a computable manner that enables:

(1) mapping of earlier 10101:2004, 10102-2012 aECG and 10101a-2015 terms to the newer ‘preferred’ 11073-10101R REFIDs and/or term-codes, when they have been defined in 10101R,

(2) mapping of ‘preferred’ 11073-10101R REFIDs and/or term-codes to earlier 10101:2004, 10102-2012 aECG and 10101a-2015 equivalent REFIDs and/or term codes.

I am happy to say that the bidirectional mapping works for practically all terms in the observation identifiers in the SCADA partition and units-of-measure, which are the primary sets of terms currently used by the IHE PCD domain and terms supported on the NIST RTMMS (including the hRTM) and NIST test tools.  The ability to perform these mappings in a version-independent manner is a major plus for product and system implementations as well as rigorous 'but tolerant’ message conformance testing.

I also am very happy to say, thanks to Malcolm Clarke's heroic efforts and others, that we are rapidly coming to completion on the IEEE P11073-10101R “revision” with the next (and hopefully last) ballot recirculation starting today or tomorrow!

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, February 27, is cancelled.  Many of us are busy reviewing IEEE P11073-10101R-D5r4 that was sent out for its third recirculation ballot last Thursday, and we are making excellent progress on that front.

Best regards,

Paul Schluter

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

PS.  If anyone has some 10101R related topics to discuss today, I would be happy to host an RTM call if I hear from you by 10:45 AM CST today.  For the past several weeks, practically all of our correspondence has been handled by email.

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, March 6, at 11:00 AM CST.  I am very happy to say that the latest draft of IEEE P11073-10101R-D6r2 has consensus approval to progress to one more recirculation (#4) with the expectation that this is the final draft.  All major issues have been addressed but since changes were made relative to the earlier recirculation (#3) another circulation is required.  So this is great news, and congratulations to Malcolm Clarke and everyone else who participated in this Herculean task!

Earlier this week the proposed definitions for the previously undefined event and alert identifiers from Annex B of ISO/IEEE 11073-10101:2004 were throughly reviewed and I submitted about 50 comments to update the proposed Definitions and Systematic Names (and Acronyms where appropriate) to ensure that they were consistent with the earlier work done by the IEEE P11073-10101:2004 Working Group.  This will allow us to continue to use them without any significant changes for the event and alert terms and tuples that we will be defining and adding in IEEE P11073-10101b.  I shared some of this documentation with several of you and I would be happy to walk through the material and answer any questions that you may have.

Best regards,

Paul Schluter

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

[Malcolm Clarke]

Dear Paul

It would be worth to add that I reviewed the spreadsheet that included the -2004 material and made changes to several more of the events to improve the entries for clarity, remove ambiguity, alignment and correct spelling errors.

It would also be appropriate to add that none of the entries were changed because they were incorrect, rather that the opportunity was taken to improve the quality, and so we should not expect further corrections are required. I think the exercise exposed more errors in the -2004 material than 10101R.

Regards

Malcolm

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 13th, is cancelled.  Many of us are busy reviewing the 1000+ page IEEE P11073-10101R-D6r2 revision that was sent out for its fourth recirculation ballot last Wednesday, with ballot comments due this Saturday, March 16, at 11:59 PM EST.

Best regards,

Paul Schluter

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

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 20th, is cancelled.  The fourth recirculation ballot of the 1000+ page IEEE P11073-10101R-D6r2 revision is now largely complete, and pending final comment resolution of one or two issues, I believe we largely done.

Best regards,

Paul Schluter

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

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 27th, is cancelled.  This is an “off week” for the IHE PCD domain, and although we had considered holding a side bar discussion regarding events and alerts, a key participant could not make the RTM call today.

Malcolm and I are very happy to say that the fourth recirculation ballot of the 1000+ page IEEE P11073-10101R-D6r2 revision was successfully completed and that all “must be satisfied” comments have now been addressed in the follow-on P11073-10101R-D7r1 draft - we now have 100% approval and have also met the Friday March 22 RevCom deadline!

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, April 3rd, is cancelled.

We will reconvene next Wednesday to resume our discussion regarding event and alert identifiers to be included in 10101b.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, April 10th, is cancelled.  I’ve been occupied with ongoing projects (and 1040 filings) and haven’t had enough time to prepare material for a discussion today.

That said, we are making good progress on nomenclature for several new devices for 10101b, including dialysis machines, fetal monitors and regional oximetry, and, of course, continuation of our work on events and alerts. 

We will reconvene next Wednesday, April 17, prior to the IHE PCD face-to-face meeting in Tucson the following week.

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, April 17th, and next week, Wednesday, April 24th, are cancelled, the latter due to the upcoming IHE PCD F2F meeting from April 23-25 in Tucson, AZ.

I am currently finalizing the <source-event> identifier pairs and their groupings for the following initial set of devices, based on feedback and suggestions I have received from previous discussions and correspondence:

ecg, 

ecgResp,

nbp,

spO2,

temp

invasive pressures,

eeg,

bis,

entropy, and the combined

spiro-resp-anesthesia-ventilator-nebulizer

We will resume our walk-thru of the <source-event> identifier pairs for these devices immediately after the upcoming HL7 and IEEE 11073 meetings in Montreal.

After that, we will begin our review of the proposed terminology for several new parameters and devices, including numeric observations and settings, waveforms and events and alerts.

We will likely reconvene on Wednesday, May 1st, just before the HL7 and IEEE 11073 meetings in Montreal.

[Paul Schluter]

Greetings!

Just a reminder - the RTM tcon for tomorrow, Wednesday, April 24th, is cancelled due to the IHE PCD F2F in Tucson this week.

We will have an RTM tcon on May 1 to restart/resume our walk-through and review of the <source-event> identifier pairs and related topics prior to the upcoming HL7 and IEEE 11073 meetings in Montreal the following week.

Thanks and regards,

Paul Schluter

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