We are working on implementing the FHIR API in a veterinary health care system. One question that has come up is which resource type we should be using for the owner of the animal (patient). In the context of the animal it is easy to see that the owner information can go into the contact of the Patient resource.
However, an animal owner is quite often referenced outside the context of an individual patient. So that leads me to RelatedPerson. The description of the RelatedPerson resource gives an example of "The owner or trainer of a horse", so it seems it might fit. However, one big issue with this is that a RelatedPerson can only be linked to a single patient. The relationship between animals and owners in the veterinary domain is many to many. So an owner often has more than one animal.
This issue led me to the Person resource. This at least gives a way to have multiple Patient's (animals) belonging to one Person (owner).
In either case we'll have to add a "percentOwnership" attribute as an extension to the resource since an animal can potentially have multiple owners.
If this is the way we should do it (using the Person resource), my next question is how would one search using the API for all Patient's linked from a given Person? If we used the RelatedPerson (which is probably not workable due to the limitation mentioned above), it seems like this search would use the relatedPerson compartment to search. However, there doesn't seem to be a person compartment in the spec.
Summary:
What resource to use for the owner of an animal?
How to search for all animals belonging to a particular owner?
If you just want contact information, then Patient.contact is fine. If you're interested in the owner as a potential actor (information recipient, informer, performer, etc.) then RelatedPerson will be necessary. However, RelatedPerson is specific to a particular Patient's record (i.e. you'll have a distinct RelatedPerson instance for each animal). To link all of the RelatedPerson instances together and say "this is the same person", you'd use Person. To query, you'd query on Person where link matched one of the desired RelatedPerson records. Then you'd need to do an include of Person.link and RelatedPerson.patient to bring back all of the animals
Related
I've seen the relationship between a MedicationRequest and MedicationStatement used in different ways at different healthcare entities - specifically linking the two with MedicationStatement.basedOn - and I'm curious if there is a best practice or recommendation for a couple clinical workflows. The FHIR documentation could be interpreted in multiple ways.
Consider the two following basic workflows:
A primary care clinic prescribes a non-acute medication (i.e. lisinopril), and creates a MedicationRequest, which gets ePrescribed to a pharmacy. This prescription could be repeatedly refilled and remain active for the patient's life, or could be stopped if the patient no longer needs later in time. This prescription will span multiple encounters (events) for the treatment plan for this patient.
A patient arrives for an inpatient stay at a hospital. That patient notes they take lisinopril during their intake, and the hospital stores this as a MedicationStatement. That patient's primary care physician (who prescribed the lisinopril) and the hospital are hooked up to the same HIE, and the hospital sees the MedicationRequest for that patient when ingesting data.
For scenario 2 (more straightforward), I could see the hospital setting a reference on their MedicationStatement.basedOn to the ingested MedicationRequest. This aligns with the following from the MedicationStatement documentation:
This is a record of a medication being taken by a patient or that a medication has been given to a patient, where the record is the result of a report from the patient or another clinician, or derived from supporting information (for example, Claim, Observation or MedicationRequest). A medication statement is not a part of the prescribe->dispense->administer sequence but is a report that such a sequence (or at least a part of it) did take place, resulting in a belief that the patient has received a particular medication.
This resource is distinct from MedicationRequest, MedicationDispense and MedicationAdministration. Each of those resources refers to specific events - an individual order, an individual provisioning of medication or an individual dosing. MedicationStatement is a broader assertion covering a wider timespan and is independent of specific events. The existence of resource instances of any of the preceding three types may be used to infer a medication statement. However, medication statements can also be captured on the basis of other information, including an assertion by the patient or a care-giver, the results of a lab test, etc.
For scenario 1 however, I have seen two possible ways to use these resources based on the above. Depending on how the above is interpreted, both could be argued as appropriate usage:
When the clinic prescribes lisinopril, a MedicationRequest is created. If treatment is stopped, that resource's status is updated. MedicationStatement resources are reserved for when their patients self-report a medication, or from ingesting data from a HIE.
When the clinic prescribes lisinopril, both a MedicationRequest and MedicationStatement is created. The MedicationRequest only refers to that specific encounter of prescribing the medication, and the MedicationStatement is used throughout the overall treatment of the patient, spanning multiple encounters or events. If the treatment no longer requires lisinopril, the MedicationStatement status is updated.
From a purely technical perspective, both are using the resources correctly (MedicationStatement is basedOn the MedicationRequest). However from a FHIR usage and clinical data perspective, which usage is correct?
MedicationStatement.basedOn has been dropped in R5 and shouldn't really be there in R4. It would mean "This MedicationStatement was created under the authorization of order XYZ", and that almost never makes sense. If you're going to link a statement to an order, use the 'derivedFrom' element.
Both scenarios are fine. MedicationStatement can be used just for self-reported meds, but it's also fine to have an instance for each active medication therapy. It sort of depends on how the system likes to represent information.
In my elasticsearch setup I want to search amongst a large collection of payments (billions), where each payment has multiple account names. This is due to each user being able to name assign a personal name to each account, while an account can be shared by many users. 1 account, many names (1 per user).
Simplified payment structure:
Payment {
"agreementNumber": 12345,
"accountNumber": 123456789,
"amount": 17,
"currency": "EUR",
"accountName" : ...
}
The user needs to be able to search for and sort on account names, however the result set must differ based on user.
Eg. if Bob and Lisa both have access to the same account, but have made individual naming, sorting on account name would make the payments appear in a different sequence. The rest of the payment details however remains unchanged. This example could be repeated for several thousands users that created their own naming.
Consideration I have made:
Flattened or inner object
I am unable to flatten the structure of the payment to contain all possible account names, and only use the account name for the specific user given the context. That would mean that all payments made with said account number would need to contain all names, and all payments with said number would need to be updated every time an alias is created, updated or deleted.
Nested
Here I would create one collection of names that I refer to in my parent. This would lighten the storage as I only maintain the account names once. This comes with limitations that an update to my nested element (list of account names), would trigger a reindex of all parents (payments) as well. As one account number can be part of thousands to millions of payments this would be very expensive.
Parent/Child relationship
Having account names as children of the parent means, that I can update the child and parent independently negating the drawback of nesting. However Elasticsearch doesn't support joins as far as I have understand, meaning I would get payments and account names as individual documents.
How do I structure my account names without it being crazy expensive?
Note
The limitations mentioned stems from this post:
https://www.elastic.co/blog/managing-relations-inside-elasticsearch
I am facing a challenge. A multi level authorization system and a friend told me cancancan could help me out.
I took a read of documentation but couldn't figure it out. So I'll explain here.
My goal is to create a sys were:
User "John" from South department creates Jane
User Jane creates June an Paul
Users June and Paul create Bob, Nat and Emily
Also
User Peter from North department creates Rita
User Rita creates Becca and Lisa
Users Becca and Lisa create Clara, Lory and Alexa
Now, each user can see only records made by themselves, or from users that are below than, but not above or from other departments.
How should I start with the models and everything?
First of all, you will need to keep track of this tree at database level. In order to do that, you can add a parent_id reference to the users table that will reference the user that created that particular user. This column will be empty for those users that were not created by anyone, and would hold the id of the parent user otherwise. I would highly recommend using a foreign key too, in order to guarantee referential integrity.
Then you will need to define your CanCanCan abilities in a way that this tree structure is traversed properly. You can take as a reference this example derived from the docs:
class Ability
def initialize(user)
can :read, Photo, Book do |resource|
resource.creator.descendant_of? user
end
end
end
I am assuming the User model has a descendant_of? method that traverses the tree from the current user towards the root checking whether the given user is a parent of the creator of the resource. A possible implementation could look like this:
# app/models/user.rb
def descendant_of?(target_user)
parent_id == target_user.id || parent&.descendant_of?(target_user)
end
Depending on the characteristics of your users tree, this proposal can quickly become poor in terms of efficiency, as all users from the owner to the root may be loaded from database in order to perform these checks. Here a couple of ideas that could be worth to explore in case you start facing these issues:
Use an array-like type for the parent_ids column to store the whole list of parent ids. The main drawbacks I see with this proposal is that it adds some overhead if there are changes in the tree, and referential integrity constraints gets lost (AFAIK it is not possible to add a foreign key in this scenario).
In addition to the proposed above, modify the CanCanCan ability to run the query directly against the database instead of doing that check in memory (executing ruby code).
Using the Google Classroom API method userProfile, I can get various information about a user, including their name and email address, but not whether they are a student or teacher. How can I determine whether a user is a student or teacher?
Classroom does have the concept of teachers and students, however the distinction between teachers and students is only meaningful relative to a particular course (it’s possible for a user to be a “teacher” of one course and a “student” of another) and so you might not be able to use these categories to apply access controls in the way you were expecting.
For example, if alice#school.edu is a member of a particular course’s courses.teachers collection, and bob#school.edu is a member of courses.students, then you can use this information to decide that bob#school.edu should not see certain content created by alice#school.edu. (For example, you might not want to show Bob the answers to a quiz that Alice has created on your website, just the questions.)
However, because by default all users can create courses, you probably do not want to show alice#school.edu sensitive information created by teachers of other courses, information intended for teachers that you provide (for example, if you are a textbook publisher), or giving her domain-wide admin features.
If you need to distinguish between “real-world” teachers and students, we recommend that you do this via a mechanism entirely separate from Classroom, such as checking that the user’s email address appears in:
a separately-maintained list of teachers (e.g. CSV uploaded by admin)
the classroom_teachers group – domain administrators can choose to verify teachers to allow them to create new classes (use the Directory API to list a user’s groups)
Classroom api dosent provide global role for a teacher or a student its vary from course to course so you can just call student/teacher api
after that you will get json output and you find a special permission for teacher "Create Course" it will help you to recognized that the person is teacher.
"permissions": [
{
"permission": "CREATE_COURSE"
}
]
in case of student this array will be null.
Imagine a website that agregates online ordering for many restaurants and is built using parse.com.
In parse.com there is a class called Order where all of the orders are stored.
Each order belongs to one, and only one, restaurant.
When querying the Order class, each restaurant can only read (and write) its own orders. A restaurant should not see (and write) orders for other restaurants.
To solve this, I've tried using one role per restaurant and add the restaurant-role to the each restaurants order's ACLs. So I've created one role for each of the Restaurants using the following naming taxonomy: Restaurant-[restaurantObjectId].
I have taken care that user's belong to their respective restaurant-role.
I've also fiddle with Class Level Permissions (CLPs) without results: either total access or total lack of access, none of access limited to restaurant data.
Any clues?
It seems that one has to have make the Find operation available to the Public. Otherwise it gives the not authorized error.