Stream: implementers
Topic: Breaking build changes
Eric Haas (May 24 2017 at 18:37):
The DataElement resource will be removed from the Continuous Integration Build of FHIR as change for the next version of FHIR. In addition ReferralRequest will be merged with ProcedureRequest ( We have not landed on a name for this yet so will be call ProcedureRequest at least for now ). So plan accordingly...
Rob Hausam (May 24 2017 at 18:45):
Are we planning to go ahead with StructureDefinition.kind for distinguishing "data element" and "logical"? That doesn't seem clear from GF#13094.
Grahame Grieve (May 24 2017 at 18:52):
what would the distinction be?
Eric Haas (May 24 2017 at 18:56):
I think the remaining task for the ticket is to describe the use case in either structuredefinition or dataelement in the narrative. in fact there is some text ( which I just removed) that does discuss this in the context of the DataElement resource that might be reworked into the general distinction.
Eric Haas (May 25 2017 at 16:20):
FYI in the Continuous Integration Build of FHIR for the next version of FHIR - ReferralRequest has been merged with ProcedureRequest. We still have some post merge analysis work to do and have some open questions:
- Besides
categorydo we need to support any additional elements to indicate a transfer of care ? - What should the name of the merged resource be ?
- Do we need to identify and document more clearly which elements might not be appropriate for a referral vs non referral ? ( with exception of .specimen which is clearly for diagnostics, I don't think there are any)
I added my mapping notes in spec for temporary reference.
Richard Townley-O'Neill (May 26 2017 at 00:06):
Nice work.
- Maybe call the resource Service Request. Being responsible for a patient is not really a procedure, but could be a service.
- Though Requester and Performer make a nice pair, "Performer" sounds wrong for the target of a transfer of care, when what is being requested is not performance of an action but acceptance of responsibility. Maybe rename "Performer" to "Provider".
- I think that performerType would be better named performerSpeciality or performerSkill. (Or, better, providerSpeciality or providerSkill.)
- Would anyone use doNotPerform with a transfer of care/referral?
- Is there any value in allowing doNotPerform=false?
- Do you propose "transfer of care" as a value for category?
Eric Haas (May 26 2017 at 01:17):
"Do you propose "transfer of care" as a value for category?" - nothing proposed formally. that was to illustrate what the issue was.
re: doNotPerform I don't know. but the bigger issue was once you got past the introduction there wasn't anything in referral request that differentiated it from ProcedureRequest. The ReferralRequest was for someone else to do something. The whole assuming of responsibility was never explicit.
Richard Townley-O'Neill (May 26 2017 at 02:12):
When we tried to think of a referral as being a request to apply expertise (e.g. a referral from a GP to a medical specialist for evaluation and treatment) and a procedure request as being a request to do a task (e.g. a request by a community worker for lawn mowing) we found the boundary to be unclear, and maybe imaginary.
Does referral include a transfer of care and procedure request not? Not always.
When is care transferred? It seems that whenever a request is made there is an assumption that due care will be taken. It seems strange to consider 'accept responsibility for care' as an extra service that can be requested.
Messy.
Stephen Chu (Jun 08 2017 at 23:28):
Even though ProcedureRequest and ReferralRequest share large percentage of "structural" similarity, to merge the two into one is clinically and semantically very undesirable for a number of reasons: (1) there is no one semantically adequate concept name that is adequate and appropriate to represent the merged concept so that it is clinically meaningful and useful for use to distinguish the different use cases; (2) some of the inline elements for ProcedureRequest and ReferralRequest are semantically different and forcing one common name for both is confusing and unsuable. Examples: (a) adding doNotPerform to ReferralRequest does not make sense, (b) forcing the change of ReferralRequest.serviceRequested to ReferralRequest.code results in confusion due to loss of important semantics, (c) forcing the change of ReferralRequest.specialty to ReferralRequest.performerType is inappropriate as the meanings of both are different, (d) forcing the change of ReferralRequest.recipient to ReferralRequest.performer is also totally inappropriate as the recipient is not always the "performer", the recipient may be a service, e.g. cardiology service .....
Lloyd McKenzie (Jun 09 2017 at 00:46):
@Stephen Chu It doesn't necessarily need to be clinically appropriate so long as implementers can use it in a way that allows it to be used through clinically appropriate interfaces. Realisticaly, there's differences between orders for surgery, for training, for occupational therapy, etc. But those are already all handled by one resource. The real question is "do almost all systems handle requesting procedures by a different interface than they use for referrals". If the answer is no, there's a good case to be made for combining them.
"do not perform" on a referral request would be used to say "do not transfer care to x". E.g. "Do not discharge to longterm care" or something like that. I'm not sure that's in the 80%, but it does seem something that could occasionally happen.
With respect to the name changes, the work group has the right to figure out what names are appropriate on the resource. There is no need to align with the request pattern if a different name makes more sense to the implementer community.
Grahame Grieve (Jun 09 2017 at 00:59):
I think the work group was quite motivated by the problem of telling them apart.
Grahame Grieve (Jun 09 2017 at 01:00):
I think we need to self-examine on the question of when we should collapse resources because there's cases where they aren't differentiated, or because some systems don't differentiate them
Michelle (Moseman) Miller (Jun 09 2017 at 15:28):
Grahame is correct. The biggest issue was getting consensus on the boundaries. Even if systems do differentiate them, do we share a common boundary of when to use ReferralRequest vs ProcedureRequest? Is it based on transfer of care (but you can have referrals for consultation)? Is it based on whether the performer and requester are part of the same org? Stated another way, is the referral used to refer/consult with an external performer or to manage attribution of who is responsible?
Stephen Chu (Jun 14 2017 at 23:47):
@Lloyd McKenzie - the "do not perform" on a referral request does not work. If a transfer of care request (e.g. to a special skilled facility, is sent using the merged resource, but the requester does not want the subject to be transferred/discharged to a "long term care facility", there is no structure in the resource to support that. The request.code value will be "transfer to skilled nursing facility". If the request.doNotPerform" value is set to true, the result will be exactly the opposite of what the requester intended. One can argue that the requester can send a separate request with request.code = "long term care facility" and request.doNotPerform = true. This will be a very cumbersome way to do that with high potential of causing confusions. It also raises the question of - how to link the two request together? Forcing a simplified technical solution without good clinical justification and utility is a thoroughly bad approach.
Lloyd McKenzie (Jun 15 2017 at 01:46):
@Stephen Chu How else would you expect to computably express "do not discharge to longterm care"? (And for implementers - how would your implementations typically capture this?) Linking multiple requests can be done a few different ways - as components of the same CarePlan, multiple requests with the same groupId or multiple components of a RequestGroup.
Stephen Chu (Jun 15 2017 at 02:24):
@Lloyd McKenzie - for the question on "how else would you expect to computationally express 'do not discharge to long term care'?" - this can be done by including an inline doNotPerform backbone element or a doNotPerform codeable element. It is a better design principle to avoid bundling different resources together for simple information requirements. Even if this issue is addressed, the design principle that any changes or designs do not need to be clinically appropriate is hugely problematic. The several other semantic incongruence issues created by the forced merging are not that easily resolved. The problems should be discussed in detail at the PC-FHIR conference call before a final decision to merge should be made.
Lloyd McKenzie (Jun 15 2017 at 13:42):
@Stephen Chu I don't know what you mean by "an inline doNotPerform backbone element or a doNotPerform codeable element". What resource would be used to make the statement? What approach would you take other than "code = refer to longterm care; doNotPerform = true"?
The data presented to clinicians should always be clinically appropriate, but won't always be - in part because "clinically appropriate" is a context-dependent determination, and in part because real-world systems - and real-world users - don't always capture data in ways that must be ideal. The way data is shared needs to support clinically-appropriate display, but won't necessarily organize data for exchange in the same way that clinicians might want it organized for capture or presentation. The focus of an interface standard is what will work for the software solutions that need to do the exchange. Enabling clinically appropriate capture/display is one of the considerations of such implementations, but it's not the only one and must remain in balance with other requirements such as implementability, reuseability, maintainability, support for legacy, etc. Thus the creation of solutions that mix data that would rarely be clinically appropriate to capture/display together (e.g. pulse rate, antibiotic suceptibility, hemogolobin and smoking status) in a single resource (e.g. Observation)
Michelle (Moseman) Miller (Jun 15 2017 at 13:59):
@Stephen Chu As I mentioned during the May 25th PC-FHIR call, GF#13196 was discussed at the WGM Wed Q3 and the vote to merge the resources passed (with OO retaining ownership of ProcedureRequest). There is talk of having a Connectathon to continue to solicit implementer feedback on the merged resource (name of the merged resource, elements, FMM level, etc.), but the decision to merge has already been approved.
Brian Postlethwaite (Jul 06 2017 at 20:57):
So to be clear, a referral to a Psychologist for counselling would be a procedure request (is councelling considered a procedure?)
Lloyd McKenzie (Jul 06 2017 at 21:54):
Councelling is definitely a procedure - it's intervention that's intended to bring about change of some sort in the subject. Even training is a procedure.
Eric Haas (Jul 06 2017 at 22:39):
I've considered"ClinicalRequest", "Request" or "ProcedureRequest" as alternatives. The transfer of care bit is NOT being represented in the resource content no matter what we call it.
Sandeep Giri (Jul 21 2017 at 21:54):
Something like "ServiceRequest" would make sense, perhaps also add a type field to denote type of service (Referral vs Procedure, etc to maintain semantic clarity) -- the general construct is that party A (such as a PCP) is requesting party B (such as a specialist) to provide a specific service to a patient. Our team is in the process of implementing referrals using ReferralRequest, and one of the big gaps we discovered was in representing patient insurance information and insurance authorization number. I understand there is the option to refer a Coverage resource as a part of SupportingInfo, but would love to see a dedicated "coverage" attribute, and an a string attribute to track authorization number (since that is specific to the referral visit, and also qualifies for procedures).
Tim Berezny (Aug 22 2017 at 18:05):
Councelling is definitely a procedure - it's intervention that's intended to bring about change of some sort in the subject. Even training is a procedure.
Couldn't it be a "referralRequest"? Or is this related to the future merging of procedureRequest + referralRequest?
Sandeep Giri (Sep 10 2017 at 17:44):
I talked to @Paul Knapp @Eric Haas and @Lloyd McKenzie at San Diego connectathon about adding insurance information to ReferralRequest and ProcedureRequest. Based on their suggestion, I have added a tracker item #13281 to request this change. Essentially it follows a pattern used in Claim resource to have "insurance" as a backbone element with 2 attributes -- one is a reference to Coverage resource, the other is a string attribute to contain preauthorization number. Would love to hear community feedback.
Lloyd McKenzie (Sep 10 2017 at 23:18):
So my real question for this proposal is what parts of "supporting information" need to be called out as distinct elements. I'm fine with calling out insurance-related info if we think we need it to be "special", but we should probably have some criteria for that, or we're eventually going to end up with 20 new data elements on the various Request resources - and that wouldn't be a good thing.
Eric Haas (Sep 11 2017 at 22:06):
Supporting information is by definition limited to 'Clinical information' as part of this discussion we would
review the option to change that definition ot be more inclusive of other non-clinical (i.e., financial information)
Last updated: Apr 12 2022 at 19:14 UTC
