We want to categorize patients in our system. For example, in organ transplant, we want to "tag" a Patient FHIR resource as a donor or recipient (ignoring the scenario where a living donor can later become a recipient) since these types of "patients" are stored separately in the back end system. So when someone does a PUT HTTP request with a patient resource, we need to know what kind of patient it is before we can do the update in the database.
It's hard to determine the best way to approach this. Using the meta area seems promising, combined with the UsageContextType of "focus" perhaps, taking on values of "donor" or "recipient".
It's not clear though how to actually code something like this in a Patient resource (JSON for us). Any guidance/examples would be very much appreciated.
Sadly, I think the FHIR folks are going down the same path they used with the V3 RIM....lots of impenetrable standard definitions, but very few practical examples of how to use some of these FHIR standards in the real world. But that is another issue.
Don't understand ignoring the scenario where someone can be both donor and recipient. However, if you needed to, you could add an extension that differentiated. You could also use Patient.meta.tag.
With the RIM there'd have been an esoteric modelling mechanism to define what you wanted, likely walking through 3-4 classes to get to one element (and a whole lot of fixed values along the way). With FHIR, if you're doing something esoteric, you just define an extension.
If you see something in the core specification you find impenetrable, please submit a change request asking for the language to be improved. (There's a "propose a change" link at the bottom of every page and registration is free.)
Related
I'm implementing FHIR at the moment and I'm having trouble dealing with appointment reasons.
I know I can use the value set available here : https://www.hl7.org/fhir/valueset-encounter-reason.html
or implement my own value set for it but it's still problematic because reasons are a resource in my app and practitioners can add, modify and delete them. Reasons also have various fields such as a color, ...
A value set won't be enough for my app.
Do you have any hints / ideas on how could I implement such thing ?
So you want to point to Condition or Observation as a reason? Or perhaps point to a ReferralRequest or ProcedureRequest the appointment is based on? If so, submit a change request - having these things would also be in alignment with the Request pattern which Appointment should be trying to align with. In the meantime, you're free to define an extension to convey the same meaning.
For us, the "reason" basically indicates what type of service the appointment is going to provide, so we actually map reasons to services, which we represent reason as a HealthcareService resource.
Basically, from the patient's perspective, they care about the "reason" they are going to the doctor. But from the healthcare provider's perspective, they care about the type of service they will provide to treat the reason.
We are using the aws-sdk for ruby, specifically AWS::Record::Base.
For various reasons we need to put records of various objects within the same domain in sdb.
The approach we thought we'd use here would be to add an attribute to each object that contains the object name and then include that in the where clause of finder methods when obtaining objects from sdb.
My questions to readers are:
what are your thoughts on this approach?
how would this be best implemented tidily? How is it best to add a default attribute included in an object without defining it explicitly in each model? Is overriding find or where in the finder methods sufficient to ensure that obtaining objects from sdb includes the clauses considering the new default attribute?
Thoughts appreciated.
It really depends on your problem, but I find it slightly distasteful. Variant records are fine and dandy, but when you start out with apples and dinosaurs and they have no common attributes, this approach has no benefit that I know of [aside from conserving your (seemingly pointless) quota of 250 SimpleDB domains]. If your records have something in common, then I can see where this approach might be useful, but someone scarred like me by legacy systems with variant records in Btrieve (achieved through C unions) has a hardwired antipathy toward this approach.
The cleanest approach I can think of is to have your models share a common parent through inheritance. The parent could then know of the child types, and implement the query appropriately. However, this design is definitely not SOLID and violates the Law of Demeter.
In an upcoming project, we will be creating forms for citizen's to fill out to start the process of applying for the requested license or permit. As one can imagine, a form tends to change often. I would prefer to plan this into the application to avoid making changes on a yearly/monthly/"the big boss want's it yesterday" basis.
My searching has shown me some examples based on the object passed to the view, but those would require coding changes. Others use XML, but never seems to go through the entire process from creating the from to storing the inputted data into the database. It isn't that I need hand holding the entire way; it's that this is something completely different for me and I want some guidance to get me in the right direction. I am thinking along the lines of how these survey sites (like SurveyMonkey) create dynamic polls.
Is there any tools, utilities, tutorials, or books that may cover this quite well?
I would imagine you would probably want to take advantage of Display / EditorTemplates. You would define an interface IQuestion or something, and then have a bunch of different form options that implement that interface. So your model would have a List<IQuestion>, and then for each question in the list, Html.EditorFor(item) or so.
Then some kind of standardized way of storing the answers into a table (perhaps a unique save / load method on IQuestion. That's my take anyways. You could define the questions via DB and then your models could have varying counts (and elements) in the List<IQuestion>. Just run a DB script (or some kind of admin page) and you could dynamically change the form displayed.
I have another programmer who I'm trying to explain why it is that a UI component should not also be a data-structure.
For instance say that you get a data-structure that contains a record-set from the "database", and you wish to display that record-set in a UI component within your application.
According to this programmer (who will remain nameless, he's young and I'm teaching him...), we should subclass the data-structure into a class that will draw the UI component within our application!!!!!!
And thus according to this logic, the record-set should manage the drawing of the UI.
******Head Desk*****
I know that asking a record-set to draw itself is wrong, because, if you wish to render the same data-structure on more than one type of component on your UI, you are going to have a real mess on your hands; you'll need to extend yet another class for each and every UI component that you render from the base-class of your record-set;
I am well aware of the "cleanliness" of the of the MVC pattern (and by that what I really mean is you don't confuse your data (the Model) with your UI (the view) or the actions that take place on the data (the Controller more or less...okay not really the API should really handle that...and the Controller should just make as few calls to it as it can, telling it which view to render)) But it's certainly alot cleaner than using data-structures to render UI components!
Is there any other advice I could send his way other than the example above? I understand that when you first learn OOP you go through "a stage" where you where just want to extend everything.
Followed by a stage when you think that Design Patterns are the solution every single problem...which isn't entirely correct either...thanks Jeff.
Is there a way that I can gently nudge this kid in the right direction? Do you have any more examples that might help explain my point to him?
Have you heard of Martin Fowler?
Separating User Interface
Code
Anyway, if he wants to go further in that direction of adding render methods to his data controls, have him look at "loose coupling". It's okay to create some generic type of interface that gets him halfway there, but the UI component should take it the rest of the way.
This boils down to functional vs. non-functional responsibilities. What the data structure does and how it's visualized are two completely separate things -- essentially the root of the MVC pattern.
There's also a notion of circular dependencies here. Since the UI must know about the data structures, if you allow the data structures to then depend on the UI, you've got yourself a nice little ball of mud.
Generally on the point of decoupling:
Not only can there be different components of the UI rendering the same data structure. You may even have completely different UIs (Web, Desktop Application, ...) Now of course, you could subclass Person with WebPerson and DesktopPerson (this already sounds wrong, doesn't it? The naming is simply not about the kind of Person - it's about something else).
Each UI could work on different kinds of Persons, e.g. Teacher and Student. So we get WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher and DesktopStudent.
Now let's say, WebPerson defines the method "drawAddressFields()" to draw a web version of the address fields. But since WebTeacher has to derive from Teacher to use the additional data field "salary" (and let's assume single inheritance), it must implement "drawAddressFields()" once again!
So maybe the argument of "this will cause much more work" will help to create some motivation :-)
BTW, it will automatically lead to creating some delegate that implements the code of drawAddressField(), which will then evolve to creating a component that does the drawing separately from the data structure.
I just read a blog post that explains MVC with a banking analogy. I have a few months of experience with web application development with an MVC framework (CakePHP), so I get the basics, but I began to see a theme that made me think I'm taking a flawed approach to where I put my logic:
Fat models, skinny controllers
Keep as much business logic in the models as possible
In my app, models are anorexic and controllers are obese. I have all business logic in the controllers and nothing besides associations and validation rules in the models.
Scanning through my controllers, I can now identify a lot of logic that should probably go in a model:
The app has lists, which contain items, and the items can be ranked. The sorting logic which puts the list in ranked order is in a controller.
Similarly, items (Item model) also have images (Image model). Each item may have a default image (designated by image_id in the items table). When an item is displayed with its images, the default image should appear first. I have the logic that does this in a controller.
When a list is displayed, related lists are displayed in the sidebar. The logic to determine which lists are related is in a controller.
Now to my questions:
With the examples I gave above, am I on the right track in thinking that those are instances of logic presently in a controller that belongs in a model?
What are some other areas of logic, common to web apps, that should go into models?
I'm sure identifying this problem and changing my design pattern is half the battle, but even if I decide to take those examples I gave above and try to move that logic to a model, I wouldn't know where to begin. Can anyone point me in the right direction by posting some code here, or linking to some good learning resources? CakePHP specific help would be great, but I'm sure anything MVC will suffice.
It's a bit tough to give you the "right" answers, since some of them deal with the specifics of the framework (regardless of the ones you are working with).
At least in terms of CakePHP:
Yes
Anything that deals with data or data manipulation should be in a model. In terms of CakePHP what about a simple find() method? ... If there is a chance that it will do something "special" (i.e. recall a specific set of 'condition'), which you might need elsewhere, that's a good excuse to wrap inside a model's method.
Unfortunately there is never an easy answer, and refactoring of the code is a natural process. Sometimes you just wake up an go: "holy macaroni... that should be in the model!" (well maybe you don't do that, but I have :))
I'm using at least these two 'tests' to check if my logic is in the right place:
1) If I write a unittest, is is easy to only create the one 'real' object to do the test on (= the object that you are using in production) and not include lots of others, except for maybe some value objects. Needing both an actual model object and an actual controller object to do a test could be a signal you need to move functionality.
2) Ask myself the question: what if I added another way to use these classes, would I need to duplicate functionality in a way that is nearly copy-paste? ... That's also probably a good reason to move that functionality.
also interesting: http://www.martinfowler.com/bliki/AnemicDomainModel.html