CorePoint, any Pro’s or Con’s?

[Ronald Ortiz]

We are interested in maybe going to Corepoint, and we’ve heard lots of “pro’s”…but no “con’s” to going with Corepoint.  I wanted to know what all everyone here has heard or experienced.  

We are on Cloverleaf 5.8.4 OP, with 110 interfaces.

Topic

[James Cobane]

I would be curious as to why you are considering switching.

Jim Cobane

Henry Ford Health

[Ronald Ortiz]

James Cobane wrote:

I would be curious as to why you are considering switching.

Jim Cobane

Henry Ford Health

They seem to be very feature rich.  For example, they can build an HL7 profile based on sample messages, and this profile sounds like it basically builds the xlate for you.  

You can also test messages against the profile to see if there are differences.  Another area that seems cool is that you don’t need to build TCL code.  They have a libraries features that seem to perform anything you would do with TCL.  And if they don’t…they build it for you (for free I think).  

They also provide metric on the data passing through the engine.  Which is something Cloverleaf doesn’t do on it’s own without your own code.

But again, this comes mostly from their website.  So I’m curious to know if anyone has heard anything bad about Corepoint.

[James Cobane]

Hi Ronald,

I have not worked with the CorePoint engine, so I can’t speak to its capabilities or usability.

[Jim Kosloskey]

Only runs on Windows platform.

If you need to extend (every engine needs to be extended), have to use C# instead of Tcl.

Above not necessarily ‘bad’ depending on your point of view.

Building message structures from sample data very flaky in my opinion since the sample may not be representative of the potential just representative of the sample. What happens the first time the vendor decides to use a segment or field they have always been able to use but just have not?

The most time spent in any integration is getting a full understanding of what is provided by the sending system and what is needed by the receiving system.. Sometimes that time is spent up front and sometimes short cuts are taken and that discovery goes on for years (it falsely looks like the project deployed quickly however). Of course you need to work through the falsehoods of the vendor specs as well.

The amount of time actually working in the engine is incredibly short if the upfront work is done (I have accomplished fairly complex Integrations once the spec is finalized in a couple of days tops using the full Cloverleaf toolset  – no BULKCOPY or Raw Route and little or n PATHCOPY with deep ITERATES). I think that is pretty fast..

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jeff Dinsmore]

I implemented Corepoint’s engine at my previous hospital to replace an in-house developed engine (which had previously replaced a poorly built/maintained copy of Cloverleaf running on DGUX).

There are some things that Corepoint does very well.

One is the building of HL7 variants from a sample set of HL7 (large sample=good variant).

Another is their DB integration. That is very slick – and part of the base product, as I recall.  I found myself doing a lot of my custom code with SQL stored procedures.

As long as your interface task fits within the standard toolkit, you’ll be fine.  That model works very well for some.  However, I fairly frequently needed/wanted to do something creative, and I felt like my hands were tied.  Some seemingly simple tasks took lots of steps.

The interface analyst is insulated from most of the workings of the Corepoint engine.  That’s a Very Desirable Thing for some, but I felt a bit fenced in.

The bottom line is that Corepoint makes a solid engine with lots of nice features (like a tool to bundle a test interface up with all of its components that can be installed in Live with a single click), but for me, Cloverleaf works like I think.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Ronald Ortiz]

Jim Kosloskey wrote:

Only runs on Windows platform.

If you need to extend (every engine needs to be extended), have to use C# instead of Tcl.

Above not necessarily ‘bad’ depending on your point of view.

Building message structures from sample data very flaky in my opinion since the sample may not be representative of the potential just representative of the sample. What happens the first time the vendor decides to use a segment or field they have always been able to use but just have not?

The most time spent in any integration is getting a full understanding of what is provided by the sending system and what is needed by the receiving system.. Sometimes that time is spent up front and sometimes short cuts are taken and that discovery goes on for years (it falsely looks like the project deployed quickly however). Of course you need to work through the falsehoods of the vendor specs as well.

The amount of time actually working in the engine is incredibly short if the upfront work is done (I have accomplished fairly complex Integrations once the spec is finalized in a couple of days tops using the full Cloverleaf toolset

[Ronald Ortiz]

Jeff W Dinsmore wrote:

I implemented Corepoint’s engine at my previous hospital to replace an in-house developed engine (which had previously replaced a poorly built/maintained copy of Cloverleaf running on DGUX).

There are some things that Corepoint does very well.

One is the building of HL7 variants from a sample set of HL7 (large sample=good variant).

Another is their DB integration. That is very slick – and part of the base product, as I recall.

[Jeff Dinsmore]

As I recall, Corepoint’s position was that while you COULD build your own custom code, that you won’t NEED to because the engine is so capable.

I didn’t put that to the test since I left while the Corepoint implementation was relatively new, but I remain skeptical.  I think as you start to build more imaginative integrations, you’d probably bump up against that more often.

Like I said, a lot of customization can be done with SQL, but that’s not my preferred method.

I don’t recall them saying that they’d develop tools as needed for customers.  Perhaps that’s new over the last few years as people are figuring out what Corepoint doesn’t do well.

I find it very easy to get my fingers into the Cloverleaf pie, but I’m very comfortable with TCL and not with C#, so it’s probably not a fair comparison, but I find Cloverleaf more extensibilty friendly.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Rehman Masood]

I have some extensive experience with CorePoint. It is a interface engine that can be used by alot more people where as Cloverleaf is somewhat geared towards folks who have a programming head.

The worst thing about CorePoint was how it handled the code base. For example, there was a Test server that contains all the latest objects and then everyone on the team had to sync their personal install of CorePoint with so their local code base was current. So lets say that I am working on an interface, I sync up my computer with Test, then take 2 days to build an interface and meanwhile someone on my team has made an update to some other interface. Now when I try to move my change, I will cause a Fork that requires a manual Resolve which is pretty much useless and a waste of time. God forbid if someone made the change to a object that I was working on, we are in some trouble to figure out how to merge our changes.

Another awkward thing of CorePoint was that its admin console was good for 10-15 interfaces but if you are running 100+ interface, it is not that fast. Sometimes to see what an interface sent 10 days ago could take 2-3 hours for me to find.

Other then that, the use of the tool is fine. It can do everything Cloverleaf can do and you won’t have to write any programming. You have to pretty strong in regular expressions if you are doing some complicated as regular expressions are used quite often.

One thing that striked me odd was that they renamed everything in CorePoint. Like, we all know what translation table. Cloverleaf calls it Table, Rhapsody calls is Table, Bridges calls it Table, OpenLink calls it Table. Well, not CorePoint. You create 2 Code Sets and then link them together to create a Correlation; that is your table.  

In the end, I would choose Cloverleaf anytime over CorePoint but dont mind working in it. I will try to see if I can find one of the action lists I created and if it doesnt contain anything PHI related, I will post up here so people can see what they look like.

[Brian Goad]

I do not have extensive experience, but have worked on it some. To me the biggest draw back was the OS. I am of the opinion that if you want a work horse you need to be on something other than Windows. You will just not get the performance and reliability on that platform.

It was very intuitive to use, I agree with Jeff D about the hands being tied. Charlie B once told me hated software that tried to “help”. I agree the more I come across those examples. I know what I want and how to do it, now get out of the way and let me build it 🙂

my 2 cents for what it is worth.

[Ronald Ortiz]

Rehman Masood wrote:

I have some extensive experience with CorePoint. It is a interface engine that can be used by alot more people where as Cloverleaf is somewhat geared towards folks who have a programming head.

The worst thing about CorePoint was how it handled the code base. For example, there was a Test server that contains all the latest objects and then everyone on the team had to sync their personal install of CorePoint with so their local code base was current. So lets say that I am working on an interface, I sync up my computer with Test, then take 2 days to build an interface and meanwhile someone on my team has made an update to some other interface. Now when I try to move my change, I will cause a Fork that requires a manual Resolve which is pretty much useless and a waste of time. God forbid if someone made the change to a object that I was working on, we are in some trouble to figure out how to merge our changes.

Another awkward thing of CorePoint was that its admin console was good for 10-15 interfaces but if you are running 100+ interface, it is not that fast. Sometimes to see what an interface sent 10 days ago could take 2-3 hours for me to find.

Other then that, the use of the tool is fine. It can do everything Cloverleaf can do and you won’t have to write any programming. You have to pretty strong in regular expressions if you are doing some complicated as regular expressions are used quite often.

One thing that striked me odd was that they renamed everything in CorePoint. Like, we all know what translation table. Cloverleaf calls it Table, Rhapsody calls is Table, Bridges calls it Table, OpenLink calls it Table. Well, not CorePoint. You create 2 Code Sets and then link them together to create a Correlation; that is your table.

[Rob Abbott]

Interesting discussion here 🙂

A couple points

– We released a HL7 variant builder with Cloverleaf 6.1.  It’s worth having a look at if you’re looking at an automated way to create your variants.  It follows the “more data = better variant” model.

– Cloverleaf 6.0 (and enhanced in 6.1) has GUI-driven database integration as part of the base product.

Rob Abbott
Cloverleaf Emeritus

[Ronald Ortiz]

Rob Abbott wrote:

Interesting discussion here 🙂

A couple points

– We released a HL7 variant builder with Cloverleaf 6.1.

[Author]

Replies