Some prescription sigs include "TAT" for "'till all taken".
This is a useful reminder for the pharmacist to relay for e.g. antibiotic prescriptions.
FHIR MedicationOrder.dosageInstruction includes "asNeeded" (code or boolean).
Typically pain medication would be taken as needed while heart medication would be taken rigorously.
Does marking "asNeeded" false imply that the prescription must be finished or should "TAT" be represented as an extension, e.g. an "untilResolved" extension with a value of false?
I would expect TAT, "with meals", "on an empty stomach" and other similar guidance would be expressed using dosageInstruction.additionalInstructions. (Feel free to submit a change request encouraging the work group to define a starter set of codes that includes these concepts.) "as needed" is used for PRN orders. It indicates that there's some sort of pre-condition that guides consumption. For example "as needed for pain" or "before intercourse". It explicitly means the patient won't necessarily be taking the medication on a regular schedule.
In the current build, there is an example binding for DosageInstruction.additionalInstructions to Snomed-CT and "Until Finished" is included in this hierarchy. http://build.fhir.org/valueset-additional-instruction-codes.html I don't believe a change request is necessary. This example binding has been in place since at least STU3.
Related
I am writing an app that has a sign-up form. This article made me doubt everything I knew about human names. My question is: does a person's name necessarily have positive length? Or can I validate names in this way and be confident that I have not denied anyone their identity?
P.S.: one might ask why am I validating at all. The answer is that this is for a school project and proper validation is a part of the mark. The article above proves that person's name can be pretty much any string of positive length but I don't know if zero length is OK.
With all types of programming, you have to draw a distinction between what is meaningful in the real world, and what is meaningful for your software solution.
How the data is to be used will validate what type of validation is required.
For instance, if your software interfaces with a government API, and the government API requires a first name and surname, you should do the same.
If you're interacting with bank accounts, you may have a single string which represents that account name, which many or may not be a human name or not, but may have other constraints around length.
If the name is only to be used for display purposes, maybe there is no point to capture the name at all, and instead you should capture a preferred display name (which doesn't needlessly assume a certain number of name components).
When writing software, you should target to make as few assumptions as possible, unless those assumptions will cause an increase in complexity of your software solution. If the software requires people to have non-empty names, then you should validate at the border that this is true.
In addition, if you were my student, you would have already lost marks for conflating null, and an empty string. In this instance, null would represent you lack data about the name, and an empty string would indicate that user has specified that their name is empty.
Also, if you decide not to validate something, you should at least leave a comment to indicate that you thought of it. If you do something unusual, it's possible a future developer may come along and fix the "bug". In addition, this helps you avoid losing marks.
I named one of my boolean parameters didInfoChange.
Many people on my team tell me to change it to isInfoChanged, which I don't agree. It maybe because my team members aren't native English speaker (neither am I), but I feel that ifInfoChanged is just isn't right.
didInfoChange -> Did information change? -> True/False
is pretty understand in my oppinion
isInfoChanged -> is info changed?
just does not sound right.
It's probably not a big deal to fight about this, but I did some search and people do not really use did for flag name. I'm ok with hasInfoChanged but has and did is basically the same thing.
I'm wondering why is did not ok?
There are two questions here:
1) Which is better, didInfoChange or isInfoChanged?
The English word "change" can be transitive or intransitive, but in this context it is clear that "the info is changed" and "the info did change" mean exactly the same thing. (There is a subtle difference in connotation, but it is of no importance here.) The two names have the same length. There seems to be no difference except style convention.
2) If your way is better than theirs, what should you do?
Consider the consequences of your actions.
If you have the power to persuade the rest of the team to use your variable name, at no cost, then do so. If doing so would cause stress (e.g. by commanding your subordinates to do something they consider a bad idea), then the improvement in style probably isn't the cost to the group dynamic.
If you cannot persuade them, but you can prolong the argument and prevent the team from doing constructive work, then... don't. Use their variable name.
If you cannot prolong the argument, but you can make yourself unpopular by being argumentative, then... don't. Use their variable name.
Beside is it is also sometimes admissible to use has in naming Boolean getter-methods, depending on which auxiliary verb would be used in spoken language; I never saw did as part of a Boolean identifier.
With hasInfoChanged you would keep the participle ending (e)d. Maybe that satisfies the rest of your team.
infoChanged could be mistaken for an EventHandler-Delegate.
Unfortunately I am not a native English speaker, either.
It depends on the context and what this field "really" expresses in semantics.
didInfoChange puts emphasis on the completed action (past-tense implied) by "did" + action-verb
isInfoChanged puts emphasis and indicates the current-state when asking now by is + state; where the past-tense is indicated by the passive "changed"
Note: Info is the vague part in the name. is is a common indicator for boolean fields or getters - indicating a question (same like has or can). did is rather rarely used because we usually ask for the current state at runtime using is. The completion or history can be expressed by other parts of the name, like specific action-verb in past-tense.
Other ways of recording/asking for change
What about asking more about the context of this change:
Who did change the information ? Like an audit field (changedBy) conveying also who did change something.
When was the information changed ? Like a audit date/time field (changedAt), not only telling that it was changed, but also when.
What information was changed ? Like capturing the change itself (lastChange) which could also be null if not changed at all.
In most ORM-frameworks which capture audit-information like this (when/who/what was changed) we can see fields like createdBy or createdAt for the initial user and timestamp when created, modifiedBy or modifiedAt for the user and timestamp that last updated or changed the object.
Sometimes also a version-indicator helps to keep track of the number of changes.
Keep it simple
One compromise could be inspired by KISS-principle:
Have a boolean field changed which could for enrichment-purpose also hold a timestamp along with a getter named isChanged to query the current state like asking a human question like:
is [this] changed ?
Note: [this] is implied when invoking the method on the object like this.isChanged().
I'm creating a class that needs to parse user contact info to determine if the presented user already exists in the db. Because the source is unvalidated, user generated data I have to test for matches under a variety of conditions.
The content is presented in 3 fields - Name (first & last are combined); Company Name; Email
I need to return a result based on each of these possible match conditions:
Exact Match
Email Match
Domain Name Only
Full Name Exact
Last Name Only
Institution Match
I have a rough idea of how I'd go about coding this and am sure that the result would be inferior to what would be produced by a formal TDD approach. My TDD learning curve is just past the very basics but I don't have the depth to see how the above scenario is staged and developed thru the full lifecycle.
I'd like some help structuring the project from an architectural point of view.
thx
Seems like tou already listed the primary positive test cases in your list of match types. So take those from the top, write a small test for the first case (exact match), warch it fail, make it pass, iterate until exact match works. Then do the same for the other match types.
I'm refactoring one of my projects - a shopping cart. One of the tightly coupled areas of my code is the "Viewer" class - to generate information for the user to see, it often needs a combination of two or more of the following objects:
The store catalog.
The customer's order.
The customer's mailing information.
I can't really break up the display methods, for various reasons.
Martin Fowler's Refactoring identifies this as a "Long parameter list" smell. The relevant refactoring here is "Introduce parameter object." I am, however, hesitant to do that, as doing so would couple loosely related data. It would also lock me to a very narrow one-to-one relationship between those three objects - while that would work for my application as it is now, it makes no real-world sense. (As there is only one store catalog, there can be many "Customer mailing information" objects, and each of those may be related to many "Customer's order" objects).
Does anyone have any elegant solutions to this?
A parameter list of three parameters needs no refactoring. Start worrying when you reach, say, 8 or 10 parameters.
Try to name the thing that binds a catalog, an order, and an address. Start, maybe with CatalogOrderAddressTuple. Ugly, isn't it? Well, maybe as a utility class of your Viewer, it should just be an inner class, where you could get by with just Tuple - or Data. Still ugly.
It doesn't sound like these belong as actual fields to the Viewer - but explore what that would look like, how your code would change if each Viewer were simply constructed with the data on which it operates.
As ammoQ & Ryan Prior have said, this isn't much of a smell, but I'd say it's worth playing with some alternatives before giving up entirely.
As stated by ammoQ, looking for refactoring opportunities with so few parameters is stretching.
See also: KISS and YAGNI.
It seems to me that introducing a parameter object would have the opposite effect of locking you to a one-to-one relationship between those three objects.
If a single customer address is being passed around, and in the future someone decides to separate billing address and shipping address, then it would probably be simpler to add the new address to a parameter object, rather than add a new parameter up and down the call stack.
(This is just an example, of course. Ideally, the address information would exist separately in the order and customer objects, since all information on posted orders should be immutable, even if the customer's address changes. But that wasn't what you were asking about!)
I've long thought (but never practiced for some reason) that a dropdown menu that is dynamically generated and only contains one item, should automatically select that item. This would opposed to the typical approach that I've observed where a blank entry is made at the top and you still have to interact with the menu to make the single available selection.
An example is when I login to my online banking and select "View Paper Statements". I've only got one account so the next step in the process is to present me with a dropdown where I have to select that single account to proceed. In this case, by implementing the solution above, it would take one less click to select the account and proceed to viewing it. Even better in this case would be to eliminate the dropdown menu step altogether and go right to the statement.
Can you think of a case where auto-select of a single item would produce undesirable results?
Can you think of a case where auto-select of a single item would produce undesirable results?
Yes - any case where the user has the option not to select any option.
In your bank account example, pre-selecting the only value makes sense. But if you have e.g. some kind of form where users can provide voluntary information, they will need the possiblity to leave that field blank or otherwise give a possible incorrect answer.
So it really should depend on the nature of the data in that dropdown whether pre-selection is a good idea or not.
I completely agree, in the case you describe. But there are times where you want to force the user to make a selection actively -- e.g., when the value of the field is somehow optional or additive.
In your case, without selecting an account, there's probably no useful way to proceed, so automatic selection does make sense. But for example, an application I'm working on allows the user to specify a number of descriptive fields (movie metadata, basically -- title, release year, genre, etc.), many of which are optional, and some of them are represented by drop-down menus. Allowing the user to leave the default selection blank lets him tell us, effectively, "I don't want to use this field," so we leave it blank, and the data remains clean.
Just one example, although you're right -- in your case, I can see how that'd be annoying. :)
If there is truly only one possibility you shouldn't ask a user to decide between Option A. (Bad grammar to illustrate the point)
If the field can be left blank, it's not an option with a single answer. Instead you have a choice between Option A "meaningful data" and Option B "".
Iif list has blank option but the form does not allow that to be blank, it's a choice between Option A. (Bad grammar to illustrate the point)
Sometimes you want the user to explicitly select an option, even when it's the only option. If the option is selected automatically, the user may never even realise it, even though they may not be happy with the result.
For example, I'm reviewing my savings account on my internet bank site. Then I go to set up a payment. As it happens, I'm not allowed to make payments from my savings account, so the payment form automatically selects my only other account. If I don't notice this then I will end up making the payment from my other account when I was expecting to use my savings account. If I had known, I wouldn't have made the payment at all.
Perhaps this is slightly contrived. But unless you can be certain that the user will be happy with the (only) choice, you should ensure that they choose it explicitly.
I agree. If there's only one item in the dropdown and it's required that the user select something, then just default to the single item. I can't think of any negative effects of this (but I'm certainly not a UI expert)
What I like to do in this instance depends on a few factors.
If the dropdown is a required field and ends up with only one item due to dynamic generation, I try to avoid displaying it as a dropdown entirely. I end up showing it as an uneditable text field instead (or not displaying it at all if it isn't necessary). Why make it even look like it's a choice when it isn't?
If the dropdown is not required, then it makes total sense to display a blank choice in addition to the single value.
If it's REQ and there's a single record/value .. I'd try and change the control to a Display field rather than the Drop Down.