2006-02-26 00:00:00

Health Wonk Review: A healthcare policy, technology, and business blogs carnival

Joe Paduda, Matthew Holt, and others have started the Healthcare Policy, Business, Technology & “Non-clinical” Issues Carnival called Health Wonk Review. Here’s how Matthew described the new Carnival:

Inspired by the Nick doing Grand Rounds, Joe Paduda at Managed Care Matters has put together the first bi-weekly edition of a compendium of the best of blogging about health care policy, business, technology and anything that isn???t really clinical in nature. We???re hoping that it???s going to be a companion to the main Grand Rounds and that it???ll be a place to find some of the best insight into our evolving health care system. And while Joe kindly calls me a co-founder, and I will be hosting in two weeks, this is all his work and he gets the plaudits.

Filed under: — @ 2006-02-26 00:00:00
2006-02-26 00:00:00

Health Wonk Review: A healthcare policy, technology, and business blogs carnival

Joe Paduda, Matthew Holt, and others have started the Healthcare Policy, Business, Technology & “Non-clinical” Issues Carnival called Health Wonk Review. Here’s how Matthew described the new Carnival:

Inspired by the Nick doing Grand Rounds, Joe Paduda at Managed Care Matters has put together the first bi-weekly edition of a compendium of the best of blogging about health care policy, business, technology and anything that isn???t really clinical in nature. We???re hoping that it???s going to be a companion to the main Grand Rounds and that it???ll be a place to find some of the best insight into our evolving health care system. And while Joe kindly calls me a co-founder, and I will be hosting in two weeks, this is all his work and he gets the plaudits.

Filed under: — @ 2006-02-26 00:00:00
2006-02-25 00:00:00

Securing Your Desktops from Pod Slurping

The EMR and HIPAA blog has posted additional information on “pod slurping”: Securing Your Desktops - Pod Slurping. He’s started a good discussion out there and we should join in to see if we can talk about policies health IT shops should put into place.

Filed under: — @ 2006-02-25 00:00:00
2006-02-25 00:00:00

Securing Your Desktops from Pod Slurping

The EMR and HIPAA blog has posted additional information on “pod slurping”: Securing Your Desktops - Pod Slurping. He’s started a good discussion out there and we should join in to see if we can talk about policies health IT shops should put into place.

Filed under: — @ 2006-02-25 00:00:00
2006-02-23 00:00:00

Best language for secure healthcare applications

I got an email from a reader recently, asking:

I have a quick question - I was wondering if there is a programming language that is viewed as ‘more secure’ for patient data compared with others? I am building a program to collect patient health info, and am in the very early stages of planning. I used Java previously that worked well for a very sophisticated algorithm to mine data, but this new application is very simple (basically a questionairre) and I have heard .NET would be best.

Given that the question is quite common based on all the startups I advise and speak with, I thought answering here might be helpful to you.

When it comes to .NET versus Java (or really any language) neither is “more secure” than the other with respect to patient data. They are pretty much equal if your engineers are highly qualified and your architecture and design is sound. If you have good software developers, they will almost always create a solid architecture and good design which will make the language selection play a small role in the general quality of your product.

It boils down to what your developers know best and what will make the fewest defects with ??? for example, if your guys know C# very they will make less errors and therefore fewer security holes. If they know Java better, then of course they’ll make fewer errors in that language. There is no “best choice” for everyone, it’s really dependent on experience, tools, and platforms.

If you want to run on different platforms and don’t have very rich UI needs, Java is a good choice. If it only needs to run best on Windows and has rich UI requirements, .NET is a good choice. That’s a simplistic view but pretty applicable in the general case. Also, give Ruby and Rails a try (see my earlier article about that).

One mistake that I see people making over and over again is choosing a language first then deciding what to build and going out to hire engineers. What you really should do is to be sure you know what you’re building, who your customer is, how your application will be used by them, and all the other “soft” issues related to the utility of what you’re creating. Then, get a good software architect to lay out a proper architecture, get some good designs and algorithms in place, and finally choose a language. Once you have done the up front work your choice of lanugage becomes clearer because you really, really want to choose people and architecture first then choose a language. It’s not easy to find bright architects and engineers who can really build things — once you have the right folks the language isn’t as important.

By the way, “just outsource it to India” is not the right approach either :-) .

Filed under: — @ 2006-02-23 00:00:00
2006-02-23 00:00:00

Why vendors don’t implement CCOW in legacy systems

Wheelybop, A HIStalk reader, recently posed a question:

Can you or your blogger network describe to me what vendors have to do to make their legacy products CCOW compliant and why some refuse to do so, what are pros/cons, etc. Would love a CCOW primer or be pointed to such.

First, lets tackle the primer. The acronym CCOW stands for “Clinical Context Object Workgroup”, a reference to the standards committee within the HL7 group that developed the standard. CCOW is a standard designed to allow information sharing between clinical and health IT applications. It uses a basic technique called “context sharing” that allows multiple clinical applications to “switch contexts” simultaneously. A “context” is a computer science term that could mean a patient’s data screen or an encounter form. Multiple CCOW compliant applications can simultaneously change their screens to see the same patient’s data when any of the other participating applications do so. For example, if a hospital can get their labs, EMR, and CPOE vendors to become CCOW compliant they can share to share patient context instead of the user having to log in and out of each application separately.

Ok, that’s the intro. There’s more at CCOW vendor (like NeoTool, Sentillion, etc) websites you can read but the above is pretty much what you’ll get there as well.

Now, to answer the reader’s original question: why don’t legacy vendors support it? The simple answer is that CCOW provides no real value to them. Legacy vendors rarely benefit from migrating and supporting new standards, regardless of what it is. CCOW is good for new entrants into the health IT field — for example, if I’m a startup and I write a new app I would definitely want to be CCOW compliant because CIOs won’t like me unless I’m interoperable with their legacy systems. However, legacy vendors have neither the inclination nor the customer outcry necessary to become interoperable with new software. They are already in the customer’s shop and don’t need to support the new standard to make more sales. The larger you are, the more entreanched you are in your customers’ shops, the less you need to “play nice” with other vendors.

Of course, there are many benefits to becoming CCOW compliant. However, none of those benefits apply to the vendor itslef. The benefits are all for the user and for the IT shop that can help users streamline their work.

So, don’t expect CCOW compliance from the legacy vendors anytime soon. :-)

Filed under: — @ 2006-02-23 00:00:00
2006-02-23 00:00:00

Best language for secure healthcare applications

I got an email from a reader recently, asking:

I have a quick question - I was wondering if there is a programming language that is viewed as ‘more secure’ for patient data compared with others? I am building a program to collect patient health info, and am in the very early stages of planning. I used Java previously that worked well for a very sophisticated algorithm to mine data, but this new application is very simple (basically a questionairre) and I have heard .NET would be best.

Given that the question is quite common based on all the startups I advise and speak with, I thought answering here might be helpful to you.

When it comes to .NET versus Java (or really any language) neither is “more secure” than the other with respect to patient data. They are pretty much equal if your engineers are highly qualified and your architecture and design is sound. If you have good software developers, they will almost always create a solid architecture and good design which will make the language selection play a small role in the general quality of your product.

It boils down to what your developers know best and what will make the fewest defects with ??? for example, if your guys know C# very they will make less errors and therefore fewer security holes. If they know Java better, then of course they’ll make fewer errors in that language. There is no “best choice” for everyone, it’s really dependent on experience, tools, and platforms.

If you want to run on different platforms and don’t have very rich UI needs, Java is a good choice. If it only needs to run best on Windows and has rich UI requirements, .NET is a good choice. That’s a simplistic view but pretty applicable in the general case. Also, give Ruby and Rails a try (see my earlier article about that).

One mistake that I see people making over and over again is choosing a language first then deciding what to build and going out to hire engineers. What you really should do is to be sure you know what you’re building, who your customer is, how your application will be used by them, and all the other “soft” issues related to the utility of what you’re creating. Then, get a good software architect to lay out a proper architecture, get some good designs and algorithms in place, and finally choose a language. Once you have done the up front work your choice of lanugage becomes clearer because you really, really want to choose people and architecture first then choose a language. It’s not easy to find bright architects and engineers who can really build things — once you have the right folks the language isn’t as important.

By the way, “just outsource it to India” is not the right approach either :-) .

Filed under: — @ 2006-02-23 00:00:00
2006-02-23 00:00:00

Why vendors don’t implement CCOW in legacy systems

Wheelybop, A HIStalk reader, recently posed a question:

Can you or your blogger network describe to me what vendors have to do to make their legacy products CCOW compliant and why some refuse to do so, what are pros/cons, etc. Would love a CCOW primer or be pointed to such.

First, lets tackle the primer. The acronym CCOW stands for “Clinical Context Object Workgroup”, a reference to the standards committee within the HL7 group that developed the standard. CCOW is a standard designed to allow information sharing between clinical and health IT applications. It uses a basic technique called “context sharing” that allows multiple clinical applications to “switch contexts” simultaneously. A “context” is a computer science term that could mean a patient’s data screen or an encounter form. Multiple CCOW compliant applications can simultaneously change their screens to see the same patient’s data when any of the other participating applications do so. For example, if a hospital can get their labs, EMR, and CPOE vendors to become CCOW compliant they can share to share patient context instead of the user having to log in and out of each application separately.

Ok, that’s the intro. There’s more at CCOW vendor (like NeoTool, Sentillion, etc) websites you can read but the above is pretty much what you’ll get there as well.

Now, to answer the reader’s original question: why don’t legacy vendors support it? The simple answer is that CCOW provides no real value to them. Legacy vendors rarely benefit from migrating and supporting new standards, regardless of what it is. CCOW is good for new entrants into the health IT field — for example, if I’m a startup and I write a new app I would definitely want to be CCOW compliant because CIOs won’t like me unless I’m interoperable with their legacy systems. However, legacy vendors have neither the inclination nor the customer outcry necessary to become interoperable with new software. They are already in the customer’s shop and don’t need to support the new standard to make more sales. The larger you are, the more entreanched you are in your customers’ shops, the less you need to “play nice” with other vendors.

Of course, there are many benefits to becoming CCOW compliant. However, none of those benefits apply to the vendor itslef. The benefits are all for the user and for the IT shop that can help users streamline their work.

So, don’t expect CCOW compliance from the legacy vendors anytime soon. :-)

Filed under: — @ 2006-02-23 00:00:00
2006-02-20 00:00:00

Beware the ‘pod slurping’ employee

I wrote about “pod slurping” a few weeks ago but cNet News.com did a better job.

CIOs of hospitals and healthcare IT managers need to pay attention to what they said:

A U.S. security expert who devised an application that can fill an iPod with business-critical data in a matter of minutes is urging companies to address the very real threat of data theft.

Abe Usher, a 10-year veteran of the security industry, created an application that runs on an iPod and can search corporate networks for files likely to contain business-critical data. At a rate of about 100MB every couple minutes, it can scan and download the files onto the portable storage units in a process dubbed “pod slurping.”

To the naked eye, somebody doing this would look like any other employee listening to their iPod at their desk. Alternatively, the person stealing data need not even have access to a keyboard but can simply plug into a USB port on any active machine.

There are no reports yet of pod slurping harming healthcare data yet but with the growing number of interns, nurses, patients, and doctors with iPods it’s only a matter of time.

When I worked for the Red Cross a couple of years ago we did a study of how donors could get data out of networked Red Cross blood collection computers and we concluded it would have been easy with wireless connections or wired connections with USB thumb drives.

iPods will make it even easier because they are full computing devices held invisbly in pockets.

Do yourself a favor and make sure you set appropriate policy about the use and connectivity of iPods in your health IT environments.

Filed under: — @ 2006-02-20 00:00:00
2006-02-20 00:00:00

Beware the ‘pod slurping’ employee

I wrote about “pod slurping” a few weeks ago but cNet News.com did a better job.

CIOs of hospitals and healthcare IT managers need to pay attention to what they said:

A U.S. security expert who devised an application that can fill an iPod with business-critical data in a matter of minutes is urging companies to address the very real threat of data theft.

Abe Usher, a 10-year veteran of the security industry, created an application that runs on an iPod and can search corporate networks for files likely to contain business-critical data. At a rate of about 100MB every couple minutes, it can scan and download the files onto the portable storage units in a process dubbed “pod slurping.”

To the naked eye, somebody doing this would look like any other employee listening to their iPod at their desk. Alternatively, the person stealing data need not even have access to a keyboard but can simply plug into a USB port on any active machine.

There are no reports yet of pod slurping harming healthcare data yet but with the growing number of interns, nurses, patients, and doctors with iPods it’s only a matter of time.

When I worked for the Red Cross a couple of years ago we did a study of how donors could get data out of networked Red Cross blood collection computers and we concluded it would have been easy with wireless connections or wired connections with USB thumb drives.

iPods will make it even easier because they are full computing devices held invisbly in pockets.

Do yourself a favor and make sure you set appropriate policy about the use and connectivity of iPods in your health IT environments.

Filed under: — @ 2006-02-20 00:00:00
« Previous Page