MEDICAL DEVICES: Special Considerations

By Staff Reporters

***

***

INFORMATION TECHNOLOGY CONSIDERATIONS FOR MEDICAL DEVICES

In 2013, the Food and Drug Administration (FDA) issued its first cybersecurity safety communication, followed in 2014 by final guidance. It struck a reasonable balance between new regulations (almost none) and guidance (in the form of non-binding recommendations).

In 2015, the Federal Trade Commission (FTC) released a staff report entitled Internet of Things: Privacy & Security in a Connected World, in which it recommend that Internet of Things (IoT) style devices, which of course include medical and clinical devices, need to maintain a good security posture. It’s worth noting that the FDA, FTC, and other government regulators are centering on a few key guidelines. The following recommendations come directly from the FTC report.

Companies should build security into their devices at the outset, rather than as an afterthought. As part of the security by design process, companies should consider:

  • Conducting a privacy or security risk assessment
  • Minimizing the data they collect and retain
  • Testing their security measures before launching their products
  • Companies should train all employees about good security, and ensure that security issues are addressed at the appropriate level of responsibility within the organization
  • Companies should retain service providers that are capable of maintaining reasonable security and provide reasonable oversight for these service providers.
  • When companies identify significant risks within their systems, they should implement a defense-in-depth approach, in which they consider implementing security measures at several levels.
  • Companies should consider implementing reasonable access control measures to limit the ability of an unauthorized person to access a consumer’s device, data, or even the consumer’s network.
  • Companies should continue to monitor products throughout the life cycle and, to the extent feasible, patch known vulnerabilities

According to colleague Shahid N. Shah MS, the FTC report and FDA guidelines are remarkably consistent. When thinking of cybersecurity and data privacy, engineers tend to think about authentication, authorization, and encryption. Those are the relatively easy topics. For safety-critical devices, however, things are much more difficult and need to encompass a larger surface of questions, including but not limited to:

  • Asset Inventory: Is the device discoverable, and can it associate itself with standard IT inventory systems so that revision management, software updates, and monitoring can be automated?
  • Cyber Insurance: Does the device have enough security documentation to allow it to be insured by standard cyber insurance riders?
  • Patching: How is the firmware, operating system (OS), or application going to be patched by IT staff within hospitals (or the home for remote devices)?
  • Internal Threats: Has the device been designed to circumvent insider (hospital staff, network participants, etc.) threats?
  • External Threats: Has the device been designed to lock down the device from external threats?
  • Embedded OS Security: Is the device sufficiently hardened at the operating system level, such that no extraneous software components, which increase the attack surface, are present?
  • Firmware and Hardware Security: Are the firmware and hardware components sourced from reputable suppliers and free of state-sponsored spying?
  • Application Security: Is the Microsoft Security Development Lifecycle (SDL) or similar software security assurance process integrated into the engineering process?
  • Network Security: Have all network protocols not in use by the device been turned off so that they are not broadcasting?
  • Data Privacy: What data segmentation, logging, and auditing is being done to ensure appropriate data privacy?
  • HIPAA Compliance: Have proper steps been followed to ensure Health Insurance Portability and Accountability Act (HIPAA) compliance?
  • FISMA Compliance: If you’re selling to the federal government, have proper steps, such as use of Federal Information Processing Standard (FIPS) certified encryption, been followed to ensure Federal Information Security Management Act (FISMA) compliance?
  • Data Loss Prevention (DLP): Is there monitoring in place to ensure data leakage outside of the device doesn’t occur?
  • Vulnerabilities: Have common vulnerabilities such as the Open Web Application Security Project (OWASP) Top 10 been reviewed?
  • Data Sharing: Are proper data sharing agreements in place to allow sharing of data across devices and networks?
  • Password Management: Are passwords hardcoded into the device or made configurable?
  • Configuration Protection: Are configuration files properly check-summed and protected against malicious changes?

ASSESSMENT

It is vital to perform a security assessment on a healthcare practice to understand the environment, identify risks and perform risk mitigation. A one-time security assessment with risk mitigation is not sufficient in 2025. This is a continuous process that needs to be performed religiously to maintain a secure and compliant practice.

COMMENTS APPRECIATED

Refer, Like and Subscribe

***

***

UNDERSTANDING MEDICAL PRACTICE CYBER SECURITY RISKS

Mitigations for the Digital Health Era

 By Shahid N. Shah MS

There has been a tremendous explosion of information technology (IT) in healthcare caused by billions of dollars of government incentives for usage of digital healthcare tools. But, IT systems face threats with significant adverse impacts on institutional assets, patients, and partners if sensitive data is ever compromised. Every health enterprise is required to confidentiality, integrity and availability of its information assets (this is called “information assurance” or IA). Confidentiality means private or confidential information must not be disclosed to unauthorized persons. Integrity means that the information can be changed only in an authorized manner so as to maintain the correctness of the information. Availability defines the characteristic that information systems work as intended and all services are available to its users whenever necessary.

It is well known that healthcare organizations face and have been mitigating many risks such as investment risk, budgetary risk, program management risk, safety risk, and inventory risk for many years. What’s new in the last decade or so is that organizations must now manage risks related to information systems because  operating systems [OSs] are also at risk. IT is now just as a critical an asset as most other infrastructure managed by health systems. It is important that information security risks are given the same or more importance and priority as given to other organizational risks.

As health records move from paper native to digital native, it’s vital that organizations have information risk management programs and security procedures that woven into the culture of the organization. For this to happen, basic requirements of information security must be defined and implemented as part of both the operational and management processes. A framework that provides guidance on how to perform these activities, and the co-ordination required between these activities is needed.

INTRODUCTION

The Risk Management Framework (RMF), supported by the National Institute of Standards and Technology (NIST) provides this framework. The NIST 800 series publications provide a structured approach to achieve risk management. It provides broad guidance and not necessarily all the prescriptions, which means it can be tailored to meet the organization’s specific needs and providing the flexibility needed for the different organizations. Using the NIST RMF helps organizations with risk management not only in a repeatable manner, but also with greater efficiency and effectiveness. Healthcare information assurance is complex and without a framework that takes into account a broad risk management approach, it is difficult to consider all the intricacies involved.

NIST Risk Management Framework

The NIST Risk Management Framework consists of a six step process designed to guide organizations in managing the risks in their information systems. The various steps as defined in the NIST specifications are the following:

  • Categorize the information system and the information processed, stored, and transmitted by that system based on an impact analysis.
  • Select an initial set of baseline security controls for the information system based on the security categorization; tailoring and supplementing the security control baseline as needed based on an organizational assessment of risk and local conditions
  • Implement the security controls and describe how the controls are employed within the information system and its environment of operation.
  • Assess the security controls using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.
  • Authorize information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this risk is acceptable.
  • Monitor the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.

***

***

Worst case scenario

All information systems process, store and transmit information. What is the possible impact if a worst case scenario occurs that causes endangers this information? A structured way to find out the potential impact on the confidentiality, integrity and availability of information can be done through the first step of NIST RMP, the categorization of information systems. The NIST SP 800-60  provides such guidance. The potential impact is assigned qualitative values – low, moderate, or high. Based on these impact levels for each of the information type contained in the system, the high water mark level is calculated, that helps in selecting the appropriate controls in the subsequent steps.

Organizations need to mitigate risks adequately by selecting an appropriate set of controls that would work effectively. In the selection of security controls step, the set of controls are chosen based on the categorization of the information system, the high water mark and the goals of the organizations. These baseline controls are selected from NIST SP 800-53  specification, one of three sets of baseline controls, corresponding to low, moderate, high impact rating of the information system. These baseline controls can be modified to meet specific business needs and organization goals. These tailored controls can be supplemented with additional controls, if needed, to meet unique organizational policies and environment factors and its security requirements and its risk appetite. The minimum assurance requirements need to be specified here.

All the activities necessary for having the selected controls in place, is done in the implementation of security controls step. The implementation of the selected security controls will have an impact on the organization risks and its effects. NIST SP 800-70 can be used as guidance for the implementation. An implementation strategy has to be planned and the actions have to be defined and the implementation plan needs to be reviewed and approved, before the implementation is done.

Once the controls are implemented, then the assessment of security controls is done to find out whether the controls have been correctly implemented, working as intended, and giving the desired output with respect to the security requirements. In short, whether the applied security controls are indeed the right ones, done in the right way, giving the right outcome. NIST SP 800-53,, NIST 800-53A, NIST 800-115 can provide the necessary guidance, here.

IS authorization

The authorization of information systems is an official management decision, authorizing that the information system can be made operational, with the identified risks mitigated and the residual risks accepted, and is accountable for any adverse impacts on the confidentiality, integrity and availability of information systems. If the authorizing personnel find that the risks are not mitigated and hence can compromise the sensitive information, they can deny authorizing the information system. NIST SP 800-37 provides guidance on authorization. The authorizing personnel are to be involved actively throughout the risk management process.

Risk management is not one-time process, that once it is done, it is forgotten. It is a continuous process, to be integrated with day-to-day activities. One of the key aspects of any risk management is the monitoring of security controls to check whether the controls are performing as intended. The main focus of monitoring security controls is to know whether the controls are still effective over a period time, given the changes that occur in the information systems — the changes in hardware, software and firmware, the changes in environment factors, operating conditions etc. NIST SP 800-37  provides guidance about this. And if the security controls are found to be ineffective, the cycle starts again, with either re-categorization or selecting another set of baseline controls, or assessing the effectiveness of the controls once more etc.

And, in all the steps in risk management framework, one of the important aspects is communication. Appropriate documents needed to be generated in all the steps, reviewed and kept up-to-date.

Assessment

Organizational risk management provides great benefits to the organization because it helps to prioritize the resources, increase interoperability, and reduce costs incurred due to the adverse effects. It helps to prevent unauthorized access to personally identifiable information which will lead to security breaches.

Conclusion

Your thoughts are appreciated.

***

Product DetailsProduct Details

***

Is there a Lack of Guidelines on the Re-Use of Hardware or Electronic Media for Healthcare?

Join Our Mailing List 

What to do to mitigate risk

Shahid N. Shah MS

[By Shahid N. Shah MS]

It is a common scenario that the hardware and electronic media are re-used instead of being simply disposed. They can be reused either internally within the healthcare organization or they can be resold or donated to other organizations/individuals.

Whatever may be the nature of reuse, it is important that all ePHI are completely erased using official government approved wiping methods, before it is given out for re-use. If this is not done, there are fairly high chances of the data being exposed and there by compromising ePHI.

Major Mitigation

Specific policies and procedures needs to be defined which clearly provides guidelines on the measures to be adopted when hardware or electronic media are reused. Often the risks associated with internal reuse of these media are overlooked, and as such there are no guidelines. Even if it is internal reuse, the same level of risks associated with unauthorized access exists here. 

Secondary Mitigation

Policies and procedures which advocates the use of logs and book keeping for these reuse would help to track these media in a better way. 

Success criteria

Audit of the logs and book keeping records will provide the information on whether the policies are being followed. And, the risk assessment report will give a clearer picture whether this risk has been mitigated or not.

***

working with computer

*** 

ABOUT

Mr. Shahid N. Shah is an internationally recognized healthcare thought-leader across the Internet. He is a consultant to various federal agencies on technology matters and winner of Federal Computer Week’s coveted “Fed 100″ Award, in 2009. Over a twenty year career, he built multiple clinical solutions and helped design-deploy an electronic health record solution for the American Red Cross and two web-based eMRs used by hundreds of physicians with many large groupware and collaboration sites. As ex-CTO for a billion dollar division of CardinalHealth, he helped design advanced clinical interfaces for medical devices and hospitals. Mr. Shah is senior technology strategy advisor to NIH’s SBIR/STTR program helping small businesses commercialize healthcare applications. He runs four successful blogs: At http://shahid.shah.org he writes about architecture issues; at http://www.healthcareguy.com he provides valuable insights on applying technology in health care; at http://www.federalarchitect.com he advises senior federal technologists; and at http://www.hitsphere.com he gives a glimpse of HIT as an aggregator. Mr. Shah is a Microsoft MVP (Solutions Architect) Award Winner for 2007, and a Microsoft MVP (Solutions Architect) Award Winner for 2006. He also served as a HIMSS Enterprise IT Committee Member. Mr. Shah received a BS in computer science from the Pennsylvania State University and MS in Technology Management from the University of Maryland. 

Conclusion

Your thoughts and comments on this ME-P are appreciated. Feel free to review our top-left column, and top-right sidebar materials, links, URLs and related websites, too. Then, subscribe to the ME-P. It is fast, free and secure.

Speaker: If you need a moderator or speaker for an upcoming event, Dr. David E. Marcinko; MBA – Publisher-in-Chief of the Medical Executive-Post – is available for seminar or speaking engagements. Contact: MarcinkoAdvisors@msn.com

OUR OTHER PRINT BOOKS AND RELATED INFORMATION SOURCES:

***

[PHYSICIAN FOCUSED FINANCIAL PLANNING AND RISK MANAGEMENT COMPANION TEXTBOOK SET]

  Risk Management, Liability Insurance, and Asset Protection Strategies for Doctors and Advisors: Best Practices from Leading Consultants and Certified Medical Planners™Comprehensive Financial Planning Strategies for Doctors and Advisors: Best Practices from Leading Consultants and Certified Medical Planners™

***

About the lack of ePHI encryption in transmission and at rest?

Join Our Mailing List 

 e-Patient Health Information is Vulnerable!

Shahid N. Shah MS[By Shahid N. Shah MS]

ePHI is vulnerable to be compromised in all the states it is in. Whether it is at rest (in databases and files), or in motion (being transmitted through networks), or in use (being updated, or read), or is disposed (discarded paper files or electronic storage media).

An extra layer of security

Using encryption puts an extra layer of security to ePHI because even if someone gains access or reads ePHI, if it is encrypted then the chances of ePHI getting compromised diminishes. It makes the data unreadable and unusable by unauthorized persons. When ePHI is transmitted through networks, it is possible that it will be accessed by unauthorized persons, thus compromising ePHI. These type of unauthorized access hacking may not be immediately known, but can cause many damages.

Major Mitigation

ePHI should be encrypted and there must also be reasonable and appropriate mechanisms in place to prevent access to ePHI so that it is not accessed by persons or software programs that have not been granted access rights.

There are many different encryption methods and technologies to encrypt data in motion (SSL, VPN) or at rest.

So, choose the methods and technologies that best meet the physician’s office requirements.

***

  Risk Management, Liability Insurance, and Asset Protection Strategies for Doctors and Advisors: Best Practices from Leading Consultants and Certified Medical Planners™

***

Success criteria

A risk analysis/assessment reports will provide a clear indication of whether these type of risks exists or has been mitigated with appropriate controls.

Assessment

Auditing logs that track access to ePHI can be verified periodically to check if there has been unauthorized access by persons or software programs that have not been granted access rights.

More:

About: Meet Shahid N. Shah MS [Our Newest IT Thought-Leader]

Conclusion

Your thoughts and comments on this ME-P are appreciated. Feel free to review our top-left column, and top-right sidebar materials, links, URLs and related websites, too. Then, subscribe to the ME-P. It is fast, free and secure.

Speaker: If you need a moderator or speaker for an upcoming event, Dr. David E. Marcinko; MBA – Publisher-in-Chief of the Medical Executive-Post – is available for seminar or speaking engagements. Contact: MarcinkoAdvisors@msn.com

OUR OTHER PRINT BOOKS AND RELATED INFORMATION SOURCES:

[HEALTH INSURANCE, MANAGED CARE, ECONOMICS, FINANCE AND HEALTH INFORMATION TECHNOLOGY COMPANION DICTIONARY SET]

      Product DetailsProduct DetailsProduct Details

[Mike Stahl PhD MBA] *** [Foreword Dr.Mata MD CIS] *** [Dr. Getzen PhD]

***

On the lack of encryption of ePHI in transmission and at rest

Join Our Mailing List 

Shahid N. Shah MS[By Shahid N. Shah MS]

ePHI is vulnerable to be compromised in all the states it is in. Whether it is at rest (in databases and files), or in motion (being transmitted through networks), or in use (being updated, or read), or is disposed (discarded paper files or electronic storage media).

Using encryption puts an extra layer of security to ePHI because even if someone gains access or reads ePHI, if it is encrypted then the chances of ePHI getting compromised diminishes. It makes the data unreadable and unusable by unauthorized persons. When ePHI is transmitted through networks, it is possible that it will be accessed by unauthorized persons, thus compromising ePHI. These type of unauthorized access hacking may not be immediately known, but can cause many damages.

Major Mitigation

ePHI should be encrypted and there must also be reasonable and appropriate mechanisms in place to prevent access to ePHI so that it is not accessed by persons or software programs that have not been granted access rights.

There are many different encryption methods and technologies to encrypt data in motion (SSL, VPN) or at rest. Choose the methods and technologies that best meet the physician’s office requirements.

Success criteria

The risk analysis/assessment reports will provide a clear indication of whether these type of risks exists or has been mitigated with appropriate controls.

***

secret

***

Assessment

Auditing logs that track access to ePHI can be verified periodically to check if there has been unauthorized access by persons or software programs that have not been granted access rights.

More

ABOUT 

Mr. Shahid N. Shah is an internationally recognized healthcare thought-leader across the Internet. He is a consultant to various federal agencies on technology matters and winner of Federal Computer Week’s coveted “Fed 100″ Award, in 2009. Over a twenty year career, he built multiple clinical solutions and helped design-deploy an electronic health record solution for the American Red Cross and two web-based eMRs used by hundreds of physicians with many large groupware and collaboration sites. As ex-CTO for a billion dollar division of CardinalHealth, he helped design advanced clinical interfaces for medical devices and hospitals. Mr. Shah is senior technology strategy advisor to NIH’s SBIR/STTR program helping small businesses commercialize healthcare applications. He runs four successful blogs: At http://shahid.shah.org he writes about architecture issues; at http://www.healthcareguy.com he provides valuable insights on applying technology in health care; at http://www.federalarchitect.com he advises senior federal technologists; and at http://www.hitsphere.com he gives a glimpse of HIT as an aggregator. Mr. Shah is a Microsoft MVP (Solutions Architect) Award Winner for 2007, and a Microsoft MVP (Solutions Architect) Award Winner for 2006. He also served as a HIMSS Enterprise IT Committee Member. Mr. Shah received a BS in computer science from the Pennsylvania State University and MS in Technology Management from the University of Maryland. 

Conclusion

Your thoughts and comments on this ME-P are appreciated. Feel free to review our top-left column, and top-right sidebar materials, links, URLs and related websites, too. Then, subscribe to the ME-P. It is fast, free and secure.

Speaker: If you need a moderator or speaker for an upcoming event, Dr. David E. Marcinko; MBA – Publisher-in-Chief of the Medical Executive-Post – is available for seminar or speaking engagements. Contact: MarcinkoAdvisors@msn.com

OUR OTHER PRINT BOOKS AND RELATED INFORMATION SOURCES:

***

  Risk Management, Liability Insurance, and Asset Protection Strategies for Doctors and Advisors: Best Practices from Leading Consultants and Certified Medical Planners™

***

Cyber-Security Considerations for “Mission-Critical” Medical Devices

Join Our Mailing List 

Understanding the balance between new regulations (almost none) and guidance (in the form of non-binding recommendations)

By Shahid N. Shah MS

Shahid N. ShahTHEN …

In 2013, the Food and Drug Administration (FDA) issued its first cybersecurity safety communication, followed in 2014 by final guidance.

It struck a reasonable balance between new regulations (almost none) and guidance (in the form of non-binding recommendations).

NOW …

In 2015, the Federal Trade Commission (FTC) released a staff report entitled Internet of Things: Privacy & Security in a Connected World, in which it recommend that Internet of Things (IoT) style devices, which of course include medical and clinical devices, need to maintain a good security posture. It’s worth noting that the FDA, FTC, and other government regulators are centering on a few key guidelines.

Six Recommendations

The following six recommendations come directly from the FTC report:

  1. Companies should build security into their devices at the outset, rather than as an afterthought. As part of the security by design process, companies should consider:
  • Conducting a privacy or security risk assessment
  • Minimizing the data they collect and retain
  • Testing their security measures before launching their products
  1. Companies should train all employees about good security, and ensure that security issues are addressed at the appropriate level of responsibility within the organization
  2. Companies should retain service providers that are capable of maintaining reasonable security and provide reasonable oversight for these service providers.
  3. When companies identify significant risks within their systems, they should implement a defense-in-depth approach, in which they consider implementing security measures at several levels.
  4. Companies should consider implementing reasonable access control measures to limit the ability of an unauthorized person to access a consumer’s device, data, or even the consumer’s network.
  5. Companies should continue to monitor products throughout the life cycle and, to the extent feasible, patch known vulnerabilities

The FTC report and FDA guidelines are remarkably consistent. When thinking of cybersecurity and data privacy, engineers tend to think about authentication, authorization, and encryption. Those are the relatively easy topics.

*** circuit***

Mission Critical Medical Devices

For “mission-critical” medical safety devices, however, things are much more difficult and need to encompass a larger surface of questions, including but not limited to:

  • Asset Inventory: Is the device discoverable, and can it associate itself with standard IT inventory systems so that revision management, software updates, and monitoring can be automated?
  • Cyber Insurance: Does the device have enough security documentation to allow it to be insured by standard cyber insurance riders?
  • Patching: How is the firmware, operating system (OS), or application going to be patched by IT staff within hospitals (or the home for remote devices)?
  • Internal Threats: Has the device been designed to circumvent insider (hospital staff, network participants, etc.) threats?
  • External Threats: Has the device been designed to lock down the device from external threats?
  • Embedded OS Security: Is the device sufficiently hardened at the operating system level, such that no extraneous software components, which increase the attack surface, are present?
  • Firmware and Hardware Security: Are the firmware and hardware components sourced from reputable suppliers and free of state-sponsored spying?
  • Application Security: Is the Microsoft Security Development Lifecycle (SDL) or similar software security assurance process integrated into the engineering process?
  • Network Security: Have all network protocols not in use by the device been turned off so that they are not broadcasting?
  • Data Privacy: What data segmentation, logging, and auditing is being done to ensure appropriate data privacy?
  • HIPAA Compliance: Have proper steps been followed to ensure Health Insurance Portability and Accountability Act (HIPAA) compliance?
  • FISMA Compliance: If you’re selling to the federal government, have proper steps, such as use of Federal Information Processing Standard (FIPS) certified encryption, been followed to ensure Federal Information Security Management Act (FISMA) compliance?
  • Data Loss Prevention (DLP): Is there monitoring in place to ensure data leakage outside of the device doesn’t occur?
  • Vulnerabilities: Have common vulnerabilities such as the Open Web Application Security Project (OWASP) Top 10 been reviewed?
  • Data Sharing: Are proper data sharing agreements in place to allow sharing of data across devices and networks?
  • Password Management: Are passwords hardcoded into the device or made configurable?
  • Configuration Protection: Are configuration files properly check-summed and protected against malicious changes?

Conclusion

Your thoughts and comments on this ME-P are appreciated. Feel free to review our top-left column, and top-right sidebar materials, links, URLs and related websites, too. Then, subscribe to the ME-P. It is fast, free and secure.

ABOUT

Mr. Shahid N. Shah is an internationally recognized healthcare thought-leader across the Internet. He is a consultant to various federal agencies on technology matters and winner of Federal Computer Week’s coveted “Fed 100″ Award, in 2009. Over a twenty year career, he built multiple clinical solutions and helped design-deploy an electronic health record solution for the American Red Cross and two web-based eMRs used by hundreds of physicians with many large groupware and collaboration sites. As ex-CTO for a billion dollar division of CardinalHealth, he helped design advanced clinical interfaces for medical devices and hospitals. Mr. Shah is senior technology strategy advisor to NIH’s SBIR/STTR program helping small businesses commercialize healthcare applications. He runs four successful blogs: At http://shahid.shah.org he writes about architecture issues; at http://www.healthcareguy.com he provides valuable insights on applying technology in health care; at http://www.federalarchitect.com he advises senior federal technologists; and at http://www.hitsphere.com he gives a glimpse of HIT as an aggregator. Mr. Shah is a Microsoft MVP (Solutions Architect) Award Winner for 2007, and a Microsoft MVP (Solutions Architect) Award Winner for 2006. He also served as a HIMSS Enterprise IT Committee Member. Mr. Shah received a BS in computer science from the Pennsylvania State University and MS in Technology Management from the University of Maryland. 

Speaker: If you need a moderator or speaker for an upcoming event, Dr. David E. Marcinko; MBA – Publisher-in-Chief of the Medical Executive-Post – is available for seminar or speaking engagements. Contact: MarcinkoAdvisors@msn.com

OUR OTHER PRINT BOOKS AND RELATED INFORMATION SOURCES:

Product Details

Product DetailsProduct DetailsProduct Details

Divorcing your EHR Sytem [A How to Approach]

Join Our Mailing List

Planning for an Escape Hatch

[By Shahid N. Shah MS]

Shahid N. ShahAs a doctor, or physician executive, you will spend weeks or months in the “sales and demo cycle” for selecting an EMR. If you’re lucky you will have time to consider all workflows; if you’re even luckier you will test drive the UI and make sure training goes smoothly.

You will also try to ensure that deployment will be easy.

However, another thing not to forget is to plan how to get out of an application or system after it’s been installed for a while.

It’s Harder to Get Out – Than Get in

Why is getting out important? Every application looks better in a demo than in a working environment and every solution becomes “legacy” sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition (“barrier to entry”) is well understood now as something we need to calculate. But the “barrier to exit” or switching cost is something you must calculate at the time you decide what systems to purchase.

If you can’t answer the “how, in 6, 18, or 24 months, will I be able to move on to the next-better technology or system?” question then you’ve not completed your due diligence in the sales cycle. Vendor sales staff are quite reticent to answer the “how do I leave your system” question; you will need to press hard and ask for a plan before signing any contracts.

Some Vendor Queries

When preparing an RFI or RFP, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases.

Here are some specific factors to consider:

  • Do you own your data or does the vendor? If you don’t have crystal clear statements in writing that the data is yours and that you can do whatever you want with it, don’t sign the contract. Look for a new vendor.
  • Is the database structure and all data easily accessible to you without involving the vendor? If only your vendor can see the data, you’re locked in so be very wary. Find out what database the vendor is using and make sure you can get to the database directly without needing their permission.
  • Are the data formats that the system uses to communicate with other vendors open? If not, you don’t own your data. Be sure that at least CCR and CCD formats are available and that all document data is accessible in standard PDF or MS Office friendly formats. Discrete data should be extractable in XML or HL7.
  • How much of the technology stack is based on industry standards? The more proprietary the tech, the more you’re locked in.
  • Are all the programming APIs open, documented, and available without paying royalties or license costs? If not, when you try to get out you’ll pay dearly.

***

EHRs

***

More:

Book Chapter:

Conclusion

Your thoughts and comments on this ME-P are appreciated. Feel free to review our top-left column, and top-right sidebar materials, links, URLs and related websites, too. Then, subscribe to the ME-P. It is fast, free and secure.

Speaker: If you need a moderator or speaker for an upcoming event, Dr. David E. Marcinko; MBA – Publisher-in-Chief of the Medical Executive-Post – is available for seminar or speaking engagements. Contact: MarcinkoAdvisors@msn.com

OUR OTHER PRINT BOOKS AND RELATED INFORMATION SOURCES:

Product Details

Chapter 13: IT, eMRs & GroupWare