FHIR Chat · endpoint · IPS

Stream: IPS

Topic: endpoint

Jens Villadsen (Aug 23 2021 at 12:48):

@Rob Hausam / @Giorgio Cangioli I would like to add some potential definition for obtaining the IPS as a capability statement on https://hl7-eu.github.io/gravitate-health/index.html. Could you guys provide me with some guidance here? Potentially the capabilitystatement that will be used for the cthon #28

John Moehrke (Aug 23 2021 at 13:27):

The way we are thinking of this in IHE... First, the IPS top level profile is what we would use as the FormatCode. Thus in the EndPoint.payloadType element on servers supporting IPS would include that value.
I guess this is the profile on the IPS Composition -- http://hl7.org/fhir/uv/ips/StructureDefinition/Composition-uv-ips

John Moehrke (Aug 23 2021 at 13:30):

in IHE (XD*) terms, there really should be a profile identifying a FHIR-Document Bundle containing the IPS. This would be more correctly the concept of a document vs just the Composition resource alone. I don't find this Bundle defined with a profile

Peter Jordan (Aug 23 2021 at 23:07):

At this moment, there isn't a Profile on the IPS Bundle in the Current Build, but there was one in the last Connectathon Build and I believe that @Rob Hausam will be merging these for the upcoming HL7 International and GDHP Connectathons.

Rob Hausam (Aug 24 2021 at 02:00):

Yes, @Peter Jordan is correct. I apologize to everyone for all the updates taking so long, but I can be pretty confident that this particular issue will be taken care of by the time of our HL7 IPS call on Wednesday (if not sooner).
@Jens Villadsen @John Moehrke

Jens Villadsen (Aug 24 2021 at 11:32):

In my mind the IPS bundle could be fetched just as easily by invoking a $summary operation on the Patient endpoint. It wouldn't conflict with XD* but mere act as a supplement / shorthand invocation

John Moehrke (Aug 24 2021 at 12:15):

@Jens Villadsen yes. we are working together. The new $summary would also be usable in combination with a cross-community "On-Demand" document entry.

Rob Hausam (Aug 24 2021 at 12:53):

Yes - $summary is the agreed preferred option to use, and to test (as far as possible) in the September Connectathon and beyond.

Jens Villadsen (Aug 24 2021 at 14:31):

Do you have a capability statement / operation definition somewhere that documents it?

Yunwei Wang (Aug 24 2021 at 15:18):

There is a ticket to create an OperationDefinition https://jira.hl7.org/browse/FHIR-32014

Jens Villadsen (Aug 25 2021 at 10:12):

@Yunwei Wang I've added the following as comment on the JIRA ticket:

{
"resourceType": "OperationDefinition",
"id": "summary-operation",
"url": " http://hl7.org/fhir/OperationDefinition/Patient-summary",
"version": "4.0.1",
"name": "Find patient summary",
"status": "draft",
"kind": "operation",
"date": "2021-08-08T08:31:20+00:00",
"publisher": "HL7 (FHIR Project)",
"contact": [
{
"telecom": [
{ "system": "url", "value": "http://hl7.org/fhir" }
,

{ "system": "email", "value": "fhir@lists.hl7.org" }
]
}
],
"code": "summary",
"resource" : ["Patient"],
"system": false,
"type": true,
"instance": true,
"parameter": [
{ "name": "identifier", "use": "in", "min": 0, "max": "1", "type": "Identifier" }
,
{ "name": "profile", "use": "in", "min": 0, "max": "1", "type": "uri" }
,
{ "name": "graph", "use": "in", "min": 0, "max": "1", "type": "uri" }
,

{ "name": "return", "use": "out", "min": 0, "max": "1", "type": "Bundle" }
]
}

Peter Jordan (Aug 25 2021 at 20:26):

@Jens Villadsen @Yunwei Wang - I'll add this , as an implementer defined operation, to my Server at the weekend.

Jens Villadsen (Aug 25 2021 at 22:57):

I'll have one rolling as well within a week that covers Denmark

Rob Hausam (Aug 25 2021 at 22:57):

That's excellent.

Peter Jordan (Aug 25 2021 at 22:58):

It would be great to test some cross-border exchanges from NZ<->Denmark at the upcoming Connectathons. @Matt Rahn

Rob Hausam (Aug 25 2021 at 22:59):

Yes, that's exactly what we are looking for.

Jens Villadsen (Aug 25 2021 at 23:05):

Our IPS currently only covers medication and demographics

Jens Villadsen (Aug 25 2021 at 23:05):

but it can be expanded

Peter Jordan (Aug 25 2021 at 23:06):

Probably needs allergies and conditions (or their recorded absence) to fulfill mandatory requirements. Meds will be interesting - what coding system will you be using @Jens Villadsen ?

Jens Villadsen (Aug 30 2021 at 12:47):

ATC for medication is one of them @Peter Jordan

Peter Jordan (Sep 02 2021 at 04:29):

@Jens Villadsen , @Rob Hausam , @Yunwei Wang - at the Connectathon we'll need to consider what has to be placed in an IPS instance that is POSTed to a Server so that it can be retrieved by another client. Looking at the draft $summary operation, that probably needs to be a patient identifier which currently has a cardinality of 0...n in the IPS Patient Profile. That's not such an issue within any given domain, but cross-border exchanges raise the issue of whether identifiers will be fully understood (e.g. systems) by both parties. Perhaps we need something like a dedicated IPS system or type plus an agreement to use GUID values to guarantee uniqueness? Further thoughts?

Jens Villadsen (Sep 02 2021 at 08:08):

I don't see the need for an IPS system in the identifier as the profile parameter tells explicitly that the request is scoped for IPS - correct?

Jens Villadsen (Sep 02 2021 at 08:09):

when profile is set to http://hl7.org/fhir/uv/ips/StructureDefinition/Bundle-uv-ips that is

Jens Villadsen (Sep 02 2021 at 08:19):

@Ole Hedegaard :point_up:

Peter Jordan (Sep 02 2021 at 08:47):

That would be fine if that's the only patient identifier in the IPS. What if there's more than one, or do you think the cardinality should be 1..1 in the IPS Patient Profile?

Jens Villadsen (Sep 02 2021 at 08:57):

multiple identifers should be allowed on the patient IMHO

Jens Villadsen (Sep 02 2021 at 08:57):

I would say the cardinality should be 1..*

Giorgio Cangioli (Sep 02 2021 at 09:09):

..sorry I'm just looking at this conversation ... I'd expect that a "real" Patient has one or more business identifier associated to its record but there are some points that are not totally clear to me: (1) why it shall be 1.. in the IPS profile (2) why a "dedicated IPS system or type plus an agreement to use GUID values to guarantee uniqueness" is needed

Giorgio Cangioli (Sep 02 2021 at 09:11):

if there is no business identifiers, but I have some identification traits, I assume I can always get the right IPS by calling [base]/Patient/[id]/$summary

Peter Jordan (Sep 02 2021 at 11:55):

A [base]/Patient/[id]/$summary request would also need to include the IPS Profile URL. However, if client A POSTS an IPS Summary to my Server and later Client B requests that summary there is no guarantee that either Client (particularly B) will know the ID of that patient on my Server.

Jens Villadsen (Sep 02 2021 at 11:56):

The thing about POST'ing an IPS is to me out of scope

Jens Villadsen (Sep 02 2021 at 11:57):

I see the IPS summary operation as a facade to an infrastructure that I as a client do not need to know any details of

Peter Jordan (Sep 02 2021 at 11:57):

It's in scope for the Connectathon.

Jens Villadsen (Sep 02 2021 at 11:57):

why?

Jens Villadsen (Sep 02 2021 at 11:58):

How the IPS was constructed seems like a detail that should be unknown to the client

Jens Villadsen (Sep 02 2021 at 12:00):

Whether it is POST'ed to the server ahead of it being retrieved or it is created Ad-Hoc / on-demand is beyond the concern of the summary operation, right?

Giorgio Cangioli (Sep 02 2021 at 12:04):

Peter Jordan said:

A [base]/Patient/[id]/$summary request would also need to include the IPS Profile URL.

Yes but this is implicit in the $summary operation otherwise how do you know which kind of summary you need to return ? (unless the server may configure a default, if not specified it tries to return an IPS...)

However, if client A POSTS an IPS Summary to my Server and later Client B requests that summary there is no guarantee that either Client (particularly B) will know the ID of that patient on my Server.

Yes but the client need to know some identification trait and can use them to have the logical ID back ... even if I recognize that the best option is to try to filter per business identifier

Giorgio Cangioli (Sep 02 2021 at 12:05):

Jens Villadsen said:

Whether it is POST'ed to the server ahead of it being retrieved or it is created Ad-Hoc / on-demand is beyond the concern of the summary operation, right?

My understanding of the $summary operation is that is up to the server to create the summary on-the-fly or return an existing one

Jens Villadsen (Sep 02 2021 at 12:07):

exactly ... meaning that how the server got its hands on the IPS is beyond the scope of the summary operation

Giorgio Cangioli (Sep 02 2021 at 12:07):

the existing one can be posted by someone else or created by the server in advance (e.g. triggered by an user request )

Peter Jordan (Sep 02 2021 at 12:22):

From a server perspective, one has to consider how the IPS instance is to be created , stored (if not created 'on-the-fly') and made available to clients. As I'm not creating them 'on-the'fly', I'm interested in both the POST and $summary request scenarios.

John Moehrke (Sep 02 2021 at 14:42):

I would say both.. but as different portions of the specificaiton. I really want the IPS to be a standalone specification about the document profiling. It should not be weighted down by the $summary operation. The $summary operation is absolutely useful and needed, but not everyone that needs the details in the IPS specification need to be weighed down by the $summary (or the discussion on IPA). These are ALL needed, and fine to test at a FHIR connectathon. But they are modular specifications so as to be useful in different context.

John Moehrke (Sep 02 2021 at 14:48):

I see many IGs that depend upon each other.

• $summary IG depends on the IPS IG because it produces an IPS.
• IPS IG depends on IPA-profiles IG as it orchestrates those profiles into the IPS document
• IPA-transaction IG depends on IPA-profiles IG as it enables RESTful access to the Resources defined with defined query parameters

possibly others will be part of this depends on relationship like a Patient Management IG, Practitioner Management IG, Organization Management IG. There is already the vHDir that we should seriously consider as providing the defining resources for organization and practitioner.

John Moehrke (Sep 02 2021 at 14:48):

making more IGs may be a bit harder up-front; but not all that much harder; and the results will be reusable blocks

Jens Villadsen (Sep 02 2021 at 14:58):

@John Moehrke you suggest that an IG is authored that 'merely' contains the capability statement and the summary operation and that it declares dependence to the IPS IG? Is that you idea?

John Moehrke (Sep 02 2021 at 14:58):

essentially, yes.

John Moehrke (Sep 02 2021 at 14:59):

I don't think that is a 'small' thing. but yes it is rather focused.

Jens Villadsen (Sep 02 2021 at 14:59):

its certainly doable

Jens Villadsen (Sep 02 2021 at 14:59):

i consider it a 'small' thing

John Moehrke (Sep 02 2021 at 15:00):

yes it is possible... did it for Patient management in IHE.

Jens Villadsen (Sep 02 2021 at 15:01):

it does have the advantage of a small scope

Giorgio Cangioli (Sep 02 2021 at 15:01):

IMHO the $summary operation is not IPS specific so it should be at the same level of the $everything or $document operation... that is or in the core specs or all of them in a separate IG

Jens Villadsen (Sep 02 2021 at 15:01):

which makes it easier to agree upon

Jens Villadsen (Sep 02 2021 at 15:02):

@Giorgio Cangioli in that case, it would be a profiled use of the summary operation

Jens Villadsen (Sep 02 2021 at 15:04):

I guess the bottomline is that it is not of importance where the summary operation is located in terms of IG's/core - the importance is in its stated use - and if it suits everybody better if it is stated i a separate IG - why dont we just do that?

Rob Hausam (Sep 02 2021 at 15:14):

Maybe we need to first do some exploration with using the $summary operation, at least in the Connectathon, and that may help us with deciding where the operation should "live" - in the IPS IG, a separate but related IG, or as a more general (not exclusively IPS) operation on the Patient resource documented in the FHIR core specification?

Jens Villadsen (Sep 02 2021 at 15:40):

If the idea of the connectathon is to assert interfaces and interactions between systems I cannot see how the result of the connectathon changes anything in this sort of decision - but I may be wrong.

John Moehrke (Sep 02 2021 at 17:31):

yes, short term we do what we can.. ultimately it would be great if it eneded up in core. But not all operations need to be in core.

Peter Jordan (Sep 03 2021 at 07:49):

$summary operation provisionally defined at https://terminz.azurewebsites.net/fhir/OperationDefinition/Patient-summary

Jens Villadsen (Sep 03 2021 at 17:37):

I'll have a test server implementing the $summary operation ready next week on https://gravitate-dk-ips.trifork.dev/fhir/Patient/$summary

Rob Hausam (Sep 03 2021 at 18:41):

I'm hoping to have one available for the Connectathon, too. Having two, or more, will be great.

David Hay (Sep 04 2021 at 19:45):

@Jens Villadsen you'll ping us here when ready? I'd like to test with the clinFHIR Bundle Visualizer...

Jens Villadsen (Sep 09 2021 at 20:08):

@David Hay -ready!

Jens Villadsen (Sep 09 2021 at 20:09):

sry ... had a to go for a 2 day conference abroad and forgot all about time and place

Jens Villadsen (Sep 09 2021 at 20:11):

invoking the operation with the following:

<Parameters xmlns="http://hl7.org/fhir">
    <parameter>
        <name value="identifier" />
        <valueIdentifier>
            <system value="urn:oid:1.2.3.4" />
            <value value="1206450168" />
        </valueIdentifier>
    </parameter>
    <parameter>
        <name value="profile" />
        <valueUri value="http://hl7.org/fhir/uv/ips/StructureDefinition/Bundle-uv-ips" />
    </parameter>
</Parameters>

• will return you with an IPS example from the Gravitate IG

Jens Villadsen (Sep 09 2021 at 20:12):

The use of the profile parameter is in our case mandatory as it says 'what' kind of summary you as a client would like

Jens Villadsen (Sep 09 2021 at 20:13):

:point_up: (FYI - @Craig Anderson )

Jens Villadsen (Sep 09 2021 at 20:19):

Changing the system of the identifier to urn:oid:1.2.208.176.1.2enables you to have a look into a danish test infrastructure

Peter Jordan (Sep 09 2021 at 21:46):

An example of invoking the operation with a GET request...
https://terminz.azurewebsites.net/fhir/Patient/$summary?profile=http://hl7.org/fhir/uv/ips/StructureDefinition/Bundle-uv-ips&identifier=https://standards.digital.health.nz/ns/nhi-id|AAA1234

Jens Villadsen (Sep 10 2021 at 13:26):

In a danish setting we probably cannot allow GET as HTTP method as the URL would show the patient's social security number, and that is something that you would not like to have stored in proxies

John Moehrke (Sep 10 2021 at 13:49):

I really hate this fallacy. GET is no worse at exposing than POST is.

Jens Villadsen (Sep 12 2021 at 07:10):

It is worse - as it is usually handed differently

Jens Villadsen (Sep 12 2021 at 12:28):

Ofc. you could cache as eBay - but I tend to not see POSTs being cached: https://tech.ebayinc.com/engineering/caching-http-post-requests-and-responses/

Craig Anderson (Sep 13 2021 at 14:44):

Hey, @Jens Villadsen , @Rik Smithies

I believe each language should be a separate document. However, we will add that to our list of questions to EMA for confirmation.

Jens Villadsen (Sep 13 2021 at 20:07):

@David Hay can't see that the server address is registered in conman

David Hay (Sep 13 2021 at 20:14):

Which server is that?

Jens Villadsen (Sep 13 2021 at 21:42):

https://gravitate-dk-ips.trifork.dev/fhir

Jens Villadsen (Sep 14 2021 at 06:55):

nevermind ... I added it myself

Jens Villadsen (Sep 14 2021 at 07:00):

@David Hay - feature request: State the FHIR version of the IG on the Implementation Guide tab

Jens Villadsen (Sep 14 2021 at 07:00):

in Conman

David Hay (Sep 14 2021 at 07:18):

Hi Jens - as a user entered field? good idea...

David Hay (Sep 14 2021 at 07:20):

Also need a way to search the servers, there's a few of them there these days....

Jens Villadsen (Sep 17 2021 at 20:17):

yep - btw - my IG happens to be FHIR v4.1.0 ;)

Jens Villadsen (Sep 17 2021 at 20:17):

David Hay said:

Hi Jens - as a user entered field? good idea...

the FHIR version is stated in the IG so you can actually compute it automatically

Jens Villadsen (Sep 17 2021 at 20:20):

so @Rob Hausam / @Peter Jordan / anyone - where did we end on the $summary operation? should we put it in its own IG. - thereby isolating it and use it as an "optional" IG - or should we forget everything about it?

Peter Jordan (Sep 17 2021 at 20:24):

Why wouldn't it be placed in the IPS IG itself, at least for R4; unless the IPA IG would be more suitable? For R5, I'd hope that it will be in the spec.

Elliot Silver (Sep 17 2021 at 20:29):

Because putting it in the IG imposes a behavior on any system claiming to implement IPS, and many systems may want to produce IPS documents without supporting the $summary operation.

Elliot Silver (Sep 17 2021 at 20:30):

(That's actually an exaggeration. There are ways to put it in the IG without requiring behavior in all systems, but that approach is less common.)

Rob Hausam (Sep 17 2021 at 21:18):

Hi, @Jens Villadsen. I think we still need to do some thinking about where and how in the IPS IG we want to document the $summary operation. But I think we should include this in the IG, and I am still intending to accept your pull request.

Rob Hausam (Sep 18 2021 at 02:07):

I think @Elliot Silver has made a good point that we need to consider, though (which fits with the thinking that I mentioned).

Last updated: Apr 12 2022 at 19:14 UTC