Stream: cds hooks
Topic: ResourceType: Hook / HookResponse
Abbie Watson (Apr 12 2019 at 17:00):
CDS Hook newbie question: why haven't resourceType fields been added to the CDS specification? One would think that it would be simple enough to just toss on a resourceType field with a value of Hook or HookResponse. Is there a back story why that hasn't happened yet?
Lloyd McKenzie (Apr 12 2019 at 17:29):
Can you expand on where/how this would be used?
Abbie Watson (Apr 12 2019 at 17:40):
Can you expand on where/how this would be used?
Well, we just did a training session, and spent two days showing examples where pretty much every JSON object has a resourceType... except for the CDS hook examples. I guess I was just surprised that there doesn't seem to be a StructureDefinition defined for the hooks and responses? Also, from a don't-know-what-I-don't-know perspective, it just seems that having a /Hooks endpoint would help with autoconfiguration, and figuring out which hooks a server supports.
Lloyd McKenzie (Apr 12 2019 at 19:19):
Ah, so the more specific question is: Why aren't the various structures in CDS Hooks defined as resources? I think the short answer is that they're purely transport level structures - no expectation to store, update, query, profile or otherwise manipulate them, no desire to ever support any syntaxes other than JSON and resources would add unwanted constraints/complexity. For example, contexts are currently handled as just a propery on the hook invocation. However, a resource doesn't just let you defined properties. We'd instead have to have a name + value[x] approach which, from a pure JSON perspective, is unnecessary.
Lloyd McKenzie (Apr 12 2019 at 19:19):
@Kevin Shekleton or @Isaac Vetter may have additional reasons
Isaac Vetter (Apr 15 2019 at 02:30):
Hey Abigail, Lloyd - originally, we actually were using the Parameter resource as part of the CDS Hooks exchange, we switched to non-FHIR json and the current structure in (I think) the Jan, 2016 connectathon. At the time, the consensus was that using the Parameters resource added no value except consistency with FHIR and made the request/response more complicated and less acceptable. Since the CDS Hooks request/response isn't FHIR, the resourceType element isn't necessary.
Isaac Vetter (Apr 15 2019 at 02:31):
I also agree with Lloyd's reasoning that an ephemeral HookRequest-type resource doesn't make sense in FHIR.
Isaac Vetter (Apr 15 2019 at 02:31):
@Abigail Watson , for your training/connectathons/outreach efforts, I'd suggest that you explain that CDS Hooks is a domain-specific wrapper around FHIR. FHIR is the content, the lightweight, small and simple CDS Hooks request/response structure is simply intended to get the FHIR where it needs to go -- while also not slowing down the clinician.
Lloyd McKenzie (Apr 15 2019 at 02:33):
I believe some of the infrastructure stuff defined for SMART is similarly not handled as a resource, so there's a precedent.
Grahame Grieve (Apr 15 2019 at 23:52):
the only caveat I have to this is that systems definitely have reasons to store the cards that come back
Abbie Watson (Apr 19 2019 at 14:26):
Thanks for the clarification. Makes sense, I think.
My takeaway is that they effectively got demoted to Metadata or Special Purpose Data type, but the documentation hasn't been updated to reflect it because CDS is a separate project.
Lloyd McKenzie (Apr 19 2019 at 14:38):
Can't be demoted if you were never promoted :) They've always been 'custom' structures and when there's been discussion about making them full resources, the outcome of the discussion was to leave things as they are. That doesn't mean there can't be a new discussion though :) I suspect the original discussion is in Git.
Abbie Watson (Apr 19 2019 at 14:52):
Well, I find it interesting/relevant that people have arrived at similar conversations from different directions.
My $0.02 would be that in-practice the resourceType field is appreciated as a general purpose data-typing field for JSON, and there's a flavor of implementors (particularly in the javascript community) who if it were up to them would just add a 'resourceType' field to all the Metadata and Special Purpose Data types. Not because they want those objects to be resources, per se; but because class-typing is useful in of itself, even if it's a kludgy pseudo-implementation.
That, and a vote to add Hook/HookResponse to the Special Purpose Data types maybe.
idk. First impressions, and all that.
Last updated: Apr 12 2022 at 19:14 UTC
