Stream: argonaut
Topic: Block vote
Lloyd McKenzie (Oct 15 2020 at 01:03):
Can #FHIR28179 be pulled from the block vote please?
Lloyd McKenzie (Oct 15 2020 at 02:38):
(@Eric Haas @Brett Marquard )
John Moehrke (Oct 15 2020 at 11:59):
what block vote?
Brett Marquard (Oct 15 2020 at 14:26):
Ha, hasn't posted yet, just organizing trackers. Lloyd noticed us categorizing trackers for a future block.
Brett Marquard (Oct 15 2020 at 14:27):
The plan is to post the first US Core block vote later today, and then likely ever Thursday for the next few weeks as discussed on the Cross Group Projects WG call.
Brett Marquard (Oct 15 2020 at 14:29):
@Lloyd McKenzie Did you pursue #FHIR28179 in base FHIR?
Lloyd McKenzie (Oct 15 2020 at 15:38):
The base standard is a little different. In theory, there could be a use-case where you'd want to capture who was involved in manipulating a record (or even just when it was manipulated) and not what the actual change was. (An uncommon need, but not outside the realm of possibility.) US Core, on the other hand, is definitely not dealing with that use-case. Even if you were to allow for it, the activity presumably should be at least mustSupport.
Drew Torres (Oct 15 2020 at 15:53):
I don't agree with that sentiment. If it were to be mustSupport it would end up being constrained to 1 value. The reason the profile was created was to meet us-regulation which was to comply with a requirement that we share the "last-hop" of provenance which was the organization that the information came from. There is no requirement to record what type of activity was done. There is a desire to keep this somewhat simple. The profile was designed to be simple enough to avoid these types of contentious issues. I don't think activity is needed to meet the objective what was laid out in front of us.
That field also doesn't match to the type of activity that EHRs currently capture (If at all). This would impose a great burden for our implementation to support.
Lloyd McKenzie (Oct 15 2020 at 15:54):
So you're saying that the Argonaut use-case is simply to capture who was involved in the last manipulation of this resource - regardless of what that manipulation was? (creation, revision, translation, anonymization, whatever)
Lloyd McKenzie (Oct 15 2020 at 15:55):
If that's true, it would be good if the profile description made that intended use a bit more clear.
John Moehrke (Oct 15 2020 at 15:58):
I would not like to see the current definition of must support applied to .activity... but I do think that a more soft "must populate if the activity is known" is appropriate.
Lloyd McKenzie (Oct 15 2020 at 16:05):
I did submit a change request - FHIR#19410. Unfortunately, you didn't do everything I said. The only codes in the current value set that are appropriate are the ones from ActCode and DataOperation. You shouldn't have anything from object-lifecycle-events, event-status, v3-DocumentCompletion or v3-ActStatus.
Lloyd McKenzie (Oct 15 2020 at 16:05):
(You didn't actually do much of what I said - you only linked the participation codes)
Drew Torres (Oct 15 2020 at 17:49):
That was the intent @Lloyd McKenzie
Yunwei Wang (Oct 20 2020 at 19:40):
I have a question for resolution of FHIR-27727, 27728, 27729, and 27730. Does this effectively create two sets of "must support", ie: USCDI "must support", and US Core "must support"?
Eric Haas (Oct 20 2020 at 20:09):
We are discussing exactly how to document using a single profile to meet both USCDI cert and other use cases.
Brett Marquard (Oct 21 2020 at 14:41):
We have fine line to walk -- if going forward we mark everything in USCDI as 'must support' in US Core we limit reuse. For example, 'birth sex' isn't used in other use cases so developers create their own IG.
Lloyd McKenzie (Oct 21 2020 at 15:40):
Is there a reason to not create two profiles - a USCDI constraint on a base?
Brett Marquard (Oct 21 2020 at 15:56):
It's unclear to me the ongoing benefit to maintaining two vs the cost -- many changes to one will ripple to the other, and future IGs will likley default to US Base when in many cases they will be capable of using US Core.
Brett Marquard (Oct 21 2020 at 15:57):
Our current path is to collect 'variance' requests on US core, if we get a large number, we will entertain a base.
Yunwei Wang (Oct 21 2020 at 17:00):
So is this, moving USCDI requirements from structured definition to notes, a temporary solution (or trial solution) till US Core has finial decision on dealing with difference between USCDI and US Realm IGs?
Brett Marquard (Oct 21 2020 at 17:04):
We haven't finalized the approach -- we will likely propose a few options on a CGP call
Yunwei Wang (Oct 21 2020 at 17:24):
Is the block vote still tomorrow?
Yunwei Wang (Oct 21 2020 at 17:28):
@Brett Marquard Then I don't understand why these four tickets are in the block vote since US Core or CGP has not decided what to do.
Brett Marquard (Oct 21 2020 at 17:29):
The block vote is to no longer mark those as must support
Brett Marquard (Oct 21 2020 at 17:30):
exactly how we communicate the USCDI piece is TBD. if you want those both addressed at same time, pull the comments.
Last updated: Apr 12 2022 at 19:14 UTC
