Stream: CCDA / FHIR mapping stream
Topic: EHR Mapping to FHIR
Roney A (Jun 06 2019 at 17:28):
Hi Lloyd, how do we address race and ethnicity of the patient in FHIR? Do we use an extension? Also, FHIR, has the concept of logical identifiers. How can we handle those in our EHR use case? Each source system may have different Patient ID's?
Jean Duteau (Jun 06 2019 at 17:28):
Yes, race and ethnicity are handled via extensions. If you look at US-Core, they have some extensions for both of those.
Lloyd McKenzie (Jun 06 2019 at 17:43):
On Patient, you should capture whatever identifiers you know - MRNs, insurance identifiers, SSN, whatever you have that is known to uniquely identify that particular Patient. Other systems will obviously have different identifier collections. To interoperate, you should ideally have at least one identifier in common, though you can use demographic-based searches and matching in cases where that's not possible.
Roney A (Jun 06 2019 at 20:39):
Yes, race and ethnicity are handled via extensions. If you look at US-Core, they have some extensions for both of those.
Thank you Jean.
Roney A (Jun 06 2019 at 20:39):
On Patient, you should capture whatever identifiers you know - MRNs, insurance identifiers, SSN, whatever you have that is known to uniquely identify that particular Patient. Other systems will obviously have different identifier collections. To interoperate, you should ideally have at least one identifier in common, though you can use demographic-based searches and matching in cases where that's not possible.
Thank you Lloyd.
Roney A (Jun 07 2019 at 16:27):
Hi Lloyd, how do we address EHR fields that could not be mapped and/or matched to FHIR resources or elements? Do we create extensions (resource or element) for ALL? For example, "Attribution table" has some 12 columns, including attribution code. How can we accommodate the 12 columns / elements in the current resource "FHIR Extension Attribution Code" ? Do we create a new resource extension "Attribution" and add 12 elements to accommodate the 12 EHR Attribution columns or add the 12 columns to the current resource "FHIR Extension Attribution Code? We also have another "Attachment table" with that many columns? What's the best FHIR approach?
Lloyd McKenzie (Jun 07 2019 at 16:33):
The general recommendation is:
1. Decide if there's any reason to share the elements at all? (Not everything that's in your EHR repository is necessarily going to be useful to downstream systems
2. Look carefully at the definitions in the core spec (not just the names) as well as the list of common extensions in the core spec as well as extensions in any potentially relevant implementation guides (C-CDA, US Core/AU Core/CA Core/IHE profiles/etc.)
3. If you can't find an appropriate home, raise separate questions for each element/interlinked group of elements on chat.fhir.org. The community may identify an appropriate location/convention you've missed (e.g. using Observation, using an extension with a broader purpose/different name that caused you to not recognize it, etc.) Alternatively, they may encourage you to submit a change request that will result in a standard extension being defined
4. If the consensus is "you'll need an extension and it's not sufficiently general purpose to define a 'standard' extension", then do that. Try to define the extension in a generic enough manner that other systems could use it too. The more systems that use the extension, the more systems will recognize it - which is your objective.
Roney A (Jun 07 2019 at 16:38):
The general recommendation is:
1. Decide if there's any reason to share the elements at all? (Not everything that's in your EHR repository is necessarily going to be useful to downstream systems
2. Look carefully at the definitions in the core spec (not just the names) as well as the list of common extensions in the core spec as well as extensions in any potentially relevant implementation guides (C-CDA, US Core/AU Core/CA Core/IHE profiles/etc.)
3. If you can't find an appropriate home, raise separate questions for each element/interlinked group of elements on chat.fhir.org. The community may identify an appropriate location/convention you've missed (e.g. using Observation, using an extension with a broader purpose/different name that caused you to not recognize it, etc.) Alternatively, they may encourage you to submit a change request that will result in a standard extension being defined
4. If the consensus is "you'll need an extension and it's not sufficiently general purpose to define a 'standard' extension", then do that. Try to define the extension in a generic enough manner that other systems could use it too. The more systems that use the extension, the more systems will recognize it - which is your objective.
Thank you Lloyd.
In other words, if the there is a general consensus, we can then add new standard element(s) to an existing 'FHIR resource', as well add a new resource, such as 'attribution' or 'attachment' and add all the agreed upon elements to the appropriate resources?
Lloyd McKenzie (Jun 07 2019 at 17:33):
Only HL7 can add things to a resource - and then it will only take effect in the next version of FHIR. For everything else, the only solution is extensions. (A single version of FHIR has a single set of schemas that all FHIR-compliant instances must align with wherever they are in the world. Letting implementers add their own elements would totally break that.
Roney A (Jun 07 2019 at 18:07):
Only HL7 can add things to a resource - and then it will only take effect in the next version of FHIR. For everything else, the only solution is extensions. (A single version of FHIR has a single set of schemas that all FHIR-compliant instances must align with wherever they are in the world. Letting implementers add their own elements would totally break that.
Thank you Lloyd. That makes sense.
Roney A (Jun 10 2019 at 20:46):
On Patient, you should capture whatever identifiers you know - MRNs, insurance identifiers, SSN, whatever you have that is known to uniquely identify that particular Patient. Other systems will obviously have different identifier collections. To interoperate, you should ideally have at least one identifier in common, though you can use demographic-based searches and matching in cases where that's not possible.
Hi Lloyd, Is the logical ID (https://www.hl7.org/fhir/resource.html) of the resource randomly generated on the FHIR server and if it is dynamic? Will all the changes (history), will be made and maintained at the business "identifier" level? Or, do we need to maintain changes by resource 'id' at the Resource.meta.versionId when the resource is created, updated, or deleted for the business identifier?
Lloyd McKenzie (Jun 10 2019 at 20:55):
The logical id is like a primary key. It's generally determined by the FHIR server. It could be random, sequential, or be generated by some other algorithm. Some servers may allow clients to actually assign the key (using PUT rather than POST). However, if that happens, the server would need to trust the clients to not create colliding identifiers.
Once assigned, the expectation is that ids will be consistent. If you query today and you query 2 months from now, the id should be the same. History is tracked on each server at the 'id' level. Each time a resource with a given id changes, the versionId and lastUpdated elements should change.
Roney A (Jun 10 2019 at 22:00):
The logical id is like a primary key. It's generally determined by the FHIR server. It could be random, sequential, or be generated by some other algorithm. Some servers may allow clients to actually assign the key (using PUT rather than POST). However, if that happens, the server would need to trust the clients to not create colliding identifiers.
Once assigned, the expectation is that ids will be consistent. If you query today and you query 2 months from now, the id should be the same. History is tracked on each server at the 'id' level. Each time a resource with a given id changes, the versionId and lastUpdated elements should change.
Thank you Lloyd.
Roney A (Jun 10 2019 at 22:17):
The logical id is like a primary key. It's generally determined by the FHIR server. It could be random, sequential, or be generated by some other algorithm. Some servers may allow clients to actually assign the key (using PUT rather than POST). However, if that happens, the server would need to trust the clients to not create colliding identifiers.
Once assigned, the expectation is that ids will be consistent. If you query today and you query 2 months from now, the id should be the same. History is tracked on each server at the 'id' level. Each time a resource with a given id changes, the versionId and lastUpdated elements should change.
Thank you Lloyd.
Question arises: How do we handle, map, relate, match, merge, or associate business "identifier" for each resource, (for example: Patient.identifier, MRNs, insurance identifiers, SSN, etc.) with the "logical id" for each resource, that being the primary key?
Lloyd McKenzie (Jun 11 2019 at 01:28):
Just put the identifier on the Patient, Observation, etc. Each resource instance might have multiple business identifiers. (In some cases, multiple records may share the same business identifiers (e.g. multiple PractitionerRole instances might share the same national provider identifier)
Roney A (Jun 11 2019 at 14:51):
Just put the identifier on the Patient, Observation, etc. Each resource instance might have multiple business identifiers. (In some cases, multiple records may share the same business identifiers (e.g. multiple PractitionerRole instances might share the same national provider identifier)
Thank you Lloyd. Agreed. Need clarity on how we relate all these identifiers (Patient.identifier, Type: Identifier) with the "logical id" (Resource.id, Type:id) of the resource which is like a primary key?
Lloyd McKenzie (Jun 11 2019 at 15:42):
The relationship is that the record with the id (key) includes the identifiers.
Roney A (Jun 11 2019 at 18:27):
The relationship is that the record with the id (key) includes the identifiers.
Thank you Lloyd. That makes sense, id (key) is like the surrogate key.
Roney A (Jun 12 2019 at 17:24):
Hi Lloyd–{FHIR Constraints, and/or limitations] Could you please clarify the following:
1. Claim header– may have several columns: servicing provider, admitting provider, attending provider, referencing provider, other_provider, etc. FHIR "Claim.provider" seems to be the relevant field. Issue: the cardinality of the field (Claim.provider) is 1..1. How to map several type of providers in a single Claim resource. The constraint 1:1 limits referring to a single provider.
2. Lab result– using multiple columns: value (a value 'String'), numeric value, observation unit. FHIR Observation.value[x] seems to be the relevant field. Issue: the cardinality is 0..1. Either numeric or string value could be represented. We need both fields for aggregations, etc.
3. Diagnosis–For Diagnosis, the corresponding FHIR resource is "Condition"–may have several columns: claim id, claim line id under Diagnosis/Condition. Issue: There is no mapping for claim id, claim line id in 'Condition' resource for Claim.
Lloyd McKenzie (Jun 12 2019 at 17:51):
@Roney A 1. The Claim.provider indicates who's submitting the claim. Additional providers would be part of the careTeam and/or referenced on resources you're claiming for (e.g. encounter)
2. Can you expand on this?
3. Each Claim item can point to a particular diagnosis using diagnosisSequence. So first you list all diagnoses that are relevant to any of the items. Then each item points to the diagnosis(es) that are relevant for that item.
Roney A (Jun 12 2019 at 20:38):
Roney A 1. The Claim.provider indicates who's submitting the claim. Additional providers would be part of the careTeam and/or referenced on resources you're claiming for (e.g. encounter)
2. Can you expand on this?
3. Each Claim item can point to a particular diagnosis using diagnosisSequence. So first you list all diagnoses that are relevant to any of the items. Then each item points to the diagnosis(es) that are relevant for that item.
Thank you Lloyd.
Explanation on 2) above. Lab result 'value' column comes in different format for different types. Lab result value column will store the results as 'string'. Lab result 'numeric value' column also comes in different format for different types, although it stores only the numeric/float values in order to perform basic functions like avg, sum, other aggregations, etc. Both columns are required.
The FHIR "Observation.value[x]" cardinality is 0..1. restricts Observation.value[x] "FHIR Comments...An observation may have; 1) a single value here, ..."
**Unless, we use, FHIR Comments: for "both a value and a set of related or component values,... in Observation.component (0..) by Observation.component.code (1:1), by Observation.component.value[x] (0..1) to identify different lab results format to store the result for data aggregation.
Lloyd McKenzie (Jun 12 2019 at 21:12):
I'm still not understanding where you'd have both a string and an encoded result. If you have an encoded value that says "5" "mg", what's the need for a string that says "5 mg" as well?
Roney A (Jun 13 2019 at 16:13):
I'm still not understanding where you'd have both a string and an encoded result. If you have an encoded value that says "5" "mg", what's the need for a string that says "5 mg" as well?
Thank you Lloyd. Yes, we get separate values from source for both the columns. For example: value = 'Negative' and numeric_value = 17.5. In other words, the need to store both the values separately in FHIR Observation resource is required.
Lloyd McKenzie (Jun 13 2019 at 16:25):
Negative would be an interpretation, not a value.
Lloyd McKenzie (Jun 13 2019 at 16:26):
(And thus go in Observation.interpretation)
Roney A (Jun 13 2019 at 17:09):
Negative would be an interpretation, not a value.
Thank you Lloyd. It makes sense.
Roney A (Jun 13 2019 at 18:24):
(And thus go in Observation.interpretation)
Hi Lloyd, The only issue using 'Observation.interpretation' is that it is a normalcy flag–a categorical assessment to determine if the lab result value was low, high or normal.
This coded representation is not for the actual numeric_value = 17.5. In this case "Negative" is the coded representation. Other example, for value column, 'Glucose' and for column numeric_value = 65.90
Lloyd McKenzie (Jun 13 2019 at 18:26):
Glucose would be the Observation.code, not the Observation.value. Observation.interpretation can convey normalcy, positive vs. negative, change and a few other things (that's why it's 0..*).
Roney A (Jun 14 2019 at 18:07):
Glucose would be the Observation.code, not the Observation.value. Observation.interpretation can convey normalcy, positive vs. negative, change and a few other things (that's why it's 0..*).
Thank you Lloyd. I see a workaround to address other definition as well.
Last updated: Apr 12 2022 at 19:14 UTC
