Stream: implementers
Topic: VisionPrescription
Grahame Grieve (Jan 04 2017 at 05:48):
@Paul Knapp I do not understand why VisionPrescription.dispense.eye and VisionPrescription.dispense.base were changed from code to CodeableConcept
Paul Knapp (Jan 04 2017 at 06:35):
Dogma. Lloyd asserts that FHIR methodology is to use CodeableConcept as there are times when one is not using the resources for their primary purpose, eg. I'm using a resource for reporting or with descriptions of costs which another department will change into dollar amounts, which isn't supported when using codes. Financial exchanges are normally very tightly designed where all parties have agreed the code systems and clients are not allowed to send text or make up codes on the fly.
Paul Knapp (Jan 04 2017 at 06:38):
So to avoid the 'churn by a thousand small changes' we have finally given in to the repeated assertions and accepted that the resources will be CodeableConcept and that for all machine to machine exchanges (eg. eClaims) all communities will need to create profiles which shut them down to just a single coding.
Paul Knapp (Jan 04 2017 at 06:40):
FM would be happy to hear your thoughts on this, but we really must stop the churn and repeated and conflicting assertions that whatever is done is 'wrong'.
Paul Knapp (Jan 04 2017 at 06:44):
Perhaps it would be better to retrun all of the elements back to being coding, reverse the decision and ballot resolutions, and let people doing local special things such as sending a description instead of a code use extensions for that purpose - would mean several of us would have to undo all of the changes we just made to our systems (and all of the changes to the specs and examples) but would be a better overall solution for the community in my mind.
Paul Knapp (Jan 04 2017 at 06:51):
And while we are on the topic, I don't know why there is an encounter element - I certainly didn't add it, it isn't in the 80%, and I haven't every heard of a functional value for having that information. While the legal requirements may be jurisdiction-based, a provider is normally required to record the presecription including date of issuance, but the encounter is relevant only to that provider and so generally not mandated and irrelevent to share.
Grahame Grieve (Jan 04 2017 at 08:24):
the principle is pretty simple, and you're not follow dogma:
- if the binding is 'required' in the base resource, then the data type would usually be 'code'
- otherwise, the binding would usually be 'CodeableConcept'
- you changed the extensible bindings from Coding to CodeableConcept - that made sense
- you also changed the required bindings from code to CodeableConcept - that doesn't make sense and isn't dogma, and I'm sure Lloyd didn't argue that it is
Paul Knapp (Jan 04 2017 at 09:08):
Agreed, we went too far. Those 2 should have remained codes. I will amend and take to FM on their Friday call - good catch, thank you.
Grahame Grieve (Jan 04 2017 at 09:11):
no problems. I am writing transforms from r2 to r3 for most resources, and have picked up quite a few issues
Simone Heckmann (Oct 28 2017 at 10:41):
Why is "VisionPrescription" a thing?
I'd have expected this to be a DeviceRequest profile referencing "Glasses" as a profile of Device.
Agreed that Device isn't really a good fit for Glasses, but Glasses are covered by the Device.type ValueSet and the describing attributes in the VisionPrescription could easily be covered by a (standard) complex extension for Device.
The way it is right now, it violates the Request/Response workflow model and makes me wonder how many different kinds of [x]Prescriptions we're gonna end up with...
Simone Heckmann (Oct 28 2017 at 11:05):
Also, it kind of precludes "Glasses" from existing outside of a VisionPrescription. So, in order to capture the fact that a patient is wearing glasses with the typical attributes of glasses described in VisionPrescription, we'd need a Device profile after all...
Lloyd McKenzie (Oct 28 2017 at 15:06):
That's been a topic of discussion already. I actually have a "todo" to mock up what DeviceRequest would look like if it allows you to specify parameters and what VisionPrescription would look like as a DeviceRequest.
Eric Haas (Oct 29 2017 at 20:14):
We have trackers to roll it into DeviceRequest them for while. As I see it, would need approval from the FM folks for this to occur.
Simone Heckmann (Oct 30 2017 at 06:48):
If the "mock up" Lloyd mentiond helps to move things along, I could whip up something on short notice...
Simone Heckmann (Oct 30 2017 at 08:39):
Here are some glasses: https://simplifier.net/Sandbox/visual-aid
Lloyd McKenzie (Oct 30 2017 at 18:38):
My vision was to have DeviceRequest.parameter with a parameter.code and parameter.value[x] where x could be CodeableConcept or Quantity (and maybe boolean). If you want to run with that, be my guest :)
Last updated: Apr 12 2022 at 19:14 UTC
