what is the difference between MedicationDispense vs MedicationAdministration fhir? Functionally speaking
I am BA and I'm trying to figure out what is actually retrieved when using one or the other. Devs are all new to this FHIR too.
If you read the descriptions there are subtleties but not clear definitions.
For example, are MedicationDispense medications that my doctor GP prescribed and I bought at the pharmacy? Are MedicationAdministration only those given to me when I am under care at home or hospital? Seems like a thin line.
MedicationDispense is used to track the supply of a medication (typically a prescribed medication) for patient use. In out-patient settings, it tracks the provision of a supply of medication to a patient or their representative - typically for periods of 30 days or longer. In in-patient settings, it is generally used to track the supply of a medication from the pharmacy to the ward (possibly per day or longer, but sometimes on a per-dose basis). In both cases, it tracks only the supply of the medication, not that it has actually been consumed by the patient. It is not uncommon for a medication to be dispensed but not administered (or not administered as planned).
MedicationAdministration tracks a single consumption of a dose of a medication. A completed MedicationAdministration means the patient is believed to have actually ingested/been injected with/otherwise appropriately therapeutically received the substance. It is typically only used in in-patient settings where a nurse or other practitioner records the occurrence of an injection, an IV adjustment, the witnessing of a patient swallowing an oral medication, etc. However, it can also be created by home health monitoring solutions. E.g. if a patient tracks their medication consumption with a mobile phone app, the app would create a MedicationAdministration instance for each dose of medication the patient (or spouse or other caregiver) records. Aside from that exception, administrations aren't generally tracked for outpatients.
The main differences are:
a MedicationDispense is accompanied by medication instructions indicating the timing and dosage instructions for how the supplied medication should be used. The quantity dispensed is typically sufficient for multiple doses and is NOT necessarily intended to be taken all at once.
a MedicationAdministration is not accompanied by instructions. Instead it simply captures what was administered at a particular point in time, or for IV or other continuous medications, over a specific period of time at a given rate.
The business processes they're associated with are quite different. If you feel the descriptions could be improved to make the differences clearer, feel free to propose language using the 'propose a change' link at the bottom of any page in the FHIR specification.
Related
Suppose we have an event and we want to prove that the event occurred after a particular date, we have a few easy ways of doing so. For example, one may just show a snapshot of a newspaper with a particular date and headline, indicating that the event is at least after that day. Or we could put in the ending stock price in a particular exchange of a particular date to say that it was after the end of trading hours of that day. This could be as fine grained to the second after the time when the exchange closed.
How to do the converse ? How can one say that an event occurred before a particular point of time ? One could depict large events (skyline of NYC to show various before or after WTC) and geological changes, but that is a very large-scale measure. Is there a much more fine-grained way to depict the fact, of the granularity of a few hours or days ?
Hash up the information you need to preserve (e.g. with a https://en.wikipedia.org/wiki/Merkle_tree) and publish the resulting hash value openly. This doesn't disclose any usable information, but if you later need to prove precedence, you can disclose the values you hashed up to show you had the information at that time.
I heard a story of AT&T paying for newspaper advertisements, long before computer security was mainstream, which disclosed a hash value. After a while the paper became worried that they were publishing mysterious advertisements every day that looked like secret codes and AT&T had to explain to the newspaper what the function of these were.
(A web search finds https://www.newscientist.com/article/mg13318103-800-technology-computer-fraudsters-foiled-by-the-small-ads/ including
Bellcore began running its advertisements in the New York Times in October
1991. They were interrupted for several months when newspaper employees
became suspicious of their cryptic contents. ‘Somebody said, ‘These look
like codes. You might be telling a terrorist to kill somebody,’ says Haber.
Fortunately for Bellcore, the Times’ computer correspondent persuaded the
newspaper to allow the advertisements back in.
Beware - article is buried in CSS and cookie notifications and inline ads)
Background:
I have been digging into the FHIR DSTU2 specification to try and determine what is the most appropriate resource(s) to represent a particular patient's historical list of GPs/PCPs. I am struggling to find an ideal resource to house this information.
The primary criteria I have been using is to identify the proper resource is that it must provide values to associate a patient to a practitioner for a period of time.
Question:
What is the proper resource to represent historical pcp/gp information that can be tied back to a patient resource?
What I have explored:
Here is a list of my possible picks thus far. I paired the resource types with my thought process on why I'm not confident about using it:
Episode of Care - This seems to have the most potential. It has the associations between a patient and a set of doctors for a given time period. However, when I read its description and use-case scenarios, it seems like I would be bastardizing its usage to fit my needs, since it embodies a period of time where a group of related health care activities were performed.
Group - Very generic structure that could fit based on its definition. However, I want to rule out other options before taking this approach.
Care Plan - Similar to Episode of Care rational. It seems like a bastardization to just use this to house PCP/GP history information. The scope of this is much bigger and patient/condition-centric.
I understand that there may not be a clear answer and thus, the question might run the risk of becoming subjective and I apologize in advance if this is the case. Just wondering if anyone can provide concrete evidence of where this information should be stored.
Thanks!
That's not a use-case we've really encountered before. The best possibility is to use the new CareTeam resource (we're splitting out CareTeam from EpisodeOfCare and CarePlan) - take a look at the continuous integration build for a draft.
If you need to use DSTU 2, you could just look at Patient.careProvider and rely on "history" to see changes over time. Or use Basic to look like the new CareTeam resource.
Currently (02-12-2013), in the practitioner resource 0..1 names can be associated to a practitioner. In contrast, 0..* names can be associated to a patient. This allows specifying a person's maiden name for example. Why is there this difference?
In the project I'm working on, we're exporting existing data about practitioners from our database using FHIR messages. In the database, all persons are stored in the same way. Since it is possible to store a person's maiden name (which is also done for practitioners in our data), we have to build the name part in a practitioner message differently from the name part in a patient's message. Also, when parsing a practitioner message, we'll need different code to extract the name of a patient and of a practitioner.
Therefore, I believe that there are two disadvantages of having different generic attributes of persons of different kinds:
It prevents us from sending the complete name information of a practitioner without resorting to extensions.
It complicates the code for building and parsing FHIR messages, which also makes the code less maintainable.
I understand that in most cases it's not very important to be able to send the maiden name of a practitioner, but it does add extra complexity for the implementation. Furthermore, I don't see what problems setting the cardinality to 0..* could cause. If someone only wants to send a single name, then that's still possible.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also discussed here) also seems like an unnecessary restriction.
Managing cardinality is a tricky issue. If the resource can have multiple names, then everyone dealing with this has to deal with the possibility of multiple names. The relevant committee believes that having multiple names is an unusual practice for practitioner records (that's certainly my experience) but a common one for patient.
Perhaps you'd like to explain your full use case so it can be considered by the committee? On the other hand, you can use an extension:
<Practitioner>
<extension url="http://myurl.com/fhir/profiles/extensions#maiden">
<valueHumanName>
<!-- details for human name -->
</valueHumanName>
</extension>
</Practitioner>
Therefore, I believe that there are two disadvantages of having
different generic attributes of persons of different kinds:
When designing Patient, Pracitioner and RelatedPerson, we have tried several different solutions:
having Person resource, separate from Patient/Pracitioner. This proved to be burdensome since many systems (unlike yours!) don't capture patient and person separately, and when looking at REST useage patterns it turned out they were always needed togehter, resulting in unneccessary burden on client and server
Having a special Demographics datatype which contained all shared attributes. This met resistance since it meant having attributes on Practitioner that did not make sense, e.g. marital status and deceasedDate. This run against our intent to keep the Resources focused to their scope and the number of attributes per resource manageable.
This is how we ended up where we are now: more or less "duplicating" the attributes (when applicable) across those three resources.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also >discussed here) also seems like an unnecessary restriction.
The Practitioner resource represents a person employed by an organization to provide care. We assumed that for one such engagement, there is one "official" (post) address for that person. The practitioner may however perform services at multiple locations (each of which can have an address).
I wanted to use drools for one of our projects - Online Buying and Selling.
Events are like Buying a book, Buying a pen, Buying a kindle.
These events are stored in a database.
Now, based on the events happened before, I want to decide the consequence.
Like say if a person had the following sequence,
1. Buy a book at a price.
2. Sell the same book at a higher price.
Then
Do something based on that.
If someone has done this,
1. Buy a kindle.
2. Purchase a book in Science Section of books.
Then
show him the relevant content in the UI.
I have all the listed things as Events in the database.
Now I have written an interface for the Actions to be done and I have also done the interface to pass a Customer when an event happens.
Now what would give me the best performance to process the events and make a decision based on the sequence of events. I cannot store all the events in memory for sure as I have a whole lot of those.
There are different aspects to consider:
For recommending additional items to customers, there are Recommendation Engines. You may want to use one of those, if most/all of Your use-cases are recommendations.
Storing "all the events in memory" is not neccessarily required. In fact, Drools removes events that are no longer relevant to the rule base. The documentation says
"Events may be automatically expired after some time in the working memory. Typically this happens when, based on the existing rules in the knowledge base, the event can no longer match and activate any rules. Although, it is possible to explicitly define when an event should expire."
To allow early removal of events, I would use Drools to generate aggregated data like "likes science topics", "owns a e-book reader", etc. Those can be inferred from the events but consume less memory.
I am trying to create a health application of a rather sensitive nature which will require some form of cryptography/obfuscation. There is a health study in which once a year, known individuals with permanent and recognisable identifier numbers (eg KIG0005001 as an individuals identifier) walk into the clinic, are identified, have their blood tested as part of a study. Next year, the same happens again, as this is a longitudinal study. Now the results of the blood test should NOT be able to be traceable to an actual individual (HIV status, etc are highly sensitive bits of information that should not be linkable with actual individuals due to their right to privacy), but it is IMPERATIVE that we can identify year on year which blood samples belong to one unique individual (without knowing WHO the individual actually is, the emphasis is on the blood samples being traceable to one individual, not the individual).
My idea (and here is where am asking for your expertise in cryptography and obfuscation) is that when the individual visits the clinic they come with an identifying card with their regular id number KIG0005001 . This number is entered into a system where via an algorithm/encryption it spits out a barcode (based on the original id KIG0005001 , therefore any future visits should produce the SAME barcode for a particular individual) which can be printed out as stickers. These barcode stickers are the ones to be used to identify the samples (stick em on the samples). The stickers should have the following information in them: unique identifier (via barcode?), the round number that the sample was taken (samples will be taken once a year, so year 1= round 1) and date sample taken.
Is this possible? What are the alternatives? How/What should I do in terms of transforming KIG0005001 into an encrypted barcode which is repeatable year on year (so blood sample can always be traced back to the same source). Am programming in Java.
Thanks in advance,
Tumaini
To answer this question, I don't think it needs to be in the barcode section.
First of all, there is no way to keep everything 100% secure... but you can make it more complicated to be understood by a human.
It's the same thing as the passport controversy... A biometric passport must be secure: it's not possible to read the information without knowing the "private key". But let's say you read and record everybody's passport that enters your store and save it to a database. You will be able to trace who is coming back and even what they previously bought since you have their passport's ID...
To make the life harder for your employees, you need to generate an ID that will match the real person's ID. So if the employee is testing the blood of KIG0005001, they will receive a different unique ID for that day; the computer will know how to link them up. So that your employee has no idea who is this number at that moment...
Cryptography is probably useless here since you work with IDs. Even a gibberish data repeated multiple time is still an ID.