Push Pull

in .NET, Reactive Framework provides great async programming model. More details @ Reactive Framework

Evolution of Data and UI

Healthcare Interoperability 101

In the US healthcare, there is a lot of buzz around "Interoperability". Mostly driven by standardization bodies and vendors, this discussion is lost in translation. Just count number of standards, HL7, LOINC, SNOMED, DICOM, CDA, AJCC, FORDS, etc. Don't worry if you don't know a few of these standards – Google will lead you in the right direction.

For system integrators, challenge is in synchronizing the relevant information and to facilitate the prompt decision making. Mostly the source data is stored in a relational format in the underlying RDBMS systems like SQL Server, Oracle, DB2, MySQL etc. In some cases, data is stored in legacy systems on mainframe computers in EBCDIC format. For example VistA, the Veteran Administration's aging Electronic Health Records (EHR) system written in MUMPS.

A good analogy would be to compare healthcare interoperability landscape with the United Nations General Assembly. In the UN, we have more than 150 countries and their representative speaking in hundreds of different languages and numerous dialects. Everyone is concerned with "Global Peace". And as was explained by one UN employee, the challenge is to establish the common ground, and ensuring that the message is not lost in translation. We in healthcare are facing the same challenge – for us, it's an interoperability challenge. For system healthcare integrators, interoperability is an ongoing struggle. Consider the following figure


Figure above represents the simplistic view of diverse message formats used in every day healthcare information exchange. Many expert working groups are investing a lot of time and energy in formulating these standards, and keeping them up to date. Most of these messages carry almost identical information like patient demographics, albeit in its own format. For example, X12 Eligibility request and HL7 patient demographics information. In the source data store, patient information will mostly be stored in the same location. Challenge is in figuring out the real cost of supporting these diverse message sets for system integrators like EMR/EHR vendors, and for the end users like providers and hospitals?

Time and again, these standards are presented as panacea for all healthcare data integration issues. Each group claims universal support and wide adoption on their website, and vendors supporting them use it wherever possible. Challenging or questioning their relevance is a sin. From BI system to PACS vendors, everyone is driving this bandwagon. IMHO, standards can resolve an interoperability issue is a myth. Standards are part of this puzzle but not the puzzle itself.

Another issue in interoperability domain is related to the special cases / exceptions. For example, In the US labs market, LOINC is a well established standard. But there are some reference labs where LOINC is not a good enough solution. So we end up with the broken system in which we implement LOINC plus custom codes. It's like writing 90% of the blog post in English with remaining 10% in some other foreign language. Supporting such special requests breaks the interop logic flow. At the implementation level, such requests are either implemented via lookup tables or through custom logic built inside the interop / rules engine.

Finally, the uniqueness of healthcare presents its own challenge. Consider the specialty like cancer care and in that specialty, a very specialized vertical like Brest Cancer treatment. Brest Cancer treatment and survival statistics reporting demands some special attention. Hence, we end up with FORDS - Facility Oncology Registry Data Standard. FORDS provides definitions and detailed instructions for coding patient diagnosis, treatment, and outcomes. Now, standards like FORDS play an important role in the cancer treatment domain. But for the system integrators, this is one more message format to deal with. In the end, we have to deal with multitude of interoperability challenges as explained below

Conclusion

Interoperability requirements will evolve with time. No one standard / group should try to design "Grand Daddy" of all these systems. Any such attempt will create a gynormous blueprint, practically impossible to implement.

References

1. Principles of Health Interoperability HL7 and SNOMED

What type of company are you working for?

No great company can be built on revenue model – everything should start with product. Apple, BMW, and GE – everybody had a great product and then they built revenue model around it. If we drive our development to catch up with revenue, we will be in catch-up game all the time. We will end up adding a lot of functionality for anybody who wants to buy. Every opportunity is billion dollar one and every customer is God! We get it, but if we don’t know where we want to go – any road will take us there…

Are you working for a product driven company or revenue driven one? Answers are not simple as revenue will drive the product, and product will generate revenue. But there is a litmus test, if your short term plan is in flux and you bump on new keyword every three to five weeks, chances are you are driven by sales organization. If you have people talking about same technology for long time, and have a capacity built around it, then you are working for a product driven company.

For example, iPhone, Google, ebay was not built to make millions / billions and 110% growth. First the product was designed and developed followed by growth. Now anybody trying to catch–up with these companies are investing 10 bucks, and want 40 back in two years. And we all know where this strategy is going.

Alas! We know – We understand and then We ignore…what type of company are you working for?

Gen next coming

Barbie The Computer Engineer...

Freash from Boot Camp

I just got back from Silverlight 4.0 Microsoft boot camp. It was great experience [much better than a three day conference]. OOB,MEF,RIA web service,isolated storage,local mesh and much more...

What we saw in these four days in Redmond is really amazing, and talking to silverlight dev team was a great experience.Friends, river of possibilities is flowing high - its just a matter of jumping in and being part of the fun ride...

I am working on a silverlight 4 test app. Will blog a bout it when its ready.

Till then, have fun, stay in touch and be safe!

Ciao!

Design 101

I was reading "Dreaming in Code" and thinking about many project I worked on in my career...

And the thought of production tragedy kept coming at me. So finally got it...

When Design is a disaster and Implementation is catastrophe - production will be Tragedy!