studentenbureau umcg universitair medisch centrum...

Validation of a Process-driven Database Design method for an Electronic Health Record-system

Developing the process models

Sjoerd Gerrit Hoekstra

Groningen, February 2014

UMCG, Project Nieuw EPDRijksuniversiteit Groningen, Technology and Operations Management

Studentenbureau UMCG Universitair Medisch Centrum Groningen

Table of contents

Appendix I Theme poster on Patient Data Exchange Systems with Regional Hospitals ........................ 1

Appendix II Theme case description ................................................................................................... 3

Appendix III BPMN Appendix ............................................................................................................... 5

Appendix IV Feedback user-interface .................................................................................................. 25

Appendix V Process models (BPMN diagrams) .................................................................................. 27

I First process model ..................................................................................................................... 29

II Second process model ................................................................................................................ 30

III Third process model ................................................................................................................... 31

IV Provisional process model .......................................................................................................... 32

V Final process model .................................................................................................................... 33

Note: the images in appendix V can be seen when the pages are unfolded

1

Appendix I Theme poster on Patient Data Exchange Systems with

Regional Hospitals

3

Appendix II Theme case description

Theme: An Electronic Health Record (EHR) system within a LTHN

Project: Validation of the logic business data model of the LTHN

Supervisor: Dr. H. Balsters

Prerequisites: Systems design, Business modeling, Basic IT-skills (process- and data modeling,

databases), affinity with engineering systems

Situation

At a LTHN (Large Teaching Hospital in the Netherlands), a large migration project is in progress to replace

the current Hospital Information System (HIS) with an advanced Electronic Health Record (EHR) system.

Currently it is being investigated how to migrate some fifty source databases into one central target

database system. This central database is a prerequisite for an EHR system such as developed at the LTHR.

This migration process is an extremely complex operation; not only is the overall size of the source data

involved overwhelming, but in the process one has to also figure out which source data is relevant to the

target system, and subsequently one has to figure out how to integrate and map the source data to the

target system in a consistent manner. In the source systems, data may be redundant with respect to the

to-be designed target system; the data may also be incorrect or out of date. Hence the migration process

also offers an opportunity to cleanse existing data. Since hospital-oriented systems also lay a huge

emphasis on reliability and safety, such a migration process has to be managed in a controllable fashion,

meaning that each step in the migration process has to be meticulously defined and validated.

In the migration process we distinguish functional aspects and technical aspects. Functional aspects

concern the desired functionalities of the system, while technical aspects concern the implementation of

the functional aspects into a technically working system. Our theme concerns the design of a logical and

technical model based on process analyses to fulfill the functional needs of a patient admission process in

a EHR system.

The LTHR has already developed a data model for a central database environment to merge all hospital

data from multiple source systems to a unambiguous defined data model , called the LBGM (Logisch

Bedrijfs Gegevens Model). This data model is based on the ‘reference domain model for hospitals’ (RDH)

which is a reference model for the relationships between the various business processes and information

objects within a hospital environment. The LTHR has expressed the need to validate the correctness of

the LBGM. In order to keep the scope of our validation project under control (our resources are limited:

three students, simultaneously working within a period of three months), we shall confine the model to a

part of the EHR system; those parts of the data model that are involved in the process of triage and

routing of patients that are referred to the hospital for a specific medical problem.

Problem

Information about the patient is captured in so-called Hospital Information Systems (HIS). In order to

cater to a hospital with a large diversity in users, a HIS tends to be very complex, even when one, for

example, confines the system to, say, patient admittance within the hospital. These systems also deal with

very privacy-sensitive medical patient data. As a result they are strictly locked-down to prevent unwanted

leaks of these types of data.

4

In order to enter or transfer patient data within a hospital, a model to facilitating this patient data entry

and exchange is envisioned. However, hospitals are struggling with constructing such an system: one has

to figure out which source data is relevant to the targeted EHR-system, and subsequently one has to figure

out how to integrate and map the source data to the target system in a consistent manner. On the other

hand, Patient Data entry and exchange is often reasonably well understood as a process: we have

information on how to process patient data, which checks are to be performed, in which order the

process should take place, etc. In order to explicitly define such a process, we wish to design a business

process model capturing all of the requirements necessary to perform patient data entry and exchange in

a consistent and complete manner. Once such a process model of patient data entry and exchange is

realized, we can move on to the design of the underlying data model supporting the process model. This

data model (a conceptual blueprint of a database) will offer the backbone of the a part of the EHR-system.

One could say that the process model offers the context in which the data model is to be developed.

Hence, the EHR-process is leading with respect to the EHR-data. The University of Groningen has already

developed his own method to systematically map process models(specified in SIPOC) to data models.

Our proposed research aims at realizing these same process- and data models supporting an EHR-system

at the LTHN by using the BPMN to FBM method. BPMN stands for Business Process Modeling Notation,

and constitutes an internationally accepted (ISO-) standard for modeling business processes. FBM stands

for Fact-Based Modeling, and constitutes an ISO-standard for data modeling. In summary, we can state

that our university wishes to investigate how data is currently entered and exchanged, what the

requirements for an entry and exchange system are, and how to design a patient data entry and exchange

system based on these requirements, resulting in a data model that could facilitate an EHR system.

Once we have derived an FBM data model supporting patient admittance as part of the LTHN EHR, we

can compare our FBM data model with the existing LBGM data model to validate correctness of (part of)

the LBGM.

Project Description

Our research aims at solving the following question:

“How to validate the correctness of data models supporting an EHR?”

This leads us to the following sub-questions:

1. What is the state of the art concerning the entry and exchange of medical patient data within the LTHR?

2. Who is currently entering and exchanging data, what data is entered and how is the data exchanged?

3. What are the constraints on patient data entry and exchange? 4. What are the requirements of a functional design of an LTHN EHR-system according the

admittance process? 5. How can we code these requirements into a process model? 6. How can we systematically derive a data model from the process model? 7. How does the existing LBGM data model of the LTHN compare to our derived data model?

Organization

Three students will be working simultaneously on this project for a period of three months. Starting date

will be September 1st, 2013.

5

Appendix III BPMN Appendix

The red and orange descriptions are also that colour in the BPMN diagram. Red does not

belong to the user interface and database, orange belongs only to the user interface.

1.Referral

The referral is a letter, fax or digital via ZorgDomein. These referrals arrive at the healthcare administration of the portal specialism to which it is addressed.

A.Login healthcare administration portal specialism

The login is a sub-process, these login processes are described on the last page of the BPMN appendix.

2.Check for digital referral

The referral could be digital or hard-copy, the healthcare administration portal specialism determines what kind of referral it is.

Input:

Digital referral: Yes/No

3.Digital referral?

At this gateway the direction of the process is determined based on the data which is already available in the system.

4.Create digital referral

Not digital referrals and attachments are scanned.

System input:

Referral number (scan name/number)

Attachments (name/number)

Input:

Referrer Date



5.Check if referral is administrative assessable

It is determined if the referral is complete enough to start the triage procedure.

Input:

Referral administrative assessable: yes/no

6.Referral administrative assessable?

6


7.Determine missing data

In this activity the data which are required are determined. In this stage of the process only the general information is viewed. These are the name and address data, and/or the referral reason.

Input possibilities:

Empty space with following possibilities:

First name Surname Further initials Gender Date of birth Street Street number Zip code Residence Referral reason

E.Request missing data

The missing data which are determined in the last activity are asked for at the referrer, this process is described on the last page of the BPMN appendix.

8.Insert gender, surname and date of birth

The gender, surname and date of birth are inserted.

Input:

Surname Gender Date of birth

System input:

Referral

9.Patient known?


10. Insert gender and date of birth

The gender and date of birth are inserted.

Input:

Gender Date of birth

System input:

7

Referral

11.Patient known?


12.Determine if patient data is complete

In this activity it is determined if the patient data is complete.

Input:

Patient data complete: yes/no

System input:

Referral

13.Patient data complete?


14.Determine missing patient data

In this activity the data which are required are determined.



BSN First name Date of birth Surname Further initials Occupation Gender Phone number Marital status Is of multiple

Street Street number Zip code Residence Birth place

GP name GP initials GP zip code GP street number GP place

8

Insurance company Insurance code Insurance type Policy number Insurance class Insurance date

F.Request missing patient data

The missing data which are determined in the last activity are asked for at the referrer, this process is described on the last page of the BPMN appendix.

15.Create patient registration

In this activity the following patient data is registered:

Input:





System input:

Patient number

16.Determine if patient is fully/correct subscribed?

In this activity the current patient data is compared with the patient data on the referral.

9

Input:

Current patient data equal to referral: yes/no

System input:

Patient data in EHR-system

Referral

17.Patient fully/correct subscribed?


18.Supplement patient registration

The patient registration is supplemented.






System input:

Patient data in EHR-system

Referral

10

19.Link referral to patient registration

The referral is linked to the patient. At this point the following is registered:

Input:

Referral number Clinic: yes/no

20.Determine if a doctor is required for determination (sub-)specialism

In this activity a employee of the healthcare administration portal specialism determines if he/she can determine the right (sub-)specialism themselves or that it has to be done by a doctor.

Input:

Doctor required: yes/no

System input:

Referral

21.Doctor required for determination (sub-)specialism?


B.Login Doctor portal specialism


22.Determine (sub-)specialism

The doctor determines the (sub-)specialism of the referral.

Input:

(sub-)specialism

System input:

Referral

23. Determine (sub-)specialism

The employee of the healthcare administration portal specialism determines the (sub-) specialism of the referral.

Input:

(sub-)specialism

System input:

Referral


11


24. Forward referral

In this activity the referral is send to the right (sub-)specialism. In this activity the employee sees an overview of the procedure.

C.Login healthcare administration (sub-)specialism


25.Attachments present at referral?

At this gateway the direction of the process is determined based on the data which is already available in the system (data is already available).

26.Link attachments to departmental system

When there are attachments at a referral, these attachments are added to the database system of the (sub-)specialism.

27.Determine if a doctor is required for the triage

In this activity it is determined if a doctor is required for the triage, otherwise the employee of the healthcare administration (sub-)specialism can do it themselves. If the referral is substantive incomplete is must also be send to a doctor.

Input:

Doctor required: yes/no

System input:

Referral

28.Doctor required for triage?




29.Determine if referral belongs to LTHN

In this activity it is determined if the referral belongs to the LTHN.

Input:

Belongs referral to LTHN: yes/no

System input:

Referral

30.Belongs referral in LTHN?

12


31.Determine reason why referral does not belong to LTHN

In this activity the reason is determined why the referral does not belong to the LTHN, the healthcare administration (sub-)specialism can communicate this reason with the referrer.

Input:

Reason of rejection

System input:

Referral

32.Determine if (sub-)specialism is right

In this activity it is determined if the referral is at the right (sub-)specialism.

Input:

Right (sub-)specialism: yes/no

System input:

Referral

33.Right (sub-)specialism?


34.Determine right (sub-)specialism

In this activity it is determined what the right (sub-)specialism is.

Input:

Right (sub-)specialism

System input:

Referral

35.Forward referral

In this activity the referral is send to the right (sub-)specialism.

36.Substantive assessment

In this activity the triage is performed, the following points are determined:

Input:

Additional research (not mandatory)

Days until appointment

13

Agenda code

System input:

Referral

37. Additional research required?


38.Determine if authorization is required

In this activity it is determined if the additional research must be authorized by a doctor.

Input:

Authorisation needed for additional research: yes/no

System input:

Referral


39.Autorisation required?




40.Additonal research in other hospital?

At this gateway the direction of the process is determined based on the data which is already available in the system (data is already available, clinical: yes/no).

41.Pass on additional research to other hospital

In this activity the additional research is send to the other hospital (referrer) to carry out there.

System input:

Referral



42.Schedule appointments

In this activity a letter will be send to the patient when and where the appointment will take place. Besides this information there will be send some extra information to the patient.

Input:

14

Specialism

Instant

Agenda code (not mandatory)

Requesting (sub-)specialism

Referrer

System input:



Agenda code

Referral

43.Appointment

This is the end of the triage procedure.



44.Determine if source for missing data is equal to referrer

It is determined if the referrer should give the additional data or that it must come from another source.

Input:

Source for additional research equal to referrer: yes/no

System input:

Referral

45.Referrer equal to source for missing data?


G.Ask permission from patient

In this activity a statement of the patient is asked for to approach other parties for additional data about the patient, this process is described on the last page of the BPMN appendix.

46. Received permission?


H. Request additional data

15

The additional data is requested at the external parties, this process is described on the last page of the BPMN appendix.



47.Inform referrer why it does not belong to LTHN

A message is send to the referrer to make clear why the referral does not belong to the LTHN.

Input:

Note why the referral does not belong to the LTHN.

System input:

Referral

Reason of rejection

48. End triage procedure

The triage procedure end.

D.Login doctor (sub-)specialism


49.Determine if there is enough data for the triage

Here it is determined if the referral contains enough medical data for the triage.

Input:

Enough data for substantive assessment: yes/no.

System input:

Referral

50. Enough data?


51.Determine missing data

In this activity the missing data is determined.

Input:

Empty space: More detailed referral reason, history, diagnoses, scans, etc.

System input:

Referral

52.Determine source for missing data

16

Here the source for the missing data is determined.

Input:

Source for missing data

System input:

Referral

53.Determine if the process can wait for missing data

In this activity it is determined if the triage process can wait for the missing data.

Input:

Wait for additional data: yes/no

System input:

Referral

54.Can the process wait for missing data?


55.Pass on missing data to healthcare administration (sub-)specialism

The data which has to be requested is send to the healthcare administration (sub-)specialism.



56.Determine if referral belongs to LTHN

In this activity it is determined if the referral belongs to the LTHN.

Input:

Belongs referral to LTHN: yes/no

System input:

Referral

57.Belongs referral in LTHN?


58.Determine reason why referral does not belong to LTHN

In this activity the reason is determined why the referral does not belong to the LTHN, the healthcare administration (sub-)specialism can communicate this reason with the referrer.

Input:

17

Reason of rejection

System input:

Referral

59.Determine if (sub-)specialism is right

In this activity it is determined if the referral is at the right (sub-)specialism.

Input:

Right (sub-)specialism: yes/no

System input:

Referral

60.Right (sub-)specialism?


61.Determine right (sub-)specialism

In this activity it is determined what the right (sub-)specialism is.

Input:

Right (sub-)specialism

System input:

62.Forward referral

In this activity the referral is send to the right (sub-)specialism.

63.Substantive assessment

In this activity the triage is performed, the following points are determined:

Input:



Agenda code



64.Authorize additional research

In this activity the doctor authorizes the additional research.

Input:

18

Digital agreement

System input:

Referral


Sub-processes


1.Employee healthcare administration portal specialism logged in?

Is the employee logged in already?

2.Insert username and password

In this activity the username and password are entered.

Input:

Username

Password

3.Combination right?

Belongs to this combination username and password an account?

4.Account authorized for healthcare administration pre-triage?

Is the account authorized for healthcare administration pre-triage?

5.Referral in process?

This gateway does not come back in the system since the user can see for himself if he has a referral in process already.

6.Take referral in process

The referral is taken out of the stock of referrals to continue working.

Input:

Pick a referral out of the list.

B.Login Doctor portal specialism

1.Doctor portal specialism logged in?

Is the doctor logged in already?



Input:

19

Username

Password



4.Account authorized for doctor pre-triage?

Is the account authorized for doctor pre-triage?





Input:



1.Employee healthcare administration (sub-)specialism logged in?

Is the employee logged in already?



Input:

Username

Password



4.Account (sub-)specialism equal to referral (sub-)specialism?

Is the (sub-)specialism account equal to the (sub-)specialism of the referral?

5.Account authorized for employee healthcare administration triage?

Is the account authorized for healthcare administration triage?



20



Input:



1.Doctor (sub-)specialism logged in?

Is the doctor logged in already?



Input:

Username

Password



4.Account (sub-)specialism equal to referral (sub-)specialism?

Is the (sub-)specialism account equal to the (sub-)specialism of the referral?

5.Account authorized for doctor triage?

Is the account authorized for doctor triage?





Input:


E.Request missing data

1.Request missing data

The missing data which are determined in the last activity are asked for at the referrer.

Input:

Send to referrer

21

2. Response within 5 days?

The system checks when the response arrives, is it within 5 days the process will go on, otherwise it will enter a loop.



3.Register additional data

The additional data is registered.

Input: Empty space with following possibilities:

First name Surname Further initials Gender Date of birth Street Street number Zip code Residence Referral reason

System input:

Reaction of referrer

F.Request missing patient data

1.Request missing patient data

The missing data which are determined in the last activity are asked for at the referrer.

Input:

Send to referrer





3. Register additional patient data

The additional data is registered.



22





System input:

Reaction of referrer

G.Request patient permission

1.Ask permission from patient

In this activity a statement of the patient is asked for to approach other parties for additional data about the patient

System input:

Source for data

Referral

2.Response within 5 days?




23

3.Register results of permission question

Hereby the result of the permission question is registered in the system.

Input:

Permission received: yes/no

System input:

Reaction of the patient

H.Request additional data

1. Request additional data

The additional data is requested at the external parties.

Input:

Empty space: History, diagnoses, scans, etc.

System input:

Referral

Information question: More detailed referral reason, history, diagnoses, scans, etc.





3.Register additional data

In this activity the additional data is registered.

Input:

Empty space: history, diagnoses, etc.

Upload possibility: scans, etc.

System input:

Reaction of external party.

25

Appendix IV Feedback user-interface

After receiving feedback from the end-users, the three researchers (Hoekstra, Fischer & Spits) analyze and discuss the root cause of the “flaws, including making a distinction between “method related flaws” and “method appliance flaws”. Method related flaws, are the flaws, caused by an structural flaw in the method (e.g.: asking the wrong questions or missing steps in the method) which indicates a required adjustment in the method. A flaw in the application of the method indicates a non-method related flaw (e.g.: inconsistency of the end-user or interpreting the issue wrongly).

1. “Referral and attachment should be auto numbers”: This is not part of the research, as this problem is not database driven, but is an issue the programmer would face and solve. Method appliance flaw.

2. “Link referral and attachments”: At first the end-user stated, the attachment is not linked to the referral at this point, since the attachment is part of a so called “external source system”. When going through the validation interview, the end-user indicates that this does not make sense and confirming that the attachment should be linked to the referral at this point of the process. Method appliance flaw.

3. “Contacting the referrer twice on same issue: missing information”: One of the end-users indicated, that the referral would be addressed twice in a short period for a similar issue. This is noted and confirmed but does not seem to be a problem. Method appliance flaw.

4. “GP data is filled in automatic, after entering the name and residence”: This is not part of this research, since the researchers are not translating the database to a system. This is an issue for the programmer. Method appliance flaw

5. “Referral reason is missing” An human error by the UI-developer. This not caused by the method, as it is correct in the database models. Method appliance flaw

6. “Clinical yes/no might be redundant; ‘Clinical internal yes/no’ missing”: The external clinical option was missing from the DB, because of the wrong interpretation from the information provided by the process designer. Method appliance flaw.

7. ““Determiner (sub-) specialism” is redundant, but not in DBM”: As this is an additional field based on what a end-user would need, it does not seem to be relevant for the UI. This field is only UI driven and was not influenced by the ORM models. Also, this field conflicts with privacy issues. Method appliance flaw

8. “’Link attachments’ should be ‘link additional attachments’, since the attachments should

are linked early in the process” See feedback point 2, as this is relevant and caused by that point. Since the linkage of the attachment(s) is at an earlier stage, stated by the end-user, this screen changes as well. It can be considered as an inconsistency of the end-user. Method appliance flaw.

9. “Multiple input for ‘additional research’ should be available” The ORM does not imply there should be one or multiple input restrains on a single input field and is caused by an interpretation issue. Method appliance flaw.

10. “Unclear what ‘specialism required’ is” Simply a misread of the UI researcher, no adjustment needed on the models, just on the UI and was a human error caused by the UI-designer. Method appliance flaw.

11. “Referrer should be filled in already (not mandatory)” UI did not translate the database model correctly, due to misinterpretation. Method appliance flaw.

12. “Redundant, since the doctor does not need authorization” After showing the UI mock-ups, the end-users identified these authorization steps of a doctor to be redundant, as a doctor does not need authorization from a fellow doctor. Therefore, this process part is removed from the process model, the data model and thus from the UI. Method appliance flaw.

After discussing the flaws and the solutions for the specific researchers, the feedback is looped back to the designated designer. The methods are valid, as there is no reason based on the feedback from the end-users to adjust the current FB-BPM method. (Spits, 2014)

27

Appendix V Process models (BPMN diagrams)

I First process model

II Second process model

III Third process model

IV Provisional process model

V Final process model

29

I First process model

30

II Second process model

31

III Third process model

32

IV Provisional process model

33

V Final process model

studentenbureau umcg universitair medisch centrum...

Documents