OpenEHR Implementation Guide: Towards Standard Low-Code Healthcare Systems.

Several open source components have been made available in recent years to help develop full openEHR systems. Still doubts exist if these are sufficient. This paper presents a case study of implementing a low-code openEHR system, investigating the feasibility and challenges of developing a system using these components for each step. The method used consisted in selecting successful examples of implementation case studies, identifying key development steps, and for each step searching for possible open source options. As a result, we had a working low-code openEHR powered EHR, successfully demonstrating the feasibility of the proposed implementation guide. The main available free or open source components used were ArchetypeDesigner and EHRbase, developed by Better and Vita/HighMed respectively. In our opinion, it is possible to build EHR systems using the available open source components, but support is still missing in the front end, specifically for form generation and screen representation.

Nutrition Information in Oncology - Extending the Electronic Patient-Record Data Set.

Electronic health records (EHRs) present extensive patient information and may be used as a tool to improve health care. However, the oncology context presents a complex content that increases the difficulties of EHR application. This study aimed at developing openEHR-archetypes representing clinical concepts in cancer nutrition-care, as well as to develop an openEHR-template including the aforementioned archetypes. The study involved the following stages: 1) a thorough literature review, followed by an expert's (nutrition guideline authors) survey, aiming to identify the main statements of published clinical guidelines on nutrition in cancer patients that were not included on the Clinical Knowledge Manager (CKM) repository; 2) modelling of the archetypes using the Ocean Archetype Software and submission to the CKM repository; 3) creating an example template with Template Designer; and 4) automatic conversion of the openEHR-template into a readily usable EHR using VCIntegrator. The clinical concepts (among 17 clinical concepts not yet available in the CKM repository) chosen for further development were: body composition, diet plan, dietary nutrients, dietary supplements, dietary intake assessment, and Malnutrition Screening Tool (MST). So far, four archetypes were accepted for review in the CKM repository and a template was created and converted into an EHR. This study designed new openEHR-archetypes for nutrition management in cancer patients. These archetypes can be included in EHR. Future studies are needed to assess their applicability in other areas and their practical impact on data quality, system interoperability and, ultimately, on clinical practice and research.

Identifying Indicators to Assess and Monitor Data Integration Engines Systems.

We aimed to identify relevant indicators for end-users in integration engines for healthcare systems. METHODS: The study was performed in two steps, including interviews and the identification of additional indicators from the literature. RESULTS: 10 interviews were performed and 90 indicators identified. DISCUSSION: Several of the indicators are difficult to calculate, nevertheless, they have the potential to improve data quality and processes in healthcare institutions and should be further explored in future studies.

Can openEHR Represent the Clinical Concepts of an Obstetric-Specific EHR - ObsCare Software?

ObsCare is an obstetric-specific Electronic Health Record in use in nine Portuguese obstetric departments. Like other EHRs, it faces major challenges related to semantic interoperability and data quality. openEHR is proposed to address those needs. This study aimed to describe a summary representation of Obscare workflow and to validate whether archetypes in the openEHR Clinical Knowledge Manager repository can represent ObsCare clinical concepts. The study included the phases: a) ObsCare form selection; b) Description of the workflow care process; c) Detailed data extraction; and d) CKM models analysis. 379 variables were analyzed: 219 were fully represented in CKM repository; 99 were partially represented and needed archetype modification; and 61 were not represented and need new archetypes. To conclude, our study showed that the openEHR CKM repository requires further enhancements to be able to fully answer to the needs of an obstetric-specific EHR, the ObsCare software.

The Impact of Electronic Obstetric Records Using the ObsCare Software on Scientific Production.

AIMS: To compare the characteristics of scientific publications performed in hospitals that used with those that didn't use an obstetric electronic health record (EHR). METHODS: This study included two reviews (A and B). Review A was an exploratory analysis of all 100 abstracts presented at the Scientific Meeting of the Portuguese Society of Obstetrics and Maternal-Fetal Medicine, in November 2017. Review B was a systematic review of studies in obstetrics, performed in Portugal and published between 2016-18 and indexed in PubMed. In both reviews, the included papers/abstracts were divided into two groups: from hospitals that used ObsCare® (ObsCare group) and from hospitals without a specific obstetric EHR or that didn't use ObsCare (sObsCare group). RESULTS: In both reviews, the sample size was significantly higher in hospitals from the ObsCare group. In review B, the length of the study period was also significantly longer in ObsCare group; no significant difference was found in review A. CONCLUSION: Publications from hospitals that used an obstetric specific EHR (ObsCare), included a higher number of patients and longer study periods.

From ObsCare Software to an OpenEHR Platform: Modelling Obstetric Archetypes.

INTRODUCTION AND AIMS: Electronic health records (EHRs) are important tools to facilitate communication between care providers and to improve clinical research. In obstetrics they became essential. The ObsCare software was created to answer to the need for an EHR with specific obstetric features. The present study aimed to develop openEHR-archetypes capable of representing an ObsCare® EHR form and to create an openEHR-template using the developed archetypes. METHODS: The study was performed in four phases: 1) selection and description of the ObsCare form; 2) Clinical Knowledge Manager (CKM) analysis; 3) modelling of the archetypes; 4) creation and testing of the template. RESULTS: One openEHR-archetype - Newborn summary - was modelled to assemble the following three clinical concepts that were not represented in CKM: hours of life, "Examination of newborn movements" and "Examination of reflexes". Finally, an openEHR-template was built and automatically converted into an EHR by VCIntegrator. CONCLUSIONS: Considering the potential to improve clinical research, we believe that more obstetric-gynecologic clinical statements should be modelled into openEHR.

Development of a birthweight standard and comparison with currently used standards. What is a 10th centile?

INTRODUCTION: Fetal growth charts are often used in clinical practice. It is important to understand the usefulness and the pitfalls associated with these tools. Without validation, it is difficult to ascertain if the cutoffs we intend are the ones we actually select. We developed a national standard for birthweight (BW) and compared it with other published reference values. STUDY DESIGN: Multicenter retrospective study. We collected data on live births, including first trimester ultrasound and pathology, from 23 to 42 weeks' gestational age (GA). We used a variation of the lambda (λ), mu (µ), and sigma (σ) method (LMS) to construct and smooth predicted centiles. GA data was plotted and modeled in days from 24 to 42 weeks. Resulting centiles were validated and compared with other published and widely used reference values. Data from both BW and estimated fetal weight was used to validate the model. RESULTS: Data on 661,338 births were collected from 22 institutions, including 71,515 cases with first trimester ultrasound. We excluded preterm cesarean section from analysis, because of a significant bias (up to 18%) on BW and used exclusively first trimester ultrasound dates from 34 to 42 weeks. The standard compares favorably with tables currently in use, both ultrasound and birthweight based. CONCLUSION: The use of first trimester ultrasound limits variability by minimizing some random error sources, such as data introduction and GA errors, while allowing better precision (GA in days). This results in a narrower range in the extreme centiles than other charts. Validation with estimates of fetal weight are sound in second and early third trimester fetuses, because that will be a "real world" usage of this standard. While there are similarities between our series and some international/foreign growth charts, other are unfit to characterize our population. This reinforces the need for validation of standards, and sound methodological practices when doing so.

Gestational age and fetal growth assessment among obstetricians.

OBJECTIVE: We aimed to characterize gestational age assessment and fetal growth evaluation among obstetricians. METHODS: Observational, cross-sectional study. We applied a questionnaire to obstetrics specialists and residents, during a national congress on obstetrics. RESULTS: Almost all 179 respondents correct gestational age in the first trimester by ultrasound, but 63% only if there is a difference of 2-9 days. Ultrasound at 11-13 weeks was considered more accurate than at 8-10 weeks by 81%, with a higher proportion of specialists choosing correctly the last answer (p = 0.05). One-third of the respondents did not correctly point the error associated with the ultrasound estimation of fetal weight (EFW). Of the 88% who use a growth table, only 32% were able to identify it by publication/author. Ninety-eight percent identify fetal growth restriction risk (FGR) with centiles (10th in 76%) and 73% of doctors diagnose FGR without other pathological findings (10th in 49%). 44% finds that a low EFW centile maintenance (4th to 3rd) is more worrisome than the crossing of two quartiles (75th to 24th). CONCLUSIONS: The role of ultrasound in gestational age assessment and use of EFW use for FGR classification was disparate among participants. EFW and respective centiles may be over relied upon.

Determinants of frequency and longevity of hospital encounters' data use.

BACKGROUND: The identification of clinically relevant information enables improvement in user interfaces and in data management. However, it is difficult to identify what information is important in daily clinical care, and what is used occasionally. This study aims to determine for how long clinical documents are used in a Hospital Information System (HIS). METHODS: The access logs of 3 years of usage of a HIS were analysed concerning report departmental source, type of hospital encounter, and inpatient encounter ICD-9-CM main diagnosis. Reports median life indicates the median time elapsed between information creation and its usage. The models that better explains report views over time were explored. RESULTS: The number of report views in the study period was 656,583. Fifty two percent of the reports viewed by medical doctors in emergency encounters were from previous encounters - 21% at outpatient attendance, 19% in inpatient (wards) and 12% during emergency encounters. In an inpatient setting, 20% of the reports viewed were produced in previous encounters. The median life of information in documents is 1.5 days for emergency, 4.8 days for inpatient and 37.8 days for outpatient encounters. Immune-hemotherapy reports reach their median lives faster (7 days) than clinical pathology (15 days), gastroenterology (80 days) and pathology (118 days). The median life of reports produced in inpatient encounters varied from 36 days for neoplasms as the main diagnosis to 0.7 days for injury and poisoning. The model with the best fit (R2 > 0.9) was the exponential. CONCLUSIONS: The usage of past patient information varied significantly according to patient age, type of information, type of hospital encounter and medical cause (main diagnosis) for the encounter. The exponential model is a good fit to model how the reports are seen over time, so the design of user interfaces and repository management algorithms should take it in consideration.

Reviewing the integration of patient data: how systems are evolving in practice to meet patient needs.

BACKGROUND: The integration of Information Systems (IS) is essential to support shared care and to provide consistent care to individuals--patient-centred care. This paper identifies, appraises and summarises studies examining different approaches to integrate patient data from heterogeneous IS. METHODS: The literature was systematically reviewed between 1995-2005 to identify articles mentioning patient records, computers and data integration or sharing. RESULTS: Of 3124 articles, 84 were included describing 56 distinct projects. Most of the projects were on a regional scale. Integration was most commonly accomplished by messaging with pre-defined templates and middleware solutions. HL7 was the most widely used messaging standard. Direct database access and web services were the most common communication methods. The user interface for most systems was a Web browser. Regarding the type of medical data shared, 77% of projects integrated diagnosis and problems, 67% medical images and 65% lab results. More recently significantly more IS are extending to primary care and integrating referral letters. CONCLUSION: It is clear that Information Systems are evolving to meet people's needs by implementing regional networks, allowing patient access and integration of ever more items of patient data. Many distinct technological solutions coexist to integrate patient data, using differing standards and data architectures which may difficult further interoperability.