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.
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.
I am trying to convert customized data format into FHIR standard. In my example, we have a practitioner (physician) with certain unique id defined by hospital. This unique id is hospital specific, not like NPI or SSN.
My approach is to use identifier element in Practitioner resource where it has system and code. For NPI or SSN, I can add value as is and set identifier.system to associated url. However, for unique id, I am not sure how to define it besides setting value to unique id. Is it possible to create url (system) that meets whatever I need?
The rules for system are here. If you are setting up a FHIR server, then you can define the system that client systems should use for that type of identifier. If you are trying to pass this data to a FHIR server owned/governed by someone else, you would need to understand if that FHIR server can accept values with any system or if there are prescribed ones that are accepted.
I am trying to update Encounter resource on the basis of patient id but it is only creating one new record of Encounter rather than updating the existing one. But if i try to update Encounter on the basis of identifier i.e. unique value representing Encounter resource then it is able to update it.
Why is that? Can anyone explain?
One patient will potentially have many (even hundreds) of encounters. Updates are always driven by the record of the resource itself - every resource (Patient, Encounter, Observation, CarePlan, etc.) has an 'id' element that represents the identifier of that resource on that particular server - sort of like a primary key. Updates are performed by making a RESTful PUT of the new record to a URL that includes that same identifier.
I.e. an update of an Encounter MUST always be performed with a URL of the form:
PUT [somebaseurl]/Encounter/[serverEncounterId]
The patient associated with the encounter will be referenced from within the Encounter object in the body of the RESTful call, but does not appear in the URL.
As you have discovered, some FHIR servers will allow a 'conditional update':
PUT [somebaseurl]/Encounter?search_key=search_value&...
You will need to add search parameters that filter all Encounters and result in a unique one, which will then be updated. Since, as Lloyd also indicated, a Patient can have multiple associated Encounters, the Patient id is not a suitable parameter for the conditional update. Your Encounter's identifier was unique enough, so that update succeeded.
I've just figured out a big mistake I had while creating the dynamodb structure.
I've created 11 tables, whereas one of them is the table mostly refereed to and the others are complementary tables.
For example, I have a table where I hold names (together with other info) called "Names" and another table called "NamesMappings" holding all these names added to the "Names" table so that each time a user wants to add a name to the "Names" table he first tries to put the name in "NamesMappings" and only if it succeed (therefore this name doesn't exist) he can add the name into the "Names" table. This procedure helps if the name is not unique and is not the primary key in the "Names" table and with this technique I don't have to search inside the "Names" table if the name exists, but instead I can try to add it to the "NamesMappings" table and only if it succeed I know this is a unique name.
First of all, I would like to ask you if this is a common approach or there is a better one?
Next, I figured out that with this design I soon reached to 11 tables each has 5 provisioned capacity of read and write which leads to overall 55 provisioned read and write under the free-tier. Then I understood why I get all these payments each month, because as the number of tables is getting bigger, and I leave the provisioned capacity as default (both read/write capacity are 5) I get more and more provisioned capacity.
So, what should be my conclusion from this understanding? Should I try to reduce the number of tables even if it takes more effort to preform scanning and querying inside the table? Or should I split the table same as I do but reduce the capacity of these mappings tables used only for indication if an item exists or not in another table?
If I understand your problem correctly you're missing the whole concept of NoSQL Databases.
Your Names table should have a Hash key (which is similar to a Primary key) that has a uniformly generated identifier (an UUID is a great candidate). This would automatically make this Table queryable by this unique identifier. You said, however, that you don't know the ID but you only know the Name instead. This leads me to think you could create a Global Secondary Index (GSI) on the Name attribute inside the Names table so you can also query by Name. Up to this point, your table structure should look like this:
id | name
Both of them are independently queryable, which gives you a lot of flexibility already.
Now, let's say you want to add the NameMapping attribute (which I don't know how it looks like), you can simply add it under the Names table, getting rid of the NamesMappings table, greatly reducing the number of WCUs and RCUs across your account. Your table structure should now look like this:
id | name | mappings
where mappings is, let's say, a JSON object.
Since you can only query on top level attributes in DynamoDB, you can now perform a query against the name attribute which has a GSI configured. If the query returns nothing, then name is unique. But let's say you still need some data inside the mappings object, then you could query by name and, in your code, you could apply a map/filter/reduce operation on the mappings attribute and decide what to do next.
Remember that duplication is just OK in a NoSQL world. This may look scary if you come from a purely SQL background, but data should be stored in such a way in NoSQL databases that you should be able to fetch all the needed information in one go, therefore avoiding "joins" (joins are still possible in a NoSQL database, but since there are no strong relationships between entities, you need to perform these joins manually on the code level). To give you some real context, imagine you have a Orders table where you keep track of the ordered Products and the Store that the Order belongs to: you'd save both the Products and the Store objects (and not their IDs, as it would happen in the SQL way) inside the Order object, so if you want to query for a given OrderId in the future, you wouldn't need to make extra calls (aka "joins") to the Product/Store tables to fetch the information, since everything would already be stored inside the Order object.
I'm reading the book "Architecting Applications for the Enterpise (Dino Esposito)". It raised a question about validation.
The Domain Model can have a property CanBeSaved which calls the Validate() method of the Domain Model. All good, except for complex situations.
For example a Customer model which needs a unique customer code (ex. 000542). You can only check this with database access. Isn't it better to put the Validation always in a Domain Service. So you have only one way of checking if an aggregate is in a valid state? If you use both, a developer can 'forget' to use the domain service validation for the Customer.
I find it better to have always valid entities rather than rely on an external validation object.
That being said, unique checks are a bit of an exception since it is often not something that the aggregate itself can determine on its own, you have to look into all existing aggregates to see if the value is not already taken. What I do is check for availability of the value before creating the entity, and also put a constraint in the database which will verify uniqueness at persistence time. You could also try to find a domain concept that encompasses all your entities and make it an aggregate that has a list of all codes and enforces the uniqueness invariant.