Stream: implementers
Topic: FHIR, Scratchpad, SMART Web Messaging, and unfinalized in...
Matt Varghese (Feb 12 2021 at 18:10):
Hey folks - a question came up on the SMART Web Messaging call today.
Would we say, if a clinician places an order in an EHR, but hasn't signed it, then that order still is expected to show on a FHIR Search with status of draft? Am I incorrect if I say the order not showing up is an EHR "implementation detail", but according to the specification, the unsigned order / unfiled information should ideally be showing up?
And corollary to that, will SMART Web Messaging making a "holding tank" for unfiled information that does not show up on the FHIR server even with a draft status be in line with the FHIR specification, or will it be a divergence from the FHIR specification?
(@Carl Anderson , @Dennis Patterson , @Chuck Feltner , @Josh Mandel , @Isaac Vetter )
Josh Mandel (Feb 12 2021 at 18:32):
To be clear, SMART Web Messaging contemplates an in-memory scratchpad for data aren't yet in a state to persist in a FHIR server (e.g., "someone started writing a prescrition for hypertension but hasn't picked a drug yet", or "someone is completing an order signing process"). We have these same use cases in CDS Hooks, where we also don't expect/require data to have been persisted in a FHIR server prior to being shared with an external CDS system for decision support.
Josh Mandel (Feb 12 2021 at 18:35):
i.e., a CDS Hooks "actions" response interacts with in-memory objects just the same way a SMART Web Messaging "scratchpad" request does. These are designed against the same interaction model.
Josh Mandel (Feb 12 2021 at 18:35):
@Dennis Patterson and @Chuck Feltner I expect this makes sense from your perspective too, given what I understand.
Matt Varghese (Feb 12 2021 at 18:47):
Are we saying that even in CDS Hooks, the suggestions from CDS Hooks are not expected to be showing up on the FHIR server when they are taken? To me that feels very wrong..
In my understanding, if data was not finalized, FHIR allows for it through draft statuses.
Whether an implementation actually exposes the unfinalized data using those draft statuses is an implementation detail of the particular implementation.
Or is my understanding incorrect?
Dennis Patterson (Feb 12 2021 at 18:56):
SMART apps today have the ability to allow the user to persist resources via a FHIR url. SMART Web Messages allow additional assistance as the user works through the stages of creation in their native EHR, whether or not that EHR chooses to use a FHIR server as their intermediate data store for draft resources (where that status exists). The scratchpad concept is storage agnostic, but the term covers the period of user->EHR interactions.
For CDS Hooks, take the order-select workflow. Just because an orderable is selected, doesn't necessarily require that it's persisted to FHIR. The user is in the process of editing that order. If the EHR choses to persist each updated field to FHIR, it certainly can. But the intent wasn't to preclude an editing process prior to pushing to a more permanent data store.
Matt Varghese (Feb 12 2021 at 18:58):
@Dennis Patterson , this what you say is really the question I am asking:
Just because an orderable is selected, doesn't necessarily require that it's persisted to FHIR
Is this according to the FHIR spec?
Or should these be on the FHIR server according to spec, and their not being on the FHIR server is an EHR implementation detail?
Lloyd McKenzie (Feb 12 2021 at 19:22):
There's no expectation that orders in the process of being created will be available on the FHIR server That's one of the reasons the hook passes the whole resources rather than just the ids for them. They could be available (as draft), but it's entirely possible they exist only in memory and aren't visible to the persistence layer at all yet.
Matt Varghese (Feb 12 2021 at 19:23):
I understand there is no expectation. However, there is already a FHIR way of doing this (what I am asking to confirm in my original post).
So is it appropriate to make another scratchpad in SMART Web Messaging?
Carl Anderson (Feb 12 2021 at 19:35):
For anyone observing this without the context of the earlier call - there are detailed minutes here:
https://confluence.hl7.org/pages/viewpage.action?pageId=104563953#SMARTWebMessagingBallotReconciliationCC20210212-Matt-DiscussScratchpadReplacementProposal
Josh Mandel (Feb 12 2021 at 19:47):
it appropriate to make another scratchpad in SMART Web Messaging?
I think this is not "another" scratchpad so much as... the implicit place where data in CDS Hooks also/already live. We're just giving a name to it so developers understand it's a thing (a place / state in which ephemeral resources can exist).
Carl Anderson (Feb 12 2021 at 19:48):
SMART Web Messaging describes the concept of an EHR scratchpad, which is conceptually, out-of-FHIR-server memory to hold a resource until it is ready to be created inside a FHIR server. A common analogue is a shopping cart in an online retail site, but in the EHR - the common use case is with an order that a clinician is assembling for a patient.
Several of the defined SMART Web Messaging messages manipulate objects in the scratchpad with CRUD operations (scratchpad.create, scratchpad.update, etc).
I think Matt's main objections are 1) that this functionality could conceptually be done entirely inside a FHIR server using draft states for resources and 2) that by defining the scratchpad in the spec - EHRs are expected to implement things a certain way.
Carl Anderson (Feb 12 2021 at 19:50):
My problem with this argument is that it can be completely turned around.
For example, even with a message like scratchpad.create - an implementing EHR is free to insert a draft resource into the FHIR server and maintain the illusion that there's an in-memory object somewhere. I just don't see how defining and using scratchpad.* messages is forcing anyone's hand - or running counter to the spirit of the FHIR spec.
Matt Varghese (Feb 12 2021 at 19:50):
I think the primary thing I am saying is that the "scratchpad" (1) may or may not exist per EHR and per resource type (2) is something that should be inside the black box of the EHR, and should not be baked into the SMART Web Messaging specification. FHIR specification hasn't baked this into it - it allows for it by staying silent about it, and the same is what SMART Web Messaging must do.
There is already mechanisms in FHIR to allow the contents of the "in memory holding tank" to be exposed if an EHR chooses to. And so we should not invent additional mechanisms in SMART Web Messaging that do the same thing?
Josh Mandel (Feb 12 2021 at 19:52):
(1) may or may not exist per EHR and per resource type
Yes, and this is good: EHRs can support or not support it, explicitly accepting or failing requests
Josh Mandel (Feb 12 2021 at 19:53):
(2) is something that should be inside the black box of the EHR,
Scratchpad API does hide it in a black box; apps don't care how the scratchpad works, whether it's the same or different rom the FHIR server, etc. They just know "here's where my ephemeral session data can be found."
Matt Varghese (Feb 12 2021 at 19:53):
Note also that, otherwise, we'll now have to create all CRUD operations for scratchpad, and it becomes unclear to an App whether what's in the scratchpad query responses is same or different from what it got in the FHIR server query responses for draft status resource etc.. We'll essentially be making another fhir endpoint for unfiled information, in addition to the existing one for finalized information..
Josh Mandel (Feb 12 2021 at 19:55):
This is how CDS Hooks already works; it's what's missing for apps launched via App Link cards.
Lloyd McKenzie (Feb 12 2021 at 19:56):
We can't reasonable force EHRs to expose their scratchpad content via their 'standard' FHIR interface - because there are technical designs where that would be impossible. However, we're not saying they can't do that in defining the scratchpad mechanism.
Josh Mandel (Feb 12 2021 at 19:58):
Exactly @Lloyd McKenzie -- that's what making scratchpad a "black box" accomplishes.
Chuck Feltner (Feb 12 2021 at 20:27):
There does not seem to be an existing FHIR mechanism to support this. How would one query for all of the draft orders for a specific user UI session? Doesn't it also seem that sending the in-progress FHIR resources within the SMART Web Messaging would make for a faster interaction between the EHR and the SMART App?
Vassil Peytchev (Feb 12 2021 at 20:36):
What is the purpose behind the need to "query for all of the draft orders for a specific user UI session"?
Josh Mandel (Feb 12 2021 at 20:38):
So that a decision support app can give you advice about things like duplicate orders, missing orders, etc.
Josh Mandel (Feb 12 2021 at 20:39):
The CDS Hooks order-sign use case (https://cds-hooks.org/hooks/order-sign/) is one example; or any apps you'd attach at a similar point in workflow.
Vassil Peytchev (Feb 12 2021 at 20:43):
So that a decision support app can give you advice about things like duplicate orders, missing orders, etc.
Doesn't the DS app need ALL draft orders for the patient, not just from the current user session? Multiple orders can be entered by multiple users at the same time...
Matt Varghese (Feb 12 2021 at 20:52):
@Chuck Feltner I'm not sure I follow this comment
There does not seem to be an existing FHIR mechanism to support this.
As I understand, the EHR has the option to expose draft orders on the FHIR Server.
Josh Mandel (Feb 12 2021 at 20:54):
Doesn't the DS app need ALL draft orders for the patient,
No, just orders that the user is responsible for -- i.e., the orders they're signing off on in their session
Matt Varghese (Feb 12 2021 at 20:56):
Also, I want to reiterate the risk of the scratchpad becoming another duplicative FHIR endpoint.
What if the App only wants to know about specific types of orders in the scratchpad? Would we allow scratchpad.search with the same set of query parameters as fhir.search? Would we allow _include and other parameters, even on a scratchpad.read?
Note that, according to the FHIR spec, the scratchpad really reduces to an additional query parameter of status=draft. (Granted implementation details make this hard).
So not only does this become a duplicative endpoint for unfiled information, it is also technically a proper subset of the FHIR endpoint in my view, barring implementation limitations.
Josh Mandel (Feb 12 2021 at 20:59):
The only query operation we proposed was "tell me everything on the scratchpad"
Josh Mandel (Feb 12 2021 at 20:59):
It'd be up for apps to filter as they see fit.
Matt Varghese (Feb 12 2021 at 21:05):
It'd be up for apps to filter as they see fit.
If that is the case, then all unsigned orders should be provided, and not just from this user's session
Matt Varghese (Feb 12 2021 at 21:07):
App may filter based on ordering provider if use case warrants it, but there are use-cases which don't warrant that.
Vassil Peytchev (Feb 12 2021 at 21:07):
No, just orders that the user is responsible for -- i.e., the orders they're signing off on in their session
So, for (completely made up) example, patient is seen by PCP, PCP decides to refer the patient to endocrinologist. Workflow allows the referral order to be done by PCP's staff, who will manage the referral. While staff is drafting the referral order (user 1, with scratchpad 1), PCP is ordering diagnostic lab tests (user 2, with scratchpad 2). Since the referral order is only on scratchpad 1, DS for diagnostic lab tests only sees orders on scratchpad 2, and raises no alerts, even though the referral to endocrinologist would have suggested two additional lab test, but the referral order is not accessible in user 2's session.
Is that too much "made up"?
Lloyd McKenzie (Feb 12 2021 at 21:34):
If a user's session is in a browser, the "EHR" has no clue what draft orders they have, and certainly has no way to share them across sessions. Also, what's a user supposed to do about a possible conflict with something someone is theoretically thinking about in a different session (possibly in a different department or even a different building)?
FHIR cannot force systems to take content they currently hold only in memory and persist it in a central database just because that might make using CDS Hooks easier. CDS Hooks has to function with the architecture of EHRs as it now exists.
Lloyd McKenzie (Feb 12 2021 at 21:37):
Vassil, the challenge with your example is if the PCP orders the 2 additional lab tests and then whoever's doing the referral decides not to submit it, you've now ordered two unnecessary lab tests. Anything 'draft' is something that might well never occur. A decision support engine advising the user creating the draft things is fine - because the user knows what's actually going to happen or not and can adjust. But trying to link across users doesn't give that insight into what's actually happening.
Chuck Feltner (Feb 12 2021 at 21:49):
@Matt Varghese Given that the EHR supported saving of draft orders, in order to support the same functionality in the scratchpad messages in the SMART App Web messaging, it would need to query for all the draft orders for the specific user UI session that the SMART App was launched within. I don't see the search parameters in the specification that could support this.
Matt Varghese (Feb 12 2021 at 22:17):
@Chuck Feltner , agreed. That is another reason I think we should just stick with the FHIR server (and an optional SMART Web Messaging fhir proxy) instead of trying to define a scratchpad which will necessitate scratchpad.read and scratchpad.search operations - and so bring with it all of these problems.
Matt Varghese (Feb 12 2021 at 22:18):
Note that I'm not saying EHRs shouldn't have scratchpad. I'm saying scratchpad shouldn't be baked into the SMART Web Messaging spec, but be completely left out, and the messages should just be called ui.create, ui.delete, and ui.update.
Matt Varghese (Feb 12 2021 at 22:20):
Whether the resource goes into a scratchpad or not before being finalized is an implementation detail that the spec shouldn't concern itself with..
Matt Varghese (Feb 12 2021 at 22:22):
For reference, the original JIRA issue I wrote up: https://jira.hl7.org/browse/FHIR-31052
Josh Mandel (Feb 13 2021 at 00:04):
We're going to have to agree to disagree on this, Matt. I've explained all of the reasons why the use cases require a scratchpad abstraction (and if the EHR wants to persist everything to a FHIR server, that's A-OK -- but it shouldn't be forced to).
Matt Varghese (Feb 13 2021 at 01:12):
I just raised this issue today @Josh Mandel - I don't know that we should close this off this quickly. I'd like to see if others have concerns here; I worry the impact of duplicating draft status and scratchpad will only become evident when people try to implement the spec with apps that use diverse resources (especially ones like Observation, Condition etc.)?
Matt Varghese (Feb 13 2021 at 01:18):
@Lloyd McKenzie, if unfinalized data is not expected to show up in the FHIR Server, why does FHIR have a status of draft for MedicationRequest, ServiceRequest etc?
What I mean to ask is, having these makes apps expect that they will show up; yet an app which only read the spec will really not work. So it would almost seem these statuses should then be altogether removed to promote interoperability by setting the right expectations for Apps?
Matt Varghese (Feb 13 2021 at 01:39):
Additionally, when we start making exceptions like what's in the browser is not going to be on the FHIR server etc., I worry that we're setting a bad precedent from the spec perspective. Next, if I have a distributed database for the EHR, then is it okay if my FHIR server only returned data in one of the databases, and not another? What if I have different buckets of data - data that I'm the primary source for, and data that was received from another service - is it okay if the FHIR server only included some of these buckets and not others?
The same parallels come into play with SMART Web Messaging. Elaborating on the idea that @Vassil Peytchev brought up, if one "scratchpad" is ordering warfarin, and another "scratchpad" is also ordering warfarin, and if these are not aware of each other - that is a patient safety incident - the patient could die!
So I'd think trying to open the opaque box of the EHR and say these parts of EHR may be on FHIR server, and these parts of EHR may not is bad precedent for the spec. The FHIR spec says draft orders can be accessed through it and provides a way. Whether the EHR implements it or not is up to the EHR. But making a duplicate mechanism like scratchpad which isn't as well thought out as the FHIR server IMO is not safe!
Lloyd McKenzie (Feb 13 2021 at 02:55):
- The fact that FHIR supports something doesn't mean servers do. Not all servers have the capacity to persist draft orders
- Imagine a tablet that's authoring content and that stores it on a cloud server. It's certainly not going to be continuously sending updates to the cloud server to store the interim data - or at least we can't demand that it does so.
I'm not worried about two scratch-pads ordering the same thing because the time of editing the order isn't the only time that decision support occurs. Decision support will also happen when the order is written to the server as an active order. And, at that point, one will get saved first and the second one will trigger an issue. Obviously it'll trigger the issue a bit later than desired and cost the bit of time, but it's likely to be significantly less time than being triggered about notifications about actions that 'might' be taking place on a device somewhere else.
The fundamental issue here is: Stuff exists in memory that isn't persisted. HL7 is not going to (and shouldn't) try to change that architecture for those that want it. However, if it's useful to find a decision support mechanism that can function when stuff lives in memory and isn't persisted, then we should do that. We're not seeking perfect, omniscient decision making. We're seeking what's possible. When you've got two apps running on the same device, having them share data about what's in memory is achievable. Having two remote devices that simply happen to be dealing with information about the same patient sharing information about what they have in memory when they don't even know about each other isn't realistic. Saying that no system can manipulate stuff just in memory isn't realistic either.
Matt Varghese (Feb 13 2021 at 03:55):
But the use case doesn't really need scratchpad or use it. It's only an artefact of the current writing of the spec. There is currently no scratchpad.read or scratchpad.search option.
What is really necessary is UI integration. So I'm saying we shouldn't propose the scratchpad at this point; since there are alternatives for the hypotheticals that drive the scratchpad, and it's too unclear what it is. ui.create, ui.delete, ui.update etc meet the requirements. Calling these scratchpad.* introduces the question, what is the scratchpad, and brings in all these considerations.
Lloyd McKenzie (Feb 13 2021 at 04:38):
That's a separate question from whether hitting the server is an alternative. If we're agreed that hitting the server isn't an alternative for accessing "in memory" resources, I'll leave making the case for accessing those in-memory resources to others.
Josh Mandel (Feb 13 2021 at 04:59):
Just to recap:
1) there's an important use case for accessing data that might not be persisted (yet) in a FHIR server; I think we have agreement on this (as indeed CDS Hooks demonstrates)
2) When exposing these data to apps, it's important to be explicit about fact that these ephemeral resources in a user's session aren't necessarily available on the EHR's FHIR server -- while also making them visible to apps (and the term "scratchpad" is intended to convey as much); I think Matt disagrees on this point and he would prefer not to introduce any developer-facing concept for these transient resources. But I don't see how to satisfy the use case without it (we spent about an hour of today's call talking through it, but the closest we could get was "support for only a limited subset of fhir resource types, and no way to query by data in the user's session, and a requirement for a 'quirks mode' when an EHR chooses not to expose non-persisted resources"
Matt Varghese (Feb 14 2021 at 22:05):
I disagree again with (1). Data that might or might not be persisted is EHR internal workings. The spec should only think of it as draft and not draft information. If we are saying as @Lloyd McKenzie answers above that FHIR server is not expected to contain Draft information, that risks making FHIR a very nebulous specification? One can no longer rely on what is and is not available on the FHIR server according to spec.
In fact, the wording on the MedicationRequest draft status itself goes counter to what we are saying, at least as I'm reading it:
image.png
@Grahame Grieve , can I request you to comment on the above? If a physician places an order in an EHR but hasn't signed it yet, according to FHIR specification is that order expected to show up in the FHIR server with a status of draft or not? Can we say that the according to the FHIR specification, that order is expected to show, and it is only FHIR server implementation limitations which might make the order not show up on the FHIR endpoint?
Additionally, the scratchpad brings in unnecessary complications. If I have currently a draft order for MRI Head, and the App has already added a delete request for that MRI head onto the scratchpad, can the app now request a delete of the delete request it added to the scratchpad? If a scratchpad is to be treated as a "shopping cart", then the app presently has a delete of the MRI Head queued up. It should be able to remove that queued up action..
Lloyd McKenzie (Feb 14 2021 at 22:15):
FHIR doesn't expect any server to do anything. A compliant server is anything that exposes a CapabilityStatement - even if the CapabilityStatement indicates the server doesn't support any resources at all. The base FHIR specification doesn't set any demands. US Core imposes more expectations, but there's no "minimum" set of statuses that are mandatory - meaning there's absolutely no requirement that servers must expose draft information. And even then, there's a difference between "draft that's stored to come back to later" and "draft held in memory while being actively manipulated". I can't imagine we'd ever write a specification that mandated support for the above.
Matt Varghese (Feb 14 2021 at 22:19):
Fine - expect is perhaps not the right word. Where I say expected above, you can read "the intention of the spec".
@Lloyd McKenzie : (rephrasing my original question) When a physician pulls in / selects an order, but has not signed it yet, is it the "intention" of the FHIR spec that the order shows up on the FHIR server with a status of draft?
Matt Varghese (Feb 14 2021 at 22:28):
And if the intention is so, can we say that the order not showing up is a limitation of the particular implementation?
Josh Mandel (Feb 14 2021 at 22:38):
As Lloyd points out, the FHIR specification doesn't work this way. It doesn't impose these kinds of constraints on how specific systems are built.
Paul Church (Feb 14 2021 at 22:41):
From the base spec it's fair to say that if it shows up, a status of "draft" is clearly the right choice.
Whether it must show up is a question for some combination of SMART Web Messaging, CDS Hooks, and us-core.
Matt Varghese (Feb 14 2021 at 22:48):
@Josh Mandel , I'm not asking about constraints.
I'm asking, is it fair to say that the way FHIR specification intends things like unsigned orders to be exposed to apps is a resource with draft status?
And so, there is a mechanism that FHIR already provides for unfiled information. Creating a concept of "scratchpad" is (1) redundant and (2) rife with concomitant issues.
Lloyd McKenzie (Feb 15 2021 at 03:27):
Yes. If a resource is persisted in a server that is unsigned and a signature is needed to activate it, then the appropriate status would be 'active'.
The issue here is that we're talking about resources that aren't stored on the server. The solution can't be "you must write them to the server" because that's imposing an architecture on the implementation that's not our right to do. SMART Web messaging is about providing a mechanism for software running on the same client to share information about what's in memory that isn't persisted anywhere.
Lloyd McKenzie (Feb 15 2021 at 03:27):
(At least, that's how I understand it...)
Matt Varghese (Feb 15 2021 at 04:17):
It is not at present a question of whether a resource is persisted or not, because at present, there is only scratchpad.create, scratchpad.update, and scratchpad.delete, with no scratchpad.read or scratchpad.search.
So (1) without there being a read or search operation, any resource on such a "scratchpad" is unknown to the App
(2) Neither CDS Hooks specification, nor the order-select or order-sign hook proposes any such notion of a scratchpad so that it cannot also be thought of as specifying any resource in such a "scratchpad" to the App
Matt Varghese (Feb 15 2021 at 04:22):
Also even if the persistence question comes up, scratchpad or shopping cart is an artefact of ordering workflows.
- When placing an unsigned order that a physician has to interact in UI to fill details for before signing, these generally go to a scratchpad in some (but not necessarily all) EHRs
- However, when placing a protocol order for example, which does not require explicit signing, but can have status of active right at the time of App filing it, such a "scratchpad" is not likely to be found in implementations as far as I know
- Similarly, when deleting an unsigned order that exists in the ordering cart, the delete happens from the ordering cart here called scratchpad. But if the delete operation was for an active order, it is a discontinue/cancel order workflow, and there is no scratchpad involved that I am aware of.
- When filing almost any other resource, say Conditions for problem list item or visit diagnosis item, or Observations for vitals or smoking history etc. such a "scratchpad" notion does not exit. In fact, likely for that very reason, many of these resources (including both Condition and Observation) don't even have a draft status.
- Based on the above examples, if an App did a scratchpad.create for a draft order, another for a signed order, and one for a condition, then the app would expect a future scratchpad.search to show all of these, yet would be very surprised / disappointed by realistic implementations because only the first would likely go into an actual scratchpad.
So in sum, it is the UI / EHR host that creates, deletes, or updates resources for the SMART App, and the UI may use a scratchpad in very select situations for the implementation of the specific operation, but definitely does not use it in all and not even in the majority of these situations. Therefore, I cannot see the scratchpad as rightfully belonging in the SMART Web Messaging specification.
Matt Varghese (Feb 15 2021 at 04:38):
Essentially, I'm saying not only is the scratchpad not universal, it does not even apply to the majority of the situations.. or even to a sizable minority. Rather it applies almost exclusively to orders (MdeicationRequest and ServiceRequest resources) with a status of draft.
Because of that, the spec should not say anything about the scratchpad. Rather, the operations should be ui.create, ui.delete, and ui.update. The UI / EHR Host will be able to consult / use the scratchpad when the particular EHR's implementation of the particular workflow involves a scratchpad, and skip the scratchpad when the particular EHR's implementation of the particular workflow does not involve a scratchpad.
Lloyd McKenzie (Feb 15 2021 at 15:12):
What's the difference between "ui" and "scratchpad"?
Matt Varghese (Feb 15 2021 at 15:21):
"ui" is what does the action of create/delete/update.
I don't honestly know what "scratchpad" is as a generic concept. As I said above, the EHR implementation detail may sometimes use an ordering cart for draft status orders - which I can't see as appropriate to generalize as a scratchpad becasue
- It is not applicable in all situations. Only applicable in draft order workflows and perhaps a few other draft resource situations (minority of situations).
- It is an internal implementation detail of some EHRs
Josh Mandel (Feb 15 2021 at 16:02):
(We've been through this in discussion; I'm not seeing anything new here, but please highlight if I'm missing anything Matt.)
Matt Varghese (Feb 15 2021 at 16:07):
@Josh Mandel : Scratchpad does not exist in majority of the create/update/delete operations.. for same reasons as why Observation or Condition resource etc. don't have a draft status. So defining "scratchpad" for these doesn't make sense..
Lloyd McKenzie (Feb 15 2021 at 16:11):
Scratch pad has nothing to do with "draft status". It has to do with content not yet persisted. A system might be creating a diagnosis (or set of differential diagnosis) and launch a SMART app to help. The SMART app might need to manipulate the in-memory content before it gets stored.
Matt Varghese (Feb 16 2021 at 21:57):
As an update, I chatted with @Lloyd McKenzie and want to summarize that discussion here:
- If we say, scratchpad contains things that are "in-memory", here is an example that contradicts. An organization has multiple systems in place. The ordering system has the ability to pend draft orders. So the order that a physician drafted up but did not sign yet is saved in persistent store on the ordering system, but is not in the EHR database. So this resource is neither in-memory, nor on the REST-ful FHIR endpoint. Should data that is ‘stored’ but not currently held in memory be accessible through the ‘scratchpad’ interface.
- An organization uses multiple systems which have their own FHIR REST-ful endpoints. These systems are each able to query the other system, so that data on the other system is "accessible" to these systems. However, the FHIR REST-ful endpoints of these systems will only return data that they are primary source for. So if we define "scratchpad" as things not on the REST-ful endpoint but available to the system, should each system include content on the other system as "scratchpad" content?
- Lloyd considers scratchpad as capturing "work in progress" objects. I pointed out that is the general English sense of "Draft" status, but Lloyd is concerned that FHIR Draft status doesn't mean the same thing. Some of the content that is “work in progress” may have a status other than draft. Also, some content with a status code of ‘draft’ might be available over the regular RESTful API and not need scratchpad to access. So even though what we mean by "scratchpad" aligns with the English sense of the word "draft", that is different from the FHIR sense of "draft" status and prevents "scratchpad" being defined as the place that holds draft resources.
- Even if we consider "scratchpad" as somehow defined, if I want to represent a Condition resource in the scratchpad for example - this presents a challenge. All the presently extant status values for Condition imply a finalized state / available at REST-ful endpoint. Status being required, we'll have to figure out how such a conceptually draft condition resource will be represented before we can use this "scratchpad". Specifically, once a system has a resource, how does it tell if it represents an in-memory “work-in-progress” object that isn’t an official resource version from one that is?
- If we take an example of an existing Patient resource's demographics being updated, the update is in a conceptually draft state, but the resource itself does not have a draft status. We'll need to be able to capture this distinction somehow in order to represent this resource in queries to the scratchpad.
Matt Varghese (Feb 16 2021 at 22:05):
All of these could make defining a "scratchpad" larger than the scope of SMART Web Messaging. We may have to also make changes elsewhere in FHIR to define such an entity.
I am proposing that we can avoid defining the "scratchpad" by saying the EHR Host (called "ui" in SMART Web Messaging) be treated as the agency for the create/update/delete operations. So the messages will be ui.create, ui.delete, ui.update. How the EHR Host does this / whether the EHR host uses a "scratchpad" or not, should be treated as an opaque box to the spec.
Lloyd is not comfortable with the above idea. According to Lloyd, even if we use "ui" as prefix, the distinction of "conceptually draft" as well as what the rules are for what can or must be exposed through the interface and how that overlaps or doesn’t with the RESTful API still needs definition.
John Moehrke (Feb 16 2021 at 22:33):
these all seem like systems design and policy. They would thus be beyond the scope of FHIR core.
Josh Mandel (Feb 16 2021 at 22:49):
Agreed John. The use case here is "stuff that doesn't necessarily exist on a FHIR server yet, but can be modeled using FHIR resources and made available to apps for decision support". When it comes to "modeled using FHIR resources," that could include status=draft in some cases, but there's not a direct equivalence here.
Last updated: Apr 12 2022 at 19:14 UTC
