Stream: argonaut
Topic: US Core CareTeam MustSupport
Yunwei Wang (Jan 06 2022 at 15:59):
In v4.1.0, the MustSupport section of USCore CareTeam states that
image.png
Does this mean server implementation "Must Support" (US Core Patient) AND (US Core RelatedPerson) AND (US Core Practitioner OR US Core PractitionerRole)?
This AND logic very different than previous versions.
Brett Marquard (Jan 06 2022 at 16:36):
In prior versions, we didn't write out the required logic -- only MS on practitioner.
Brett Marquard (Jan 06 2022 at 16:38):
Let me write differently since when I read your list it implies to me all in 'one instance'
- Systems MUST Support US Core Patient
- Systems MUST Support US Core RelatedPerson
- Systems MUST Support US Core Practitioner OR US Core PractitionerRole. (They are allowed to support both)
Brett Marquard (Jan 06 2022 at 16:39):
...feel free to log a JIRA ticker for us to add bullet 'Systems MUST Support US Core RelatedPerson' since this wasn't clear.
Yunwei Wang (Jan 06 2022 at 16:50):
My concern is that in US Core 3.1.1, a server implementation shall support at least one of (US Core Patient, US Core Practitioner, US Core Organzation). And in US Core 4.0.0, a server implementation shall support US Core Practitioner. So if a server implementation support US Core Practitioner only, it passes testings with US Core 3.1.1/4.0.0 but will fail new testing with US Core 4.1.0. Has that been considered?
Yunwei Wang (Jan 06 2022 at 16:59):
To further clarify the concern. In current Inferno US Core v3.1.1 testing, a server passes this MustSupport test if the server provides at least one CareTeam resource having participant.member populated with Reference( US Core Patient, or US Core Practitioner, or US Core Organization). So if there is a system using only Reference(US Core Practitioner), the system can easily pass current Inferno testing. But such system will fail on US Core v4.1.0 because it cannot demonstrate its support of populating Reference(US Core Patient) nor Reference(US Core RelatedPerson)
Cooper Thompson (Jan 06 2022 at 17:04):
That's interesting. That means that US Core 4.1.0 really couldn't be used as an SVAP version for USCDIv1. Or at least not practically. I'm tryin to think of a good way for US Core to support both USCDIv1 and USCDIv2 at these same time.
Really I think the only way is to blow up MS, and have different tags for USCDIv1 MS and USCDIv2 MS.
Cooper Thompson (Jan 06 2022 at 17:05):
Also, related tracker that I'm submitting: FHIR-34556 to remove MS from RelatedPerson.
Greg Thole (Jan 06 2022 at 17:25):
Cooper Thompson said:
That's interesting. That means that US Core 4.1.0 really couldn't be used as an SVAP version for USCDIv1. Or at least not practically. I'm tryin to think of a good way for US Core to support both USCDIv1 and USCDIv2 at these same time.
Really I think the only way is to blow up MS, and have different tags for USCDIv1 MS and USCDIv2 MS.
@Cooper Thompson isn't that already a reality with the expansion of Profiles in new US Core versions independent of MS considerations? By my thinking, if you only support USCDI V1 data scope you can't fully support US Core 4.1.0. I was always assuming that SVAP would need to "pair" particular USCDI versions with corresponding US Core versions. Although, the different USCDI version tags thing is an interesting idea.
Brett Marquard (Jan 06 2022 at 17:44):
Please, please no USCDIv1 MS and USCDIv2 MS tags :)
Cooper Thompson (Jan 06 2022 at 17:45):
I personally think we need to explode MS. Having one tag that means a bunch of different things in different contexts is really painful.
Brett Marquard (Jan 06 2022 at 17:45):
How about we make this a topic at the Connectathon? This multi-versioning USCDI + SVAP +US Core isn't quite nailed down
Brett Marquard (Jan 06 2022 at 17:47):
In a few cases we have 'special' logic Must Support -- but I believe @Eric Haas and i have been careful/consistent in how we apply...and are very explicit if there is an special logic.
Cooper Thompson (Jan 06 2022 at 17:53):
@Greg Thole The issue is that I was hoping that US Core would advance and still be usable for USCDIv1. In part because US Core 3.1.1 has some issues that have been corrected in US Core 4.0.1. And it is annoying having to ask ONC for a CCG clarification for every thing we find wrong in US Core 3.1.1. It would be nice to have an SVAP to 4.0.1 (and maybe 4.1.0 in the future) that could be used for USCDIv1.
The alternative is that the g10 CCG would basically need to list all the Jiras that get applied to 3.1.1 to fix USCDIv1 stuff.
Brett Marquard (Jan 06 2022 at 17:54):
I want to +1 first paragraph. I am hopeful we won't have to maintain an acceptable JIRA list with ONC/inferno
Greg Thole (Jan 06 2022 at 18:51):
@Cooper Thompson that makes sense and I'm all for it (I think all sides can agree on the complexity of the CCG clarifications reliance). On the flipside, if you want to certify your APIs to a new USCDI version I still think there'll need to be a minimum US Core version attached to that as a dependency (e.g., USCDI V2 and US Core 4.1.0). But that's more of a topic for ONC.
Last updated: Apr 12 2022 at 19:14 UTC
