Manage Reporting Workflow with DefinITy

In my previous post regarding MPI consolidation, we observed how a conversion/upgrade effort, though an intensive undertaking, presents many opportunities to improve our organization and workflow. One of these opportunities is how we can improve our data governance, specifically the process of evaluating and planning our reporting needs. This is most apparent during a platform change, and that will be the use case I’ll be focusing on, but the same considerations can be applied whether we are in the process of upgrading our HCIS or during the maintenance cycle.

Reporting is central to our day-to-day operations and long-term planning, and over time we accrue hundreds of essential reports, distributed throughout our HCIS and depended on by our multi-disciplined user base. When planning for an upgrade, many of these reports will need to be rewritten in light of enhanced functionality and changes present in the new system. In 2018, our development partner Halifax Health completed their upgrade from MEDITECH Client Server to MEDITECH Expanse. Planning for this upgrade, Halifax needed a way to evaluate the full scope of their accumulated reports and effectively determine the best way to consume the report governance elephant.

We begin by answering a series of questions, based on our particular upgrade effort. Such as: Exactly how many reports do we currently have? How can this number be reduced? Out of these reports, we want to determine relevance, and if relevant, then priority and upgrade requirements. What type of report is it, i.e. NPR Report Writer or Data Repository? Is the application the report references changing platforms (NPR to M-AT)? Does the latest MEDITECH version provide standard functionality that makes the report obsolete? Once these questions have been answered, we can begin to delegate the individual reports to internal or external resources that will be responsible for rebuilding and testing the reports in the new MEDITECH platform.

DefinITy is our report tracking and governance solution that was born out of Halifax Health’s planning and analysis effort. DefinITy facilitates the upgrade process by providing a means to easily track and manage the steps from report discovery and analysis through testing and finalizing the new report version. Existing report metadata and usage criteria are loaded into the DefinITy database, and then assigned an owner, i.e. the user responsible for determining the relevance of the report. Report owners can then manage their list of reports, by canceling reports no longer needed, or confirming the request for an upgrade of the report, adding any additional details or requirements. Requested reports are then assigned to a resource for tracking the completion of the new version of the report.

Sound planning and consideration ensure that we make the most of the opportunities presented to us during an upgrade effort. Using a tool to manage and track the report update process in phases, allows us to focus on the upgrade as a whole while delegating out the details to the correct resources. To assist sites with this process, The HCI Solution offers a complementary report analysis, providing a high-level overview of a site’s current reporting footprint and usage, and highlighting those reports that will be impacted by platform upgrades. We also offer a full suite of Data Services, in the event that you are looking for external resources to assist with your reporting needs, regardless of your MEDITECH version.

Please feel free to check out our no-obligation Request a Quote Form

To learn more about The HCI Solution’s DefinITy  CLICK HERE.


Why SyncSolve® Perfectly Complements MEDITECH’s Corporate Management Software (CMS)


Utilizing your Electronic Health Record’s (EHR’s) TEST system is the best way to ensure that issues with dictionary, parameter, or new software changes are discovered prior to introducing patient safety or other issues into your LIVE EHR environment. However, your EHR’s TEST system is only truly effective in catching problems if it behaves the same way as your LIVE EHR. That means putting effort into supporting a proper dictionary management process. Whatever dictionaries are built and edited in the LIVE system need to have the same changes made in the TEST system and vice versa. This is easier said than done. Manually re-keying dictionary edits in two different systems is an arduous process filled with opportunities to introduce human error. These errors can eventually lead to more time spent troubleshooting issues that arise from TEST and LIVE systems not behaving the same. Let’s learn why SyncSolve® complements MEDITECH’s Corporate Management Software (CMS) so perfectly.


MEDITECH customers are receiving the MEDITECH CMS solution with new Expanse implementations. The CMS system was first developed for larger corporate healthcare organizations and Integrated Delivery Networks (IDNs). It was a way for large organizations to standardize their EHR content across all facilities. Dictionaries could be built in one “standards” HCIS, and CMS background jobs would propagate those dictionary edits to target corporate HCIS. One great feature is that the system allows certain fields and certain dictionaries to be “localized.” For instance, it would not make sense to standardize and centrally control the location dictionary. There are a lot of dictionaries and fields that are very specific to designated facilities.

CMS not only keeps disparate MEDITECH facility EHRs synchronized, it is also used to keep the separate MEDITECH TEST and LIVE system’s synchronized. This is the primary reason why MEDITECH started offering it to smaller organizations with Expanse. CMS is a big step in the right direction for dictionary management. However, it is not the be-all end-all. There are still some challenges with the CMS system. Here are some limitations:

  • A lot of dictionaries are not controlled/propagated by CMS.
  • The full automation of CMS is a positive, but there are times when more granular control and analysis is desired.
  • When customers are going through a MEDITECH update, propagation from one MEDITECH release to another is not possible.
  • Sometimes things do not sync as intended due to CMS or other MEDITECH software problems. These issues can be difficult to detect without an additional dictionary compare tool.


The HCI Solution has several customers that utilize both CMS and SyncSolve® for their dictionary management needs. Why? SyncSolve® is 100% CMS compatible – dictionaries that are synced by SyncSolve® to the “standards” HCIS are propagated to all CMS target HCIS’s, even dictionaries from other MEDITECH releases. SyncSolve® can be used to compare any dictionary from one MEDITECH system to another, even across Universes! CMS does not synchronize every dictionary. SyncSolve® synchronizes nearly every dictionary. Here are just a few of the many examples of dictionaries that can be synced by SyncSolve® that cannot be synced by CMS:

  • Person Dictionary
  • Canned text
  • Menu/Procedure Access
  • CWS Resource
  • Oncology Treatment Plan

When MEDITECH customers are going through an update, SyncSolve® can synchronize between software releases, where CMS cannot. Some of our customers even use SyncSolve® to compare dictionaries between HCIS’s to make sure that CMS is functioning properly. SyncSolve® provides much more granular control than CMS does. It allows you to sync specific fields within specific dictionaries, something that CMS does not do. It allows users to create very specific use-cases for hospital initiatives.


  • Available in MAGIC, CS, M-AT 6.x, Expanse
  • Compare dictionaries across databases, HCIS’s, and even UNV’s
  • View discrepancies field by field
  • View dependent dictionary deficiencies
  • Generate detailed work lists and reports
  • Launch directly to dictionary Enter/Edit screens from work lists
  • Schedule and automate dictionary maintenance
  • Monitor dictionaries for changes
  • Auto-synchronize dictionary and dependent dictionary differences
  • Build custom use cases
  • Manage access controls for decentralization
  • Copy dictionaries and parameters
  • Distribute reports by email


CMS is a great tool for automating the propagation of dictionary edits. It goes a long way in helping to keep your TEST and LIVE systems synchronized. However, it does not cover everything. SyncSolve® will fill in those gaps. SyncSolve® is the perfect tool to help complete specific use-case projects along with CMS, like building new assessments in TEST prior to syncing them to “standards”, or building users in LIVE and then syncing them to TEST. It is also useful for migrating previous release TEST dictionaries to your new TEST release ring, for those dictionaries that MEDITECH could not copy. Hopefully now you see why SyncSolve® perfectly complements MEDITECH’s Corporate Management Software (CMS).


If you don’t have MEDITECH’s CMS system, then SyncSolve® is the only real option for you, that truly works. SyncSolve® is available for MAGIC, C/S, 6.x, and Expanse.

To learn more about The HCI Solution’s SyncSolve®­­­­  CLICK HERE.

CONTACT US to schedule a demo and see SyncSolve® in action.



Interface Engine Maintenance

An interface engine can act as the heart of dataflow in an enterprise, as it facilitates the transfer of data from one application to another. As with any system, there are certain things to be mindful of in order to keep dataflow moving in a reliable manner 24 hours a day, 7 days a week. After working with numerous interface engines for over 16 years, I have inevitably run across several “best practices” that have withstood the test of time. Among these are: interface and application endpoint documentation, interface contingency alerting, server health monitoring, and high-availability assurance.


Good documentation provides a map of the interfaces in place. The best integration shops have them, unfortunately this is more an exception than the rule. Good documentation does not need to be complicated. While Visio diagrams are ideal, a spreadsheet can be a great start. Each interface can be assigned a row and given a unique id on a spreadsheet; include the interface name, a brief description and a column with a reference (typically a unique identifier) to the interface(s) it feeds, separated by a comma. You can always add other columns later to indicate the interface’s dataflow source and destination address. Keep it simple, then you can go for greater sophistication later.


Unless you have a very small number of interfaces, a dedicated 24 x 7 help desk, or adopt a reactive stance by which you depend on your application users to notify you of delayed data updates; having automated alerting is a must. In a nutshell, automated alerting lets key people in your organization (including vendors) become aware of interface problems before your users notice something is wrong with the timely interfacing of data. Automated alerting allows for interface connectivity, message processing or delivery problems to be reported via a dashboard, email or texting medium. Just about every interface engine has these capabilities built into it. Having a dedicated SMTP email account can be a starting point for automated, real-time alerts that will reach key support team members quickly and proactively.


Alerting does not have to stop at the interface engine. The server in which the interface engine resides requires continuous monitoring. If available, the interface engine’s built-in alerting system may monitor important server resources such as disk storage space, CPU, RAM, network or disk resource utilization and alert if any thresholds are crossed. Other interface engine components such as database servers, should also be monitored and alerted. There are also third-party tools, such as The HCI Solution’s Sentry, that can supplement, if not provide full monitoring support for these vital server monitoring and alerting functions.


While alerting provides insights into what is happening now, it should still be considered a reactive component of an interface management regime. A “trending approach” should be adopted as a proactive component of best interface engine management practices, as it can help you spot problems BEFORE they exacerbate into a dataflow stoppage or even data loss.

System resource utilization trends will not only indicate when there is trouble brewing (i.e. dwindling disk space or higher than usual network bandwidth utilization) but can also be of use when it comes to long-term planning. Tracking CPU, RAM, and disk usage trends should be placed alongside interface engine utilization metrics on a daily, weekly and monthly basis with message/transactions as a primary source from which to derive overall data usage bandwidth. A calculated average message size multiplied by the number of messages for each interface can provide a more accurate throughput metric (MB/GB’s per 24 hour period) than total message counts, as message sizes can vary greatly. Data mining interface engine databases or message logs are alternate ways of accomplishing this key task.


If you really want to be proactive, run periodic “stress” tests by submitting a batch of messages through a test interface, recording the time it takes for that batch to process and trending the “time to delivery” over time. This is a great way to measure the engine’s message processing performance vis-à-vis the engine’s current workload. Other strategies such as virtual machines and high-availability software solutions such as Microsoft Cluster Server can make it easy to keep the interface engine dataflows running 24 x 7 while operating system patches, hardware or any other events that may bring the engine offline.


Similar to your own biological heart, an interface engine is the heart of data flowing throughout your enterprise. Just like frequent exercise, good eating habits and routine monitoring of your body’s vital signs throughout your lifetime can keep your cardiovascular system in top shape, the same applies to interface engines. Understanding what those components are, tracking their performance, and utilizing a regime of software tools and best practices, will keep you running 24 x 7 and avoid the nasty surprises that occur several years down the road when you least expect them.

To learn about The HCI Solution’s Interface Engine Services  CLICK HERE.


Engineering Concierge

We all equate a concierge to a go to person in the hotel we are staying that direct us to a restaurant, pharmacy, or department store when needed. They help us to get where we want to go with the resources needed to accomplish what we want to do in the time we have to do it.

Community hospitals have pressing issues. With interoperability, interface engines, complex reporting, software development, and the use of custom integration to ease workflow burden; community hospitals need more diverse technical resources than ever before to address vastly different functions.

Technical employees can be exceedingly difficult to recruit. Many managers get caught in a repeating cycle of recruiting, vetting, testing, and hiring. With different skill sets needed at different times, you might never have the correct individual employed for those pressing initiatives.

Could a team of virtual experts that possess the myriad of technical requirements and experience be the answer? Would you call on them to help? If you needed 10 hours a month of help at a very competitive rate for one year, would you sign up?

Engineering Concierge is the idea of the future. Gone is the idea of one individual to handle one set of challenges. Engineering Concierge is one point of contact for all technical services, even the most diverse skill set that might not typically be part of your team. As your needs change, let the solution remain the same.

To learn about The HCI Solution’s Engineering Concierge Services  CLICK HERE.


API component of Promoting Interoperability

There isn’t a week that goes by that we don’t receive a question about the Provider to Patient Exchange or API component of Promoting Interoperability. With the measure carrying a weight of 40 points in the new manner of 2019 scoring methodology and needing to amass 50 points, it is understandably a consideration.

With MEDITECH Greenfield, I was hoping to see some application development so hospitals would have a choice. Unfortunately, the economics of developing applications for patients to choose are quite anemic. Patients should not have to pay for their own health information and almost certainly, are not willing to do so without some other value associated. Even large organizations known for cutting edge development and deep pockets aren’t touching it. Google Health anyone?

When apps are developed, the hospital will have to test the ability of those apps to work in their environment. There is also the scary thought of a hospital being responsible for any breach on an 3rd party app that is promoted. You can check that information out on the HHS website.

MEDITECH does have quite a bit of information on their website. You might want to check it out and check back often.

To me, the key is the wording of the attestation requirements:

Provide Patients Electronic Access to Their Health Information

  • DENOMINATOR: The number of unique patients discharged from an eligible hospital or CAH inpatient or emergency department (POS 21 or 23) during the EHR reporting period.
  • NUMERATOR: The number of patients in the denominator (or patient authorized representative) who are provided timely access to health information to view online, download and transmit to a third party and to access using an application of their choice that is configured to meet the technical specifications of the API in the eligible hospitals or CAHs CEHRT.

Making certain you have the API component of Promoting Interoperability configured and available sets you up for success with this measure. In addition, keep your portal up and rolling!