- Email: [email protected]
Implementing the Canadian Apheresis Registry: A programmer's point of view
Accepted Manuscript Title: Implementing the Canadian Apheresis Registry: a programmer’s point of view Author: Albert Ebidia PII: DOI: Reference:
S1473-0502(17)30131-3 http://dx.doi.org/doi:10.1016/j.transci.2017.07.003 TRASCI 2196
To appear in:
Please cite this article as: Albert Ebidia, Implementing the Canadian Apheresis Registry: a programmer’s point of view, Transfusion and Apheresis Science (2017), http://dx.doi.org/10.1016/j.transci.2017.07.003 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ALBERT EBIDIA, Page 1
Implementing the Canadian Apheresis Registry: a programmer’s point of view
ip t
ALBERT EBIDIA, Programmer (Canada) for the Listening Post Section, Transfusion and Apheresis Science
Many articles in today’s medical journals, including this very publication, support their findings
cr
by providing data collected during the research of their selected study. Various terms used
us
include a randomized group of patients, outcome data, total counts and averages. Many of these terms are then supported by figures and tables depicted by line graphs, bar graphs and
an
histograms. The question to answer is how was all this data gathered? The following
M
discussion will attempt to explain, in simple terms, how the data entry and collection was
d
implemented for the Canadian Apheresis Registry database.
te
The original data collection for the Canadian Apheresis Registry used a multi-page paper form
Ac ce p
containing all the required points for entry. Nursing staff would fill in the appropriate data points by either selecting from a list of options or writing down the necessary data in the space provided. These forms were then mailed to the head office in Ottawa where staff would manually inspect and count many of the data points needed for statistical reporting purposes and to publish the reports for the yearly conference. The need to automate this data collection was realized and a solution was achieved.
In order to remove the paper based system, a web based approach was the only remedy.
Page 1 of 7
ALBERT EBIDIA, Page 2
In a meeting with Dr. Gail Rock, PhD, MD, FRCP, Chair of the Canadian Apheresis Group (CAG), a conceptual discussion took place which included topics such as how many centers were involved, who performed the data entry and what was the objective of such a registry. The
ip t
answer to these questions was that approximately 40 centers across Canada participate in the
cr
registry. The nursing staff enters the data and the objective is to publish the various reports in
us
a year book that is presented and discussed at the annual CAG conference.
an
One of the very first things that a programmer requires is a set of good specifications. Fortunately, for me, this already existed in the form of the dozen pages of the paper system
M
which was then in place. This gave me an idea of the number of data points to build on for data collection. The forms contained various sections which were well designed with many quick
te
d
selection options that only required a check mark.
Ac ce p
Further discussion, in more detail, was needed for the conversion from a paper based system to an online system included the following items.
Privacy
Patient privacy is a high priority for any healthcare online system. The CAG registry uses a center selected arbitrary ID that can contain both numbers and letters. Only the center knows who the patient is. This ID is selected by the center to open the list of treatments to add or edit information. The concept of privacy also applies across centers. The system requires a login user id for each center so that specific data is only accessible to that particular center
Page 2 of 7
ALBERT EBIDIA, Page 3
Required entries In all systems dealing with data, there are certain fields that cannot be left blank. These entries
ip t
were identified and the programmer applied various identification settings to alert the user
cr
that they are required. Examples are: setting the background color of the entry and presenting
us
a message that the field is a required entry.
an
Free text entries
All programmers are concerned when a free text field is part of the project specifications. The
Pick lists
d
M
client needs to be made aware that reporting on free text fields is sometimes not possible.
te
This is the most important concept in designing a system where entry speed is a high priority.
Ac ce p
Nursing staff have enough work on their hands and providing pick lists is a great utility to quickly enter the data.
Sometimes the requirements dictate the need to pick more than one option for the same pick list. There are ways that the programmer can accomplish this. Furthermore, there may be a need to add an ‘Other’ option in a pick list where the user cannot select the item from the existing list. If ‘Other’ is selected, the box can appear to manually enter the item.
Numbers versus letters entry
Page 3 of 7
ALBERT EBIDIA, Page 4
Identifying the field content in terms of whether it should have number or letters is important for the programmer. This decision will dictate the backend database setup.
ip t
Date entries
cr
The date entry format may be important to all users and a format description can be added on
us
the screen. An example would look like this: ‘Enter treatment date (dd-mm-yyyy)’
an
The concept of 1 to many
This concept needs to be discussed in the early stages of the requirements. The client needs to
M
understand that this is extremely important in the way the database is setup. A simple example would be the existence of one unique patient that has many treatments during his or her
d
course of care. The programmer will create two tables. One will store patient information and
Ac ce p
tables will contain.
te
the other treatment data. The link between the two will be a hidden numeric id that both
Maintenance and support
Once the front end and back end are implemented and any outstanding bugs have been resolved, the project then moves to a maintenance and support mode. This arrangement between the client and the programmer will dictate the manner in which users will contact the export user in case any issues arise during normal use of the system. The programmer will usually request that a single point of contact receives all calls and if a solution cannot be provided they would then be forwarded a description of the issue.
Page 4 of 7
ALBERT EBIDIA, Page 5
Instruction Manual The system manual can take many forms. A printed document can be supplied and distributed
ip t
to all users. This, however, would apply to the current version of the system and would require
cr
additional addendums when new functionality is added to the system. The easiest way to
produce a manual is to incorporate it in the system. A PDF is usually the best solution since all
us
computers have Adobe reader installed. Microsoft word can be used to create the document
an
which will include diagrams and a detailed description of the software functionality. The final document can be converted to PDF and loaded as part of the web site files. A link within the
M
software can easily open the PDF without having to exit the system. When new functionality is
te
Reports
d
added, a new PDF can be loaded containing the latest changes.
Ac ce p
Once data has been accumulated in the database, reporting can take place. The client will need to provide the programmer detailed samples of all the required reports. This can come in the form of excel spreadsheets or text documents. The programmer will review the details and make sure that all desired data actually exists in the system. Each report will require the creation of a query that will contain conditions and filters pertaining to the required specifications. He can create a link within the system to provide a list of all the reports that can be accessed. The best way to produce that data is to allow the user to view the results on the screen. A button with the Excel logo is then clicked to convert the screen report to an Excel spreadsheet that can be saved on the user’s PC. The user can manipulate the data using Excel
Page 5 of 7
ALBERT EBIDIA, Page 6
functionality if desired or just print it directly. The Canadian Apheresis Group (CAG) annual conference book contains many of the reports which allows all hospitals across Canada to
ip t
compare their data.
cr
System Setup
This important feature in the software allows the expert user to add items to the many pick lists
us
that all users will be shown during data entry. The expert user will have a login and password
M
the number of calls made to the programmer.
an
that will display this ability among others that only they can see. Having this flexibility can limit
Conclusion
te
Ac ce p
user reports and 208 queries.
d
The current version of the CAG database includes 31 pick-lists, 33 tables, 43 system reports, 8
As with any software, the need to revise and add functionality is always present. I have taken this into consideration when developing the original model. Yearly post conference discussions by the physicians and nurses have resulted in some minor changes to the existing system. Luckily, these did not result in major database backend changes and, so far, do not require code rewrites.
Overall comments relating to the system have been very positive and all registered centers across Canada are quite happy with this real time bed side data entry model. The system has
Page 6 of 7
ALBERT EBIDIA, Page 7
come a long way since its paper based inception. Personally, I am happy to be connected with
Ac ce p
te
d
M
an
us
cr
ip t
the Canadian Apheresis Group and felt gratified to have received such positive feedback.
Page 7 of 7
S1473-0502(17)30131-3 http://dx.doi.org/doi:10.1016/j.transci.2017.07.003 TRASCI 2196
To appear in:
Please cite this article as: Albert Ebidia, Implementing the Canadian Apheresis Registry: a programmer’s point of view, Transfusion and Apheresis Science (2017), http://dx.doi.org/10.1016/j.transci.2017.07.003 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ALBERT EBIDIA, Page 1
Implementing the Canadian Apheresis Registry: a programmer’s point of view
ip t
ALBERT EBIDIA, Programmer (Canada) for the Listening Post Section, Transfusion and Apheresis Science
Many articles in today’s medical journals, including this very publication, support their findings
cr
by providing data collected during the research of their selected study. Various terms used
us
include a randomized group of patients, outcome data, total counts and averages. Many of these terms are then supported by figures and tables depicted by line graphs, bar graphs and
an
histograms. The question to answer is how was all this data gathered? The following
M
discussion will attempt to explain, in simple terms, how the data entry and collection was
d
implemented for the Canadian Apheresis Registry database.
te
The original data collection for the Canadian Apheresis Registry used a multi-page paper form
Ac ce p
containing all the required points for entry. Nursing staff would fill in the appropriate data points by either selecting from a list of options or writing down the necessary data in the space provided. These forms were then mailed to the head office in Ottawa where staff would manually inspect and count many of the data points needed for statistical reporting purposes and to publish the reports for the yearly conference. The need to automate this data collection was realized and a solution was achieved.
In order to remove the paper based system, a web based approach was the only remedy.
Page 1 of 7
ALBERT EBIDIA, Page 2
In a meeting with Dr. Gail Rock, PhD, MD, FRCP, Chair of the Canadian Apheresis Group (CAG), a conceptual discussion took place which included topics such as how many centers were involved, who performed the data entry and what was the objective of such a registry. The
ip t
answer to these questions was that approximately 40 centers across Canada participate in the
cr
registry. The nursing staff enters the data and the objective is to publish the various reports in
us
a year book that is presented and discussed at the annual CAG conference.
an
One of the very first things that a programmer requires is a set of good specifications. Fortunately, for me, this already existed in the form of the dozen pages of the paper system
M
which was then in place. This gave me an idea of the number of data points to build on for data collection. The forms contained various sections which were well designed with many quick
te
d
selection options that only required a check mark.
Ac ce p
Further discussion, in more detail, was needed for the conversion from a paper based system to an online system included the following items.
Privacy
Patient privacy is a high priority for any healthcare online system. The CAG registry uses a center selected arbitrary ID that can contain both numbers and letters. Only the center knows who the patient is. This ID is selected by the center to open the list of treatments to add or edit information. The concept of privacy also applies across centers. The system requires a login user id for each center so that specific data is only accessible to that particular center
Page 2 of 7
ALBERT EBIDIA, Page 3
Required entries In all systems dealing with data, there are certain fields that cannot be left blank. These entries
ip t
were identified and the programmer applied various identification settings to alert the user
cr
that they are required. Examples are: setting the background color of the entry and presenting
us
a message that the field is a required entry.
an
Free text entries
All programmers are concerned when a free text field is part of the project specifications. The
Pick lists
d
M
client needs to be made aware that reporting on free text fields is sometimes not possible.
te
This is the most important concept in designing a system where entry speed is a high priority.
Ac ce p
Nursing staff have enough work on their hands and providing pick lists is a great utility to quickly enter the data.
Sometimes the requirements dictate the need to pick more than one option for the same pick list. There are ways that the programmer can accomplish this. Furthermore, there may be a need to add an ‘Other’ option in a pick list where the user cannot select the item from the existing list. If ‘Other’ is selected, the box can appear to manually enter the item.
Numbers versus letters entry
Page 3 of 7
ALBERT EBIDIA, Page 4
Identifying the field content in terms of whether it should have number or letters is important for the programmer. This decision will dictate the backend database setup.
ip t
Date entries
cr
The date entry format may be important to all users and a format description can be added on
us
the screen. An example would look like this: ‘Enter treatment date (dd-mm-yyyy)’
an
The concept of 1 to many
This concept needs to be discussed in the early stages of the requirements. The client needs to
M
understand that this is extremely important in the way the database is setup. A simple example would be the existence of one unique patient that has many treatments during his or her
d
course of care. The programmer will create two tables. One will store patient information and
Ac ce p
tables will contain.
te
the other treatment data. The link between the two will be a hidden numeric id that both
Maintenance and support
Once the front end and back end are implemented and any outstanding bugs have been resolved, the project then moves to a maintenance and support mode. This arrangement between the client and the programmer will dictate the manner in which users will contact the export user in case any issues arise during normal use of the system. The programmer will usually request that a single point of contact receives all calls and if a solution cannot be provided they would then be forwarded a description of the issue.
Page 4 of 7
ALBERT EBIDIA, Page 5
Instruction Manual The system manual can take many forms. A printed document can be supplied and distributed
ip t
to all users. This, however, would apply to the current version of the system and would require
cr
additional addendums when new functionality is added to the system. The easiest way to
produce a manual is to incorporate it in the system. A PDF is usually the best solution since all
us
computers have Adobe reader installed. Microsoft word can be used to create the document
an
which will include diagrams and a detailed description of the software functionality. The final document can be converted to PDF and loaded as part of the web site files. A link within the
M
software can easily open the PDF without having to exit the system. When new functionality is
te
Reports
d
added, a new PDF can be loaded containing the latest changes.
Ac ce p
Once data has been accumulated in the database, reporting can take place. The client will need to provide the programmer detailed samples of all the required reports. This can come in the form of excel spreadsheets or text documents. The programmer will review the details and make sure that all desired data actually exists in the system. Each report will require the creation of a query that will contain conditions and filters pertaining to the required specifications. He can create a link within the system to provide a list of all the reports that can be accessed. The best way to produce that data is to allow the user to view the results on the screen. A button with the Excel logo is then clicked to convert the screen report to an Excel spreadsheet that can be saved on the user’s PC. The user can manipulate the data using Excel
Page 5 of 7
ALBERT EBIDIA, Page 6
functionality if desired or just print it directly. The Canadian Apheresis Group (CAG) annual conference book contains many of the reports which allows all hospitals across Canada to
ip t
compare their data.
cr
System Setup
This important feature in the software allows the expert user to add items to the many pick lists
us
that all users will be shown during data entry. The expert user will have a login and password
M
the number of calls made to the programmer.
an
that will display this ability among others that only they can see. Having this flexibility can limit
Conclusion
te
Ac ce p
user reports and 208 queries.
d
The current version of the CAG database includes 31 pick-lists, 33 tables, 43 system reports, 8
As with any software, the need to revise and add functionality is always present. I have taken this into consideration when developing the original model. Yearly post conference discussions by the physicians and nurses have resulted in some minor changes to the existing system. Luckily, these did not result in major database backend changes and, so far, do not require code rewrites.
Overall comments relating to the system have been very positive and all registered centers across Canada are quite happy with this real time bed side data entry model. The system has
Page 6 of 7
ALBERT EBIDIA, Page 7
come a long way since its paper based inception. Personally, I am happy to be connected with
Ac ce p
te
d
M
an
us
cr
ip t
the Canadian Apheresis Group and felt gratified to have received such positive feedback.
Page 7 of 7