FHIR Chat · Value Set Ownership · workflow

Stream: workflow

Topic: Value Set Ownership


view this post on Zulip Michelle (Moseman) Miller (Mar 15 2018 at 23:06):

@Lloyd McKenzie Do you know why it shows Patient Care as the owner of the following value set?
http://build.fhir.org/valueset-request-status.html

view this post on Zulip Michelle (Moseman) Miller (Mar 15 2018 at 23:08):

The reason why I ask is because Patient Care was assessing whether to replace our CarePlan.status value set with the Request.status value set and there were a number of edits that Patient Care would like made to the definition of the code values. You can see the proposed changes in red in our meeting minutes, http://confluence.hl7.org/display/PC/2018-03-15+Patient+Care+FHIR+Conference+Call. I can log a tracker, but wanted to confirm if it should be owned by PC or Workflow.

view this post on Zulip Lloyd McKenzie (Mar 15 2018 at 23:34):

I'm not sure why it shows owner as Patient Care - it should be FHIR-I. (@Grahame Grieve ?)

I'm happy with inserting the language authorization/plan/proposal everywhere. I'm not happy with removing the term "authorization" because for an order, that's what we're dealing with.

view this post on Zulip Grahame Grieve (Mar 16 2018 at 00:00):

why should it be FHIR-I?

view this post on Zulip Lloyd McKenzie (Mar 16 2018 at 00:05):

FHIR-I owns all of the workflow patterns and request-status is defined in the Request pattern.

view this post on Zulip Grahame Grieve (Mar 16 2018 at 00:19):

so the code that makes the decision about who owns it doesn't have access to where it was defined, only how is using it. I'll have to investigate how it's deciding in this case

view this post on Zulip Eric Haas (Mar 16 2018 at 06:15):

i'm not happy with "plan" being in all the request statusesdefinitions. It is only an issue for CP. i suggested letting define its own status VS and use the definitions they like. having /plan everywhere is awkward looking and confusing for all the request resources. CP is the outlier here and shouldnt have to adhere closely to the pattern.

view this post on Zulip Michelle (Moseman) Miller (Mar 16 2018 at 12:40):

@Eric Haas I don't understand why you think it's only an issue for CarePlan. Many of the other request resources have an intent that can be "plan"

view this post on Zulip Michelle (Moseman) Miller (Mar 16 2018 at 12:48):

I've created GF#15782 for the requested changes to the definitions in the valueset-request-status

view this post on Zulip Lloyd McKenzie (Mar 16 2018 at 14:12):

@Eric Haas "Plan" is one of the Request.intent values and it applies for most if not all request types

view this post on Zulip Lloyd McKenzie (Mar 16 2018 at 14:12):

It certainly should be applying to the requests managed by OO.

view this post on Zulip Eric Haas (Mar 16 2018 at 18:16):

  • The text description would be stylistically ugly bordering on unreadable like a legal contract.
  • With that logic - why stop at plan and not include all the intents in the status descriptions.
  • The concept of plan for CarePlan and the concept of plan in the intent element are not the same thing. In the status description we are talking about the whole resource not just one intent type.
  • We separated intent from status a while back and this is conflating them again.

  • I think is generally unwise to look at the status description out of their context and parse each word.

  • I do think the authorization/request text needs to be rewritten as well. perhaps adding a note to clarify why was added in the first place.

view this post on Zulip Eric Haas (Mar 16 2018 at 18:22):

Why can't CarePlan use a separate value set with the same code system and use the comment extension to customize the definitions..

view this post on Zulip Eric Haas (Mar 16 2018 at 18:23):

  • And I don't think that one outlier should drive a change to a commonly used valueset like this.

view this post on Zulip Lloyd McKenzie (Mar 16 2018 at 18:38):

I'm not really understanding "concept of plan for CarePlan and the concept of plan in the intent elementare not the same thing" - they're exactly the same thing. The status is talking about the whole resource - but the terminology it uses needs to span all possible intents. That's why I prefer to use "Request" as that's intended to span all intents

view this post on Zulip Lloyd McKenzie (Mar 16 2018 at 18:39):

CarePlans can be plans, proposals or orders. So can ServiceRequests

view this post on Zulip Eric Haas (Mar 17 2018 at 01:02):

That's my point. So I'm against the proposal to have 'plan/proposal/orders/request' everywhere we use the term 'request'


Last updated: Apr 12 2022 at 19:14 UTC