Stream: argonaut
Topic: scheduling / Issue #39 Need to prioritize building a shor...
argo-scheduling-bot (Sep 11 2017 at 23:18):
cooperthompson opened Issue #39
We should prioritize building a (probably Extensible) valueset of the >10 common appointment types for scheduling.
We will exclude visit type modifiers from this (i.e. new/existing pt, pediatric, etc.)
argo-scheduling-bot (Sep 12 2017 at 02:20):
Healthedata1 commented on Issue #39
already in core?
Eric M Haas, DVM, MS
Health eData Inc
211 South Jefferson Street, Napa, CA, 94559
707.227.2608|Skype: haas.eric1
ehaas@healthedatainc.com <ehaas@healhtedatainc.com>On Mon, Sep 11, 2017 at 4:18 PM, Cooper Thompson <notifications@github.com>
wrote:We should prioritize building a (probably Extensible) valueset of the >10
common appointment types for scheduling.We will exclude visit type modifiers from this (i.e. new/existing pt,
pediatric, etc.)—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/argonautproject/scheduling/issues/39>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AHEU6qpaA1VOUiirna3WFJdEEKS3bRdHks5shb_LgaJpZM4PT5E4>
.
argo-scheduling-bot (Sep 27 2017 at 00:27):
Healthedata1 commented on Issue #39
See my comment for #38
argo-scheduling-bot (Sep 27 2017 at 21:43):
Healthedata1 commented on Issue #39
To clarify here the "Appt-type" = Patient Friendly Service codes that subsumes Appt-type, Specialty and Service
- Issue is whether can get a single list of codes that rules them all and bigger issue is whether could get broad agreement between clients ( 3rd Party Apps) and Servers ( EHRs) on these concepts
- Could Provide a cross-mapping to Appt-type, Specialty and Service in the FHIR Resources ( Slot, Appt, etc)
- Where would the translations occur client/server?
argo-scheduling-bot (Sep 27 2017 at 21:57):
brianpos commented on Issue #39
The Appointment-type on the base appt resource is about the type of patient that will receive the service, the service-type/category/specialty is about what is to be done, and I think where the patient friendly service codes should go.
argo-scheduling-bot (Sep 27 2017 at 22:09):
Healthedata1 commented on Issue #39
I think appt-type is an appt attribute = the circumstances around the
appointment. I would like to see its definition clarified in the resources
think I have a tracker to that effect.Eric M Haas, DVM, MS
Health eData Inc
211 South Jefferson Street, Napa, CA, 94559
707.227.2608|Skype: haas.eric1
ehaas@healthedatainc.com <ehaas@healhtedatainc.com>On Wed, Sep 27, 2017 at 2:57 PM, Brian Postlethwaite <
notifications@github.com> wrote:The Appointment-type on the base appt resource is about the type of
patient that will receive the service, the service-type/category/specialty
is about what is to be done, and I think where the patient friendly service
codes should go.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/argonautproject/scheduling/issues/39#issuecomment-332667390>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHEU6gy1AEp22dwYrH1zS8UCwwmtWzGJks5smsSsgaJpZM4PT5E4>
.
argo-scheduling-bot (Sep 28 2017 at 16:27):
daliboz commented on Issue #39
Just to clarify - when we say "patient friendly" are we talking about having a display that is different than what the system/practitioner would see? If so, that's likely an extension off the display of the CodeableConcept rather than a value set. I'm curious why the codable would need to be different for this use case.
argo-scheduling-bot (Sep 28 2017 at 16:55):
Healthedata1 commented on Issue #39
Yes you are right a patient friendly display could be an alternate
designation in the value set. But I think the intent the comment was
trying to convey is to unify the service codes into a single list that does
it all. Which is a tall order.Eric M Haas, DVM, MS
Health eData Inc
211 South Jefferson Street, Napa, CA, 94559
707.227.2608|Skype: haas.eric1
ehaas@healthedatainc.com <ehaas@healhtedatainc.com>On Thu, Sep 28, 2017 at 9:27 AM, Jenni Syed <notifications@github.com>
wrote:Just to clarify - when we say "patient friendly" are we talking about
having a display that is different than what the system/practitioner would
see? If so, that's likely an extension off the display of the
CodeableConcept rather than a value set. I'm curious why the codable
would need to be different for this use case.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/argonautproject/scheduling/issues/39#issuecomment-332890688>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHEU6p277jiBTIFPkzQKd-KXL-xrr3zGks5sm8jzgaJpZM4PT5E4>
.
Eric Haas (Sep 28 2017 at 16:57):
I don't understand @Jenni Syed question "I'm curious why the codable would need to be different for this use case."
Jenni Syed (Sep 28 2017 at 16:59):
The standard code - which is the list in the codeable field, shouldn't need to change just because it's patient facing
Jenni Syed (Sep 28 2017 at 17:00):
IE: for Observation, we allow Observation.code to be a list of standards. EG: Loinc
Jenni Syed (Sep 28 2017 at 17:00):
That loinc display isn't what I want displayed - it may not be physician-friendly, for example
Jenni Syed (Sep 28 2017 at 17:01):
That's where the text field comes into play (Observation.code.text) - the codeable doesn't change standards
Jenni Syed (Sep 28 2017 at 17:02):
IE: the patient doesn't care about the backing terminology in this case, they only care that when they look at it/read it, it's something they understand
Jenni Syed (Sep 28 2017 at 17:03):
There's a deeper issue if you're saying you want a patient friendly terminology - what about when it's the desk clerk or provider looking at it? You can't change the resource just because a different person is looking at it (ie: you shouldn't change a specific field value just because of that)
Eric Haas (Sep 28 2017 at 17:04):
Thanks for the explanation. and I agree with you. But I think the core of the comment is whether we can come with a single list of concepts instead of specialty, service and appt-type
Jenni Syed (Sep 28 2017 at 17:05):
And that terminology set wouldn't live in the Resource itself?
Jenni Syed (Sep 28 2017 at 17:08):
So, If I'm following correctly, we're trying to take something that is post-coordinated in the FHIR resource (3 values/fields) and find a set of values that are essentially a pre-coordinated representation of the valid combinations
Eric Haas (Sep 28 2017 at 19:30):
Am trying to explain what the ask is - I think you bring up a lot of great questions which I have as well. As I see it there would need to be:
- a concept mapping done to use in the resource ( i.e., split into specialty, service and appt-type) or
- overload one of those elements with this list (and ignore the other two?)
Either way the terminology is obviously a sore point when using the FHIR resources (no surprises there) since what is used in the real world probably doesn't closely align with these axis defined in FHIR.
argo-scheduling-bot (Oct 09 2017 at 23:28):
Healthedata1 commented on Issue #39
After further discussions about this, Are there a few <20 services that can be identified that cover the majority of use cases?
and should be somehow incorporate them into the spec either as a value set or a set of concept maps to the the existing terminologies and or examples?
argo-scheduling-bot (Oct 11 2017 at 00:37):
Healthedata1 commented on Issue #39
How to implement this?
- Use directly as input Parameters instead of Appt-type, Service and Specialty Codes
- Pros:
- Easier to manage on Client end
- low hanging fruit ( "common stuff")- Cons:
- Mal-alignment with Appt-type, Service and Specialty Codes in current FHIR resources -
shifting the mapping steps around
- Consensus on a single list may be not be achievable
argo-scheduling-bot (Oct 11 2017 at 19:27):
cooperthompson commented on Issue #39
Here is a list of some of our common visit types:
Breast Imaging
CONSULT
CT
Dental
DXA
ECHO
ECHO STRESS TEST
ED FOLLOW UP
EEG
EGD
ELECTROCARDIOGRAM
EVALUATION
FLU SHOT CLINIC
Fluoroscopy
FOLLOW UP
Home Heath Visit
INJECTION
Interventional Radiology
LAB
MINOR SURGERY
MRI
NEW PATIENT
Nuclear Medicine
OCCUPATIONAL THERAPY
OFFICE VISIT
PHYSICAL
POST-OP
PRE-ADMISSION TESTING VISIT
PRE-OP
PROCEDURE
PROCEDURE
SAME DAY
STRESS TEST
SURGERY
TREATMENT
ULTRASOUND
URGENT
Vision
WALK IN
WELL CHILD
X-ray
argo-scheduling-bot (Oct 25 2017 at 18:10):
Healthedata1 commented on Issue #39
Next steps: Review, Implement as a single list With mapping to Service + Appt type. (tentatively on client end)
argo-scheduling-bot (Oct 26 2017 at 00:02):
Healthedata1 commented on Issue #39
Are these visit types for patient scheduling and/or provider scheduling. Do we need two list for each scenario?
argo-scheduling-bot (Oct 31 2017 at 21:31):
Healthedata1 commented on Issue #39
updated build to include visit-types added mappings to service-type and appt-type and added to operation. http://build.fhir.org/ig/argonautproject/scheduling/OperationDefinition-appointment-find.html.
Comments?
argo-scheduling-bot (Nov 01 2017 at 00:19):
Healthedata1 labeled Issue #39
argo-scheduling-bot (Jan 12 2018 at 00:00):
Healthedata1 commented on Issue #39
creating extensible binding for service-type in Slot and Appointment profiles.
argo-scheduling-bot (Mar 19 2018 at 23:23):
Healthedata1 commented on Issue #39
applied as a "visit-type" values set
argo-scheduling-bot (Mar 19 2018 at 23:23):
Healthedata1 closed Issue #39
Last updated: Apr 12 2022 at 19:14 UTC
