Closed cooperthompson closed 6 years ago
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 .
See my comment for #38
To clarify here the "Appt-type" = Patient Friendly Service codes that subsumes Appt-type, Specialty and Service
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.
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 .
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 codeable would need to be different for this use case.
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 .
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?
How to implement this?
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
Next steps: Review, Implement as a single list With mapping to Service + Appt type. (tentatively on client end)
Are these visit types for patient scheduling and/or provider scheduling. Do we need two list for each scenario?
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.
RE: mapping to Service + Appt type. Tentatively implemented on server end - still need to update the examples..
Comments?
creating extensible binding for service-type in Slot and Appointment profiles. will keep open until after connectathon experience
applied as a "visit-type" values set
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.)