HIPAA's states: "the privacy rule requires a covered entity to reasonably safeguard PHI from any intentional or unintentional use or disclosure that is in violation of the requirements of HIPAA" Your main goal is to protect data in transit, and data at rest. Encryption covers most of this for you so let's look at your question:
"I have a private service that exposes sensitive information (PHI)
via a REST API, and that I want to permit access to it from only one
other service"
SERVICE (API) ---> connection ---> ONE OTHER SERVICE
ROUND 1: Your first concerns should be securing the REST API to the best of your ability (a covered entity to reasonably safeguard PHI from any intentional or unintentional use or disclosure).
SERVICE (API) [ROUND 1] ---> connection ---> ONE OTHER SERVICE
Your second concerns would be minimizing, removing, encrypting (if possible) PHI during transit. You don't want anyone being able to sniff the wire and either see data, or be able to create any kind of inference attacks. Crypto standards/guidelines on HIPAA can be searched, so they literally tell you what is and what isn't acceptable.
SERVICE (API) [ROUND 1] ---> [encrypted/tunneled] connection [encrypted/tunneled] ---> ONE OTHER SERVICE
Lastly, on the "one other service" machine, the same rules would apply. Encryption whenever possible, minimalist (need to know) access.