onset[x] is when the allergy was known/believed to have started.
Use Case 1: If a patient is allergic to bee stings, I would record onsetDateTime for the day when it actually started. Is this correct?
Use Case 2: If a patient is allergic to bee stings since he or she was 10 he/she could record the Age in onSetAge. Is this correct?
Use Case 3: onsetPeriod - Can you please provide an example on where an how will this be used?
Use Case 4: onsetRange - Can you please provide an example on where an how will this be used?
Use Case 5: onsetString - If a patient is allergic to bee stings, the patient could record it as “I have been allergic to bee stings from the age of 10”. Is this correct? But in this case the value “Bee sting” will also be provided code element as SNOMED code or just text?
I have included a lot of use cases here, but I would really appreciate if you could review and validate each of these and provide guidance.
Thank you in advance!
- Yes - though it’d be super unusual to specify a time. The DateTime would essentially be the first time the allergy was known to exist (either date of first reaction/symptoms or date when the first test occurred.
- This lets you say something like “My asthma developed sometime between 1980 and 1982”
- This lets you say something like “My asthma developed when I was 4 or 5 years old”
- The string is still just conveying the time-period. But it’s something not easily conveyed with one of the other ranges. E.g. “It was spring time, but it could have been 1952 or 56 because we were at Uncle Gerald’s farm” (though the last bit quite possibly wouldn’t be part of the record)
If you’d like to see additional clarity in the specification, feel free to submit a change request asking for additional guidance. (Use the ‘propose a change’ link at the bottom of any page in the spec.)
These examples are very helpful !
Having the information available as above, how do you identity a duplicate if a patient is recording the same allergy in at-least one of the 2 of the four ways?
Thanks in advance!
The server could choose to reject the POST and return an OperationOutcome indicating the reason why. (Not sure what you mean by “2 of the four ways”.)
What I was trying to say is -
Day 1 for a patient 1 onsetRange was provided - i.e. Asthma developed between 1980 and 1982 ()
Day 5 for the same patient onsetDateTime was provided - i.e. Asthma developed on 06/01/1980
Both the use cases will be considered as a new records on POST. The second record will not be rejected as duplicate
Nothing stops a system from allowing 2 (or 50) different Condition instances all describing the same thing. What rules a system will choose to enforce around what constitutes a create vs. what should be an update will vary. There may also need to be different records of the same “problem” to reflect the views of different sources of truth. The Linkage resource can be used to tie together multiple records that are all reflecting the same event/occurrence/issue.
Sorry couple of more things -
In an allergy resource if an allergy is deemed to have subsided - how does this recorded?
In an allergy resource if an allergy has been incorrectly diagnosed then status “entered-in-error” can be used.
subsided would correspond to clinicalStatus=resolved
incorrectly diagnosed would typically be verificationStatus=refuted.
entered-in-error would be more typically allergy was recorded against the wrong patient record. I.e. No one ever intended to say “Patient X was allergic to Y”. If someone did intend to make an assertion that “Patient X was allergic to Y” and it’s later determined that the patient definitely doesn’t have an allergy, “refuted” would be the appropriate solution.
This has been very helpful.
Thank you very much for all the guidance!