Let me explain more about my question with a use case which i think more suitable for explain my thinking
Lets say i want to build a app which capture patient records at a Out Patient Ward. Where i come from we don’t have proper structured documents which capture out patient information as i know (at least i have not seen). But i assume that there could be several forms which could help to capture the information about the visit. Such as
- vital signs of the patient
- social background
and also if the patient has some specific illness or has gone through like Domestic violence then the physician might decide to do some additional documentation about it with some specific form for that.
So for the first part i see we could have a visit archetype template with relevant archetypes. But for the second part we might have a different archetype template.
So now in my hypothetical application, the physician might first document about the visit using the visit template and the additional information will be documented in another patient record using the second template. So i need to provide a way to select relevant template and document in the application UI. For that i need to load archetypes and interpret them in my application to populate the UI if i directly consume Definitions openEHR APIs. Now once the physician has entered data in the UI, the application need to transform the UI data into a Composition and use the EHR openEHR API if i plan to use them directly.
The problem i see with this approach is:
- Using Archetypes Template make the UI Application to bring down information more than what it needs when considering some meta data those templates has.
- if we need to use some kind of UI layouting or specific UI controls based on different use cases on top of the template, then the we need to build it separate and perform it on the UI application. (I saw this was implemented as a Form layer on top of templates in one of openEHR demos)
- The UI Application is totally responsible for creating the Composition structure with all relevant attributes and metadata.
- Again the structure has more data than what is needed to represent the data we captured.
So i was thinking what if we can defined
- Our own template entity or Form entity based on archetype template, so it can be configured by informaticians and application admins to looks more user friendly. May be use a more intuitive layout to make the template more presentable. Also this will only contain the essential attributes.
- Our own entity to capture the information in generic way similar to Composition structure, but not contains all the openEHR attributes, we only capture the data in the UI and some meta information about the form so we can later use that to create a Composition
So these new entities will be implemented by the OP Application Service (DDD speaking these are domain models and what we will use to communicate with client will be some DTO representation of that). And the implementation of this service/domain layer will convert these entities into openEHR models and use a CDR as the repository or infrastructure layer.
So the advantages of this approach is that,
We can add workflow support which i don’t see in openEHR spec, for example if some thing recorded by a student physician must be attested by that student and by the physician who he works with. So to do this we need to handle this workflow, so these logics can be implemented in the domain layer.
We ca support more form data on top of archetype templates, for example if a certain form allows to attach x-ray reports, then that can be defined in the form layer connected to a archetype entry. The type of capturing application and related meta data can be at the form layer, even multiple options might be in need to be configured to choose from in the UI.
Also we could have different APIs from the Application Layer based on the different applications that might be used to capture information. In a highly digital hypothetical environment, a application might offer you to enter quantifiable things into the form directly, while the physician might take digital short note in the same application, which the physician can later translate into proper documentation later by looking at the short notes. These short notes doesn’t need to go into openEHR repository since it will be discarded once the physician is done with the task.
For analytics, we could direct query the CDR using a BI tool, may be something like Power BI for example. But if there are more end user application which needs to feed some specific dashboards i would prefer the same approach as above with a BFF.
So as you can see this gives from freedom for the application developers to have more optimized DTOs and that will benefit when the application backend is hosted in cloud where there might be a certain network latency to consider.
Also you can see this type of use case is not so specific for a single archetype based data capturing.
The above use case is something i made up, looking at how my home country (Sri Lanka) hospitals works and what i see as a patient. Hope this will give you some background to my original question.
As @Seref mentioned, my thinking is also in that same description. But i wanted to make sure how others think when using openEHR and what are pros and cons in these different approaches and some practical experiences with the suggestion brought up by others in this discussions.