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.
Related
How to collect all records of the resource encounter that patients have the resource CarePlan with the status of active?
In this scenario, we have 3 resources involved, Pacient, CarePlan and Encounter.
So, in the request to the server, the objective is to obtain only the encounter data and any other data from another resource is prohibited.
Short answer - you can't - at least not with the standard search parameters. However, if you can live with getting back the Patient resource along with their encounters, you could do this:
[base]/Patient?_has:CarePlan:patient:status=active&_revinclude=CarePlan:patient
That will page through Patient and for each patient who has at least one active CarePlan will return the Patient and all associated encounters.
Note that "all encounters" is generally not going to be that desirable - some patients may have hundreds or thousands going back decades. So you might be best running it as a 2-step query - first find the patient ids, then find the encounters for those patients - filtering further to only include the encounters actually of interest.
In TS-0001chapter 12 "Information Element Recording" triggers (e.g. a request on Mcc/Mca or any other interface) are described.
In clause 12.2.2 "Filtering of Recorded Information for Offline Charging" it is described how to derive charging information from recorded information which means that charging data is being derived from IERs.
In clause 10.2.11.14, "Service Statistics collection record" is described.
There are 3 questions:
First, is there any correlation between Service Statistics Collection record and IER? It looks like Service statistics collection record is a subset of IER derived on the basis of eventConfig and statsCollect resources. If it is a subset, then there is no field in IER which maps to "collectingEntityID" as Service Statistics Collection Record are derived corresponding to "collectingEntityID".
Second, there is no description for charging data records (CDRs). It is described as subset of IER. As a result of statsCollect, Service Statistics Collection Records are generated. When will the CDRs be generated?
Third, there is no linking between Service Statistics Collection record and CDR, both needs to be transferred on Mch interface.
For your first and third questions, I understand the confusion. The Service Statistics Collection record and a M2M Event Record probably should be combined or consolidated. In fact, based on your question we will shortly bring in contributions to the oneM2M standard to make this change.
For the second question, TS-0001 clause 12.2.4 describes CDRs. This clause defines Accounting-Request and Accounting-Answer messages that flow between an IN and a billing system over Mch. Within the Accounting-Request there is an M2M Information element defined in which M2M Event Record information is stored. This is effectively the CDR. Depending on the requirements of the billing system, the charging function of the IN will filter the required information from the M2M Event Record and store this information in the M2M Information element of the Accounting-Request message for transfer to the billing system.
In addition, TS-0004 A.2 "Diameter Commands on Mch" defines how to bind the Mch Accounting-Request and Accounting-Answer messages to the Diameter protocol for deployments which use Diameter.
The MedicationDispense resource of FHIR defines the attributes related to prescription, like request, dosage, quantity etc. The prescription number, a.k.a. the RxNumber is a pretty common attribute of dispensed record in pharmacy system. I'm wondering why this is not defined in MedicationDispense schema?
There are two identifiers in the schema, the id and identifier. As mentioned in another post, the identifier should be something across systems, like SSN of a patient. Meanwhile the id is ambiguous since it could be internal database identifier or anything that could uniquely identify this dispense record.
What's the difference between id and identifier for a FHIR resource?
The MedicationDispense includes a reference to the 'authorizingPrescription' MedicationRequest. That's where all information about the prescription (identifier, prescriber, prescription date, prescribed drug, etc.) is captured. In FHIR we try hard to not combine information present in other resources into a referencing resource because doing so makes it hard to keep things in sync and doesn't work well for RESTful exchange. As a result, it's common to use the _include parameter when executing search to grab related resources (e.g. MedicationRequest, Organization, Medication, Practitioner, etc.) when searching against a base resource.
The 'id' is essentially the primary key for a resource as stored on a particular server. If you copy the resource onto a different server, that server will assign its own id/primary key. The 'identifier' on the other hand is a business identifier. For a dispense, this would typically be the "transaction" identifier that goes on the bottle/jar/box that uniquely identifies that particular dispense event. If the dispense information gets stored on multiple systems (e.g. it gets forwarded to the prescribing system, to a personal health record, to a centralized medication registry, etc.) it would have the same 'identifier' but would (usually) have a distinct 'id'. It's certainly possible for two closely linked systems to share the same 'id' for the equivalent records, but it requires careful coordination to avoid conflicts.
Note that the MedicationDispense.identifier is not the same as the MedicationRequest.identifier. The first is a unique identifier for a specific dispense event. The latter is a unique identifier for the overall order. There are often multiple MedicationDispense events (each with a distinct identifier) for a single MedicationRequest.
My very first DM so be gentle..
Modeling a hierarchy with ERD as follows:
Responses are my facts. All the advice I've seen indicates creating a single dimension (say dim_event) and denormalizing event, department and organization into that dimension:
What if I KNOW that there will be future facts/reports that rely on an Organization dimension, or a Department dimension that do not involve this particular fact?
It makes more sense to me (from the OLTP world) to create individual dimensions for the major components and attach them to the fact. That way they could be reused as conformed dimensions.
This way for any updating dimension attributes there would be one dim table; if I had everything denormalized I could have org name in several dimension tables.
--Update--
As requested:
An "event" is an email campaign designed to gather response data from a specific subset of clients. They log in and we ask them a series of questions and score the answers.
The "response" is the set of scores we generate from the event.
So an "event" record may look like this:
name: '2019 test Event'
department: 'finance'
"response" records look something like this:
event: '2019 test Event'
retScore: 2190
balScore: 19.98
If your organization and department are tightly coupled (i.e. department implies organization as well), they should be denormalized and created as a single dimension. If department & organization do not have a hierarchical relationship, they would be separate dimensions.
Your Event would likely be a dim (degenerate) and a fact. The fact would point to the various dimensions that describe the Event and would contain the measures about what happened at the Event (retScore, balScore).
A good way to identify if you're dealing with a dim or a fact is to ask "What do I know before any thing happens?" I expect you'd know which orgs & depts are available. You may even know certain types of recurring events (blood drive, annual fundraiser), which could also be a separate dimension (event type). But you wouldn't have any details about a specific event, HR Fundraiser 2019 (fact), until one is scheduled.
A dimension represents the possibilities, but a fact record indicates something actually happens. My favorite analogy for this is a restaurant menu vs a restaurant order. The items on the menu can be referenced even if they've never been ordered. The menu is the dimension, the order is the fact.
Hope this helps.
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