PHI TECHNOLOGY white paper

ABSTRACT

This document represents the technical whitepaper of the PHI Technology.

The purpose of this document is to present the PHI Technology to people, who are not familiar with it and to provide a basic understanding of its concepts, architectural elements, and features. The whitepaper does not aim to explain the PHI Technology in details, but rather to introduce it to you and to give you a general idea of how it can be helpful to you.

The INTRODUCTION section is intended for people facing the PHI Technology for a first time, giving its main definitions.

The TYPICAL SCENARIO section faces a typical situation of our daily round in which the product may be helpful. It describes tasks faced by an employee in the healthcare field, problems that may occur, and the problem solving solution of our product.

The OVERVIEW section is intended for people, facing the PHI Technology for a first time. It provides a general outlook of the main tools and components.

After the brief introduction, you can find a TECHNICAL OVERVIEW section with details of the product’s concepts. There is also an introduction to the suggested readers and users. The structure of the product and the used technology are described within this section.

Implementation of the core vital tools and components of the PHI Designer are described in the PHI DESIGNER section.

The description of the PHI RE engines is located in the section PHI RUNTIME ENVIRONMENT.

In the end of the White Paper, you can find the BENEFITS of the product. Specific features that distinguish it from the other solutions are explained in this section.

INTRODUCTION

PHI Technology is divided in two separate parts called PHI Designer and PHI Runtime Environment (PHI RE). The PHI Designer is used to generate healthcare applications named PHI Solutions, deployed and executed upon the PHI RE runtime environment. PHI Designer and PHI RE share a common Reference Information Model (PHI RIM), fully extensible and customizable, derived from the international standard HL7 RIM ([1]). PHI RIM stores the metadata catalog, describing objects’ attributes, services, events, vocabularies and ontologies. Applications, named “solutions”, are designed and executed upon the RIM. The physical database (PHI RIM DB) is invisible to designers and applications; its conceptual and physical model is derived from the RIM, that makes it an open database, based on the most popular international healthcare standard. Its mixture of Entity-Relationship and Entity-Attribute-Value physical structures makes it extremely flexible and performing.

TYPICAL SCENARIO

The typical daily duties of an employee in the healthcare institutions cover multiple tasks concerned with handling different types of information, such as: patients’ records, disease management, hospital administration tasks, and many more. In our web-connected daily round, processing administrative information becomes inevitable part of healthcare employees’ tasks. They become not only humanitarian executives, but they have also to keep connection with other doctors, nurses, general practitioners, and institutions such as other clinics, hospitals, and even governmental offices. In this daily round the medic, faces many and different software solutions developed by people who are not part of the healthcare field, they provide predefined forms and structures, which demand additional qualification, which are abstract, new, and complicated.

Let’s imagine a typical scenario where a physician performing his daily tasks, aided by an IT system, realizes that software application he’s using does not satisfy a new requirement.

Due to the fact that software maintenance slows down the time to market, a great advantage would arise from keeping out of the software maintenance tasks as much as possible. Most of the users’ change requests should not affect the source code of the software. Actually changes are affecting the source code because the software applications have been written years ago using old technologies and minding mainly the fast first implementation and not considering sufficiently the maintenance. Here comes the difference between old fashioned architectures and PHI Technology that thanks to its model-driven and service-oriented architecture facilitates the productivity in handling with information for the healthcare institutions. Instead of working with predefined and abstract software solutions; using PHI Designer the product specialist draws self-explained and consistent web forms. The product specialists, whose skills are closer to the real processes knowledge than to the software engineering, can use and enrich the set of predefined functionalities, GUI objects, processes, etc. to compose and change continuously the final application without involving the software developers. Most of the maintenance activities are quickly performed by analysts and product specialists, which are closer to the physician than to the software engineer, both geographically and culturally. Finally, only a very limited subset of requests needs the involvement of software development.

If a special component or property is needed, the user calls the development staff. They quickly add the new component and its properties by following some easy steps. Due to the fact that the developers can make changes without affecting the source code a lot of time can be saved. The code of the new component is automatically generated, and then it is ready for use for the user interface of the product. After drawing the form, the user can associate functionalities to the components. This process is as easy as a drag-and-drop sequence on the components of the visual area. All functionalities are available in intuitive tree structures, as parts of the GUI Designer. When every part of the newly created form is on place final deploying of the solution is one command away. Users can add or remove components, and associate functionalities according to their needs. A very important quality of the PHI RE is its reusability. Once deployed all forms in use can be used many times, by different people. The only reason to return to the designing process is for further updates (adding or removing additional components). Designed elements of the form, or the form itself can be used as building blocks of the whole Runtime Environment. This way the product specialist creates, previews, and deploys from its basis a final solution on the Runtime Environment. Finally, the team creates a PHI Solution using the designers and henceforth this PHI Solution can be executed on the PHI RE easily. Another aspect of this solution is the easiness, to update a PHI Solution. Another feature of using PHI Technology is the portability of PHI Solutions due to the use of open standard formats for the open models which are actually represented in XML format.

OVERVIEW

Generally, the PHI Technology is created to assist employees in healthcare institutions like hospitals, clinics, and general practitioners in their daily work with information. The most important feature of PHI Technology is that you do not have to be a computer expert to use it. Doctors, nurses and administrative staff work every day with huge amounts of information that needs to be stored and organized in an easy to use way. However, different people have different understandings of the term “logically organized”. That is why the PHI Technology gives you the tools to create easy to use ways to handle information. With PHI Designer, in fact, Tools, Components, Wizards, Templates are used together to simplify the modeling phases in order to enable a business analyst to deliver the needed solution by assembling pre-defined and user-defined building blocks.

The PHI Designer is intended to assist you with developing easy to use and intuitive reusable applications for your daily work with information. Finally, the PHI Technology provides you with a runtime environment independent from underlying operating systems, named PHI RE, based on J2EE (Java 2 Enterprise Edition) and open standards, where you can deploy your applications once you have designed them with the PHI Designer. Servers and Engines can be seen as being nearly synonyms. The main purpose of the PHI RE is to enable the applications exchange and reusability among partners and customers, making it as easy as a plug-and-play setup. PHI RE is mainly composed by Servers and Engines, which are, finally, J2EE components developed in JBoss SEAM framework, which are deployed in JBOSS Application Server.

Both PHI Designer and PHI RE are reliable and scalable: you can install the whole PHI Technology either on a personal computer or in a network of distributed servers, in single node configuration as well as in a cluster configuration for high availability.

TECHNICAL OUTLOOK

Purpose

The PHI Technology provides tools and components to design eHealth applications (named PHI Solutions) to be executed in a runtime environment (PHI RE) independent from the underlying operating system. The main characteristic of the PHI Technology is the adoption of a Model Driven Architecture (MDA) combined with a Service Oriented Architecture (SOA) completely based on the latest open standards. These elements protect the investment assuring the longest lifetime of the applications, reduce the risk factors, speed up the time-to-market and reduce the maintenance cost.

With the PHI Designer, part of PHI Technology, you can also generate final solutions (PHI Solutions) that are plug-and-play and open-model in the sense of a model driven architecture. These open models are represented using the technologically independent format of XML. The PHI RE interprets the meta-code of the solutions enabling the final users to work with them.

Creating a PHI Solution with the PHI Designer is not a pure software development process indeed. It is, instead, an assembly of pre-defined and user-defined building blocks, wizard driven and end-user oriented.

The PHI Technology is designed to satisfy needs of people, working in healthcare organizations. Particularly it can provide software solutions for hospitals and clinics and help staff in processing data for medical purposes.

Who Should Use the Product?

The product is designed for two groups of users:

1.The first group includes high level users like process specialists or 
  senior analysts and software  developers. These users do not work with 
  the source code as the PHI Designer itself is generating it. However, 
  they are required to work with the model of the PHI Designer in order to 
  update the plug-in for the needs of the target customers. They also set 
  the runtime engine of the product for the designers.
2.The second group of users is the group of the designers. They are required 
  to have average computer literacy. They handle with the user interface 
  and the designing tools of the PHI Designer. The outputs of their work 
  are healthcare applications named PHI Solutions.

Used Technology

The PHI Technology is based on an open-model concept. It means that the final software applications, named PHI Solutions, have been generated from a model (of the process, of the user interface, of the document, etc…).

In order to update the plug-in, you have to update its model. From that point, the PHI Technology provides ways to update the model and start automatic generation of source code. The model is language independent. Theoretically, you can generate source code from a model in different programming languages. The result of the generation of source code: Java classes, XML files, HTML and JavaScript, SQL scripts are created. Finally, to manipulate the model you have to use the PHI Designer or any other tool, which is compliant with the runtime environment.

The PHI Designer is based on the Model Driven Architecture – Integrated Development Environment (MDA IDE) - provided by the Graphical Modelling Framework (GMF) comprising the open source Eclipse Modelling Framework (EMF) combined with Graphical Editing Framework (GEF) and it uses Java Emitter Template (JET) an Eclipse framework to generate several output.

It is ready to adopt the Open Healthcare Framework (OHF), which is an Eclipse Project oriented to healthcare applications based on international standards, like Health Level 7 (HL7) ver. 3, Digital Imaging and Communications in Medicine (DICOM), Integrating Healthcare Enterprise (IHE), ebXML, and others.

The PHI Runtime Environment runs on Java Runtime Environment (JRE) and is based on Java 2 Enterprise Edition (J2EE).

Eclipse Workbench

The Eclipse Platform is built on a mechanism for discovering, integrating, and running modules called plug-ins. A tool provider develops a tool as a separate plug-in that operates on files in the workspace and surfaces its tool-specific user interface in the workbench. When the platform is launched, the user is presented with an Integrated Development Environment (IDE) composed by set of available plug-ins. A plug-in is the smallest unit of Eclipse Framework function that can be developed and delivered separately. Usually a small tool is written as a single plug-in, whereas a complex tool has its functionality split across several plug-ins. Plug-ins are coded in Java. A typical plug-in consists of Java code in a JAR library, some read-only files, and other resources. PHI Designer tools and components are developed and implemented as Eclipse compliant plug-ins.

Eclipse provides also an extensible Welcome Page, combined with programmable tutorials, wizards and plug-ins (that means all PHI Tools and Components).

PHI Designer tools and components are developed and implemented as Eclipse compliant plug-ins.

Eclipse provides also an extensible Welcome Page, combined with programmable tutorials, wizards and plug-ins (that means all PHI Tools and Components). Used properly, these tools can greatly simplify the tasks for modeling and designing new applications. Analysts could interact with the most common features, by their personal perspective, mainly driven by the Welcome Page.

PHI DESIGNER

PHI Designer provides a set of integrated designing tools and components for the modeling of PHI Solutions for the final users, which are executed on the PHI Runtime Environment (PHI RE).

PHI Designer consists mainly of GUI Designer, Process Designer, Report Designer, Security Designer, Rule Designer plus some other few components, such as Domain of Vales Explorer (DoV Explorer), Templates Explorer (TE), Generic Explorer (GE), Catalog Explorer (CE) and Process Explorer (PE) that are used by the main designing tools.

PHI Designer tools are all based on the same modeling framework (EMF = Eclipse Modeling Framework), they share the same PHI Designer Components (Catalog Explorer, Generic Explorer, Process Explorer, Templates Explorer) and the same technology (Eclipse Java Emitter Template, shortly JET) to generate the source code from the designed model of the page as well as of the process and the report too.

GUI Designer

The Graphical User Interface Designer (GUI Designer) provides you with the fastest way to create and modify web-based user interfaces as well as other kinds of user interfaces. This capability to render different output formats from the same GUI model is owed to the modelling framework of Eclipse combined with the templating framework.

The basic properties and layout are based on XML templates that only authorized users can modify.

The user interface designers have the ability to create preferred by them forms. These forms are the result of using GUI Designer. However, the designers do not have the knowledge to update the supplied XML templates and therefore the components and features that GUI Designer offers. In the work of the designers, they are supplied with an easy to learn and use user interface, built with coherence and homogeneity.

The PREVIEW is a feature, supplied to assist the GUI designers in designing and configuring the runtime pages. The user can drag-and-drop widgets to the editor and arrange them. The main point is that at any time of their work on a form, the designers have a preview of the way the page will look like. This is feature in the process of drawing self-explained web forms.

Once the work on a certain diagram is finished, the GUI designers can generate files of the form they have been working on. The output is two files that are generated in the output folders of the project. These files are:

1.XHTML: This file contains definitions of the elements in the page. 
2.Cascading Style Sheet (CSS): This file contains definitions of the 
  styles that are applied to the elements in the page.

The widgets, that are listed in a palette, used by the GUI designers are based on Java Server Faces (JSF) components. These two kinds of presentation are linked by EMF model elements.

The GUI Designer is associated to an Eclipse Perspective that divides the work space in different area:

•TOP - Toolbar and Menu 
•MIDDLE LEFT – PHI Navigator where the PHI Solution project are listed
•MIDDLE CENTER – Editor area used to designed UI, Process, Rule, Security
•MIDDLE RIGTH – Palette where the widgets are listed
•BOTTOM LEFT – PHI Explorers: Generic Explorer, Domain of Values Explorer, 
 Template Explorer, Catalog  Explorer, Process Explorer
•BOTTOM RIGTH – Property view for all the components used in the Designer 
 and RIM Vocabulary

Form

Part of the GUI Designer is the Form, a component that allows the designer to aggregate data and service to model the hospital reality. A Form, that is a set of widgets with its own layout, is made using the Drag&Drop capability: from the palette the widgets and from the Explorers data and services.

For each Forms the Designer generates one output file (XHTML) that store widgets, data and services and one CSS that store the layout characteristics.

Forms Container

Part of the GUI Designer is the Forms Container, a component that allows the designer to define how many forms have to be loaded into that page, into which forms and into which position. There are no restrictions on how many Forms a Container can include.

The Container has a list of properties, defined in the model of the GUI Designer. These properties set the style and appearance of the components, such as size, color, position etc.

A very important feature of such a graphical component is the capability to define master-detail relationships among the contained forms. This capability enables the automatic synchronization of the linked information, without reloading the whole page.

For each Forms Container the Designer generates one XHTML file that represents the PHI Solution Page, one XHTML that is the Forms Container, one CSS that store layout characteristics and one JavaScript used to managed the master-detail relation among the contained forms.

Report Designer

The Report Designer plug-in provides a number of tools and components, including a 'Data Explorer' which "organizes data sources (connections) and data sets (queries), allowing you to test your data set to ensure the report receives the correct data.

A 'Layout View' WYSIWYG editor supports drag and drop creation of the presentation portion of your report. A 'Property Editor' presents the most commonly used properties in a convenient format that makes editing quick and easy.

The 'Code Editor' tool enables scripting to add business logic to reports during data access, during report generation, or during viewing; this code editor provides standard Eclipse features for editing your scripts: expression builder, syntax coloring, auto-completion, and more.

Finally, our Report Designer generates RTF, HTML, PDF documents via Jboss iText, and HL7 CDA2 (Clinical Document Architecture version 2, xml formatted).

Process Designer

This tool provides a process designer based jBPM (JBoss Business Process Management), to define workflows of any kind and WS orchestration file. These files are then interpreted and executed on the PHI RE by the Process Engine.

jBPM is licensed by the Apache Software Foundation under the open source license that makes it free to download, use, embed, and distribute.

Processes are organized on tasks and sub-processes. Sub-processes are used to simplify the graph, grouping atomic simple sub-processes together with tasks, in more generic processes, using a top-down approach as well as a bottom-up.

The Process Designer has its own property view independent from the rest of the Eclipse Framework. All specific functions of the Process Designer are placed there.

Catalog Designer

The Catalog Designer is a tool of the PHI Designer based on Eclipse GMF eCore and used to maintain the object model on which the PHI Solutions are built via a user friendly editor. Such an object model contains all the available data structures (metadata) and events, according to the HL7-like Reference Information Model (RIM). It is based on the HL7 MIF metamodel (Message Interchange Format), which is the XML representation of the RIM used to maintain it (update, extend, import, export) and to port it through the different organizations. The editor provides a very user friendly handling of building up expressions for calculated fields using Java Script without forcing the user to know its syntax. Once the data objects created using the Catalog Designer are validated and approved by the designer (user’s role) they are stored also in the Catalog Explorer (CE).

Security Designer

The Security Designer is a tool of the PHI Designer based on JBoss Rules (see next paragraph) for the designing of complex security rules. It supports HL7 RBAC Role Based Access Control and enables its application upon HL7 RMIMs read and create basic services.

Rule Designer

The Rule Designer is a tool of the PHI Designer based on JBoss Rules, that is licensed by the Apache Software Foundation under the open source license that makes it free to download, use, embed, and distribute.

Rules engines simplify applications by separating business policy or rules logic from process, infrastructure and presentation logic. This modularity enables business analysts, rules developers and auditors to develop, deploy, modify and manage a business process’s rules with much greater ease and speed.

Rule Designer is a great way to collect complex decision-making logic and work with data sets too large for humans to effectively use. The JBoss rule engine can make decisions based on hundreds of thousands of facts, quickly, reliably and repeatedly.

Rule engines facilitate knowledge-transfer to centralized repositories and helps combat issues due to the loss of key decision makers, managers, executives, specialists and highly creative employees from “normal” turnover rates and aging populations.

Once your business rules are separated from other logic, they can be more easily reused across many applications and in service-oriented architecture environments.

The tool provides a graphical editor not only in the PHI Designer but also like web application this means that a PHI Solution user can modify a rule.

Domain of Values Explorer (DoV Explorer)

The Domain of Values Explorer runs as an Eclipse plug-in and particularly presented as a tree-view object. The goal of this component is to manage a list of values that can be associated to a particular kind of widget like: ComboBox, ListBox, GroupCheckBox or GroupRadioButton.

The Domain of Values Explorer is a visual component of the PHI Designer, which allows the user to manage short lists of values in a certain domain. The domain is multilingual. It has associated transducer code values. All the information is stored in a Java Bundle.properties file.

The DoV View represents a windowpane with the Domain Tree in it. The tree and its nodes are the DoV Explorer. They can be further edited or assigned to widgets of the GUI Designer.

The association of the DoV Explorer to a widget in the visual area is as simple as a drag-and-drop sequence. The system registers the binding automatically.

A pop-up menu can be opened with the secondary mouse button when a node or leaf within the Domain Tree is selected. It gives the user a set of assigned commands for communication with the DoV Explorer. There is attached tool tip for further facilitation while working with the DoV Explorer.

The DoV Explorer has its own toolbar independent from the toolbar of the Eclipse Framework. All specific functions of the DoV Explorer are situated there. The search feature can help the user to find a domain.

Generic Explorer (GE)

The Generic Explorer enables the designer to browse NON-RIM-BASED data model and service and to bind its elements to a graphical widget.

The GE View represents a windowpane with a tree in it. The nodes of the GE Tree show data objects name that contains one DATA node, where the Leaves represent the specific data attributes, and one OPERATION node that contains service methods with INPUT and OUTPUT parameters. The service methods can be assigned to widgets like buttons in a form or tasks in a process.

The association of the GE to a widget in the visual area is as simple as a drag-and-drop sequence. The system registers the binding automatically. The plug-in is multilingual. This means, that the same data structure can be described in many languages.

The GE View has its own toolbar independent from the toolbar of the Eclipse Framework. All specific functions of the GE are situated there.

Templates Explorer (TE)

The Templates Explorer (TE) is another important component of the PHI Designer. It runs as an Eclipse compliant plug-in, particularly presented as a tree-view.

The TE permits to save Form or part of them in a TE tree organized them using folder and reuse when necessary. A Template can be created using the secondary mouse button when a set of widgets in a Form is selected, in this way the set of widgets is stored in a Form Template under TE tree. Then the Form Template can be imported in a Form using the secondary mouse button.

The TE View has its own toolbar independent from the toolbar of the Eclipse Framework. All specific functions of the TE are situated there.

Catalog Explorer (CE)

The Catalog Explorer (CE) is another important component of the PHI Designer. It runs as an Eclipse compliant plug-in, particularly presented as a tree-view object.

It contains all the available data structures (metadata) and events (services), according to the HL7-like Reference Information Model (RIM). It is based on the HL7 MIF metamodel (Message Interchange Format), which is the XML representation of the RIM used to maintain it (update, extend, import, export) and to port it through the different organizations.

CE is mainly used to bind data objects and services to GUI widgets (like an entry field, a table, a button).

Modifications (extensions) to the RIM are made by the Catalog Designer, which is integrated with CE: each time an update is performed in the Catalog Designer, CE is immediately updated.

CE is integrated with the HL7 documentation to make easy the use of the RIM model, the documentation can be call with secondary mouse button click on the RMIM node and will be shown in the Eclipse Web Browser.

The CE is divided by domains (order, schedule, observation, patient administration, …) and provides a search engine for a rapid retrieval of the right object (MIF) in order to make someone not skilled on HL7 RIM being able to interact with it. This search function is based on SNOMED-CT ontology that is linked to the RMIM of HL7.

Such a RIM-based Catalog is independent from the database physical structures, which are bound to Hibernate objects instead (Hibernate, by JBoss, is an object-relational mapping tool).

Process Explorer (PrE)

The Process Explorer (PrE) is another important component of the PHI Designer. It runs as an Eclipse compliant plug-in, particularly presented as a tree-view.

The PrE permits to collect and reuse Process in different PHI Solutions.

The PrE View has its own toolbar independent from the toolbar of the Eclipse Framework. All specific functions of the PrE are situated there.

PHI RUNTIME ENVIRONMENT (PHI RE)

PHI RE consists of a stack of technology inside RedHat JBoss Application Server. Everything but the database is contained by the Application Server. The picture below represents the architecture, that complies with the industry standard reference architecture for enterprise applications. It keeps the different layers decoupled: view, presentation, control, context management, state management and data access. Actually only Oracle and MySQL databases are taken into consideration, plus Progress when the interoperability with Patidok Hospital Information System is an issue.

PHI Server

PHI Server includes a set of specialized servers and engines. The most important are Catalog Server, Rules Engine, Process Engine and Report Engine.

Catalog Server

The Catalog Server (CS) is the core of the PHI RE and is the main component of each PHI web application. It makes the web 2.0 rich applications interact with the underling Reference Information Model, avoiding any direct access to the database and making the separation between the view layer and the model and the control effective. It is build upon the JBoss SEAM framework and includes an implementation of the JavaSIG open source objects library for the HL7 Reference Information Model.

Rules Engine

Based on Jboss Rules Engine and fully integrated eith the PHI R.E. , provides

• Full Rete Implementation – with high performance indexing and optimization
• Field Constraints

 * Literal, Bound Variable, ReturnValue and Predicate Constraints

• Conditional Elements

 * And, Or, Not, Exists and Eval

• Agenda Management

 * Confl ict Resolution (Salience+Depth)
 * Agenda Groups
 * Agenda Filters
 * No loop for recursion control

• Truth Maintenance with Logical Assertions
• Temporal Rules – allows rules to fire based on time requirements
• Dynamic runtime addition and removal of rules
• Complete Event Model

 * Execution Audit logging

• Functions
• Global Data
• Working Memory Query support.
• Language independent Engine

 * Drools is interface driven using the Rule
 * Assembly API to construct rules

Process Engine

The Process Engine is based on an jBPM (JBoss Business Process Management). It is integrated with the other servers in order to be able to orchestrate every task of the application.

Report Engine

The Report Engine is based on the Jboss Seam that enables reports to be generated within any Java application using report models created by the Designer. It has four main integration points with an application: (1) Parameter UI, in which a user specifies some kind of input, called a report parameter; (2) Running the Report, triggered when the user submits the parameter form; (3) Data Access, whereby reports obtain data from Java applications; (4) Viewing the output of the report. Security Server The Security server is based on SEAM Security that is build upon JAAS (Java Authentication and Authorization Service) and it’s integrate with Rule Engine in this way the security rule can be defined in an easy way.

Service Dispatcher

The Service Dispatcher invokes proper Services, which are provided by Enterprise Java Beans (EJB3), contained in the Application Server. These services provide the business logic and interact with the lower layer of Data Access Objects.

Data Server

The Data Access Objects (DAO) are Enterprise Java Beans (EJB3), contained in the Application Server, generated by an object relational mapping tool, that accesses the database structures via server. This indirect access enables the independency between application and database. It introduces also the capability to publish existing Patidok functionalities like services, evocable from external web pages, portals and process engines.

Patidok Gateway

The Patidok Gateway (PG) enables the tight integration and reusability of the PHI Solutions and existing Patidok programs and customized configurations.

This is the only client-side software of the PHI R.E., used only when reusability of existing Patidok Progress programs and Patidok configurations is needed. PG, infact, inables to trigger from a web page an existing Progress program, so that the web interface could act as a “remote controller” of the underlying Patidok functions.

The ideal scenario for the use of the PG is a Patidok customer who wants to migrate progressively to the PHI Technology, reducing the delivery time and avoiding the risk of a complete reengineering in one shot.

Registry/Repository

As the name already tells, there are two parts contributing to this technology: the Registry and the Repository. To be able to provide public data and services among organizational boundaries and facilities these artifacts have to be registered and stored in a centralized way using web services. Then it is possible to query for these artifacts within the Registry and selecting the appropriate artifacts. There are also metadata stored in the Registry to describe the data and services provided by the Registry-server. As it can be seen in the figure to the side, it is possible to combine many Registry servers to a cooperating federation like a peer-to-peer net. This means that these cooperating Registries behave like a single e-Business Registry to the clients.

Using this technological feature provides the opportunity to tie together internal applications and the systems of critical trading partners via:

=> seamless query
   This means that it is possible to search for registered content 
   – i.e. patient data – in any Registry in a federation, regardless of 
     the Registry type.
=> seamless synchronization
   This means that all the registered contents are synchronized between 
   the federations’ Registry servers.
=> seamless relocation
   This means that it is possible to move (relocate) registered content 
   – i.e. patient data – from one Registry to another within a federation.

The Repository on the other hand stores the artifacts. This is exactly the way the medical data in our PHI Technology is managed. The figure on the right provides a representation of a typical request/response flow. Retrieving patient data from a Repository means, querying first the Registry server(s) by invoking the “QueryManager” and then – if found the appropriate patient data – accessing the Repository via the Registry server. This means that the facade visible to the client is a Registry (or federation acting like a single Registry). The client does not have to worry about retrieving the data from a Repository server. Also editing medical data on a repository is managed by the Registry using the “LifeCycleManagment service”. This service provides the functionality required by Registry clients to manage the life cycle of patient data contained within a Repository.

Typical scenarios

Typical applications of the Registry/Repository servers are the Patient Master Index, the Document Master Index, the Continuity of Care Patient Record, the Clinical Procedures Index, and all the other similar cases, where an information set is needed by different organizations spread geographically, regardless where it has been originally stored.

BENEFITS

PHI Technology provides beneficial tools in creating reusable solutions for healthcare institutions. The meaning of reusable solutions is that once the forms have been created and the processes, have been designed they can be used many times by many users. There is no need of designing the same diagrams many times.

The user-friendly interface provides the opportunity for people with average computer literacy, to create and deploy self-designed and thus self-explained reusable applications for handling data. The common self-created reusable solutions called PHI Solutions combined with the strong process-orientation shortens the distance among the individuals of the organization. Drawing a form or a process, one can express his/her view and own thoughts of the appearance and data handled by operations and workflows.

Developers who provide technical maintenance of the product do not need to write code, concerned with the tools. They simply add new tools and properties and then execute a command, which updates the whole model automatically. This saves time and increases developer’s efficiency.

Additional benefits come from the GE, PE, CE, DoV and TE components. With their intuitive tree structure, they facilitate data handling processes. Their multilingual feature makes them available to wider community. Users can use different languages in their work with the application while the result remains the same. GE, PE, CE, DoV and TE plug-ins are generated from XML based files, which means that new method or service, can be added quickly. This practice speeds up the form design process reduces the risk of trivial mistakes and simplifies the maintenance tasks.

The modeling framework aids desingers in creating simple and comprehensible solutions. It supports creative thinking of the individuals involved in designing clear applications, which facilitate further data handling processes.

The product specialists whose skills are closer to the real processes than to the software engineering can use the set of predefined templates and services, GUI objects, processes, rules and reports to compose and change continuously the final application without involving the software developers.