Best Practice Data Management for MEDITECH Hospitals: What to do about Scanning and Archiving (SCA) images Prepared for MUSE Education

Best Practice Data Management for MEDITECH Hospitals: What to do about Scanning and Archiving (SCA) images

Prepared for MUSE Education

2 BridgeHead Software / Healthcare Data Management

A Little About Me

• Chris Welch

• Follow me: @Chrisw767

• Send me email: [email protected]

• Worried about Backup, Archiving, and Disaster Recovery Business Continuity

• Visited hundreds of MEDITECH hospitals throughout North America

• Worked with all of the recent versions of MEDITECH and implemented all of BridgeHead's MEDITECH solutions, including first FileStore deployments for MEDITECH SCA

• Private pilot

• Living in upstate New York

mailto:[email protected]


Goals for this Discussion

• Discuss SCA and what data goes into it

• Discover the true criticality of SCA data- it’s more important than you think

• Why is SCA data so hard to protect?

• What is the Best Practice to follow when protecting SCA data


What is MEDITECH SCA?

• Reduces paper in MEDITECH hospitals

• Automates medical records processes

• Manages electronic forms

• Integrates document management with MEDITECH applications

• Creates single point of access for all patient data within MEDITECH


Where does the data come from?

• Point of Care (drivers license, insurance card, etc)

• Reports from other modules (nursing notes, lab results, physician reports, etc)

• Data from other applications tied into SCA

• Directly scanned data (EKG strips)

• Historical records- paper charts

• “Other”


Where does the data go?

• SCA sends the data to a network share

• Typically this is a Scanning and Archiving server, with storage attached to it

SCA Server

• Typically millions of small files• Typically grow rapidly• Typically takes a large amount

of day-to-day administrative oversight


How much data ends up on the SCA server?

• The average 1 TB SCA LUN (disk) contains 15 million files

• SCA LUNs tend to grow rapidly and frequently beyond initial growth expectations

• As people discover that SCA can house other types of data, the growth accelerates

• In our experience, ingesting historical records is common and overwhelms the storage

• “The digital version of your Medical Records room”

BridgeHead Customer:

Rochelle Community Hospital

Hospital Profile

• Community Hospital in the greater Chicago area

• Health and wellness services for the city of Rochelle, Ill and surrounding rural communities

• Multi-Specialty Center, a Fitness Center and offers wellness, pediatrics and orthopedics

• MEDITECH and SCA clinical applications

• Heterogeneous storage including SAN and NAS

• 6-person health IT administration team for the entire hospital

• BridgeHead ISB/IDR for MEDITECH HCIS and Archive for MEDITECH SCA

“BridgeHead’s vendor neutrality made architecting and implementing a multi-tiered storage architecture easy. Once we had some specs and speeds from BridgeHead, we could buy anything we wanted. Since BridgeHead is independent of any hardware, we could maximize our budget with lower-cost storage.”

Scott Stewart, Manager of Information Systems

Problem Solved

Keeping up with the growth of clinical data exceeded the storage budget for the hospital. IT manager Scott Stewart used BridgeHead tiered storage management to effectively extend the life of more expensive SAN storage with backup and archive software. As an added outcome, BridgeHead also significantly reduced administrative burden for the Community Hospital team.

Why BridgeHead?

• BridgeHead’s vendor-agnostic software approach was critical to enabling Rochelle to place the storage equipment of their choice, enabling cost-efficient storage selection

• Avoided storage vendor lock-in

• Addition of the BridgeHead solution made SCA a “set-it-and forget it” solution, with reduced administration burden

BridgeHead Customer:

Humber River Hospital

Hospital Profile

• One of Canada’s largest regional acute care hospitals

• Located in the Greater Toronto Area

• Serves more than 850K people

• 549 beds, 3K staff, and approximately 700 physicians and 400 volunteers

• Affiliated with the University of Toronto

• Home to Ontario’s first Centre of Excellence for laparoscopic bariatric surgery

• Canada’s first home nocturnal dialysis program and a major cancer program

“Our IT team prides itself in providing outstanding Service Levels to our hospital clinicians. Our culture is one in which we are held accountable to these SLAs, and our data protection partner needs to do the same. We standardized on BridgeHead because of its excellent technology, certainly. But what convinced us to move forward with this importantconsolidation project was the track record of outstanding service which BridgeHead has provided to us over the years. BridgeHead’s service and support to our team has been critical to enabling our team to maintain its SLAs for the hospital.”

Kevin Fernandes, Manager of Infrastructure, TechnicalSupport and Service Desk

Problem Solved

Updating to MEDITECH 6.0 offered the opportunity to centralize IT resources and improve the organization’s disaster recovery capabilities, as part of the project. This covered both clinical and administrative data, and included new coverage of MEDITECH SCA along with HCIS.

Why BridgeHead?

• Integrated backup and archive, for optimized protection and recovery

• Capability to establish a true hospital archive

• BridgeHead’s service team excellence and commitment to SLAs which enable the health IT team to meet their hospital commitments


Case in Point: Humber River’s SCA Environment

• Humber River Regional Hospital’s MAGIC SCA environment– 10x 1 TB LUNS with approximately – 15 million files in EACH LUN

• Backups (with ISB) were taking days to complete

• In a site disaster, restore of SCA would have taken well over 24 hours, while the rest of the MEDITECH environment would have taken 4-6 hours


Why is SCA data so critical?

• This may be the most important data in the hospital– Medical/Legal Archive– Billing– RAC Audits– Frequently becomes the clinicians favorite view into the

medical record


Why is SCA data so hard to protect?

• The data changes!– Called “Scanning and Archiving” but “archived” data from the

modules can and will be overwritten- a lot– There is no limit to how far in the future the data can be

overwritten• Examples

– Electronic Signatures months down the road– At one hospital a configuration change in MEDITECH caused a

million files to be overwritten- these took months to recreate


Common Questions & Considerations with SCA DR

• “Scan and Shred”– Many facilities have a shredder right next to the scanner, and

as soon as the data is scanned and validated, the original paper is shredded

– What if your server failed after the paper was shredded but before a backup occurred?

• Point of Care Scanning– Patient presents to emergency department and scans

driver’s license and insurance card for scanning– What if your server failed after the patient is discharged but

before a backup occurred?


Data Protection Technologies You May Be Considering for SCA

Protection Technology Challenges with SCA

File-level backup • Takes too long just to scan all the data• Restores take “forever”

ISB • Good for small SCA deployments – 1-2TB• Expensive – needs more disk and tape

resources, constant administration• Beyond 1TB the restores become impractical

Replication • Copies data corruption as quickly as good data – so not a sufficient protection method

• Most common SCA restores are from monthly or yearly – so lack of generational protection makes this approach impractical

Synthetic backup – or “incrementals forever”

• Data backup is optimized – but recovery is de-optimized

All of these Protection Methods

• If I have to restore back one file from two years ago, then I have to start by restoring everything


What does a Best Practice look like for SCA data protection?

• In a site disaster, you need to be able to come up quickly with recent, relevant data

• You need to provide deep generational protection for all versions of the images- possibly going back years

• You need to provide “immediate” protection for files to accommodate Scan and Shred

• You want to store the recent data on fast disk, and older data on less expensive disk

• You want many copies of your data on inexpensive targets

Archive and Keep

SCA Server

1.TIF1.TIF

FileStore/SQL Server

New file from applicationput on LUN

FileStore scans LUN and identifies new or changed files based on policy

FileStore copies files to Offline Locations

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

Application still accesses files from original location.

Data is well protected inmulticopy repository

Finch Disk Copy 2

Finch Disk Copy 1

Tape Copies

Archive and Stub

SCA Server

ArchiveServer

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

After a period of time, a policy causes the file to be stubbed.

“Restore” Stubbed Files

SCA Server

ArchiveServer

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

A user or application attempts to access the stubbed file

Archive software intercepts the access request

Archive software restores the file

Application accesses data(less than 2 seconds from request)

SCA Architecture after Archive stubbing/stub consolidation

SCA Server

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

T1.IF

T1.IF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIF

1.TIFWhen the files have been stubbed, LUNS which were previously full nowonly have a small amount of data onthem.

Archive consolidates the stubs onto a single LUN to reduce storage requirements

The resulting single LUN iseasier to back up and restore

The hospital reclaims significant valuable SAN storage.

Archive Enables Better Backup of the SCA System


Final thoughts

• SCA data may be more critical than expected

• Standard data protection strategies are not ideal for SCA data

• Keep in mind that you need to protect for multiple types of disasters

• Deep generational protection is vital to SCA

• Consider testing a restore with your solution

• It is easier and less costly to implement a data management strategy early, before there is a huge amount of data.


Thank-you!

Questions?


Why shouldn’t I use a regular “File Level” backup for SCA?

• File level backup “walks” the file system and backs up a single file at a time- works well for a small number of larger files

• Typical backup times for 1 TB SCA LUNs are over 24 hours- restore times will be longer

• File level backup protects each file in the state it was in when it reached the file, so a restore will present the first file in the state it was in almost 24 hours before the state that the last file will be in (need help wording this better)


Why shouldn’t I use ISB (Integrated Serverless Backup) for SCA?

• ISB will perform much faster, consistent backups, but at a high cost because of disk and target requirements

• ISB is a good solution for “smaller” SCA environments, up to 1-2 TB

• As the environment grows, disks and tape devices will need to be added

• Beyond 1 TB, restores quickly become unpractical


OK, so how about replication?

• Many customers use software or hardware replication to protect other types of data

• Replication will copy all changes to the target

• If corruption or a mistake occurs, there will be no way to go back

• Most common restores in MEDITECH come from monthly or yearly tapes

• As the SCA data volume grows, the disk requirement on both sides grows with it


How about Synthetic Backup or Incrementals Forever?

• Backups will work and will be relatively fast

• Data can end up spread on many pieces of media

• Restores can take a huge amount of time- perhaps months

• Must restore ALL data to get ANY data

Documents

Best Practice Data Management for MEDITECH Hospitals: What to do about Scanning and Archiving (SCA) images Prepared for MUSE Education