This has been possible the healthcare sector for many years with HL7 and later FHIR [1].
Essentially you have a standard protocol and a set of message to exchange health-related information between the different softwares even if they from different vendors. This allows (for example) a doctor with software A to ask for a test on a patient, have a nurse see it on software B, have the sample sent to a laboratory which uses software C and then the result sent back to software A where the doctor can also check it. Meanwhile the signed document has been stored on software D.
That said FHIR especially is more than that and allows different approaches.
HL7 is a shared messaging standard, much like XML or JSON. The shared standard does allow for communication between applications, but its rather unruly.
I would say that HL7 is more like a XML + a set of XML schemas. In any case, you're right that it is only a messaging standard, but I have always seen it used in the contest of having a central broker like Mirth passing messages around so it is in my opinion a good example of what the parent poster was thinking about.
And yes, you're right, it is quite unruly (information being present in one field or another depending on the software and the like). In my experience luckily most of those issues could be handled at the broker level.
Essentially you have a standard protocol and a set of message to exchange health-related information between the different softwares even if they from different vendors. This allows (for example) a doctor with software A to ask for a test on a patient, have a nurse see it on software B, have the sample sent to a laboratory which uses software C and then the result sent back to software A where the doctor can also check it. Meanwhile the signed document has been stored on software D.
That said FHIR especially is more than that and allows different approaches.
[1] https://www.hl7.org/fhir/