This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "RIMBAA: PHI Technology"

From HL7Wiki
Jump to navigation Jump to search
Line 19: Line 19:
 
''This section uses terminology as defined in [http://www.ringholm.de/docs/03100_en.htm this whitepaper].''
 
''This section uses terminology as defined in [http://www.ringholm.de/docs/03100_en.htm this whitepaper].''
  
[[Image:Rimbaa phi.jpg]]
+
[[Image:RimbaaPhi.JPG]]
  
 
On the one hand the PHI Technology solutions occupies the '''RP-RO-MS''' squares using the [[RIMBAA: Java based Reference Implementation|Java SIG materials]].
 
On the one hand the PHI Technology solutions occupies the '''RP-RO-MS''' squares using the [[RIMBAA: Java based Reference Implementation|Java SIG materials]].
 
In addition to the Java SIG materials, the '''RO-RS''' squares are Java code based on [http://www.jboss.com/products/seam JBoss Seam].
 
 
:Question: the diagram contains a mapping from RS to MS (or: MS to RS). How is this achieved? [[User:Rene spronk|Rene spronk]] 12:03, 1 August 2008 (UTC)
 
  
 
===User Interface===
 
===User Interface===
Line 34: Line 30:
 
   Patient_PRPA_MT201301UV02.player[classCode=PSN,determinerCode=INSTANCE].name.FAM
 
   Patient_PRPA_MT201301UV02.player[classCode=PSN,determinerCode=INSTANCE].name.FAM
  
All the user interface are linked to a Seam Bean that using the XPATH-like binding, derived by RMIM, can read/write attribute in the RIM Object.
+
All the user interface are linked to a [http://www.jboss.com/products/seam JBoss Seam] Bean that using the XPATH-like binding, derived by RMIM, can read/write attribute in the RIM Object.
 
Example:
 
Example:
 
         <h:outputText id="Label_1211819478500_id" rendered="true" styleClass="Label_1211819478500"
 
         <h:outputText id="Label_1211819478500_id" rendered="true" styleClass="Label_1211819478500"
Line 53: Line 49:
 
       </h:inputText>
 
       </h:inputText>
  
When PHI RE receives this binding string ('''RS''' square) – then it checks:
+
When PHI RE receives this XPATH-like binding checks:
 
#If the Patient_PRPA_MT201301UV02 is in the context get/set value using XPATH-like binding player[classCode=PSN,determinerCode=INSTANCE].name.FAM for reading/setting the RIM Object attribute. A converter was implemented to manage RIM Type value and Java Type.
 
#If the Patient_PRPA_MT201301UV02 is in the context get/set value using XPATH-like binding player[classCode=PSN,determinerCode=INSTANCE].name.FAM for reading/setting the RIM Object attribute. A converter was implemented to manage RIM Type value and Java Type.
 
#If the Patient_PRPA_MT201301UV02 is NOT in the context then the instance associated to the root of the PRPA_MT201301UV02.mif is loaded using Java Sig. All attributes with fixed/default value, set in the mif file, are initialized and then RIM Object instance is stored in the context and cached.
 
#If the Patient_PRPA_MT201301UV02 is NOT in the context then the instance associated to the root of the PRPA_MT201301UV02.mif is loaded using Java Sig. All attributes with fixed/default value, set in the mif file, are initialized and then RIM Object instance is stored in the context and cached.
  
 +
The two steps are necessary because when the Process start and the object is required, in the Process context, for the first time we need an empty R-MIM root class instance initialized with some value that came from MIF, instead during the life of the Process Context we need to work with object with values (Family Name, ....), for example filled in the task before of the running process.
  
:Question: the latter part isn't clear to me. Maybe it would help if you could describe what type of payload you are using in communications with other systems. MS (serialized R-MIMs), or RS (serialized RIM). [[User:Rene spronk|Rene spronk]] 12:03, 1 August 2008 (UTC)
+
The communication with other system will be implemented using the Java SIG HL7 message v3 capability starting from RIM Object (RO) and it will be sent to the ESB that communicates with other system with some useful transformation feature from v3 to v2.x when it's required.
:Question: why the two steps? Why doesn't one (or the other) work for all circumstances? [[User:Rene spronk|Rene spronk]] 12:03, 1 August 2008 (UTC)
 
  
 
== PHI TECHNOLOGY Roadmap ==
 
== PHI TECHNOLOGY Roadmap ==

Revision as of 22:15, 1 August 2008


Overview

The PHI TECHNOLOGY Tool suite (created by ITAL TBS Group) aims to provide the user with the tools to create easy to use ways to handle information. 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 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. 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.

PHI TECHNOLOGY contains:

  • A product called PHI Designer. The PHI Designer is used to generate healthcare applications named PHI Solutions, deployed and executed upon the PHI RE runtime environment.
  • A PHI Runtime Environment (PHI RE).

PHI Designer and PHI RE share a common Reference Information Model (PHI RIM), fully extensible and customizable, derived from the HL7 RIM. 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.

For additional information:

HL7 v3 Technology Matrix

This section uses terminology as defined in this whitepaper.

RimbaaPhi.JPG

On the one hand the PHI Technology solutions occupies the RP-RO-MS squares using the Java SIG materials.

User Interface

The User Interface is an R-MIM driven generation process (by PHI Designer). R-MIMs, process-tasks and GUI widgets are bound/configured using the toolset (the Process Explorer).

The RO object is bound to a UI widget using a binding string that has a XPATH-like format, e.g.:

 Patient_PRPA_MT201301UV02.player[classCode=PSN,determinerCode=INSTANCE].name.FAM

All the user interface are linked to a JBoss Seam Bean that using the XPATH-like binding, derived by RMIM, can read/write attribute in the RIM Object. Example:

       <h:outputText id="Label_1211819478500_id" rendered="true" styleClass="Label_1211819478500"
           value="#{RimBean.getValue('Doctor_PRPM_MT999999UV01.player[classCode=PSN,determinerCode=INSTANCE].name.FAM')}">      
       </h:outputText>   
       <h:selectOneMenu id="vocab_EncounterSpecialCourtesy_combobox_ComboBox_1217003891062"
                   rendered="true"  required="false"  styleClass="ComboBox_1217003891062"
                   valueChangeListener="#{SelectItemBean.processValueChange}">
                   <phi:selectItems  value="vocab_EncounterSpecialCourtesy" />
                   <f:param value="Encounter_PRPA_MT402001UV02.specialCourtesiesCode" name="binding"/>
      </h:selectOneMenu>
      <h:inputText id="TextBox_1210948378437_id"
          styleClass="TextBox_1210948378437"
          required="false"
          rendered="true" value="#{inputTextBean.value}">
          <f:param value="Patient_PRPA_MT201301UV02.player[classCode=PSN,determinerCode=INSTANCE].name.FAM" name="binding"/>   
          <f:converter  converterId="RimPropertyResolverAsConverter" />   
      </h:inputText>

When PHI RE receives this XPATH-like binding checks:

  1. If the Patient_PRPA_MT201301UV02 is in the context get/set value using XPATH-like binding player[classCode=PSN,determinerCode=INSTANCE].name.FAM for reading/setting the RIM Object attribute. A converter was implemented to manage RIM Type value and Java Type.
  2. If the Patient_PRPA_MT201301UV02 is NOT in the context then the instance associated to the root of the PRPA_MT201301UV02.mif is loaded using Java Sig. All attributes with fixed/default value, set in the mif file, are initialized and then RIM Object instance is stored in the context and cached.

The two steps are necessary because when the Process start and the object is required, in the Process context, for the first time we need an empty R-MIM root class instance initialized with some value that came from MIF, instead during the life of the Process Context we need to work with object with values (Family Name, ....), for example filled in the task before of the running process.

The communication with other system will be implemented using the Java SIG HL7 message v3 capability starting from RIM Object (RO) and it will be sent to the ESB that communicates with other system with some useful transformation feature from v3 to v2.x when it's required.

PHI TECHNOLOGY Roadmap

Tools and components actually available in rel. 1.0 :

  • GUI DESIGNER
  • REPORT DESIGNER
  • PROCESS DESIGNER
  • CATALOG DESIGNER
  • GENERIC EXPLORER
  • PROCESS EXPLORER
  • CATALOG EXPLORER
  • TEMPLATES EXPLORER
  • DOMAIN-OF-VALUES EXPLORER
  • PROCESS ENGINE
  • REPORT ENGINE
  • RULE ENGINE
  • CATALOG SERVER
  • SECURITY SERVER
  • REGISTRY/REPOSITORY

Planned for rel. 1.1:

  • SECURITY DESIGNER (to enable Advanced Security: from role-based security of rel. 1.0 to rule-based security of rel. 1.1)
  • Smarter integration with Jboss Rule Editor and PHI DESIGNER
  • Automatic generation of HQL scripts (Hibernate Query Language) for the DB schema creation after changes in RIM foundation classes via Catalog Designer
  • built-in HTML HL7 documentation Editor (as a feature of Catalog Designer)
  • New database model (PDM3 = Physical Data Model ver. 3), implementing a E-R/EAV hybrid approach, to make it more flexible.
  • PHI COMMANDER: a new GUI widget, customizable per user perspectives, to enable users entering PHI Commands from any GUI and to make as easier as possible the information retrieval. Its special ergonomy is optimized for the usage of one finger only (for touch screens or other smart pointing devices).

PHI Software Licencing

Copyrights on PHI TECHNOLOGY belong to ITAL TBS Group ([1]).

PHI TECHNOLOGY software licensing is constrained by :