FHIR Chat · URL Matching · FHIR at Scale (FAST): Exchange with/without intermediaries

Stream: FHIR at Scale (FAST): Exchange with/without intermediaries

Topic: URL Matching

---

Gino Canessa (Oct 19 2021 at 18:13):

Hi all, just starting a thread based on our discussion today (October 19) regarding URL matching.

I'm trying to include my assumptions, since I'm not convinced I don't have some wrong ones =).

• A directory has a method for matching an entity (e.g., Actor 2) to a URL (e.g., actor2.intermediary-abc.com/r4, r4.intermediary-abc.com/actor2, etc.).
• A client interested in contacting Actor 2 queries the directory and gets back a URL.
• A client uses the returned URL as the base FHIR URL to make queries against Actor 2 (via intermediary-abc).
• Given that the requests are just standard FHIR requests, intermediary-abc is responsible for sorting out their convention, routing rules, etc.
  • intermediary-abc will establish their conventions based on their architecture, tech stack, etc.
• URLs are opaque to a caller (e.g., any convention should is acceptable).
• Actor 2 has some sort of relationship with intermediary-abc, such that they receive their opaque base URL that they should use in their links, etc.

Is this correct? And/or, what am I missing? Thanks!

Gino Canessa (Oct 19 2021 at 18:23):

If I were to map the same process using HTTP Headers:

• A directory has a method for matching an entity (e.g., Actor 2) to a URL (e.g., intermediary-abc.com/r4, r4.intermediary-abc.com, etc.) plus a header value for a documented header (e.g., FHIR-Entity=actor2).
• A client interested in contacting Actor 2 queries the directory and gets back a URL and header value.
• A client uses the returned URL as the base FHIR URL to make queries against Actor 2 (via intermediary-abc), with the expected header value.
• intermediary-abc is responsible for routing based on the header value
• URLs and header values are opaque to a caller (e.g., any convention should is acceptable).
• Actor 2 has some sort of relationship with intermediary-abc, such that they receive their opaque base URL that they should use in their links, etc.

Again, is this correct?

Mike Yackanich (Oct 19 2021 at 18:43):

Hi Gino, I'm digesting your example above....

OK - here goes. I numbered the steps in the flow you outlined and added comments underneath. Perhaps you can provide some example request URLs to illustrate your suggestions?

1. A directory has a method for matching an entity (e.g., Actor 2) to a URL (e.g., actor2.intermediary-abc.com/r4, r4.intermediary-abc.com/actor2, etc.).
   MikeY>>> Agreed.

2. A client interested in contacting Actor 2 queries the directory and gets back a URL.
   MikeY>>> Agreed.

3. A client uses the returned URL as the base FHIR URL to make queries against Actor 2 (via intermediary-abc).
   MikeY>>> Agreed.

4. a) Given that the requests are just standard FHIR requests, intermediary-abc is responsible for sorting out their convention, routing rules, etc.
   MikeY>>> I am not clear on this. If the client initiator (Actor 1) sends a request to an intermediary then the intermediary's baseURL should be used AND a target destination id should be added to it. That would come from Actor 1's directory - so Actor 1 themselves doesn't need to do any injecting of target or anything.

An example Patient read would be: https://abc.im1.com/fhir/r4/parkland/Patient/123. When the intermediary receives that request, it needs to parse the subdirectory path and extract out the target destination id. The intermediary needs to know that this request should be routed to "parkland". There has to be rules on how to do that. I propose we take the following standard format (this is from hl7.org/fhir)

VERB [base]/[type]/[id] {?_format=[mime-type]}

and inject a target identifier in the path immediately after the [base] of the intermediary:

VERB [base][/TargetId]/[type]/[id] {?_format=[mime-type]}

Intermediary should then ALWAYS identify and extract the target id from the same location in each request.

4. b) intermediary-abc will establish their conventions based on their architecture, tech stack, etc.
   MikeY>>> Not sure what you mean. Once 4a is done, Intermediary will then determine how to route to "TargetId" - most probably based on their own directory search.

5. URLs are opaque to a caller (e.g., any convention should is acceptable).
   MikeY>>> Agreed that they are opaque. Don't agree that any convention is acceptable, because how would intermediary know how to parse the request?

6. Actor 2 has some sort of relationship with intermediary-abc, such that they receive their opaque base URL that they should use in their links, etc.
   MikeY>>> not sure I understand. See my feedback under 4b - I think it's related.

Vassil Peytchev (Oct 19 2021 at 18:49):

This matches my understanding/assumptions.

Mike Yackanich (Oct 19 2021 at 18:59):

Forgot to add, @Gino - I do understand and agree with your outline of the HTTP Header approach.

Michael McCune (Oct 19 2021 at 19:08):

Yes, agreed that 4a is the most concerning part. The intermediary could potentially be flexible with the URI that it received if there was an agreement between actor 2 and the intermediary. For example, it would be agreed upon that the URI sent to the intermediary maps to the R4 endpoints of the intermediary and the destination....in other words, this is a R4 API. This may add complexity.

Michael McCune (Oct 19 2021 at 19:11):

It would have to be a unique URI such that if we see the URI from the initiator then we know that uniquely maps to responder actor 2 and no one else.

Gino Canessa (Oct 19 2021 at 19:12):

Great!
4.a) How does Actor 1 know that intermediary-abc is the URL for Actor 2? I assumed it was via looking up Actor 2 in the directory.

• If that is true, the URL will include all the relevant path segments - Actor 1 does not need to inject anything specific to Actor 2 into the request, because it is, by definition, the URL for Actor 2.
• If that is not true, Actor 1 has some external knowledge of the URL for Actor 2. If Actor 1 already has a mapping from Actor 2 to intermediary-abc, it should not be an extra burden to include the additional path components of a URL. (Indeed, it will likely need some path segments regardless, since it's unlikely that every intermediary will use a bare domain for their FHIR base URL).

Using your example URL: https://abc.im1.com/fhir/r4/parkland/Patient/123 , Actor 1 shouldn't care whether it uses that URL or something like https://abc.im1.com/fhir/r4/some-unique-key-like-a-guid/Patient/123 - the URL is opaque to Actor 1. My argument is that the mapping from intermediary-abc to Actor 2 is an implementation detail that I don't think we should be involved in defining.

More generally, I believe
VERB [actor2-actual-base]/[type]/[id]{?_format=[mime-type]}
should map to
VERB [actor2-base-url-via-intermediary-abc]/[type]/[id]{?_format=[mime-type]}

This means that Actor 1 is not responsible for injecting anything, and that existing clients will work 'out of the box' (e.g., I can take an arbitrary SMART on FHIR App and point it at [actor2-base-url-via-intermediary-abc]).

Michael McCune (Oct 19 2021 at 19:15):

In short, the URI proposed by Gino would have to be unique for all requests received by the intermediary:
VERB [actor2-base-url-via-intermediary-abc]/[type]/[id]{?_format=[mime-type]}

Michael McCune (Oct 19 2021 at 19:16):

because the URI uniquely defines the target destination as a whole -- the one constraint is that the hostname must route to the intermediary.

Michael McCune (Oct 19 2021 at 19:19):

as mentioned, there does have to be some agreement between the intermediary and actor 2 on the URI -- they must agree on something that uniquely identifies actor 2 and they must agree on the mapping of the URI to the base URL or URI of actor 2.

Gino Canessa (Oct 19 2021 at 19:19):

Yes, so if the intermediary wanted their clients to be:

• client1.intermediary-abc.com, client2.intermediary-abc.com, etc.
• intermediary-abc.com/client1, intermediary-abc.com/client2, etc.
• r4-endpoints.intermediary-abc.com/client1, r4-endpoints.intermediary-abc.com/client2, etc.
• intermediary-abc.com/fhir/r4/provider/client1, intermediary-abc.com/fhir/r4/client2, etc.
• or even intermediary-abc.client1.com/r4, intermediary-abc.client2.com/r4, etc.

Those are all viable routing patterns, based on how intermediary-abc wants to design their system (and work with their clients).

Patrick Murta (Oct 19 2021 at 19:21):

Yes, actor 1 looks up actor 2 in directory optimally or if the directory is not yet established, has downloaded some agreed upon directory endpoint.

Initially, the app path concept considered using a segment of the URL, not the entire URL, but I think the entire URL is probably workable as well.

Actor 2 is responsible for telling the intermediary the unique URL of which transactions should be routed to them. Thus, there not not so much a pattern match but a full url.

Patrick Murta (Oct 19 2021 at 19:22):

and the hostname routes to the intermediary since actor 2 has full authority over the DNS configuration

Michael McCune (Oct 19 2021 at 19:23):

That is possible. In practice, each intermediary will probably advise a standard convention to follow for the URI which should make the configuration easier on the intermediary. Then, you will end up with different URI conventions from each intermediary.

Michael McCune (Oct 19 2021 at 19:25):

But, the spec could say that although intermediaries can define URI conventions, they cannot require a specific convention other than the establishment of a URI that uniquely defines the responder (actor 2).

Patrick Murta (Oct 19 2021 at 19:25):

I think each intermediary and actor 2 can define those but not mandating a constraint in the IG allows some flexibility and removes the need to look at specific segments of the URL

Michael McCune (Oct 19 2021 at 19:26):

Right, I think we are on the same page Patrick with my last statement.

Michael McCune (Oct 19 2021 at 19:28):

If the URI sent to the intermediary can be almost "anything under the sun" as long as it's unique, there will likely be additional web layer based forwarding/rules that say map URI xyz to the R4 URI for the intermediary...things like that.

Michael McCune (Oct 19 2021 at 19:29):

So that's one reason intermediaries will probably prefer to establish a convention for the URI.

Patrick Murta (Oct 19 2021 at 19:30):

Agree, but providing that flexibility at the intermediary/actor level is probably more easily digested than a IG level constraint...

Michael McCune (Oct 19 2021 at 19:34):

Yes, possibly. My thinking is that the IG should document a preferred URI convention but state that the convention is not required as long as actor 2 and the intermediary can agree on a unique URI that can be assigned to actor 2 and maps to a specific endpoint for actor 2.

Michael McCune (Oct 19 2021 at 19:36):

So you can take the preferred approach, but if for some reason that will not work out, come to an agreement on a unique URI and its mapping.

Mike Yackanich (Oct 19 2021 at 19:44):

But if it can be "anything under the sun" (I like that phrase) - that won't work if the intermediary is a FHIR Server service - because the FHIR service has it's own baseURL portion of the path. It would require that the intermediary instead be a REST service only. And if the latter, customizations would also then be required if it needed to return, for example, an OperationOutcome. For example, what if the "anything under the sun" value did not map to anything within the intermediary - I expect that the behavior of the intermediary should be to return an OperationOutcome with a related error message.

I need to re-read the examples above...

Michael McCune (Oct 19 2021 at 19:48):

Hi Mike Y - the "anything under the sun" URI is not truly anything -- it's an agreed upon URI between the intermediary and actor 2 but it must uniquely define actor 2 and map to a specific endpoint for actor 2 and map to a specific intermediary endpoint. In this case, the intermediary would likely need to do some web server "magic" to rewrite or forward the request to the appropriate intermediary endpoint.

Michael McCune (Oct 19 2021 at 19:50):

Since the "magic" will put some extra burden on the intermediary, I stated my preference for establishing a URI convention and have the agreed upon URI (not using the convention) be more like the exception to the rule.

Mike Yackanich (Oct 19 2021 at 20:01):

I think I'm coming at this from the perspective of an intermediary as a FHIR Server. With that said - there is no "agreed upon URI". The Intermediary will have a FHIR baseURL that must be used. A target identifier can then be added/appended/inserted AFTER that - but it can't mess with the baseURL. Based on how I am interpreting MikeM and Gino's comments - it seems like y'all are looking at the Intermediary not as a FHIR Server, but as a RESTful application service that says "send me anything you want and I'll figure it out and map it to a target endpoint". Is that my disconnect?

Gino Canessa (Oct 19 2021 at 20:01):

I think I'd argue that pushing a specific pattern on intermediaries is a higher burden. What is 'simple' to do depends greatly on tech stack and architecture.

Offering examples is great, but if we give a "recommended" approach, we need to do the diligence to ensure it's meeting the 80% rule for implementers.

Michael McCune (Oct 19 2021 at 20:05):

Mike Y - I am only focused on the intermediary as a FHIR pass-through right now or little more than a pass through and not a FHIR resource server that directly provides access to FHIR resources. In other words, only actor 2 provides FHIR resources.

Mike Yackanich (Oct 19 2021 at 20:12):

Yes - agreed. Intermediary as a passthrough or proxy - not a resource repo. Like our existing fhirproxy. Which has a specific app path (part of baseURL) that must be used to access it (i.e. /fhirproxy/fhir/r4). I don't see how we would be able to support

/parkland/fhirproxy/fhir/r4
or
/fhirproxy/parkland/fhir/r4

We have to have that baseURL portion consistently be /fhirproxy/fhir/r4.

But that is implementation specific.

Gino Canessa (Oct 19 2021 at 20:18):

Mike Yackanich said:

I think I'm coming at this from the perspective of an intermediary as a FHIR Server. With that said - there is no "agreed upon URI". The Intermediary will have a FHIR baseURL that must be used. A target identifier can then be added/appended/inserted AFTER that - but it can't mess with the baseURL. Based on how I am interpreting MikeM and Gino's comments - it seems like y'all are looking at the Intermediary not as a FHIR Server, but as a RESTful application service that says "send me anything you want and I'll figure it out and map it to a target endpoint". Is that my disconnect?

The FHIR Base URL doesn't have any particular magic - it's just a URL that counts as the 'root' of a FHIR server (e.g., can service [type]/[id], root operations, etc.). Adding anything before the 'FHIR API' part is just changing the base URL as far as a caller is concerned.

I'm not sure how something else could be inserted there and still be FHIR compliant, since there is no concept for URL parts in between those two components. E.g., if I tell an app that my base URL is example.com/actor2, it works - regardless of whether I am using HTTP routing or I have built a FHIR implementation that virtualized actor2 internally. Telling a client that the base URL is example.com (e.g., metadata is example.com/metadata) but that I need to make requests to example.com/actor2/Patient isn't valid - no existing software would be able to handle that.

Mike Yackanich (Oct 19 2021 at 20:27):

Yeah. "I'm not sure how something else could be inserted there and still be FHIR compliant, since there is no concept for URL parts in between those two components."

Yes - that was my original thought when "AppPath" routing was being introduced. I saw it as a bastardization of the Intermediary's baseURL.

"Telling a client that the base URL is example.com (e.g., metadata is example.com/metadata) but that I need to make requests to example.com/actor2/Patient isn't valid - no existing software would be able to handle that."

Yeah - this is where the customization within the Intermediary comes into play. Like what we have done and demonstrated in the POC at the past couple of connectathons. We needed rules for parsing the request so that we could deconstruct and extract the target identifier - so that we could do a directory lookup to find that target's endpoint. So the intermediary has to be able to accept "example.com/actor2/metadata" and turn it into "actor2.com/metadata" (if that makes sense).

Michael McCune (Oct 19 2021 at 20:31):

Right, there wouldn't be a static base URL that could be used with an intermediary with app path routing.

Michael McCune (Oct 19 2021 at 20:34):

The base URL for the intermediary always changes -- either adding a component that indicates the destination such as "/actor2" or the entire base URL is an agreed upon base URL between the intermediary and actor 2 that uniquely identifies actor 2 so that the Hub (intermediary) knows to route to actor 2.

Michael McCune (Oct 19 2021 at 20:35):

In that sense, Mike Y has a point that the base URL for the intermediary is non-standard and not static.

Michael McCune (Oct 19 2021 at 20:38):

So with respect to the intermediary, the base URL for the intermediary is constantly in flux, such as:
-- For actor 2 which is a responder and not an intermediary: example.com/actor2
-- For actor 3 which is a responder and not an intermediary: example.com/actor3
-- For actor 4 which is a responder and not an intermediary: example.com/actor4
...and so on

Michael McCune (Oct 19 2021 at 20:42):

.... we are saying that there is going to be a non-static component to the base URL when you send the request to the intermediary, unless we define the routing component outside of the base URL. If neither of those options seem viable, then I'm not sure that the app path solution as a whole is viable?

Vassil Peytchev (Oct 19 2021 at 20:42):

Why is there a need to have "an agreed upon base URL between the intermediary and actor 2"? It seems to me that this is trying to solve some not-yet-described problem with the directory lookup - is that the case?

If we go back to the original write-up that Gino did, why is there a need for 4a to be part of any consideration?

Michael McCune (Oct 19 2021 at 20:47):

Most servers (any type of web server, regardless of FHIR) have a defined URL/endpoint to connect which is commonly defined at the web server layer. An intermediary is no different. Vassil -- what do you propose about the application path part of the URL (minus the hostname) that is sent to the intermediary? What does that look like?

Vassil Peytchev (Oct 19 2021 at 20:49):

we are saying that there is going to be a non-static component to the base URL when you send the request to the intermediary, unless we define the routing component outside of the base URL.

Is there some assumption that states that the intermediary must dynamically construct URLs for arbitrary destinations? The way I see the intermediary providing a service to actor 2 is:

1. Have a formal agreement for providing a service to actor 2
2. Establish routes from intermediary to actor 2
3. Statically declare the base FHIR URL for handling requests on behalf of actor 2 and publish them in a shared directory

What are the missing pieces?

Gino Canessa (Oct 19 2021 at 20:49):

Yes. So at the end of the day, it's opaque to callers whether it is:

• example.com/actor1
• actor2.example.com
• example.com/actor/3/
• example.com/<UUID>/
  ... even within a single intermediary.

Since the caller needs to look up the URL of the intermediary regardless (e.g., in this example, example.com), and that URL is mapped via the actor, saying that the URL/app path is used for routing becomes transparent and an implementation detail of the intermediary.

This means that intermediaries:

• have the flexibility to route based on their architecture
• are not forced into a mapping system we define (e.g., human-readable, regionalized, UUID, etc.)
• can change their patterns over time
• can choose to have multiple endpoints for a single actor, depending on some other rules (e.g., region, etc.)
  etc.

Michael McCune (Oct 19 2021 at 20:59):

Opaque to the callers sounds good, I agree. For the intermediaries, it's easy to route to the next hop as long as the URI used by the caller uniquely identifies actor 2. I get what you are saying about not enforcing a URI convention so each intermediary may establish their own convention...

Vassil Peytchev (Oct 19 2021 at 21:00):

what do you propose about the application path part of the URL (minus the hostname) that is sent to the intermediary? What does that look like?

As Gino said - it is an implementation detail for the intermediary.

I think now I understand what you mean by a non-static component of the app path - it is non-static with regards to a single instance of a web server application, which is handling the routing for all destinations (presumably with some kind of lookup based on the incoming URL). I think this is still an implementation detail - an intermediary may very well have multiple instances of the web server application, each with their own app path, and a static configuration setting for the destination.

There is no need to be prescriptive about any of this.

Michael McCune (Oct 19 2021 at 21:08):

To be clear, each Intermediary will want to enforce a convention although intermediaries don't need to use the same convention. A convention makes the difference between a highly manageable solution and a solution that is bogged down by requests that allow for any URI format being received by the intermediary. At the web server layer of the current eHealth Exchange solution, mapping for any URI format for each actor is a hand edit in a configuration file -- very error prone and not a good idea if it can be avoided.

Michael McCune (Oct 19 2021 at 21:12):

As long as each intermediary can prescribe a URI convention, then that makes the solution much more feasible.

Michael McCune (Oct 19 2021 at 21:24):

So the process would be the following when the intermediary is acting as a FHIR pass through:
1) Actor 2 (the responder with a FHIR resource server) wants to work with an intermediary (INTM 1).
2) The intermediary provides a URI convention to actor 2 in order for callers to send requests through INTM 1 and eventually onwards to actor 2. The URI convention may prescribe the app path and port including an app path component that designates the responder as actor 2 -- taken as a whole, this is effectively a "base URL" for INTM 1.
3) The intermediary and actor 2 will agree that the URI established under #2 will map to a specified base URL for actor 2.
4) Actor 2 publishes the URI established under #2 in a directory accessible to actor 1 (the caller).

Mike Yackanich (Oct 19 2021 at 21:33):

OK - I got it. It sunk in. We're kinda saying something similar except I'm talking a specific implementation of the AppPath approach.

For our implementation that we've created for the CAT testing, for example, we required /fhirproxy/fhir/r4/<target>/[type]...and that is how directory entries pointing to us as an intermediary would have to be formatted. From Actor1's (ultimate initiator) perspective - that endpoint/path is opaque.

Carry on. Nothing to see here. :grinning:

Vassil Peytchev (Oct 19 2021 at 21:33):

I agree. Steps 2 and 3 are only relevant to Actor 2 and INTM 1, and are therefore an implementation detail. Do you see a need for some specific coordination there that needs guidance?

Michael McCune (Oct 19 2021 at 21:40):

For step #3, I don't think any guidance is needed. For step #2, I cannot think of any guidance needed -- possibly one exception would be the hostname used in the URI to connect to INTM 1 -- can the hostname be specified by actor 2 as long as it maps to the IP address of INTM 1?

Gino Canessa (Oct 19 2021 at 21:43):

If the domain belongs to the actor, the intermediary needs to get a certificate from them in order to host an HTTPS endpoint. It's viable, but requires more coordination than the other way around.

Michael McCune (Oct 19 2021 at 21:54):

Good point, thanks Gino.

David Pyke (Oct 20 2021 at 13:22):

Oh gang, what do we do when there's multiple intermediaries in the path? actor1.intermediary1.intermediary2.intermediary3.com?

David Pyke (Oct 20 2021 at 13:23):

Intermediary3.com/intermediary2/intermediary1/actor1 ?

Vassil Peytchev (Oct 20 2021 at 13:44):

I think it is best to approach it the same way as eating a large meal - one bite at a time. As long as actor1 and actor2 don't need to be aware that there are intermediaries, there are ways to resolve the routing and other requirements. Navigating a federated network of networks is not necessarily a new problem.

Michael McCune (Oct 20 2021 at 14:07):

Hi @Patrick Murta or @Frank McKinney -- are you able to capture our thoughts from yesterday afternoon's chat above? Let us know if we need to summarize or make it more concise.

Gino Canessa (Oct 20 2021 at 14:09):

I think the thing to keep in mind is that TCP connections are 1:1. Regardless of how many layers or hops are actually involved with servicing a request, the most anyone can publicly know is the next URL.

Someone is responsible for that domain and service to actually handle a request. From there:

• If the resolution is to respond authoritatively, the server should do that.
• If the resolution is to forward somewhere else, that system can do that (edit: even if it's another intermediary - though the resolution needs to be setup in such a way as to avoid infinite loops).
• If the resolution is to ‘fan out’ to multiple actors on their part, they need to perform their discrete operations and process the results for passing along.
  Etc.

Michael McCune (Oct 20 2021 at 14:11):

Also, doe anyone want to have an "out of band" call prior to the next scheduled HL7 call, if that's possible? I'm hoping that might speed this up.

Frank McKinney (Oct 20 2021 at 16:19):

Hey @Michael McCune , @Patrick Murta , all. Great discussion... just finished making my way through. Yes, I'll take a whack at capturing the discussion and resolution and will reach out if I need clarification.

Michael McCune (Oct 20 2021 at 16:20):

Excellent, thanks very much @Frank McKinney

Frank McKinney (Oct 20 2021 at 16:23):

I'd welcome an additional call prior to the next one scheduled for the 2nd. Others interested?

Michael McCune (Oct 20 2021 at 16:49):

Yes, I'm interested, in case that wasn't obvious. :-)

David Pyke (Oct 22 2021 at 15:33):

Please post the meeting details once you have it set?

Patrick Murta (Oct 27 2021 at 12:02):

@Michael McCune , @David Pyke , @Frank McKinney , @Gino Canessa, @Mike Yackanich , @Vassil Peytchev
Can folks make Thursday October 27th at 5 to 6PM eastern time work? We will get a link to the updated IG out before then.

Frank McKinney (Oct 27 2021 at 13:31):

Hi @Patrick Murta , @Michael McCune @David Pyke , @Gino Canessa , @Mike Yackanich , @Vassil Peytchev , all. It looks like 5-6 this Thursday the 28th works for most folks. We'll be adding details to the HL7 calendar shortly.

Michael McCune (Oct 27 2021 at 13:52):

Thanks. Please let us know when we can pickup the calendar invite.

Frank McKinney (Oct 27 2021 at 16:05):

@Patrick Murta , @Michael McCune @David Pyke , @Gino Canessa , @Mike Yackanich , @Vassil Peytchev , all. Because there's an overlapping FHIR-I call, we weren't able to add this week's meeting to the calendar, but it will still be happening at 5-6 ET this Thursday. We sent out invites to folks who have attended earlier calls and also posted to the FHIR-I listserv. But if you didn't see either of those, here's the meeting info:

https://global.gotomeeting.com/join/815167661
You can also dial in using your phone.
(For supported devices, tap a one-touch number below to join instantly.)
United States: +1 (872) 240-3212

• One-touch: tel:+18722403212,,815167661#
  Access Code: 815-167-661

Frank McKinney (Oct 28 2021 at 20:35):

Hi @Patrick Murta , @Michael McCune @David Pyke , @Gino Canessa , @Mike Yackanich , @Vassil Peytchev , all. The draft IG has been updated to (hopefully) align to where the group is landing. In particular, on the Specification page...

Added an Assumptions section including where I hear us landing on partnership and setup between the destination and intermediaries
Updated the FHIR Service Base URLs section to...

• indicate that the guide does not prescribe a particular URL structure
• add content describing Private FHIR Service Base URLs Used in routing between intermediaries and to the actual destination server
• add content addressing sharing of private URLs among the destination and partner intermediaries
  Removed HTTP header and query string parameter approaches

I also added a very draft Security guidance page

We can walk through these sections in our call today and see what should be changed or added. And feel free to discuss here on Zulip as well

Frank McKinney (Nov 02 2021 at 16:42):

Hi all. I made updates to the Exchange IG's specification page ... adding a couple higher-level context pictures that we'll talk through during our call today at 1 ET

Frank McKinney (Nov 02 2021 at 16:44):

Call details are on the HL7 calendar. But here's the zoom info:
https://global.gotomeeting.com/join/262996117

---

Last updated: Apr 12 2022 at 19:14 UTC