IEEE PKP Update

IEEE PKP update2021-09-21

David Gregorczyk & Björn Andersen @35th Annual Plenary & Working Group Meeting, Virtual Venue

IEEE PKP Update

35th Annual Plenary & Working Group Meeting,September 20-24, 2021 • Virtual Event

• SDC standards family recap

• Base PKP status

• Metric PKP status

• Alert PKP and External Control PKP status

21st of September 2021, Slide 2

Agenda

35th Annual Plenary & Working Group Meeting,September 20-24, 2021 • Virtual Event 21st of September 2021, Slide 3

SDC standards family recap

Nomenclatureprovidessemantics for communicated data by introducing a mapping of concepts to unambiguous codes

Core standards provide technical basis for secure and interoperable exchange of medical data

Device Specializations provide• Detailed specification of different types of devices

including containment trees• Modular containment tree building blocks that can be

re-used across different specializations• Optional but extremely helpful to enable vendor

independent interoperability by standardized device representations

PKP standards provide • Technical design and process requirements to ensure

safe execution of clinical functions in an SDC system• Assignment of responsibilities to allow for safe

operation of devices in an SDC system• Support market approvals for individual devices as

components participating in an SDC system

35th Annual Plenary & Working Group Meeting,September 20-24, 2021 • Virtual Event 21st of September 2021, Slide 4

Base PKP initial ballot round I


• Decision for recirculation

• Work out low hanging fruits(typos, obvious flaws) beforeescalating discussions to the SDC Subgroup for resolution

• Recirulation is planned forNovember ’21

• Ticket system: https://sourceforge.net/p/opensdc/p11073-10700-pre-ballot/


Base PKP initial ballot round II

https://sourceforge.net/p/opensdc/p11073-10700-pre-ballot/


• The P11073-10701: Ballot group forming hasstarted

• If you would like to participate in the balloting of Metric PKP, you must enroll as a member of the ballot group by 08 Oct 2021, 23:59 UTC-12

• Just as of the 21st of September (that istoday!), the document has been sent to theMEC

• Ticket system: https://sourceforge.net/p/opensdc/p11073-10701/


Metric PKP ballot group forming and MEC

https://sourceforge.net/p/opensdc/p11073-10701/


• Alert PKP: P11073-10702

• Still at the start line (content gathering still active)

• https://sourceforge.net/p/opensdc/p11073-10702-content-gathering/

• Timeline planning: first draft by end of Q1/22

• External control PKP: P11073-10703

• Scope is defined

• No definitive requirements captured

• Timeline planning: first draft by end of Q2/22


Upcoming Alert PKP and External Control PKP

https://sourceforge.net/p/opensdc/p11073-10702-content-gathering/

Björn AndersenDavid Gregorczyk

Thank you!


Challenge on the regulatory pathway:

Traceability of requirements, from use case and design documents down to technical specifications

24th of September 2021, Slide 9

Requirements Traceability / Interoperability

The system shallsynchronize time

Provide a clock objectin the MDIB

Provide changereports

Implement NTP client

Consider risks w.r.t. failed sync

The SDC provider shallnotify clockderivations

The SDC consumershall periodically check

the providers clock


• Word documents or PDF files do not support machine-processingand hence aren‘t appropriate to link requirements to one another


The challenge: it‘s all about the format

The system shallsynchronize time

Provide a clock object in the MDIB

Provide change reports

Implement NTP client

Consider risks w.r.t. failed sync

The SDC provider shallnotify clock derivations

The SDC consumer shallperiodically check the

providers clock

?


• Moreover, it‘s nearly impossible to check if a text is really a requirement or a note, or if it is shall, should or may

• Solution: make documents available in a format that is annotatedand parsable, e.g. ReqIF, from which other output can begenerated


Machine-readable sources to the rescue


• … there is no definitive requirements format specified that is valid forall standardization commitees (ISO, IEEE, IHE, HL7, …)

• How to overcome this problem?• This is a Current State / Future State problem• Today –✓ Define a ReqIF model that supports the SDC/PKPs & SDPi✓ Use simple standard-specific / repurposed tooling

• Future –✓ Define a requirements metamodel for all Garden standards✓ Adapt for each component standard✓ Develop tooling that will support fully automated traceability

& coverage from the specification to the product interface

Note: ISO Online Standards Development (OSD) may support


But wait…


• We agreed on a ReqIF format that allows us to specifyrequirements in a common way and by that allows for „easily“ linking between specifications (e.g., HF Surgery DevSpec→ModSpec→Metric PKP → Base PKP)

• It‘s publicly available:

definitions · master · sdc-suite / reqif · GitLab

• Unfortunately, this only covers the tip of the iceberg

• The format isn’t well integrated into the IEEE ecosystem nor is itknown to any other standardization organization

➔More investigation and coordination needed


Approach for PKPs and PocSpec

https://gitlab.com/sdc-suite/reqif/-/tree/master/definitions

Date post:	28-Mar-2022
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

IEEE PKP Update

Documents