Personally, I think you need to hire a security consultancy company to properly cover the security issues here. Your exact security issues will likely be highly contextual, and there are additional regulatory implications in hospitals. That said, I'll try to cover your concerns.
This application is in use in many large hospital systems, so finding it hard to believe that vendor wouldn't have addressed this somehow
Unfortunately, that's pretty common. Speak to anyone who handles IT infrastructure, networks, security, software, etc. in a hospital (or any organisation really) and they'll tell you the same thing - vendors are usually slow to fix problems, and often won't put the effort in for legacy products that are still relied upon.
Is this is a concern?
Most likely, yes. You're putting an out-of-date, insecure framework on the affected systems. Java can be invoked via the browser unless it is properly configured, which potentially allows for remote attacks against the system. Another potential attack vector against the framework is via Java web servers such as Apache Tomcat, which might expose exploitable functionality (e.g. RMI) regardless of what the application does.
What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?
The problem is that, if they're using out of date Java (esp. 1.6 or earlier) then it doesn't really matter what they do to address individual vulnerabilities in their application - the underlying framework itself is broken and they can't mitigate that individually.
Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?
The simple answer is yes. The more complex answer is that you could sandbox off the application server so that, if it were to be compromised, there's a limited level of access that it has back to your internal network, if any. However, if patient data is included (especially any PII) then you've got regulatory requirements to contest with.
The TL;DR is that the vendor should update their code to work with a more modern version of Java. There are two primary ways you can expedite this: offer to pay towards the development time required to do so, or threaten to switch off their service and use an alternative which is more up-to-date.
Another avenue you have is regulatory: assuming you're in the US, tell your HIPAA regulatory body that their software uses a vulnerable framework that results in risks exposure of patient information. If their customer base is large, they may be required by law to update their software or otherwise mitigate any issues.
