Fig. 12.1
The complete digital patient model provides a variety of views, or representations, of the patient depending on the specific tasks, requirements or areas of interest of the end-user
A Precision Surgery View may be utilized to enhance surgical guidance for improved safety and efficiency; a Surgical Workflow View may be employed in the Operating Room to optimize the surgical process; a Physiological View would optimize the process of patient monitoring; a Decision Support View would provide assistance in the selection of best treatments; a Biomarkers and Imaging View could be employed to help gain a deeper understanding of disease fundamentals, e.g. oncology; and, a Disease/Epidemiology View may be utilized to pool large numbers of DPMs to gain insight into patient populations and epidemiology (Model-based Medical Evidence [MBME]).
A few points, from the Chaps. 3 through 11, will serve as reminders of the complexity of creating an ITS-PM for HCC: (1) the treatment spectrum for HCC extends from one extreme to the other, i.e. from transplantation of the entire liver to targeted therapy with Sorafenib at the molecular level; (2) HCC is often treated without tissue diagnosis, i.e. with radiologic and biochemical confirmation; (3) the understanding of the hepatic microenvironment and its relationship to HCC is evolving; and, (4) there are limitations in the RCTs comparing different minimally invasive treatments and/or their roles in down-staging of advanced cases. The science behind our treatment choices can be thought of as being in a state of evolution. There are differences of opinion, as well as newly emerging evidence, concerning many facets of HCC and its treatment. Therefore, the ITS-PM system under development must be sufficiently broad, sensitive, and flexible enough to help organize and make sense out of the widespread and disparate information available. It is hoped that the ITS-PM will help fill the gaps of our knowledge by incorporating and integrating new information into the existing fund of medical knowledge and help us make the best decisions for our patients, even when medical knowledge is incomplete. As in any medical decision support system, it is important to emphasize that the role of the ITS-PM is not to replace the physician in decision making, but rather to assist the decision making process, such as at a hospital’s Tumor Board.
In summary, the development of the ITS-PM for HCC will provide a comprehensive system to identify and then determine the relative value of the wide number of variables: (1) factors reflecting clinical assessment of the patient including functional status, liver function, degree of cirrhosis, and comorbidities; (2) factors reflecting tumor biology at a molecular, genetic, and anatomic level; (3) factors reflecting tumor burden and individual patient response; and (4) factors reflecting medical and operative treatments and their outcomes. If this project is successful, it can serve as a prototype for IT solutions to assist in the diagnosis, research, and management of other cancers as well as non-malignant diseases.
12.1.1 ITS-PM: Organization and Architecture
12.1.1.1 Requirements for an ITS-PM
The first task is to consider and define the requirements for an IT approach for PPPM with respect to HCC. It is probably best if we divide this task into broad categories, each of which will have its own focus, data types, tasks, and solutions.
Reference Model for Open Distributed Processes and Service-Oriented Architecture
It is imperative that comprehensive and cohesive hardware and software architecture is provided for the ITS-PM to allow each section to function independently, while synchronized and in communication with each other section. Reference Model for Open Distributed Processing (RM-ODP) and Service-Oriented Architecture (SOA) (which may be considered a related subset of RM-ODP and is perhaps more widely known) are standards, methodologies, or approaches to enterprise system development that could help fulfill the necessary requirements.
RM-ODP is an International Organization for Standardization (ISO) standard that gives a solid basis for describing and building widely distributed systems and applications in a systematic way. Emphasis is placed on the need to build such systems with evolution in mind by identifying the concerns of major stakeholders and then expressing the design as a series of linked viewpoints representing these concerns. Each stakeholder can then develop an appropriate view of the system with a minimum of interference from the others [1] (Fig. 12.2) (Table 12.1).
Fig. 12.2
A graphic representation of the points of view utilized in the reference model for open-distributed processes. (Adapted from [1])
Table 12.1
Viewpoints utilized in the reference model for open-distributed processes. (Adapted from [1])
Viewpoints for reference model for open-distributed processes |
|---|
The enterprise viewpoint focuses on the organizational situation in which the design activity is to take place. It concentrates on the objectives, business rules, and operational policies that need to be supported by the system being designed. |
The information viewpoint concentrates on the modeling of the shared information manipulated within the enterprise of interest. By providing a common model that can be referenced from throughout a complete piece of design, we can ensure that the same interpretation of information is applied at all points. |
The computational viewpoint is concerned with the development of the high-level design of the processes and applications supporting the enterprise activities. It uses the familiar tools for object-oriented software design, expressing its models in terms of objects with strong encapsulation boundaries, interacting at typed interfaces by performing a sequence of operations (or passing continuous streams of information). |
The engineering viewpoint tackles the problem of diversity in infrastructure provision; it gives the prescriptions for supporting the necessary abstract computational interactions in a range of different situations. It thereby offers a way to avoid lock-in to specific platforms or infrastructure mechanisms. |
The technology viewpoint is concerned with managing real-world constraints, such as restrictions on the hardware available to implement the system within budget, or the existing application platforms on which the applications must run. |
Once the requirements and the approach to fulfill these requirements have been developed, reviewed, and approved by the overall team, the wide variety enterprise software components need to be created and assembled. SOA provides the infra-structure and organization required for both connectivity and interaction between a wide variety of programs and functions (services) that may be written in different software languages to provide proper and secure transactions. SOA does not imply a specific technology or creation of a single all-encompassing program. Rather, SOA is an architectural paradigm and discipline that may be used to build infrastructures enabling those with needs (consumers) and those with capabilities (providers) to interact via services across disparate domains of technology and ownership [2].
Implementation of a SOA will provide for user interfaces, messaging between users, storage of data, access to data and services, establishment of workflow processes, and system security. When properly conceived, SOA is sufficiently flexible to allow incremental development and implementation of the functionality required by the organization. While SOA is often associated with Web Services, it is important to understand that the services provided by SOA need not be web based. SOA is often associated with the streamlining of business practices; however, the organization, interchangeability, and flexibility of SOA can provide advantages for the scientific and medical community as well, that faces similar obstacles created by the wide variety of software and IT tools that are currently difficult to integrate. For the purposes of this article, the importance of SOA resides in its ability for the scientific and medical community to find a realistic methodology for creating a useable and secure system, composed of complex and disparate entities, including Electronic Medical Records, Hospital and Radiology Information Systems, research databases and repositories, as well as the database systems that will form the core of an ITS-PM.
It is beyond the scope of this article to provide a complete RM-ODP enterprise proposal with detailed SOA schema. However, we will try to explore and define the overall objectives and processes (enterprise viewpoint), the requirements relating to data types and data exchange (information viewpoint), and the software categories (computational viewpoint). (In some cases, specific software components, categories or products may be mentioned. However, at this stage of development this is done for illustrative purposes only to indicate the feasibility of a required technology or process. Architectural detail, as well as specific hardware and software selection and development, would be determined much later in the project.) A simplified schematic for the organization of an ITS-PM is presented in Fig. 12.3.
Fig. 12.3
A schematic for organization of an ITS-PHC. This diagram reorganizes many of the TIMMS components in a structure that will enable the secure interchange of information between data sources, database management systems, data analysis systems, and end-user applications. (Legend: PSM patient specific model; TIMMS therapy and imaging model management system; PACS picture archiving and communications system; MEBN multi-entity Bayesian network; NoSQL not only structured query language; DBs databases)
Stay updated, free articles. Join our Telegram channel
Full access? Get Clinical Tree
