PACS 2.0

Dalai has a post about PACS customization that touches on something that I have been thinking about. The current state of what vendors call customization is sadly pathetic. Changing some options is not customization. The first and most basic method of customization is being able to build completely custom UIs. This goes far beyond hanging protocols and would allow the user to alter any visual element in the PACS. The second is having an open and documented API for third party software developers to build software that runs inside or on top of the PACS. This is a toolkit for programmers. The third would be a widget like interface, something like Google IG or netvibes. This would allow power users who are not software developers but are comfortable with editing HTML or other markup languages to make addins and UI widgets.

Why would a PACS vendor ever offer such a thing? Well why does Microsoft allow anyone to write software that runs ontop of Microsoft Office? The reason is simple. Software that is built as a platform is much more valuable than a standalone application. Open source office software is not going to have trouble trying to take market share from Microsoft Office because it is not as good, but rather because vendors and organizations have built thousands of pieces of software that add value to Microsoft Office, making it much more valuable than what comes out of the box.

The first PACS vendor to treat their PACS like a platform will have a real advantage. A good platform is hard to replicate. It is a strong competitive advantage. Do I see this happening? No. PACS companies are too busy replicating each others features to think about truly changing the industry. This is one time where a company should lead its users.

Technorati Tags: , , ,

  1. As in my article, I think this is a great idea, but I am really worried as to how it will be implemented in places like mine. How do you see this happening?

  2. The actual problem is that I do not see this happening. There are no companies in the market that I can see that would embark on a strategy such as this. As you have clearly shown many companies have trouble building user friendly applications. Also large companies have a hard time innovating since they have established products and customers. If a serious open source competitor emerges they might include this functionality but I really don’t expect that to happen. The integration of 3D into PACS systems over the next couple of years is going to seriously raise the technology bar of what is required in a modern PACS system. If you want to see what the future looks like look at TeraRecon’s intuition product.


  3. yes, there is great incentive for vendors to take on the platform approach. you pointed out a great example with msft office. another successful example is google maps api that has enabled the development of mashups.

  4. I agree with google maps although it is different in that google has not monetized the API. Microsoft has very effectively locked people into office with their API. has also achieved some level of lockin using their AppExchange API.

  5. What about FDA regulations? MS Office is not regulated by a body that can criminally prosecute you for changing software without proper change control or testing. Let’s say a user modifies the display of user information and it gets out of sync with images, or it puts the wrong data up for whatever reason. This results in misdiagnoses and you know the rest. Who is liable? And who wants to take that chance?

    I agree that customization is important, as is the ability for 3rd party vendors to have access but there are many other considerations.

  6. Matt, the problem you describe with liability issues is already possible even with the limited capabilities of integration APIs for PACS. If such an incident were to occur blame could only be assessed and liability determined after an investigation to establish the event’s root cause.

  7. The idea that liabilities are going to be greatly increased in actuality is something that I do not agree with. As Michael points out that can happen now with the limited APIs that are available. As for the FDA, I have only seen the problem that you describe, images and meta data out of sync, on an FDA validated system. FDA regulations are not effective since there is no in depth testing of a system under production conditions.

    People who make mashups would be responsible for testing them. I think that the mashups will show that there are far more cracks in the foundation of PACS and that most PACS systems are very poorly written systems.

    I would expect that vendors could at least enable mashups or have a plan to add information to the inside of their software.


  8. Steve,
    PACS 2.0 is a great idea! I love the idea of a PACS Platform. Your readers have started thinking in the right direction. It was intresting to note that “liabilities”amongst the first hurdles/barriers to entry. Like you had stated- That is something that can be resolved throgh an apprporiate testing and documentation schedule. The greater challenges are in identifying the right technologies to envision this platform. The Web ( internet) is definately a starting point . leading PACS vendors have started focussing their efforts on Web Based PACS systems ( Fuji’s Synapse is the front runner in putting all the thought- their AON compression mechanism is something that gives them a competitive advantage over other leading vendors), McKesson’s Horizon Imaging Group has the HRS 11D ( Horizon Rad Station (WEB) that is also fast agining some clout.
    What are the technologies/Platforms that hold the key to the problem( AJAX, RUBY, etc)? How can it be standardized? I am a keen student of this business and i do see the imaging sector going this route in the future.. . distant but sure future. . ..Let us isolate the true economic neccessity for this platform and we can start finding a way!. . counterpoint to that belief is in the adgae “build and they will come”
    let watch out pacs2.0 and welcome it with open arms
    BTB: I liked yootalook. . good work. . .good luck. . wish you all success!

  9. Hi Steve,

    I enjoyed reading through you posts (just discovered your blog today), and wanted to respond to this thread in particular even though the original post is more than a year old.

    We are not a PACS company per se. Since early 2006, however, we’ve been contracted to build an open source RIS/PACS for a major teaching hospital here in Canada. We’re projecting that we will completed most of the deployment by the middle of 2009.

    The reason I’m posting, is because the RIS/PACS we are building is designed to be extended by 3rd parties. Although UI customization in our case cannot be as easy as you’ve described, it is possible through our separation-of-concerns approach to the architecture (which was also designed because we want to maintain cross-platform ability in the future).

    Extensibility is achieved through a very flexible plug-in architecture. The “boundary” around the core system as we have defined it, is documented in our SDK. In principle, however, almost the entire application can be changed and customized, if you know how to write software.

    I’ve move away from the product development responsibilities to involve myself more with the business development side of things, and that’s why I’m combing the net for information. It was nice to find and read your blog.

    Clinton Chau

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>