The Program resource in OpenMRS is designed to track patients in a treatment program or study protocol, where patients are typically enrolled and then may travel through different states until they either complete the program, are transferred out, or lost to follow up. FHIR’s Condition resource, on the other hand, are designed to track problems in a patient’s problem list. Therefore, I do not think PatientState (a state within a treatment program or study protocol) would map to FHIR’s Condition. I would think our Program would map more closely to FHIR’s Protocol, which I believe has been subsumed into PlanDefinition. From my understanding FHIR’s PlanDefinition is used to define protocols (like our treatment programs), which would presumably include the metadata of available states. In FHIR, the actual data about progress of a specific patient through a PlanDefinition is recorded in CarePlan and associated resources. So, presumably, our PatientState (which is data about a patient’s current status in a “protocol”) would map somewhere close to CarePlan, Activity, or Detail. @jteich has put a lot of thought into care plans in OpenMRS, so may have insights. My impression is that this may not map neatly to FHIR and the CarePlan resources are relatively immature in FHIR, so it may not be worth the effort to map to FHIR at this time.
You are correct that OpenMRS’ Form would map to FHIR’s Questionnaire; however, there are some significant differences in the use of these resources at this time that might cause problems. @darius and I discussed this on today’s design forum. FHIR’s Questionnaire and QuestionnaireResponse resources are designed primarily to capture any data from a patient. In OpenMRS, the primary use of forms is for encounter forms, where the majority of the data collected are discrete, clinical data (i.e., Observations). So, we need a way to define our forms as FHIR questionnaires where the items are answered with an observation. The list of possible types for Questionnaire→Item.type doesn’t seem to include observation as an option. @darius’ suggestion was to not try to map forms to FHIR right now (just use our REST representation)… he may be right. It’s close; however, I don’t think a model where all responses to forms are expected to be QuestionnaireResponses (instead of Observations) will work well for us.