For a couple of recent months, I was working on an interesting project. That was implementation of SAP MDG Custom Objects for relatively complex data model of EUDAMED UDI (European Database on Medical Devices). The main requirements were multi-records processing with data export/import via excel spreadsheets with highlighted changes and approval workflow with parallel tasks. The result looks like below:
First, a few words about UDI:
Unique Device Identification (UDI) helps identifying medical products and their published master data in public databases. In short, if medical device producer wants to sell a product on some market (US, EU, UK, Korea, etc.) the product must be registered in corresponding country/union database. The databases can be accessed by anyone and most attributes of the registered medical devices can be found there (some data is registered but not openly published).
EU (EUDAMED):
https://webgate.ec.europa.eu/eudamed-help/?lang=en
US (GUDID):
https://www.fda.gov/medical-devices/unique-device-identification-system-udi-system/global-unique-dev...
Australia (AsuUDID):
https://www.tga.gov.au/how-we-regulate/manufacturing/manufacture-medical-device/unique-device-identi...
The attributes to be registered depend on country/organization requirements and in practice some of them are common across the databases, some values can be mapped between them, and others are specific for the particular database implementation. So, the idea was to create “Common Device Record” which is then used as base when publishing the device in given target database (by enhancing and mapping the values to specific external database requirements).
The whole architecture looks like below and in this blog I will just focus on the highlighted part:
Attributes of the medical devices does not match SAP material master fields (apart from material number and EAN), moreover the relation between material master and UDI is not 1:1 but rather 1:n (like material to EAN relation), so instead of extending already heavy MDG-MM model the solution has been implemented with MDG Custom Objects.
Data Model
As shown in Picture 2 the UDI records are maintained on different levels (Central record, GUDID UDI, EUDAMED UDI, EUDAMED Basic-UDI) logically they are all Medical Device data records, therefore a single custom MDG model has been used for all of them with several entities of type 1 (Business Objects). To have better control and easier access to active area the “Reuse” option has been used.
In case of EUDAMED records we have two kinds of Type 1 entities: “Basic UDI-DI records” (BUDI) and “UDI-DI records” (UDI-DI). In both cases they have some related sub-tables and lookup tables (entities of type 4 and 3).
Quick explanation: BUDI records (typical for EUDAMED) are grouping UDI-DI records (relation 1:n) – more details about that you can find on EUDAMED website.
Search and single record display
Even though there was no need to create workflow for single record processing the SP configuration still needed to be done – it is used for the records search and display.
The search result list has been enhanced with current record status and synchronization icon (showing state of record replication to EUDAMED database)
The EUDAMED UDI-DI records differ depending on “applied legislation” (which is an attribute of linked Basic UDI-DI), that means for one type some of the fields are relevant and for the other type not. While data model was prepared to hold all the attributes, when displaying a single Medical Device record just the relevant fields should be shown.
That’s the right place for implementation of Context Based Adaptation (CBA), in result the records are shown with layout configured for assigned legislation. Below a sample view of Legacy Device (MDD legislation) and Regulation Device (MDR) record:
And the MDG change request CBA context enhanced with the new dimension:
The CBA context is set in application controller, not in the UIBB feeder class like suggested in CBA WIKI tutorial – the second option does not work correctly with “lazy loading”.
I had some fun with modeling multilingual fields of the UDI-DI records. In EUDAMED the texts are sometimes translatable sometimes not. The interesting attribute is “Trade Name”:
Which means the language specific texts in this case are not linked to each other (they are not translations but just collection of different texts in multiple languages). I don’t know how such texts are stored and updated on EUDAMED side but “locally” there was made assumption that for given device there will be just one or 0 particular text per language.
Technically all the texts in (reuse) active area are stored in single texts table (with GUID and language as a key), however in MDG model they are split into separate entities depending on the text type. To display the translations, buttons have been added to the UI, they trigger popups with details:
The buttons are hidden dynamically in case there are no texts or just English translation exists.
Additionally, there is a link created for BUDI record – it opens related BUDI details:
Multi record configuration
As mentioned at the beginning it was required to implement multi-record change request with highlighted changes. Fortunately, all the dialog tasks are just approvals (read-only mode) that eliminated the need of enhancing the UIBBs with add/delete functions – which would be a bit tricky especially for multilingual texts – anyway the FPM configuration of all UIBBs works on wires and standard MDG wire classes – so it is “edit-mode ready”.
As you can notice above, for new record there is temporary number generated (starting with $) it is replaced later with final record ID in access class during activation. Like in single processing also here have been implemented “dynamic buttons” for displaying multilingual texts details. All the UIBBs use common feeder class inheriting from standard CL_USMD_MC_FEEDER_LIST where just the three methods below have been redefined:
As the dialog steps are read-only all the validations and derivations have been implemented in “starting application” described below.
Records maintenance application
The logic of this application is simple:
This is achieved with the first three buttons below, additionally the last (toggle) button changes displaying mode of sub-tables
For export/import of XLSX files the standard ABAP classes have been used: CL_CMCB_EXCEL_2007 and CL_FDT_XL_SPREADSHEET. The first one - for exporting - has rather limited formatting options (still they allow to create multiple sheets and, and use of four cell formatting styles), so to achieve really nice looking XLSX something as abap2xlsx library should be used, but for the project the CL_CMCB_EXCEL_2007 was sufficient.
As mentioned before, all the validations are triggered in the "maintenance application" because later the data in the workflow is read-only. Like in the workflow steps the changes are highlighted in yellow, additionally key fields are in blue and "to be deleted" rows are marked with red color.
Another requirement was that potential processors assigned to corresponding validation/approval workflow tasks should be selected by the CR creator (from users with an assigned corresponding role). This, together with 4-eyes principle check has been implemented with collapsible list like below.
SAP MDG Central Governance is known from performance issues, (especially MDG-M for materials with many Plants/Sales Orgs.). Here the model is no so complex, however we have multi-record CRs.
Below are shown time measurement results of three operations (MDG 9.2 on Hana DB - test system):
CRs with more than 400 records caused time outs when opened.
Below CR with 376 records:
MDG Custom Objects can be successfully used to process multi-record change requests for relatively complex objects. Features like highlighting of changes, context based adaptations with enhanced dimensions or wiring UIBBs work as well pretty good.
There are some performance issues, however up to 100 objects in CR the lags are acceptable.
With custom coding a “maintenance application” can be created which exports/imports data to/from XLSX file, validates the imported data and triggers MDG CR. This requires some development effort but once done it can be easily used as template for another MDG Custom Objects implementations.
Picture 1 - Implementation results
First, a few words about UDI:
Unique Device Identification (UDI) helps identifying medical products and their published master data in public databases. In short, if medical device producer wants to sell a product on some market (US, EU, UK, Korea, etc.) the product must be registered in corresponding country/union database. The databases can be accessed by anyone and most attributes of the registered medical devices can be found there (some data is registered but not openly published).
EU (EUDAMED):
https://webgate.ec.europa.eu/eudamed-help/?lang=en
US (GUDID):
https://www.fda.gov/medical-devices/unique-device-identification-system-udi-system/global-unique-dev...
Australia (AsuUDID):
https://www.tga.gov.au/how-we-regulate/manufacturing/manufacture-medical-device/unique-device-identi...
The attributes to be registered depend on country/organization requirements and in practice some of them are common across the databases, some values can be mapped between them, and others are specific for the particular database implementation. So, the idea was to create “Common Device Record” which is then used as base when publishing the device in given target database (by enhancing and mapping the values to specific external database requirements).
The whole architecture looks like below and in this blog I will just focus on the highlighted part:
Picture 2 - UDI-DI data architecture
Attributes of the medical devices does not match SAP material master fields (apart from material number and EAN), moreover the relation between material master and UDI is not 1:1 but rather 1:n (like material to EAN relation), so instead of extending already heavy MDG-MM model the solution has been implemented with MDG Custom Objects.
MDG Implementation overview
Data Model
As shown in Picture 2 the UDI records are maintained on different levels (Central record, GUDID UDI, EUDAMED UDI, EUDAMED Basic-UDI) logically they are all Medical Device data records, therefore a single custom MDG model has been used for all of them with several entities of type 1 (Business Objects). To have better control and easier access to active area the “Reuse” option has been used.
In case of EUDAMED records we have two kinds of Type 1 entities: “Basic UDI-DI records” (BUDI) and “UDI-DI records” (UDI-DI). In both cases they have some related sub-tables and lookup tables (entities of type 4 and 3).
Quick explanation: BUDI records (typical for EUDAMED) are grouping UDI-DI records (relation 1:n) – more details about that you can find on EUDAMED website.
Search and single record display
Even though there was no need to create workflow for single record processing the SP configuration still needed to be done – it is used for the records search and display.
Picture 3 - Records search
The search result list has been enhanced with current record status and synchronization icon (showing state of record replication to EUDAMED database)
The EUDAMED UDI-DI records differ depending on “applied legislation” (which is an attribute of linked Basic UDI-DI), that means for one type some of the fields are relevant and for the other type not. While data model was prepared to hold all the attributes, when displaying a single Medical Device record just the relevant fields should be shown.
That’s the right place for implementation of Context Based Adaptation (CBA), in result the records are shown with layout configured for assigned legislation. Below a sample view of Legacy Device (MDD legislation) and Regulation Device (MDR) record:
Picture 4 - Records details with CBA applied
And the MDG change request CBA context enhanced with the new dimension:
Picture 5 - CBA context with new dimension
The CBA context is set in application controller, not in the UIBB feeder class like suggested in CBA WIKI tutorial – the second option does not work correctly with “lazy loading”.
I had some fun with modeling multilingual fields of the UDI-DI records. In EUDAMED the texts are sometimes translatable sometimes not. The interesting attribute is “Trade Name”:
Picture 6 - EUDAMED Business Rule for multiple languages
Which means the language specific texts in this case are not linked to each other (they are not translations but just collection of different texts in multiple languages). I don’t know how such texts are stored and updated on EUDAMED side but “locally” there was made assumption that for given device there will be just one or 0 particular text per language.
Technically all the texts in (reuse) active area are stored in single texts table (with GUID and language as a key), however in MDG model they are split into separate entities depending on the text type. To display the translations, buttons have been added to the UI, they trigger popups with details:
Picture 7 - Translations pop-up
The buttons are hidden dynamically in case there are no texts or just English translation exists.
Additionally, there is a link created for BUDI record – it opens related BUDI details:
Picture 8 - Link to BUDI record
Multi record configuration
As mentioned at the beginning it was required to implement multi-record change request with highlighted changes. Fortunately, all the dialog tasks are just approvals (read-only mode) that eliminated the need of enhancing the UIBBs with add/delete functions – which would be a bit tricky especially for multilingual texts – anyway the FPM configuration of all UIBBs works on wires and standard MDG wire classes – so it is “edit-mode ready”.
Picture 9 - Multi-record Change Request with highlighted changes
As you can notice above, for new record there is temporary number generated (starting with $) it is replaced later with final record ID in access class during activation. Like in single processing also here have been implemented “dynamic buttons” for displaying multilingual texts details. All the UIBBs use common feeder class inheriting from standard CL_USMD_MC_FEEDER_LIST where just the three methods below have been redefined:
Picture 10 - Overridden inherited methods of UIBB feeder class
As the dialog steps are read-only all the validations and derivations have been implemented in “starting application” described below.
Records maintenance application
The logic of this application is simple:
- Export selected existing EUDAMED data and/or data to be created from “Common Device Record” into excel,
- After adjustments import the same excel file (showing changes in colors)
- Run validations and trigger new Change Requests with requested changes
This is achieved with the first three buttons below, additionally the last (toggle) button changes displaying mode of sub-tables
Picture 11 - Action buttons of maintenance application
For export/import of XLSX files the standard ABAP classes have been used: CL_CMCB_EXCEL_2007 and CL_FDT_XL_SPREADSHEET. The first one - for exporting - has rather limited formatting options (still they allow to create multiple sheets and, and use of four cell formatting styles), so to achieve really nice looking XLSX something as abap2xlsx library should be used, but for the project the CL_CMCB_EXCEL_2007 was sufficient.
As mentioned before, all the validations are triggered in the "maintenance application" because later the data in the workflow is read-only. Like in the workflow steps the changes are highlighted in yellow, additionally key fields are in blue and "to be deleted" rows are marked with red color.
Picture 12 - Validations results and highlighted changes in maintenance application
Another requirement was that potential processors assigned to corresponding validation/approval workflow tasks should be selected by the CR creator (from users with an assigned corresponding role). This, together with 4-eyes principle check has been implemented with collapsible list like below.
Picture 13 - Submit pop-up with potential processors assignment
Performance
SAP MDG Central Governance is known from performance issues, (especially MDG-M for materials with many Plants/Sales Orgs.). Here the model is no so complex, however we have multi-record CRs.
Below are shown time measurement results of three operations (MDG 9.2 on Hana DB - test system):
- Upload of the data from XLSX (all validations are triggered here)
- Submit of new CR from the “Record maintenance application” (this is done with MDG GOV API)
- Opening the created CR from “My Change Requests” (all UIBBs expanded)
Picture 14 - Performance measurement results
CRs with more than 400 records caused time outs when opened.
Below CR with 376 records:
Picture 15 - Stress test CR with many records
Conclusions
MDG Custom Objects can be successfully used to process multi-record change requests for relatively complex objects. Features like highlighting of changes, context based adaptations with enhanced dimensions or wiring UIBBs work as well pretty good.
There are some performance issues, however up to 100 objects in CR the lags are acceptable.
With custom coding a “maintenance application” can be created which exports/imports data to/from XLSX file, validates the imported data and triggers MDG CR. This requires some development effort but once done it can be easily used as template for another MDG Custom Objects implementations.
- SAP Managed Tags:
1 Comment
