FAQ: Technical

Frequently Asked Questions

I understand that our local MPOG server can connect to your central MPOG server and upload and download data.  Is it intended to be in our DMZ (outside our firewall)?  

While you do upload cases from your local MPOG server to the central repository, the connection does not need to be direct. We have a transfer application that can be run in a DMZ, transferring cases over HTTPS while keeping the database inside the firewall.

And if our firewall rules don’t allow direct connectivity, is there an FTP methodology that would allow us to send data that way?

As it currently stands, MPOG does not have a separate file protocol. We do have plans in the mid-term (~6-12 months) to refactor our transfer utility to use SFTP, but the only accepted method of sending case data to MPOG is through our transfer utility.

I assume your intended connectivity is designed to be a VPN connection, true?  If so, what are the requirements of those connections?

The transfer protocols are already encrypted, so a VPN is not needed for that.

For accessing data in the central repository, University of Michigan’s VPN is used to tunnel into our network. For this MPOG members need to get user accounts through UMHS. Once that’s done access is provided for using the MPOG application suite via Citrix.

Are there any requirements for external accounts on our local MPOG server?

No, you do not need to grant access to MPOG personnel on your MPOG server.

We are an EPIC shop, and therefore lots of the work is already scoped out, but we do NOT use EPIC Hospital and Ambulatory Billing, just the Clinicals (therefore not all billing diagnoses are available in EPIC).  It’s unclear to me what data elements I might need to pull out of our GE/IDX Billing system to load into MPOG through an alternate load process.  

We have documentation for the specifics of this, but we are generally looking for:

·         Patient identifier (typically MRN)

·         Date of service start/end

·         Procedure/diagnostic code

·         A few misc fields (e.g. data source, priority)

We do not import anything from billing systems regarding providers or charges.

And how might this affect the FTE requirements you note on your site?

Without knowing the specifics of your situation it is difficult to say exactly, but you will need additional FTE (0.5?) for a SQL developer to develop an extract for your hospital billing system.

Is there a User Interface to the MPOG server?  Is it available through a browser (if so, what browsers and versions are supported)?

We have several applications designed to work with the MPOG database. Most clinicians will use the Case Viewer, which emulates how an intraoperative record is displayed in an AIMS.

The MPOG suite is a Windows desktop application. No browser-based interface is currently available.

Is there local reporting against this server available?

No. MPOG is working on developing centralized QA reporting, but nothing is planned for a local instance.

Are there any system up-time schedule requirements for the MPOG server?  I assume that the files are loaded by batch processes utilizing Clarity extracts, so up-time is up to us.

No, we do not specify any no up-time requirements. You are correct in the extracts are batch processes, not realtime.

Is there any printing that will be needed from this MPOG server?

No.

Do you recommend a VM or Physical Server?

A VM can suffice if you are not going to be doing a lot of your own internal querying and research on the server.  At a minimum, we would recommend 4 CPU Cores, and 16 GB of memory.  If you plan on doing a decent amount of internal querying of the data, the best thing you can do is increase the amount of memory.  For instance, our Michigan internal reporting server is a physical server with 16 cores and 64GB of memory.  We have queries running on it all day, and quite honestly we wish it had more memory.

Is it possible to provide a sample of medications and clinical components that we need to map?  We are tryin to assess the level of applicaiton  understanding needed by the clinician when doing the mapping, so we can estimate the resource allocation.

Attached are some examples of how the University of Michigan mapped medications, medication units, and intraoperative notes.  It is mostly terminology mapping, which is why a clinician is necessary.  We’ve seen sites try to have their IT reps do mapping, and it hardly ever works out well. The most important piece is having very good local data/domain experts.  The initial mapping is a long process, the incremental mapping after that should be much quicker.   Sample Concept Mapping

What are the different MPOG database roles?

The following database roles are available to help control access to the MPOG database:

MPOG_Researcher
General-use role for minimal access (little to no update/delete rights), enables case viewer and data diagnostics.

MPOG_CaseValidator
Grants rights necessary to use the case validator utility

MPOG_VariableMapper
Grants right necessary to use the standard variable mapping utility.
Should be granted in conjunction with MPOG_Importer on the MPOG_MAS_CONFIG database

MPOG_ContentDownloader
Allows the user to run the Content Sync utility which updates the MPOG_ tables

MPOG_Importer
Broad access to the data for the purposes of importing data (has insert/delete/update/select rights on most tables)

MPOG_Exporter
Allows users to use the transfer utilities.