1
Assessing user experience during data
collection in the context of eOverdracht
by better exploiting Health Care
Information Models
2
Assessing user experience during data collection
in the context of eOverdracht by better exploiting
Health Care Information Models
Student
Nikki Haaksman
Student number: 11429097 Mentors
Bernard Bresser
Product Manager Hospitals NEXUS Nederland B.V. Tutor
Dr. ir. R. Cornet PhD Faculty of Medicine
Department of Medical Informatics, AMC‐UvA Location of Scientific Research Project
NEXUS Nederland B.V. Weverstede 35 3430 AS Nieuwegein The Netherlands Practice teaching period November 2018 – June 2019
3
Preface
This thesis describes my scientific research project (SRP) called “Assessing user experience during data collection in the context of eOverdracht by better exploiting Health Care Information Models”. This SRP is the final part of the Master Medical Informatics. This Master prorgamme was followed the Academic Medical Centre (AMC) in Amsterdam and the University of Amsterdam (UvA). The SRP was performed at NEXUS Nederland B.V., a software provider for the care sector. The aim of this SRP is to gain insight in the challenges concerning data collection with HCIM and the users’ needs in the context of eOverdracht. Therefore, this thesis contains a gap analysis and user research.
I would like to thank my mentor Bernard Bresser (NEXUS Nederland B.V.) and my tutor Ronald Cornet (AMC) for their support and guidance throughout this entire process. Their enthusiasm and expertise inspired and motivated me to a great extent. I am grateful for all the time they made for me in the most unexpected moments and the great feedback I received from them. I learned a lot!
Next, I would like to thank all my colleagues at NEXUS Nederland B.V. for the support during all these months. Everyone’s help and interest was highly appreciated! Especially the help of all the experts who were involved in the validation of the results of this research. Without them the validation would not be possible.
Furthermore, I would like to thank all the nurses of the St Anna Hospital in Geldrop for their participation in this research project. I’m very grateful for their cooperation, patience and contribution. Their help was invaluable!
Finally, I would like to express my sincere gratitude to my friends and family for all their support and believing in me during this research project and throughout all my years of study.
4
Contents
1. Introduction ... 8 1.1. Research objectives ... 8 1.2. Research questions ... 9 1.3. Expected results ... 9 1.4. Chapter organisation ... 9 2. Preliminaries ... 10 3. Methods ... 13 3.1. Gap analysis ... 14 3.1.1. Selection of HCIM... 14 3.1.2. Queries ... 17 3.1.3. Inspection ... 17 3.1.4. Analysis ... 17 3.2. User research ... 18 3.2.1. Users ... 18 3.2.2. Observing ... 18 3.2.3. Interviews ... 18 3.2.4. Analysis ... 19 3.3. Recommendations ... 19 3.3.1. Gap analysis ... 19 3.3.2. User research ... 19 3.4. Classification ... 20 4. Results ... 21 4.1 Classification ... 22 4.2. Gap analysis ... 27 4.3. User research ... 31 5. Discussion ... 38 6. Conclusion ... 45 References ... 46 List of Abbreviations ... 49 Appendix 1 ... 50 Appendix 2 ... 53 Appendix 3 ... 555
Keywords:
Standardisation
HCIM
eOverdracht
User Experience (UX)
Usability
6
Abstract
INTRODUCTIONEvery year, 300.000 patients are transferred between care facilities in the Dutch healthcare system, leading to exchange of information. However, more than half of the nurses involved in these transfers experience issues like incomplete and ambiguous information. Emerging from the initiative ‘Registratie aan de Bron’, Health and Care Information Models (HCIM) were introduced to improve standardisation and the exchange of patient information. Consequently, the information standard for patient transfers (eOverdracht) was completely built up by HCIM. However, standardisation introduces potential increase of (time consuming) data capture and usability issues for the users which could make standardisation less efficient and effective than intended. Since this could influence the user experience and consequently negatively affect patient care, it is important to determine the challenges surrounding the implementation and use of HCIM and the eOverdracht, and provide solutions for them. METHODS
A gap analysis was performed to compare the current data collection to the HCIM guidelines and determine the challenges to becoming HCIM compliant. To examine the user experience of the implementation of HCIM and the eOverdracht, nurses were observed while using the system and interviewed afterwards. Design guidelines, feedback from experts, nurses and from the actual process of designing and implementing HCIM were used to provide recommendations for each challenge. RESULTS
There is a mismatch between the system and HCIM since changes are required to become HCIM compliant. For instance: Free-text fields need to change to data fields that have input controls with predefined options. Occasionally, free-text fields will be split up in multiple data fields. Besides, code lists might have to be compiled by using expert groups and multiple code systems are occasionally possible. Furthermore, as much data fields as possible need to be prefilled by using readily available data or using rules. Although not all (data elements of) HCIM might be implemented, it needs to be possible to receive all of them for the sake of information exchange. Mandatory elements should be clearly distinguishable from non-mandatory content. The user research showed that using tables as a template to capture HCIM information should be prevented. Inconsistent and non-intuitive buttons should be prevented as well. Although it is better to hide most data fields, it should also be possible to expand all the data fields. Furthermore, it should be possible to save all HCIM-based information in a form at the same time. Distinction between the main and sub-content in the system and HCIM and non-HCIM related data fields is recommended. Reusing information is important. Data should be captured only once and used for multiple GUI elements, which is possible after implementing HCIM. For the eOverdracht, all data can then be shared as well. As much data as possible needs to be imported to the eOverdracht since this would save much time. However, it should be possible to change the selection of data as well since a nursing view is always needed. Consistency between the data captured in the system and asked in the eOverdracht is important.
CONCLUSION
Several changes are needed in order to become HCIM compliant. The presentation of information will be different due to the amount of free-text fields currently used and all the standardised content that needs to replace these. Since this will increase the amount of data fields, it is recommended to create rules to prefill and reuse as much data as possible. However, a nursing view on the data remains necessary. Consistency between the data recorded in the system and asked in the eOverdracht is important. Furthermore, overwhelming the user with information is not recommended since this affects the overview. Data fields should not all be shown immediately and a distinction between different types of data is necessary. The recommendations were not implemented and validated with the nurses but provide first insights in user experiences of HCIM and eOverdracht. However, further research is needed. To add, most issues could be solved by better implementation and design. Although this was not realised yet, NEXUS’ software is capable to change the designs and functionalities.
7
Samenvatting
INTRODUCTIEIeder jaar worden er in het Nederlandse gezondheidssysteem zo’n 300.000 patiënten overgedragen aan andere zorginstellingen wat leidt tot het uitwisselen van informatie. Echter, meer dan de helft van de verpleegkundigen betrokken bij deze overdrachten ervaren hier problemen mee zoals incomplete en dubbelzinnige informatie. Door het ‘Registratie aan de Bron’ programma zijn zorginformatiebouwstenen (ZIBs) geïntroduceerd met als gevolg dat de informatie standaard voor de verpleegkundige overdracht (eOverdracht) volledig werd opgebouwd uit ZIBs. Echter, standaardisatie introduceert een mogelijke toename van tijdrovende registraties en gebruiksvriendelijkheidsproblemen wat de efficiënte en effectiviteit ervan beïnvloedt. Aangezien de gebruikerservaringen en daardoor ook patiëntenzorg hierdoor negatief beïnvloed kunnen worden is het belangrijk om de uitdagingen op het gebied van de implementatie en het gebruik van ZIBs voor de eOverdracht vast te stellen en hiervoor oplossingen te bedenken.
METHODEN
Een gap analyse werd uitgevoerd om de huidige registratie te vergelijken met de richtlijnen van ZIBs en te bepalen wat de uitdagingen zijn om conform de ZIBs te registreren. Om de gebruikerservaringen met de huidige ZIBs en eOverdracht te onderzoeken werden verpleegkundigen geobserveerd terwijl ze het systeem gebruikten en vervolgens geïnterviewd. Design guidelines, feedback vanuit het ontwerp- en implementatieproces en feedback van experts en de verpleegkundigen zijn gebruikt om aanbevelingen te bieden voor de problemen die geconstateerd werden.
RESULTATEN
Er is een mismatch tussen het systeem en de ZIBs aangezien er een hoop veranderingen nodig zijn om conform de ZIBs te registreren. Vrijetekstvelden moeten veranderen naar datavelden waarbij voorgedefinieerde waardes gekozen kunnen worden. Sommige vrijetekstvelden zullen ook opgesplitst worden in meerdere datavelden. Daarnaast zullen codelijsten samengesteld moeten worden door expert groepen te creëren en zijn soms meerdere codestelsels mogelijk. Ook moeten zo veel mogelijk datavelden vooraf gevuld worden door bestaande data te gebruiken of regels toe te passen. Alhoewel mogelijk niet alle (dataelementen van) ZIBs aanwezig zijn in het systeem, moet het wel mogelijk zijn bij uitwisseling alle informatie te ontvangen. Verplichte dataelementen moeten duidelijk te onderscheiden zijn van de niet-verplichte dataelementen, net als de hoofd en sub-content en ZIB en niet-ZIB gerelateerde onderdelen. Tabellen gebruiken om ZIBs te registeren is niet aan te raden, zeker niet als meerdere ZIBs hierin gecombineerd worden. Inconsistente en niet-intuïtieve knoppen moeten vermeden worden. Alhoewel het beter is om de meeste datavelden te verbergen, moet het mogelijk zijn ze allemaal zichtbaar te maken. Alle ZIBs in een registratiepaneel moeten zowel individueel als tegelijkertijd kunnen worden opgeslagen. Informatie moet slechts een keer geregistreerd worden en vervolgens meerdere malen gebruikt, waaronder voor eOverdracht. Zo veel mogelijk informatie moet automatisch worden geïmporteerd in de eOverdracht door regels toe te passen. Het moet echter wel mogelijk zijn om de selectie van informatie aan te passen i.v.m. de verpleegkundige blik die nodig blijft. Consistentie tussen de informatie in het systeem en informatie nodig voor de eOverdracht is belangrijk. CONCLUSIE
Er zijn veel veranderingen nodig om aan de ZIB-richtlijnen te voldoen. De presentatie van informatie zal erg veranderen door de huidige hoeveelheid vrijetekstvelden en de gestandaardiseerde informatie die deze vrijetekstvelden moet vervangen. Aangezien het aantal datavelden hierdoor toeneemt is het aan te raden om regels toe te passen die automatisch datavelden vullen met informatie. Een verpleegkundige blik blijft nodig. Consistentie op alle vlakken van het systeem is belangrijk, evenals overzicht behouden. Duidelijk onderscheid tussen verschillende typen informatie is noodzakelijk. De aanbevelingen zijn niet geïmplementeerd en gevalideerd met verpleegkundigen maar bieden eerste inzichten op het gebied van gebruikerservaringen van ZIBs en eOverdracht. Aanvullend onderzoek is derhalve nodig om de resultaten te valideren met gebruikers. De software van NEXUS kan de veranderingen van functionaliteiten en designs die nodig zijn aan. Deze zijn echter nog niet gerealiseerd.
8
1. Introduction
Transferring patients from one healthcare provider to the other is a daily practice for nurses and other caregivers. Every year, around 300.000 patient are transferred between care institutes in the Dutch healthcare. [1] Along with these transfers comes the exchange of patient information. Research of Nictiz among nurses showed that more than half of the nurses and caregivers experienced several problems with transfers. The most prominent issue was the incompleteness of the information that was received, due to the lack of knowledge of the preferences of the receiving parties. Besides, the transfers were considered unclear and the content inconclusive.
Due to the large amount of transfers in the care chain, a clear and unambiguous transfer for nurses is needed to improve the communication in this chain. Therefore, the information standard eOverdracht was developed. The eOverdracht is a generic core set of care-related transfer data for nurses and caregivers in the healthcare chain. [2] The importance and urgency for an electronic and standardized transfer of patient information between care institutes is also recognized by the government. The Dutch minister of medical care and sports has confirmed that regulations will be developed on short notice to enforce health care institutions to implement a standardized digital exchange of data faster. The transfer by nurses (eOverdracht) is part of this. [3] [4]
In 2014, the initiative ‘Registratie aan de Bron’ [5] (Facilitating clinical documentation at the point of care) was introduced to improve the quality of care and, as called this way by ‘Registratie aan de Bron’ [6], unity of language. Unity of language means unambiguous information for all users. The ‘Registratie aan de Bron’ initiative promotes unambiguous data capture only once during the care process so data can be reused. To realise this, Health and Care Information Models (HCIM) were introduced in the Dutch health care system. [7] HCIM are information models that contain functional (non-technical) agreements for the standardisation of information surrounding a specific care-based concept. Examples are ‘Respiration’ or ‘Bowel Function’. To define the structure, every HCIM is described in terms of the data elements that they consist of and the specifications of these data elements such as data types, cardinality and specified code lists.
Besides providing unambiguous and one-off data capture, HCIM are clinically relevant and can be used in many different care settings. Interoperability is also stimulated since data captured in HCIM can be easily reused within care processes themselves but also for other purposes such as quality registrations or information standards such as the eOverdracht for exchanging patient information to other care institutes. [8]
Due to the introduction of HCIM, version 3.0 of the eOverdracht (from now on always referred to as ‘eOverdracht’) is completely built up by HCIM, stimulating standardised digital exchange of patient data and solving transfer issues as described before. [9]
Although HCIM were developed to improve standardisation, standardisation also introduces potential increase of (time consuming) data capture and usability issues. This leads to challenges for both the users of a system with HCIM and vendors who implement the HCIM into their electronic health record (EHR) as well. [10] Since the eOverdracht consists solely of HCIM, the usability of the eOverdracht is affected as well. Improving the experience of both HCIM and the eOverdracht for users in the care sector is extremely important since it affects patient care as well as the satisfaction of the users. [11] In order to improve the effectiveness and efficiency of standardisation by HCIM and eOverdracht, the challenges for implementation and users surrounding data collection with HCIM should be determined and solutions provided.
1.1. Research objectives
By the end of 2019, due to the Dutch VIPP programme most EHR vendors will have 26 HCIM related to the BgZ (Basisgegevensset Zorg) implemented in their EHR. The BgZ is the minimal set of patient data that is relevant for any profession, specialism or disease, and consists of 26 HCIM. The BgZ was created
9
as part of the ‘registratie aan de bron’ initiative. [12] The Dutch VIPP implementation programme was initiated to accelerate the transfer of patient data between professionals and with patients [13] Although the BgZ covers a minimal set of relevant information, it does not cover the complete set of information needed for nurses to transfer a patient. The information standard eOverdracht consists of 66 HCIM, of which 14 HCIM have an overlap with the BgZ. The remaining 52 HCIM are eOverdracht specific and are not part of the current VIPP programme. Therefore, the analysis of the content and designs for these HCIM are not yet realised and implemented in the products of NEXUS Nederland B.V. (from now on referred to as NEXUS).
NEXUS is a medical software vendor. Besides an EHR they provide software for, among others, operating rooms, emergency departments, food care, but also an electronic nurse record (ENR). The ENR is a separate product but an integral part of the overall NEXUS EHR.
Eventually, the goal of this research is to assess the implementation and user challenges concerning data collection with HCIM in the context of eOverdracht and provide solutions so HCIM can be exploited to overcome these challenges. In order to do this, the challenges concerning the implementation of the remaining 52 eOverdracht-specific HCIM need to be determined first by comparing the current data collection with the HCIM guidelines. The changes that need to be made to the current data collection in order to become HCIM compliant can be challenging for the users. User feedback on the current data collection with HCIM and the eOverdracht is necessary to determine the current issues and needs of the users. Since nurses are responsible for the eOverdracht, the users are nurses. By providing recommendations based on the challenges concerning implementation of HCIM for data collection and the issues described by the nurses, the challenges and issues can be overcome.
1.2. Research questions
The main research question in this research is as followed:“What are possible solutions to overcome implementation and usability challenges concerning data collection with HCIM in the context of eOverdracht?”
In order to answer this research question, the following sub-questions need to be answered.
Which are the current challenges for implementers and users concerning data collection with HCIM?
What is the experience of users during current data collection and eOverdracht, and which are their perceived needs?
How to employ HCIM in order to overcome the challenges and meet the needs of the users?
1.3. Expected results
In the end, a list of recommendations will be provided for all the challenges faced when changing the data collection to become HCIM compliant and for all the issues surrounding data collection with HCIM and the eOverdracht as described by the users. In this way, the users’ needs will be met and the user experience optimised.
1.4. Chapter organisation
In the following chapter (chapter 2), a short background information will be provided about the specifications of HCIM. In chapter 3, the methods used in this study will be discussed. Chapter 4 will present the results of this study. In chapter 5, the results will be discussed including the strengths and limitations of this study and further research. Lastly, the conclusion of this study will be presented in chapter 6.
10
2. Preliminaries
Since many terms based on the HCIM guidelines will be used in this study, a short description of the specifications of HCIM and an explanation of all the terms that will be used is provided.
2.1. HCIM
As a reference, the HCIM ‘BodyTemperature’ will be used. [14] Besides several metadata like the ID of the HCIM and the date of publishing, important items as the concept, purpose and information model of the HCIM are described in each HCIM guideline. The ‘concept’ contains a short description of the care-related concept the HCIM is based on. For ‘BodyTemperature’ this is described as followed: “Measuring and documenting the body temperature of a person as a surrogate for a person’s central body temperature (the highest temperature at the centre of the torso)”
Afterwards, the ‘purpose’ of the HCIM is shortly described. In case of the ‘BodyTemperature’ this means:
“Measuring the body temperature is of medical importance. A number of diseases are accompanied by characteristic changes in body temperature. The symptoms of some diseases can be tracked by measuring the body temperature. The healthcare provider can use this temperature development to determine the effect of the treatment.”
The ‘information model’ that follows is close to a data model that shows how the root concept is constructed from its associated ‘data elements’. The root concept of the BodyTemperature information model is ‘BodyTemperature’. The information model of the HCIM ‘BodyTemperature’ is shown in figure 1. The model shows the structure and the relationships between all data elements.
Figure 1: Information model of the HCIM 'PulseRate' [14]
Data elements are the associated (care-related) elements that belong together and to the root concept of the HCIM. The four data elements in the HCIM ‘BodyTemperature’ are ‘TemperatureValue’, ‘TemperatureDateTime’, ‘TemperatureType’ and ‘Comment’. Each data element is described using among others a definition, datatype, definition code, an example, and when possible the value set. An example of a description of the data element ‘TemperatureValue’ is shown in figure 2.
11
Figure 2: Description of the data element ‘TemperatureValue’ as part of the HCIM ‘BodyTemperature’. [15]
The ‘data type’ describes how the data elements should be captured. All possibilities are shown in figure 3. Examples are Boolean (yes or no), Integer (a number), free-text or coded (with a code system).
Figure 3: A description of all the data types possible for data elements of HCIM. [16]
The ‘definition code’ gives the code of a specific code system that refers to the concept of the data element. This will be the underlying code of the label of the data field in a system.
An ‘example’ of what should be captured is provided as well for each data element. For the data element ‘TemperatureValue’ this is ’37.3 ⁰C‘.
When a data element is coded, a ‘value set’ with possible choices for that data element could be provided. This is a list with codes and will also be referred to as a ‘code list’ in this study. An example of the value set for the data element ‘TemperatureType’ is presented in figure 4. The value set for ‘TemperatureType’ contains anatomical locations of where temperature was measured. The value set describes all the concepts names, the corresponding concept codes which is unique for that concept, the name of the coding system where this concept code can be found, the identification number of the coding system and a description of each concept name.
12
Figure 4: Value set for the data element ‘TemperatureType’ of the HCIM ‘BodyTemperature’. [15]
The last term that will be discussed is the ‘cardinality’ of each data element. The number ‘1’ means that a data element is mandatory and should always be recorded. A cardinality of ‘0..1’ means either no item or one item is captured. A cardinality of ‘0..*’ implies that the data element is captured zero, one, or multiple times. A cardinality of ‘1..*’ means the data element has to be captured once, or multiple times. [6]
13
3. Methods
In this chapter the methods for the gap analysis are explained first. During the gap analysis the differences between the current data collection and the HCIM guidelines were studied in order to define the challenges. Afterwards, the user research is explained. During this research nurses were observed and interviewed about their experiences with the current data collection with HCIM and for eOverdracht. Feedback was provided. Next, the analysis for the recommendation is described. Hereby, the method to which the recommendations for the challenges and the issues as described by the users is explained. Lastly, the overall classification for the results is introduced.
14
3.1. GAP ANALYSIS
In order to determine the current challenges concerning data collection with HCIM, the current data collection in the EHR and ENR was compared with the HCIM specifications. As previously mentioned, the ENR is a separate product but an integral part of the EHR. The data is shared between ENR and EHR. However, nurses have a different workspace and additional functionalities that support the working method. While much data is captured in the EHR only, this data is visible for nurses as well. Although the eOverdracht is the responsibility of the nurses, nurses do not capture all patient-related data. Much data is captured by doctors in the EHR. While most of this data can be accessed via the ENR, the ENR might not be the source of this data capture. Therefore, both EHR and ENR were examined for the gap analysis.
The specifications of each HCIM are described in documents managed by Nictiz. The changes needed in order to become HCIM compliant were examined and compared to the data collection of the EHR and ENR. To limit the chances on results that are based on system-specific functionalities, the EHR and ENR of only one client hospital of NEXUS were involved. The systems are client-specific and therefore non-identical to the systems of other clients. There are no guidelines to how current data collection should be, and how the data collection in conformance to HCIM should be presented to the user. Therefore, a qualitative empirical approach was used. Qualitative data was preferred for this research since this research serves to give insight into the type of challenges, not into the exact size and impact of these challenges.
3.1.1. Selection of HCIM
Since the HCIM of the BgZ overlap with the HCIM for the eOverdracht, several HCIM were excluded from this study. The HCIM that are part of the BgZ are listed in table 1. The HCIM of the BgZ were already analysed, designed and mostly implemented in the EHR of NEXUS. Therefore, the data collection prior to HCIM could not be studied for these HCIM. Consequently, these HCIM were excluded. NEXUS analysed, designed and implemented one additional HCIM besides the BgZ. Therefore, this additional HCIM was excluded as well.
There are several HCIM for specific target groups, like elderly, people in nursing homes, and children. While all the other HCIM are representable for (almost) every patient, the HCIM for these specific target groups were exceptions or additional HCIM. To improve the generalisability of this research, the exceptional HCM were not included. Eventually, all the HCIM that were representable for a ‘regular’ adult. This does not mean that children and elderly are not represented in this research, solely that the few exceptional HCIM that were created for these target groups were not included. In figure 5, a visual presentation of the overlap of all HCIM mentioned is shown. An overview of all the HCIM of the eOverdracht and the excluded HCIM can be found in appendix 1. All HCIM included in this study are listed in table 2.
Figure 5: Visual overview of the amount of HCIM in the eOverdracht, BgZ, and overlap between eOverdracht and BgZ. Within the eOverdracht, the excluded HCIM of children, non-regular adults and one additional HCIM are shown as well.
15
Table 1: List of all the HCIM of the Basisgegevensset Zorg (BgZ)
HCIM (Dutch) HCIM (English)
1 Alcoholgebruik AlcoholUse 2 Alert Alert 3 AllergieIntolerantie AllergyIntolerance 4 Behandelaanwijzing TreatmentDirective 5 Betaler Payer 6 Bloeddruk BloodPressure 7 BurgerlijkeStaat MaritalStatus 8 Contact ContactInformation 9 Contactpersoon ContactPerson 10 Drugsgebruik DrugUse 11 FuntioneleOfMentaleStatus FunctionalOrMentalStatus 12 LaboratoriumUitslag LaboratoryTestResult 13 Lichaamsgewicht BodyWeight 14 Lichaamslengte BodyHeight 15 Medicatieafspraak MedicationAgreement 16 MedicatieGebruik2 MedicationUse2 17 MedischHulpmiddel MedicalDevice 18 OverdrachtGeplandeZorgActiviteit PlannedCareActivityForTransfer 19 Patient Patient 20 Probleem Problem 21 Tabakgebruik TobaccoUsage 22 ToedieningsAfspraak AdministrationAgreement 23 Vaccinatie Vaccination 24 Verrichting Procedure 25 Voedingsadvies NutritionAdvice 26 Wilsverklaring AdvanceDirective 27 Woonsituatie LivingSituation 28 Zorgverlener HealthcareProvider
16
Table 2: List of all the HCIM of eOverdracht included in this research
HCIM (Dutch) HCIM (English)
1 Ademhaling Respiration 2 AlgemeneMeting GeneralMeasurement 3 Behandeldoel TreatmentObjective 4 Blaasfunctie BladderFunction 5 Brandwond Burnwound 6 Darmfunctie Bowelfunction 7 DecubitusWond PressureUlcer 8 FunctieHoren HearingFunction 9 FunctieZien VisualFunction 10 Gezinssituatie FamilySituation 11 Huidaandoening SkinDisorder 12 HulpVanAnderen HelpFromOthers 13 Infuus Infusion 14 Levensovertuiging LifeStance 15 Lichaamstemperatuur BodyTemperature 16 Mobiliteit Mobility 17 MUSTscore MUSTScore 18 ParticipatieInMaatschappij ParticipationInSociety 19 Pijnscore PainScore 20 Polsfrequentie PulseRate 21 SNAQScore SNAQScore 22 SondeSysteem FeedingTubeSystem 23 Stoma Stoma 24 Taalvaardigheid LanguageProficiency 25 UitkomstVanZorg OutcomeOfCare 26 VermogenTotDrinken AbilityToDrink 27 VermogenTotEten AbilityToEat 28 VermogenTotMondverzorging AbilityToPerformMouthcareActivities 29 VermogenTotToiletgang AbilityToToilet 30 VermogenTotUiterlijkeVerzorging AbilityToGroome 31 VermogenTotVerpleegtechnischeHandelingen AbilityToPerformNursingActivities 32 VermogenTotZelfstandigMedicatiegebruik AbilityToManageMedication 33 VermogenTotZichKleden AbilityToDressOneself 34 VermogenTotZichWassen AbilityToWashOneself 35 VerpleegkundigeInterventie NursingIntervention 36 Vochtbalans FluidBalance 37 VrijheidsbeperkendeMaatregelen FreedomRestrictingMeasures 38 Wond Wound 39 Ziektebeleving IllnessPercention 40 Zwangerschap Pregnancy
17 3.1.2. Queries
Queries were used on the database of the EHR. For the included HCIM of the eOverdracht standard, lookup terms were created. These lookup terms were based on the information in the HCIM guidelines, by using general medical knowledge and searching online. Searching online was needed to find official medical terms as well, which might be used in the EHR and ENR. The lookup terms had to cover every data element of the HCIM. For instance, the measuring tool SNAQ could be used to measure the extent of malnutrition of the patient. Data elements of the HCIM ‘SNAQ Score’ are among others a nutrition score, appetite score and weight loss score. The lookup terms representable for this HCIM might be SNAQ, nutrition, appetite, weight or weight loss etc.
It should be noted that words might be part of a word that is not relevant. An example is finding the word ‘staircase’ when using the lookup term ‘air’. This term is not relevant. Time spent on inspecting the graphical user interface (GUI) elements of the EHR and ENR that contain these lookup terms should be prevented. GUI elements are all the elements in the user interface that provided data capture or displayed data. Due to the possibility of these irrelevant matches, the exact word that caused the match of the query was queried as well to be able to make these words visible in the query output and judge them for initial relevance. Consequently, irrelevant words and GUI elements could be filtered out.
Besides, some words end differently when used in another tense or when in plural. Since it is not known whether words might appear in different tenses, singular or plural in the system, the most universal part of the words was used. For instance, ‘continen’ was used as a lookup term since ‘continent’, ‘continence’ or both might appear in the system. This was considered more efficient than adding lookup terms for every tense and plural as well.
The output of the queries consisted of all the GUI elements in the EHR and ENR that contained the lookup terms. The exact word that matched the query was shown as well so irrelevant word matches could be excluded before inspection of the GUI elements.
3.1.3. Inspection
For the inspection, all the content (all GUI elements) in the system were studied. Each GUI element had to be inspected to decide on its relevance for every data element of the HCIM. For every data element the presence or absence was determined, where exactly it was located (multiple GUI elements possible), the current data capture method (String, Boolean, predefined options etc.), the cardinality and when relevant, the units. Remarks were added as well. Examples of remarks were the things that needed to change, the context in which the data capture was used, the purpose of that data capture and how all of this deviates from the specifications of that data element in the HCIM.
For every data element, it was noted whether it was not, partly, or completely compliant to the HCIM guidelines. The focus was on the user interface, since the way in which the data was used and presented was of interest.
3.1.4. Analysis
All remarks were combined and analysed to find patterns by looking for recurring issues and topics. Changes that often had to be made, and issues and findings that appeared frequently were categorized. These categories were created in a data-driven approach. So, by looking at recurrent themes in the data instead of predefining categories and trying to fit the data in those categories. This approach was chosen to limit a personal or intuitive influence on the data. Every category consisted of several sub-categories that each defined a more specific topic within that category.
18
3.2. USER RESEARCH
In the second phase of this study, several users of the system studied (nurses) were observed and interviewed in order to look at the usability of the system.
3.2.1. Users
The users of the system that create the eOverdracht are mostly and usually nurses. Therefore, nurses were the users studied in this research. Although the doctors had more HCIM implemented in the EHR already, they were not involved in the eOverdracht process. Since this research is about the eOverdracht, it is not relevant to include the feedback of doctors on the usability of their system and feedback on HCIM and eOverdracht. Besides, doctors have a different working method and approach to patient care. Therefore, their way of thinking differs from nurses. Combining user feedback could lead to different opinions of doctors compared to nurses. Due to the focus of this research (exchange of patient information by nurses (eOverdracht)), doctors and other caregivers besides nurses were excluded.
The nurses worked in the same hospital as studied for the gap analysis so the nurses used the same system as studied. This was necessary to have no mismatches between the system studied and the feedback on the system by the nurses and so feedback provided by the nurses could be related to the challenges detected in the gap analysis.
Since surgical and non-surgical (diagnostic) specialisms have different views on care, differences in results could have appeared such as specialism specific issues. [17] To limit department or specialism specific issues, a department with a surgical and diagnostic specialism were chosen. These were the surgery department (surgical) and the cardiopulmonary department (diagnostic).
3.2.2. Observing
Firstly, the purpose and functionalities of the system had to be identified in order to critically assess the system usage of the nurses. The gap analysis already gives insight in this due to all the GUI elements that had to be examined. Besides, the different functionalities of the system were observed by scanning and testing by trial and error. Implementation specialists with a history as a nurse provided demonstrations of how the system is intended to work.
Afterwards, the nurses were observed when using the system. To test in a real-life environment, all testing was performed in the hospital while the nurses were working. When nurses had difficulty with finding something in the system, or used the system differently than how the system is supposed to be used, they were asked what caused this.
3.2.3. Interviews
Although there are many questionnaires that focus on usability, the purpose of this research was to gain qualitative data to find the exact struggles of the nurses. However, there are no questionnaires about the Dutch HCIM, eOverdracht and the connection with user experience. Therefore, interviews were created so open questions could be asked about these topics. Since the questions were open, feedback could diverge. To make sure that the nurses thought about specific usability aspects as well, several sub-questions about usability were added based on usability questionnaires. These questionnaires were the SUMI [18] and the QUIS [19]. The questions that were created for the user interface were among others about buttons, colours, terminology, and content. Besides, the nurses’ satisfaction of the system, best functionalities, worst functionalities, time-consuming functionalities, obscurities and more were questioned. Eventually, the interview questions were based on a combination of the topics of this study (HCIM, eOverdracht) and usability aspects.
Since the nurses are often not familiar with the technical term ‘HCIM’, their opinions on the changes that were introduced in one specific form were asked instead of asking about ‘HCIM’. This is due to the fact that it is not relevant for the nurses to know about HCIM and the underlying processes
19
and codes. Changes should be visible in the user interface, but the terms ‘HCIM’ or codes should never be visible. The form was the only place in the system where HCIM were introduced. The HCIM were the only changes to this form. Therefore, the changes are related to the introduction of HCIM.
For the eOverdracht, the nurses were first asked what their thoughts on the eOverdracht were. Afterwards, more specific questions were asked as well like what they thought of the current content and layout, what data they select for the eOverdracht and how they get this data to the form. In the end, the nurses were asked about additional remarks or feedback on the system. In this way, input could be given on issues that were not covered by the questions that were asked during the rest of the interview. All interview questions can be found in appendix 2.
3.2.4. Analysis
As described before, feedback was given on data collection in the system with (and without) HCIM, and specifically on the eOverdracht. The feedback about HCIM was put in the category ‘HCIM’, and the feedback on the eOverdracht in the ‘eOverdracht’ category. All results were validated with domain experts within NEXUS to avoid that outcomes were too hospital specific. Domain experts were consultants, information analysts, product managers and user experience (UX) experts. When these experts identified a result as valid, this feedback was included. Feedback that was mentioned only once was critically assessed or removed. When feedback was mentioned by only one nurse, there were often similar underlying concepts between this feedback and other provided feedback. In these cases the feedback was included as well. When one nurse gave contrasting feedback to others, it was considered important to mention this as well. However, it was clearly indicated when only one nurse provided feedback.
Within all (sub-) categories, the feedback was categorised into sub-categories using a data driven approach. In each sub-category, the feedback was combined and turned into a recommendation for future implementations or alterations of HCIM and eOverdracht.
3.3. RECOMMENDATIONS
After first identifying the challenges concerning data collection with HCIM, and issues concerning data collection with HCIM and eOverdracht perceived by nurses, recommendations were provided.
3.3.1. GAP ANALYSIS
The challenges detected during the empirical gap analysis were provided with recommendations. These recommendations were based on the Canada Health Infoway design guidelines for clinical coding of data [20], experiences from VIPP consultations with experts from several hospitals involved, and feedback from experts working for NEXUS. The former specifies design guidelines to implement SNOMED CT in an EHR, with a focus on usability and safety of the user interface. The guidelines are based on literature, existing guidelines, interviews with implementers and innovators and heuristic evaluations of existing coding implementations. The VIPP meetings are used to analyse HCIM and discuss how the HCIM of the BgZ will be implemented and what the content of the code lists will be. Therefore, the HCIM were analysed and (re-)designed as well which provided feedback. Nurses, implementation specialists and care coordinators among others have all given input during the VIPP meetings and discussed issues experienced by the nurses and during implementation. Product managers, product owners and UX experts working for NEXUS were consulted as well to validate the issues and recommendations. Additional feedback for the recommendations was included just like
3.3.2. USER RESEARCH
Since the approach of the interviews was to gain insight in the issues and possible solutions or needs of the users, most problems were already solved by the nurses themselves. The nurses mentioned issues and explained how they would rather see this. Other issues could be solved by using the Canada Health Infoway guidelines, experiences and feedback from VIPP consultations with experts from several
20
hospitals involved, and feedback from experts working for NEXUS. The experts were consultants, analysts, product managers and UX experts.
3.4. CLASSIFICATION
After the recommendations for both the gap analysis and the user research were defined, the challenges, issues and all recommendations were viewed as a whole. In order to define the underlying concepts of all the results, classes were introduced. Each results was assigned a class. These classes were created data driven. The classification of a result was based on the theme they fit best.
21
4. RESULTS
In this chapter, all the results of this study will be presented. To start, the classes that are introduced are explained. Afterwards, a table with results will be shown. This table contains all the challenges, user issues and accompanying recommendations, (sub-) categories and classification. Finally, the results in the table will be further explained.
22
4.1 CLASSIFICATION
The classes that were created based on the content and underlying concepts of the challenges, issues and recommendations are as followed:
1. Presentation of information
This class contains several aspects of presentation of information. This presentation will either be affected by standardisation or is currently not optimal.
2. Methods
This class consists of several methods than can be applied to make the implementation of HCIM in the EHR more effective and efficient.
3. Reusing and prefilling data
This class contains challenges, issues and recommendations that promote or provide ways to reuse and prefill data fields in the EHR and the eOverdracht.
4. Consistency
This class describes several ways to promote consistencies and prevent inconsistencies. 5. Functionalities
This class describes several functionalities that can be added to the EHR to support the user.
An overview of all challenges, issues, and recommendations can be found in table 4, including the data driven (sub-) categories and the classifications that were introduced.
23
Table 3: Overview of all the challenges detected in the gap analysis, issues detected during the user research, and all the accompanying recommendations. The classifications in the last column correspond to the following: Class 1 (green) is presentation of information, class 2 (orange) is methods, class 3 (yellow) is reusing and prefilling data, class 4 (blue) is consistency, and class 5 (red) is functionalities.
GAP ANALYSIS
# Category Sub-category Challenges Recommendations Class
1
Code systems
Standardised data capture
Free-text fields need to change to standardised data fields with input controls for predefined options.
Refer to the Canada Health Infoway design guidelines and Material Design for choosing the appropriate type of input control for the amount of options there are for the user to choose from.
1
2 One free-text field will change to multiple standardised
data fields.
Improvement due to a better structure for data capture and displaying
information. 1
3 Code lists
Code lists are not always specified for the coded data elements of HCIM. The code lists have to be compiled. This costs time.
Create expert groups per HCIM to create and manage a basic set of
options for the code lists. Involve users actively. 2
4 Mapping
For some HCIM data elements, multiple code systems are possible. When different code systems are used, mapping needs to take place for exchanging information, which is not always possible. Even when it is, this leads to information loss which should be prevented.
SNOMED CT is supported by almost every data element of all HCIM and therefore the most universal. It is not recommended to use several coding systems. However, sometimes this is necessary when SNOMED CT does not cover what needs to be captured like laboratory results. Combination of code systems is currently inevitable and no solutions are available.
2
5 Graphics Using graphics as input controls can only be maintained if
the graphics can lead to standardised content.
Graphics can be of great use for capturing and presenting data. However, the graphics must be able to change data capture to standardised content. 1 6 Registration burden Prefilling data fields
HCIM data elements might be used differently in the system, or not captured at all. Additional data capture or other working methods should be prevented.
Prefill as much data fields as possible. Labels of data fields and current timestamps can be used to prefill data fields. Rules, such as a result status of a measurement that automatically gets the status ‘Final’, should be implemented as much as possible in order to save time and to be able to fill in as much data elements as possible with no effort of the users.
3
7 Mandatory
elements HCIM contain mandatory and non-mandatory data fields.
Mandatory content should be clearly distinguishable from the non-mandatory content so the users do not feel obliged to fill in all the data fields presented to them.
1
8 Consistency Labels
A HCIM data element will have the same label on every GUI element in the system so there is uniformity. Specialism-specific labels will not be possible anymore.
One standard terminology is an improvement since it gives clarity and
24
9 Contradiction Contradiction in data capture should be prevented. There
are many contradictions in the code lists for HCIM.
The possibilities to select contradicting options in input controls, should be limited. The type of input control can be adjusted to this, or rules that make it impossible to select contradicting options can be applied.
4 10 Deviating data capture Different data capture
Data can be captured differently than described in the HCIM guidelines.
When the current methods differ from the HCIM guidelines, it should be questioned what the right manner is. When in doubt of the validity of the HCIM, consult Nictiz to discuss this. When 1:1 mapping of concept names is possible, replace the system values for the HCIM values.
2
11
Presence of data
Data elements or entire HCIM might not be captured anywhere in the system. It is challenging to incorporate this since users do not like additional data capture or different working methods.
Try to find a location for this data capture that support the working method of the users. For instance, locate them near data capture that is similar or support the other, or combine HCIM. Also make sure that (data elements of) HCIM that are not implemented in the system can still be received and viewed as a matter of exchanging information. Otherwise, there will be loss of information.
1
12 Clarity
Complicated HCIM
HCIM are not always clear. It takes a much time to figure out what to do or not to do in these situations.
Inform other parties like Nictiz, auditors or other software suppliers and hospitals that have been in the same position when clarity is needed about certain (aspects of) HCIM. Some HCIM are large and extended, which causes the possibilities to be almost endless. For instance, several HCIM or code systems can be possible for a HCIM. Input from others about the best way to deal with and implement this should always be asked instead of trial and error.
2
USER RESEARCH
# About Category Issues Recommendations Class
1
HCIM
Templates Tables as a template for capturing data of one or several
HCIM is unclear and not user-friendly.
Do not use tables as a template to capture HCIM related data, and
specifically do not cluster multiple HCIM in one. 1
2 Visibility
When clicking the button to expand all data fields, still not all the data fields are opened. However, it is considered unclear when all data fields of a HCIM are opened, especially when multiple HCIM are present in the same form.
Make it possible to open all the data fields within one display or form with one button to be able to see all data fields that need to be filled in, but to not overkill the nurses with all this information immediately. However, do not show all the single data fields within a HCIM immediately, but let subsequent data fields open as a consequence of what is captured before to keep an overview.
1
3 Consistency
Buttons for expanding or collapsing data fields were used inconsistently in the system, leading to missed data fields when capturing data.
Use consistency in the system. Specifically make sure that buttons are intuitive and clear for the nurses and are represented and used the same everywhere in the system.
25
4
HCIM
Layout
Differences between main and sub-content were not clear to the nurses due to the layout. This contributed to nurses not realising more data fields had to be opened and missing on data captured.
Clearly differentiate between main and sub-content in your design. The data fields that belong to a HCIM should be distinguishable from other HCIM and non-HCIM related data fields. Within the HCIM it should also be clear what the main and sub-parts are.
1
5 Saving HCIM
HCIM were placed individually in a data capture form and had to be saved separately as well. This was considered inconvenient and unclear.
All HCIM in a form should be saved at once by saving the entire form
they are located in, as well as saving every HCIM separately. 5
6
eOverdracht
Reusing data
All information for the eOverdracht had to be looked up in the system. The information was scattered and hard to find. Above all, most of it had to be retyped in the eOverdracht as copy pasting was not always possible. This is dangerous since typing errors could occur.
Automatically import as many information as possible in the eOverdracht since this saves much time and prevents retyping errors. Not all information can automatically be put in the eOverdracht since the transfer requires a nursing view. Therefore, the information that is automatically transferred to the eOverdracht should have the possibility to be changed or deleted in order to create an appropriate eOverdracht.
3
7 Contribution
Since the eOverdracht takes long to fill in, multiple nurses might be involved in filling the form. When another nurse takes over, it is not visible what items in the eOverdracht are done and which are incomplete. It takes time to figure this out.
One nurse recommended adding the possibility to ‘check off’ or colour data fields that are finished to give insight to the nurse and the nurse that takes over the eOverdracht. However, when the eOverdracht is standardised and optimised the time it takes to finish the eOverdracht is reduced and nurses can finish the eOverdracht at once. No interruptions or other contributors might happen then.
5
8
Consistency
The layout of the eOverdracht form was not consistent in the overview and print version compared to when filling in the form. This is confusing. However, nurses did not like consistency when this means items of the eOverdracht that were not filled in were still shown in the overview and print version.
Make the overview and print version of the eOverdracht consistent by using the same or a similar layout and design. Additionally, data fields that are not filled should not be shown in the overview and print version of the eOverdracht.
4
9
The content of the anamnesis and the rest of the system is consistent. However, this information is not consistent with the eOverdracht. Additional data needs to be collected for the eOverdracht while this data was never necessary or captured. This costs much time.
Consistency between the information in the entire system and the eOverdracht form is recommended. Use clinical reasoning in hospitals, and an extended version of Gordon’s health patterns in other care institutes.
4
10 Content
The nurses were pleased with the content of the eOverdracht, which is based on the health patterns of Gordon and recognisable for the nurses.
Gordon’s functional health patterns are appropriate for the eOverdracht content and layout. However, they should be combined with clinical reasoning to present a brief overview of the health patterns instead of and extended analysis of all health patterns. The extendedness of the
26
eOverdracht
health patterns is not needed for hospitals and created inconsistency between data captured in the system and data asked for the eOverdracht. This should be prevented.
11
One section was repeated multiple times throughout the eOverdracht form. This was the section about the patient’s goals and need for support. The same questions were repeated for every health pattern of Gordon. This was confusing and unclear.
Do not repeat data capture of the same items multiple times in the eOverdracht. When the same items need to be filled in for different subjects, try to combine these in one GUI element and make it as small and general as possible for all the subjects so it only appears and has to be filled in once. Especially for support and goals for the patient this is relevant.
1
12 Searching
With the current search options, it was not always possible to find what was desired. It was not possible to look for sub-content since the search functions only supported looking in the main topics and labels. Therefore, information could not be found and was captured in wrong GUI elements. With much standardised predefined content (due to HCIM) search function might be needed more in the future. Issues like this should then be prevented.
When searching for information, it is convenient to be able to search for synonyms and within sub-parts of an item (besides the title) as well to reduce the amount of time spent on searching the right GUI element and data captured in the wrong GUI elements.
5
13 Sorting
The order is which data is presented to the nurses is important. Dates are considered important for the eOverdracht since information related to a hospital stay is relevant.
Arrange data in order of importance. Especially dates are important in matters of a transfer based on a hospital stay, which is in a specific time frame. Dates, but also other relevant data should be immediately visible, so without having to take further actions.
1
14 Uniformity of
captured data
There is no uniformity between captures data that belongs together and has been captured at the same time. Showing time stamps for every data item that is captured is then confusing and impairs the clarity and overview of the data. Grid lines between captured data also indicate that there is no uniformity.
When multiple data items are captured at the same time, it is only necessary to show the timestamp for the first data item in an overview. This gives a clearer overview compared to showing the same time stamp for all data items. Besides, data items that belong together should not have grid lines in between them since this would indicate that these are separate data items.
1
15 Capturing data Much data needs to be captured in the system by typing.
This is much work and takes much time.
Selecting predefined sentences and texts, and word prediction may help speed up typing in the EHR. However, all of this is not in conformance to standardised data capture since it is free text.
27
4.2. GAP ANALYSIS
Some of the challenges, issues or recommendations are further explained or illustrated in appendix 3. These are indicated with an asterisk (*).
4.2.1. Code systems
4.2.1.1. Standardised data captureChallenge 1: While much data capture is currently in free-text, this will not be possible anymore for most of the data capture when implementing HCIM. Due to standardised data capture objectives and unity of language, most data elements of a HCIM consist of predefined options from a specified code list. This implies going from free-text data capture to selecting predefined options presented by input controls like for instance radio buttons, checkbox lists or dropdown lists.
Recommendation 1: The Canada Health Infoway Guidelines contain guidelines for among others the type of input control that is appropriate considering the amount of options that need to be presented. Examples of input controls are radio buttons, checkbox lists and dropdown lists. Although the Canada Health Infoway Guidelines give great insight into many aspects of the design of user interface, there are drawbacks.
First, it is not always appropriate to follow the guidelines. Situations should always be judged individually since designs should be applicable to the situation, not only to the guidelines. Dropdown menus create two clicks, while a selection list is only one click. Therefore, guidelines are good but should not be used as mandatory. User experience (UX) expertise is needed as well to make decisions.
Secondly, the guidelines are not applicable in all situations and based on PC platforms. There is a need for device independent guidelines and designs since mobile devices are being used as well in health care. Therefore, the material design [21] guidelines are a good example that could be used as an additional source. However, these are only guidelines. They do not mention the use of for instance images to click on and store standardised content which could make it easy for the user to understand.
Challenge 2 (*): Currently, the vast majority of the data is captured in one single free text field. However, HCIM consist of data elements that all need to be captured in a different data field. Consequently, multiple standardized data fields will replace one large free-text field.
Recommendation 2: Although standardised data fields are in contrast to the current working method (using many free text fields), these changes have a positive influence on the overview. Firstly, using many different data elements gives a better structure for reporting and can be used as a checklist to examine whether all information is present. Secondly, when you need to scan and find information it is easier to scan through clearly structured information than through large free text fields.
4.2.1.2. Code lists
Challenge 3: Specified code lists were created for most data elements of HCIM. However, sometimes the lists are extensible, which results in that one system might present more or less options to the user than the other system. The database should be able to store the extra options as well, otherwise information will get lost. However, since some data elements are not provided with specified code lists, these need to be compiled in its entirety. It takes much time to make an inventory of all the options that need to be present in a code list, and to find the accompanying code.
Recommendation 3: When code lists of the HCIM specifications can be copied from the guidelines, this saves much time. This is only possible when these code lists are considered as applicable for the desired system. When this is not the case, it is recommended to create expert groups per HCIM to create and manage a basic set of options for the code lists by actively involving the users. The expert groups should contain experts and users from all care institutes involved in the process. When there are
28
disagreements between hospitals as far as including concepts concerned, these concepts need to be excluded from the basic set of concepts for the code lists. However, these hospital-specific terms can be added to their own basic set by the hospital.
In the future, it might be useful to analyse all codes that have been used and received by other parties so code lists can be optimised. Codes that have not been used could possibly be removed, and codes that have been received but were not present in the institute’s database could be added. Another side note is that the optimal solution would be all care institutes using the same code list. This would lead to optimal interoperability. Therefore, all care institutes should be encouraged to work together with Nictiz to create a standard national data set for every HCIM.
4.2.1.3. Mapping
Challenge 4 (*): Another issue considering this topic is the fact that there are multiple code systems possible in some cases. For example, there are ten code systems available for the data element ‘ProblemName’ of the HCIM ‘Problem’. [22] There are specific code systems for several specialisms such as for instance psychiatry (DSM) and nursing (NANDA). Mapping is needed to translate one code system to another code system. [23] However, mapping is not possible for all code systems since for instance multiple SNOMED CT codes correspond to only one single ICD10 code. This is due to the fact that SNOMED CT has more specific and detailed options than ICD10. Therefore, when mapping is possible it almost always leads to loss of information. This loss of information is caused by differences in both structure and level of detail of classification systems. [24]
Recommendation 4: The SNOMED CT database was created especially to cover the core terminology for electronic health records. It contains over 340,000 concepts and is supported by almost every data element of all HCIM that needs coding. [25] SNOMED CT has very specific terms, whereas other coding systems often contain broader terms. There is less information loss when mapping specific information to more broad information than the other way around. Therefore, a more specific terminology that covers many concepts like SNOMED CT could be recommended.
However, while SNOMED CT supports almost all data elements of HCIM it does not cover all possible concepts. Although it is not recommended to use code systems that cannot easily be mapped and therefore exchanged, it is necessary in several cases. For instance, for laboratory determinations the LOINC code system is used. Although SNOMED CT covers many request for laboratory determinations, laboratories currently use LOINC codes for the results since SNOMED CT does not cover these. Therefore, depending on the type of data capture and market other coding systems might be necessary to exchange information. There is no solution yet for the amount of different code systems needed and lack of integration between all of them. The most universal code system (SNOMED CT) is recommended to use, but additional code systems are currently inevitable.
4.2.2. Registration burden
4.2.2.1. GraphicsChallenge 5: Using graphics as input controls will not be possible anymore when capturing data does not lead to standardised content. Graphics needs to change to make standardised content possible or they have to be removed.
Recommendation 5 (*): Either data fields for standardised content need to be created or comprehensive interactive graphics that allow a user to capture detailed data need to be developed. Nonetheless, graphics can be of great use for capturing and presenting information. Images can give better insight at a glance instead of having to read every option or looking for a specific textual option.
29 4.2.2.2. Prefilling data fields
Challenge 6: It might occur that there are HCIM data elements that are currently captured in a different way or not at all in the system. This would imply another working method or additional data that needs to be captured. This needs to be prevented.
Recommendation 6 (*): Information that is either available or can be defined or derived by using several rules, can be prefilled in data fields. This saves much time and makes sure the users do not have to change their working method in many ways. To clarify, there are some examples from the HCIM studied below.
Example 1: An example of automatically prefilling data fields are timestamps. Since timestamps are data elements in many HCIM, it is convenient when these do not have to be filled in every time. Especially for measurements and determinations, an automatic timestamp of the current date and time should be prefilled. When necessary, this can always be changed. However, it is more common to use the current time and date.
Example 2: An example of information that can be prefilled in a rule-based manner corresponds to the HCIM ‘General Measurement’. [26] This HCIM can be used to capture a measurement or determination made for a patient. The data element ‘Result Status’ describes the status of the entire measurement and is currently not information that is captured. Possible values are ‘Pending’, ‘Preliminary’, ‘Final’, ‘Appended’, ‘Corrected’. The HCIM ‘General Measurement’ covers measurements like temperature. When for instance ‘Temperature’ is measured, the status of this measurement is usually ‘Final’. It is inconvenient for the user to fill in the ‘Result Status’ too, when this is usually the same. Therefore, rules can be created to prefill this data element. When a measurement or determination captured, it should always be prefilled as ‘Final’. When a measurement or determination is altered after saving it, the status should automatically change to ‘Corrected’. When for instance a list with questions for a scoring system is not completely finished yet but saved anyways, the result status should automatically be ‘Preliminary’. Since this could save time, it should be determined for all data elements to what extent they can be prefilled and what rules could be added to prefill differently for several situations.
4.2.2.3. Mandatory elements
Challenge 7: Not all data elements have a cardinality of ‘1’ and are therefore not mandatory to be filled in. Although it should be stimulated to fill in as much data as possible at once, there might be data elements that are not applicable in the current situation since not every case needs the same amount of depth. Besides, some data might be unknown at the moment, or there might not be much time to fill in the data. There is a reason that certain data elements are mandatory in the HCIM guidelines, while others are not. It can be overwhelming and discouraging for users when they think they have to fill in all of them.
Recommendation 7: The non-mandatory fields are optional and this should be made clear in the user interface so the users do not feel obliged to fill in all the data fields. Although this distinction is made in the current data capture as well, it needs to be clear when implementing according to HCIM since these lead to more data fields than before.
4.2.3. Consistency
4.2.3.1. LabelsChallenge 8: While data can currently be captured in several different GUI elements in the system, with different labels, this is not possible anymore with HCIM. Since specialists tend to use abbreviations for their own reporting and the labels of all the data fields, there is no uniformity at the moment.
Example 1: For instance, the data fields for gravidity of a woman (amount of pregnancies) is sometimes called gravidity, another time gravida, or sometimes abbreviated to grav. The date of last menstruation
