Claims:We Claim:
1. A processor implemented method, comprising:
receiving, via one or more hardware processors, a request for generating a deployable application in a deployable environment, wherein the deployable application is associated with an interoperability score (202);
defining, via the one or more hardware processors, a plurality of datapoints corresponding to the deployable application (204);
dynamically generating, via the one or more hardware processors, a plurality of Application Programming Interfaces (APIs) corresponding to a database schema based on the plurality of datapoints (206);
configuring, via the one or more hardware processors, a plurality of policies based on the request for generating the deployable application in the deployable environment, wherein each policy from the plurality of policies is mapped to one or more APIs from the plurality of Application Programming Interfaces (APIs) (208);
creating, via the one or more hardware processors, one or more modules based on the database schema, the plurality of policies, the dynamically generated one or more APIs, and one or more corresponding user interface (UI) screens (210);
integrating, via the one or more hardware processors, the one or more modules into the deployable application to obtain an integrated deployable application (212); and
deploying, via the one or more hardware processors, the integrated deployable application into the deployable environment based on the interoperability score (214).

2. The processor implemented method of claim 1, wherein the step of defining, via the one or more hardware processors, the plurality of datapoints corresponding to the deployable application is preceded by determining the deployable application as a new deployable application, a homogeneous deployable application, or a heterogeneous deployable application.

3. The processor implemented method of claim 1, wherein the plurality of datapoints is defined based on a class level of the deployable application.

4. The processor implemented method of claim 1, further comprising:
executing the plurality of policies comprised in the integrated deployable application of the deployable environment based on one or more pre-defined triggers; and
validating the integrated deployable application based on the execution of the plurality of policies.

5. The processor implemented method of claim 4, further comprising determining an execution sequence of one or more mapped APIs based on the execution of the plurality of policies.

6. A system (100), comprising:
a memory (102) storing instructions;
one or more communication interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more communication interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to:
receive a request for generating a deployable application in a deployable environment, wherein the deployable application is associated with an interoperability score;
define a plurality of datapoints corresponding to the deployable application;
dynamically generate a plurality of Application Programming Interfaces (APIs) corresponding to a database schema based on the plurality of datapoints;
configure a plurality of policies based on the request for generating the deployable application in the deployable environment, wherein each policy from the plurality of policies is mapped to one or more APIs from the plurality of Application Programming Interfaces (APIs);
create one or more modules based on the database schema, the plurality of policies, the dynamically generated one or more APIs, and one or more corresponding user interface (UI) screens;
integrate the one or more modules into the deployable application to obtain an integrated deployable application; and
deploy the integrated deployable application into the deployable environment based on the interoperability score.

7. The system of claim 6, wherein the step of defining a plurality of datapoints corresponding to the deployable application is preceded by determining the deployable application as a new deployable application, a homogeneous deployable application, or a heterogeneous deployable application.

8. The system of claim 6, wherein the plurality of datapoints is defined based on a class level of the deployable application.

9. The system of claim 6, wherein the one or more hardware processors are further configured by the instructions to:
execute the plurality of policies comprised in the integrated deployable application of the deployable environment based on one or more pre-defined triggers; and
validate the integrated deployable application based on the execution of the plurality of policies.

10. The system of claim 9, wherein the one or more hardware processors are further configured by the instructions to determine an execution sequence of one or more mapped APIs based on the execution of the plurality of policies.

Dated this 12th day of April 2022

Tata Consultancy Services Limited
By their Agent & Attorney

(Adheesh Nargolkar)
of Khaitan & Co
Reg No IN-PA-1086 , Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
MODULAR AND INTEGRATIVE PATTERN-ORIENTED PLATFORM TO CONFIGURE AND GENERATE DEPLOYABLE APPLICATIONS

Applicant
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India

Preamble to the description:
The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
The disclosure herein generally relates to deployable applications generation, and, more particularly, to a modular and integrative pattern-oriented platform to configure and generate deployable applications.

BACKGROUND
In many real-world applications, due to linear dependent business processes and lack of smoothness in configuration, system architecture becomes monolithic, and it takes a lot of time to build and configure applications for multiple customers with different configuration. Sometimes static content such as logo, image, theme, font and size matter based on many requirements. Sometimes the business model changes, then the whole solution needs to be changed in between Software as a Service (SaaS), Business Process as a Service (BPasS), and Product as a Service (PasS). Due to all the tightly coupled business processes and code structures, stakeholders may not be able to customize their choices. Even after customizing the requirements, it takes a lot of effort and time to rebuild and redesign such solutions.

SUMMARY
Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems.
For example, in one aspect, there is provided a processor implemented method that implements a modular and integrative pattern-oriented platform (MIPOP) to configure and generate deployable applications. The method comprises receiving, via one or more hardware processors, a request for generating a deployable application in a deployable environment, wherein the deployable application is associated with an interoperability score; defining, via the one or more hardware processors, a plurality of datapoints corresponding to the deployable application; dynamically generating, a plurality of Application Programming Interfaces (APIs) corresponding to a database schema based on the plurality of datapoints; configuring, via the one or more hardware processors, a plurality of policies based on the request for generating the deployable application in the deployable environment, wherein each policy from the plurality of policies is mapped to one or more APIs from the plurality of Application Programming Interfaces (APIs); creating, via the one or more hardware processors, one or more modules based on the database schema, the plurality of policies, the dynamically generated one or more APIs, and one or more corresponding user interface (UI) screens; integrating the one or more modules into the deployable application to obtain an integrated deployable application; and deploying the integrated deployable application into the deployable environment based on the interoperability score.
In an embodiment, the step of defining, via the one or more hardware processors, a plurality of datapoints corresponding to the deployable application is preceded by determining the deployable application as a new deployable application, a homogeneous deployable application, or a heterogeneous deployable application.
In an embodiment, the plurality of datapoints is defined based on a class level of the deployable application.
In an embodiment, the method further comprises executing the plurality of policies comprised in the integrated deployable application of the deployable environment based on one or more pre-defined triggers; and validating the integrated deployable application based on the execution of the plurality of policies.
In an embodiment, the method further comprises determining an execution sequence of one or more mapped APIs based on the execution of the plurality of policies.
In another aspect, there is provided a processor implemented system that implement a modular and integrative pattern-oriented platform to configure and generate deployable applications. The system comprises: a memory storing instructions; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to: receive a request for generating a deployable application in a deployable environment, wherein the deployable application is associated with an interoperability score; define a plurality of datapoints corresponding to the deployable application; dynamically generate a plurality of Application Programming Interfaces (APIs) corresponding to a database schema based on the plurality of datapoints; configure a plurality of policies based on the request for generating the deployable application in the deployable environment, wherein each policy from the plurality of policies is mapped to one or more APIs from the plurality of Application Programming Interfaces (APIs); create one or more modules based on the database schema, the plurality of policies, the dynamically generated one or more APIs, and one or more corresponding user interface (UI) screens; integrate the one or more modules into the deployable application to obtain an integrated deployable application; and deploy the integrated deployable application into the deployable environment based on the interoperability score.
In an embodiment, the step of defining a plurality of datapoints corresponding to the deployable application is preceded by determining the deployable application as a new deployable application, a homogeneous deployable application, or a heterogeneous deployable application.
In an embodiment, the plurality of datapoints is defined based on a class level of the deployable application.
In an embodiment, the one or more hardware processors are further configured by the instructions to execute the plurality of policies comprised in the integrated deployable application of the deployable environment based on one or more pre-defined triggers; and validate the integrated deployable application based on the execution of the plurality of policies.
In an embodiment, the one or more hardware processors are further configured by the instructions to determine an execution sequence of one or more mapped APIs based on the execution of the plurality of policies.
In yet another aspect, there are provided one or more non-transitory machine-readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause implementing a modular and integrative pattern-oriented platform to configure and generate deployable applications by receiving a request for generating a deployable application in a deployable environment, wherein the deployable application is associated with an interoperability score; defining a plurality of datapoints corresponding to the deployable application; dynamically generating, a plurality of Application Programming Interfaces (APIs) corresponding to a database schema based on the plurality of datapoints; configuring a plurality of policies based on the request for generating the deployable application in the deployable environment, wherein each policy from the plurality of policies is mapped to one or more APIs from the plurality of Application Programming Interfaces (APIs); creating one or more modules based on the database schema, the plurality of policies, the dynamically generated one or more APIs, and one or more corresponding user interface (UI) screens; integrating the one or more modules into the deployable application to obtain an integrated deployable application; and deploying the integrated deployable application into the deployable environment based on the interoperability score.
In an embodiment, the step of defining a plurality of datapoints corresponding to the deployable application is preceded by determining the deployable application as a new deployable application, a homogeneous deployable application, or a heterogeneous deployable application.
In an embodiment, the plurality of datapoints is defined based on a class level of the deployable application.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause executing the plurality of policies comprised in the integrated deployable application of the deployable environment based on one or more pre-defined triggers; and validating the integrated deployable application based on the execution of the plurality of policies.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause determining an execution sequence of one or more mapped APIs based on the execution of the plurality of policies.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
FIG. 1 depicts an exemplary system to configure and generate deployable applications, in accordance with an embodiment of the present disclosure.
FIG. 2 depicts an exemplary flow chart illustrating a method configure and generate deployable applications, using the system of FIG. 1, in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
As described earlier, system architectures have become monolithic, and it takes a lot of time to build and configure applications for multiple customers with different configuration. Sometimes static content such as logo, image, theme, font, and size matter based on many requirements. Sometimes the business model changes, then whole solution needs to be changed in between various services type. Due to all the tightly coupled business processes and code structures, stakeholders may not be able to customize their choices. Even after customizing the requirements, it takes a lot of effort and time to rebuild and redesign such solutions. Some of challenges in existing solutions include: (i) Existing systems require more effort and time if business process changes. In traditional architectural components, if business process changed or if new business module is introduced, developers need to write code, make the possible connection changes, and rebuild and validate the solution. Sometimes it may happen that the existing application needs to be changed to integrate with other application. (ii) Due to lack of interdependent process synchronization, modularity of architecture goes down and solution becomes more monolithic with multiple dependent challenges wherein prerequisites and dependencies increase day by day when multiple business logics integrate and perform a single business requirement. (iii) Maintenance cost, and enhancement cost goes high and upgradation flexibilities becomes tougher in traditional architecture and approaches. In such scenario sometimes stakeholders need to scrap legacy application and redesign as new. (iv) Sometime user interface (UI) integration becomes cumbersome when multiple application together performs a single business need. For example, it may happen when user needs to go through different UI screen and collect information and enter that information in a single screen. (v) For further enhancement in business process, skilled resource(s) is/are required on specific technology/technologies to change code and logic(s). Such dependencies may take long time to resolve.
Embodiments of the present disclosure provide systems and methods that implement a Modular and Integrative Pattern-Oriented Platform (MIPOP) to configure and generate deployable applications. The platform as implemented by the systems of the present disclosure enables connecting multiple business components from UI screen and fulfill custom needs/requirements. It allows designated user to control very granular level of configuration from UI screen. Flexible business process with granular level configuration makes the platform smart and next generation solution. The system components help to connect required business components such as mosaic and generate single solution package that can work with UI, without UI (API based), in cloud, in on-premises, Operating System (OS) independent, other software independent, as separate solution, on top of legacy system. This type of application architecture helps stakeholders to configure the (business) process/processes without having any programming experience. Systems and methods of the present disclosure further help in providing support and maintenance groups the ability to generate solution based on custom requirement. A MIPOP system or a MIPOP module refers to a module/application configuration and generation that follows a structured or pattern-oriented architecture. For instance, any module creation that results in a deployable application using the steps of method described herein may be referred as a MIPOP system/MIPOP application. Similarly, a non-MIPOP system or non-MIPOP module refers to a module/application configuration and generation that follows any other method other than described herein. The MIPOP system and method described herein enables creation of MIPOP module or MIPOP application that can be integrated into another MIPOP module, or another MIPOP application, in one embodiment. The MIPOP system and method described herein enable creation of MIPOP module or MIPOP application that can be integrated into a non-MIPOP module, or a another non-MIPOP application, in another embodiment. The MIPOP system and method described herein enables creation of MIPOP module or MIPOP application that can be integrated as fresh module/application into a new deployable environment or an existing deployable environment, wherein such existing environment may include various operating system(s), MIPOP systems/modules/applications, and/or non-MIPOP systems/modules/applications.
Referring now to the drawings, and more particularly to FIG. 1 through 2, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
FIG. 1 depicts an exemplary system 100 to configure and generate deployable applications, in accordance with an embodiment of the present disclosure. In an embodiment, the system 100 may also be referred as Modular and Integrative Pattern-Oriented Platform (MIPOP) or MIPOP system and interchangeably used herein. In an embodiment, the system 100 includes one or more hardware processors 104, communication interface device(s) or input/output (I/O) interface(s) 106 (also referred as interface(s)), and one or more data storage devices or memory 102 operatively coupled to the one or more hardware processors 104. The one or more processors 104 may be one or more software processing components and/or hardware processors. In an embodiment, the hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is/are configured to fetch and execute computer-readable instructions stored in the memory. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices (e.g., smartphones, tablet phones, mobile communication devices, and the like), workstations, mainframe computers, servers, a network cloud, and the like.
The I/O interface device(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.
The memory 102 may include any computer-readable medium known in the art including, for example, a volatile memory, such as static random-access memory (SRAM) and dynamic-random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, a database 108 is comprised in the memory 102, wherein the database 108 comprises information related to requests received from various users (e.g., customers), wherein such requests may be related to business process(es). The database 108 further comprises information such as application type that is required to be configured, associated interoperability score, various datapoints being defined for each deployable application, associated Application Programming Interfaces (APIs), associated modules created using corresponding database schema, and the like. The database 108 or the memory 102 further stores policies, various associated triggers for the policies, information on integration of modules with an application, deployment in one or more various environments, and the like. The memory 102 further comprises (or may further comprise) information pertaining to input(s)/output(s) of each step performed by the systems and methods of the present disclosure. In other words, input(s) fed at each step and output(s) generated at each step are comprised in the memory 102 and can be utilized in further processing and analysis.
FIG. 2 depicts an exemplary flow chart illustrating a method configure and generate deployable applications, using the MIPOP system 100 of FIG. 1, in accordance with an embodiment of the present disclosure. In an embodiment, the system(s) 100 comprises one or more data storage devices or the memory 102 operatively coupled to the one or more hardware processors 104 and is configured to store instructions for execution of steps of the method by the one or more processors 104. The steps of the method of the present disclosure will now be explained with reference to components of the system 100 of FIG. 1, and the flow diagram as depicted in FIG. 2.
In an embodiment, at step 202 of the present disclosure, the one or more hardware processors 104 receive a request for generating a deployable application in a deployable environment, wherein the deployable application is associated with an interoperability score. Once the request is received, the application that is required to be configured and generated by the system 100 is checked to determine whether the deployable application is going to be a new deployable application, a homogeneous deployable application, or a heterogeneous deployable application. In an embodiment, at step 204 of the present disclosure, the one or more hardware processors 104 define a plurality of datapoints corresponding specific to the deployable application. Examples of data points for complaint management intake system (e.g., a complaint management intake application (or module) for which a request is received for configuring and deploying in an application environment) may include, but are not limited to complaint_number, complaint_date, event_date, complaint_description, etc. In an embodiment, each datapoint from the plurality of datapoints is defined based a class level of the deployable application. The steps 202 and 204 are better understood by way of following description.
As an exemplary scenario, the request for generating deployable application may be a medical device complaint management system. Such a system may include one or more processes based on complaint type, approver (e.g., authorized persons), and some of the standard procedures defined by regulatory authorities for different region and countries. All these business processes are interdependent, and therefore, it is very difficult to get a single business process as a service. In modular and integrative pattern-oriented platform (MIPOP) architecture as referred herein as system 100, all components are being generalized and modular. During the configuration of the datapoints it is evident that if database connections are obtained, system can extract the database schema and understand about contents in the database schemes (e.g., table, column, and types of data). Each business process may be using one or multiple tables and specific datapoints. MIPOP system has capability to create classes from table of the database schema. So far tables from database schema have been extracted and connected with classes (python classes). MIPOP system 100 already has its own business classes (e.g., pre-defined classes). The system 100 compares both the set of classes to determine an interoperability score. For instance, if a module A (e.g., say MIPOP based module A) needs to be connected with a module B, wherein datapoints (both dependent and independent) for module B is obtained based on all the datapoints in module A) and total number of datapoints * 100%. So, the system 100 has capability to identify basic prerequisites for each module. When different MIPOP modules are connected, system has capability to calculate the homogeneity of a module with respect to a current module. Hence, to integrate module A to module B, the calculation of data homogeneity may be obtained based on below expression:
Interoperability score (%) = (B-(AnB))/(A?B)*100%.
It is to be understood by a person having ordinary skill in the art or person skilled in the art that the above expression/equation of computing the interoperability score depicted for 2 modules shall not be construed as limiting the scope of the present disclosure. In other words, the interoperability score may be computed across modules for a given deployable application (or across applications) and deployable environment, and such expressions of computing interoperability score may vary depending upon the requirements.
In the present disclosure, complaints management in medical device is considered as a scenario for developing and configuring application(s). So, if a duplicate check module needs to be integrated with a customer existing complaint management system, then in the same way as mentioned above the interoperability score may be computed. In the duplicate check system, a device identifier, a patient contact number, patient email address, incident date, event type, etc., may be needed. If destination system has all of the above fields and datapoints ready, then the interoperability score may be computed as 100%. In some scenarios, depending upon the information available, the interoperability score may vary which may impact configuration and deployment of modules/application in a deployable environment. Therefore, the interoperability score and the difference B-(AnB) components may enable in deciding level of data integration required and accordingly required data framework may be determined. All the connections between modules, database, data mart and data lake are totally based on the interoperability calculation between modules and unique datapoints present into that specific module(s). The interoperability score may also be referred as homogeneity score, heterogeneity score, or simply score that enables determination of level of configuration, operability, and integration for communication between modules as required and further deployment of the deployable application for integration in the deployable environment. The deployable environment may either be a MIPOP environment or a non-MIPOP environment. The MIPOP environment may refer to an environment that includes module(s), applications that are configured and integrated using the MIPOP system and the steps involved in configuration and integration as being described herein (e.g., refer steps 202 till 214). The above description may be further understood by way of following description:
With respect to the architectural style, the present disclosure describes 2 types of architecture: 1) MIPOP (homogeneous system) and 2) Non-MIPOP (heterogeneous system). For example, from a deployment standpoint, a fresh MIPOP module (or MIPOP application) may be deployed to avert any other integrations or different MIPOP modules or any other non MIPOP module may be integrated. If the system is deploying a MIPOP module with a MIPOP system/MIPOP environment, then it is falling under homogeneous system. After getting the interoperability score (e.g., in this case homogeneity score), the datapoints are identified that are required to be deployed. Model classes are created, APIs are dynamically generated, and trigger objects and policy documents are created. As example, if destination application has MIPOP intake module, and a duplicate check module needs to be integrated with the MIPOP intake module, then destination application datapoints are needed to be connected to determine homogeneity score. In this case, the homogeneity score is 100% because if intake system/module is already deployed, the required datapoints to perform the duplicate check may already be present in the existing environment. Trigger object has the attribute “Trigger name”, “Trigger type”, “Trigger code”, “last modified”. Policy object has attributes “policy name”, “policy type”, “start_trigger”, “config_tree”, “module_name”, “last_modified”. Configuration are created for all of the triggers and policy for duplicate check. Once this is done, system 100 creates a deployable container/application with models, APIs, associated triggers, policies, and the like. The container/application needs to be deployed in a container management service in cloud or any virtual machine or any server. From the container, URL and port number are exposed and obtained with which the whole deployed application can be accessed.
Referring to steps of FIG. 2, in an embodiment, at step 206 of the present disclosure, the one or more hardware processors 104 dynamically generate a plurality of Application Programming Interfaces (APIs) corresponding to a database schema based on the plurality of datapoints. In the present disclosure, configuration and integration of deployable application is carried out by the system 100 which may be referred as a totally microservice based, wherein each of the microservices is connected with one or more tables. Each API consists of model class (which is already generated above), business logic that is already there in a MIPOP module, Uniform Resource Locator (URL) endpoints name that user needs to define in configuration screen, serializer that is autogenerated from each of the model class, request types, and the like. The request type such as POST, PUT, GET, DELETE, and the like may be defined by one or more users (e.g., developers or individuals configuring applications) based on the request received specific to the deployable application (or business process). Based on the above information system 100 dynamically generates APIs which would be responsible for one or more transactions (e.g., POST -fresh entry to db (database), PUT -update entry to db, GET – fetch the data from db, DELETE – delete the data from db). Business process(es) are created by the system 100 in the modules in such a modular way that it is not challenging to dynamically generate the APIs. The main reason for dynamically generating the APIs is because each and every transaction as mentioned above may consist of basic transactions and/or events. For example, if an event is complaint intake (complaint creation) the following set of APIs may be dynamically generated by the system 100.
GET – validate_device_information
GET – validate_patient_information
GET – validate_reporter_information
POST – save_complaint_data
POST – save_device_data
POST – save_patient_information
PUT – update_patient_information
PUT – update_reporter_information
POST – save_complaint_attachment
It is to be understood by a person having ordinary skill in the art or person skilled in the art that the above exemplary dynamically generated APIs shall not be construed as limiting the scope of the present disclosure.
In an embodiment, at step 208 of the present disclosure, the one or more hardware processors 104 configure a plurality of policies (e.g., also referred as policies or policy document and may be interchangeably used herein) based on the request for generating the deployable application in the deployable environment, wherein each policy from among the plurality of policies is mapped to one or more APIs from the plurality of Application Programming Interfaces (APIs). The above step of configuring the policies is better understood by way of following description. Policy document refers to set of instructions of the APIs and associated triggers. For the above module/event which is complaint intake, the system 100 defined the list of the APIs that are to be executed. Therefore, using the APIs, one or more event flows are created wherein the policies are mapped to one or more corresponding APIs and associated triggers. The configuration screen in the application comprises of all associated triggers and the dynamically generated APIs. For instance, before a complaint intake, device, patient, and reporter information need to be validated. Therefore, structure of the complaint intake policy may be described or configured as below illustrative example:
? call validate_device_information ? ? if false ?
? call validate_patient_information ? ? if false ? ? ? want to create follow-up ? if yes ? call create follow-up policy ? else
? call validate_patient_information ? ? if false ? ? ? want to create follow-up ? if yes ? call create follow-up policy ? else
? call validate_patient_information ? < check trigger> ? if True ? call save_patient_information ? ? Success? ? if yes ? call save reporter_information ? ? Success? ? if yes ? call validate_device_information ? < check trigger > ? if yes ? call save_device_information ? < check trigger > ? if yes ? call api save_complaint_data ? ? if yes ? call save save_complaint_attachment
In an embodiment of the present disclosure, the policy document (or the policies) is a dictionary tree document stored in JSON (JavaScript Object Notation) file. From a configuration screen, drag and drop may be performed by selecting appropriate policies that are formed using appropriate API(s) and triggers, resulting in a process tree. Further, a submit button is created and the JSON file is generated in a configuration directory (e.g., config directory which is stored in the memory 102). It is to be understood by a person having ordinary skill in the art or person skilled in the art that the above exemplary policies configuration and creation shall not be construed as limiting the scope of the present disclosure.
In an embodiment, at step 210 of the present disclosure, the one or more hardware processors 104 create one or more modules (also referred as module(s) and interchangeably used herein) based on the database schema, the plurality of policies, the dynamically generated one or more APIs, and one or more corresponding user interface (UI) screens. The above step of modules creation is better understood by way of following description. It is evident from above description that, the system 100 has generated or obtained database schema, model class, APIs, policy documents, and the like. User Interface (UI) components are being generalized with specific components, forms, field, button, chart, graph, data tables, and the like. The system 100 enables users (e.g., developers) to define datapoints which are already present in model class and types of UI that he/she want to render in a deployable environment when the deployable application is executed. Based on the above selection, appropriate UI components are being made available and visible into the screen. As an exemplary scenario, say the system generates a UI screen for complaint creation form (also referred as compliant creation module). There may be 4 base form (or UI components) for Complaint, Patient, Device, Reporter, and the like. For all of these fields, class is auto generated from a corresponding model class wherein property from the model class is obtained, whether it is text, dropdown, radio button, toggler button, etc. Here in this type of compliant creation module, main form may include complaint form, device form, patient form, reporter form, and the like (e.g., Mainform ? Complaint form, device form, patient form, reporter form, and the like). Similarly, sub form may include description form, malfunction form, event description form, and the like (e.g., Subform ? description form, malfunction form, event description form).
For the device, a device search form (lotnumber. Serial number, brand name) may be required and table components where the data is being loaded, needs to be returned as a result. Therefore, on selection of data from data table, device details form is auto populated. Similarly, for patient form, patient basic details, and patient result are needed in a tabular format, if these exist. For reporter form, reporter information and reporter result are needed in a tabular format, if these exist. This information is required for generating all UI frames and components which are then wrapped into a React JS project and are further placed in a docker container. Such as docker container is configured (e.g., configured by user(s)), wherein all UI components are defined in the container, including APIs, and database being defined in the container. The docker container is then deployed in a container management services in cloud (kubernetes), in one example embodiment of the present disclosure.
Once the above modules are generated, in an embodiment, at step 212 of the present disclosure, the one or more hardware processors 104 integrate the one or more modules into the deployable application to obtain an integrated deployable application. In an embodiment, at step 214 of the present disclosure, the one or more hardware processors 104 deploy the integrated deployable application into the deployable environment based on the interoperability score.
In an embodiment of the present disclosure, upon deploying/integrating the deployable application in the deployable environment, the plurality of policies comprised in the integrated deployable application of the deployable environment are executed based on one or more pre-defined triggers (also referred as associated triggers and interchangeably used herein). Based on the execution of the policies, the integrated deployable application is validated. The triggers and policies execution are described in step 210 above.
During (or after) the execution of the policies, an execution sequence of one or more mapped APIs is determined. This execution sequence enables determining whether the required APIs are executed/fired based on the pre-defined triggers (e.g., check, action, and the like). Below is an illustrative example of determining the execution sequence of the one or more mapped APIs. As example, regulatory check process for medical device complaint management is more appropriate to explain multiple policy execution and connected (or mapped) APIs. For compliant intake module, below are the steps that are to be executed in sequence which further determine execution sequence of mapped APIs, accordingly.
? Determine a reportable country
? Answer all questions for each reportable country
? Determine reportable timelines for all reportable country
? Generate template(s) for all of devices and reportable countries
? Submit the template to an authorized regulatory body (e.g., Food and Drug Administration (FDA))
Each of the steps that is defined each of the policy document is described below:
Here, policy (or policy document) may be “Determination of reportability country”
Required APIs and respective policies may include,
[POLICY— Country Determination] Get_number_of_devices_by_complaint
[POLICY— Country Determination] Get_device_mfg_country
[POLICY— Country Determination] Get_complaint_country
[POLICY— Country Determination] Get_event_country
[POLICY— Regulatory Assessment] Save_questions_by_country
[POLICY— Reportable Timelines] Create_regulatory_object
[POLICY— Reportable Timelines] Timeline_based_on_ra_object
[POLICY— Report Generation] Generate_report_based_on_ra_object
[POLICY— Template Submission] Get_configuration_by_country
[POLICY— Template Submission] Submit_template_to_ra
One or more pre-defined triggers (also referred as trigger object and interchangeably used herein) are present inside each policy which when executed, enable sequencing of mapped APIs for execution, thus sequencing the various policies. Below is an exemplary policies sequencing that also indicate mapped APIs (not shown explicitly) and their execution by way of pre-defined triggers.
? execute [POLICY— Country Determination] ? for the prerequisites of next policy ? if true ? execute [POLICY— Regulatory Assessment] ? for the prerequisites of next policy ? execute [POLICY— Reportable Timelines].
The deployable application (also referred as container and interchangeably used herein) can run in any server independent of operating system software, application software, and other libraries.
Embodiments of the present disclosure provide a MIPOP system and method, which generate solution package (e.g., application(s)/container(s)) based on custom requirements. All the functional blocks are very loosely coupled, and any of the blocks/modules can be accessed and deployed separately. It allows “Platform Designer” to generate and package an image file which contain operating system (OS), source code, all required software and library, configuration files and other required services. Altogether, that solution image (also referred as deployable application/container) can be deployed to any server and cloud. Further, the system and method of the present disclosure enable separate configurations of various modules which can be later merged into a single UI screen, thus reducing refreshing load. The system and method further allow to connect flag check(s) for each module to create dependent module(s). Dependent modules check is being done based on the datapoints that are defined. Each and every module has specific set of datapoints and models. Now during interoperability score checking, the system 100 shows all the datapoints present in the memory 102 and all other modules which are bound by the datapoints and each module dependency across modules. It is evident in application designing and deployments that data warehousing is an important aspect of modern business models because of how it improves business development. And even though data warehousing has become a common practice for many businesses, there are still some challenges that can be expected during implementation. The system and method of the present disclosure resolve many of the challenges. For instance, the MIPOP system 100 allows to configure data governance principle to ensure high quality data return throughout the data lifecycle. Database schema has all the properties of data like value, attribute, and datatype. During the interoperability score computation, the system 100 checks all the properties which ensures the data quality is maintained throughout the system, thus enabling verification of data distribution policies including the roles and accountabilities of involved internal and external entities. Since the deployable application (or container) consists of APIs, web framework, UI configuration, business logic configuration, integration services and various type of endpoints to access the application in different mode, smoother accessibility is achieved. API endpoints are defined by the system 100 to only access the metadata which is logically processed. Application endpoints are defined to access it from browser with UI and data. Endpoints are defined and configured as iframe tag so as to enable integration of deployable application over an existing application screen. End points obtained from one or more APIs, may include, but is not limited to a URL. UI iframe tag refers to an embedded code present in link (e.g., a link associated with an online video portal, such YouTube®).
Further, the method of FIG. 2 that is performed and described herein by the present disclosure, defines the modularity of the system 100 and method in the way it is implemented. For instance, each business case (or business process) can be wrapped as a single solution. To build any software and application, a database, a middleware, user interface (UI), business logic, and set of configurations are needed. However, in the present disclosure, system and method described herein have generalized structure of the deployable application and associated components (e.g., various modules) such that it can be wrapped into any single business case/logic as a solution, thus referring to a modular application. Further, the present disclosure implements the system and method as described herein which enable integration with other systems (or applications) for a given application environment. For instance, the system and method have described 2 scenarios such as a MIPOP system scenario and a Non-MIPOP system scenario.
The MIPOP scenario refers to a scenario in which configuration and integration of a deployable application (e.g., say Application X) into a system (or an application – say Application Y) that is previously configured (and/or developed) using the system 100 and the method described herein. Both application X and Y (or modules X and Y) are configured and deployed by using the system 100 and method described herein. In other words, the existing system/application (e.g., say application Y) may be configured in an environment by the system 100 and method described herein, in which an application (e.g., say application X) is deployed using the same system 100 and the same method described herein. Such configuration and integration of the deployable application may be referred as homogenous deployable application, in an embodiment of the present disclosure.
The non-MIPOP scenario refers to a scenario in which configuration and integration of a deployable application into a system (or an application or an existing system/application) that is not configured (and/or developed) using the system 100 and the method described herein. In other words, the existing system/application (e.g., say application A – non-MIPOP) may be configured in an environment by a third party (e.g., an entity A), in which an application (e.g., say application B) is deployed using the system 100 and the method described herein. Such configuration and integration of the deployable application may be referred as heterogeneous deployable application, in an embodiment of the present disclosure. Further, another scenario could be deployment of an application as a fresh deployment, where there is no existing MIPOP or non-MIPOP application deployed. The system and method of the present disclosure enable implementation of the above defined scenarios (all 3 scenarios), wherein the integration of deployable application can happen in both at frontend and at database levels.
The system and method of the present disclosure configure and integrate deployable applications in a deployable environment by following a systematic approach (e.g., the steps of method described in FIG. 2), which is pattern oriented. In other words, each module (or application) that is configured and integrated into an environment follows the same structure, database, APIs, policy, trigger, user interface, and the like.
The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g., any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g., hardware means like e.g., an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g., using a plurality of CPUs.
The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.