I'm reviewing the current version of the specs and remembered an issue we had in the past about this (check the bold text)
8.2.5.7. Relationship to Archetypes Much of the semantics of particular Instructions and Actions derive from archetypes. Currently, archetypes are used to define two groups of Instruction semantics. The first is the descriptions of activities that are defined in Instructions (ACTIVITY.description) and executed in Actions (ACTION.description). These descriptions are always of the same form for any given Instruction, and it is highly desirable to have the same archetype component for both. An example is where the description is of a medication, commonly consisting of a tree or list of ten or more elements describing the drug, its name, form, dose, route and so on. ref: http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_careflow_process_to_state_machine_mapping 1. I mentioned in other thread that current specs about INSTRUCTIONS are too focused on medication cases, but not on treatments, non-drug therapies, procedures, etc. I would suggest to add more examples to the spec that are not related with medication, and ask the collaboration of the clinical colleagues on that area. I'm sure you can come up with very good examples we can include on the specifications. 2. On those non-medication related cases of INSTRUCTION/ACTIVITY and ACTION modelling I'm not sure if this is true "These descriptions are always of the same form for any given Instruction". This is a very hard assessment that doesn't leave much modelling options. I as an informatician can come up with some examples where that is not true, and I'm sure clinical people can have better examples: a. For physiotherapy: I had 10 sessions of laser treatment ordered by my physiatrist. This is scheduled as an administrative process. On each session, the physiotherapist needs to complete a form marking each ordered service as "done" and sign. After the last session, the order (instruction) is completed and that can be done automatically, because the start and end date are established on the schedule. On this case, the records (ACTION) created on each session have different structure as the ones on the order, the only dependency from the ACTION to the ACTIVITY, is to the ID of the specific ACTIVITY. The ACTION's descriptions don't need to have the same structure as the ACTIVITY description. b. Hemodialysis: I have worked on this area some time ago, patients are ordered hemodialysis as a long term treatment in some cases, or while waiting for a kidney transplant on other cases. The order is the treatment, The record of each session has a very strict protocol and every detail of it is recorded. That has a very specific structure that would be modelled as a whole COMPOSITION, but include an ACTION to represent a treatment executed for a medical order. I would say 99% of the documentation of the hemodialysis session will be on OBSERVATIONS, EVALUATIONS and ADMIN_ENTRY, and the ACTION would be just a log of the sessions occurrence, saving the relationship to the INSTRUCTION/ACTIVITY that ordered the treatment. Again I don't see that ACTION description to be equal in structure to the ACTIVITY description or the order for the treatment. c. Surgical procedure: a traumatologist surgeon ordered an arthroscopic knee surgery to fix my meniscus. The INSTRUCTION included the procedure to be executed, and some indications for me. The procedure record was a complete COMPOSITION with all the details, and as in previous cases, the ACTIONs were related to the indication of "in progress" and later "completed" procedure. I also don't see the structures of ACTIVITY.description and ACTION.description match on this case. Sorry for the long email, but this has been a long term issue for me. Please let me know if something of this makes sense, or not :) If it does, I would propose to relax the specs descriptions a little and add non medication related examples. Clinical modellers input would be more than welcome! -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
