Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
(Reposted from Implementers' List)
As you have mentioned primarily the two things that are required for a good oncology implementation: A. Concept and B. UI
I. In the concpet front, we have added significant number of concepts for our implementation in RG Kar Hospital for Oncology and Radiation Oncology (specifically in Brachy and EBRT). We are completely in sync with MVP - that means, we don't create a concept in our dictionary instead follow the process as mentioned here - https://wiki.openmrs.org/display/docs/Getting+and+using+the+MVP-CIEL+concept+dictionary+%28link%29
( we cheated the process a little this weekend - as I needed two new concepts , Andy created those in MVP and I have created is at the same time so that the concept id remain same)
As such, if you take the latest MVP dictionary from dropbox you will get all those new concepts
In the concpet area the principal that we followed are:
A. Create coded concepts as much as possible for the nodes, diagnosis (TNM classification), Specific procedures (such as in EBRT what type of machine is used etc)
B. Used numeric values whenever applicable (such as instead of ECOG PS to be a coded, it is a numeric )
C. We have used texts concepts whenever we have found difficulty to code.
The concepts are not 100% correct and obviously not coded, but instead of waiting and completely mapping out everything we are going ahead with these concepts.
I need to do some cleansing and will the concept excel file that I have used to communicate with Andy for MVP update. Please give me couple of weeks. I will load it in the wiki in the page mentioned below
II. The next part is the UI. We have used standard HFE to create the forms. Again in this area, there are several limitations of HFEs that is causing is to not very user friendly - some of those features are :
a. Not having an anatomy drawing tool
b. Not having a file upload tag
c. Not having a dynamic repeat tag (so that you can add on number of observation instead of hardcoding)
e. Not able to repeast same obs in the same form
All the above three are GSOC project and are well underway for completing within a month or so.
But again, we haven't waited for everything to be fixed/enhanced and so we have moved forward in creating the HTML forms (again not 100% correct). Our apporach was as following:
A. Patient registration was done using core openmrs patient create process (we are also using the idgen and patient matching module - another awesome addition in the tool set)
B. Set 1 Forms (approx 3) - Complaint, History, Family History and General examination (mostly coded)
C. Set 2 Forms - Examination by body parts (coded and text mixed)
D. Set 3 forms - Imaging and Reports (mostly text)
E. Treatment plan (includes tumor board recommendation - an internal board of physicians) & Final diagnosis - text & coded
I will publish all these forms in the wiki in few weeks. I am just too swamped in the actual go-live.
III. And another thing that is very important, for a full end to end EMR , specifically for oncology implementation is a Patient Portal where the patient's journal/journey can be maintained by the patient and patient can communicate with the doctor. In that area, the PHR module developed by Hui Xiao for lance armstrong foundation is a great module. As part of the GSOC project, that is also getting improved and hopefully we will be able to use that.
The attached diagram shows the oncology work flow, specifically the radiation oncology work flow. The numbers indicate the sequence. Note that on the first time around the cycle, when you reach the Follow up position, the patient is repeatedly reviewed until a recurrence is discovered. At that stage the second cycle begins. This work pattern matches the knowledge structure pattern.
Inherent in this pattern is the notion that all treatments are linked to a specific diagnosis and stage. Professionally, this is the consistent worldwide pattern - first establish the diagnosis and then the stage, then use the knowledge gleened from the literature and experience to specify the treatments to be applied. After the treatments have been completed, then assess the outcome. If the disease returns, the diagnosis remains unchanged, but the staging needs to be repeated and the new treatment decisions made.
For other treatments there are differences at step 3. For surgery the preparation is anaesthesia, for chemotherapy/immunotherapy/hormone therapy, the preparation is pharmacy.
I have been rummaging around the system having installed the standalone version with MVP-CIEL installed. I have been looking at concepts and find things I don't understand.
I don't understand the need to generate single overlap entries. Surely an association of HIV (ID-884) with a later diagnosis of lung cancer means exactly the same thing? In oncological medicine, if there is a "Personal History of Malignant Neoplasm of Lung", the patient's record should have a discrete diagnosis and definition of previous treatment, rather than the composite entry.
I shall continue looking, but as a clinician, in order to fit my concept categories to match those here, the logic needs to explained.
I haven't loaded the dictionary lately, but I suspect that the concepts mapped to ICD10:C34.1 are all "narrower than" ICD10:C34.1. The idea of a map type (contained in the comments pre-1.9, expressed explicitly in 1.9) allows non-synonymous relationships.
With respect to Personal History and Family History, there is quite an effort made to distinguish between observations and history, and in the case of history, between patient history and family history. There are differences of opinion as to whether these should be kept as booleans or as list members, but for reporting purposes, a diagnosis of HIV is different than a patient-reported history of HIV is different than a family history of HIV.
With respect to your HIV Staging question, these are a set of conditions used for HIV Staging and many systems have a way of staging automatically based on the staging questions. The questions themselves may not be at an appropriate level of specificity for a physician treating the condition, but are part of the WHO staging criteria. Since much of our work is in low-resource settings, I think you are likely to find a number of concepts used for syndromic diagnosis of diseases that in high-resource settings would be diagnosed through testing.
You touch on some of my issues quite well.
My final concern is the way that concepts are produced. As I see it, there are two types of concepts - concepts of single entities and concepts of groups of entities ('group concepts'). The single concepts are made first, and then a new concept can be made which specifies multiple simpler concepts within a grouping.
If this is correct, I can see that these 'group concepts' make reports and displaying data very quick and easy since they are indexed. They cause a problem though. For any cancer patient to be placed in a discrete oncological group, a number of specifications need to be included. The minimum specification includes an ANATOMIC SITE, a HISTOPATHOLOGICAL TYPE and a STAGE. It should be noted that this does not include mandatory BIOLOGICAL and PROGNOSTIC FEATURES (receptors), or more detailed formalised staging (TNM). You can see below the example of breast cancer that I have extracted from the NCI's PDQ showing the various permutations of each of these specifications. Now I am unsure it I am able to add each item individually and have them linked or whether I have to specify a group concept that uniquely describes each group.
So, can I have 'C50.0', 'carcinomaNOS', and '0' separate but linked? (if yes, how do you do this?) Or do I need to have a group concept called 'C50.0_carcinomaNOS_0' (which means I need to do a lot of work on generating concepts - is there a mechanism for generating these and then importing them via a CSV file?
C50.0 Nipple and areola
C50.1 Central portion of breast
Ductal Carcinoma in situ
Invasive Ductal Carcinoma with predominant intraductal component
Invasive Ductal Carcinoma, NOS
Medullary Carcinoma with lymphocytic infiltrate
Mucinous Carcinoma (colloid)
C50.2 Upper-inner quadrant of breast
Lobular Carcinoma In situ
Invasive Lobular Carcinoma with predominant in situ component
Invasive Lobular Carcinoma
Mixed Invasive Lobular and Ductal Carcinoma
C50.3 Lower-inner quadrant of breast
Paget disease of the Nipple, NOS
Paget disease of the Nipple with intraductal carcinoma
Paget disease of the Nipple with invasive ductal carcinoma
C50.4 Upper-outer quadrant of breast
C50.5 Lower-outer quadrant of breast
C50.6 Axillary tail of breast
C50.8 Overlapping lesion of breast
C50.9 Breast, unspecified
NB: For the TNM classification which is commonly used, there are clinical AND pathological classifications:
c&pT 18 options
cN 10 options
pN 18 options
M 3 options
This appears to mean I might need to produce 2376 'group concepts' without TNM.
Adding info from implementers list. See attachment SPR and ICCR Summary.pdf
I have attached a background summary of our local structured pathology reporting project and how it has branched into an international collaboration.
It is in the context of the International Collaboration which is working on developing cancer datasets for pathology reporting of cancer that David spoke to Graham who mentioned OpenMRS. In the longer term we are hoping the Collaboration can facilitate implementation of the cancer datasets in the less developed parts of the world with a simple electronic form type of application. We are a long way off from doing this and basically in the fact finding stage so hence our interest in what you have been doing with OpenMRS. We are after general information about the tool and why you chose it.
Best regards Meagan
The two contact persons so far have been Graeme Green firstname.lastname@example.org and Meagan Judge email@example.com
Is the structured pathology reporting being based on an ontology of pathology reporting, or just an ad hoc put together of items?
So is there anyone out there doing Oncology Implementation? Is it possible to get/see what the GUI looks like?
Anyone working on an Ontology>Concepts generator? Or Archetypes>Concepts generator?
Feedback on this page? Questions?
Visit OpenMRS Talk, our community discussion hub.
Text is available under the Creative Commons 4.0 International Attribution License (CC BY 4.0).
Software is available under the Mozilla Public License 2.0 with Healthcare Disclaimer (MPL 2.0 HD).
"OpenMRS" is a registered trademark and the OpenMRS graphic logo is a trademark of OpenMRS Inc.
Powered by a free Atlassian Confluence Open Source Project License granted to OpenMRS. Evaluate Confluence today.