Stream: implementers
Topic: Enrollment
Brendan Keeler (Oct 28 2020 at 17:22):
When designing provider edge application workflows, a common mental model is "Enrollment" -> "Supplementation" -> "Writeback"
Enrollment is the moment at which an app knows there is work to be done for a given patient. For example, for a surgical application, this might be the moment that a patient is scheduled for a case. For a diagnostic testing application, it could be the moment that a provider places an order for the test. In any circumstance, this is the first time that you know of the patient and your trigger to do something with their data.
Enrollment in an pre-FHIR world was primarily driven off of HL7v2 ADT, ORMs and SIU, with the occasional single sign-on launch passing patient ID via SAML or encrypted URL.
Enrollment is different with FHIR. SSO is encapsulated well with SMART, but the query-based nature of FHIR (at least the capabilities we see on the market) doesn't lend itself to the ideal enrollment scenario. FHIR subscriptions are undeveloped and not seen with EHRs yet, polling is inefficient and often not widely supported (I can't hit most EHRs' ProcedureRequest endpoints to get the newest updates; I need to pass patient or encounter as a required parameter), and no one seems to like messaging.
So applications are forced to develop clunky flows where providers have to select patients in the application, it seems. How are people thinking about / solving for this?
Vassil Peytchev (Oct 28 2020 at 17:33):
"Enrollment is the moment at which an app knows there is work to be done for a given patient. " --> generally that is expected to be done via Task. At least that is the goal, AFAIK it is still not widely adopted.
Brendan Keeler (Oct 28 2020 at 19:52):
For a concrete example: if I were a LIS and use ORM / ORU today, how do I accomplish my workflow in a FHIR world?
Vassil Peytchev (Oct 28 2020 at 20:01):
For a general background, take a look at http://build.fhir.org/workflow.html
For a more specific (but still general and higher-level) diagram, take a look at http://hl7.org/fhir/us/dme-orders/2020Sep/restful_fhir_exchanges.html
Brendan Keeler (Oct 29 2020 at 04:59):
Thanks Vassil.
It just doesn't feel like we're close to that flow being real. I don't see Task supported by many (any?) EHRs and it's not like upcoming regulatory changes affect that. So some of the most common integration use cases (EHR - LIS, EHR - PACS, etc) aren't serviced in the FHIR world.
René Spronk (Oct 29 2020 at 07:28):
Most of those workflows occur within one single organization, so HL7 v2 will reign such workflows for the foreseeable future. It only makes sense to switch to FHIR if there are real advantages ($-wise), or if one is dealing with exchange scenarios v2 wasn't designed for. To me, this is the sole reason for the low uptake of Task and Task-based workflow scenarios.
Lloyd McKenzie (Oct 29 2020 at 13:35):
I generally describe interoperability as having 4 levels of complexity:
- read-only
- write for 'single-owner/write-once' (e.g. Observation, QuestionnaireResponse)
- write for shared/multi-write resources (e.g. Encounter, Condition, AllergyIntolerance)
- integrated workflow (external system asks for order fulfillment, manages orders)
EHRs have broad support for the first. Most have support for the second. They're starting to roll out the third. The fourth is hardest, so it's not surprising it's not implemented yet. However, Da Vinci, Gravity and others are pushing for this capability, at least in some areas, so I suspect we'll start to see it happening.
Brendan Keeler (Oct 29 2020 at 14:21):
Why is FHIR inherently cross organization?
Provider SMART launch is "in-enterprise" /"one organization". Seemingly a paradox that capability being built out en-masse (at least in the US) when corresponding FHIR resources necessary for the most meaningful and common workflows can't be accommodated.
IHE is well established for cross organizational flows. Not advocating for XDS by any means, but it's an example of how the precedence of a well deployed standard isn't explanation enough.
The only greenfield is patient authorized applications, which certainly has seen adoption and opens up a new class of consumers applications, but it doesn't "fix" broken problems.
From my experiences, the Netherlands just as much as the US is still hindered in innovation by HL7v2. It seems wild to me that diagnostic ordering is not accommodated and nowhere on the EHR roadmap. When remote care, digital therapeutics, and other rapidly growing need order/resulting, they're forced to live in the 90s and set up VPNs, learn MLLP, and start counting pipe delimiters. That seems wrong.
Brendan Keeler (Oct 29 2020 at 14:30):
Lloyd, that's an interesting framework.
To be clear, I'm not critical of the standard level of things here (as Task exists and there's detail on how things could be), but I'm concerned and dismayed about the direction of regulatory and implementation adoption levels. The mixed standards of healthcare are only going to get muddier for the forseeable future.
Vassil Peytchev (Oct 29 2020 at 14:41):
they're forced to live in the 90s and set up VPNs, learn MLLP, and start counting pipe delimiters. That seems wrong
HL7 over HTTP has been around for a while. It probably needs an update, but it is in use.
Brendan Keeler (Oct 29 2020 at 15:11):
EHRs haven't really adopted that. 87.9% of the HL7v2 traffic we see is MLLP over VPN. Another 9.8% is SFTP. Only 1% is HTTPS.
Lloyd McKenzie (Oct 29 2020 at 18:38):
FHIR isn't inherently cross-organization. FHIR is quite neutral into how it's used. However, implementation typically has been in places where interoperability hasn't already existed or been poor - and that's generally been in the cross-organization space. Organizations have long experience getting systems within the walls of a hospital to talk to each other via complex interface engine configurations. But that doesn't scale well across organizations. Certainly you could rip out all of an organizations v2 interfaces and use FHIR for everything. However: lots of internal systems still have zero FHIR support; spending lots of money to replace an interface and not accomplishing anything that wasn't already being done tends not to be career-enhancing; in-institution exchanges are typically 'mission critical' while external interfaces are perceived as less so. All of those factors tend to drive an 'external' focus. All that said, at least a few organizations have chosen to replace most/all of their v2 with FHIR because moving to a single modern platform was deemed to provide benefits worth the risk/cost
Koray Atalag (Nov 18 2020 at 08:58):
Hi All, I have a query around Enrollment - in a nutshell a broader scope that includes particularly enrolling patients to mHealth / wellness programs. My real-world requirement is for an EMR to be able to tell our ePRO platform (patient reported outcome) to add a patient to a predefined project (e.g. Hip Replacement) so that a series of questionnaires and educational material can be sent to patients. In this case, there is the notion of setting a baseline data collection date (can be others). Comments/Feedback/Advice welcome
I'm carrying over a related discussion from #Questionnaire channel; between myself and Lloyd
Koray> I'm looking to model a request from EMR to our PROMs solution to add (enroll/recruit) a particular patient to a predefined project. Once the patient is added to a particular project our system defines the questionnaires and the schedule by which they'll be sent out to the patients. In essence this is similar to the ADT A01 type of transaction.
If I breakdown the actions I'm needing:
1) Create a new Patient in ePROMs solution (ZEDOC) (if already exists then update)
2) Add patient to an existing PROMs project (via an agreed Project Id)
3) Set baseline data collection date
Lloyd: Lloyd McKenzie3:36 AM
Right now, we have a couple of 'enrollment'-related resources, but those are currently specific to coverage/insurance rather than to programs in general, though personally I'd like to see them generalized. (As well, there's a need to transition the notion of 'enrollment response' to just 'enrollment' because sometimes enrollment isn't driven by a request.)
Koray: That's great, I was thinking about exactly the same resource but then realised the use case was for insurance. Another one that got my attention is the Measure resource, which includes PROMs in its type description. But I reckon this isn't for an action but rather definitional. I can see the enrolment concept would apply more broadly, for example including things like recruiting patients to a smoking cessation programs or blood glucose control mHealth interventions etc. Not sure if there's already a resource for it specifically but should also apply to patient recruitment to a clinical trial as well
Lloyd McKenzie: Measure is for defining what information should be collected - it has no notion of "sign-up".
Lloyd McKenzie: You might experiment with EnrollmentRequest and response, and if they're "close", you can submit a change request to have their scope broadened
Koray: I reckon for the time being I can create an an extension for baseline data collection date, which probably in the end will most likely not be part of resource proper anyways. The more I think about this I think it is worth having a dedicated resource for enrolling patients to a program that involves data collection points with certain semantics (e.g. pre-visit, baseline, post-op, 30days follow up etc.). Which I believe could be done via a repeating generic date element and through slicing these tags could be added. That's what I'd do with an openEHR archetype
Lloyd McKenzie9:12 AM
A new resource is definitely an option too. We look forward to your feedback :)
Lloyd McKenzie (Nov 18 2020 at 13:28):
@Paul Knapp
Daniel Thomson (Nov 18 2020 at 23:37):
This is something we've been looking at too for the New Zealand context. We currently have a National enrolment service using SOAP APIs to record a patient's enrolment for publicly funded primary care. We're now looking at offering FHIR APIs for our various services including a version of the enrolment service, but the existing Enrolment-related FHIR resources don't seem well suited to recording participation in a program like this.
Koray Atalag (Nov 30 2020 at 11:11):
Hi @Daniel Thomson any progress with this? I've been referred to the #patient empowerment stream and had a chat with Dave deBronkart who encouraged to bring this
Brendan Keeler (Nov 30 2020 at 21:59):
@Vassil Peytchev @Lloyd McKenzie circling back on this. for the LIS workflow, why wouldn't the ordering system just send/push ServiceRequest (rather than sending Task and expecting the rendering system to pull it?
We have a group that's interested in replacing their standard ORM/ORU with FHIR, but they are proposing just:
EHR (as client) sends ServiceRequest to LIS FHIR Server as a POST Create
LIS (as client) sends DiagnosticReport/Observations to EHR FHIR server as POST Create
Vassil Peytchev (Nov 30 2020 at 22:12):
- ServiceRequest does not reflect the state of the workflow, in this case, "received", "accepted", "Specimen received", "Specimen Collected", "Specimen Insufficient", "Preliminary results", "Final results" etc. Task.status + Task.businessStatus + Task.statusReason can handle that.
- ServiceRequest is the authorization. It belongs to the ordering provider, and needs to exist on the EHR side. The "mirror" copies on the LIS are not of interest to the ordering provider
- The "results" in the EHR need to be matched to the original ServiceRequest. Instead of creating DiagnosticReport/Observations on the EHR side, the LIS can notify the EHR of changes to the Task, so that the EHR can GET the results (and expose the EHR version in separate resources). This way the EHR can be (mostly) read-only from the CRUD perspective, while the LIS only needs to allow CRU for the Task resource.
Lloyd McKenzie (Nov 30 2020 at 22:27):
Sending a ServiceRequest is a possibility, though you need to put a tag on it that says "action this". Posting a ServiceRequest alone doesn't imply that the recipient needs to act on it. There are lots of reasons to share a ServiceRequest as an FYI.
Lloyd McKenzie (Nov 30 2020 at 22:28):
The workflow section in the spec covers all the different ways you can say "please do this" and their various pros and cons. A bare ServiceRequest is one of the options there, but be sure you understand all the cons and the necessity of adding the 'action' tag.
Paul Knapp (Dec 04 2020 at 17:58):
The term enrollment has a variety of meanings depending upon context. Financial Management created the stub of this resource to address enrollment in insurance plans, but this resource could be generalized to address other 'enrollment' activities as well. Please join the conference calls Tuesdays at 11 Eastern at https://us02web.zoom.us/j/82031005986 Passcode: 098894.
Koray Atalag (Dec 05 2020 at 07:29):
@Paul Knapp thanks for the heads up - unfortunately that'd be my 5am so won't be able to join. What would be the best way to follow up offline? Here on Zulip or on Confluence / Jira?
Cooper Thompson (Dec 07 2020 at 14:01):
@Brendan Keeler In many cases, I also like the ServiceRequest push model rather than the Task based model. The task model assumes that the pushing system knows which external parties should be acting on the ServiceRequest. In my experience, very of then the knowledge of which system is responsible for what actions based on a ServiceRequest is just organization knowledge and is codified in a routing layer. The EHR system (for example) that is sending out the ORM/ServiceRequest may not (in general) know which parties will be acting on it.
Cooper Thompson (Dec 07 2020 at 14:02):
Using Task and ServiceRequest adds a tight coupling between the request for something to be done, and the workflow for doing it. I think there are different opinions on on whether that tight coupling is good or bad.
Cooper Thompson (Dec 07 2020 at 14:06):
I personally prefer the loose coupling. EHRs aren't generally going to know all the systems in an enterprise that want to know about a ServiceRequest and do something when an order is placed. The lab system usually has tight integration, so maybe the EHR and Lab are tightly coordinated, but you also have infection control systems, data warehouses, back-end CDS services, care management, HIEs, etc. The HL7 decoupled model is nice because the EHR system doesn't have to be aware of all the systems that need to know about something, you can have a separate routing layer that has that knowledge. If you move that knowledge in to the EHR, then either 1) you have to duplicate that routing logic for other content that isn't sourced from the EHR or 2) make every system in your enterprise aware of every other system that needs to know about stuff.
Cooper Thompson (Dec 07 2020 at 14:08):
Or 3) you still have that intermediary doing the routing, they just have to spawn and track all the Tasks, which makes the routing layer a lot more complicated since it needs a stateful FHIR server.
Lloyd McKenzie (Dec 07 2020 at 14:22):
Task-based doesn't presume the pushing system knows. The Task might be stored on the placer system, and filler systems come along and query or subscribe and claim the Task. Or they might be stored on an intermediary system and do the same. Choosing to use ServiceRequest doesn't really change that, other than the 'source of truth' ServiceRequest should never be posted to anywhere other than the placer system.
ServiceRequest alone is just an authorization. It doesn't trigger any action unless there's a flag on it that says 'actionable'. (In which case it needs to be posted to the filling system and should have an 'intent' of 'filler-order'.)
Cooper Thompson (Dec 07 2020 at 14:56):
Lloyd McKenzie said:
ServiceRequest alone is just an authorization. It doesn't trigger any action unless there's a flag on it that says 'actionable'.
Agree here. I guess my opinion is that sending the authorization for the service is the thing that FHIR should be communicating across the wire. What action is appropriate for that authorization is something a receiving system would determine for themselves upon receipt of the ServiceRequest.
Cooper Thompson (Dec 07 2020 at 15:01):
Lloyd McKenzie said:
The Task might be stored on the placer system, and filler systems come along and query or subscribe and claim the Task. Or they might be stored on an intermediary system and do the same.
This is the part I don't get. How would the placer know all of the tasks that exist in an enterprise based on an authorization for a service? The placer might know that the lab would be actually executing the test, but there are a lot of other tasks that an enterprise might be doing based on an authorization for a lab test. It seems needlessly complicated to either have the placer manage all those, or have an intermediary (that formerly just did routing) manage all those. Distributing the management/creation of Task to the filler systems seems like a much more flexible design, but in that case the Task could just be internal to the filler and isn't really part of the workflow, so it doesn't really need to be FHIR.
Lloyd McKenzie (Dec 07 2020 at 15:52):
The receiver of an authorization cannot safely determine what they should do. There are lots of situations where authorizations get shared when there is not an expectation for the authorization to be acted on. The presumption is that when an authorization is pushed, that it's an FYI unless there is a specific tag that indicates otherwise. As well, if you don't have a Task, then there's no ability to say "yes I will/no I won't", communicate progress, etc.
Lloyd McKenzie (Dec 07 2020 at 15:55):
There always needs to be something beyond just the base Task that says 'please fulfill'. The workflow section of the spec describes the options (setting a tag, calling an operation, sending a message or using Task). If you're sticking with pure REST, then your choices are 'tag' or Task. And 'tag' is pretty limited in what you can accomplish. It's essentially a "toss it over the wall, presume it'll be acted on, and hope a result/set of results get tossed back over the wall.
MaryKay McDaniel (May 13 2021 at 19:17):
@Koray Atalag
Koray, we've added your JIRA Ticket 22812 to the MAY WGM Friday Q4 session.
FMWG Co-Chairs
Koray Atalag (Jul 01 2021 at 02:24):
MaryKay McDaniel said:
Koray Atalag
Koray, we've added your JIRA Ticket 22812 to the MAY WGM Friday Q4 session.
FMWG Co-Chairs
Sorry I seem to have missed this - what was the resolution?
Priya Mathew (Aug 17 2021 at 21:30):
Following...we had a similar need. I'd raised it with the task group- https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Existing.20valuesets.20for.20Patient.20Portal.20enrollment.20status. We went ahead and used the EnrollmentRequest/Response to implement it- even though it's a stub state. I know- we probably broke a few rules here, but it fit our use case really well! In DSTU2, this resource was more generic.
Last updated: Apr 12 2022 at 19:14 UTC
