Page tree
Skip to end of metadata
Go to start of metadata


What are the rules and guidelines for a SERVICE PROVIDER that supports external control services, and when a SERVICE CONSUMER of a different safety class wants to invoke the control? (see Meeting Logs & Notes - 2020.06.23

David Gregorczyk

Peter Kranich

Notes from 2020.06.30 Discussion


  • A patient with a COVID-19 infection is housed in an isolation room. The nurse needs to change the alarm limits for the heart rate on the PoC devices in the room. A central station outside of the isolation room allows the nurse to change the alarm limits at the devices remotely without entering the isolation room. The PoC devices as well as the central station are classified in different medical device classes.
  • A ventilator, a patient monitor and a CDS analytics system are part of a closed loop application. The CDS analytic system analyses the vital signs parameters from the patient monitor (e.g. SpO2, respiration rate, etc.) and automatically adjusts the ventilation parameters (e.g. airway pressure, tidal volume, etc.) at the ventilator.

SDC Trust Relationship & Safety Classification

This paragraph describes the current aspects of the  trust relationship, participant key purpose (PKP), and safety classification in SDC:

  • Devices authenticate other devices (SamDs included here) by signed X.509 certificates and trusted root or intermediate certificates.
    Trust relationship between SDC Participants is built up from Public Key Infrastructures and mutual authentication. That means, every SDC Participant is equipped with a public and private key, and the public key is digitally signed by a trustworthy certification authority (e.g. Dräger possesses it’s own root certificate signed by VeriSign and hence trusts every other device whose public key has been signed by Dräger’s root). When two SDC Participants decide to communicate with each other, they exchange their certificates and verify the digital signature against an entity they trust – so far, Dräger only trusts in Dräger signatures. But, it’s conceivable if not inevitable to trust other entities in the future, namely when Dräger devices are supposed to communicate with devices of other vendors. By then there has to be another third-party that both devices from different vendors trust in (maybe because the third-party is known to perform exhaustive technical and process verifications – it hasn’t been detailed yet).

  • Devices authorize other devices based on Participant Key Purposes (PKP). Those are encoded as Extended Key Usage (EKU) OIDs as part of the X.509 certificates shipped with a device.
    For example, if an SDC Service Provider fulfills an Alarm Provider and External Control Provider PKP, and those PKPs are signed appropriately, then an SDC Service Consumer knows that any interaction with the SDC Service Provider is safe as a PKP claims conformance with a set of rules the SDC Service Provider is obliged to fulfill prior to get a trusted digital signature. The same applies for consumer PKPs attached to an SDC Service Consumer’s certificate.

  • Last but not least there is the concept of a SafetyClassification. The SafetyClassification is an enumerated value that allows 4 different levels of safe usage: Informational, MedA, MedB, and MedC (similar but not equal to software classes from IEC 62304). Depending on where to find a safety classification in the MDIB tree, a different interpretation of the classification applies. For example, a safety classification attached to a metric describes the metric’s permissible usage for informational purpose (Inf), for display purposes to support patient and device monitoring (MedA), in clinical functions with nonserious injuries (MedB) or in clinical functions with serious injuries (MedC). For remote control operations, the safety classification is the required safety classification of the consumer, i.e. it pertains to the risk related to erroneous or inadvertent invocation.
    Example: SDC consumer device is MedB. SDC provider device is MedC and provides operations OP1 : MedA, OP2 : MedB, and OP3 : MedC. The consumer is only allowed to invoke OP1 and OP2 but not OP3!

Questions & Answers

  1. Are the regulatory aspects regarding external device control considered in the standard?
    1. (Stefan) this situation would be addressed in the PKP 11073-10703 external control ...
      1. If Safety classification C for a given PROVIDER operation, 
      2. May have to link to the particular standard for that device (60601-2-x)
      3. Certificate would indicate at connect time

  2. Is there a requirement for a confirmation when the user invokes a remote operation on another device? If yes, does the user have to confirm on the local device or on the remote device?
    1. The confirmation requirement would be considered in the risk management for the CONSUMER system
    2. For a unified concept, the confirmation should always be performed at the local device (CONSUMER)
    3. In some application, double confirmation may be required

  3. Can the CONSUMER provide device classification in service invocation? 
    1. Considered but didn't want to push this responsibility back on the PROVIDER system
    2. CONSUMER has to consider the device classification of the operation

  4. Can a Class B device invoke operations on a Class C?
    1. A Class B device may invoke operations on a Class C device which are classified as A or B - this should be accepted from a regulatory perspective
    2. Technically, there is nothing that prevents a Class B device to invoke a Class C operation. However, the Class B device would probably not get regulatory approval if it claims this in the regulatory approval request.

  5. Are there any considerations regarding the different national medical device regulations (FDA in the US, EU MDR in Europe, etc.)?
    1. ...

  6. Does the standard define how remote operation calls are logged by the CONSUMER / PROVIDER? If yes, which information must be logged by the CONSUMER / PROVIDER?
    1. Requirements in standard for both CONSUMER and PROVIDER logging of operations
    2. What is the information is recorded?  
      1. General requirements in -10700 Base PKP
      2. Specific requirements also in -20702 WS Profile
    3. At MDIRA/ICE could also be supported by a Data Logger actor or syslog (see separate topic)
    4. NOTE:  AAMI 2700-2-1 Data Logger standard out for review (CD ballot)

  • Peter Kranich Craft the set of questions / examples 
  • Stefan SchlichtingDraft responses to the above questions / scenarios 
  • Stefan Schlichting Previous FDA discussions about identifying "product code" and classification for these devices - send OR.NET input 
  • Todd Cooper Link this discussion to the SES MDI White Paper sections