Much of the development is being done at Henry Ford Health System, in its Semantic Data Capture Initiative (SDCI) project. As part of this project, we are in the process of deploying the 'PIP stuff' to work with the next generation EHR of Henry Ford. We expect this to happen in early 2010.

Licence

Why EPL?

Because EPL :

is unambiguous
provides freedom to do many things, which will fuel innovation. Healthcare organizations would not want to be shackled down with too many restrictions
will allow the core model and functionalities to become more robust by receiving fixes from other implementations
is compatible with LGPL and several other licenses of the same ilk

Are there any other licenses under which the PIP Project code has been released?

Currently, no. However, in the future we may decide to make it available under other licenses.

Proteus Model

Is the Proteus Model stable?

No, far from it. We are in the process of making some fundamental changes to the model. The new model will provide some exciting capabilities which are not possible with the current one. The key changes will be:

Polymorphism of Proteus Components (see below)
High degree of compatibility with standards like HL7 v3 and ISO/IEC 11179
XML as the 'native' format for representing KCs

These will lead to greater ease of editing, collaborative editing, more interoperability, more reusability, and semantic searching/navigation of knowledge repository.

What will happen to the existing Guidelines and Knowledge Components when the shift to the new version of model takes place?

Since the model change will lead to change in data design, the current guidelines and KCs will become incompatible with the newer versions of tools and model. However, we will also develop tools to allow migration of the existing knowledge base to the newer version so that you can use them with these enhance capabilities.

What is Polymorphism?

We co-opt the term from the Object Oriented design universe. However, it could also be said to be inspired by the biological concept of the same name.

In the Proteus world, it simply means that the same component can be expressed as any of the Proteus component variations and will behave differently based upon the context in which it is placed. For example, Diagnosis of Diabetes, which is originally specified as a process KC, if placed in an atomic KC, will behave as a data element component. Similarly, a data element can be turned into a process KC by simply turning on a switch and changing its context. Obviously you will need to add some process related information to the component, so that it does what you want it to do, but at least you won't have to create the component from scratch.

Exciting, isn't it?

Protean - The Proteus Process Authoring Tool

Proteus Engine

GreEd - The Rule Authoring System

Shouldn't GreEd be a separate tool?

We couldn't agree more.

GreEd is in the process of being separated from Protean, even as we speak. We see great potential for GreEd as a generic Business Rules Management System, which will work with any of the popular rule engines.

Integration with an EHR

How can I make Proteus Engine and GreEd run with our EHR?

Good things come to those who wait.

In the SDCI project of HFHS we are doing exactly this. Even though, the SDCI project is for making Proteus and GreEd work with Henry Ford's system, the tools and adapters developed will be generic enough to allow other systems to exploit their functionality. We will be creating tools to facilitate such integration.

There is also a sister Kenai project that is dedicated to this effort. Since it is still in early stages, we do not like to crow about it. But soon we will be shouting about it too.

Keep your eyes open.