CONTEXT:
I’m working on a project to model a template in openEHR that captures the necessary data for Baby-Friendly Hospital Initiative (BFHI) certification, as outlined in the official implementation guidance (external link). Given the various requirements, including tracking breastfeeding practices, skin-to-skin contact, rooming-in, and other related clinical activities, I’m seeking advice on the most appropriate composition to use for this template.
QUESTIONS:
Which existing compositions would be best suited for capturing statistical data?
May the composition Pregnancy summary be suitable to capture this data, as the data is populated from shortly before delivery and one week after discharge?
Are there any best practices for structuring this data to align with BFHI guidelines while maintaining openEHR’s flexibility?
Is such as certificate actually a kind of report to record perinatal information? If yes, the Composition Archetype Report or its specialization (maybe still need to created) could be used to represent the certificate. The Archetype Post mortem report is a little bit similar to it.
I assume that you mean statistical data about a single patient, and not statistics about multiple people? In this context, what differentiates statistical data from other data about the patient?
I think this could definitely be a candiate, as it’s a) intended to be a summary and not data from a specific encounter or test, and b) its main component ENTRY (EVALUATION.pregnancy_summary) concerns a specific pregnancy including the antenatal period, labour, birth and the immediate postnatal period.
I don’t know enough about the BFHI to answer this, but I think the fact that both COMPOSITION.pregnancy_summary and EVALUATION.pregnancy_summary are unpublished archetypes is an opportunity for the BFHI guidelines to inform those archetypes (and possibly other adjacent ones) if someone were to run reviews and get them published
I genuinely feel reassured now that both of you have reached similar conclusions on the most suitable composition. Yes, the Report archetype could work, as it is generic enough to cover the information required by the BFHI. However, since this involves a pregnancy, I also considered the Pregnancy Summary archetype.
The challenge, though, is that using it for BFHI data might misuse its clinical context, as the information is neither an assessment nor the result of a test. The data captured concerns the mother and the newborns (or stillbirths) such that it is a mix of perinatal information, context-sensitive information of the mother and the behavior among staff, mother and newborns.
While I’m leaning towards the Pregnancy Summary, I do agree with your point about the Report archetype being a viable option. This is precisely why I decided to ask for your input—your feedback has made me feel more confident in the decision.
As for the Postmortem Report, I think it would lead to awkward discussions with stakeholders, especially since the BFHI is about capturing data on new life rather than loss. That said, I really like your idea and always welcome new approaches to thinking, as they often bring fresh perspectives to complex issues, which results in new solutions.
Regarding the BFHI requirements, it involves data collection for both mothers and newborns (or stillbirths), meaning it encompasses multiple entities. Since this data does not influence clinical outcomes or lead to changes in medical treatment, it is classified as statistical rather than clinical data. As I understand openEHR, it is primarily designed to capture clinical data within the Observation → Evaluation → Instruction → Action framework, which makes BFHI data a bit of an awkward fit in this context.
I agree, the Pregnancy Summary archetype could indeed be suitable. However, I also think the Report archetype is another strong candidate. Both could fit the BFHI context if we set aside the fact that this data doesn’t directly impact clinical decisions.
I’m with you on this point as well! Since both COMPOSITION.pregnancy_summary and EVALUATION.pregnancy_summary are unpublished archetypes, this presents an opportunity for the BFHI guidelines to influence their final design (and possibly other related archetypes) if someone were to initiate reviews and work toward their publication.
Thank you both, @siljelb and @linforest, for your thoughtful responses! I truly appreciate the time you took to share your perspectives and ideas. Your insights have been very helpful in clarifying the direction I should take. It’s reassuring to see that we’ve come to similar conclusions, and your input has certainly boosted my confidence in navigating this topic. I will discuss with my team about the best approach and inform you on the decision made.
I did dig into the BHFI document a little more and my impression was that this was very largely about hospital processes / staff training and not really about patient-level data as such. Even where patient-level data is involved, it would seem to be reported at population level e.g proportion of mothers having advice on breast -feeding.
I wonder even if it makes sense to have a specific composition to store the report, or perhaps just query into a pregnancy Summary composition captured as part of routine care, which can capture the data to go into a Certification document (population-level) but without that Certification document being in openEHR.
@linforest : Your response made sense, and I guessed that with stillbirths could be managed using Postmortem reports. So, it was a good answer. But as I am trying to fulfill the client’s requirements, who want to have a generic solution, it would probably result in awkward discussions.
@ian.mcnicoll : You are not confused, you are enlightened. Yes, that’s why I decided to ask this question. I also had a discussion with my superior about this issue, as I don’t believe that openEHR is suitable for such data that I consider statistical data. You are right, the BFHI focuses more on hospital processes and staff, but the client stated additional data requirements which I try to satisfy. Consequently, the requirements go far beyond the BFHI requirements, such that it is a mix of clinical data on mother and newborns, and administrative data on staff and settings. Overall, the collected data has no clinical relevance as it won’t influence the medical treatment nor outcome of patients, why I consider it statistical data.
But unfortunately, the client desires to do so in openEHR, and I have to make the best out of it. They prefer this data to be stored in one cohesive block, such that AQL should be avoided to coerce this data. It is also their first real project with openEHR.
From internal discussions at the company with team members, the Report composition is the most suitable one, especially as I have to fulfill the constraint to apply existing archetypes in the international CKM. But it would be a misuse, nevertheless. Personally, I would have liked to create a new composition, but this is not welcomed.
Is it possible/feasible to create an EHR-like record for a subject of record other than the patient, especially for an organization such as a hospital? If yes, it would seem the life become pretty easier.
That sounds very interesting and would actually suit the use case quite well, because the data gathered along the BFHI certification actually suits the healthcare organization’s needs and does have any clinical influence on the medical treatment of the mother.
Can you provide me with a direction, namely a document or specification, on how to set this up?
It was just a thought that flashed through my head at the time. It should theoretically be feasible, especially if existing EHR model allow its subject of record to be other types of entities other than person, such as organizations.
Thanks for your answer. Currently, we do a lot of hacks in order to fulfill requirements. And if I come across a hack how to implement your flashy idea, I ll post our approach in this thread.
I’m starting to think there might be a case for introducing a new top-level object that functions exactly like EHR (and is still the container for contributions/compositions) but is explicitly for non-human objects.
It would possibly be a bit of a messy catch-all but would be really helpful in deployments
