Identifying specific types of Observations for representation using FHIR

24 views
Skip to first unread message

Suranga Kasthurirathne

unread,
Mar 19, 2015, 5:59:37 PM3/19/15
to d...@openmrs.org

Hi everyone,

I'm hoping to obtain some input on how the FHIR module should identify 'specialized' versions of observations. In this instance i’m using a specific scenario (the modeling of allergies), but note that the lessons learnt here can inform how we manage other specific types of obs, such as diagnosis, procedures, conditions etc.

Lets assume that we have a patient with allergy information - in the pre allergyUI module days, this information would have been persisted as an OpenMRS observation.

Lets assume the following scenarios, and how we can use FHIR to export this information.

Scenario one: OpenMRS implementation stores allergies using the allergyUI module and allergy specific tables.
User wants to obtain all allergies for a given patient.
He does so by making specific requests that return FHIR allergyIntolerance resources from the allergy table. No problems

Scenario two: OpenMRS implementation has allergies stored as generic observations AND using the allergyUI table.
Once again, the user wants to obtain all allergies for a given patient.
Now we need to return allergy intolerance resources based on the generic obs table and the allergy table. In such a case. What is the best approach to identify which obs are allergies? would this be done via concept class?




--
Best Regards,
Suranga

Darius Jazayeri

unread,
Mar 19, 2015, 6:12:43 PM3/19/15
to dev
Suranga,

I would suggest that trying to merge both those things together is misguided, and an implementation should be using one method or the other but not both. If they used to use obs, but then started using the new allergy modules, it should be the implementation's job to migrate their data, not OpenMRS's job to forever be merging those things together.

But your question is equivalent and meaningful without the "AND using the allergyUI table" bit...

I suggest using the Strategy pattern, so the implementation configures which strategy the FHIR module should use to select their allergies.

As out-of-the-box-included patterns I would suggest one that uses the allergyapi module, and a second that selects observations based on having obs.concept equal to the value of a global property like "concept.allergicTo".

(I quickly searched CIEL and did not find a set construct that represents allergies, so I guess our out-of-the-box example can just support a simple obs like "Patient Allergic To" = "Sulfa", rather than a structured obs group.)

You definitely don't want to do it based on concept class. The class of the value of an obs tells you nothing about the meaning. E.g. you don't know if obs.concept is "what is the patient allergic to" or "what allergies have we ruled out". :-)

-Darius

PS- Don't forget that the core API has actually had allergies in it since 1.7, though that implementation will go away soon, so you might also want to consider that option.

--
OpenMRS Developers: http://om.rs/dev
Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
Manage your OpenMRS subscriptions: http://om.rs/id
 
Visit OpenMRS Talk at http://om.rs/talk for chat and discussions!

Suranga Kasthurirathne

unread,
Mar 20, 2015, 2:57:49 PM3/20/15
to d...@openmrs.org

Thank you Darius,

Now there's a coincidence, we plan to be using the strategy plan! in fact, we've already done some work around it.

And your recommendation is to identify allergies via concept id's specified using a global property. I too searched through CIEL, but didn't find anything that represents an allergy.

I wonder if Dr. Kanter can comment on the suitability of this approach? would like to hear if he endorses what we're about to do :-)

PS: Yeah, and thank you for setting me straight on the use of concept class :-)



On Fri, Mar 20, 2015 at 11:25 AM, Suranga Kasthurirathne <suran...@gmail.com> wrote:
Thank you Darius,


Now there's a coincidence, we plan to be using the strategy plan! in fact, we've already done some work around it.

And your recommendation is to identify allergies via concept id's specified using a global property. I too searched through CIEL, but didn't find anything that represents an allergy.

I wonder if Dr. Kanter can comment on the suitability of this approach? would like to hear if he endorses what we're about to do :-)

PS: Yeah, and thank you for setting me straight on the use of concept class :-)

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@openmrs.org.



--
Best Regards,
Suranga



--
Best Regards,
Suranga

Andrew Kanter

unread,
Mar 20, 2015, 9:43:52 PM3/20/15
to d...@openmrs.org
Allergy list is CIEL code 160647
 
--------------------
Andrew S. Kanter, MD MPH FACMI

Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University
Email: andrew...@dbmi.columbia.edu
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter

Suranga Kasthurirathne

unread,
Mar 20, 2015, 10:44:14 PM3/20/15
to d...@openmrs.org

Thank you, so basically, I guess that the 'default' value that we assign to the "concept.allergicTo" property would be the CIEL Concept 160647.
By default, any observation with CIEL code 160647 will be eligible to be returned as an allergyintolerance resource.

 If someone is not using the CIEL dictionary, then they will need to go in and change this property.




Reply all
Reply to author
Forward
0 new messages