1. IEEE 11073 Nomenclature Status
IEEE GC at HL7, La Jolla
Tuesday, September 12, 2017
Paul Schluter

2. Topics IEEE P11073-10101b – New Observation Identifiers
IEEE P b – Events, Alerts and {REFID,disc,code} 3-tuples
IEEE P a – IDC Extensions
Terminology Coordination with other groups
NIST RTMMS {REFID,disc,code} assignment process

3. IEEE P11073-10101b Observation Identifiers
Extends ISO/IEEE Std :2004 and a-2015:
Initial Proposal
REFIDS
Definitions
UoM
Enums
WG Appr
Codes
N/A
Infusion pumps and infusion events (IHE PCD PIV and IPEC)
Ventilator mode, high-frequency ventilation, annotations
NMT Neuromuscular transmission (level of neuromuscular block) *
Finalize the WCM waveform attributes
Ventilator E:I ratio, Ipart, Epart and other terms
IHE PCD Device Management Control (DMC)
IHE PCD Real-Time Location Services (LS)
Event and Alert Identifiers (in progress)
Dialysis
Surgical and OR devices (by OR.NET at
Hemodynamic parameters using transpulmonary thermodilution and pulse contour analysis
Note: Inclusion of new terms in draft standard is contingent on timely completion.

4. IEEE P11073-10101b Events and Alerts
The existing list of ISO/IEEE :2004 MDC_EVT_ identifiers has been extended to support the IHE PCD Rosetta for Events and Alerts and ACM. Extends existing :2004 nomenclature with contributions from GE, Philips and others.
Events and alerts will be included in IEEE P b , based on earlier discussions.
Physiologic events and alerts – largely done, with par-src-evt 3-tuples. Proposed par‑src‑evt 3-tuples: phys.4n.x6i.x4b T18.par-src-evt.xls
Technical events and alerts – 800+ proposed and existing REFIDs and definitions based on GE, Philips and :2004 standard (also expecting contributions from Dräger). See RTM HTML with definitions: XSL Output.tech.4n.6xi.x4n T16.html Early par‑src‑evt 3-tuples: tech.4n.x6i.x4p T21.par-src-evt.HL7.xls

5. IEEE P11073-10101b par-src-evt 3-tuples
description
remarks
ecg-phys
MDC_ECG_HEART_RATE
MDC_EVT_LO MDC_EVT_HI
Heart rate limit exceeded
+ reuse of existing numeric identifiers + additional lo|high variants
MDC_ECG_V_P_C_CNT MDC_DEV_ARRHY ?
MDC_EVT_ECG_V_P_C_RonT
R-on-T PVC
’named’ event/alert fully identifies
– src is largely arbitrary and redundant
ecg-tech
MDC_ECG_LEAD_RA
MDC_ECG_LEAD_*
MDC_EVT_LEAD_DISCONN
Lead disconnected
+ src and evt convey useful information
vent-tech
Estimated leak flow rate ?
MDC_EVT_VENT_PAT_CIRCUIT_DISCONN
Patient circuit disconnected
’named’ event/alert fully identifies – src is unnecessary
Comments:
1. par-src-evt representation works reasonably well (par is typically required in most protocols).
2. src identifier is not consistently obvious if evt is already a strong standalone semantic concept.
Recommendations:
IEEE P b (or RTMMS) shall provide a full description with each par-src-evt 3-tuple.
Alternatively stated, one or more valid src values shall be specified with each event/alert term-row.
This is consistent with how many user and service manuals are written and would facilitate direct conversion of on-the-wire par-src-evt 3-tuples to text messages that could be displayed on the device.

6. IEEE P11073-10103a Implanted Devices Cardiac
Extends IEEE P :2012 Implanted Devices Cardiac
New IDC term codes, extending IEEE P :2012.
Notifications (‘alerts’) are largely complete with the definition of 14 standardized notification categories that convey publically- disclosed vendor-specific notifications. [This reflects the sometimes significant differences in the underlying vendor design of these devices.]
Several dozen new terms and term-sets have been reviewed by the Heart Rhythm Society (HRS) and will be included in the standard.
The IDCO WG meets weekly on Fridays at 10:00 AM Central (US).

7. http:/all vendor platform
Masterlayout
© BIOTRONIK
Let’s now talk about details and open issues of the ISO/IEEE
Implantable Devices - Cardiac - (IDC) Nomenclature
Device Programmer
Device Programmer
2017 More systems, more interfaces
IHE EPRC-IE
IHE IDCO
IDCO adapter
CDISC
Home environment
Patient portal
vendor platform
FDA GUDID
Internet ((
FDA CDRH
UDI
ACC NCDR
Device management, Cardiology Module, Clinic EMR
IHE RCS-EP ?
IHE EPRC-IE ?
IHE IDCO
Practice/Hospital electronic health record
Vendor web services

8. IDC Nomenclature The scope of the next version of the standard
The scope of the existing IDC nomenclature V 1.0 (ISO approved: 2014)
The discrete terms necessary to convey a clinically relevant summary of the information obtained during a device interrogation … summary interrogation information from all vendor devices
The extended scope of the IDC nomenclature V 1.1
Scope of V1.0 above plus
more remote monitoring information
notifications (‘alerts’)
new device types (S-ICD,…), new vendors
more implantation related information (DFT-Test?)
new coded values (e.g. all the new episode types)
if possible, EGM

9. Coordination Topics
IHE PCD MEM-LS and and PHD Location Info
MEM-LS will likely reference home dwelling names in IEEE ISO/IEEE “Independent Living Activity Hub”.
MEM-LS currently defines GPS, [X, Y, Z] and uses HL7 ‘named’ room locations for in-building care facilities.
Extensions to ISO/IEEE Annotated ECG (aECG)
The proposed SCP-ECG V3.0 (revision to EN 1064) project may required additional ECG terms, and these can be added to the existing term groups aECG.

10. Interesting Topics and Next Steps ...
Physiologic Events and Alerts
ECG ST lead-group alerts (named or generic groups)
Technical Events and Alerts
Alert distribution scope:
local device display (only)
local area network to other devices and systems
enterprise network to gateways, alarm reports, biomed lab and EMR
Next steps ...
Preliminary assignment of event/alert {REFID,disc,code} 3-tuples
After IEEE and IHE PCD review, use NIST RTMMS to assign numeric codes.

11. IEEE 11073 and NIST RTMMS Terminology Process
BACKGROUND SLIDES

12. New Term REFID and Code Assignments
Background for this discussion, motivated by the desirability of assigning numeric codes at the earliest possible time.
Use the NIST RTMMS as the authoritative numeric code validator (and generator) for new terms to guarantee non-overlap between multiple organizations, e.g. IEEE PoCD, IEEE PHD, IHE PCD Rosetta, PCHA/Continua, MDPnP, OR.NET and others.
If the assigned Reference ID, Disc, Part::Code is discarded during balloting, it is retired as a “zombie term” and cannot be re-used.
Terms that are assigned codes must have complete definitions, UoMs, enum values and other information when they are submitted as an Excel worksheet, formatted exactly as it would appear in the published standard.
Is this a good idea?
Yes, if we can keep the number of “zombie terms” to a small number (e.g. < 1 to 3% of new terms defined).
No, we could end up with a ‘free-for-all’ if this is uncontrolled without any degree of editorial review and curation.

13. Code and Term Assignment Process
 Proposed 0^MDCX terms that have not been approved by a recognized working group, let alone by the larger IEEE community.
 Provisional terms that have been approved by a recognized working group (e.g. IEEE PoCD, PHD, IHE PCD Rosetta, PCHA/Continua, MDPnP, OR.NET and others) may have numeric codes assigned to them prior to IEEE balloting. The status of each term (proposed, provisional, published) will be maintained on the NIST RTMMS.
 Published terms are those that have been balloted, approved and published as an IEEE standard.
Note: If a provisional term is rejected during IEEE balloting, the { Reference ID, Disc, Part::Code } 3-tuple will be retired as a “zombie term” and the Part::Code shall not deployed in messages nor recycled for use with another term in the future (enforced by NIST test tools). Proposed and provisional terms are subject to change and are not final until published in an IEEE standard.
CF_CODE10^REFID
RTMMS Status
Meaning
0^MDCX_term
 Proposed
Proposed term
nnnnn^MDC_term
 Provisional
Assigned numeric code (could become zombie)
 Published
IEEE Balloted, Approved and Published

14. Additional Required NIST RTMMS Capabilities
Clearly indicate { proposed, provisional, published, zombie } status for all terms.
Maintain list of { published ∪ provisional ∪ zombie } terms, from which new provisional REFIDs and Part::Codes shall not be drawn.
Essential First Steps ...
The IEEE PHD WG should copy or move their terminology {REFID,disc,code} 3-tuples and definitions to NIST RTTMS so that it can function as the single authoritative numeric code generator.
The entire set of all {REFID,disc,code} 3-tuples should be verified against other vendor databases to ensure correctness.