1. P & P Status
Ballot Results and Plans, BICEPS Primer
Joint meeting of IEEE EMBS SC and PoCD WG and HL7 Health Care Devices (DEV) WG, 09/20/2016, Dr. David Gregorczyk, Dr. Stefan Schlichting

2. P & P Status
Ballot Results and Plans, BICEPS Primer
Joint meeting of IEEE EMBS SC and PoCD WG and HL7 Health Care Devices (DEV) WG, 09/20/2016, Baltimore, Dr. David Gregorczyk

3. Outline 1 Ballot Results P11073-20702 (MDPWS)
2 Ballot Plan Discussion P (BICEPS)
3 Access to DICOM Devices via BICEPS
4 Device Specializations
5 BICEPS Primer
P & P Status | Dr. David Gregorczyk | 09/20/2016

4. Outline 1 Ballot Results P11073-20702 (MDPWS)
2 Ballot Plan Discussion P (BICEPS)
3 Access to DICOM Devices via BICEPS
4 Device Specializations
5 BICEPS Primer
P & P Status | Dr. David Gregorczyk | 09/20/2016

5. Ballot Results P11073-20702 (MDPWS)
Number of recirculations: 2
Number of balloters: 40
Number of comments: ~230
Response rate: 80%
Approval Rate: 96 %
Abstain Rate: 6 %
Balloting started in June
Last draft finished in September
Altogether, 2 recircs
40 members balloted w/ about 230 comments
Most issues solved, such that, given a response rate of 80 %, 96 % of them approved and 6 % abstained.
The overall result is that MDPW successfuly passed the WG balloting phase and is now out for editorial revision  Lisa, may be you can give a short remark what‘s happening next?
P & P Status | Dr. David Gregorczyk | 09/20/2016

6. Outline 1 Ballot Results P11073-20702 (MDPWS)
2 Ballot Plan Discussion P (BICEPS)
3 Access to DICOM Devices via BICEPS
4 Device Specializations
5 BICEPS Primer
P & P Status | Dr. David Gregorczyk | 09/20/2016

7. Ballot Plan Discussion P11073-10207 (BICEPS)
Forming the balloting group up from now to mid/end of October 2016
Doing the initial balloting in October/November 2016
Recirulations are expected to take place until December/January
The upcoming balloting within the SDC standards triple is going to be BICEPS
Stefan will send out a balloting invitation to form the ballting group within the next few days
As soon as the balloting invitation phase is completed, we will start balloting; if everything goes well, this will be in the late October plus November
Afterwards, we will most likely have some recirculation such that I expect to be finished with the balloting in December or January
P & P Status | Dr. David Gregorczyk | 09/20/2016

8. Outline 1 Ballot Results P11073-20702 (MDPWS)
2 Ballot Plan Discussion P (BICEPS)
3 Access to DICOM Devices via BICEPS
4 Device Specializations
5 BICEPS Primer
Next item in the Agenda is a DICOM device definition that was conceived for BICEPS to allow BICEPS compliant devices to negotiate any DICOM related connection
The DICOM definition is currently not included within the BICEPS spec. We should discuss if we really need that in the or if we can in a way outsource to another project
P & P Status | Dr. David Gregorczyk | 09/20/2016

9. Outline 1 Ballot Results P11073-20702 (MDPWS)
2 Ballot Plan Discussion P (BICEPS)
3 Access to DICOM Devices via BICEPS
4 Device Specializations
5 BICEPS Primer
The next bulletpoint in the agenda is about Device Specialization. And, another time, that‘s not the stuff I am actually dealing with. Björn, would you have the honor to say something about it?
P & P Status | Dr. David Gregorczyk | 09/20/2016

10. Outline 1 Ballot Results P11073-20702 (MDPWS)
2 Ballot Plan Discussion P (BICEPS)
3 Access to DICOM Devices via BICEPS
4 Device Specializations
5 BICEPS Primer
Ok, let‘s start with the main program for my todays presentation
P & P Status | Dr. David Gregorczyk | 09/20/2016

11. Focus for today General Outline of the SDC Series Overview of BICEPS
Wording / Terms and Definitions
Participant Model
MDIB building blocks
Descriptor/State Concept
Communication Model
Service Model
Message Model
Agenda of the upcoming Webinars
P & P Status | Dr. David Gregorczyk | 09/20/2016

12. Standard Series Overview
SDC
MDPWS
Transport via Web Services
Last recirc just finished in September
~50 pages
BICEPS
Transport-independent device modelling via XML-Schema
Balloting starts soon
~400 pages
Glue
Set of rules to connect MDPWS and BICEPS
Balloting starts in the end of 2016 / beginning of 2017
~? pages
P & P Status | Dr. David Gregorczyk | 09/20/2016

13. BICEPS at a glance
Official Title: P – Domain Information & Service Model for Service- Oriented Point-of-Care Medical Device Communication
Non-normative Title: BICEPS = Basic Integrated Clinical Environment Protocol Specification
Conceptual model based on ideas of classic DIM
Semantic description of medical device capabilites and state information
Compatible with ICE architecture led by MD PnP
BICEPS does not define means to transport data over a physical layer!
P & P Status | Dr. David Gregorczyk | 09/20/2016

14. Communication Backbone (e.g., IP-based Network)
SOMDA
SOMDA = Service-Oriented Medical Device Architecture
Communication Backbone (e.g., IP-based Network)
Service
Participant
P & P Status | Dr. David Gregorczyk | 09/20/2016

15. BICEPS Wording Participant IT System Service Provider Service(s)
Service Consumer
PoC Medical Device
P & P Status | Dr. David Gregorczyk | 09/20/2016

16. BICEPS Components This picture will be the common theme for today
Here we have the main components of BICEPS
From a domain perspective, BICEPS defines a Participant Model to constitute medical device representation
The participant model comes with a descriptor/state concept that I will explain later on
From a network perspective, BICEPS provides a discovery and communication model
The discovery model itself is split up into implict and explicit discovery
The communication model is separated by a service model and message model
Any other thing that does not fit into these functional partition, is settled to that vertical column on the right
P & P Status | Dr. David Gregorczyk | 09/20/2016

17. Participant Model
P & P Status | Dr. David Gregorczyk | 09/20/2016

18. Participant Model MDIB
MDIB comprises of a description and state part
MdDescription includes a descriptor hierarchy
MdState includes a list of states, where each belongs to a descriptor
Any descriptor or state is identifiable via handles or handle references
P & P Status | Dr. David Gregorczyk | 09/20/2016

19. Participant Model (Abstract)Descriptor
Capability description of Medical Device Systems (MDSs)
Almost static
Descriptors can be described through terminologies by using coded values
P & P Status | Dr. David Gregorczyk | 09/20/2016

20. Participant Model (Abstract)State
Volatile state (measurements, settings, contextual info)
Might change frequently
Single state: w/o handle; is identifiable by the descriptor handle
Multi state: w/ handle; because not uniquely identifiable by the descriptor
P & P Status | Dr. David Gregorczyk | 09/20/2016

21. Participant Model – Descriptive Part MDIB
P & P Status | Dr. David Gregorczyk | 09/20/2016

22. Participant Model – Descriptive Part Context
P & P Status | Dr. David Gregorczyk | 09/20/2016

23. Participant Model – Descriptive Part Service Control Object (SCO)
P & P Status | Dr. David Gregorczyk | 09/20/2016

24. Participant Model – Descriptive Part Metrics
P & P Status | Dr. David Gregorczyk | 09/20/2016

25. Participant Model – Descriptive Part Alert Systems
perceive
P & P Status | Dr. David Gregorczyk | 09/20/2016

26. Communication Model
P & P Status | Dr. David Gregorczyk | 09/20/2016

27. Communication Model
BICEPS is based on Service-oriented Architecture (SOA)
In SOA, service operations are invoked to exchange messages
BICEPS Communication Model defines
Set of services
Set of messages
P & P Status | Dr. David Gregorczyk | 09/20/2016

28. Communication Model Service Model
Every service comprises a set of service operations
Every service operation is either
Request-response (RR) or
Notification (N)
Notifications may be retrievable episodically or periodically
Example service operations
GetMdib in GET SERVICE (RR)
SetContext in CONTEXT SERVICE (RR)
MetricReport in STATE EVENT SERVICE (N)
P & P Status | Dr. David Gregorczyk | 09/20/2016

29. Communication Model Message Model
Each request-response service operation exchanges two messages
Each notification service operation pushes one message to a receiver
GetMdib
Service Consumer
Service Provider
GetMdibResponse
Service Provider
MetricReport
Service Consumer
P & P Status | Dr. David Gregorczyk | 09/20/2016

30. Discovery Model
P & P Status | Dr. David Gregorczyk | 09/20/2016

31. Discovery Model Explicit Discovery
P & P Status | Dr. David Gregorczyk | 09/20/2016

32. Discovery Model Implicit Discovery
P & P Status | Dr. David Gregorczyk | 09/20/2016

33. Non-functional Requirements
P & P Status | Dr. David Gregorczyk | 09/20/2016

34. Non-functional Requirements
Patient Safety & Cyber Security Concerns
A BICEPS compliant binding is required to be able to establish
confidentiality between participants
data integrity
connection loss detection between participants that exchange messages
accountability between participants that exchange messages
Clinical Effectiveness & Regulatory Considerations
A BICEPS compliant binding is required to
support time synchronization between participants
support provision of defining QoS metrics between participants
distinguish unique messages in a sequence of messages with potential duplicates
P & P Status | Dr. David Gregorczyk | 09/20/2016

35. Webinars on 28th and 29th of September 2016 Walk through the BICEPS spec, draft 5
Learn details about the Participant Model (28th)
Versioning
State model
Context, metric and alert system attributes
Component and alert system activation concept
Learn details about the Communication Model (29th)
Service operations
Messages
Remote control
Example message transfer
P & P Status | Dr. David Gregorczyk | 09/20/2016

36. Thank you for your attention.
David Gregorczyk
Stefan Schlichting
Schlussfolie / Final Slide:
Platz für Namen, Position und Kontaktdaten des Verfassers / Room for author's name, position and contact details
Oder: Aufforderung zur Diskussion / Or: prompt a discussion
Oder: "Vielen Dank für Ihre Aufmerksamkeit." / Or: "Thank you for your attention."