Software Company in Kansas City: A Keep, Wrap or Replace Sheet for Health System Connections

Updated November 2026 · Written and maintained by the Progression Agency strategy team

There is an interface running in production that no one at the hospital can name an owner for, and the vendor who wrote it was bought, moved or reorganized years ago. A software company in Kansas City working in health IT meets this all the time. Oracle’s consolidation of the former Cerner campuses here, as reported in September 2025, has some teams asking which custom connections still have a future. This page is a working sheet: one row per connection, each marked keep, wrap or replace, with the information blocking rules beside it. It is for CIOs, integration leads and health tech founders. Progression is headquartered in New York and serves Kansas City clients remotely, with on-site sessions on request.

The interface with no owner

Every health system has one. It started as a quick fix, moved patient or billing data between two systems, and kept running after the person who wrote it left. Nobody touches it because nobody knows what else depends on it.

The row above is invented, but the problem is common. The sheet on this page begins with a blank owner column and does not end until each row has a name in it and a decision beside the name.

What a software company in Kansas City inventories first

Kansas City has a long history in health IT, and the news is now about change. HIT Consultant reported on September 4, 2025 that Kansas City area employees at Oracle, now headquartered in Nashville, had received layoff notices. It also reported that, since acquiring Cerner, Oracle has closed former Cerner campuses and consolidated work at its Innovations Campus near Interstate 435 and Bannister, and cited a 2024 Bloomberg report on the size of Oracle’s Kansas City workforce. Those are the report’s statements, quoted for context and not as current figures.

What matters to a health system is local and practical: which connections depend on people, vendors or products that have changed. The first job is a list. Every connection, the data it carries, the person who owns it and the way it fails.

Our healthcare software development page describes the wider service. The sheet below is the working tool.

The sheet

One row per connection. The decisions below are invented examples to show the format, and a real sheet has your own connections and your own reasons. The band column gives the published market range for that kind of work.

What goes in the columns after the decisions?

Add three columns once the decisions are made: who approves, who pays and when. A sheet with no dates is a wish list.

Keep: when the old thing is the right thing

An old connection is not a bad connection. If it is stable, documented and owned, replacing it spends money to remove something that works. The decision to keep deserves a written reason, so the next person does not reopen it.

• Write down what it does, who owns it and when it last changed.
• Run a test that proves it still works after each upstream change.
• Set a date to review the decision.
• Name the person who gets the call if it stops.

Is a custom interface always a problem?

No. A custom interface that is stable, documented and owned can outlast a product. The risk comes from the missing owner and the missing page of notes, not from the age of the code.

Wrap: put a seam around it

A wrap leaves the old connection in place and puts a controlled layer in front of it. Everything new talks to the layer, and the layer talks to the old feed. When the feed is finally replaced, only the layer changes.

Federal rules describe what certified health IT must offer. Under 45 CFR 170.315(g)(10), certified health IT provides a standardized API for patient and population services, responding to requests for patient data under the listed standards, with complete publicly accessible documentation. A wrap for your own connection should aim at the same habits: standard requests, complete documentation, and tests that you can run. See API development and web portal development for the build side.

Replace: when a connection blocks access

Some connections need replacing because they stand between a person and their own data, or between two systems that must exchange it. The federal rule on information blocking is the reason to look closely.

Under 45 CFR 171.103, information blocking means a practice that, except as required by law or covered by an exception, is likely to interfere with access, exchange or use of electronic health information. For a health IT developer of certified health IT, a network or an exchange, the test is that it knows, or should know, that the practice is likely to interfere. For a health care provider, the test is that the provider knows the practice is unreasonable and likely to interfere. Section 171.102 defines an actor as a health care provider, a health IT developer of certified health IT, a health information network or a health information exchange.

This page does not say that any company is engaged in information blocking, and it does not tell you whether a given practice is. Whether a connection raises the question is a matter for counsel. Our HIPAA compliant software development page covers the privacy work that any replacement carries.

• A connection that makes patient data hard to get belongs on the replace list for review.
• A connection with one fixed format and no documentation belongs on the wrap list at least.
• Ask counsel before changing anything that touches access, exchange or use of records.
• Keep a dated note of why each decision was made.

What each row costs, and the table

Software development in Kansas City is priced by what a row asks for: a small wrap, a rebuilt integration, a portal or a platform. Hosting, licenses and security testing come on top, and the first thing to settle is which rows are worth acting on this year.

Bands for integration and platform work

The bands run from the typical low to the published high.

Progression quotes after a written scope.

Where the row costs hide

Testing against vendor sandboxes is the usual surprise. Each vendor has its own test environment, its own approval time and its own limits. Ask for sandbox access in the first week, and write the testing into the scope with a price. Security testing, hosting and licenses are separate lines.

• Vendor sandbox access and the time it takes to get it.
• Security testing and a review of PHI handling.
• Data migration and the dry runs before cutover.
• Training for the people who use the result.

Who signs off on a row?

A decision on a connection touches clinical staff, security, finance and the people who run the system. Settle in advance who has the last word on each kind of row, or the sheet stalls at the first disagreement.

• Name one decision owner per row so there is a single person to ask.
• Record the date and the reason beside each sign off.
• Escalate disagreements to a named executive, not a meeting.
• Revisit a keep decision when the vendor, the data or the law changes.

What does the work look like after the sheet is done?

A finished sheet turns into a short sequence of projects. The first usually fixes owners and tests, the second wraps what is worth wrapping, and the third replaces what must go.

• Do the owners and tests first because they cost the least.
• Wrap before replacing when callers outnumber the old feed.
• Rehearse each cutover on a copy before touching production.
• Keep the sheet alive; a dated review beats a thick binder.

Which row should be replaced first?

The one where a failure would hurt most or where the old connection blocks something people need. Start there, learn from it, and let the next row go faster.

• Rows that block access to records or exchange between systems.
• Rows with no owner and no documentation.
• Rows tied to a product that is no longer maintained.

Software companies in Kansas City and the first inventory week

Software companies in Kansas City that work with health systems can run the first inventory in five days. The point of the week is a sheet with every row marked, not a finished plan. For crews that cross the line, our page about app developers in Kansas City shows what a field app stores at each stop.

Custom software development in Kansas City for a health system starts with that sheet, because it tells you which rows need new code and which only need a name and a test. Keep the week short, and make the owners come to the room.

Should we replace everything at once?

No. Replace by row, in the order that risk and value suggest. A single replaced row teaches the team what a good cutover looks like, and the next one goes faster.

If your search is wider than software, we also run marketing in Kansas City and SEO in Kansas City for local businesses.

Related services and guides

Pages that sit beside this sheet:

• Software development company
• Healthcare software development
• HIPAA compliant software development
• API development
• Web portal development
• Software development in Chicago

Frequently asked questions