Stream: IPS
Topic: National PS Implementations
Sheridan Cook (Nov 16 2021 at 14:30):
Hey all - thought it would be helpful to have a space for those of us who are developing national/jurisdictional/canton based implementations of IPS and may be hitting similar technical & business challenges. Here in Canada, we're developing a PS-CA specification & FHIR IGuide - but are finding that we need to build a bridge/roadmap of versions to help some of our systems progress towards meeting the full set of MS expectations for the international gold standard (i.e., IPS). I'll share some of the challenges we've been facing below in hopes of connecting with others who may be facing/have faced the same problems.
@Peter Jordan I've heard things are moving in New Zealand and have checked out the NZIPS Simplifier Project. @Morten Ernebjerg We've re-used some of the language in Smart4Health guide about aligning to IPS where possible but not fully deriving with all the profiles. Have either of you you run into any places where you've had to relax the IPS constraints due to current system capabilities?
@Giorgio Cangioli - in prior posts you've pointed out previously that there a numerous EU and Nordic implementations, as well as work in the semi-automated PS creation in Portugal - I know a lot of the work has been in CDA, but are there others we should be connecting with here?
Morten Ernebjerg (Nov 16 2021 at 15:17):
Hi @Sheridan Cook I should start by saying that we are working with a green-field and cross-national research project so unlike most "official" national project, we did not have hard constraints imposed by existing national standard. We started with IPS as our foundation and accordingly we found very few conflicts with with it. Also, we use IPS as basis for individual profiles but neither create nor ingest full IPS Bundles at this time.
The one main case where we did have to relax IPS is related to some rather special technical constraints we have because our backend system is end-to-end encrypted. That is, it only holds and serves encrypted data, so we do not have a standard FHIR REST API. Because of this and other related factors, we use logical references (based on business identifiers) for references between resources, rather than the typical "REST-style" literal references. For many resources (e.g. MediationStatement or Condition), however, the IPS profiles require that the reference to the patient be literal (e.g. that Condition.subject.reference be filled). Since we could no fulfil that, we had to relax that constraint ,meaning that most of our profiles cannot be not re-profiling of the IPS counterparts & hence do no ensure IPS conformance.
One other case where we had to relax a constraint was for Observation.status. In IPS, it is fixed to "final", in line with the typical "full IPS document" use case. However, we wanted to allow exchange and update of individual resources, so we had to relax this constraint as well to allow other statuses.
That being said, I can absolutely see how tension between IPS and existing national standards could also arise here in Germany. For instance, in Germany there is an existing, defined set of basic medical data for emergency treatment (Notfalldatensatz) which was recently mapped to FHIR in the so-called Patientenkurzakte (PKA) IG (profiles are here, text in German only). There, allergies are always given by the substance causing the allergy and the reaction, which in FHIR was mapped to AllergyIntolerance.reaction.substance and AllergyIntolerance.reaction.manifestation, respectively (see this profile). Conversely, AllergyIntolerance.code - which is required by IPS - was not used - in fact, it was profiled out since this particular standard, for specific reasons, choose very "closed" profiling. That clearly makes it very hard to map to and from IPS since it requires you to map between a single code for IPS and a (substance, manifestation)-pair for PKA.
Rob Hausam (Nov 16 2021 at 17:14):
@Morten Ernebjerg This is very interesting, and it's great to hear these details of the issues that you've found, as well as the progress that you've made. I'm wondering if we have (inadvertently) in those IPS FHIR profiles constrained the element too far (e.g. requiring the .reference). I think that's something that we should look at, and I can add it as an agenda item for our call tomorrow (also a heads up, be looking for a post about the call time for tomorrow that I should be sending shortly).
And for the Observation.status, unless I'm thinking incorrectly or incompletely (which is certainly possible), I'm thinking that our open slicing approach should be able to handle this for you - without you actually having to relax or otherwise alter any actual constraints. With the open slicing you should be able to send an Observation resource instance with a non-final status in the results or other sections of the IPS bundle, and it should still be conformant with the STU 1 (and CI build) profiles. If that's not the case, then we should look at that, too.
Peter Jordan (Nov 16 2021 at 19:36):
In New Zealand we have two distinct, but related, projects relating to the IPS. The first one is looking at cross-border use cases and involves participation in the GDHP Interoperability Stream's work; the second is NZIPS which will derive from the core IPS for use within NZ ('building block' approach). The latter will undoubtedly add resources (e.g. encounter) and use different and additional terminology bindings. However, one thing, I am keen to avoid is constraining out elements in clinical resources - particularly if any of the NZIPS Profiles are to be candidates for National Profiles in our Base NZ IG.
John D'Amore (Nov 16 2021 at 21:23):
@Morten Ernebjerg @Sheridan Cook
The approach to including other resources as Rob suggested is possible but will try to take a look at the Observation.status and other items for discussion on tomorrow's IPS call (11/17 11am ET).
Morten Ernebjerg (Nov 17 2021 at 07:21):
@Rob Hausam I take it you mean the open slicing approach at the level of the Composition, allowing for the inclusion of Observation that do not match the IPS profiles in an IPS document? At the level of the Observation profiles, the element status is constrained to have the fixed code "final". The problem we had is that we were always using the profiles as "standalones" and never package resource into (or out of) a full IPS FHIR document (IPS-as-toolbox). Our goal was to reuse as much as possible of individual IPS profiles and ideally make our profiles re-profiling thereof, thereby automatically ensure compatibility with standard IPS. And if I read it right, that is not possible in this case if want to allow other status values.
(BTW, sorry for always chickening out of the IPS calls, unfortunately fits my schedule & timezone very poorly... ).
Rob Hausam (Nov 17 2021 at 11:41):
@Morten Ernebjerg Thanks for the clarification - and that makes sense. I think we should discuss this, and I will bring it up on the call(s) today. The main HL7 IPS (technical) call today will be at the usual 11:00 AM ET time, but I will also open the meeting at 9:00 AM ET, and 9:00 AM will be the call time next week, and likely going forward. I don't know if that helps with your schedule?
Morten Ernebjerg (Nov 17 2021 at 12:59):
@Rob Hausam Sorry about the angry-looking smiley (now gone) in my previous msg., that looked much more friendly on my screen! - was meant to indicate a light embarrassment on my part, not displeasure with the scheduling. Maybe I can make it next week, I think the biggest hurdle is the pile of other work :smile:
Rob Hausam (Nov 17 2021 at 13:02):
Sure - totally understand!
Sheridan Cook (Nov 17 2021 at 13:09):
@Morten Ernebjerg we haven't quite gotten to Observation yet but I anticipate that we may share in the challenge with fixed code set to final, given what we're seeing in terms of our implementers wanting to leverage their development efforts for IPS to also support sibling use cases.
Our biggest challenge here in Canada is that we're a mix of green-fields and jurisdictions that want to leverage their existing FHIR/HIT assets that don't quite meet all the system expectations of the IPS. So to drive faster testing and adoption we're looking at ways that we can allow for systems who can do 60% of the MS expectations to still produce summaries that are compliant to IPS.
We're currently seeking feedback on an approach for adding an additional profile in the composition.section.entryMedications that would model how implementers would claim they don't currently support the profile for the medications section. It reuses the NoMedicationInfo pattern in the current profile, but adds an additional coding as well and removes many of the MS constraints from the profile that are counterintuitive to someone claiming they don't support the PS MedicationStatement profile. It's clunky and early stages- but we need a way to differentiate between a system that doesn't know medication info and a system that hasn't finished the development to provide medication info in FHIR yet...while still ensuring the output doesn't break any IPS rules.
structuredefinition-profile-medicationstatement-notsupported-ca-ps.json
@Rob Hausam I'll be on today's 9am, though it's still a bit early for Elliot so I'll fill him in.
Giorgio Cangioli (Nov 19 2021 at 07:59):
Most of the constraints you mentioned reflects the usage of these profiles for building a PS document rather than using them as baseline for other scopes/profiles. The question is how much we should relax them to allow a wider usage ...
Giorgio Cangioli (Nov 19 2021 at 08:04):
For example, independently by the fact they are conveyed as part of a document or retrieved as distinct resources, should a summary include non final results ?
Sheridan Cook (Dec 14 2021 at 23:01):
@John D'Amore @Rob Hausam As requested in the December 8th IPS Call - In lieu of being outside of a balloting cycle for IPS we wanted to surface a number of areas where we've had to relax IPS-UV constraints as part of the current version of the pan-Canadian Patient Summary (which is intended to be used for exchange within jurisdictions, across Canada, and globally).
The list in the attachment below should be considered a reflection of our national spec at a specific point in time (PS-CA v0.0.3) and meant to reflect the current capabilities of the majority of systems participating in our initial release- we'll continue to update the IPS team as any constraints are re-added through later releases.
We're not sure how many of the areas we've had to relax will be felt by other national implementations - but wanted to start the conversation here - especially if it informs the efforts to determine IPS's approach moving forward towards established patterns for national implementations that are developing patient summaries for various use cases beyond global exchange.
IPS-UV-PS-CA-v0.0.3-Differences.docx
Rob Hausam (Dec 14 2021 at 23:10):
Thanks so much for this, @Sheridan Cook! I'll plan to look through it this evening and I think we can plan to have some further discussion on the call tomorrow.
John D'Amore (Dec 22 2021 at 13:45):
I've performed some additional analysis on the Must Support statements as they currently exist in the IPS based on some of the work from Canada (thanks @Sheridan Cook) , other national profiles and feedback from connectathons/meetings. I have a presentation which I'll aim to share this morning here: https://docs.google.com/presentation/d/1hopNZWY57AUB7qlpmSinrCiTHtmtkELgZJVjL5-jE_g/edit#slide=id.p
Please note that this is for discussion (especially last slide), so not a final proposal yet. Look forward to discussing this morning shortly (at 9am ET)
Peter Jordan (Dec 22 2021 at 20:45):
@John D'Amore FYI, New Zealand has only copied the core/cross-border version of IPS as a first step in it's internal usage/derivation. If 'Must-Support' cannot be removed in derived IGs and Profiles then practical considerations will dilute its meaning. Cardinality constraints are the key for implementers and it appears superfluous for 'must support' flags to be placed against elements with a cardinality of 1..1 or 1..*. If they could be removed, along with the other recommendations, it would add significant value to the IPS IG.
John D'Amore (Dec 22 2021 at 21:12):
Thanks for that perspective @Peter Jordan We did seem to reach a consensus to evaluate substantial reduction in Must Support in the base IPS profiles today (there are over 400 today!). Based on today's discussion, I will lead a proposed revision, and will share more here (hopefully in next couple weeks).
Rob Hausam (Dec 22 2021 at 21:41):
Yes, thanks, @Peter Jordan One thing we discussed today is that some of the most likely excessive use of mustSupport is baggage that was accumulated and has been carried forward from dealing with the warnings from previous versions of the IG Publisher which were generated for any element in the differential which did not have mustSupport declared. That obviously led to a proliferation. We need to go back now with the results from our current analysis to determine what reasonably should be mustSupport (and what doesn't need to be) and re-align all of it from there.
John Moehrke (Jan 29 2022 at 15:09):
derived profiles of IPS are likely to be more specific... thus presenting the problem Peter points out. This is the case in IHE today with a few more specific use-cases that start with IPS as the base.
Last updated: Apr 12 2022 at 19:14 UTC
