I'm concerned about downloading applications from the Internet but most people are not. I have friends and family that have the "dancing bunny" syndrome. They'll do whatever it takes to see a dancing bunny. You can add as many warnings, drop-downs, and checkboxes as you can - but they WILL see that dancing bunny. How do you protect users from themselves and all of the malware out there? I'm aware of malware today, how do I know it's safe for my computer to install that application? (Anti-Virus and Anti-Spyware only help during the infection, not in advance of it).
Take it another way, the Package Manager in Ubuntu (or any linux based OS) allows you to add functionality and applications to your computer in a "safe" manner. If I add Firefox via my Package Manager, the distro is controlling the manner in which applications are added into the system in a "safe" and controlled process. Why does the Add in Add/Remove Programs do nothing? Wouldn't it be great if we could have a list of clean and safe applications available online via the Add Programs applet? I should be able to add any single application from the Google Pack, without the Google Pack. Why can't I?
I take no credit, just opinion and advise that can easily be ignored (that's why your holding the mouse).
I've done Java2 and currently do.NET.
HL7 v3 is XML but still has gaps. The full spec isn't done yet but they're getting there. The RIMS are long, complicated, and changing.
State-side, most vendors continue to use the older 2.x versions (2.3-2.4 mostly) since engines/interfaces are expensive and everything's backwards compatible. Even though the 2.3 spec was approved as an ANSI standard in 1997, most people still use it.
Here's your typical argument: 1) It costs hospitals a LOT of money to put up HL7 into production and most are experienced with 2.x to get it up rapidly. 2) Hospitals aren't all new and those that are usually have experienced people who have come from existing hospitals 3) Once a vendor has built something on top of 2.x and it works, what's the incentive to use 3.0 with XML for the exact same functionality.
So just because a hospital CAN get XML with 3.0 doesn't mean they will. Not sure about you, but I've been to several different hospitals - have you noticed how many screens are still green and black? It's because it works!
Yeah - I always get those things messed up. I do a lot of work in Imaging of documents (TWAIN, Imports, File convesions) and less on the medical side (Rad, Card, DICOM, PACS, etc).
The key to smaller offices is not thru HL7 (which is expensive to implement) but by "other means" such as import/export, direct access, etc. Having a platform like.NET allows you the flexibility to connect to many different systems. There's more plug-ins, toolkits, and third-party support for the Windows platform (in general) due to the number of vendors out there. This includes DICOM Image Toolkits, HL7 Engines, etc.
Depends on your implementation and support staff. You could code in Java and still fail, depends on how good you are at not just coding.
I've seen complicated linux/c++ installs fail where Delphi and VMS work (yes, old skool mainframes). Your workflow, interface, up-time, training, support, etc - all that - equals a successful product. Not what IDE you fire up.
Of course, if your starting fresh - why start with COBOL? That was my point. Don't worry about what you pick from the IT side but instead from the "what's the best thing for my product".
I work for a company that just landed a large install to a large hospital system. Here are some points to consider.
My experience...
1) Don't worry about the run-time in terms of a desktop requirement. Since you'll have to install your software, you'll have the opportunity to install the VM.
2) Getting security clearance to run on a hospital system will largely be dependent on your application architecture and not on your application framework. Do you depend on certain ports or services, certain databases, file shares, web services, etc.
3) A majority (overwhelming majority) of these systems do run Windows. If you find Linux in the mix, it'll usually be for very specific systems (PAX/DICOM) or back-end work (your mainframes and such). Due to the large number of small vendors in healthcare, a ton of applications are installed to the clinican's desktop. (And may have simple architectures or older frameworks like VB, Delphi, and even Terminal/Telnet). Everything from intergrated hospital wide systems to what a doctor uses on his own box to manage X, Y, and Z. [hint: look-up CCOW]
4) Integration with an EMR is important, and again, most are Windows based. If you want to feed data into "the system", be prepared to work with the system. EMRs are heavy on HL7, light on Web Services and XML.
5) Depending on your architecture, your GUI/interface and your "server" can be running on different systems, platforms, and/or frameworks. Probably not the best route but it is possible.
General knowledge and opinion...
1) Mono (.NET) for non-Windows applications is just as viable as Java for multi-platform use. You could do.NET AND Mono deployments (or just pick one).
2) Hospitals pay huge $$$ for integrated systems. As such, they will purchase hardware dedicated to your implementation. If your worried about running on their existing OSX servers, don't be - sell them a Dell running Windows 2003 or a black box running RH. Your software will be more expensive than the boxes. You could also just include $2-10K in hardware costs as part of the PO.
I highly recommend going to a trade-show or just talking to vendors "as a 100-300 bed hospital". You can see what others do by being a customer.
Not saying you have to do what everyone else does - but it does help to sell something that won't take a lot to get going.
Section 2 - Windows XP Security Guide Development (17-32) about general networking guidelines and how this guide came to be
Section 3 - Windows Security Components Overview (33-38) with summary notes on the last page (38), the rest was features and footprint
Section 4 - Installation, Backup, and Patching (39-48) consists of advise on running Windows Update, using strong passwords, etc. Notes are again, on the last page.
Section 5 - Overview of the Windows XP Security Policy Configuration and Templates (49-54) explains templates and how to use them.
Section 6 - NIST Windows XP Template Settings Overview (55-66) which explains the templates provided.
Section 7 - Additional Windows XP Configuration Guidance (67-90) is a ton of good content
Section 8 - Application Specific Security Configuration Guidance (91-110)
Section 9 - Putting it All Together (111-112)
Appendix A-F contain resource information not needed to secure your machine but good information to have.
Steps to securing:
Read the last page of Sections 3 and 4, if it's new to you - read the whole thing.
Apply templates using information from Sections 5 and 6 if you don't know how.
Read Section 7.
Section 8 is optional depending on what types of programs you use.
Slashdot Mirror
I'm concerned about downloading applications from the Internet but most people are not. I have friends and family that have the "dancing bunny" syndrome. They'll do whatever it takes to see a dancing bunny. You can add as many warnings, drop-downs, and checkboxes as you can - but they WILL see that dancing bunny. How do you protect users from themselves and all of the malware out there? I'm aware of malware today, how do I know it's safe for my computer to install that application? (Anti-Virus and Anti-Spyware only help during the infection, not in advance of it).
Take it another way, the Package Manager in Ubuntu (or any linux based OS) allows you to add functionality and applications to your computer in a "safe" manner. If I add Firefox via my Package Manager, the distro is controlling the manner in which applications are added into the system in a "safe" and controlled process. Why does the Add in Add/Remove Programs do nothing? Wouldn't it be great if we could have a list of clean and safe applications available online via the Add Programs applet? I should be able to add any single application from the Google Pack, without the Google Pack. Why can't I?
Thoughts?
I take no credit, just opinion and advise that can easily be ignored (that's why your holding the mouse).
.NET.
:)
I've done Java2 and currently do
HL7 v3 is XML but still has gaps. The full spec isn't done yet but they're getting there. The RIMS are long, complicated, and changing.
State-side, most vendors continue to use the older 2.x versions (2.3-2.4 mostly) since engines/interfaces are expensive and everything's backwards compatible. Even though the 2.3 spec was approved as an ANSI standard in 1997, most people still use it.
Here's your typical argument:
1) It costs hospitals a LOT of money to put up HL7 into production and most are experienced with 2.x to get it up rapidly.
2) Hospitals aren't all new and those that are usually have experienced people who have come from existing hospitals
3) Once a vendor has built something on top of 2.x and it works, what's the incentive to use 3.0 with XML for the exact same functionality.
So just because a hospital CAN get XML with 3.0 doesn't mean they will. Not sure about you, but I've been to several different hospitals - have you noticed how many screens are still green and black? It's because it works!
Don't shoot the messenger
Yeah - I always get those things messed up. I do a lot of work in Imaging of documents (TWAIN, Imports, File convesions) and less on the medical side (Rad, Card, DICOM, PACS, etc).
.NET allows you the flexibility to connect to many different systems. There's more plug-ins, toolkits, and third-party support for the Windows platform (in general) due to the number of vendors out there. This includes DICOM Image Toolkits, HL7 Engines, etc.
The key to smaller offices is not thru HL7 (which is expensive to implement) but by "other means" such as import/export, direct access, etc. Having a platform like
Depends on your implementation and support staff. You could code in Java and still fail, depends on how good you are at not just coding.
I've seen complicated linux/c++ installs fail where Delphi and VMS work (yes, old skool mainframes). Your workflow, interface, up-time, training, support, etc - all that - equals a successful product. Not what IDE you fire up.
Of course, if your starting fresh - why start with COBOL? That was my point. Don't worry about what you pick from the IT side but instead from the "what's the best thing for my product".
I work for a company that just landed a large install to a large hospital system. Here are some points to consider.
.NET AND Mono deployments (or just pick one).
My experience...
1) Don't worry about the run-time in terms of a desktop requirement. Since you'll have to install your software, you'll have the opportunity to install the VM.
2) Getting security clearance to run on a hospital system will largely be dependent on your application architecture and not on your application framework. Do you depend on certain ports or services, certain databases, file shares, web services, etc.
3) A majority (overwhelming majority) of these systems do run Windows. If you find Linux in the mix, it'll usually be for very specific systems (PAX/DICOM) or back-end work (your mainframes and such). Due to the large number of small vendors in healthcare, a ton of applications are installed to the clinican's desktop. (And may have simple architectures or older frameworks like VB, Delphi, and even Terminal/Telnet). Everything from intergrated hospital wide systems to what a doctor uses on his own box to manage X, Y, and Z. [hint: look-up CCOW]
4) Integration with an EMR is important, and again, most are Windows based. If you want to feed data into "the system", be prepared to work with the system. EMRs are heavy on HL7, light on Web Services and XML.
5) Depending on your architecture, your GUI/interface and your "server" can be running on different systems, platforms, and/or frameworks. Probably not the best route but it is possible.
General knowledge and opinion...
1) Mono (.NET) for non-Windows applications is just as viable as Java for multi-platform use. You could do
2) Hospitals pay huge $$$ for integrated systems. As such, they will purchase hardware dedicated to your implementation. If your worried about running on their existing OSX servers, don't be - sell them a Dell running Windows 2003 or a black box running RH. Your software will be more expensive than the boxes. You could also just include $2-10K in hardware costs as part of the PO.
I highly recommend going to a trade-show or just talking to vendors "as a 100-300 bed hospital". You can see what others do by being a customer.
Not saying you have to do what everyone else does - but it does help to sell something that won't take a lot to get going.
- Section 1 - Introduction (15-16)
- Section 2 - Windows XP Security Guide Development (17-32) about general networking guidelines and how this guide came to be
- Section 3 - Windows Security Components Overview (33-38) with summary notes on the last page (38), the rest was features and footprint
- Section 4 - Installation, Backup, and Patching (39-48) consists of advise on running Windows Update, using strong passwords, etc. Notes are again, on the last page.
- Section 5 - Overview of the Windows XP Security Policy Configuration and Templates (49-54) explains templates and how to use them.
- Section 6 - NIST Windows XP Template Settings Overview (55-66) which explains the templates provided.
- Section 7 - Additional Windows XP Configuration Guidance (67-90) is a ton of good content
- Section 8 - Application Specific Security Configuration Guidance (91-110)
- Section 9 - Putting it All Together (111-112)
- Appendix A-F contain resource information not needed to secure your machine but good information to have.
Steps to securing:Read the last page of Sections 3 and 4, if it's new to you - read the whole thing.
Apply templates using information from Sections 5 and 6 if you don't know how.
Read Section 7.
Section 8 is optional depending on what types of programs you use.
Required reading: 25 pages