Stream: implementers
Topic: eDelivery | ebMS3/AS4
Alexander Henket (Apr 06 2017 at 14:55):
Hi. I'm trying to make sense of recent development in The Netherlands where more and more documentation comes up suggesting that we need to deploy an ebMS based infrastructure to support PHR / EHR connections. Note that we are not talking about patient portals, or SMART on FHIR apps, but EHR agnostic patient environments that connect to "any EHR".
.
Content wise we seem to all agree that it needs to be FHIR, but infrastructurally ebMS is pushed. One of those reasons is because the EU came up with a CEF standard called eDelivery (https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+How+it+works), and another would be because XDS uses ebXML, and this recommendation from Australia says so (http://www.sbr.gov.au/__data/assets/pdf_file/0018/42750/Message-Protocols-for-Enabling-Digital-Government-Services-Final-Report.pdf).
.
ebMS may or may not be a bad choice, but I fail in making the right connections with some dynamic aspects of FHIR. What would a CapabilityStatement for ebMS look like? Does it even make sense to have one? How do I query/search FHIR stuff using ebMS? By repackaging the query into a generic $search operation?
.
I'm looking for pointers and/or a nice conversation in Madrid.
Lloyd McKenzie (Apr 06 2017 at 14:59):
You probably could come up with a way of packaging FHIR over ebMS, but you'd lose a good chunk of your interoperability by not supporting things like SmartOnFHIR which are dependent on having a REST interface.
Alexander Henket (Apr 06 2017 at 15:51):
Does SMART on FHIR not consist of two parts. 1. token negotation and 2. supplying the token in subsequente interchanges? I thought 1. is REST, but the second part does not need to be. So once you have the token you would be golden over ebMS
Lloyd McKenzie (Apr 06 2017 at 17:08):
Only if your idea of "golden" includes no smart apps working with your systems . . . Whether it may be possible to leverage parts of the technology is different from whether you'll interoperate with the existing community of systems. When pursuing an interoperability technology, a primary consideration (if not *the* primary consideration) should be maximizing the number of systems that can interoperate with you with minimal (or ideally no) customization specific to your implementation. I'm not sure how ebMS would give you that.
Grahame Grieve (Apr 06 2017 at 21:58):
ebMs is adding unnecessary layers on top of REST for no value. But that's the sort of thing that happens in the real world.
Grahame Grieve (Apr 06 2017 at 21:58):
does ebMS = xds.b?
Grahame Grieve (Apr 06 2017 at 21:59):
or just original xsd?
Grahame Grieve (Apr 06 2017 at 21:59):
or just something different?
Elliot Silver (Apr 07 2017 at 17:40):
I'm not sure, but I don't think ebMS is related to XDS.a or XDS.b. It's something different.
John Moehrke (Apr 07 2017 at 17:57):
isn't ebMS a form of SOAP for messaging... isn't it used in HL7 v3 messaging?
Jens Villadsen (Apr 07 2017 at 22:16):
https://en.wikipedia.org/wiki/EbXML#Messaging_Service_Specification
Jens Villadsen (Apr 07 2017 at 22:27):
I would take ebMS from the EU and put it in a pipe and smoke it. There is no single standard that can ensure that any environment can connect to "any EHR", and putting all the balls in one basket saying that ebMS is the single solution sounds weird to me. There is no problem in piggybacking FHIR into ebMS but is it sort of an artificial wrapping - or as Grahame once told me when I asked about putting FHIR into the unstructured part of CDA: its turtles all the way down. So you would gain a little I guess, but not much
Alexander Henket (Apr 08 2017 at 06:54):
ebMS uses ebXML and looks like SOAP with MIME attachments to me. Note that ebMS is not my choice, but coming from the EU it might be something we need to deal with. eDelivery is the outcome for creating "one single digital market" for the EU in any domain, not just healthcare. Applicability for eHealth has only just been tested. By whom, where I don't know. I'm still waiting for the report that was offered to the EU on Thursday.
The reasoning behind ebMS with inevitable repackaging involve:
- Being content agnostic. FHIR RESTfull is not, but I can use FHIR Bundle or Binary to achieve the same, comparable with Jens' FHIR wrapped in CDA :-)
- Being able to use end-to-end content encryption. No idea how to do that with FHIR
- Being able to use the defined service lookup feature. For FHIR you need to know beforehand where the service is before you can check its CapabilityStatement. With an ecosystem of PHR/care providers that do not know eachother beforehand this becomes an issue
- Being able to use async communication. FHIR typically is synchronous (this is one of the weakest arguments I think)
Lloyd McKenzie (Apr 08 2017 at 14:44):
If you need end-to-end encryption with multiple hops, you'd do a FHIR message where the payload was a Binary containing the encrypted payload. With FHIR you can have a registry of CapabilityStatements - those would tell you where the systems were as well as what they can do. FHIR messaging is there to support async. And you can do async with Tasks RESTfully too.
Grahame Grieve (Apr 09 2017 at 02:38):
actually, you can do just SSL for end to end encryption. What you can't do with SSL is partial encryption. There's some work around partial encryption in HTTP, but it hasn't gone far
Grahame Grieve (Apr 09 2017 at 02:40):
and there are projects building endpoint registrys. (oddly enough, using the EndPoint resource)
John Moehrke (Apr 09 2017 at 16:47):
The beauty of FHIR being transport agnostic is that there are many ways to get end-to-end encryption. S/MIME (like in the USA with Direct), XML-Encrypt (like in IHE-DSG), XML-Encrypt (like in WS-I profiled end-to-end soap encryption), etc...
Alexander Henket (Apr 10 2017 at 12:18):
@John Moehrke FHIR content is transport agnostic, but FHIR RESTful is not content agnostic. eDelivery as content agnostic infrastructure supports FHIR content. eDelivery comes with open source software. FHIR does. Doesn't mean that the combo works nicely... I would be able to contact zero test servers today.
Alexander Henket (Apr 10 2017 at 12:19):
@Grahame Grieve SSL is transport layer encryption, not content encryption. End-to-end content encryption (compare Whatsapp) is what I get as requirement today. The idea is that hops in the network cannot access/change contents.
Alexander Henket (Apr 10 2017 at 12:22):
@Lloyd McKenzie Yes that's the direction I'm thinking of.
Thomas Lukasik (Apr 12 2017 at 01:32):
@Alexander Henket RE "eDelivery comes with open source software" <= is 'eDelivery' a specific project or initiative that you can link me to, or are you using the term "eDelivery" generically.. as a shorthand for "electronic delivery"?
Alexander Henket (Apr 12 2017 at 06:55):
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+How+it+works Software is here: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+Services
Thomas Lukasik (Apr 12 2017 at 08:11):
@Alexander Henket Thanks!
Thomas Lukasik (Apr 12 2017 at 08:18):
@Alexander Henket ..I see now that I should have read your initial post more carefully ;-)
Grahame Grieve (Apr 15 2017 at 20:30):
I asked about this on the HTTP stds mail list, and Mark Nottingham (chair for HTTP says): http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encoding.html has some traction. Because it's part of WebPush, it'll end up in browsers too (and I think already is getting in there), although it's not clear how/if it'll be exposed generically.
Grahame Grieve (Apr 15 2017 at 20:31):
I encourage Europeans - all questions about this are from Europe - to join https://github.com/httpwg/wiki/wiki/EncryptedContentEncoding and encourage this along
Alexander Henket (Apr 18 2017 at 11:37):
Thanks Grahame. I've shared your suggestion with a number of people closer to the fire than I am. To be continued.
Last updated: Apr 12 2022 at 19:14 UTC
