Let me try and paint a picture, let’s see if this applies to any of you:
- I have many portals, mostly provided by the line of business application vendors, that do not talk to each other
- I can look at the information in the portal, but on order to change it I need to go back to the original application
- I have multiple applications that do not talk to each other and require duplicate data input or fail to leverage data that is in other systems
- I want/need to participate in community, regional or national information sharing efforts, but I cannot even have a cohesive information integration strategy within my enterprise
- I don’t have a coherent architecture strategy, but rather a patchwork of siloed applications
- I’m having trouble integrating multiple applications on multiple platforms and rewiring the workflows based on changing requirements and goals
- I’m stuck with HL7 v2.x
If you can recognize at least one of the problems, we might have something for you, so keep reading 🙂
The main objectives for the Connected Health Framework are:
- Highlight a series of best practices for service oriented health information and collaboration architecture
- Enable the development of an ecosystems of solutions developed along these guidelines
The reason why portals today are largely a “look-but-no-touch” experience is because the information you see was pried out of applications that were never meant to support this type of bidirectional interaction. In fact there is usually no way to put the data back in without compromising the integrity of the application’s database or totally bypassing the business rules checks provided by the user interface.
Applications built according to modern SOA practices expose services, in addition to user interfaces, that allow for other systems to interact with them at a much deeper level.
The Connected Health Framework discusses how to build these systems to maximize interoperability and composability of services and business components.
In that sense the Connected Health Framework has little to do with the Microsoft platform and I’m sure you’ll find great material even if you’re 100% Java shop. The point is really about making these services and business components interact with each other on a much more profound basis, regardless of the platform upon which they are built.
The other key point is that you do not need a healthcare-specific architecture to solve healthcare problems. The architecture of your systems should be based on cross industry best practices that transcend the specific vertical. What makes a solution specific to healthcare is the type of messages that are exchanged, the security and policies for authentication, authorization and information access and of course the nature of services and business components.
We’ve been discussing the Connected Health Framework with customers and partners since early this year. I am happy to announce that the final content is now published for your review and comment:
- Connected Health Framework – Executive Whitepaper
- Connected Health Framework Architecture and Design Blueprint
The documents are hosted on the Solution Sharing Network web site.
We would like to have a broader community input on the material and we’ll incorporate that feedback in subsequent releases. So, please share your thoughts on the SolShare.net healthcare forums, I’ll be there too.
This was a collective effort from a number of people around the world, both from Microsoft and the industry. I’d like to thank all the people that contributed to releasing the Connected Health Framework Architecture and Design Blueprint and all of you that will spend time putting it to work and making it better.
[Update] The landing page for the Connected Health Framework on microsoft.com is here.