Stream: implementers
Topic: Existing valuesets for Patient Portal enrollment status
Priya Mathew (Jun 27 2019 at 15:54):
Hello!
I'm creating an extension on Patient to hold the enrollment status for a Patient in a portal. Values like "Invited", "Active", "Revoked" "Inactive" etc. Are there any existing valuesets that can be harnessed to hold this information?
Thanks
Priya
René Spronk (Jun 28 2019 at 15:40):
Have you looked at Contract to capture this (instead of using an extension) ? http://build.fhir.org/contract.html
Yunwei Wang (Jun 30 2019 at 22:34):
Or could this be Encounter because enrollment is an interaction between a patient and a health provider for the purpose of providing healthcare related service.
Peter Jordan (Jun 30 2019 at 23:00):
Given the number and variety of patient 'portal' products on offer - some tethered to GP system, some not - I don't think that a single status extension on the Patient Resource would suffice. Therefore, I agree with @René Spronk that the Contract Resource may be a better option. In NZ we do classify patient enrollments into general practices as encounters, but if the use of that resource is constrained to interactions between healthcare providers and patients it might not cover portal products that aren't directly provided by healthcare facilities.
Priya Mathew (Jul 01 2019 at 03:09):
Thank you for the responses! I hadn't thought of contract at all. Perhaps I should elaborate our use case -We are a HIS working with a portal - the use case here is to send a patient resource to enroll in the portal. The portal API will then respond with a status as to whether the patient was sucessfully enrolled. What kind of resource can the portal API return to indicate the state of enrollement of the patient? Are there examples of such a use case we can harness? Thanks!
Lloyd McKenzie (Jul 01 2019 at 04:13):
If the enrollment is for coverage, then you can look at EnrollmentRequest and EnrollmentResponse. (We're actually evaluating whether those can be generified to other types of program enrollment.)
Lloyd McKenzie (Jul 01 2019 at 04:15):
Note that if you're submitting a request and expecting to get a response resource back, you'll need to use an operation
Priya Mathew (Jul 01 2019 at 14:55):
Thanks Lloyd! The enrollmentRequest and Response is most closely aligned to our use case although we're not enrolling for coverage. Yes, please do consider making it generic for other types of program enrollment.
We are an oncology information system working with a number of patient portals. The patient, who is already registered in our HIS, is invited to join the portal- we send an enrollment request(POST patient resource) to the portal with all pertinent demographics including email. Portal invites the patient through the email provided. Patient enrolls in the portal through the portal invite email. We then asynchronously query the portal for all enrollment updates using a timestamp. This is the invite/register usecase. Once registered in the portal, other clinical info is exchanged using standard FHIR resources.
I think the enrollmentrequest and response resource would very nicely fit our usecase, but looks like this is still in a draft state. When will this be in a more mature state to start implementing?
Lloyd McKenzie (Jul 01 2019 at 15:33):
Maturity is driven by implementer action as well as committee work (which is significantly influenced by implementers declaring what they want :>) @Paul Knapp @Andy Stechishin ?
Brian Postlethwaite (Jul 01 2019 at 23:31):
@Peter Jordan you might want to consider EpisodeOfCare instead of encounter where it's not recording an interaction, but a registration/association style thing.
Priya Mathew (Jul 02 2019 at 17:07):
Thank you Brian, looking into EpisodeOf Care. Lots of ideas to run by my team- thanks!
Priya Mathew (Jul 03 2019 at 20:59):
@Lloyd McKenzie after going through the enrollment request/response resources, we feel this best matches our needs. What can we do as early adopters/implementers to push this to be more generic and ready to implement. Where can I raise this? We're looking to start implementing this fall- Thanks for the pointer Lloyd!
Priya Mathew (Jul 03 2019 at 21:24):
@Lloyd McKenzie infact I see this resource was indeed more generic in dstu2! https://www.hl7.org/fhir/dstu2/enrollmentrequest.html.
"Insurer" vs "target"
Paul Knapp (Jul 12 2019 at 17:37):
@Priya Mathew Enrollment with a web site, enrollment for the military, enrollment in a clinical trial, enrollment in an insurance program are similar, to a degree, and also quite different in obligations, information requirements and perhaps workflow. The Financial Management Work Group is interested and knowledgeable on the insurance side, and may have thought on the others, and Patient Administration would have interests and thoughts as well. Suggest you attend the FM conference call when you can and we can open up this topic for advancement. I expect we will need to get into the weeds on a few use cases to determine whether the one or more enrollment resources are required.
Priya Mathew (Jul 12 2019 at 17:55):
Thanks Paul. @Paul Knapp , where can I find details of the FM conference call?
Paul Knapp (Jul 13 2019 at 22:33):
@Priya Mathew All HL7 Conference calls are in the HL7.org Events Conference calls calendar.
FM calls are Tuesday at 11 AM Eastern, goto https://join.freeconferencecall.com/fm4 for the conference screen share and audio.
k connor (Aug 29 2019 at 01:24):
After talking with Priya during the FM and FHIR Security calls, a couple of other considerations seemed to be on the table. Priya clarified that her use case isn't about an agreement to be enrolled in a patient portal, and by implication, other enrollment use cases such as to the military or a clinical trial would not be in scope. Seems that in her use case, the enrollment agreement bit happens between the portal and the patient, e.g., terms of service and privacy practices, which should be done with FHIR Consent/Contract depending on level of legal binding. My observations are that (1) FHIR doesn't seem to support adding Patients/Providers etc to Directories/Master Files so suggest this is a gap that should be addressed. But that's not entirely Priya's use case (as I understand it) although in the ball park. (2) Another thought and another gap, is that FHIR doesn't have a Provisioning Resource, i.e., a way to convey what an End User may do with information (collect/access/use/disclose and other LCEs) given their structural roles (competencies) and their functional roles (permitted workflow functions). This might be a useful way to collect and verify the claims made in an OAuth request or declared in a Push. In Priya's use case, the HIS tells the portal that the patient with demographics for authentication has the right to collect/access/use/disclose their HIS patient records via the patient portal. Seems like provisioning to me. I'll put in a CR for FHIR Security consideration and include responses to this. I added CR for Provisioning Resource https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23776 and one for a Directory Enrollment Resource https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23777 . There may be better solutions but wanted to get something actionable going.
John Moehrke (Aug 29 2019 at 13:03):
The 'request to add this actor to your directory' seems to be a use of a defined operation where the new actor resource is submitted to the directory/portal. As an operation it is expected that the service may need to do many things, such as a human workflow to provision the user. Thus I think this is simply an operation. This operation can also check that the request is authorized and legitimate, etc...
It is surprising this is not part of vhDIR http://hl7.org/fhir/uv/vhdir/2018Jan/index.html
seems if we treat the Portal as a Directory (it is a directory for the users within the portal mapped to backend identifiers)... then this operation works there too?
Last updated: Apr 12 2022 at 19:14 UTC
