Stream: argonaut
Topic: IPS Comparison
Grahame Grieve (Feb 28 2019 at 21:49):
@Michele Mottini has done a comparison of IPS (International Patient Summary) and Argonaut for us (with generous support from ONC, thanks!). Here's a draft report for people to look at
Grahame Grieve (Feb 28 2019 at 21:49):
What I'm looking for is whether it's possible, as a server or a client, to support both IPS and argonaut at the same time. And it's not possible right now.
Grahame Grieve (Feb 28 2019 at 21:50):
IPS-Argonaut.docx IPS-Argonaut.xlsx
Grahame Grieve (Feb 28 2019 at 22:05):
Several issues leap out at me after looking at the review (@Rob Hausam ):
- Should IPS document how to get/send an IPS summary? (I say: yes, it should define how to get it from a RESTful end-point, and how it would be sent somehow)
- Should Argonaut document rules/best practices/observed practices around negation (e.g. 'no known allergies). And I'd hope for some consistency here, but we can't yet comment further about that?
- Why does IPS prohibit expressing a medication as a codeable concept, when this is the very must common situation?
- IPS should align with the guidance on multi-language narratives in the future
- "IPS defines an extension specifying the preferred practitioner or organization to be contacted for a patient" - isn't that part of care team? Why would IPS not use care team here?
- IPS has an extension for 'statement - why doesn't this use Annotation in the extension? In fact, since both resources can have annotation, why define the extension at all?
- I'm not familiar enough with the way device is used in Argonaut to know whether there's a problem
- Why does IPS not include MedicationRequest as well? Presumably that is based on requirements, but really?
- why does IPS ise Observation for lab reports, not DiagnosticReport?
- what plans are there for harmonizing IPS clinical notes with the clinical notes discussion?
- Why does IPS use an observation for an attachment, not a document reference?
(the last 3 seem like the big issues to me)
Grahame Grieve (Feb 28 2019 at 22:06):
note: these are mostly issues for IPS, not argonaut, I think, but I think IPS is going to matter to all of us - I'm already hearing about countries trailing it. (Was at the Global Digital Health Partnership meeting this week).
John Moehrke (Feb 28 2019 at 22:30):
The first one is DocumentReference and/or $docref... right?
Rob Hausam (Feb 28 2019 at 23:07):
I just finished taking my first look through the report. Thanks, @Michele Mottini for doing this (and ONC and @Grahame Grieve for supporting it). Basically, I would say that I agree with your list, Grahame. For some of the differences I think there are simple explanations and possibly good reasons for them. For some others, the differences probably arose due to the timing and coming at it from different places. And at least many terminology differences will be expected based on a US vs. international specification. One thing in the review that I didn't see Grahame note is the difference between the document based structure of IPS and the querying of individual profiled resources in Argonaut. In IPS we are already working to move in the direction of enabling and encouraging the use of the individual profiles (either in the soon to be published initial version or the next version) to cover a broader set of use cases.
With that said, I think I would agree that Grahame's last three bullets are probably the most significant ones to look at (and hopefully harmonize) further. My quick take on those is:
- I think the reason IPS landed on Observation rather than DR is that we moved from CDA which uses observations and that was a natural correspondence - but I don't think that necessarily constitutes a valid reason for IPS to perpetuate this difference, so we should further consider this.
- The clinical notes discussion was re-energized and has gotten recent attention mostly after we had already established the pattern in IPS and the work in both streams occurred in parallel, so we haven't really looked at this difference until now (and I don't recall getting any ballot comments in regard to it specifically). It seems to me like we should be able to come together here.
- I think the use of observation vs. document reference is related to the clinical notes issue above, and just hasn't really been considered so far.
It seems to me that there's probably some alignment work to be considered on both sides, but certainly the weight of existing implementations on the Argonaut side is a very significant consideration. But however we need to do it, I think we should try to align both specs to the extent that is possible.
Eric Haas (Feb 28 2019 at 23:28):
thanks for that background @Rob Hausam that probably explains the why.
Grahame Grieve (Mar 01 2019 at 00:50):
Obviously there'll be terminology differences. it's possible to handle those as server and client (good!). It's the incompatibilities that hurt. @Rob Hausam you're comments didn't discuss the DiagnosticReport issue?
What might the timeline on convergence be?
Rob Hausam (Mar 01 2019 at 01:07):
That was my first bullet under "quick take", where I said "I think the reason IPS landed on Observation rather than DR ..." There's obviously more to say, though. We should discuss what the timeline for convergence should and could be and how to go about it. I can't see a way to do something like that without going to ballot, and we didn't submit a NIB for May (although we gave some consideration to the possibility). So we could plan for that for September, which is pretty much what we were thinking pending the outcome of the evaluation and with the likelihood that there would be some needed changes. I assume there aren't any other likely options, but I am happy to consider any possibilities.
Eric Haas (Mar 01 2019 at 05:28):
Obviously there'll be terminology differences. it's possible to handle those as server and client (good!).
What does this mean? if binding IPS is incompatible with binding Argo I don't see how this possible ?
Lloyd McKenzie (Mar 01 2019 at 05:29):
In principle, you can send translations for both
Giorgio Cangioli (Mar 01 2019 at 14:09):
Thanks all for this useful comparison, I really hope that some follow up on this topic may happen in Montreal.
Robert already described the context of the IPS and how from the initial idea of a document for (cross-border) unscheduled care, the IPS has been changed to a common set of core data to be used more widely (this is what has been also exercised in the European Project called Trillium II)
On top of this I'd like to add that:
(a) the Patient Summary is in any case not a full EHR, but an EHR extract;
(b) that the IPS is also a cross-SDOs initiative: e.g. the high level reference data set has been defined by the CEN/TC 251 EN 17269 standard (that will be discussed in Goteborg in April to be likely moved also in ISO). I hope that sooner or later we could have a computable format of this data set as FHIR logical Model (for who may be interested in you can download a first proof of concept from the IPS gitHub - "fhir-logical-models"
branch )
(c) the ecosystem of IPS standards is for sure currently uncomplete (previous chats highlighted some of the missing parts). But when we discussed the first IPS PSS we decided not to try to realize everything in one shot... :-)
Giorgio Cangioli (Mar 01 2019 at 14:11):
Concernig the Grahame's points:
(1) Should IPS document how to get/send an IPS summary? (I say: yes, it should define how to get it from a RESTful end-point, and how it would be sent somehow)
Yes but this is strictly related to the scenarios of creation/curation and use. The IPS coule be a document or a collection of distributed data . The IPS "document" could be an index of selected data, with the IPS instance created on the fly by a regional/national system or it shall be a persistent and signable bundle. (I can give you real jusrisdictional examples of all of these cases.. ). So different options should be considered for each of these cases.
Giorgio Cangioli (Mar 01 2019 at 14:11):
(2) Why does IPS prohibit expressing a medication as a codeable concept, when this is the very must common situation?
Because in absence - for the time being - of globally recognizable identifiers for medicinal products the only way to be global is to provide a set of identification/description attributes not just a code
Giorgio Cangioli (Mar 01 2019 at 14:12):
(3) IPS should align with the guidance on multi-language narratives in the future
Could you please better explain this point ? we change in the last ballot the way to express translated narratives based on the guidance on multi-language narratives. What are you referring to ?
Giorgio Cangioli (Mar 01 2019 at 14:12):
(4) "IPS defines an extension specifying the preferred practitioner or organization to be contacted for a patient" - isn't that part of care team? Why would IPS not use care team here?
It reflects the CDA participation for representing the patient's contacts in case of emergency.
The EN 17269 IPS dataset includes however much more details about possible healthcare professionals beyond those to be contacted in case of emergency.
Let's discuss this point.
Giorgio Cangioli (Mar 01 2019 at 14:14):
(5) IPS has an extension for 'statement - why doesn't this use Annotation in the extension? In fact, since both resources can have annotation, why define the extension at all?
The scope of the statement extension was that of playing a similar role of the asserter for AllergyIntolerance . If I well understood the note (Annotation) in the immunization (or procedure) allows to record who and when additional notes was added not who is the source of the "main" information (we need something equivalent to the entry level CDA author).
But let's see in detail if and when this extension is really needed .... maybe it could be removed in future version (in any case is optional)
Giorgio Cangioli (Mar 01 2019 at 14:16):
(6) Why does IPS not include MedicationRequest as well? Presumably that is based on requirements, but really?
The idea for the IPS was that of providing information about medications taken or to be taken not that of supporting the administration/dispensation workflow. And I believe this is what the medicaitnStatement was conceived for.
However moving from a "pure" IPS document to a set of reusable core data blocks we should consider to make wider what the IPS could offer.
This is a limitation we experienced in trillium II when we tried to reuse the IPS blocks to build the mobile field hospial discharge report for disaster management. ...
Giorgio Cangioli (Mar 01 2019 at 14:22):
(7) why does IPS ise Observation for lab reports, not DiagnosticReport?
The idea for the IPS was that of having an extract of relevant data not (necessarly) the complete report(s); and this is also what was adopted in the IPS CDA implementation.
In principle Provenance data might be used to derive where these extracts were get from
We had some years ago some discussions if references to existing document/reports should be included or not in the IPS and we came up with the decision of keeping things simple. (no references)
Having said however if a Physician deems that a whole report is relevant for the IPS why not to allow this for the future.... (technically this is also possible with the current IG..)
Giorgio Cangioli (Mar 01 2019 at 14:29):
(9) Why does IPS use an observation for an attachment, not a document reference?
not sure to have understood this comment ., please help me on this...
.. If my memory is correct there is a so called "observation media" that is optionally used for the lab/path observations. However this is not an observation resource , but a media resource used for input evidences.
Please @François Macary correct me if I'm wrong.
@Grahame Grieve was this the question ?
Giorgio Cangioli (Mar 01 2019 at 14:32):
(2) Why does IPS prohibit expressing a medication as a codeable concept, when this is the very must common situation?
Because in absence - for the time being - of globally recognizable identifiers for medicinal products the only way to be global is to provide a set of identification/description attributes not just a code
Having said that, however, let's discuss this more in detail....
Grahame Grieve (Mar 01 2019 at 18:58):
@Rob Hausam DR is ambiguous - DIagnosticReport or DocumentReference :-(
@Eric Haas with regard to client & server supporting both, I was mainly thinking of consumption not generation; @Lloyd McKenzie is right that it would be theoretically possible to generate both but in reality, most systems won't have the coding capacity to do so
Grahame Grieve (Mar 01 2019 at 19:06):
@Giorgio Cangioli
(1) - Agree that there are many ways to actually manage the data set. but if you want interoperability, you'll need to describe and limit the common ways
(2) - it seems unlikely to me that this is practical. If a system just has a code - like most of the production systems I've ever seen (specially primary care) - how do they turn this into a rich description? (And if they can, why can't the receipient?)
(3) - IPS defines an extension for multi-language narrative, where as the specification recommends using the W3C lang tag in divs in the narrative
(4) - Does sound like care team to me. I fail to understand why a CDA interpretation of a requirement leads to the requirement being represented wrongly in FHIR
(5) I misunderstood the extension then. I think it's not well documented, at the least. Has PC been asked why it didn't have asserter? And the structure of the extension is... odd for the purpose
(6) I wonder about the appropriateness of that idea; @Eric Haas presumably Argonaut supports both MedStmt and MedReq because that's what source systems have? (or @Jenni Syed or @Danielle Friend ?)
(7) You can use DiagnosticReport to represent a report data without it having the complete report (but I also agree that a summary that can't include the very important documents is a not a useful summary)
(9) I'll have to check
Rob Hausam (Mar 01 2019 at 19:19):
Point taken - I thought using 'DR' was clear in context with Observation, but it would have been better to be explicit.
David Hay (Mar 02 2019 at 07:04):
I'd also like to elevate the 'negation' discussion - ie why not use Composition.section.emptyReason when there is no data for a section (like allergies)
David Hay (Mar 02 2019 at 07:22):
Oh, and seems like a good forum to throw this into the mix: http://www.jointinitiativecouncil.org/registry/Patient_Summary_Standards_JIC_Jan_2018.pdf
Grahame Grieve (Mar 02 2019 at 19:49):
why not use Composition.section.emptyReason
Because then the composition solution would be different to the Argonaut solution on the restful interface
David Hay (Mar 02 2019 at 20:16):
So when would emptyReason be used?
Grahame Grieve (Mar 03 2019 at 19:30):
I actually don't know
Rick Geimer (Mar 04 2019 at 05:19):
I seem to remember a discussion in SDWG about whether or not to remove emptyReason from Composition.section, since it is not really used and is only there as a holdover from when we pulled in the properties of List for DSTU2. Not sure if SDWG has followed up on that with anything actionable though. @Sean McIlvenna ?
Grahame Grieve (Mar 04 2019 at 06:58):
well, not having it means that we have to describe for anything that might be a list how to do it's equivalent.
Grahame Grieve (Mar 04 2019 at 06:59):
having it means we have to deal with the fact that it's.. obscure... in a RESTful context.
Grahame Grieve (Mar 04 2019 at 06:59):
I think we should discuss in a joint meeting in Montreal
François Macary (Mar 04 2019 at 08:21):
(9) Why does IPS use an observation for an attachment, not a document reference?
As @Giorgio Cangioli says, IPS laboratory and pathology profiles of Observation use the element "derivedFrom" to reference a Media resource whose content is an image related to the observation. e.g; a microscope picture of cells or an electrophoresis graph. The intent is not to attach a document.
Grahame Grieve (Mar 04 2019 at 08:56):
I'm not sure that I follow all that. I guess I'm happy if OO and II are happy
Eric Haas (Mar 04 2019 at 14:20):
I would not assume OO and II is happy with this. We are wrestling with the media/docref right now. also I don't even know If OO has even looked at IPS formally, but it is easy to loose track with all the igs in the pipeline..
Rick Geimer (Mar 04 2019 at 15:38):
Agreed, good discussion topic for May.
Rob Hausam (Mar 04 2019 at 15:45):
Right. And part of the problem is that DocumentReference doesn't really (or at least doesn't only) mean "document reference".
Rob Hausam (Mar 04 2019 at 16:10):
OO hasn't taken any formal look at IPS so far. Probably a few have looked at it on their own, but I haven't heard too much about that (through ballot or otherwise). It's probably time (past time, really) to do that. I don't think we could get it on the agenda for this week, but probably we could sometime in the next few weeks.
Elliot Silver (Mar 04 2019 at 18:05):
I'm not sure that I follow all that. I guess I'm happy if OO and II are happy
II hasn't been involved in any IPS discussion.
@Brad Genereaux @Diana_Ovelgoenne
Diana_Ovelgoenne (Mar 13 2019 at 09:47):
As Elliot says II hasn't been involved either, despite of the inclusion of "IPSRadiologyResultObservation" on it.
@Giorgio Cangioli @Elliot Silver @Brad Genereaux it would be good if at least once, the radiology part of the IPS is walked through with the II People. Can this be done in May? I do have concerns that Content-wise it is STU-1 according to Art-Decor, however how does this go along with the moving into an ISO story?
I think we shall move this thread to a stream, as IPS shall consider more Topics than just the Argonaut harmonization.
Giorgio Cangioli (Mar 13 2019 at 10:48):
@Diana_Ovelgoenne happy to describe the ratio of the content of the imaging results data set and the choices made for their representation in CDA and FHIR. Let's organize something for Montreal.
Giorgio Cangioli (Mar 13 2019 at 10:51):
Please consider in any case that the intent for the IPS templates/profiles is not that of representing a complete diagnostic imaging report but provide core data relevant for the scope of the IPS
Grahame Grieve (Sep 13 2019 at 21:01):
ping!
Last updated: Apr 12 2022 at 19:14 UTC
