In healthcare, it’s about the patient’s chart, tests, and
results, which all starts in the quality of the information extraction from
Allscripts. Of course, when you move from one solution to another, people tend
to get in the way. What I mean by this is that there usually needs to be a
consultant to broker between each sides of the transfer.
Information
Requirements gathering is only as good as the person’s
experience who’s managing it. A third may boast many years of experience,
however, chances are good that there are a few key internal architects that
need to be involved and listened to from the get-go. The mapping of patient
data, doc types, and workflows are all fundamental to the success of the
migration. The sizing parameters will have to be detailed, such as, number of
files, average file size.
Execution logistics
As the “what” questions are answered, inevitably, new ones
come up, such as “What transfer batch size should we use?”, “How long will it
take to transfer each batch?” and “When will we shut down access to
Allscripts?”, etc. A “who/what/when/where/how” matrix will help sort out the
details. The transfer batch will depend on how many document pages are
extracted and will entail multiple folders and file naming convention.
Testing
Testing and its organization are a litmus test of how well
the project is managed. Hopefully all of the application’s SMEs are involved
and designated Users are scheduled to test. Testing ADT scenarios and OnBase
scanning and indexing are essential. Also, testing the backfill of accounts and
demographics has to be done at least twice to get all of the pieces validated.
Extract
The Allscripts extract index will be delimited and should
have all of the metadata needed to import into OnBase. It should have a pointer
to the scanned files. These files will most likely be extracted pages, so there
will need to be a unique number to be able to build the document before
importing into OnBase. You’ll need the following:
Patient
Demographics – enough information to validate and tie back to the ADT patient
record.
Master
Patient Index – the corporate medical record number to identify the extract as
it is imported to OnBase
Document
types – each type must go through HIM for validation. If Allscripts was used
for ambulatory sites, chances are good that the naming of doc types will
reflect this. You may want to just keep all the source names and prefix them
with a value that allows for easy recognition. These should also be set up in a
new doc type group if there are a lot of them. The “go forward” strategy of
scanning should include only the unique doc types that were not already in the
Onbase system.
Document
formats – there may be some formats that surprise you. Import formats have to
be identified and set in the OnBase import process.
List of
file pointers – this list tells OnBase the page’s file system locations. If
there are thousands of pages, the pointer will most likely have a folder in it
that changes as the batches are imported. The filing naming convention will
have to be unique and could be extracted from Allscripts’ unique file naming.
Data Manipulation
Between any focused information management system there are
bound to be idiosyncrasies. For example, the patient medical record numbering
scheme will be different, the rules around naming conventions of metadata, and
many other conventions specific to the infrastructure of the source system.
Registration, EMR and interface
With different naming conventions of patient metadata between
the source and target systems, the issues of data integrity could be compounded.
During testing all sorts of issues can come up from ADT messages not having
correct patient data, to patient corporate numbers being duplicates. Quality
control and validation as a separate can help fix issues before they go into
the target system.
Import
As we know the quality of the import starts with quality of
the extract. As the patient data issues get mapped and fixed, the actual
importing will have to be achieved through a third party tool or customization.
Every difference that is not accounted for in the design or development will
definitely show up as errors during testing of this process. Using the tool to
look up values in the target system based on source values should be part of
the tools requirements. The tool should be able to handle errors gracefully by
logging them and queueing them for reimporting.
People
The human factor cannot be overlooked with any migrations.
Both sides will have feelings though they may be hidden behind professional
facades: some were comfortable with the old system and others are not happy
about the new responsibilities of the new one. These feelings will show
themselves with delays in development, or show stopper issues during testing.
If everyone is complaining about the project manager then you know the culture
is old school in that the walls of knowledge continue to be fortified, that
sharing only occurs when show stoppers force everyone to open up and help each
other if only for just that moment…
